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

[jonas.woerner]

according to the wireshark logs, there are so many lost packets, that it sums up to about a second sometimes, but Im not sure on this as lowering the transmit power and even separating the devices into different rooms didnt really change anything. Its extremely frustrating. Sometimes I can measure a hundred times without any problem and then suddenly the delay goes way up. I dont understand it.

[Einar Thorsrud]

Are you in an appartment-block or similar where you have neighbours heavily using a microwave oven? That creates a lot of noise in the entier 2.4 GHz ISM band. To check if this really is the case, perhaps you could try to repeate the experiment somewhere with less 2.4 GHz traffic?

[jonas.woerner]

I have done some furhter research, and I now know that the big delay comes from the delay between calling bt_gatt_write_without_response_cb and the successful transmission of the data.

[00:05:30.102,783] <inf> bluart: write_blocking: transmitting 1019 bytes
[00:05:30.103,118] <inf> bluart: write_blocking: transmitting 5 bytes
[00:05:30.103,302] <inf> bluart: write_blocking: transmitting 556 bytes
[00:05:30.425,659] <inf> bluart: complete_test: TX complete
[00:05:30.426,177] <inf> bluart: complete_test: TX complete
[00:05:30.646,484] <inf> bluart: complete_test: TX complete

as you can see in this log, there is a total of more than 500ms between calling the write function, and the execution of the TX complete callback. this is still with 90ms connection interval, and I changed the code so that every relay waits for the full payload and only relays it once its fully received, to limit the concurrent on-air traffic.

the question now is, why is there such a long time between calling write and getting the complete callback? to me this still seems like an issue with the transmitting and would confirm my earlier findings that it is due to interference. Do you also think so? Or do you know of any other causes that would cause a delay there?

[jonas.woerner]

I managed to log another long delay and capture it with wireshark at the same time:

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=90

CONFIG_BT_PERIPHERAL_PREF_MAX_INT=90 
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=500
CONFIG_BT_L2CAP_TX_MTU=1024
#mtu+4
CONFIG_BT_BUF_ACL_RX_SIZE=1028

can you spot anything abnormal? to me this still looks like Interference... but again, Im not a pro at this.

also, why are there so many small fragments? I put 1Kb of data into the Zephyr write function and have set the data length max to 251, so why are there such small packets?

[Einar Thorsrud]

Hi,

I see that there is a lot of retransmissions. The most typical reason is noise or intererence, or low signal strength. But it could also be caused by other factors, like inaccurate or low frequency clocks on the devices (or misconfiguration, where you indicate that the clocks are more accurate than they are, so that the listening time (window widening) is not long enough. 

Regardign fragmentation I see you send short (normal) packets with a 27 byte payload. To send longer packets you need to use data length extension. You can refer to exersize 2 from lesson 3 in the Bluetooth Low Energy Fundamentals for seeing how to do that (essentailly calling bt_conn_le_data_len_update()).