OTA DFU CRC check taking too long

RE: OTA DFU CRC check taking too long

bjorn-spockeli — Wed, 03 Oct 2018 07:35:49 GMT

I was referring to the nRF5x SDK used on the Nordic side, not the Android SDK.

You can use the nRF Sniffer SW + a NRF52 DK/nRF51 Dongle to capture a sniffer trace of the on air packets, see the nRF Sniffer page on our site for more information and download of the sniffer FW.

Make sure that you use the nRF-Sniffer-v2 firmware. The use of the nRF Sniffer is covered in the nRF-Sniffer-UG-v2.

Best regards

Bjørn

RE: OTA DFU CRC check taking too long

Aleksandar Kahriman — Tue, 02 Oct 2018 15:15:49 GMT

Hello Bjørn,

Thank you for the quick reply. I am not sure which connection interval am I using nor am I sure weather I can extract that information from the Android SDK. The client is a Google Pixel II phone if it means anything to you. BLE packet size is 20 bytes, so I'm sending 4kB 20 bytes at a time, which takes me less time than the CRC command (0x03). As for SDK, I'm not using any SDK since no SDK exists for Xamarin, but I took special care to implement the protocol the same way you guys did in your Android SDK.

Can you please explain to me how to capture a sniffer trace of the on air packets?

Best regards,

Aleksandar

RE: OTA DFU CRC check taking too long

bjorn-spockeli — Tue, 02 Oct 2018 15:01:19 GMT

Hi Aleksandar,

which SDK version are you using? Which connection interval are you using?

1.5 - 2 seconds for calculating the CRC of a 4kB chunk sounds way to much. The 4kB chunk will be divided into smaller chunks that will fit inside the MTU of the bluetooth packet. The CRC of each of these packets will be calculated on the fly, so when the 0x03 command is sent to the DFU target, the CRC calculation should be ready.

Would it be possible for you to capture a sniffer trace of the on air packets?

Best regards

Bjørn