Is it at all necessary to integrate CRC when using notification?

RE: Is it at all necessary to integrate CRC when using notification?

Karin_Bøe — Wed, 03 Feb 2016 02:05:00 GMT

Thank you Øyvind, your tortuous way of pointing out the lack of professionalism in my phrasing is duly noted.

RE: Is it at all necessary to integrate CRC when using notification?

Øyvind — Tue, 02 Feb 2016 07:36:03 GMT

The Core Specification is not a description of how implementations of the protocol stack works, but rather a set of instructions for the protocol stack implementers.

"A packet with an incorrect CRC may cause a connection event to continue, as specified in Section 4.5.1." contains direct instructions to the implementer (taking the reference into account) and is not just a hint of what may happen.

"It is possible that a packet with an incorrect CRC doesn't cause a connection event to be terminated" sounds more like a description to a bystander of what happens, which is not the intention of the spec.

RE: Is it at all necessary to integrate CRC when using notification?

Karin_Bøe — Tue, 02 Feb 2016 05:56:47 GMT

I see. So the wording of the document is misleading. Instead of "A packet with an incorrect CRC may cause a connection event to continue" it should have said " It is possible that a packet with an incorrect CRC doesn't cause a connection event to be terminated"

RE: Is it at all necessary to integrate CRC when using notification?

RK — Tue, 02 Feb 2016 03:36:55 GMT

You're misinterpreting all of that. A packet with a bad CRC is not passed out of the stack, all this is talking about is how connection events can and do continue even when a bad CRC packet is received, ie just getting garbled data doesn't either break the connection nor does it stop devices continuing to talk to each other.

The back CRC packet however will not be ACKed, will not be passed to the application and will be re-sent until it's received properly or the maximum number of failures occurs at which point the connection will be torn down.