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).

[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.