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

[Einar Thorsrud]

Hi Nick,

In general, you could say that you would get longer range with lower data rate, if for instance using BLE long range (Coded PHY). In that case you would use more energy per data bit in order to increase range, using several techniques. That is not the case here, though.

In your description you do not mention anything about PHY, so I assume you always use the same PHY. In that case, the only relevant factor is that the less data you send, the more time there is to send retransmissions. So essentially you can loose more packets before noticing it on the application layer, but that is all.

Einar

[Nikosant03]

Hi Einar and thank you for your answer!!

I am not using coded PHY. My problem is that the higher the transmission frequency the less the range I achieve..  For example when notifying with a frequency of 100Hz (min and max connection interval are set to 10ms) I achieve around 4m range (before disconnection). When I downgrade the data rate, lets say to 10Hz  (min and max connection interval are set to 10ms) then the range is much much better (around 10m before disconnection). So, how is related the data rate with the range?

P.S: When I say "notifying with a frequency of 100Hz" I mean calling sd_ble_gatts_hvx every 10ms

[Einar Thorsrud]

Hi,

Nikosant03 said:

So, how is related the data rate with the range?

Physically, the range is the same regardless of notification frequency. The only difference is that if you notify with a higher frequency using the same connection parameters, then there will be less time for retransmissions (fewer attempts to get the packet through) before it causes problems. Under challenging RF conditions this could result make it seem like the range is lower.

You have both a connection interval of 10 ms and send notifications every 10 ms. In general I would expect you would get a corresponding improvement if reduce the connection interval to the half, but you already use a very short interval. If that had been possible, it would have given the same effect as reducing notification frequency. The key here is that with your configuration, you do not have any time for retransmissions. As your connection interval is the same as your notification frequency, any retransmission will cause a delay of the subsequent notifications, etc (retransmissions always happen on the next connection event). So your set of parameter cannot really work properly in a real world as it depends on never getting packet loss.

[Nikosant03]

Thank you for your responce Einar,

Einar Thorsrud said:

then there will be less time for retransmissions

You mean to send more than one packet in the same connection interval? or in case that the packet is getting loss there is no time for retransmission? I want to send just one packet per conneciton interval.

Given that I need to notify every 10ms what should be the connection parameters?

[Einar Thorsrud]

Hi,

Nikosant03 said:

You mean to send more than one packet in the same connection interval?

No, not in this case. Even if you have time to send more packets per connection event, retransmissions always occur on the next connection event. 

Nikosant03 said:

or in case that the packet is getting loss there is no time for retransmission? I want to send just one packet per conneciton interval.

Yes, that is the problem with your setup. As retransmissions occur on the next connection event, everything gets shifted. You must give some room for retransmissions.

Nikosant03 said:

Given that I need to notify every 10ms what should be the connection parameters?

For this to work satisfactory in the real world you have to either use a shorter connection interval (not that much to go on, as 7.5 ms is the lowest possible), or buffer up notifications and send multiple per connection event after a retransmission to get back on track. This is up to you and which works best in your case, but you must design your system to handle packet loss as that will always happen from time to time, sometimes a lot, some times almost nothing (depending on factors such as distance, interference etc.).

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