• State Not Answered
  • Replies 25 replies
  • Subscribers 73 subscribers
  • Views 10239 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 110654
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why am I seeing an "immediate" disconnect?

jimvert

I’m attempting to use an nRF51 dongle with connectivity_115k2_with_s130_1.0.0.hex burned on to it. I’m using the dongle as a central, attempting to connect to a peripheral. Upon connect, I’m seeing an almost immediate disconnect. In the same environment using different centrals (BlueZ HCI-base, and an iPhone), I'm able to connect to the peripheral with no problem.

Here are some traces. You’ll notice that the disconnect code is 62 (0x3e).

debian@beaglebone:~/ttm$ ./main.py 
Log: Successfully opened uart. Port name: /dev/ttyACM0. Baud rate: 115200. Flow control: none. Parity: none
Log: [Write] 0xC0
Log: [Write] 0x00
Log: [Write] 0x2F
Log: [Write] 0x00
Log: [Write] 0xD1
Log: [Write] 0x01
Log: [Write] 0x7E
Log: [Write] 0xC0
Log: [Read] 0xC0 0x00 0x2F 0x00 0xD1
Log: [Read] 0x02 0x7D 0xC0
Log: [Read] 0xC0 0x00 0x2F 0x00 0xD1 0x01
Log: [Read] 0x7E 0xC0
Log: [Write] 0xC0
Log: [Write] 0x00 0x2F 0x00 0xD1 0x02 0x7D 0xC0
Log: [Read] 0xC0 0x00 0x3F 0x00 0xC1 0x03 0xFC
Log: [Read] 0x11 0xC0
Log: [Write] 0xC0
Log: [Write] 0x00 0x3F 0x00 0xC1 0x04 0x7B 0x11 0xC0
Log: [Write] 0xC0
Log: [Write] 0x00
Log: [Write] 0x3F
Log: [Write] 0x00
Log: [Write] 0xC1
Log: [Write] 0x03
Log: [Write] 0xFC
Log: [Write] 0x11
Log: [Write] 0xC0
Log: [Read] 0xC0 0x00 0x3F 0x00 0xC1 0x04
Log: [Read] 0x7B 0x11 0xC0
Log: [Write] 0xC0
Log: [Write] 0xDB 0xDC 0x3E 0x00 0x02 0x00 0x66 0x01 0x31 0x74 0xC0
Log: [Read] 0xC0 0x08 0x00 0x00 0xF8 0xC0
Log: [Read] 0xC0 0xC8 0xBE 0x00
Log: [Read] 0x7A 0x01 0x66 0x00 0x00 0x00 0x00 0x08 0x59 0x00
Log: [Read] 0x67 0x00 0x18 0x94 0xC0
Log: [Write] 0xC0
Log: [Write] 0x08 0x00 0x00 0xF8 0xC0 0xC0 0xC9 0x8E 0x00 0xA9 0x00 0x60 0x01 0x00 0x00 0x00 0x00 0x00 0x3D 0x1D 0xC0
Log: [Read] 0xC0 0x10 0x00 0x00 0xF0
Log: [Read] 0xC0 0xC0 0xD1 0x6E
Log: [Read] 0x00 0xC1 0x01 0x60 0x08 0x00 0x00 0x00 0x5D 0x10
Log: [Read] 0xC0
Log: [Write] 0xC0
Log: [Write] 0x10 0x00 0x00 0xF0 0xC0 0xC0 0xD2 0x8E 0x00 0xA0 0x00 0x68 0x25 0x00 0x00 0x00 0x01 0x01 0x92 0x75 0xC0
Log: [Read] 0xC0 0x18 0x00 0x00 0xE8 0xC0
Log: [Read] 0xC0 0xDA 0x6E 0x00 0xB8 0x01
Log: [Read] 0x68 0x00 0x00 0x00 0x00 0x9A 0xC3 0xC0
Log: [Write] 0xC0
Log: [Write] 0x18 0x00 0x00 0xE8 0xC0 0xC0 0xDB 0xDD 0xCE 0x01 0x56 0x00 0x88 0x01 0x00 0xB6 0xCB 0x1D 0x86 0x02 0x34 0x01 0x01 0x00 0x40 0x01 0xF0 0x00 0x05 0x00 0x01 0x28 0x00 0x50 0x00 0x00 0x00 0x2A 0x00 0xD2 0x17 0xC0
Log: [Read] 0xC0 0x20 0x00 0x00 0xE0 0xC0
Log: [Read] 0xC0
Log: [Read] 0xE3 0x6E 0x00 0xAF 0x01 0x88 0x00 0x00 0x00
Log: [Read] 0x00 0x3C 0x5E 0xC0
Log: [Write] 0xC0
ble connect status = 0
Log: [Write] 0x20 0x00 0x00 0xE0 0xC0
Log: [Read] 0xC0 0xE4 0xDE 0x01 0x3D 0x02
Log: [Read] 0x10 0x00 0x00 0x00 0x00 0xB6 0xCB 0x1D 0x86 0x02
Log: [Read] 0x34 0x01 0x25 0x7F 0xDA 0x7A 0xEC 0xEA 0x02
Log: [Read] 0x00 0x50 0x00 0x50 0x00 0x00 0x00 0x2A 0x00 0x5B
Log: [Read] 0xE9 0xC0
Log: [Write] 0xC0
Got event id (16)
Log: [Write] 0x28 0x00 0x00 0xD8 0xC0
Connection Status = 1
connection added: {0L: <ble.connection instance at 0xb47cc3a0>}
Log: [Read] 0xC0
Log: [Read] 0xE5 0x6E 0x00 0xAD 0x02 0x11 0x00 0x00 0x00 0x3E 0xEB 0xDA 0xC0
Log: [Write] 0xC0
Log: [Write] 0x30 0x00 0x00 0xD0 0xC0
Got event id (17)
disconnect: 0
disconnect reason = 62
Connection Status = 0

