openthread: [nrf52840] CSL transmission fails when using a dongle as CSL Transmitter and a DK as CSL Receiver
Describe the bug For some reason, I’m using a nrf52840 dongle as CSL Transmitter and a nrf52840 DK as CSL Receiver. When I ping from the Transmitter to the Receiver, it fails. (The Receiver didn’t receive it and there’s no ack.) However it can work in the opposite way: If I ping from the Receiver to the Transmitter, it works. And the Receiver can receive the ping reply. I also tried using 2 dongles and 2 DKs. In both cases the ping succeeded.
Here is a pcap, the time of failed CSL transmission seems correct to me:
To Reproduce Information to reproduce the behavior, including:
- Git commit id: 4538a5f
- IEEE 802.15.4 hardware platform: nrf52840 DK(PCA10056 v1.1.0), dongle (PCA10059 v1.0.0)
- Build steps
Dongle:
OT_CMAKE_BUILD_DIR=dg_build ./script/cmake-build nrf52840 USB_trans_bl -DOT_THREAD_VERSION=1.2 -DOT_CSL_RECEIVER=ON
arm-none-eabi-objcopy -O ihex dg_build/examples/apps/cli/ot-cli-ftd ot-cli-ftd.hex
nrfutil pkg generate --debug-mode --hw-version 52 --sd-req 0 --application ot-cli-ftd.hex --key-file private.pem ot-cli-ftd.zip
DK:
OT_CMAKE_BUILD_DIR=dk_build ./script/cmake-build nrf52840 UART_trans -DOT_THREAD_VERSION=1.2 -DOT_CSL_RECEIVER=ON
arm-none-eabi-objcopy -O ihex dk_build/examples/apps/cli/ot-cli-ftd ot-cli-ftd.hex
Any idea for the problem? @edmont @hubertmis Is it possible that this is caused by the different versions of hardware?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 24 (24 by maintainers)
It seems dongle clock drifts from the sniffer clock back ~10 us per 1s (10 PPM, it’s within tolerance). For the successful transmissions (no 23, 28), the transmitter is a little too late (a number of dozens of microseconds, within tolerance). However, the transmitters clock keeps drifting and if you wait long enough, it transmits the frame earlier than expected. Frames 30-33 are transmitted ~80 us too early, and frames 46-49 ~490 us too early.
I would verify if CSL receiver is prepared for too early transmissions. If receiver would be enabled just before expected transmission (without taking into account the transmitter drift), the result would be exactly what you observe.
Also, to verify timings of CSL receiver and transmitter, you can play with debug gpio mode in the radio driver and verify with a logic analyzer when receiver opens its window and when transmitter transmits the frame.