Introducing analyzer triggers! An experimental feature that allows you to trigger the view by searching for a single protocol result by its ASCII, hex or binary value (based on the selected format)
Resize channel labels
Clear and Snap to Bottom terminal buttons
Improvements
Removed sidebar maximum width
Data rendering is much faster!
Bug fixes
Improved session deletion, to reduce application hangups
Fixed analyzer percentage processed dropping to zero
I2C analyzer now reports the first start condition to HLAs and the data table.
I started using the Protocol Trigger and have a couple of questions. First… Thank You, THANK YOU! This is the start of something that we have all waited for for years.
I setup a simple I2C trigger on the I2C address. When the trigger occurs, the waveform display freezes showing the trigger, but the capture continues to run. I need to manually stop it. Is this the expected behavior? I have the Trigger in the Capture Settings set for something that does not happen for a long time. How do the Protocol Trigger and the Capture Settings trigger work together?
What is the purpose of the “Holdoff” field next to the query?
A comment you have seen before, and that is that the address shown in the table and the query is not the address shown on the waveform display due to the bit shift that I2C has depending on how the channel is setup in the Analyzer. They should be consistent.
When the trigger occurs, the waveform display freezes showing the trigger, but the capture continues to run
The current version only supports continuously triggering the view every time a trigger is found (or only once your case). The holdoff is the minimum amount of time between triggers, e.g. if the holdoff is 100ms and two triggers are found in less than 100ms, the second one will be ignored.
Our plan is to have a system of events, such as triggers of any kind (analog, digital and protocols), and actions - what to do when a trigger is found - move the view, set a marker or in your case stop the capture. This is only v0
I’ve been using the protocol trigger all day and I just want to say it is awesome!
I’m writing a SPI driver for a high speed device and this has been super helpful in debugging. This is one of the few features traditional scopes had over the Saleae, but now there’s one less reason to use a scope.
Excited to see how this evolves. This continuous development is what has me recommending this thing to every electron herder I know
I have started creating a Digital Measurement extension I really like the possibility of creating custom measurements!
I just found a strange thing: the first sample of the DigitalData is not the starting bitstate and timestamp but the first transition’s state and timestamp.
But your documentation says:
“Currently, the DigitalData collection will first include the starting time and bit state, and then every transition that exists in the user selected range, if any.”
I have found another bug.
If I’m dragging one of the borders of a measurement range and accidentally make a right click during that, the dragging mode will not end when I release the left button of the mouse.
ESC button or mouse clicking will also not help. I have to exit the program.
Sorry for the confusion, that documentation was inaccurate and DigitalData has always only included transitions within the range. I’ve updated the documentation to match the implementation.
Thanks for the info on DigitalData format and the bugfix in 2.3.4.
I have two ideas on measurements which I think would be useful:
Ability to drag and move (slide) the whole measurement range instead of drag the start OR the end of it. Then it would be easy to test a fixed length e.g moving average window through the captured data.
Ability to add some kind of markers from measurement extensions. For example, in case of analog signals, place markers at the places of min and max analog values. In case of digital signals I would find very useful to easily see the place of the shortest / longest positive / negative pulse.
Great ideas @tamas.csatari, and thanks for posting those! I agree, those would be very useful, especially your idea #2. I added my vote to it and we’ll keep an eye on user interest in the meantime.
