General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Jordy U — Fri, 06 Nov 2020 08:27:14 GMT

Hello Vidar,

Thank you very much for your explanation!

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Vidar Berg — Tue, 03 Nov 2020 08:05:33 GMT

Hello,

The specification allows for longer radio packets as you said, the 27 byte limit is in our stack. The problem with long packets though is that it increases the chance for packet loss. In terms of range it should be better to let the stack split the payload into several 27 packets rather than a few 251 packets.

[quote user="Jordy U"]Will only the lost messages be resend in that case or all of them?[/quote]

The Bluetooth stack handles all re-transmission regardless of the packets size and will never skip a packet. Failing to transmit a packet after x re-transmits will lead to a disconnect (supervision timeout).

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Jordy U — Fri, 30 Oct 2020 13:12:21 GMT

[quote userid="4240" url="~/f/nordic-q-a/47073/general-questions-about-notifications-low-level-ble-packets-and-softdevice-phy-connection-interval-connection-event-length-att-mtu-and-dle/186303#186303"]Yes, this is a bit confusing. The Softdevice support 251 bytes with coded PHY, but the MaxRXTime/MaxTXTime is 2700 uS (=27 bytes with S=8 encoding). [/quote]

Hello Vidar, thank you for the useful information. I have a question about using coded PHY with large packages.

Situation
I want to develop systems that can communicate over a long range (around 500 meters, festival/event environment) with messages of around 250 bytes long. Latency up to 500ms is acceptable. I don't have a development kit yet, but I was thinking about using the nRF5340 PDK and nRF52840 Dongle (for testing)

Question
Why are the MaxRXTime and MaxTXTime set to 2700 uS? Is there a possibility to set it to 16656 uS (251 bytes) or 17040 uS (257 bytes)? And should that be better in this case?

If I split a big message over 10 smaller messages, there's a higher chance that the complete message will not arrive, right? Will only the lost messages be resend in that case or all of them?

Why am I asking this
I see in your answer and vaguely in other sites that this coded PHY and long packages (DPL) are never used together. However, the Bluetooth specification shows that it is possible. See attached spreadsheet for a simple overview of sources, images and calculations. So everything I find online contradicts the specification.

I'm asking you, because I have come to a dead end. You help will be very appreciated.

www.dropbox.com/.../Bluetooth send time.xlsx

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Andy — Mon, 13 May 2019 11:56:55 GMT

Ok I see, makes sense. Thanks!

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Vidar Berg — Mon, 13 May 2019 11:44:01 GMT

[quote user="andresovela"]What is pairs? I thought it might be 7 for the LE 1M PHY, 11 for the LE 2M PHY and 1 for the LE Coded PHY, but using 7 I get 25.08 ms. That plus 7.5 ms doesn't give the final 33.75 ms suggested in the spec.[/quote]

The number should be increased to the nearest 1.25 ms unit.

[quote user="andresovela"]I also wanted to ask what is t_scanReserved.[/quote]

It's the reserved time that the Softdevice needs for each Scan window. Table 1 shows the Softdevice scheduling priorities (link).

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Andy — Fri, 10 May 2019 10:50:18 GMT

Thanks, that was a very interesting read.

I have a couple of questions though:

In this paragraph:

When long Link Layer (LL) Data Channel PDUs are in use, it is recommended to increase the event length of a connection. For example, LL Data Channel PDUs are by default 27 bytes in size. With an event length of 7.5 ms, it is possible to send seven full-sized packet pairs in one connection event. Therefore, when increasing the Link Layer Data Channel PDU size to 251 bytes, the event length should be increased to 33.75 ms. To calculate how much time should be added (in ms), use the following formula: ((size - 27) * 8 * 2 * pairs) / 1000.

What is pairs? I thought it might be 7 for the LE 1M PHY, 11 for the LE 2M PHY and 1 for the LE Coded PHY, but using 7 I get 25.08 ms. That plus 7.5 ms doesn't give the final 33.75 ms suggested in the spec.

I also wanted to ask what is t_scanReserved.

And the final question: it looks like the scanner has a higher priority than the connections. I assume that because of all the talk about dropped packets in order to scan and all that. Where can I see the priorities of the SD?

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Vidar Berg — Fri, 10 May 2019 10:16:38 GMT

Good question. The Softdevice will spend nearly 100% of the time sending the packets. However, the Softdevice scheduler may, in some cases, drop events to allow other tasks to be handled. Suggest that you read the section about the scheduler in the SDS for more details: https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/suggested_intervals_windows_s132.html?cp=3_4_2_0_14_9

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Andy — Fri, 10 May 2019 09:59:04 GMT

Ok. One last question: If I set the both the connection interval and the connection event length to 50 ms, there's no way that the SD can handle other tasks right? For example scanning for other devices.

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Vidar Berg — Fri, 10 May 2019 09:43:39 GMT

It means that you already had allocated enough RAM, and that you had some unused RAM before. Slave latency should not affect memory usage.

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Andy — Fri, 10 May 2019 09:24:19 GMT

I've been playing around with the event length and haven't seen any changes. Or maybe instead of the slave latency it was due to the event length and I already increased the RAM enough so I don't get errors anymore... Who knows.

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Vidar Berg — Fri, 10 May 2019 09:22:15 GMT

