BLE data relay latency issues

[jonas.woerner]

Hello,

I am in the process of writing my bachelors thesis about using BLE to relay data over multiple hops.

In my test setup, I have 5 nrf52840 that connect to each other and form a linear "network". I can then send data to the first relay and it will get relayed through all the nRFs to the last one.

The problem is, Im currently trying to evaluate the latency of this system and hit a roadblock. I cannot figure out why the latency behaves how it does:

sometimes I get low latency results of about 100ms, and sometimes I get very high results of >1s, this is all with the exact same setup, sometimes even without disconnecting between the tests.

the strange thing is that the lows and highs are not evenly distributed, but it seems like its low latency for a while, then gradually gets better or worse and then repeats (although its really hard to say how it varies exactly, it sometimes gets worse very sudden too.)

I tried this with various connection parameters but I always observed the same behaviour. It could also be a bug in my software, but I dont think so / dont know.

the payload im testing with is 1.5Kb in size, and Im feeding the data from an android phone into the first relay.

I would greatly appreciate it if someone could just share thoughts on this, as Im out of ideas on what to try next.

thanks,

Jonas

[Einar Thorsrud]

Hi Jonas,

Can you say more about how you transfer the data?

• Is it as notifications or another method?
• What is the connection interval
• What is the event length?
• How long packets do you use?
• Are more/many packets typically sent per connection event?

Also do you have any siffer trace of this, both the good case (where y0ou have low latency) and the bad case where you have high latency?

Without knowing more, my gut feeling is that you are using fairly long connection events and event lengths, and send multiple packet per connection event. Is that so? If so, a packet loss could explain what you are seeing, as an event would end in that case, and the retransmission will happen in the next connection event.

Einar 

[jonas.woerner]

the data is sent using write without response.

Tested connection intervals range from 7.5ms up to 400ms, all with the same relative results, the absolute delay is smaller on the smaller intervals.

I tried with multiple event lengths too, but cant seem to see any difference, is it correct to set it using

CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT

MTU is set to 1024 at the moment, but I also tried differernt values with similiar results.

I already did some sniffing and have found out that there indeed is packet loss, I didnt know that a packet loss causes the event to end though, that could go in the right direction. Its hard for me to catch the "long" packets, as the sniffer needs to be setup for a particular device prior to connecting, but I only know which device causes the latency after connecting. I will have to try with multiple sniffers setup beforehand, I will update this with a sniffer log as soon as possible.

In the meanwhile, here are some pictures of the latency, a rising edge means that the first packet of my test payload has been received, a falling edge means that the payload is complete. The first image shows a case where it behaves more or less like expected, the second image shows a too high latency. this is done with 90ms connection interval.

[jonas.woerner]

and by the way, if the problem indeed would be packet loss, my guess would be its because I have multiple BLE devices in close proximity, all transmitting simultaneously at full power. How would I try to solve this? is there even anything that could be done to solve this?

[jonas.woerner]

latencytest_5relays.zip

In the attached ZIP file you will find 4 different wireshark captures and a pulseview capture.

the wireshark logs show the connections between all the relays and the pulseview log shows the latency / propagation delay of each relay (rising edge = start receiving test payload, falling edge = test payload complete)

the wireshark logs and the pulsseview trace show the same test, except that the first time the payload was sent it was not logged with pulseview. from the second time on, pulseview and wireshark are in sync.

If you look for packet no. 10436 in relay3_4 and packet 11460 in relay2_3 (which should be payload no #62 if I didnt miscount) I think I can see exactly what you thought has happened, the relay2_3 transmission was fast according to pulseview and I cannot see any retransmissions. The relay3_4 transmission however was slow and I can see multiple retransmissions. It would be very much appreciated if you could verify my findings though, as Im not really experienced with BLE sniffing.

If all the above is correct, then I think that indeed the packet loss is the cause of my latency. This would totally make sense now that I think more about it, as I observed the latency get worse and worse over time and then get better and better again, which i now would explain as the connection intervals drifting towards until spontaneous synchronisation happens and latency is at its worst, then gradually gets better. Very Interesting!

One question remains though, Is there a way to optimize this behaviour and reduce the amount of packet loss in that situation?

kind regards,

Jonas

[Einar Thorsrud]

Hi Jonas,

You can never avoid all packet loss, and particularily not in a congested RF environment. Bluetooth LE chagne channel every connection event though, so unless you have a very high number of devices that send a lot of data I would not expect that to be the main problem. Also, with your connection interval being less than 100 ms I do not see why loosing a few packets would suddenly lead to a 1 second latency. Perhaps there is another issue in your setup, or with how you measure the latency?