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

[Sigurd]

Hi,

ziv123 said:

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 ? 

Yes, it's per connection event(that happens every connection interval), so you need to sum it to get it the amount over time. This is the way to do it.

ziv123 said:

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 ?

The central has the final say in what connection interval to use.

ziv123 said:

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 ?

I have not seen any complaints or issues with that before. If you are sending a lot of data, that are split into many small packets, then the total on-air time is reduced with a Data Packet Length Extension, since you don't have the overhead/header data for multiple packets. Also with BLE 5.0, you have 2M PHY, so packets are sent 2x faster, that also reduces the risk of packets being affected by RF interference. 

[ziv123]

Hi

Sigurd said:

Yes, it's per connection event(that happens every connection interval), so you need to sum it to get it the amount over time. This is the way to do it.

1. our connection interval is the minimum 7.5mlsec, is it enough time to get all the info summed (we also read data from external flash and build packets while transmitting) ?

2. i did not understood from your question if i need to sum the

(nak count + crc_fail count + rx_timeout count = re tx count) , or am i missing something ? 

3.  if the report is per connection event then the event counter is llike a running index counting how many connection event there have been so far, meaning the last one is the total connection event happend in one connection session between 2 devices ?

Sigurd said:

The central has the final say in what connection interval to use.

the central does have the final say but if i want the peripheral to ask for longer connection events, how can i do it ?

Sigurd said:

I have not seen any complaints or issues with that before

i am not complaining :) and obviously throughput should be better, but i just wonder if there is some data or some ratio of packet size vs probability to have to resent it since our devices are sometimes installed in challenging environments BLE wise

[Sigurd]

ziv123 said:

1. our connection interval is the minimum 7.5mlsec, is it enough time to get all the info summed (we also read data from external flash and build packets while transmitting) ?

Yeah, that shouldn't be a problem.

ziv123 said:

2. i did not understood from your question if i need to sum the

(nak count + crc_fail count + rx_timeout count = re tx count) , or am i missing something ? 

Yes, you need to sum it.

ziv123 said:

3.  if the report is per connection event then the event counter is llike a running index counting how many connection event there have been so far, meaning the last one is the total connection event happend in one connection session between 2 devices ?

One report will be generated every connection event. If you add some counter in your application, that you increment each time you get this event, then yes, that would be the total amount of connection events happened in one connection session between 2 devices.(Assuming your device is only connected to 1 device.)

ziv123 said:

the central does have the final say but if i want the peripheral to ask for longer connection events, how can i do it ?

By default, we extend the connection event as long as there are packets to be sent. If there is no more data to send, the connection event is closed. There is no option in the spec to ask the central for "longer connect events".