Thank you @auturgy and @j_p for your replies, this helps.
One of the missing pieces for me was the confirmation of mavlink framing, which I had suspected. Perhaps I was naively/silently hoping that some “official” or “internal” documentation on this existed.
More context on what I’m looking at: I’ve been able to successfully generate and send to the FMU my own mavlink OBSTACLE_DISTANCE messages before, but now I’m running into issues reliably reading the telemetry serial data stream using three-wire connection to Raspberry Pi. Using mavlink_frame_char to decode the messages and to find message boundaries I was only able to mostly reliably “see” HEARTBEAT and TIMESYNC messages, most likely because of their short length. I had confirmed it wasn’t a baud rate mismatch, and made sure the serial read is non-canonical. I’m wondering if it was due to some sort of noise, a timing (burstiness) issue which requires more sophisticated buffering, additional envelope information in the byte flow which I was missing, or something else - thus my post.
Have you run into this kind of initial issue with being able to reliably read/parse incoming serial telemetry data from the FMU (on Linux)? Is the three-wire serial connection (no flow control) the issue here?
