nRF52840 - SDK16 - s140 - Data Rate vs Range

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Nikosant03 — Tue, 15 Dec 2020 08:53:43 GMT

Thank you for your great support!!

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Einar Thorsrud — Mon, 14 Dec 2020 14:02:50 GMT

Hi Nick,

[quote user="Nikosant03"]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?[/quote]

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.

[quote user="Nikosant03"]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?[/quote]

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

[quote user="Nikosant03"]I can adjust the event length from NRF_SDH_BLE_GAP_EVENT_LENGTH right? Is there any example of buffering notifications just for reference?[/quote]

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.

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Nikosant03 — Mon, 14 Dec 2020 13:47:42 GMT

Thank you Einar!!

[quote userid="7377" url="~/f/nordic-q-a/69336/nrf52840---sdk16---s140---data-rate-vs-range/284760#284760"]and a new notification also in queue[/quote]

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?

[quote userid="7377" url="~/f/nordic-q-a/69336/nrf52840---sdk16---s140---data-rate-vs-range/284760#284760"]If the event length is long enough[/quote]

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

[quote userid="7377" url="~/f/nordic-q-a/69336/nrf52840---sdk16---s140---data-rate-vs-range/284760#284760"]It might not be possible though, if for instance the packet length is so long that you cannot fit two packets in one event[/quote]

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

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Einar Thorsrud — Mon, 14 Dec 2020 11:41:12 GMT

Hi Nick,

[quote user="Nikosant03"]I am correct so far?[/quote]

Yes, perfectly correct so far 🙂

[quote user="Nikosant03"]I understand that reducing the connection interval will give some time for re-transmission but I cannot understand how buffering up notifications will help.[/quote]

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)?

[quote user="Nikosant03"]With s140 you can buffer up to 6 packets, right?[/quote]

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.

[quote user="Nikosant03"]Lastly, you said that I have to handle packet loss. Is there any example of that?[/quote]

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)

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Nikosant03 — Mon, 14 Dec 2020 10:43:18 GMT

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

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Einar Thorsrud — Mon, 14 Dec 2020 08:01:36 GMT

Hi,

[quote user="Nikosant03"]You mean to send more than one packet in the same connection interval? [/quote]

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.

[quote user="Nikosant03"]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.[/quote]

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.

[quote user="Nikosant03"]Given that I need to notify every 10ms what should be the connection parameters?[/quote]

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.).

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Nikosant03 — Sun, 13 Dec 2020 09:04:50 GMT

Thank you for your responce Einar,

[quote userid="7377" url="~/f/nordic-q-a/69336/nrf52840---sdk16---s140---data-rate-vs-range/284441#284441"]then there will be less time for retransmissions[/quote]

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?

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Einar Thorsrud — Fri, 11 Dec 2020 07:40:04 GMT

Hi,

[quote user="Nikosant03"]So, how is related the data rate with the range?[/quote]

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.

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Nikosant03 — Thu, 10 Dec 2020 20:27:15 GMT

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 🙂

RE: nRF52840 - SDK16 - s140 - Data Rate vs Range

Einar Thorsrud — Thu, 10 Dec 2020 12:55:36 GMT

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