Improved text message HLA & data formatting question

dennis · January 2, 2021, 3:38pm

I have extended the ‘text messages’ HLA by adding another column in the list of messages which displays messages as hex values.

I needed this because I am analyzing a protocol that sends messages consisting of multiple bytes and uses a frame timeout. I wanted to concatenate these bytes like this HLA does, but they are in binary format rather than readable text, so I added a hex column.

The extra column worked right away, but I noticed that there is a row for the HLA in the waveform display which still showed the text messages. I “fixed” this by changing the line that sets result_types.message.format, but ultimately it would be nice to let the user select the format. The context menu for the HLA already has four options (Binary, Decimal, Hexadecimal, ASCII) but whatever is selected there has no effect. Ideally, that selection should determine how the messages are formatted. I couldn’t find how to achieve this.

By the way: why does this HLA only define a single result type “message” and dumps things like errors and I2C addresses into that message as strings, just like received data? From the documentation it seems that it would be more appropriate to define two more result types “error” and “I2C address” so that “message” is really only for received messages. Or did I get this wrong?

My fork of the HLA is available here:

timreyes · January 7, 2021, 12:08am

@dennis Thanks so much for making those additions! I could certainly see the usefulness of adding a hex column for non-text data.

I’m going to shoot your message over to Mark, the creator of the Text Messages HLA.

markgarrison · January 7, 2021, 12:25am

Nice work @dennis!

Right now the display base in the settings menu only affects the data table. There are a lot of improvements we need to make here, but we won’t be able to get back to extensions development for a while, we’re focusing on other areas of the application at the moment.

I suggest using the HLA settings API instead. You can add settings to the HLA settings dialog, the same dialog where you select the input LLA.

You can use the delimiter option as an example:

github.com

saleae/hla-text-messages/blob/b8a1143ba40cd71853a1086d8633a5ba8a361a08/text_messages.py#L31


class TextMessages(HighLevelAnalyzer):
    temp_frame = None
    delimiter = '\n'
    # Settings:
    prefix = StringSetting(label='Message Prefix (optional)')
    packet_timeout = NumberSetting(label='Packet Timeout [s]', min_value=1E-6, max_value=1E4)
    delimiter_setting = ChoicesSetting(label='Packet Delimiter', choices=DELIMITER_CHOICES.keys())
    # Base output formatting options:
    result_types = {
        'error': {
            'format': 'Error!'
        },
    }
    def __init__(self):
        self.delimiter = DELIMITER_CHOICES.get(self.delimiter_setting, '\n')

You could add a new setting to select Ascii or Hex (or others).

Given that this is a pretty big expansion to this HLA, I suggest publishing it as a new extension. The purpose of the “Text Messages” HLA was to make it easy to read strings sent over UART connections. This is makes it more of a generic packetizer.

If the protocol you’re working on is a standard, you could take this further and customize the HLA to decode information specific to the protocol.

markgarrison · January 7, 2021, 12:26am

You’re right about that. This HLA was created as a simple demonstrator, to provide some value but to also act as a simple example extension to help people understand how it works and provide another starting point for users to modify.

dennis · January 7, 2021, 9:55am

Thank you for the feedback!

The protocol I am working on is not a standard, it’s something I came up with myself. Background: a device periodically needs to send binary 16-bit messages over one pin. Having 16 data bits per packet seems a bad idea, since it would require super accurate clocks (besides being non-standard), so I’m sending another start bit in the middle, i.e. essentially two packets with 8 bits each. Now the receiver still needs to connect two bytes to a message and it needs to know where a message starts (otherwise it might forever interpret the second byte as the first). This can be easily achieved by leaving some minimum time between messages and working with a timeout. The “Text Messages” plugin provided all that functionality, that’s why I used it. I don’t need the delimiters, just the timeout. While this is not a standard protocol, I think it is a common use case and it would be useful to have a HLA for this.

I will turn this into a plugin of its own. However, I am not convinced that it’s good to have tons of different analyzers with little differences. I agree it’s good to have a simple example for demonstration purposes, but when it comes to a collection of analyzers for regular use, a generalized HLA with more settings appeals to me more than multiple specialized ones that are similar.

dennis · January 7, 2021, 11:28am

I submitted it under a new name: Concatenator

I added a setting for the format to choose between ASCII and Hex. I also added the delimiter option “None” and changed the time unit to micro-seconds.

The repository is here: GitHub - pastaclub/hla-concatenator

timreyes · January 7, 2021, 9:50pm

@dennis I can confirm that your HLA has been added. I just tried it out myself. Thanks for contributing this!

markgarrison · January 7, 2021, 10:14pm

You’re right, one of the big missing pieces of the marketplace is organization and management. We don’t have any features for this at the moment.
Ideally, we would have tags, search, ratings and comments, and perhaps some top level categories. We’ll also want to focus on the most common needs that we discover through the marketplace, and make sure these needs are well covered by either Saleae written extensions, or community extensions. It’s still very early days at the moment. Looking forward to it!