Reason behind CRC error

RE: Reason behind CRC error

endnode — Wed, 09 Aug 2017 08:55:37 GMT

Yes, if SN/NESN sequence goes on as expected but sniffer reports any error on the packet then most probably it is just its problem with reception.

RE: Reason behind CRC error

Nivetha — Wed, 09 Aug 2017 08:38:58 GMT

I have seen samples where SN and NESN values are different(then it must have been ACked) but their CRC is not OK. Then this might be due to interference.

RE: Reason behind CRC error

endnode — Tue, 08 Aug 2017 14:56:51 GMT

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

RE: Reason behind CRC error

Nivetha — Tue, 08 Aug 2017 14:32:17 GMT

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?

RE: Reason behind CRC error

endnode — Tue, 08 Aug 2017 14:24:13 GMT

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.

RE: Reason behind CRC error

Nivetha — Tue, 08 Aug 2017 13:18:24 GMT

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.

RE: Reason behind CRC error

endnode — Tue, 08 Aug 2017 10:03:18 GMT

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