The first one is Bus display.
I often have to look at state machine and there is actually no convenient way of displaying them.
Maybe it could be interesting to split the signals that are display vs the one that are selected for capture.
So that you can select what you want to display and display them as stand alone signal or bus or even protocol decoder.
The second one is continuous trigger.
In one use case I have an heartbeat every minute and I’m interested by the last one that happen when my code crash. So instead of capturing the first heartbeat pulse with a One-time trigger, i will need a continuous trigger to re-trigger on each an so getting the last occurrence of it.
Bonus point if I can configure pre-trigger buffer duration and post-trigger duration independently.
Agreed. Both ‘protocol-only channel’ and ‘bus view’ are on the roadmap. This probably will change but they currently are on the board for Q1 2020.
Do you mean that you want to trigger on, and save a capture for every single heartbeat?
What do you think about recording in “Looping” mode - where the application continually holds on to the most recent N GB of data, and allows you to stop at any time, such as after you see a crash? Right now the Alpha software mostly works for this, although it’s hard-wired for a 2GB limit.
No I don’t want to save every single heartbeat in independent capture but honestly it could be a nice feature so you can compare all the trace.
The fact is that with Looping capture it rely on me to be present in front of the software to stop.
And I’m trying to actually capture a crash that happen within a 2 to 8 hour window and we run it during the night so definitively I need to rely on the client software to keep the interesting point, cause else when i arrive in the morning everything would have disappear depending the buffer depth and when my issue arrive.
Something that works in a way that “if there is a trigger save it, and if there is already one discard it” would do the tricks for me
Hum… This isn’t very compatible with the current architecture but is interesting to think about how it would work. Imo setting up multiple captures like this (where the latest one could, if it finishes on its own, overwrite the previous one) is something that we totally need to support via the upcoming automation API.
We will have a bus display; thinking about it now, the way we may implement it is as a “viewer” for a protocol analyzer - meaning that a ‘parallel’ protocol analyzer will convert multiple channels into a single bus value, and display it in the style of a bus view. This way we could use ‘trigger on protocol’ to implement such a trigger.
If we can make it super easy - then the best way for users to make crazy arbitrary triggers in the future might just be to write them in a few lines of code. Not sure!
Any progress on the continuous trigger idea? I would like it too. I need to observe jitter in a periodic pulse, and this would be much easier if the Saleae would just continuously trigger on the same falling edge, and update the view accordingly, like an oscilloscope. It would only need to record [window width] of data and stream that small buffer to the PC, repeatedly. On a Saleae with USB3 this would not be a problem I suppose. I can do something similar on my SmartScope, even with USB2.
I know this is more of an oscilloscope feature than a logic analyzer feature, but I guess the Saleae is a mix already anyway, with its analogue channels, and it would be very nice not to need an additional instrument on my desk.