Hardware logic analyzers have the option to trigger on a logic state being stuck for a certain period of time either low or high.
Currently Logic 2 supports "Pulse Trigger" which you need to specify both the minimum and maximum time before it will trigger.
However, it will not trigger if a signal stays low, or stays high permanently (i.e., beyond the maximum time of the pulse trigger).
This is useful to debug scenarios where a signal may be continuously toggling during a normal state, and would stop toggling or get "stuck" upon a failure condition.
Thus being able to trigger on a signal getting set to one state for too long would be a useful debug feature, that many hardware logic analyzers (Agilent etc) have, and seems very close to the "Pulse" trigger anyway so maybe won't be too much of a leap to implement.
Please, this was requested years ago. And I need it now :)
"How can I use trigger ‘Low Pulse’ for “Low too long”?
I want to capture when signal is stucked, but It seems only support trigger which must be setup by time range of Low Pulse mode.
Is there other options for?"
"It would be handy if you can trigger on a pulse NOT within a range.
(As far as I can see, it is now only possible to trigger when a pulse IS in the range, there is no option to invert that logic)
Sometimes you just want to trigger on a non-expected pulse width."
Only adding the option to invert the logic (i.e. trigger when NOT in range) would already give a lot more freedom.
If this is extended then with the possibility to trigger when it will guaranteed be out of range even if you did not detect the other edge yet will solve most (if not all) of the issues here.
But a simple option to invert the trigger logic is a good start!!
"We need to trigger the event of our 250Khz signal if it drops out at any time. We have a Saleae Logic Pro 8."
"I would like to stop the analyzer on a certain event. For example, supposing I have a 1Hz signal on a line. If the signal stops changing, can I set up the analyzer so it stops acquiring"
This feature is really useful!
Is there any news on this feature ? I am often chasing down bugs that crash my system after multiple hours and catching a trace is currently neat impossible since I would need to spend hours in front of the Logic 2 software. We were able to mitigate this by using an oscilloscope as a trigger point. This feature would be a major time saver for us.
This is a feature that is available in Logic 1.x, however, we don't recommend using that version of the software, and we no longer support nor develop for it. In addition, newer revision hardware no longer work on it.
Unfortunately, outside of the workaround above, we don't have any updates on this feature request right now.
"It could be nice to have a new trigger feature. Currently I am using Analyzer I2C and I would like to catch when communication with sensor is stopped throw the interrupt line, could it be possible to add a trigger on pin state low (or high) for more than x ms or sec ?"
This feature is needed. Please add back, even if just allowing to set n/a as described in the faq:
"Hi. I wanted to know if and when you will re-insert the possibility to trigger on a pulse with a minimum length but without the other edge (in 1.x it was possible by setting the upper range to n/a or something similar). It was really a very useful feature! Thanks in advance."
With the original Logic software it was possible to trigger on a pulse that with to specific maximum time. This was very useful for example to trigger when a signal stops changing.
This feature was explicitly mentioned on your site:
Currently I cannot select a "n/a" value for the maximum time so this does not work anymore.
I'm just a customer so I don't have the full story, but my understanding is that the analyzer uses an FPGA to manage sampling and data conversion so it effectively just sends transitions to the host computer. I'm sure Saleae will set me right if I've got the wrong end of the stick, but they are west coast USA so they won't see this thread until USA Monday.
So yes, my understanding is that even sampling at 500MHz the data rate and data size out of the analyzer will be a function of the total transition rate across all sampled digital channels.
I agree this would be good to have. i have tried to group a parallel bus, and wanted to add it would be nice to also prioritize sampling rates, so that if one signal was an enable strobe, you might want to sample at 10KHz because it transitions once rather than blowing 1/10th of the 550MHz sampling capability if you have 10 signals to watch. Even if there was a high medium low so it isn't infinitely variable, this would be good.
Saleae run length encodes the digital data so only transitions are recorded for digital signals. The implication is that even at high sampling rates, with little actual activity in the sampled data the data rate is low.
So let me get this straight. When I have 5 signals and set the sampling rate to 500MHz, each is not using 100MHz bandwidth of the total sampling capability? It also could be that if the signals are entering an FPGA with a 500MHz fabric speed, then ALL signal edges are sampled at this rate. I am not sure which is in the device. My thought was if I have a strobe with high speed signals like a clock inside it, then I would rather have control over the sampling rate so I could put 250MHz sampling on the clock and maybe 1 MHz sampling rate on the strobe.
i am confused why this has not been readded? it seems rather easy to allow for a 0 to be left on the maximum input field of trigger width to achive at least the simple configuration of this function! But I also don't know how extensive internal the trigger code would look like then. Currently you can not enter a minimum greater than the maximum, which makes sense but a 0 should be a special case IMHO
"I am using 2.3.29, and cannot configure for a minimum pulse width like I used to. How should it be done?
I have a signal that I want to trigger if it is low for at least 25 seconds. There is no maximum time limit."
When my device stops working, I would like to see what happened at the very end. How about a trigger on a signal without any transitions for longer than a specified time?
Hi, We have about 10 saleae Logic8/Logic16, this is a needed feature in the new version of the SW which is otherwise quite great! Thank you!
Feature Request - trigger on pulse with no maximum end time. Need to catch when a logic signal goes inactive (no switching events for some time).
Thanks for copying this here. This would be a very useful feature for debugging cases where a bus hangs up and there isn't another control/trigger signal available to indicate this otherwise.
Request via GitHub issue:
"I don't see the option for "n/a" as maximum limit in Logic 2. Is it possible to set up a trigger this way?
"So I need a function which start the capture after a signals stop to work
or if a signal is no longer change ovver some seconds"
"Hi I'm using the Version 2.3.17 of Logic. How to set the max duration of a low pulse in the trigger so that it is a "not care"? Before there was a n/a option"
We desperately need this feature as well. We're trying to hunt down an issue with i2c clock stretching where the stretch exceeds a threshold. I believe Logic 1 has had this feature for some time.
How can you define a trigger on pulse width with a certain min. width but no max. limit? I think the tool always asks for a finite max. value. However, there are situations where one is interested in a certain min. value to trigger.
Marcos raises an important point here. If there is a set maximum period the trigger can't be generated until that amount of data has been collected after the candidate pulse leading edge. A "Don't care" maximum value allows the trigger to be generated as soon as the minimum pulse period is exceeded.
This could be looked at as a edge trigger with a minimum debounce period.
I would add my vote that this is an important feature to have. I am trying to track down the source of a system lockup right now, and a certain wire going to a high state for longer than 10 mSec is a sign that things have gone bad.