Analyzer bubbles messed up while using HLA

I am using Logic 2 (version 2.4.7) to analyze inter-device communications. It is done via UART with custom upper-level protocol, so I tried to use HLA to decode this protocol.
My protocol don’t specify packet length, it using start and stop bytes instead. So, my HLA script collecting data until it got stop byte, and then analyzing packet. Everything looks fine in Data Table, but on main screen with waveforms the analyzer bubbles looking partially screwed up. Maybe, it caused because my HLA script return array of markers unsorted in time.
Anyway, here is my HLA code (it far from perfect, but still can parse
packets): · GitHub
Capture and screenshot attached.

sample.sal (4.9 KB)

@aleaksah Sorry for the trouble with that! I’m happy to look into this for you, and thanks for providing those files. I’ll need some time to run some tests and review your source code. I’ll keep you updated once I’ve had a chance to look into this.

Note: More information provided from support ticket #79982.

I’ve created custom HLA for parsing packets sent over my network (based on RS485). Sometimes it works well, but usually all analyzer bubbles messed up. Sometimes this even cause major software issuer like zooming problems. I guess this can be caused by returning array of AnalyzerFrame instead of one AnalyzerFrame, but this should be possible according to your guide. Can you help me understand what cause such behavior and fix it?

@aleaksah I’ve had a chance to get to reviewing your source code and capture file. Thanks for your patience in the meantime! After further review and testing, this looks like a potential rendering bug on our end. I’ve attached some files here for reference in the meantime, including as screen-capture of the rendering bug in action. I’ve created a .json file to go along with your HLA .py file as well to make it quick and easy to install and test your HLA. (3.2 MB) (12.3 KB)

We’ll need some more time to figure out what could be causing the analyzer bubbles to randomly disappear. We’ll continue to keep you updated, and I apologize for the trouble with this in the meantime.

Sorry for the delay with this! I was able to test this out and find the root problem.

The returned frames are not in time order. The frames returned must always increase in start time, because the system relies on the frames to be sorted in order to binary search them while rendering. Out of order frames produces undefined behavior and can cause very odd issues.

We originally elected not to test this to avoid the extra overhead on every frame add, however, perhaps we should add it, to avoid confusion like this.

A quick test:

        for res in result:
            print(f'start: {res.start_time}')

This produces the following console output for your HLA and sample:

The frames must always increase in start time. (also, ideally, frames don’t overlap, and end time is always larger than the start time)

Please update your HLA to ensure the returned frames always increase in time. You might want to add code to detect this problem and raise an exception when it occurs too, just to be sure.

Thanks for your reply!
Yes, I had an idea that this can be root of my problems, but your documentation don’t mention importance of ordering frames in time at all.
It it any way to sort already created array by start time? I tried to do it with “sorted”, but failed.

Yes, the following should work:

result.sort(key=(lambda x: x.start_time))
1 Like