how can i get the number BLE TX re transmissions

[ziv123]

hello Nordic

i am working with nrf52832 and nrf52840 socs, with ncs v2.1.0

i would like to know how many of the BLE packets i am sending has to be resent (and if it is possible to know the reason of resent, in case there is another reason beside packet missed some bytes/bits on the OTA way, that would be great as well ) 

any idea how can i get that info ?

also another question, if i move (with BLE 4.2 and above) to extended length packets, to increase throughput, should there be more resent packets since the risk of loosing data in a larger packet is greater ?

hope to read you soon

best regards

Ziv

[Sigurd]

Hi,

You can get this info as an QoS Connection Event Report.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/nrfxlib/softdevice_controller/doc/api.html#c.sdc_hci_subevent_vs_qos_conn_event_report_t

This sample uses it to count crc mismatches:

https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/llpm/src/main.c#L312

[ziv123]

hi Sigurd

Sigurd said:

You can get this info as an QoS Connection Event Report.

i looked at the link you added and i have some questions, 

1. if i want the count of re-transmission i actually need to sum the count of naks, crc fails and rx timeouts ? is there a better way to get how many BLE packets i sent more then once ? 

2. when referring to event counter, does it counts number of connection event with in an established connection ? and does the above counts are counted within a connection event or throughout all the time the 2 devices are connected ? 

one clarification, i m tx'ing a lot of data so in one connection session i will probably have many BLE connection events  

3. if i can get the number of connection events, is it possible for me from one side (peripheral) to dictates / ask for a longer connection event in order to have less connection intervals and so more throughput ?

4. at some point i will move to BLE 4.2 or above on the non Nordic central and then i will be able to use extended BLE packet length, sending bigger packets, might result in more packets needed to be resend cause bigger packets may have greater risk of missing some data on transmission ?

hope to read you soon

best regards

Ziv

[ziv123]

Hi, 

thanks, for the patient and help :) few more questions  

Sigurd said:

Yes, you can enable/disable this reporting as needed.

1. is there some example or place to look for how to enable it after a connection was establish and disable before a connection is terminated ?

2. i got values when analysing my data transfer connection via different Rssi values while Node is also scanning for another device that is in it's white list. i am trying to understand what can i understand by the type of fails i get. 

when having more then one device in the Node white list with rssi ~40 : i get around 8300 timeouts and ~330 naks but only ~12 crc fails. total connection events count ~11330

when i have one device in the white list with same rssi, i get around 200 timeouts, ~350 naks and ~8crc. total connection events count ~ 5660

with more then one device in Node white list but with rssi ~70 : ~8800 timeouts, ~560 naks (in compare to ~330), ~200 crc (in compare to ~12). total ~11820 

i guess crc fail is caused by some bit miss but then what may be the reason to receive naks ?

also what can i learn on the connection if i get so many timeouts on one state and much less on another state (rssi on both tests was the same), and what is the different causes for timeouts that explains the different values in comparison to the other two reasons ? 

in all cases total data size transmitted is the same.so also when trying to calculate how many re transmission and how many total connection events it seems that there is no "gold" number of connection events to transfer a known size of data it varies a lot from case to case. is there something to learn from looking on how many re  transmissions and total connection events count ?

hope to read you soon

best regards

Ziv

[Sigurd]

Hi,

ziv123 said:

1. is there some example or place to look for how to enable it after a connection was establish and disable before a connection is terminated ?

Just call the enable/disable function in the connected/disconnected callback you get when a device connects/disconnects.

ziv123 said:

2. i got values when analysing my data transfer connection via different Rssi values while Node is also scanning for another device that is in it's white list. i am trying to understand what can i understand by the type of fails i get. 

when having more then one device in the Node white list with rssi ~40 : i get around 8300 timeouts and ~330 naks but only ~12 crc fails. total connection events count ~11330

when i have one device in the white list with same rssi, i get around 200 timeouts, ~350 naks and ~8crc. total connection events count ~ 5660

with more then one device in Node white list but with rssi ~70 : ~8800 timeouts, ~560 naks (in compare to ~330), ~200 crc (in compare to ~12). total ~11820 

