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]

Hi,

Sorry for the late response, I have been traveling for a while.

Even though you specify the data length as 251 bytes when you configure the Softdevice, the Softdevice will overrule this and reduce the data length to a value that allows a TX-RX pair to fit into a connection event. To increase the throughput you should use longer connection intervals to avoid the packets being fragmented.

 

[Mathias]

Hi Martin,

No problem, I hope you enjoyed your holidays 

Okay, so I now tried the application with connection interval of 50 ms. I changed the application as well so that it just sends 100 packets of full payload, one at a time (so only when the previous packet is ACK'ed and TX complete event is given, a new packet is send). I indeed see a lot of radio event times of ~ 34 ms.

However, I also still see some packets taking more than one radio event. I wonder if this is normal (due to coded PHY, etc.) or if I still do something wrong? One or two times would be just maybe some interference or other stuff going on. But its still a lot more than that, and also consistent after measuring a few times.

I sniffed the traffic via a logic analyzer, showing 2 channels. One channel who captures the radio and one channel who captures the sending and TX complete of each packet (or thus the round trip time). You can find a sniffer trace for one measurement of 100 packets sent, attached to this message. There, it is clearly shown that still too much packets take more than one radio event.

Thanks in advance.

Long range 50 ms 100 packets.logicdata

EDIT 1:

Actually, it also seems strange to me that it takes around ~34 ms if only on radio event is needed. Because I would expect it to be around ~ 18 ms, which is Full TX (244 bytes payload) + IFS + Empty RX + IFS (= 18060 µs, see above). Why does the radio still take around the time for a full TX and RX while the real communication flow only needs a full TX?

[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?