BLE connection stability

RE: BLE connection stability

Edvin — Fri, 16 Oct 2020 07:32:52 GMT

Hello,

Most of this seems right, but a few corrections:

[quote user="Tim123"]A connection event is always 7.5 ms. So a larger connection interval means more idle time between connection events. This can be helpful when BLE coexists with timeslot API activity, as in our case.[/quote]

This is not necessarily true. Typically, a connection event is only a couple of ms (with little payload), and up to the entire connection event, depending on the connection parameters, and the payload.

You can check it out here:

https://devzone.nordicsemi.com/nordic/power/w/opp/2/online-power-profiler-for-ble

[quote user="Tim123"]S110 has 6 tx buffers. Is this true also for S112 v6.1.1?[/quote]

It really depends on the packet size. You can fill it with one long notification as well.

While I believe it is possible to increase this queue size, that is rarely the solution, as it will just move the queue from one location to another. Keep track of what packets you have been able to queue. As long as the function you use to queue returns NRF_SUCCESS, it is queued and will be sent. You can forget the payload from your application side. If it returns NRF_ERROR_RESOURCES, it means that the packet didn't fit in the queue, and it was not queued. In this case, you must wait for the next BLE_GATTS_EVT_HVN_TX_COMPLETE event. This means that a packet from your softdevice queue was acked, and it has room for more data. At this point you can call the function that calls sd_ble_gatts_hvx() function again.

Best regards,

Edvin

RE: BLE connection stability

Tim — Fri, 16 Oct 2020 03:17:49 GMT

Thanks Edvin. Testing has been going well. Thanks to your help, I have a better understanding of some of the interaction between central and peripheral. Some of my current assumptions:

A link between central and peripheral is always initially PHY 1MBPS. Then if the central supports it (i.e. BLE 5.0 or later), it will send a BLE_GAP_EVT_PHY_UPDATE_REQUEST to the peripheral and the peripheral can update PHY to any of the available options (AUTO, 1MBPS, 1MBPS, CODED). For our application, range is more important than throughput, so we set to 1MBPS.
It seems that the initial connection interval when connecting peripheral with iOS central is always 30 ms. If connection parameter negotiation offers minimum interval of 30 ms with any maximum (always needs to be multiple of 15 ms), iOS will always select 30 ms. However, if peripheral offers minimum greater than 30 ms (e.g. 45, 60, 75, etc.) and a maximum greater than that, iOS will always choose the maximum. I've tested up to a maximum of 120 ms.
A connection event is always 7.5 ms. So a larger connection interval means more idle time between connection events. This can be helpful when BLE coexists with timeslot API activity, as in our case.
Yes, this post says connection parameter negotiation occurs 5 seconds after connection (in many examples) to be sure service discovery has completed.

This post says S110 has 6 tx buffers. Is this true also for S112 v6.1.1? Rarely does our application call sd_ble_gatts_hvx() more than twice in quick succession.

Recently we've been testing with connection interval of 120 ms. Our application uses the timeslot API for radio use between BLE activity. I presume that a larger connection interval makes it easier for time slots to be successfully scheduled, correct?

Many thanks Edvin.

Tim

RE: BLE connection stability

Edvin — Tue, 06 Oct 2020 08:16:53 GMT

Hello Tim,

That is good. I thought iPhones just set it to 30ms no matter what connection interval you used. So if you are able to set it higher, it will reduce the current consumption. Please note that it will also increase the latency of the link.

Remember that when you increase the connection interval, you may also want to increase the supervision timeout. If you have a connection interval of 60ms, and a supervision timeout of 600ms (just random numbers) you can miss 10 packets before a disconnect, while if you increase the connection interval to 120ms, you can only miss 5.

[quote user="Tim123"]What is the reason for the 5 second delay before calling sd_ble_gap_conn_param_update() in ble_app_uart example of SDK 15.3.0 (FIRST_CONN_PARAMS_UPDATE_DELAY = 5s)?[/quote]

