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
Ahh, I get it now - the application will have âstopped by itselfâ by crashing, and you just want to have a trace of what happened just before and up to that point.
Super interesting situation - my first thought was that the pulse trigger could work, but it currently wonâtâŚ
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.
@nickantoniades11 Thanks for letting me know! We donât have any updates on this yet unfortunately, but I did get your vote added in the idea post I shared previously.
The continuous trigger is on the roadmap, but we havenât started development on it and I donât want to give an estimate now, since things can change between then and now. Iâm really excited about it.
We donât have bus display on the roadmap at the moment. I posted more feedback in a reply to your other comment.
