nRF Connect for PC v1.0, updating connectivity firmware

[mrono]

Hi. I'm using NRF Connect v1.0 on a Windows 10 PC, together with an nRF52-DK (PCA10040). It works nicely with the connectivity firmware 1.0.0 that the PC app offers to flash to the DK.

If I update the firmware of the DK with either of the v1.1.0 precompiled hex files from the pc_ble_driver -project, NRF Connect no longer communicates with the DK.

Using the sd_api_v3 hex file, I get a flood of internal errors as soon as I select the COM port from the NRF Connect app:

Enabling BLE failed. (NRF_ERROR_INTERNAL)

Error occured when enabling SoftDevice. Errorcode: NRF_ERROR_INTERNAL (0x3)

With the sd_api_v2 hex file, I get an NRF_ERROR_TIMEOUT instead.

Is this even supposed to work? Or am I doing something wrong?

[mrono]

Thanks for the warning. My intention is to implement DLE as well so that I can have a single packet over the air. I saw that there is an example for it in the latest SDK, though I haven't yet checked in detail how much work it would be to add that to my project.

The goal is not high data throughput, but to get the ~100-150 bytes sent quickly and go back to sleep. Then using slave latency the next wakeup could be up to 16 seconds later. This would keep the connection alive and allow the slave to sleep most of the time.

The other alternative to all this is to have a short interval, many short packets then disconnect and reconnect every 1-16 seconds.

My intention is to implement both of these scenarios and then decide which suits my product best.

[Hung Bui]

If the requirement is only to send 100-150 bytes as fast as possible I think slave latency + short connection interval would fits you best. Of course long MTU would also help saving overhead bytes.

Using DLE to have single packet over the air can improve through put, but if you have interference the whole packet need to be resent and it then will cost you the transmission of the whole packet, not just the chunk that got issue as in normal packet.

[mrono]

I'm definitely going to use slave latency, but my reasoning for trying to use the long MTU and DLE features is to make sure I'd get the 100-150 bytes transmitted during one connection interval. That way the battery powered peripheral would only need to awaken once to send its data. Then using slave latency I can make the unit sleep for up to 16 seconds which is what I really want. I know I could get several short packets sent during one interval, but I'm not sure if I could get all of the data transmitted that way.

The other option is to use the default short packets, in which case the unit would need to wake up at least twice to send the data, maybe more depending on number of packets per connection interval. I could choose a shortish interval that would still allow the unit to sleep for the maximum 16 seconds without hitting the max slave latency limit.

[Hung Bui]

I understand. You can try to use long MTU and DLE. Be aware that many Android phones now doesn't support DLE yet. I assume you will have an option in case DLE is not supported.

[mrono]

DLE can be used on one connection and not on another, right? That is the impression I got when reading the GATT module sources.

My final product will consist of both the central and the peripheral, permanently bonded together. So lack of support for DLE is not an issue here. But the central should also be able to act as a peripheral to a phone for occasional configuration changes.