Async Serial does not call HLA with correct bytes

Extensions
1

The Async Serial is set up to decode a 9 bit protocol with a 9th bit indicating an address.

image
image512×574 28.2 KB

This works fine and the bytes are decoded correctly ( Green in image ), but when they are fed to my HLA, they are something else…?!? (last gray printouts show the green bytes, image was cut a bit)

image
image1216×593 28.6 KB

0x11 is 0x11 (adress)
0x33 is 0x03 (WRONG!)
0x81 is 0x81
0x00 is 0x00
0x63 is 0x0C (WRONG!)
0x95 is 0x95
0x03 is 0x03
0xFA is 0xFA

Code in my HLA ( built upon the example, som extra code has been removed to protect company):

   def decode(self, frame: AnalyzerFrame):
        print(frame.data)

Any suggestions?!?

2

Thanks for reporting this! I don’t think we ever tested MDB mode with HLAs!

We will need to look into this more closely.

A quick scan of the analyzer source code, it does look like we remove the MSB from the data before adding it to FrameV2 for HLAs here:

However, I think we need to adjust the number of bits per transfer before we add the data to the FrameV2 object here:

I’ll need to take a closer look, could you save a capture and send it to us, so we can load it into the software over here and take a look?

3

Salea_9_bit_HLA_problem.sal (3.8 KB)

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.

Salea_9_bit_HLA_problem_settings_for_async
Salea_9_bit_HLA_problem_settings_for_async534×594 28.6 KB

Salea_9_bit_HLA_problem_withouth_HLA
Salea_9_bit_HLA_problem_withouth_HLA1917×544 52.1 KB

4

Thanks for the details! I found the issue and fixed it. I’ve attached a build of the fixed windows analyzer.

serial_analyzer.zip (24.5 KB)
The fix was very simple, you can see it here:

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:
image
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.

5

Hi, I’m back to work and I swapped the old serial_analyzer.dll for the new one. The 0x33 is still reported as 0x03…

received: b’\x11’
Start of packet with address: 11
received: b’3’
received: b’\x81’
received: b’\x00’
received: b’c’
received: b’\x95’
received: b’\x03’
received: b’\xfa’

6

@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)
  • ‘c’ = 0x63 (‘c’ ASCII converts to 0x63)

I hope that makes sense!

7

… my mistake. Thanks! I thought I knew this :wink:

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
else:
  ch = b'\x00' + frame.data['data'] # New HLA interface and we only get one byte
print('received:',ch.hex())
1 Like