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]

ok, if i am correct then the issue is this config  ' CONFIG_BT_LL_SW_SPLIT '

which according to https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/connectivity/bluetooth/bluetooth-arch.html#bluetooth-build-types

means i am working with the zephyr BLE stack and not with the nrf connect SDK's softdevice.

please correct me if i am wrong

and if i understand correct then zephyr BLE LL des not support the connection event report, again, correct me if i am wrong

so..

1. is there an API to get BLE re transmissions count, while using zephyr BLE LL 

2. is there a build that enables work with both, if it is even possible to have 2 ble stacks work together, or is ti just enabling use of nordic libraries ?

3. if not, how complex should it be to migrate to work with the Nordic softdevice, is there some guide on the topic ?

p.s. regarding low latency, according to the table of Proprietary feature support in here https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/README.html#softdevice-controller

 is it not dependent on the other side of the BLE connection, central/peripheral's ability to support that ?

hope to read you soon

best regards

Ziv

[Sigurd]

Hi,

ziv123 said:

and if i understand correct then zephyr BLE LL des not support the connection event report, again, correct me if i am wrong

Correct. The QoS Connection Event Report is a feature of the SoftDevice/MPSL stack.

ziv123 said:

1. is there an API to get BLE re transmissions count, while using zephyr BLE LL 

I'm not aware of any API for this for the Zephyr Controller.

ziv123 said:

2. is there a build that enables work with both, if it is even possible to have 2 ble stacks work together, or is ti just enabling use of nordic libraries ?

You can only have 1 stack enabled.

ziv123 said:

3. if not, how complex should it be to migrate to work with the Nordic softdevice, is there some guide on the topic ?

Set CONFIG_BT_LL_SW_SPLIT=n

ziv123 said:

 is it not dependent on the other side of the BLE connection, central/peripheral's ability to support that ?

To use the Low Latency Packet mode, you need to use nRF52 with LLPM support on both sides of the link.

[ziv123]

Hi,            

Sigurd said:

Set CONFIG_BT_LL_SW_SPLIT=n

this much i know,  but the the whole API used on our BLE comm module will have to change now 

and my question is is there some API correlation doc to switch to softdevice controller from zephyr controller ?

- what modules are used in softdevice that correlate and if i try to deep dive into my current zephyr controller APIs until i get to an NCS ones, could i just use them directly ? (not sure you can answer that but i am trying )

 - where can i find some comparison between the 2 BLE stacks cause changing the BLE stacks may change much more things in the connection and throughput etc. 

also i need to know if by moving to softdevice controller i am loosing some zephyr's controller features ? 

and lastly is it actually preferable to move to softdevice controller from currently implemented zephyr controller assuming we are going to keep on working with nrf52832 and nrf52840 for a list few more years ? what are the pros and cons of that transition ?

hope to read you soon

best regards

Ziv                           

[Sigurd]

ziv123 said:

this much i know,  but the the whole API used on our BLE comm module will have to change now 

I don't see why, Both the SoftDevice Controller and the Zephyr Controller, uses the Zephyr Bluetooth Host, and the Zephyr Bluetooth Host API can be used by both controllers.

ziv123 said:

also i need to know if by moving to softdevice controller i am loosing some zephyr's controller features ? 

I'm not aware of any features you might lose. Is there anything you have in mind ?

ziv123 said:

and lastly is it actually preferable to move to softdevice controller from currently implemented zephyr controller assuming we are going to keep on working with nrf52832 and nrf52840 for a list few more years ? what are the pros and cons of that transition ?

The SoftDevice Controller is the recommended controller. It's what we test and qualify. 

[ziv123]

Sigurd said:

I don't see why, Both the SoftDevice Controller and the Zephyr Controller, uses the Zephyr Bluetooth Host, and the Zephyr Bluetooth Host API can be used by both controllers.

if i change to =n (only that change) then i get:

ASSERTION FAIL [((((prio)) == 10 && z_is_idle_thread_entry((entry))) || (((10 - 1) >= ((-5))) && ((prio)) >= ((-5)) && ((prio)) <= (10 - 1)))] @ WEST_TOPDIR/zephyr/kernel/thread.c:536
00> 
00>   invalid priority (10); allowed range: 9 to -5
00> 
00> [00000001] <err> os: ***** USAGE FAULT *****
00> [00000001] <err> os:   Attempt to execute undefined instruction
00> [00000001] <err> os: r0/a1:  0x00008001  r1/a2:  0x20022b40  r2/a3:  0x0004ae97
00> [00000001] <err> os: r3/a4:  0x20026c30 r12/ip:  0x00000000 r14/lr:  0x0003ed4b
00> [00000001] <err> os:  xpsr:  0x61000000
00> [00000001] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
00> [00000001] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
00> [00000001] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
00> [00000001] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
00> [00000001] <err> os: fpscr:  0x00000000
00> [00000001] <err> os: r4/v1:  0x200055c8  r5/v2:  0x00000388  r6/v3:  0x00000000
00> [00000001] <err> os: r7/v4:  0x20022b50  r8/v5:  0x0003ca55  r9/v6:  0x0000000a
00> [00000001] <err> os: r10/v7: 0x00000000  r11/v8: 0x00000000    psp:  0x20022ad8
00> [00000001] <err> os: EXC_RETURN: 0xffffffed
00> [00000001] <err> os: Faulting instruction address (r15/pc): 0x0003ed4a
00> *** Booting Zephyr OS build v3.1.99-ncs1  ***
00> I: Reset Reason, RESETREAS=0x4
00> I: Reset Causes: 
00> I:  Software
00> I: GNU Build ID: 80e5e918576521287483c25ad58831d4437782b8

in my init flow

any idea why this is ?

maybe it has something to do with me working with pm_static and maybe the softdevice needs to be given some defined specific place ?

hope to read you soon

best regards

Ziv