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

[Karin_Bøe]

Suppose you want to send 20 bytes of data using API sd_ble_gatts_hvx, do you need to punctuate the first 16 or so data within the 20 bytes sent with a CRC ?

it may seem unnecessary as BLE stack in itself is quite reliable, but I'm still puzzled by these few lines found within the BLE stack specification:

3.1 ERROR CHECKING At packet reception, the Access Address shall be checked first. If the Access Address is incorrect, the packet shall be rejected, otherwise the packet shall be considered received. If the CRC is incorrect, the packet shall be rejected, otherwise the packet shall be considered valid. A packet shall only be processed if the packet is considered valid. A packet with an incorrect CRC may cause a connection event to continue,

and:

The slave shall always send a packet if it receives a packet from the master regardless of a valid CRC match, except after multiple consecutive invalid CRC matches as specified in Section 4.5.6

My understanding is that the communication should have a zero-tolerance policy regarding wrong CRCs, or else it's meaningless, upon receiving a mismatching CRC, either slave or master shall inform the other by either sending a control packet of some sort, or stall the comm and cause the entire established link to start over. The quoted paragraphs of the specification makes it look like as if it is necessary to have a CRC at a higher level. May be I'm misinterpreting all of this?

[RK]

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.

[Karin_Bøe]

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"

[Øyvind]

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.

[Karin_Bøe]

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