Mavlink is usually transported using serial connection, so the Saleae Logic will already “see it”
With the headers at https://mavlink.io/en/
it should be trivial to “understand” the package, type, sequence, verify the checksum.
Do a protocol plugin also need to detect baudrate start/stop bits etc, or could the custom protocol just use the binary data already decoded as a serial stream ?
Also, such plugin would somehow do the same thing as the native serial handling, how would that go ?
One way that I wish was possible to handle it, would be for the custom protocol pluging to just recieve the bytes, and then, if it detected known protocol, it could return annotations/labels.
how big a project would it be to properly show MAVlink ?
We’re not too familiar with MAVlink, but based on my quick reading of the protocol, it looks doable. Assuming I’m not missing anything crucial, this could be implemented by starting with our Async Serial Analyzer codebase. It’s hard to say how long this project will take without much knowledge of MAVlink. Assuming you have a working knowledge of C++ but have no experience with our SDK, we’ve seen customers implement a working analyzer in about 1 week, but this varies depending on complexity.
First, I would ensure that our ‘Async Serial Analyzer’ can properly decode your MAVlink stream. If so, then you have a good starting point, and you can simply take the data that is already decoded by the Async Serial Analyzer and convert it to display in a way that is meaningful to MAVlink.
Our Async Serial Analyzer has an “auto-baud” feature already implemented, or you can also manually set the baud rate. Currently, Start and Stop bits are implemented as ‘0’ and ‘1’ respectively. Also, the number of bits per data message is a fixed number, so if MAVlink changes their bit length depending on the message, then the code will need to be modified further.
Source code and setup instructions below:
https://support.saleae.com/saleae-api-and-sdk/protocol-analyzer-sdk
Feel free to send me an email (support@saleae.com) in case you need help getting started. I’m happy to walk you through it in case you run into trouble.
By the way, thanks for the idea below:
“One way that I wish was possible to handle it, would be for the custom protocol pluging to just recieve the bytes, and then, if it detected known protocol, it could return annotations/labels.”
Auto protocol detection is certainly on our radar. We will start exploring with this idea once we get our Alpha software to a stable release.
I work with many different Async protocols.
the Saleae logic does properly detect/display all of them as serial data.
Autobauding works.
However, I did see more “framing errors” using that than when just entering the baud-rate.
Another feedback would be to disable baud input field (textbox) when autobaud is checked.
Some of the protocols I work with have unusual space between bytes, some are half-duplex, and so on, but all are read just fine.
The ultimate protocol-dialect-detection would be to be able to add some logic when handling the bytes you already decoded with the following logic:
if certain byte(s) in row : then label those in GUI as “something”
if preceeding_idle_time_was > ms and byte_1 is “5” then…
basically: to be able to recognize data-patterns, abd use some of the bytes for variables, creating labels and tags based on actual data.
Finally: the search feature can search for 0x10 , but only one byte at a time … it would be useful to search for multiple bytes in a row.
Thank you.