I have weird problem. I'm able to get SCP to work properly using the installer. I was able to use my ps3 controller via BT, but after I restart my laptop I can't connect to my laptop. I've uninstalled and re-installed several times. I am able to connect my ps3 controller every time I reinstall but that is only till I restart my laptop. I have windows 8.1 if that makes a difference
(10-12-2015, 03:09 AM)redzero36 Wrote: [ -> ]I have weird problem. I'm able to get SCP to work properly using the installer. I was able to use my ps3 controller via BT, but after I restart my laptop I can't connect to my laptop. I've uninstalled and re-installed several times. I am able to connect my ps3 controller every time I reinstall but that is only till I restart my laptop. I have windows 8.1 if that makes a difference
Go to your services.msc and go down the list searching for SCP DSx Service and make sure it's status says started and it's startup type is set to automatically start. If it's not, double click it and edit the settings there.
(10-12-2015, 09:50 AM)LinkTree Wrote: [ -> ]Go to your services.msc and go down the list searching for SCP DSx Service and make sure it's status says started and it's startup type is set to automatically start. If it's not, double click it and edit the settings there.
It was started. Its on automatic. But when I press the PS button, the leds just flash and on SCP monitor it doesn't show that the controller connected. When I tried starting SCP sever I get the message " the root hub is already running, please stop the Scp service first!" So that should mean that I have the SCP DSx Service running properly right?
(10-12-2015, 09:58 AM)redzero36 Wrote: [ -> ]It was started. Its on automatic. But when I press the PS button, the leds just flash and on SCP monitor it doesn't show that the controller connected. When I tried starting SCP sever I get the message " the root hub is already running, please stop the Scp service first!" So that should mean that I have the SCP DSx Service running properly right?
Yes it does. I hope you get a response from someone more experienced soon!
(10-05-2015, 11:41 AM)WkNaZA9 Wrote: [ -> ]I've had a look at the logs, and so far the only difference pre-reboot and post-reboot is that HCI_Role_Change_EV is performed when connecting pre-reboot, but not after reboot.
Hope this can give some insight.
when working:
HCI_Command_Status_EV [0F] [00] [HCI_Accept_Connection_Request]
HCI_Role_Change_EV [12]
HCI_Connection_Complete_EV [03]
-- Genuine Sony DualShock 3 found
L2CAP_Connection_Request [02] PSM [11]
L2CAP_Connection_Response [03]
when not working (aka after reboot)
HCI_Command_Status_EV [0F] [00] [HCI_Accept_Connection_Request]
HCI_Connection_Complete_EV [03]
-- Genuine Sony DualShock 3 found
HCI_Connection_Request_EV [04] <connection attempts loop begin here>
HCI_Delete_Stored_Link_Key [0C12]
HCI_Remote_Name_Request [0419]
Hello, for the bluetooth not working after reboot, I did some further digging using a tool to capture usb packets, and the findings match what I found earlier. I suspect that after reboot,
HCI_Connection_Complete_EV [03] doesn't receive the proper parameters, thus it fails to indeed complete the connection and then loops.
I've attached a screenshot. On the left: capture before reboot. On the right: after reboot. See on the tabs at the bottom that
Connection_Complete receives different data in each case (also the role thing is not performed after reboot, not sure if relevant.) I can share the full capture if someone is interested. btw, the tool to capture is named "sysnucleus usbtrace", I'm using trial version in the snapshot.
Hope that helps to troubleshoot this issue, seems few users are also affected.
[
attachment=57565]
(10-12-2015, 01:08 PM)WkNaZA9 Wrote: [ -> ]Hello, for the bluetooth not working after reboot, I did some further digging using a tool to capture usb packets, and the findings match what I found earlier. I suspect that after reboot, HCI_Connection_Complete_EV [03] doesn't receive the proper parameters, thus it fails to indeed complete the connection and then loops.
I've attached a screenshot. On the left: capture before reboot. On the right: after reboot. See on the tabs at the bottom that Connection_Complete receives different data in each case (also the role thing is not performed after reboot, not sure if relevant.) I can share the full capture if someone is interested. btw, the tool to capture is named "sysnucleus usbtrace", I'm using trial version in the snapshot.
Hope that helps to troubleshoot this issue, seems few users are also affected.
Hi @nefarius, sorry to be so persistent, but I just keep reading and learning a bit about bluetooth and this issue after reboot.
I read this from a bluetooth book:
"In a Bluetooth connection, one side is the master and the other side is the slave. The device that initiates a connection assumes the role of master. This means that the gumstix becomes the slave for incoming connections. However, when the gumstix is the slave, it becomes undiscoverable by other devices. Fortunately, Bluetooth allows devices to switch roles after connecting. The link-mode setting controls how the device treats incoming connections. When set to master,accept this device accepts incoming connections in slave mode, but then requests to switch roles and become the master."
but going through the source of "BthDongle.Tasks.cs", it seems to be assumed that the controller would be always the master?
transfered = HCI_Accept_Connection_Request(bdAddr, 0x00); [BthDongle.Tasks.cs]
private int HCI_Accept_Connection_Request(byte[] bdAddr, byte role) [BthDongle.Hci.cs]
Wouldn't it be better to let the devices auto negotiate who's master and who slave?
Just for testing purposes, and to prove whether my point makes sense, could you send me a test version that assumes the controller is slave first, with only this change?
transfered = HCI_Accept_Connection_Request(bdAddr, 0x01);
I'm more than willing to donate through paypal if we manage to solve this weird reboot issue
(10-12-2015, 04:26 PM)WkNaZA9 Wrote: [ -> ]Hi @nefarius, sorry to be so persistent, but I just keep reading and learning a bit about bluetooth and this issue after reboot.
I read this from a bluetooth book:
"In a Bluetooth connection, one side is the master and the other side is the slave. The device that initiates a connection assumes the role of master. This means that the gumstix becomes the slave for incoming connections. However, when the gumstix is the slave, it becomes undiscoverable by other devices. Fortunately, Bluetooth allows devices to switch roles after connecting. The link-mode setting controls how the device treats incoming connections. When set to master,accept this device accepts incoming connections in slave mode, but then requests to switch roles and become the master."
but going through the source of "BthDongle.Tasks.cs", it seems to be assumed that the controller would be always the master?
transfered = HCI_Accept_Connection_Request(bdAddr, 0x00); [BthDongle.Tasks.cs]
private int HCI_Accept_Connection_Request(byte[] bdAddr, byte role) [BthDongle.Hci.cs]
Wouldn't it be better to let the devices auto negotiate who's master and who slave?
Just for testing purposes, and to prove whether my point makes sense, could you send me a test version that assumes the controller is slave first, with only this change?
transfered = HCI_Accept_Connection_Request(bdAddr, 0x01);
I'm more than willing to donate through paypal if we manage to solve this weird reboot issue
Don't worry, my "GIVE ME YOUR MONEY!!^11" post from above had nothing to do with your previous posts, I just felt like I should at least post one hint
No need to apologize, I'm very glad someone's willing to dig deeper into the inner workings of the Bluetooth magic. I myself also had
a lot to read and research since the takeover of the project, the more brains combine the faster we'll succeed I hope
Back to topic; yeah, I guess you're on the right track; the Role_Change command is missing from the faulty connection attempt. I guess since Scarlet.Crush mainly focused on stand-alone dongles and genuine controllers he might have hard-coded stuff that won't work under certain conditions. I sure can provide a build with said changes but wouldn't it be a lot faster if you'd compile it yourself?
EDIT: the genuine DS3 still connects after the code change; fake ones still having different troubles.
I'm having issues with my bluetooth device, we couldn't get it working and i was wondering if we could revisit the issue.
HW ID is: USB\VID_0A12&PID_0001&REV_5276
Device website:
http://www.cirago.com/bta6310.php
Now i'm not sure if you recall, But it installed just fine, however for whatever reason the DS3 doesn't connect to it. Could it be that this is a BT 3.0+EDR device?
I was going to attach the logs but curiously they missing from the driver folder, have they been renamed?
(10-12-2015, 05:10 PM)hellbringer616 Wrote: [ -> ]I'm having issues with my bluetooth device, we couldn't get it working and i was wondering if we could revisit the issue.
HW ID is: USB\VID_0A12&PID_0001&REV_5276
Device website: http://www.cirago.com/bta6310.php
Now i'm not sure if you recall, But it installed just fine, however for whatever reason the DS3 doesn't connect to it. Could it be that this is a BT 3.0+EDR device?
I was going to attach the logs but curiously they missing from the driver folder, have they been renamed?
They're renamed, yes but only slightly, should still begin with ScpDsx...log.xml