added checksum escape

[alxwk]

I found an interesting thing in the protocol (maybe it was just added recently).

If the final checksum byte of a message equals 0x7e, it needs to be "escaped" by doubling it.

Examples I've captured with Wireshark under Win10:

84831   38.381411       host    3.18.2  39      7e063f171a013d3f00007e7e
[...]
100486  44.386961       host    3.18.2  50      7e063f171a013d3f00007e7e7e062d13f53100000000f7
[...]
165201  65.711808       3.18.2  host    52              7e078e2100000b000000327e7e7e078e910000060000001dd4

So, for example, in the last reply the device 0x12 answers with the message having the checksum==0x7e, it gets doubled, and then follows the next message from the device 0x19, resulting in three 0x7e in a row.

(I learned about it the hard way — as I'm making a telemetry utility, I accidentally stumbled upon the telemetry combination resulting in a message having this checksum, and after sending it as is, without doubling, the wheel started to behave strange, RPM LEDs falling into some sort of "idle mode". Took me a couple of days to figure it. Honestly, it's not the brightest handling of a communication protocol by Moza developers, but oh well...)

[Lawstorant]

Hmm, I need to test this a bunch more as it doesn't make 100% sense to do this. The header already contains the message length so we easily know when 0x7e is a start of a message or just part of it.

[Lawstorant]

I found a few settings that create such checksum but try as I might, it always works properly.

[alxwk]

Well, in a case of boxflat as an utility which only uses the serial for settings change once in a while, it may be not much important. In my case of a telemetry app with a constant serial exchange any discrepancy can be noticed pretty quickly. I filled this PR mostly just as a heads-up, if someone hits the same situation as I did. I agree that such "escaping" is not necessary for any sensible handling of a serial protocol, but apparently Moza developers (or a LLM they use) think otherwise.

[giantorth]

Here's what I've figured out at this point.... when a frame's computed checksum equals 0x7E (the start-of-frame marker), the sender doubles it on the wire and transmits 0x7E 0x7E instead of a single 0x7E. The receiver then must consume the extra byte after reading a frame checksum of 0x7E. Without this, the escape byte is misinterpreted as the start of a new frame, desyncing all subsequent parsing.

This applies to both directions (host -> device and device -> host)

Host → device:  7e 06 3f 17 1a 01 3d 3f 00 00 7e 7e
                └── frame (cksum=0x7e) ──────────┘ └─ escape byte

Three 0x7E in a row (escaped checksum + next frame start):
Device → host:  7e 07 8e 21 00 00 0b 00 00 00 32 7e 7e 7e 07 8e 91 ...
                └── frame 1 (cksum=0x7e) ────────┘  │  └── frame 2 ─
                                              escape ┘

In the three-7E case, the first 7E is the checksum, the second is the escape, and the third is the start of the next frame.

[alxwk]

Here's what I've figured out at this point....

Yep, that's exactly what I wrote. Maybe my English isn't too good (despite being C2 at tests, lol).

Usually, it's a pretty rare condition (1/256 probability, obviously), but when I stumbled upon it in my telemetry configuration, it almost has driven me mad. The LED just didn't light no matter what.

[giantorth]

Yep, that's exactly what I wrote. Maybe my English isn't too good (despite being C2 at tests, lol).

Somehow I misread your PR to say it was doubling the message itself a 2nd time, took me a while to wrap my head around what was going on. I've been seeing these values plenty when trying to add support for dashboard displays in another codebase with the high traffic rate of messages being exchanged.