Theoretical evaluation of Long Range experiments

[Mathias]

Hi,

I'm doing some experimental evaluation of BLE Long Range. I use the ble_app_att_mtu_throughput example with parameters:

• ATT MTU: 247 bytes
• Data length extension: 251 bytes
• Connection interval: 20 ms
• Connection length extension: on
• Preferred PHY: Coded

Using these parameters, I get an experimental throughput of 40.08 kbps. I also want to theoretically validate this, in the same way I did for 1Mbps and 2 Mbps PHY (https://devzone.nordicsemi.com/f/nordic-q-a/29269/theoretical-throughput-doesn-t-match-experiments-done-via-ble_app_att_mtu_throughput-example). But now I need to use the packet format of a Coded Phy packet, given below:

Using this information, I calculate:

• Tx-Time (full packet) = 80 µs + 256 µs + 16 µs + 24 µs + 257 * 8 * 8 µs + 24 * 8 µs + 3 * 8 µs = 17040 µs
• Rx-Time (empty packet) = 80 µs + 256 µs + 16 µs + 24 µs + 2 * 8 * 8 µs + 24 * 8 µs + 3 * 8 µs = 720 µs
• IFS = 150 µs

=> Theoretical send-time = 17040 µs + 720 µs + 150 µs * 2 = 18060 µs

But through previous questions (https://devzone.nordicsemi.com/f/nordic-q-a/29269/theoretical-throughput-doesn-t-match-experiments-done-via-ble_app_att_mtu_throughput-example and https://devzone.nordicsemi.com/f/nordic-q-a/28682/ble_app_att_mtu_throughput-throughput-calculation-packets-per-interval-data-length-extension) I know that the SoftDevice will first check if a full TX and RX can still be done before a next real packet exchange is scheduled. The timing for this is Tx-time (full packet) + Rx-time (full packet) + 150 µs * 2 = 2* 17040 µs + 300 µs = 34380 µs. However, this is already more than the full 20 ms connection interval... So it doesn't fit in there even once...

So in short, I'm a bit at a loss how to calculate the theoretical throughput for Long Range BLE...

Any help would be greatly appreciated. Thank you in advance.

Kind regards,

Mathias

[MartinBL]

Hi,

I'm not sure if I understand your reasoning at the end. Shouldn't it be

Tx-time + Rx-time + (IFS * 2) 

and not 

(Tx-time + Rx-time + IFS) * 2 

?

[Mathias]

You mean "Tx-time (full packet) + Rx-time (full packet) + 150 µs * 2 = 2* 17040 µs + 300 µs = 34380 µs. "?  I calculated that the time for a full packet is 17040 µs. Because of the Softdevice checking if a full Tx and Rx can still be done before the real transmission is scheduled, the time to check is 2 * a full packet + 2 * IFS = 2 * 17040 µs + 2 * 150 µs. Or at least, that's how I understand it right now.

[MartinBL]

What kind of software do you use to open the .logdata file? It looks like a Saleae logic trace file, but I'm unable to open it with my Saleae software. It sounds like you are toggling GPIOs on certain events in software and measuring them with a logic analyzer? It would be helpful if we could see an actual sniffer trace of BLE packets. Do you have equipment for that?

 

[Mathias]

Hmm, that's strange, I can open it with my Salea software. I downloaded it here https://www.saleae.com/downloads/. I am indeed toggling GPIOs on certain events. I'm toggling the radio using the notification handler and I'm toggling sending of packet and receiving of ACK, this right before hvx method and right after receiving TX complete for the packet respectively. I only send one packet a time, each time triggered after receiving a TX complete for the previous packet.

Unfortunately, I don't have any equipment to sniff LR BLE packets... Is there any free or not so expensive sniffer possibility available?

EDIT

So the second GPIO pin actually maps the round trip time for each packet.

[MartinBL]

Hi,

I have discussed a bit back and forth with the Softdevice team, and it turns out that our Coded phy solution doesn't actually support long packets at all. In other words, it is packets with maximum 27 bytes L2CAP + 2 bytes LL. So, we don’t send or receive long packets which explains why you see packets distributed over more than one connection event. It is strange though, that you are seeing 34 ms events. Maybe it is a result of using radio notifications.

Anyway, to get any further in this, we will need your code so that we can use a sniffer and see what actually goes on in the air. 

 

[Mathias]

Hi,

You can find my code here: https://we.tl/MkCEBqs9Oi. The folder needs to placed in SDK15 folder/examples to be able to run.

It's a variant of the max throughput example available in the SDK, in the central & peripheral folder. It's also with two boards. One board acts as tester and the other as dummy. So when button 3 is pressed on the tester it will starts scanning and when button 4 is pressed on the dummy it will start advertising. But I don't use any console input anymore, everything is preprogrammed, so when the two boards establish a connection, they just start communicating.

After connection is established, the tester sends one packet of 244 payload and when it receives a TX complete for that one, it logs the throughput, round trip time, RSSI and channel on which the communication was done. It also sends the same packet again. This processing is repeated infinitely. When the connection goes out and comes back, the application takes care of this and the communication is reset. Communication while advertising/scanning and in connection is both using the LR PHY.

The other used parameters are:

• Connection interval: 40 ms
• MTU: 247 bytes
• Data Length Extension: 251 bytes
• Connection length extension: ON

Thanks,

Mathias

[MartinBL]

Hi,

My apologies for the slow response again. It is holiday season in Norway and those left of the Softdevice team (as well as the long range BLE sniffer equipment) are tied up in preparation for some upcoming releases. Your case is not forgotten, but unfortunately I'm not sure when I'll have time to work more on it either. 

[Mathias]

Hi Martin,

I understand, no problem. It's already interesting to know that long packets are not supported with LR, so we can further research with that new knowledge in mind. When you guys do find something else, we would be very glad to know.

Thanks.

Mathias

[Mathias]

Hi Martin,

It's been a while since we've been in touch on this question. We have been experimenting with Long Range a bit more but we haven't been able to solve the weird behavior. Even with using legacy 20 bytes payload packets, we see that when sending multiple packets at once, this takes multiple connection events most of the time, regardless of turning on connection event length extension and providing a sufficiently high enough connection interval.

However, we use nRF52840 DK's with a v0.9.2 IC, while the newest 2 SD's 140 v6 and v6.1 aren't compatible with this IC according to the compatibility matrices: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52%2Fdita%2Fnrf52%2Fnrf52_comp_matrix.html  and http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52%2Fdita%2Fnrf52%2Fcompatibility_matrix%2FnRF52840_ic_rev_sdk_sd_comp_matrix.html . Could this be an issue causing the weird behavior?

Kind regards,

Mathias

[MartinBL]

Hi,

I wonder if it could be due to packet loss? Maybe certain packets need to be retransmitted and eventually get spread across multiple connection events. I'm not sure how this would look on a logic trace using radio notifications and toggling GPIOs, but since you write "most of the time" it sounds like there is an element of uncertainty involved. If it was caused by a limitation in the BLE Spec, the Softdeivce, or in simple physics one would expect consistent behavior right?

There are several errata related to Coded PHY and packet loss: 
[110] RADIO: Packet loss or degraded sensitivity
[164] RADIO: Low selectivity in long range mode
[191] RADIO: High packet error rate in BLE Long Range mode

All of those are fixed in the latest silicon or in the latest Softdevice. 

PS: the Link Layer payload size is still limited to 27 bytes for connections on LE Coded PHY using S140 v6.1.0. The reasoning is that longer packets will cause interference issues on long range.

[Mathias]

Hi Martin,

I just found out that I never replied to your comment! We ordered new silicons at the time and it was indeed a problem with old hardware. So I'll verify your answer :) thanks again!