Start losing frames on LL_CHANNEL_MAP_REQ

[elgogi]

Hi

I'm using nrf51422 to send periodically a frame through ble_nus service to the Nordic nRF UART app. One of the frame data is the message count number, that is reset every 64 counts.

Everything goes smooth until the master sends LL_CHANNEL_MAP_REQ. From then on, the SoC starts sending only some of the frames, others are omitted. Why should this command produce this behaviour?

I'm using SDK v7.1.0 with S310 softdevice. I attach the sniffer capture if that helps.

Thanks!

Nexus5.pcapng

[Hung Bui]

@elgogi: Could you explain on the observation that after LL_CHANNEL_MAP_REQ there are some packet missing ?

I couldn't find that in the sniffer trace, the channel hopping was jumping correctly.

I saw that the disconnection was from the phone side, when notification was sent and acked until it is disconnected.

Which app did you use to test the device, have you tried to use the Master Control Panel app?

[elgogi]

Thanks for the quick reply. If you check the notification value, you will see that the first digit is a frame counter that goes from 0 to 63 and so on. Before receiving LL_CHANNEL_MAP_REQ every notification value comes with this consecutive counter correctly, but after receiving it there are some notifications missing.

This is tested on a Nexus 5 (Android 5.0.1) with nRF UART app and also with nRF Master Control Panel app with the same result. However, a Nexus 4 (Android 4.4.4) hasn't got such issue as it is not sending the LL_CHANNEL_MAP_REQ.

No problem about disconnection, I did it on purpose on the phone side.

[Hung Bui]

@elgogi: This meant there was no missing packet on BLE link itself. The missing notification values was most likely because the packet wasn't queued in the transmission queue because the queue was full for example. Have you checked and make sure you only increase the counter if the call sd_ble_gatts_hvx() returns successful (NRF_SUCCESS) ?

[RK]

I don't think it's the channel remap which is the event causing the start of these missing packets. If you look a little before that you'll see the slave requests a connection parameter update with an interval of 500-1000ms. The master replies and sets the interval to 1000ms, 1s. Before that, the connection interval is 50ms (40 x 1.25), much shorter.

If you change the left-hand column of wireshark to show delta time the pattern gets easier to see. Each connection interval there's a burst of packets, each one from the slave has the 'more data' flag set showing it has more to send and the packets are 3-4ms apart, however after 4 or 5 packets that's the end of that connection interval and there's nearly 1s gap before the next connection because the connection interval is now very long.

So - as Hung Bui points out - if you are continuing to write notifications at a high rate then either the queue is full and they are just not queueing, or, since notifications are not guaranteed the spec allows the softdevice to throw them away (I have no idea if Nordic's SD throws them away or just stops queueing new ones, the effect is similar either way).

So I'm pretty sure the gaps you're seeing are because of the 20x increase in connection interval, which the slave (nrf51422) requested. It just happens that the channel remap occurs right around that time but I think that's just coincidence. You're getting bursts of 3-5 packets and then a huge gap in time.

[elgogi]

Thanks! Adapting the interval values (I think you cannot increase the queue size on ble_nus) it can work fine.