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]

My goal here is to profile the power consumption of a peripheral that sends larger data packets, using MTU size extension available with SDv3. A PC app would have been the easiest central to test this with. I thought that I could get the central to support longer MTUs and DLE simply by updating the connectivity firmware.

Since I posted this question I have realized that this probably wouldn't have worked anyway, as the features require more RAM to be allocated for the softdevice. I assume the precompiled hex files don't have this even if the PC app supported the v3 softdevice.

Anyway, I saw a few posts on this forum where updating the firmware to 1.0.1(?) was recommended, so I thought 1.1.0 should work also. That's why I asked if what I'm trying to do should work.

[Hung Bui]

For your testing purpose you can think of making your own application based on the pc_ble_driver then you can take advantage of the new features in S132v3.0. There is also some python binding example in our github also. Or you can simply use one NRF52 board as the central and test your devices.

Many Android and iOS phone now already support long MTU (usually 158 bytes) you can also use them for testing.

The issue when you want to use S132 v3.0 for the current nRFConnect is that the API are not compatible.

The RAM size is not the problem because it's inside the connectivity firmware which already configrued for S132 v3.0.

[mrono]

Yes, I'll adapt one of the example projects for central role and use the nRF52-DK without the PC app. At this point all I really need the central to do is to allow the peripheral to send long data packets.

I'm making measurements to decide if, for my app, it is better to send one large block of data with a long connection interval or many smaller blocks with a short interval. And also if I should keep the connection alive or disconnect and reconnect every time.

Once I can get some numbers for each case I'll be able to choose the best approach.

[Hung Bui]

@Mrono: please be aware that on link layer, it will still be 27 bytes payload regardless what you have on the L2CAP MTU. So what you save using long MTU is just the header bytes on L2CAP layer. We did some calculation, the improvement of the throughput is only applied when data is more than 230bytes, and it's only about 10-20%