Triks for keeping BLE connection robust.

[Valer_I]

Hello all, at present time I'm making investigation of BLE link stablility at harsh megapolis environment and at long open space ranges. During testing I found out some information and collected some questions.
The setup is: Proprietary device based on nRF518222 + S110 v.8 softdevice. The NUS service configgured to notify some data each second. The connection parameters were: ConnInterval: 30ms, SlLatency: 34, SupervisionTimeout: 10000ms.

The sniffer capturing shown:

1. Peripheral sends empty pdu packet without considering that recently notification PDU was sent to central. So slave latency counter functionality in S110 do not monitor other outgoing packets? Why? It drains the battery what is the gain ?

2. At long distances the slave latency counter seem to be disabled and S110 peripheral send the empty PDU at each connection event. What RSSI threshold (in dbm) is set in Softdevice to start link reinforcement.

3. Any RSSI averaging algorithm in Softdevice before passing value through the BLE_GAP_EVT_RSSI_CHANGED event?

The brief manual on how to hold the BLE link as long as possible by means of Nordic's SoC would be appreshiated.

Edit: Sniffer_cap_link_test.pcapng

[Hung Bui]

1. It's a good question. I think it's a design choice here. We have to wake up on the next connection event after we send the notification to re-transmit it if it's not ACKed by the central. And I think what we did was to send an empty packet on that event just to mark a new anchor point. This won't cost much as we already awake and we can save 1 connection event for the slave latency (skip one extra connection event) .

2. Well, it may not has anything to do with RSSI, it's just we were re-transmitting the packet because it's not ACKed by the central. You can see that we have SN =0 and NESN = 1 in 4 consecutive slave packet before it's ACKed.