Time-based frame-delimiting about min HOT 4 CLOSED

SOF/EOF doesn't work well if it's possible to start receiving part-way through a message: you then possibly erroneously decode a payload as a frame start, and then not synchronise properly. That's why it uses an escaping mechanism in the payload - i.e. character stuffing - so that the framing is clear.

The timing mechanism for framing requires much more intrusive drivers to access those timers on the embedded side, and on the host side it's almost impossible to get such fine control over timing with a desktop OS (eg like Windows).

MIN is designed to be "low touch" and require nothing more than a serial port, which makes it fit any host and any embedded device (either a USB serial system like TinyUSB or a UART that feeds into a serial-USB converter cable, which are easily available for PC-based hosts).

from min.

Thanks for your response, Ken! Totally agree about the disadvantage of needing fine timing control with the time-based synchronization approach. And I must confess, I didn't even think about the PC-side of things because of my working within an MCU-to-MCU context (woops).

It would seem that I should reconsider pursuing this as the payoff might not be all that much. The reason I began to look into it is that my co-worker pointed out a disadvantage of having a lot in the header (SOF x3, ID, Sequence, Length). The more there is in there, the more likely a bit error can occur in the header, resulting in the whole frame being discarded, even if the payload was intact. A time-based delimiter would be more impervious to bit errors than, well, bits.

That being said, I don't actually have experience using MIN to confirm this theory about the header posing this problem. Feel free to shoot that down if your experience says otherwise :) In my application, the UART line is crossing an isolation barrier which introduces considerable noise into the picture.

from min.

There's usually a trade off between throughput and robustness. If you're dealing with a link that's very noisy then maybe Forward Error Correction is the way to go: extra bytes are added to correct errors, like Vitterbi codes. I don't think an embedded microcontroller can deal with the advanced codes, but a simple Hamming code could work.

Also the header should really get its own CRC: it's a common design error (that MIN, CAN and many others make) where the length code can get corrupted, causing the main CRC to be read from the payload, overwhelming the Hamming distance. So a new MIN with FEC would also have a small header CRC.

FEC adds overhead, of course, so it's only appropriate on noisy channels or ones with high latency - which is why it's used on spacecraft. But if kept optional it would be a useful feature. You would need to see how many errors you normally get to pick the right code, but something like the 72/64 Hamming code use for error correcting RAM might be appropriate, and only cost 1 additional byte per 8. Worth thinking about.

from min.

Thought about FECs, but wasn't sure if they were suitable in an embedded, resource-constrained context. Didn't see them in any existing protocols' frame designs. Was thinking about "streaming" (#33) redundant data over to correct for errors, sort of like a repetition code, instead of using FECs.

Same deal with a header CRC: I only saw one protocol, and not a standard one at that, which implemented this. This led me to think that it might be overkill in a MCU-to-MCU situation perhaps, seeing as how it was almost never used.

Thanks for the insight and ideas. I'm starting to appreciate how tricky protocol design can be, haha.

from min.