I don't remember exactly the reason, but there is something that we want to let finish before we start this. I believe it is the service discovery that we want the central to be able to perform before we change the connection interval.

Best regards,

Edvin

RE: BLE connection stability

Tim — Tue, 06 Oct 2020 05:58:07 GMT

Hi Edvin,

I've discovered that with iPhone/iOS, if slave requests minimum connection interval is 30ms, then you'll always get 30ms regardless of what maximum interval is. However, if minimum interval is 45ms or higher (needs to be multiple of 15 to meet Apple requirements), then you'll get whatever the specified maximum interval is. I've tested on both old iPhone (4s) and new (iPhone SE (2020)) and observe this behaviour.

I've attached two traces. conn_intervals_30-105.pcapng uses min 30, max 105. Notice no connection parameter update request, and the initial CONNECT_REQ packet shows 30ms interval.

devzone.nordicsemi.com/.../conn_5F00_intervals_5F00_30_2D00_105.pcapng

devzone.nordicsemi.com/.../conn_5F00_intervals_5F00_45_2D00_105.pcapng

conn_intervals_45-105.pcapng uses min 45, max 105. Notice connection parameter request from the slave at packet no. 734, then the response at no. 735 with move result "Accepted". Then no. 757 LL_CONNECTION_UPDATE_REQ showing interval of 84, which is 105ms.

In most recent tests the connection instability previously experienced was gone. Two things changed:

- used connection interval of 120ms

- switched from 2MBPS to 1MBPS PHY

Given high throughput is not a requirement, thought to go with min 60 and max 105. Reasonable?

What is the reason for the 5 second delay before calling sd_ble_gap_conn_param_update() in ble_app_uart example of SDK 15.3.0 (FIRST_CONN_PARAMS_UPDATE_DELAY = 5s)?

Many thanks,

Tim

RE: BLE connection stability

Edvin — Fri, 02 Oct 2020 13:51:54 GMT

[quote user="Tim123"]Given throughput is not important, power consumption is not important (peripheral devices powered by 2 AA batteries), but reliable use with Timeslot API is important, what min/max connection intervals would you recommend?[/quote]

If your central is always an iPhone it doesn't really matter. Set min = 30ms and max = 100ms. You will get 30ms either way. If you set max=100ms, and Apple one day in the future supports >30ms, you will save some battery.

[quote user="Tim123"]How do I attain a higher connection interval if iOS always denies and uses 30 ms?[/quote]

You can't. It is always the Central that controls this parameter. As you mentioned in the previous reply, you can request changes, but it is the central that has the final saying. The only thing the peripheral can do is to disconnect if you don't get the connection parameters you desire, but I guess you don't really want to do that.

[quote user="Tim123"]Is there a way a peripheral application can read the connection interval in use for debug logging?[/quote]

I guess it says in the connected event and in the connection parameter update event.

Check out the parameters in this struckt in the BLE_GAP_EVT_CONNECTED:

p_ble_evt->evt.gap_evt.params.connected.conn_params... [min_conn_interval, max_conn_interval_slave_latency, conn_sup_timeout]

And check out the parameters in this struct in BLE_GAP_EVT_CONN_PARAM_UPDATE event:

p_ble_evt->evt.gap_evt.params.conn_param_update.conn_params... [the same parameters as the BLE_GAP_EVT_CONNECTED event]

[quote user="Tim123"]but then the LL_PHY_UPDATE_IND packets from the master show False for all modes.[/quote]

I believe this packet is just an "abort" message for the phy change. It also says "instance: 0". Instance refers to the event counter that these changes shall be enforced. If you want to monitor the changes from the application, check out the BLE_GAP_EVT_PHY_UPDATE_REQUEST and BLE_GAP_EVT_PHY_UPDATE_REQUEST events (look for the parameters like you do for the connected and conn_param_update events).

The BLE_GAP_EVT_PHY_UPDATE_REQUEST event will contain the phy parameters that the central requests, and if you get the BLE_GAP_EVT_PHY_UPDATE event, it means that the PHY is updated, and the event contains the new PHY.

