What does happen when corrupted data is received

[Clonimmus74]

My configuration:

• IAR V8.22
• Custom board with nRF52832
• Softdevice V6.0.0
• SDK 15

I understand that BLE uses, in the link layer, CRC to verify packet integrity, and drops the packet if is it corrupted. We also use encryption so there's the Message Integrity Check as well.

We did some EMC tests, and when we apply noise at the 2.4GHz band we received corrupted data (we stream data values of up to 22 bit (using uart profile), and we sometimes receive data much higher (32 but values) when the noise is applied). Can it be that the CRC in the link layer and Message Integrity Check are not enabled?

thanks

[bjorn-spockeli]

Hi Igal, 

So you are transmitting data consisting of 22-bit values , but you are receiving 32-bit values? So each 22-bit value consists of  four 8-bit bytes, where the last two bits of byte 3 and entire byte 4 are flipped from 0s to 1s ?

Do you have a on-air trace from a Bluetooth Protocol Analyzer that shows this behavior? 

Can it be that the CRC in the link layer and Message Integrity Check are not enabled?

The CRC is a part of the Bluetooth Packet PDU and cannot be disabled( at least not with our SoftDevices), the MIC will as you have stated be included if the link is encrypted. 

A on-air trace of the data would be very helpful. 

Best regards

Bjørn

 

[Clonimmus74]

Unfortunately I don't have on-air trace capabilities.

It's not that the 3rd and 4th bytes are flipped. We send data from our sensor (22 bit signed values), and during the EMC test, as described, we sometimes see spikes in the data, where the data is beyond the sensor capabilities.

the spikes seem random (their values) but appear in some interval, probably in relation to the interference interval done by the testing lab.

If you say that the CRC and MIC cannot be turned off, can I be certain that the interference influences the data after it is received by the receiver i.e. data corrupted in the air will never pass to my application?

[bjorn-spockeli]

Clonimmus74 said:

t's not that the 3rd and 4th bytes are flipped. We send data from our sensor (22 bit signed values), and during the EMC test, as described, we sometimes see spikes in the data, where the data is beyond the sensor capabilities.

 Ok, understand. 

 

Clonimmus74 said:

If you say that the CRC and MIC cannot be turned off, can I be certain that the interference influences the data after it is received by the receiver i.e. data corrupted in the air will never pass to my application?

 If the CRC sent with the packet does not match the CRC calculated by the RADIO peripheral on the NRF device, then the SoftDevice's ( i.e. Nordics BLuetooth protocol stack) Link Layer will not acknowledge the package and the peer will retransmit the packet until an ACK is received, see 4.5.9 Acknowledgment and flow control in the BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B, page 2790. 

Invalid CRC matches will not be propagated to the application layer by our SoftDevice. 

[Clonimmus74]

Thank you very much