i guess crc fail is caused by some bit miss but then what may be the reason to receive naks ?

also what can i learn on the connection if i get so many timeouts on one state and much less on another state (rssi on both tests was the same), and what is the different causes for timeouts that explains the different values in comparison to the other two reasons ? 

in all cases total data size transmitted is the same.so also when trying to calculate how many re transmission and how many total connection events it seems that there is no "gold" number of connection events to transfer a known size of data it varies a lot from case to case. is there something to learn from looking on how many re  transmissions and total connection events count ?

If you are getting rx_timeout, then the central did not send a packet when it was expected. I'm not sure what you mean by node white list, but if the central device is connected to other devices, then it's maybe skipping connection events, and then the reason for the timeout have to do with scheduling. You can read about how the SDC handles scheduling here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/nrfxlib/softdevice_controller/doc/scheduling.html , you could e.g try to change connection interval and see how that affects the behavior. Also a sniffer log can be useful here, maybe it's skipping every x connection events. For nak_count, then the other device did not get your packet last connection event, and a packet needed to be retransmitted.

[ziv123]

hi Sigurd

it has been a while since i touched this issue. i am back on it now.

I am enabling the connection event report and it works ok.

1. What added values can i get from the channel index if I look at the complete time of connection between central and peripheral ? 

2. Is there some other info I can get from the softdevice that can give insight / statistics on the BLE connection health, noise, density etc. ? (i am also reading RSSI on peripheral side and central side)

3. i am using the same function as in the ncs example [ enable_qos_conn_evt_report() ] to enable the callback on the connection events

does it matter if i call it once in my application comm's init function, without disabling it (ever) ?

can i enable and disable it while a connection is already active between central and peripheral ? 

how can i disable the callback ?

hope to read you soon

best regards

Ziv 

[Sigurd]

Hi Ziv,

ziv123 said:

I am enabling the connection event report and it works ok.

Great!

ziv123 said:

1. What added values can i get from the channel index if I look at the complete time of connection between central and peripheral ? 

I don't understand this question.

ziv123 said:

2. Is there some other info I can get from the softdevice that can give insight / statistics on the BLE connection health, noise, density etc. ? (i am also reading RSSI on peripheral side and central side)

We have recently added a new feature on the main branch. https://github.com/nrfconnect/sdk-nrfxlib/blob/main/softdevice_controller/CHANGELOG.rst#id317 that gives you channel_energy.

"Experimental support for the Quality of Service (QoS) channel survey. See the :c:func:`sdc_hci_cmd_vs_qos_channel_survey_enable` function."

ziv123 said:

3. i am using the same function as in the ncs example [ enable_qos_conn_evt_report() ] to enable the callback on the connection events

does it matter if i call it once in my application comm's init function, without disabling it (ever) ?

can i enable and disable it while a connection is already active between central and peripheral ? 

how can i disable the callback ?

I don't think there is any limitations here. You disable it in the same way as you enabled, but instead of cmd_enable->enable = true; , you set cmd_enable->enable = false;

PS: I believe the original question in this case, "how can i get the number BLE TX re transmissions", has been answered. If you have new questions or issues, please open a new case.

[ziv123]

Hi Sigurd

i'll close this topic after this last question 

Sigurd said:

I don't understand this question.

what i am asking is what can i learn from the information about the channel number (which probably change every few connection events or something like that) in the connection event report ?

(that is when i look at a complete connection session that is composed from many connection events) 

Sigurd said:

We have recently added a new feature on the main branch. https://github.com/nrfconnect/sdk-nrfxlib/blob/main/softdevice_controller/CHANGELOG.rst#id317 that gives you channel_energy.

same question as for what i can learn about the environment, interference, etc. where my central and peripheral are set from channel energy?

(or is it something that suppose to help the central pick specific channels for the hopping map ? )

hope to read you soon

best regards

Ziv

[Sigurd]

Hi,

ziv123 said:

(or is it something that suppose to help the central pick specific channels for the hopping map ? )

Correct. E.g. if you see that retransmits happening on only certain channels, or that the channel energy is very high on certain channels, the central can use that that information, and call bt_le_set_chan_map() to set a channel map to avoid those channels.