Reason behind CRC error

[Nivetha]

Hi!

I am sorry if I had repeated questions in this forum. I would like to understand few things.

Test scenario

Central - nRF52840 Peripheral - nRF52840 Bluetooth 5.0 Connection interval - 10 ms Data - 10 samples/10ms as notifications Sniffer - nRF52 Dk(with unofficial sniffer fw)

I have few questions after observing the nRF sniffer with Wireshark log

The markers indicate the data with the CRC error. My understanding from the log is that samples sent as notifications are retransmitted until it is ACKed by the peer or until its CRC ok.(This has been repeated several times)

• Does the CRC error indicate that the packet( from the TX) is already faulty or unable to reach the receiver or NACKed by the receiver?

• Or Is this due to the usage of unofficial firmware sniffer?

Thanks in advance for solving these questions.

Nivetha

[endnode]

I believe that CRC errors are only on Sniffer's side (sniffer has no idea what is actual Rx peer seeing at that moment;). So I'm afraid it's just consequence of using cheap sniffer in sub-optimal topology and doesn't necessary indicate real error of packets in the air... If there would be real packet loss on some side and re-transmission you should see that from SN/NESN sequence (see slides 115 and 117-118 of this presentation).

[Nivetha]

Yeah, you are right:) I see that SN and NESN are different for packets with CRC error. More likely because of using an unofficial sniffer.

[endnode]

Noooooo, unofficial means that it might be crashing or exhibiting other severe problems because it was untested and isn't officially supported. But it shouldn't degrade receiving capabilities just by FW. Believe me this you will see with "official" sniffer on nRF51 DK board also, simply you need to have very good placement of all 3 devices and almost no interference to have 100% of success in sniffer's trace. That's life.

[Nivetha]

When the SN and NESN values are different, it denotes that the previous packet is ACKed. But while observing the logs, it's not how it behaves. It still shows CRC error and being retransmitted. Isn't that contradictory?

[endnode]

Not sure that I can follow. SN and NESN are ticking in special sequence like (0,0), (0,1), (1,1), (1,0) and so on. If you see two packets with the same (SN, NESN) then it means re-transmit. Sure if there is some real interference on the radio it's probable that both receiver and sniffer will detect it as some kind of error (CRC or even preamble not match).