Best regards,

Edvin

RE: BLE connection stability

Tim — Fri, 02 Oct 2020 12:28:55 GMT

Thanks Edvin. Given throughput is not important, power consumption is not important (peripheral devices powered by 2 AA batteries), but reliable use with Timeslot API is important, what min/max connection intervals would you recommend?

I find it odd that when I used:

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(60, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(120, UNIT_1_25_MS)
#define SLAVE_LATENCY 0
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS)
#define FIRST_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(5000)
#define NEXT_CONN_PARAMS_UPDATE_DELAY APP_TIMER_TICKS(30000)
#define MAX_CONN_PARAMS_UPDATE_COUNT 3

the CONNECT_REQ packet in sniffer trace still showed connection interval of 30 ms:

Bluetooth Low Energy Link Layer
    Access Address: 0x8e89bed6
    Packet Header: 0x22c5 (PDU Type: CONNECT_REQ, ChSel: #1, TxAdd: Random, RxAdd: Random)
    Initator Address: 5e:94:05:58:20:fc (5e:94:05:58:20:fc)
    Advertising Address: d5:88:07:32:7a:ad (d5:88:07:32:7a:ad)
    Link Layer Data
        Access Address: 0xaf9aa3de
        CRC Init: 0x9ef18e
        Window Size: 3 (3.75 msec)
        Window Offset: 6 (7.5 msec)
        Interval: 24 (30 msec)
        Latency: 0
        Timeout: 72 (720 msec)
        Channel Map: ff07c0f81f
        ...1 0000 = Hop: 16
        001. .... = Sleep Clock Accuracy: 151 ppm to 250 ppm (1)
        CRC: 0xadcae0

(This is packet 2215 of sniffer trace attached above.) This was for one of the 9 connected peripherals and it was the last peripheral to connect. As far as I can tell, the above defines respect Apple's requirements:

Interval Min ≥ 15 ms (multiples of 15 ms)
Interval Min + 15 ms ≤ Interval Max (Interval Max == 15 ms is allowed)
Interval Max * (Slave Latency + 1) ≤ 2 seconds
Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout
Slave Latency ≤ 30
2 seconds ≤ connSupervisionTimeout ≤ 6 seconds

How do I attain a higher connection interval if iOS always denies and uses 30 ms?

Is there a way a peripheral application can read the connection interval in use for debug logging?

Lastly, in sniffer trace, how do I verify what PHY setting is used for the link? In the attached trace, I see packet 2235 is the slave/peripheral stating it prefers LE 1M PHY, but then the LL_PHY_UPDATE_IND packets from the master show False for all modes.

devzone.nordicsemi.com/.../8688.sniffer-trace_2D00_4.pcapng

Many thanks,

Tim

RE: BLE connection stability

Edvin — Fri, 02 Oct 2020 08:52:12 GMT

Hello,

By default the nRF will advertise using 1MBPS (according to the BLE specification). After this, any of the devices may request a PHY change.

[quote user="Tim123"]Is it guaranteed that ble_evt_handler(...) will be called with the BLE_GAP_EVT_PHY_UPDATE_REQUEST event?[/quote]

Yes. This is what triggers the response.

[quote user="Tim123"]Should I also call sd_ble_gap_phy_update(...) when the BLE_GAP_EVT_CONNECTED event occurs?[/quote]

Not unless you want to change the PHY. There is no point in updating the PHY if you are already on the PHY that you would like to stay on. Calling sd_ble_gap_phy_update(...)

[quote user="Tim123"]Can the central refuse to honour the sd_ble_gap_phy_update(...) request?[/quote]

No, but it can reply that it doesn't support 2MBPS, and the devices will stay on 1MBPS.

[quote user="Tim123"]I realize that connection parameters can be requested by the peripheral but the central decides which parameters to use. In the attached sniffer trace, the connection interval is 30ms, even though min/max connection interval were 60/120.[/quote]

That is correct, and phones act differently. Most Androids and iPhones use only two connection intervals, 15ms or 30ms, so this next section may not be that useful for you.

In your case, where you don't need a lot of throughput, you may turn the connection interval up, as this would mean less radio activity, which again means a lower current consumption. However, a higher connection also means a higher latency.

Supervision Timeout/Connection interval is the number of packets you can drop before it leads to a disconnection with reason 0x08, which is also a thing you should consider.

A large connection interval also makes it easier for the timeslot API to get their timeslots.

Best regards,

Edvin

RE: BLE connection stability

Tim — Fri, 02 Oct 2020 04:55:56 GMT

Thanks Edvin. I tried using 1 MBPS and it reduced disconnect errors to zero. Sniffer trace (attached) shows very few dropped packets. This was with same test scenario: 9 peripherals, sets of 3 connected to 3 central devices. I understand 2 MBPS came with BLE 5.0. Only one of the central (iOS) devices supports BLE 5.0. The other two support 4.2. So in the previous test (many disconnect errors), 3 of 9 peripheral links were 2 MBPS and 6 of the 9 were 1 MBPS.

devzone.nordicsemi.com/.../sniffer-trace_2D00_4.pcapng

Is it guaranteed that ble_evt_handler(...) will be called with the BLE_GAP_EVT_PHY_UPDATE_REQUEST event? Should I also call sd_ble_gap_phy_update(...) when the BLE_GAP_EVT_CONNECTED event occurs? Can the central refuse to honour the sd_ble_gap_phy_update(...) request?

The initial test (today) was with min/max connection interval set to 30/75ms (zero disconnect errors). I increased to 60/120 and same good results. I don't know how to choose optimal min/max connection intervals given use case. Data throughput is not important, and only small amounts of data (<18 bytes) are sent either direction. Any advantages, other than data throughput, of low connection intervals? BLE needs to play well with Timeslot API. I realize that connection parameters can be requested by the peripheral but the central decides which parameters to use. In the attached sniffer trace, the connection interval is 30ms, even though min/max connection interval were 60/120.

Thanks for your explanation about supervision timeout. I understand.

Many thanks,

Tim

RE: BLE connection stability

Edvin — Thu, 01 Oct 2020 14:36:59 GMT

You can increase the supervision timeout, but consider what this really does. All it does is changing from a connected to a disconnected state after the supervision timeout has expired. If that works in your case, you may try this. But the reason for your timeouts is that the devices hasn't been able to communicate for 720ms. Setting the supervision timeout to e.g. 4 seconds will increase the time it takes to disconnect by timeout, but it still means that you loose packets. Disconnecting and reconnecting isn't really an issue in itself, but if it soothes your mind that the devices is connected at all times if you increase the supervision timeout, then go ahead.

NB: By default, all the examples in the SDK has a supervision timeout of 4 seconds.

[quote user="Tim123"]3 devices max is typical, but sometimes there can be 6 or even 9.[/quote]

If you intend to have 9 connected devices, I would look into increasing the connection interval. One connection event takes a couple of ms, so 3 connections per 30ms is not a problem, but if the central spends over half the time on the radio supporting all the links, then you may encounter more packet loss, due to timeslot collisions. Please check out how long the central spends on one connection per connection interval using the online power profiler:

https://devzone.nordicsemi.com/nordic/power/w/opp/2/online-power-profiler-for-ble

Best regards,

Edvin

RE: BLE connection stability

Tim — Thu, 01 Oct 2020 12:38:45 GMT

Thanks Edvin. I will try changing to 1MBPS. I presume I should also change to 1MBPS for the radio configuration of the time sync code that uses Timeslot API to sync clocks?

Yes, all devices are in the same large room (160 x 120 square feet), no interior walls. For my current testing, all devices are near one wall.

I’ll try 1MBPS next. Would it also be worthwhile to increase the minimum connection interval? Supervisor timeout? 3 devices max is typical, but sometimes there can be 6 or even 9.

Could caps of too low value (12 pf instead of 20) cause the issue? We will change to 20. I’ll check with our engineer about R10.

Many thanks Edvin,

Tim

RE: BLE connection stability

Edvin — Thu, 01 Oct 2020 10:36:53 GMT

Ok, so the timeout reasons are:

0x08: BLE_HCI_CONNECTION_TIMEOUT
0x3E: BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED
0x28: BLE_HCI_INSTANT_PASSED

0x3E means that the devices failed to connect, which can also be caused by packet loss.

0x28 means that some change that was supposed to happen (e.g. channel map update or connection parameter update) was not Acked until the instant they were supposed to take place.

All of these can occur if you struggle with packet loss.

Regarding the PCB layout. The capacitors C6 and C7 should have the value:

C = 2*Cl - Cpin - Cpcb

where Cl = capacitance of the LFXTAL (Y1), Cpin = the capacitance of the pin, which is 4pF on the nRF52832 and Cpcb is the capacitance on the PCB trace. Typically between 0 and 1pF.

From the datasheet of your XTAL, it has 12.5pF, so in your case the capacitors should have: C = 2*12.5 - 4 - 0 = 21pF. Standard capacitors are either 20 or 22, so you should go with 20 pF Capacitors (allowing 1 pF in the PCB trace). Regarding the R10 (10MOhm) I am not sure. It is not present in the reference layout. I see it has a large resistance, but I don't know what effect it has. Do you know why it was added?

As I can see you are not sending a lot of packets, and you are using 30ms connection interval. If you only have 3 connections that should be plenty of time.

I did however notice that you are using 2MBPS. This is not great for longer ranges. I suggest that you set 1MBPS. Depending on what SDK you are using, this is set a bit differently.

Try changing:

case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;
        
//to:

case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_1MBPS,
                .tx_phys = BLE_GAP_PHY_1MBPS,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

2MBPS has a shorter range than 1MBPS, and since you are not sending a lot of payload data, this may be better in your case, if you have long distances.

[quote user="Tim123"]With 9 peripherals connected to 3 centrals (3 peripherals to each central (iOS device)), the disconnects occurred often for one particular peripheral (once every minute or two). The 3 peripherals connected to a central are separated by maximum 140 feet in open space. The centrals (iOS devices) were sitting at most 100 feet from the farthest peripheral. I noticed that often as I walked up to the centrals, a disconnect would occur. It seemed that when the space had other people (8-10 people) present, disconnects occurred more frequently.[/quote]

Reasons for packet loss:

- Too long distance, so the signal strength is too low.

- Obstances, such as walls, and people (The human body is mostly water, which absorbs the 1.4GHz radio signals)

- Noise (a little bit from other BLE connections, but not much, as they are using different channels. Wifi is a causing more noise).

Try changing to 1MBPS, and see if that helps. Are all the devices in the same room, or are there many walls in between the devices?

RE: BLE connection stability

Tim — Thu, 01 Oct 2020 06:01:59 GMT

Thanks Edvin,

Today I confirmed that when random disconnects occur, it is not because the nRF is crashing and resetting. I logged the following reason codes: 0x08, 0x3E, 0x28 with 0x08 being the most common. With 9 peripherals connected to 3 centrals (3 peripherals to each central (iOS device)), the disconnects occurred often for one particular peripheral (once every minute or two). The 3 peripherals connected to a central are separated by maximum 140 feet in open space. The centrals (iOS devices) were sitting at most 100 feet from the farthest peripheral. I noticed that often as I walked up to the centrals, a disconnect would occur. It seemed that when the space had other people (8-10 people) present, disconnects occurred more frequently.

After logging the disconnect reasons and capturing a few more sniffer traces, I turned off 2 of the 3 sets of 3 peripherals leaving 3 peripherals connected to 1 central. Disconnect rates went way down (only a couple disconnects over a 20-minute period). I walked throughout the space carrying the central device and no disconnects. Probably maximum 190 feet distance between central and any of the 3 peripherals.

I've attached another sniffer trace with several disconnects captured.

devzone.nordicsemi.com/.../sniffer-trace_2D00_3.pcapng

I didn't have time to test using the internal RC. If still worthwhile after above information, I'll test today. We use 12pF caps on the external crystal. Here's the schematic:

Here's a portion of the board layout:

Thank you for your thoughts about this. If your sense now is that RF interference is the cause of the disconnects, any suggestions in how to mitigate this? Adjust connection parameters? Clock settings?

Generally, what are the common sources of RF interference that would impact BLE connection stability?

Many thanks,

Tim

RE: BLE connection stability

Edvin — Wed, 30 Sep 2020 08:23:00 GMT

Hello Tim,

[quote user="Tim123"]As I mentioned earlier, our application uses a simplified version of the wireless clock synchronization code described here.[/quote]

That should not affect the timekeeping for the softdevice. These are completely separate.

The accuracy of the XTAL is dependent on both the XTAL itself and the PCB layout (more precisely the capacitors between the LFXTAL and the nRF). I see that your LFXTAL has 12.5pF capacitance. What are the value of the caps between the XTAL and the nRF?

However, I am not convinced that this is an XTAL issue.

[quote user="Tim123"]Should I be setting NRF_SDH_CLOCK_LF_ACCURACY to 9?[/quote]

If you want to check whether it is an XTAL issue, please try to set:

NRF_SDH_CLOCK_LF_SRC 0
NRF_SDH_CLOCK_LF_ACCURACY 1
NRF_SDH_CLOCK_LF_RC_CTIV 16
NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2

This will enable the internal RC oscillator instead of the external XTAL. Since we know this should work, try to look for the disconnects with these settings.

But first, I would try to look for the disconnect reason with your current settings.

BR,

Edvin

RE: BLE connection stability

Tim — Wed, 30 Sep 2020 05:07:29 GMT

Thanks Edvin. I was out testing today and was unable to log the intermittent disconnect. It happened only once on a peripheral I was not debug logging. I'll continue to confirm whether nRF gets the disconnect event.

As I mentioned earlier, our application uses a simplified version of the wireless clock synchronization code described here. For each system of 3 peripherals connected to 1 central (iOS device), one of the peripherals constantly transmits time beacons at a constant frequency for a specific PREFIX0 and BASE0. Every 30 seconds, the other two peripherals listen for beacons (same PREFIX0 and BASE0) and once a beacon is received they stop listening and set a timer to start listening again in 30 seconds. Initially the transmit frequency was 50Hz and I was noticing that receipt of beacons at the listening peripherals could take up to 8 or 10 seconds. I increased the transmit frequency to 100Hz and the time to receive a beacon once listening started went down to 1 second or less. However, after increasing the transmit frequency to 100Hz, I noticed an unexpected disconnect of one of the peripherals. At 50Hz, the BLE connections appeared stable. The documentation for the Timeslot API (used by the timer sync code) states that its use can influence the performance of the SoftDevice. Makes me wonder if Timeslot API use is the cause of unexpected disconnects.

Would increasing the min and max connection interval and supervisor timeout help with stability of the BLE connection?

About clock source and accuracy, sdk_config.h has the following:

//  NRFX_CLOCK_CONFIG_LF_SRC  - LF Clock Source
// <0=> RC 
// <1=> XTAL 
// <2=> Synth 
// <131073=> External Low Swing 
// <196609=> External Full Swing 

#ifndef NRFX_CLOCK_CONFIG_LF_SRC
#define NRFX_CLOCK_CONFIG_LF_SRC 1
#endif

// NRF_SDH_CLOCK_LF_SRC - SoftDevice clock source.
// <0=> NRF_CLOCK_LF_SRC_RC 
// <1=> NRF_CLOCK_LF_SRC_XTAL 
// <2=> NRF_CLOCK_LF_SRC_SYNTH 

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

//  NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 7
#endif

Our custom board has this ±5ppm external crystal connected to XL1/XL2. Should I be setting NRF_SDH_CLOCK_LF_ACCURACY to 9?

Thanks Edvin.

Tim

RE: BLE connection stability

Edvin — Tue, 29 Sep 2020 08:45:23 GMT

Hello Tim,

[quote user="Tim123"]occasional Empty PDU packets from the slave are not seen by the sniffer. For example, at 15.408, 15.497, 15.588, etc. Prior to disconnect at 103.733[/quote]

Yes. Those are "normal". Since it is an on air link, you will occasionally have some dropped packets. When these are missing from the sniffer trace it means one of three things:

1: The sniffer didn't pick up the packet, but the central did.

2: The sniffer and the central didn't pick up the packet.

3: The peripheral didn't pick up the previous packet from the central correctly (bad CRC), which means it doesn't have anything to reply to.

In the case of packet nr 2001 and 2002 (15.408) I see that the NESN (next expected serial number) in the central's packet doesn't change, which indicates that the central didn't pick up any packets from the peripheral in between these two:

However, if you have a large distance between the two devices, you can expect some packet drops occasionally.

The increased number of dropped packets is probably caused by the environment. If something comes between the devices, a lot of radio noise in the area, a bad channel (much noise) or similar can cause this. Since it does reply after a while (even with 8 packets) that indicates that the nRF is still running as expected. However, when you have the disconnect you have 24 missed packets. It can either mean that the nRF's application has "crashed" and reset, or that the radio conditions are bad (noise). This is why I asked for the debug information on the nRF side. If you get the disconnected event, it probably means that the radio conditions are bad from time to time. If you don't get this event, you are probably seeing a reset caused by an application bug (most likely).

[quote user="Tim123"]Maybe as clocks of other nearby peripherals drift, and at some point the interference becomes intolerable?[/quote]

That shouldn't be an issue. They sync up every time they receive a packet. When you miss more packets the window that the peripheral listens will increase proportionally with the number of concecutive missed packets. You should however make sure you have the correct XTAL accuracy in the sdk_config.h file.

RE: BLE connection stability

Tim — Mon, 28 Sep 2020 16:52:58 GMT

Thanks Edvin. It will take some time to set up a debug environment in the field, but I can do that and find out if the BLE_GAP_EVT_DISCONNECTED event occurs on the peripheral and what the disconnect reason is.

In the meantime, I would be glad for any general guidance on creating a most stable link connection. Given that data throughput is not important, and that only small amounts of data are written (in either direction), what would be suggested connection parameters? Any other helpful considerations?

In reading the Timeslot API documentation, I understand that using it can affect performance of the SoftDevice, so I wonder if it is a factor in what I am experiencing.

I've attached another sniffer trace. It appears the disconnect occurs around time 103.733 as the peripheral/slave begins advertising again at 104.661. It seems that throughout duration of the connection, occasional Empty PDU packets from the slave are not seen by the sniffer. For example, at 15.408, 15.497, 15.588, etc. Prior to disconnect at 103.733, dropped slave Empty PDU packets become more frequent. At 98.002 there are 3 missing slave Empty PDU packets. At 100.852 there are 8 dropped packets, then more and more dropped packets until disconnect around 103.733. Would this suggest an interference issue? Maybe as clocks of other nearby peripherals drift, and at some point the interference becomes intolerable? Again, I have very little experience here, so maybe unhelpful speculation.

Many thanks,

Tim

devzone.nordicsemi.com/.../sniffer-trace_2D00_2.pcapng

RE: BLE connection stability

Edvin — Mon, 28 Sep 2020 14:46:39 GMT

Hello Tim,

I have looked at the sniffer log that you provided, and it looks like the nRF (the peripheral/slave) is not responding, and hence the disconnect, as you probably know.

What does the nRF behave like in this case? Have you tried to debug the application there? Do you get the disconnected event on the nRF as well, or does it for some reason reset? If you receive the disconnect event, what reason is it pointing to?

You can find the disconnect reason in the BLE_GAP_EVT_DISCONNECTED event by using:

NRF_LOG_INFO("Disconnected, reason: 0x%02x", p_ble_evt->evt.gap_evt.params.disconnected.reason);

What does it say?

Best regards,

Edvin