nRF52840 - SDK16 - s140 - Data Rate vs Range

[Nikosant03]

Hi everyone,

I am using a third party nRF52840 module and I have developed my own bluetooth application. I have implemented one characteristic for notifying data from the IMU. I have to notify data with a frequency of 100Hz (close to the 7.5s limit). For testing purposes, I am using the nRF52840 Donggle as central.

I've noticed that the range is proportional to the transmission frequency. For example, @100Hz the range is much less (and there is a disconnection in just a few meters) compare to e.g 50Hz. This is the case? Is it what I have to expect?

Thanks in advance

Nick

[Nikosant03]

Thank you for your effort Einar,

So, let me rephrase in order to confirm that I have understood correctly.

When the sd_ble_gatts_hvx is been called the payload (packet) is placed in sd buffer (ATT table) and remains there until the next connection interval. Re-transmission occurs every connection interval.

When a packet is transmitted, then a slot from the sd buffer is getting free and the BLE_GATTS_EVT_HVN_TX_COMPLETE event is received. In case of unsuccessful transmission, the packet remains in sd buffer and a re-transmission of the same packet will be attempted on the next connection interval (so there is a shift in time). If the buffer is getting full the NRF_ERROR_RESOURCES error returns from sd_ble_gatts_hvx. 

I am correct so far?

I understand that reducing the connection interval will give some time for re-transmission but I cannot understand how buffering up notifications will help. With s140 you can buffer up to 6 packets, right?

Let's say that buffering 6 packets and for any reason the packets do not be transmitted..they will remain in sd buffer and a re-transmission will occur in the next connection interval, isn't it? I know that I miss something.. :)

Lastly, you said that I have to handle packet loss. Is there any example of that?

Nick

[Einar Thorsrud]

Hi Nick,

Nikosant03 said:

I am correct so far?

Yes, perfectly correct so far 

Nikosant03 said:

I understand that reducing the connection interval will give some time for re-transmission but I cannot understand how buffering up notifications will help.

What I means is that if you have a connection interval of 10 ms and a notification interval of 10 ms, you normally get the notification out immediately"(or rather within 10 ms). but if we assume you get one packet loss, then for the next connection interval you will have the packet to be retransmitted, and a new notification also in queue, so that would be two. If the event length is long enough, and you have the packets buffered, and there is no packet loss, then you would get two packets through in this case, and you would be back on track. It might not be possible though, if for instance the packet length is so long that you cannot fit two packets in one event (I do not know enough to day)?

Nikosant03 said:

With s140 you can buffer up to 6 packets, right?

There is no hard limit, though for old SoftDevices you could queue 1, 3 or 6 packets depending on configuration. If the event length is long (compared to the packet length), and you are able to queue more packets during the event length, you can get more packets through.

Nikosant03 said:

Lastly, you said that I have to handle packet loss. Is there any example of that?

The stack handles that automatically. There will be retransmissions until is succeeds or there is a supervision timeout. My point was just that the stack cannot do magic, so the connection parameters and the number of packets /length of packets you try to get through has to work in the real world where (there will always be packet loss, and unless you control the environment like in an RF chamber or alone in the forest, this will be variable and unpredictable)

[Nikosant03]

Thank you Einar!!

Einar Thorsrud said:

and a new notification also in queue

By default the queue size is BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT  1 (ble_gatts.h). Meaning that only one notification can be in queue? Basically I cannot buffer notifications and the NRF_ERROR_RESOURCES will return right?

To buffer the packets (lets say to buffer 2 packets) I have to increase the queue size by calling the sd_ble_cfg_set() with BLE_CONN_CFG_GATTS and ble_gatts_conn_cfg_t.hvn_tx_queue_size?

Einar Thorsrud said:

If the event length is long enough

I can adjust the event length from NRF_SDH_BLE_GAP_EVENT_LENGTH right? Is there any example of buffering notifications just for reference?

Einar Thorsrud said:

It might not be possible though, if for instance the packet length is so long that you cannot fit two packets in one event

The packet legth is 38bytes

Sorry for the bunch of questions but I am relative new to BLE developing and I am trying to put the things i order :)

Thanks

[Einar Thorsrud]

Hi Nick,

Nikosant03 said:

By default the queue size is BLE_GATTS_HVN_TX_QUEUE_SIZE_DEFAULT  1 (ble_gatts.h). Meaning that only one notification can be in queue? Basically I cannot buffer notifications and the NRF_ERROR_RESOURCES will return right?

No, that is just the default value. The queue would be longer if you have configured a longer maximum event length when initializing the SoftDevice. See this post.

Nikosant03 said:

To buffer the packets (lets say to buffer 2 packets) I have to increase the queue size by calling the sd_ble_cfg_set() with BLE_CONN_CFG_GATTS and ble_gatts_conn_cfg_t.hvn_tx_queue_size?

That is not needed, given you configure the SoftDevice properly as suggested above.

Nikosant03 said:

I can adjust the event length from NRF_SDH_BLE_GAP_EVENT_LENGTH right? Is there any example of buffering notifications just for reference?

Yes, and no. You typically use the SoftDevice handler library, so you should configure the NRF_SDH_BLE_* macros properly, and that will configure the SoftDevice for you. So to adjust the event length, you adjust NRF_SDH_BLE_GAP_EVENT_LENGTH.

[Nikosant03]

Thank you for your great support!!