BLEHci.connection_timeout with connectivity firmware on nRF52840 dongle (pca10059)

[Franz]

Dear community,

I am using the nRF52840 dongle with the connectivity FW and set the max number of connections to 10 in the connectivity firmware (of course the RAM area was incresaed, so that initialisation of the ble stack is successful.

We used the dongle and the code for weeks, without any problems using up to 4 peripheral devices. However, as soon as we use more than that (max number is 8), we often get a disconnect with reason "BLEHci.connection_timeout". This is reproducable and has to do with the number of peripheral devices.

We also observed that the disconnect seems to happen when most of the communication happens in the main python code, so it seems that somehow the dongle cannot handle the data transfer while keeping the connections. However, there is never really "much" data exchanged with more than one device. In the typical scenario, where the problem arises, e.g. 6 devices are constantly notifying values (~16 bytes per second) and the dongle is asked to write ~60 bytes to the devices sequentially(!).

Also, it seems that the python pc-ble-driver execution is "slowing down" a bit with more connections, but that is just a feeling without hard numbers.

Can you give me a hint about how to proceed the debugging? For the BLEHci.connection_timeout. i read about crystal inaccuracies (which is not likely because up to 4 devices work seemlessly) and about communication intervals (which I think the central should figure out for itself, right?). Is there an easy way to explicitely tell the python pc-ble-driver to use speficic (but fixed!) communication intervals for the single devices? Should I even play around with "manually" forcing specific communication intervals?

Thanks!

[Edvin]

Hello,

Just to rule out any misunderstandings, your dongle is running pc-ble-driver, and not anything zephyr/NCS related? The reason I ask is because of the "BLEHci.connection_timeout". The softdevice doesn't reveal any HCI interface, so this is a reason you see on the phone or something?

If this happens when you increase the number of connections, it may simply be that it struggles handling all the connections simultaneously. What is your connection interval in the connections? Is the dongle a central or a peripheral? If it is a peripheral, what is the central in the connection?

Even if you are only writing 16 bytes per second, the softdevice needs to maintain the connections every connection interval. If the connection interval is short (7.5ms) it means that it needs to communicate with the connected device every 7.5ms. This communication takes a couple of ms, even if you are not sending any data. So if you have 3-4 connections you will start to struggle. If you have a connection interval of 15ms, you will probably manage to do about 8-9 connections. Try to set the connection interval to e.g. 50ms. Let me know what the central of the connection is. It may be a bit more tricky if it is e.g. a phone, because it is always the central that decides the connection interval. Try to sniff a connection using e.g. nRF Sniffer, and see what the actual connection interval is, if it is a phone.

BR,
Edvin

[Franz]

Hi Edvin,

yes, the nRF52840 dongle is running "standard" connectivity firmware, where the only change in code was to enable up to 10 connections. 

The dongle is used from a PC that is running python 3.7 (pc-ble-driver-py / pc-ble-driver) and the dongle us used as central. I see this timeouts in python when I connect to more than 4 peripherals, although I cannot tell if it maybe sometimes may work with up to 5 devices.. I can only tell that using up to 4 devices, the code runs well for at least an hour, If I use 6, it is more or less guaranteed that I get the timeout at the passage of the main code, where more data is sent than it is in the 30min before (that part of the python code is part of some testing routines which at some point transfers testing input data to the devices).

I cannot tell the connection interval of the single devices yet - I will try to sniff that with another devkit, I just have to find out how to properly sniff ALL the negotiated intervals because they are most likely different on different connections, right? (Not sure about the algorithm that the dongle uses as a central to negotiate the intervals). 

The periperhals are all identical, using the nRF52832 with SD112. They use a min connection interval of 20ms.

//EDIT: According to the conn_params that are reported in "on_gap_evt_connected" , python shows me a connection interval of 30ms for all devices.

Best regards!

[Edvin]

Franz said:

//EDIT: According to the conn_params that are reported in "on_gap_evt_connected" , python shows me a connection interval of 30ms for all devices.

 It may be that the devices negotiate another connection interval later than the on_gap_evt_connected callback. Make sure that 30ms (or whatever connection interval you decide to use) is between the min and max connection interval of all the peripherals. 

This may not be trivial, since the nRF Sniffer can only follow one connection at the time, but see if you can use the nRF Sniffer to capture a disconnect between the central and the peripheral. 30ms should be sufficient, but perhaps you can try to increase it even more.

Also, if the issue is packet loss leading to the disconnect, perhaps you can try to increase the supervision timeout parameter. I don't know what it is set to in your case, but this decides how long the link will accept missing packets from the connected device before the link is considered lost. If the connection is a supervision timeout, then increasing this parameter may help.

When a device disconnects. Have you checked what happens on the other side of the connection (the peripheral using nrf52832 with SD112?) Do you get a BLE_GAP_EVT_DISCONNECTED event there as well? And what is the disconnect reason? At least check that the device didn't run into an app error that causes the device to reset.

BR,

Edvin