mirror of
https://gitee.com/mirrors_PX4/PX4-Autopilot.git
synced 2026-04-14 10:07:39 +08:00
bae275898b
Instead of directly passing the next packet to the parser after successful parsing, switch the state to SBUS2_DECODE_STATE_SBUS_START and search for the start byte again. The timeout is increased as the IO main loop also takes a bit of time (max ~0.7ms). Tested on v5x with Futaba R7008SB (60Hz update rate) and FrSky X8R (111Hz update rate). Background: When using the Futaba R7008SB, I noticed there's additional bytes added in between packets. Often it's a null byte, but sometimes more. There's some consistency but I did not find any documentation for it. Sample data: a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 c0 8b 00 0f 04 ec 1f a8 fb 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 04 ec 1f a8 fb 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 05 ec 1f 30 60 bf 1c bd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 07 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 03 c0 31 00 0f 05 fc 1f a8 fb 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 05 fc 1f a8 fb 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 0f 04 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 04 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 03 c4 00 00 0f 04 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 04 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 0f 04 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 03 c0 31 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 05 fc 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 0f 05 fc 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 03 c0 31 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 05 f4 1f a8 fb 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 03 c4 00 00 b0 60 7f 1c bd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 05 ec 1f a8 fb 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 03 c0 31 00 b0 60 bf 1c bd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 04 f4 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 30 70 7f 1c bd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 34 00 0f 05 f4 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 04 00 03 c4 00 00 0f 05 fc 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 05 ec 1f b0 60 bf 1c bd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 14 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 01 08 40 00 02 10 80 00 24 00 0f 05 ec 1f a8 fd 07 16 5b 81 05 d4 a0 06 20 00 This was causing the parser to skip entire packets resulting in an update rate of ~31Hz on the FMU side. With this patch the update rate increases to 42-48Hz. The investigation was triggered by an RC glitch with a packet containing random channel data. It's likely, although not completely verified that the frequent desync randomly happend to pass the CRC check with garbage data.