Thanks for looking into it, I think this is the thing I can send you on a public forum (these protocols originate in vending machines payment systems, so they are a bit sensitive to share) In the pictures are the settings, and the correct values that are decoded by Async, but when my HLA receives them, the values are partly different on some bytes. So it sort of works, but not always.
Note, what you saw in the terminal was very, very confusing.
The real problem was that each of those entries contained two bytes instead of one. That’s the only issue I fixed.
However, the default console printer, when trying to print bytes, it will print displayable characters as ASCII, and fall back to “\xXX” for non-displayable characters. 0x33 is the number 3 in ASCII, and 0x63 is the letter C.
This is the new output:
At least this is more clear because it’s no longer mixing hex and ascii on the same line.
Note, if you want to consistently print those as hex, just convert them to hex strings first in python.
@anders.hedberg Sorry for the confusion that causes. By default, our Async Serial Analyzer (and the HLA you are using) outputs characters in ASCII format if the associated hex code prints a valid ASCII character. If a ASCII character does not exist for the particular hex code, it will print it out in hex with the ‘\x’ prefix.
Therefore in your example,
‘3’ = 0x33 hex (‘3’ ASCII converts to 0x33)
\x81 represents 0x81 (printed as such because 0x81 doesn’t represent a valid ASCII character)
For anyone needing to support both new and old HLA this might be helpful:
#To support both new and old Saleae async dll we check what we get
if len(frame.data['data']) == 2:
ch = frame.data['data'] # Old HLA interface and we get two bytes
ch = b'\x00' + frame.data['data'] # New HLA interface and we only get one byte