You need to allocate more RAM to the Softdevice when you increase the event length (increase the app's RAM base address) which otherwise could have been used by the app.

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Andy — Fri, 10 May 2019 09:20:43 GMT

[quote userid="4240" url="~/f/nordic-q-a/47073/general-questions-about-notifications-low-level-ble-packets-and-softdevice-phy-connection-interval-connection-event-length-att-mtu-and-dle/186336"]I think the practical throughput is going to be significantly lower, unfortunately. [/quote]

Yep, I'm afraid that will be the case.

[quote userid="4240" url="~/f/nordic-q-a/47073/general-questions-about-notifications-low-level-ble-packets-and-softdevice-phy-connection-interval-connection-event-length-att-mtu-and-dle/186336"]The example I provided uses 50 ms connection intervals so event length above 50 ms is just wasted RAM. [/quote]

Why do you say that it is a waste of RAM? How does the connection event length affect the RAM usage? I haven't seen anything like this so far.

The only thing that I have seen affects the RAM usage is the slave latency.

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Vidar Berg — Fri, 10 May 2019 09:16:15 GMT

I was testing with different connection intervals and forgot to change the event length. The example I provided uses 50 ms connection intervals so event length above 50 ms is just wasted RAM.

Are you testing against another Nordic device? The event length may be limited on the other side.

The screenshot is from an Ellisys BT sniffer. Yes, I did get around 40 kbps, but this was at close range ( < 1M). I think the practical throughput is going to be significantly lower, unfortunately.

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Andy — Fri, 10 May 2019 09:06:12 GMT

Also, if I understand correctly, you're getting a throughput of 7.31 kB/s? If that's true then that's around 58 kbps and I guess that's counting L2CAP and ATT headers, so in the end I should be able to expect a practical throughput of ~43 kbps (?).

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Andy — Fri, 10 May 2019 09:01:28 GMT

Hi Vidar,

Thanks for all the answers! Regarding the example you attached:

I see that the peripheral is configured with min/max connection interval = 50 ms, and the GAP event length is set to 500 ms (400 * 1.25 ms units). In the central, however, the GAP event length is set to 62.5 ms (50 * 1.25 ms units). How does this affect the connection?

Btw, unfortunately I only have one DK so I can't really test this here. Someone else is doing the testing with another device and I'm trying to adjust the connection parameters to get more throughput.

And what program is that in the screenshot?

RE: General questions about notifications, low level BLE packets and SoftDevice (PHY, connection interval, connection event length, ATT MTU and DLE)

Vidar Berg — Fri, 10 May 2019 08:11:14 GMT

Hi Andy,

[quote user=""]First thing: I know that it is possible to send up to 6 notifications in a single connection interval. What if I increase the connection interval and the connection event length? Would it be possible to send more than 6? Or what is the purpose of increasing the connection event length?[/quote]

Yes, you can send more than 6 packets per connection event. If you set event length == connection interval, you should be able to fill the time between connection events sending/receiving notification packets.

[quote user=""]I'm guessing it is also possible that the SD sometimes cannot send all 6 notifications in a single connection interval (assume that 6 notifications were already queued using sd_ble_gatts_hvx), depending on the connection parameters. Is this true (assuming a good quality link with no packet losses)? Or is it always possible to send 6? What if you set up something like connection interval of 7.5 ms, with maximum data length and ATT MTU? What if you set up the Coded PHY?[/quote]

There is not enough time to send 6 packets with coded PHY at 7.5 ms intervals as the transmission of each packet requires longer time compared to 1M PHY. I guess that you may be able to send 2 at this interval.

[quote user=""]Assuming that the link quality is bad: If a notification can't be sent due to interference, will the SD try to send the same notification 6 times within the same connection interval?[/quote]

No, the re-transmits will be attempted on the following connection event. So the throughput will be heavily impacted by the link quality, especially if you're using long connection intervals.

[quote user=""]Regarding the Coded PHY: I've read that when you use the Coded PHY, the maximum data length possible is 27 in order to avoid interference. However, it still looks like the nrf_ble_gatt module is accepting the max data length of 251 even when the Coded PHY has already been set up. Does the SoftDevice use a data length of 27 internally anyway?[/quote]

Yes, this is a bit confusing. The Softdevice support 251 bytes with coded PHY, but the MaxRXTime/MaxTXTime is 2700 uS (=27 bytes with S=8 encoding).

[quote user=""]I know that when the ATT MTU is larger than the supported data length, the data will be broken down in multiple packets. Does this still give better throughput or is it better to always keep the ATT MTU smaller than the data length? I'm not exactly sure whether having ATT MTU > DL introduces more overhead or not.[/quote]

Larger MTU gives a slightly smaller overhead due to packet encapsulation. The SDS shows the difference in terms of throughput ( under ideal conditions): https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/ble_data_throughput/ble_data_throughput.html?cp=3_4_1_0_16. The data will still be split into smaller link layer packets.

[quote user=""]What happens if the connection event length is set up to be longer than the connection interval? I ask this because the event length must be set up during SD initialization and the connection interval is negotiable at runtime. It looks like the SoftDevice is smart enough to handle this but I just want to be sure and ask this.[/quote]

The Softdevice is smart enough to handle this:)

[quote user=""]I'm asking all these questions because I'm trying to get as much throughput as possible using the Coded PHY, but even following all the threads I could find on this I couldn't manage to achieve a high enough throughput. I need to get around 24 Kbps which is supposedly achievable, but I'm having trouble with that. Any input on that will also be deeply appreciated![/quote]

I think 24kbps should be achievable, but only if the link quality is good. I have modified the ble_app_uart and ble_app_uart_c example in SDK 15.2.0 to test this, see attached zip below. Can you try this example and see what you get?

devzone.nordicsemi.com/.../nRF5_5F00_SDK_5F00_15.2.0_5F00_mod.zip

Test with 400 ms interval