BLE sniffer detects different packets in Wireshark than nRF Connect BLE tool log file

[aarnaizz]

Hello! My link configuration is:

TX: STM32WB15CC notify at high rate: one 251B frame per 3ms

RX: BLE sniffer dongle nRF52840

I'm having trouble to detect lost packets in my connection. On one hand, I am using one sniffer to get the notification of the packets by the provided log file in the nRF Connect BLE app. This way, if the transmission is successful, I get no errors and 0 packets lost. On the other hand, if I sniff the connection through another sniffer with Wireshark connected to the same PC or other PC, I get different packets received, as there are way more errors and retransmissions that occasionally end in lost packets.

However, the packets that seem apparently lost in Wireshark are actually received in nRF Connect, so the sniffer in Wireshark seems not to be working well. Why is this? What can I really trust about the frames in Wireshark?

[aarnaizz]

Example:

wireshark 1

wireshark 2

log

My sent scheme consists on a sequence of numbers in each frame, sent 3 by 3.

It can be noted that wireshark does not seem to get the packets between the two selected ones in the images, while the log file does show them. Furthrmore, in the next packets shown by Wireshark, there cannot be found any retransmissions of these packets.

[Edvin]

Hello,

I am not sure what I am looking at here. Do you claim that the link is sending more data than the device receives?

How do you get data from your nRF into Excel? I understand that you copied something, but where did you copy from?

What do you want to show me with the wireshark screenshots?

Are you trying to say that you are missing packets in the actual connection, or that the two sniffer traces show different data? 

Best regards,

Edvin

[aarnaizz]

Sorry for the misunderstandings!

• From the dongle acting as a receiver, I send a notify to the TX and get the packets with no errors, as you can see in the log file. However, from the dongle acting as a link sniffer with Wireshark, I observe pasket loss, as you can see in the screenshots.
• I copied the data and processed it with Matlab from the log file provided by nRF Connect Bluetooth Low Energy app.
• In the wireshark screenshots, you can see that some packets that the nRF Connect Bluetooth Low Energy app got into the log file are missing. Also, the second packet shown in Wireshark has an incorrect CRC, while the log file shows a perfect frame arrival.
• I am trying to say that the two sniffer traces show different data, indeed.

I hope now the information is clear.

Thanks!

[Edvin]

You know that you don't need to send these long packets with all 00's. You can set the length of each packet before you send it. 

What I see from the wireshark traces is that one notification holds several 0x48__ values, is that correct? Also, it looks like they end with 48, while the values from your excel starts with 48. Why is that? Perhaps it is a 48 from an earlier packet, and you didn't clear the buffer before sending it? Either that, or you didn't set the correct length, and the leftover 48 is from a previous packet? It is still unclear to me what data you actually received and pasted into your matlab script. But it isn't really that important. 

The CRC may be wrong in a sniffer trace (Wireshark). It just means that the sniffer didn't pick up the packet correctly. It could be a single bit error. The sniffer is not always a 100% representation of what's going on. If the actual receiver of a packet receives a CRC error, the packet will be retransmitted. But the sniffer doesn't affect the BLE link itself, so it will not trigger any retransmissions. In fact, the BLE link is unaware that there is a sniffer picking up the packets at all. The sniffer will just do it's best to show you what happens on the air. Also, longer packets will increase the probability of the occasional crc error, because there are more bits that can be received incorrectly. 

aarnaizz said:

I am trying to say that the two sniffer traces show different data, indeed.

I would say that this is not unexpected. Bit errors on air are not uncommon. In fact it is quite common, which is why most (almost all) wireless protocols have mechanisms of picking up bit errors/crc errors, and retransmissions.

Best regards,

Edvin

[aarnaizz]

Thanks for the reply!

Just for making it clear, I'm sending extra 0s just because I'm testing the link with 247B payload data because it is what I am actually going to send in reality. 

Regarding the sequence of numbers I'm transmitting, the bytes in the excel are reversed compared to the Wirehark bytes, but as you say, is not really relevant.

Okay, I had previously hear that the sniffer was not 100% accurate, but thank you a lot for the retrasnmission explanation. I think now it is more clear.

Regards, 

Álvaro.

[Edvin]

No problem

Yes. The sniffer is a great tool for debugging, because in most cases it will pick up everything. And even if the CRC is wrong, most of the packet will still be correct. But it is a passive listener, so the connected devices are not aware of it.

BLE itself, between two devices, is lossless. This does not mean that packet loss will not occur, but it means that all packets will be retransmitted until they are acknowledged. So the only way a packet is discarded is if the two devices are no longer able to communicate, but this means that the link will be disconnected (and you will see the disconnected event in your application). 

Best regards,

Edvin