Bi directional UART analyzer with basic packet decoding capability

Hi folks,

When reverse engineering packet based communications over UART it would be handful to have an analyzer which could export the decoded UART data “packetized”.

I am thinking about the following construction:

  • The analyzer would have two input channels.

  • A “packet end” delay could be specified for each channel: if no data received after the packet end delay the bytes recieved considered a “packet” which could be exported as one packet.

  • Both channels could have text input for prefix and the export output would look like this way (> and < symbols used as as a prefix):

    AA BB CC DD
    < 12 42 67 89

I have not found any similar analyzer, however I might overlooked it.

Thanks for letting us know your requirements. This might be possible via a High Level Analyzer extension added to the Async Serial Analyzer. More information on HLAs below:
https://support.saleae.com/extensions

I wanted to gather some more information from you regarding the format you would prefer to be sure if this is possible via an HLA.

Right now, the export format for a single Async Serial Analyzer is shown below as an example:
Screen Shot 2021-03-22 at 4.59.29 PM

Can you provide an example csv/txt file that shows how exactly you would like it to appear? I also don’t quite understand the 2 channel requirement, so if you could go into detail on that, that would be helpful as well.

Can you provide an example csv/txt file that shows how exactly you would like it to appear? I also don’t quite understand the 2 channel requirement, so if you could go into detail on that, that would be helpful as well.

Ah, I see the problem: the code tag eat my brackets.

The HLAs and the old analyzers exports the data byte-per-byte.

However I would like to group the bytes to packets and print the packets line-by-line.

My idea for packet forming is simple: if a byte arrives within a certain amount of period to the previous one (user editable parameter) then it belongs to the same packet if not it is a new packet.

Here is an example of what I used to do:

This is a basic command-response based UART communication which is quite common.

What I would like to see for this one as an output: one line for the command and one line for the response (prefixed with some user parameter). The bytes in the packets are printed with HEX separated by spaces.

In the image above this is the beginning of the R16 TX - STM command packet:

And this is the beginning of the response packet:

My intention to have an export capability in the following way (TX, RX is the user specified “channel prefix”):

TX AA 12 01 D0 ...
RX AA 58 01 07 ...

During reverse engineering I often create traces while applying different circumstances to the target and do diff on the created traces with standard text comparison tools.

If the output is packetised properly it is easier to edit/spot differences/etc.

I also second that this could be a nice feature. For example earlier when I was working with Dynamixel Servos by Robotis, I helped make a low level analyzer that worked with these servos, but this was on one serial line that runs in half duplex. Keep wondering about trying to convert this to HLA…

But currently, I am playing with some new servos by Lynxmotion(RobotShop), which are full duplex, with RX and TX lines running to each of the servos. So again it would be interesting to have an Analyzer that understands the TX and RX packets known by these servos. into one stream.

If I were going to hack it for my own usage, could maybe try something like, have an HLA over each Serial IO channel , that does sort of as you mentioned, that maybe tries to gather all of the information of each packet into one logical unit. Either by timeout, or knowing a little about the packet formats, like they start with XX XX and or have a length field…

Then I would maybe have an output version which dumps these out with a beginning time stamp, some form of identifier like which channel, and then the Serial data…

then if I could output both of them, I could then manually load both of them into text editor and sort by time stamp…

Again not pretty but might get the job done.

@martonmiklos Thanks for describing that. I see what you mean now. @KurtE Thanks for jumping in and providing your thoughts as well.

After thinking about this some more, modifying the Async Serial analyzer itself using our Analyzer SDK and adding support for a second channel may be your best bet.
https://support.saleae.com/saleae-api-and-sdk/protocol-analyzer-sdk

This method would give you more freedom with timeouts, grouping of packets, and export format.

After thinking about this some more, modifying the Async Serial analyzer itself using our Analyzer SDK and adding support for a second channel may be your best bet.

Yupp, that was my idea as well, I just wanted to ask around to make sure that I am not replicating something which is already implemented.

1 Like

In the case if someone would be looking into similar: I have started to work on this here:

It is not yet complete (the bubble display broken at the moment), however the CSV export works.

@martonmiklos Thanks for the update! This is fantastic. I’d love to get this up on our list of protocol analyzers made by the community:
https://support.saleae.com/protocol-analyzers/community-supported-protocols

Once you’ve completed it, let me know if you’re interested in getting your analyzer listed there.

Well I hacked to a state where it hits the usability level in my use case.

Renamed the repository to make it easier to distinguish and find:

This is great, thanks for sharing it! I went ahead and added it to our Community Supported Protocols list below:
https://support.saleae.com/protocol-analyzers/community-supported-protocols