I've tried setting compatibility mode. That makes no difference.

I'm also attaching Frontline sniffs of the interaction.

Any help would be appreciated.

Thanks.

NordicDisconnect.cfa

democapture.pcapng

democapture2.pcapng

democapture3.pcapng

testAtestB.pcapng

testA.pcapng

TestA-2.cfa

TestB-2.cfa

  • 0

    I added a third connection capture. It doesn't show much except that the connection process takes place during the time delay between packets 28 and 29.

  • 0

    I changed the scenario a bit. I pulled the BGM out of the picture, and replaced it with my Ubuntu 14.04 Linux box. On the Linux box I did the following:

    sudo hciconfig hci0 down sudo hciconfig hci0 up sudo hciconfig hci0 leadv

    I then attempt to connect to the Linux box with the nRF51. This connection fails in a similar manner as connecting to the BGM. I then attempted a connection to the Linux box using an iPhone. That connection worked.

    democapture3 records these sessions. Packets 1-20 are for the nRF51 attempt. Subsequent packets are for the iPhone.

  • 0

    Hi Jimvert,

    I noticed that in the connect request from the nRF51 had the master sleep clock accuracy of 0-20ppm. This is pretty strict and maybe hard for the slave to match. The iPhone only has 31-50ppm.

    The connectivity_115k2_with_s130_1.0.0.hex firmware may have the clock accuracy fixed to 20ppm but what you can do for testing is:

    • Test the dongle (running connectivity_115k2_with_s130_1.0.0.hex) with our nRF51 as peer device instead of the BGM or the linux machine. This is just to verify the dongle still work properly.

    • Test with S120/S130 softdevice instead of using the connectivity_115k2_with_s130_1.0.0.hex on the nRF51 dongle. This will require you to let the dongle run as a standalone central (not controlled by PC). You can find central examples in our nRF51 SDK. In the source code you can modify to have more oscillator tolerance ( use NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION when init softdevice with SOFTDEVICE_HANDLER_INIT() )

    • Test with Master Control Panel (Master Emulator firmware) instead of the ble driver on the dongle. You still can make PC application with the Master Emulator instead of the ble driver.

  • 0

    I tested an nRF51 dongle as a central to an nRF51 dongle as a peripheral -- both running connectivity_115k2_with_s130_1.0.0.hex. This scenario works properly.

    You still can make PC application with the Master Emulator instead of the ble driver.

    I'm not running the dongle on a PC. It's running on an embedded controller. I'm looking at the viability of the nRF51 as a Bluetooth solution in this environment. We would ultimately put the nRF51 directly on the PCB but would end up running connectivity_115k2_with_s130_1.0.0.hex on that chip.

    Can you send me a modified version of connectivity_115k2_with_s130_1.0.0.hex to try out?

  • 0

    Hi Jim,

    If that's the case, I would suggest you to go with the test case #2 of testing with S120/S130 first. And then you can test with the ble_connectivity project in the SDK. Then you can use the embedded controller to control the nRF51 board via UART or SPI. You have more flexibility with the serialization solution than with the ble driver.

Related
Terms of service