How to capture BLE packets with CRC errors on nRF5340? (Accessing raw payload like nRF Sniffer)

[qwessr]

I have a question regarding the nRF5340. I would like to capture and access the raw payload of BLE packets that fail the CRC check.

I know that with the nRF52840 (running the nRF Sniffer firmware), we can visualize these "bad" packets in Wireshark. I want to achieve similar functionality on the nRF5340 for a specific debugging application.

Could you please guide me on the required development steps?

Since the radio is on the Network Core, does this require writing custom firmware for the Network Core (bypassing the standard SoftDevice Controller)?

Is there any existing example or configuration in the nRF Connect SDK (NCS) that allows passing packets with CRC errors from the Network Core to the Application Core?

[Hung Bui]

Hi Qwessr, 
The current implementation of our BLE softdevice is that the packet is discarded when there is a CRC error. I don't think it's possible for the application to get the packet when CRC is failed. 

The reason the nRF Sniffer can capture CRC failed packet is that the nRF Sniffer doesn't use the softdevice and simply use the RADIO to capture raw packet and process the packet without the softdevice. 

We unfortunately don't publish the code for the NRF sniffer so if you want to achieve something similar you will have to write your own code to scan and process BLE packet (as a sniffer, not as a peer device in BLE, otherwise you are talking about making your own softdevice). 

Or you can think of using Zephyr BLE controller, then it's possible to access the code (it's open source) and add  your own code to extract the CRC failed packet. If you go with this direction, you may need support from Zephyr as it's not our code. 

[qwessr]

Thank you for the explanation.

I am currently using the nRF5340 Audio DK. Could you please confirm if it is feasible to modify the Zephyr BLE controller to achieve this functionality on the Audio DK? Or is it necessary to switch to the nRF5340 DK?

[Hung Bui]

Hi Qwessr, 
If your code already run on the nRF5340 Audio DK , I don't see a reason why you need a nRF5340 DK. But you need to double check if the Zephyr BLE controller can be used for the Audio DK. I'm not so sure that the Zephyr BLE controller can do LE Audio on the nRF5340. 
Could you let us know why you want to access the raw payload when CRC is failed ? Which application is that ? 

[qwessr]

I am sending simulated BLE packets via SDR, which are received well on the TI CC2652. However, there is a noticeable packet reception rate issue when using the nRF5340 Audio DK (the reception rate decreases as the packet length increases). Therefore, I want to obtain CRC error data to investigate where the problem lies.I only need it for debugging; the LE Audio feature is not required.

[Hung Bui]

I see, as I mentioned we don't make the Zephyr Controller so I don't know how exactly you need to modify it to access the CRC error. You will have to explore the controller code for that. 
You may want to use a DK to compare the reception rate. 
Maybe you can use the sniffer as well, to see if the sniffer also report CRC failed packets. I guess it would be the case if the environment is really noisy. But I don't know why CC2652 can receive well when the nRF5340 has a significant packet drop.