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?

[Hung Bui]

Hi Mrono,

Could you tell why you want to update the hex ?

The current version of nRFConnect is not compatible with v3 hex file. On v2, we removed support for S132. You may want to wait for the next nRFConnect release.

[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.