You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When reading CRTP packets from the Crazyflie 2.1+ using BLE shortly after booting the drone, I experience two issues:
The first 7 CRTP packets contain only null bytes
All other CRTP packets that were too big to fit in one BLE packet are malformed
The second split packets have their first byte cut off, and an extra junk byte appended to the end. This would seem to point to an off-by-one error in the nRF firmware, but it appears correct to me.
Additionally, it looks like the packet splitting procedure is not implemented in accordance with the documentation. Namely, it only sets the start and length bits in the first packet's control byte (it does not set the pid bits), and it does not clear the start or length bits in the second packet's control byte. It seems like the previous version of the firmware set the control byte correctly though.
Here is a partial dump of the packets I receive after boot:
If I reboot the STM only (but not the nRF) by sending the SYSOFF and SYSONbootloader commands, I get the expected packets after boot, but they are still malformed:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
When reading CRTP packets from the Crazyflie 2.1+ using BLE shortly after booting the drone, I experience two issues:
The second split packets have their first byte cut off, and an extra junk byte appended to the end. This would seem to point to an off-by-one error in the nRF firmware, but it appears correct to me.
Additionally, it looks like the packet splitting procedure is not implemented in accordance with the documentation. Namely, it only sets the
start
andlength
bits in the first packet's control byte (it does not set thepid
bits), and it does not clear thestart
orlength
bits in the second packet's control byte. It seems like the previous version of the firmware set the control byte correctly though.Here is a partial dump of the packets I receive after boot:
If I reboot the STM only (but not the nRF) by sending the
SYSOFF
andSYSON
bootloader commands, I get the expected packets after boot, but they are still malformed:Is anyone else experiencing this issue?
Beta Was this translation helpful? Give feedback.
All reactions