Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Delay data received at long ranges

Hello,

nRFSD5 v16.0, softdevice v.7.0.1, nRF52840

We have an application where we receive data from mobile application whenever it writes to a certain UUID. The data is collected at nRF52 hardware end when BLE_GATTS_EVT_WRITE event is fired.

However, at longer distances, this data is received late, sometime it takes more than 5 seconds, which is understandable as the distance is too much and signal quality is poor and BLE stack sends lots of back and forth data. However, in the same scenario our mobile application received data sent acknowledgment after about 2 seconds. In the device firmware, I'm running a timer, while the mobile application also send time along-with the data.  I calculate the difference between the two and know the time it takes to receive data at device end. 

So my question is, while the nRF52 service gets data after 5 seconds, why mobile application gets an acknowledgment after 2 seconds. Theoretically both events should be fired at same time. Can you please tell me why this is happening?

Parents
  • Hello,

    There may be several reasons for this. Your connection parameters are probably different when you are connected to an nRF52 and a phone. 

    My initial thought is that the packet length may differ between the two connections. If you are sending long packets, it means longer time on air, and a larger risk for noise and faulty CRCs. 

    Another possibility is that you may have different connection intervals on the phone and the nRF. Remember that it is the central that decides the connection interval, so even if you set the preferred connection interval on the peripheral, the central may choose something completely different.

    Is it possible to capture a sniffer trace using the nRF Sniffer? Preferably a sniffer trace of both scenarios, phone and nRF52 as the central. If you can sniff the conection while you have the 5 second delay, perhaps it can reveal why it takes so long.

    BR,

    Edvin

Reply
  • Hello,

    There may be several reasons for this. Your connection parameters are probably different when you are connected to an nRF52 and a phone. 

    My initial thought is that the packet length may differ between the two connections. If you are sending long packets, it means longer time on air, and a larger risk for noise and faulty CRCs. 

    Another possibility is that you may have different connection intervals on the phone and the nRF. Remember that it is the central that decides the connection interval, so even if you set the preferred connection interval on the peripheral, the central may choose something completely different.

    Is it possible to capture a sniffer trace using the nRF Sniffer? Preferably a sniffer trace of both scenarios, phone and nRF52 as the central. If you can sniff the conection while you have the 5 second delay, perhaps it can reveal why it takes so long.

    BR,

    Edvin

Children
No Data
Related