nRF Connect for PC v1.0, updating connectivity firmware

RE: nRF Connect for PC v1.0, updating connectivity firmware

Hung Bui — Thu, 05 Jan 2017 15:52:55 GMT

You set a single maximum data length to the softdevice, there is no option to set different maximum data length for each connection. But if you peer device doesn't support longer data length then the maximum the peer support will be used.

If you have control over both side of the connection then I think it's fine.

RE: nRF Connect for PC v1.0, updating connectivity firmware

mrono — Thu, 05 Jan 2017 14:05:36 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

Hung Bui — Thu, 05 Jan 2017 13:35:09 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

mrono — Thu, 05 Jan 2017 10:04:39 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

Hung Bui — Wed, 04 Jan 2017 15:31:11 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

mrono — Wed, 04 Jan 2017 12:35:24 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

Hung Bui — Wed, 04 Jan 2017 11:37:29 GMT

@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%

RE: nRF Connect for PC v1.0, updating connectivity firmware

mrono — Wed, 04 Jan 2017 11:18:33 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

Hung Bui — Wed, 04 Jan 2017 10:06:33 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

mrono — Wed, 04 Jan 2017 06:49:00 GMT

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.

RE: nRF Connect for PC v1.0, updating connectivity firmware

Hung Bui — Tue, 03 Jan 2017 14:44:08 GMT

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.