This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF Connect for PC v1.0, updating connectivity firmware

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?

Parents
  • 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.

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

Reply
  • 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.

Children
No Data
Related