Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

RE: Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

Carlos — Mon, 07 Oct 2019 12:49:29 GMT

Hi,

I managed to solve the main issue as I changed the way I was handling TX_COMPLETE event when transmitting data and now every packet is sent without any packet loss.

Thank you very much for your time and support.

Regards.

RE: Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

tesc — Mon, 07 Oct 2019 08:56:00 GMT

Hi,

The LF accuracy setting affects timing windows in the BLE protocol, for accounting for clock drift. It will not change the accuracy of the clock, rather it accounts for drift up to the selected value. The NRF_CLOCK_LF_ACCURACY setting is used by the BLE stack in both ends of the connection, in the places appropriate.

What boards are you using? Does nRF52 Development Kits show the same behavior Would it be possible for me to reproduce this using nRF52 DKs?

Regards,
Terje

RE: Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

Carlos — Thu, 19 Sep 2019 19:19:34 GMT

Hi,

I give a try to each of your suggestions but no one has a positive effect to solve missed packets.

1- At First, NRF_CLOCK_LF_ACCURACY for master/slaves were the same as 20ppm.

Before reading BLUETOOTH SPECIFICATION Version 5.0 | Vol 2, Part E chapter 7.7.65.10 LE Enhanced Connection Complete Event, in the last paragraph is stated "The Master_Clock_Accuracy parameter is only valid for a slave. On a master, this parameter shall be set to 0x00." I changed both as suggested to 500ppm without success.

So, considering it changed master to 500ppm and keep slaves in 20ppm although this has not solved the question.

2- Slave latency has been tried but it makes master missed lot of packets

3- Changed scan window and scan interval for 10ms.

Any other suggestion ? I'm still working full time to solve this issue and keep trying but no success to the end.

RE: Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

tesc — Wed, 18 Sep 2019 14:35:38 GMT

Hi,

Three suggestions:

1. It might be an LF clock issue. What is your setting for NRF_SDH_CLOCK_LF_ACCURACY? Try set it to 500 ppm (NRF_CLOCK_LF_ACCURACY_500_PPM). This goes for both peripherals and central.

2. Use slave latency. Note that unit is not ms, it is number of connection events the peripheral can skip. (Note also that unit for supervision timeout is ms, not 1.25 ms units.)

3. In order to reduce the effect of scanning on active links, you can set equal, low values for scan window and scan interval (e.g. 5.)

Regards,
Terje

RE: Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

Carlos — Mon, 16 Sep 2019 15:03:46 GMT

Hi Terje,

For easy, consider following scenario as we changed configuration to run with only 2 peripherals to reproduce issue.
We are considering this design similar to multilink scheduling with two connections as a Central and minimum interval, as described on S132 spec.

Each Peripheral output (S) 39 bytes packet data at every 2t, where t is sensor rate at 10ms, see below picture.

Connection Event Length Extension enabled
Data Length Extension enabled
Gap event length = 16 (20ms) for both peripherals
Gap event length = 4 (5ms) for central
TX/RX MTU = 42 bytes
TX/RX time = 480us

After connection and before notifications, we update conn parameters to sensor rate at 10ms:
min Connection Interval = 32 (40 ms) // 10 * n*n + scan window, n=2 (common factor in ms)
max Connection Interval = 32 (40 ms) // scan window = 0, no scan after all devices connected
slave latency = 0ms
supervision timeout = 6000 ms
Central enable notification at once for all peripherals simultaneously.
Central only receive packets from peripherals, not sending (almost) any data to them

But this timing setup is not working properly as packet data are being lost from each peripheral.
After reading many times, S132 spec and specially the chapter 15.10 Suggested intervals and windows, which is not much clear we have tried lots of combinations of these parameters but none of them eliminates this problem.
New log files were attached showing how this configuration performed.
Devices are placed on the table and are away 30 cm from each other forming a triangle and sniffer boards placed in the middle of it. Central tx power is +4dbm and 0dbm for peripherals.
Thanks.

devzone.nordicsemi.com/.../4760.capture_5F00_36_5F00_new.pcapng devzone.nordicsemi.com/.../3286.capture_5F00_88_5F00_new.pcapng devzone.nordicsemi.com/.../5661.capture_5F00_new.txt

RE: Configuration for central and multi peripheral devices with DLE and Event Connection Extension Enabled

tesc — Fri, 06 Sep 2019 14:56:56 GMT

Hi,

Regarding scan and connection parameters, note that with the scan window and connection interval you have chosen, the SoftDevice of the central is not able to schedule connections and scanning without collisions between the two. Note also in the top-most scenario that when central has min/max of 80/160, and peripheral has min/max of 100/100, the negotiated connection interval will be 100. For timing and connection/scan parameters, I refer to Connection timing as a Central and Suggested intervals and windows, from the SoftDevice Specification.

Regarding periods of no packets from the peripheral, I see that for instance in capture_36.pcapng, at No. 8502, which is the last notification before no packets for a while, the packet is malformed (wrong CRC) and for the series of Empty PDU from master the sequence number is the same (repeated packet). It looks to me like the packet from the slave is either not received because of interference / noise, or it pauses RX for a while. Can you tell a bit more about the test setup with regards to where the boards (including sniffer) are placed in relation to each other?

Note also that the nRF Sniffer can only follow one link. That means you will get packets between the central and one of the peripherals, and so other peripherals and connections between those and the master will not be part of the sniffer trace.

Regards,
Terje