Repeated trigger capture

Roadmap

Voters 70

H
R
M
E
P
M
+ 62 voters
M
T
W
A
A
T
A
B
K
J
T
R
R
D
D
N
A
H
A
A
Z
D
D
J
J
I
M
M
S
S
N
K
O
B
A
M
Y
R
A
M
D
B
C
N
K
J
S
A
S
E
P
J
F
C
D
M
A
N
R

A
+ 2 anonymous

Open
Subscribe

Uriel Klieger

Similar to the "normal" trigger mode of an oscilloscope, it would be useful if Logic could be set capture an amount of time around a trigger event, and then re-arm the trigger and do it continually. Logic could save each trigger to a file automatically or only display the most recent capture.

This could be useful for capturing certain events which are far apart in time, without having to sift through all the data in between.

It would be most helpful for capturing the final occurrence of a trigger -- that is, something should happen regularly when things are running normally and then it stops happening. This way, we could see what happened around the time of the failure and not miss the event.

29-03-2020 -

Activity Newest / Oldest

Kazimierz

I haven't realized I would need that feature, but now it would be useful. I'm capturing a very repetitive signal, nothing fancy, just two pulses on separate channels. And it would be great to be able to see in real time what the time relation is between them. Currently I have to start and stop the capture just to stop them whooshing through the screen. Would be great to be able to make them update (does not have to update at every event) at the same spot on the screen based on falling or rising edge.

Tim

(#79043)
"I love your HW but I really wish you would add that continuous trigger feature that people have been asking for for years. I've read the support posts where it's been implied that it would be added for "future hardware". I hope you can imagine what that sounds like to people who already own a $1400 version. Go for it but there are already a few tickets out there for this exact feature. I was just venting when the annoying pop-up launched on your website."

Tim

discuss.saleae.com/t/is-there-any-way-to-use-rising-edge-falling-edge-for-trigger-view/1913/3
"What I want is to use capture in loop mode and have it run endlessly, but with a holdoff of 100msec so that the edge of the trigger signal always appears in the same position.

I think the trigger view feature is closest to what I want, but this feature seems to work based on analyzer results."

Ril

Hello,

Any news on the "normal" mode trigger ? We just bought some Logic Pro 16, because they seemed like a great replacement for our current Picoscope devices, but not having the "continuous trigger" feature is really a big weakness in our opinion.

On top of that,. it would be great to be able to do statistical analysis on these continuous triggers, like pulse width average, frequency, duty cycle, etc.. For me, it is standard logic analyzer features. Any plan to introduce these features soon ?

Thanks :)
Ril

Tim

We unfortunately don't have any news to share on a "continuous trigger" mode, however, we do provide the ability to continuously trigger on protocol results as described below.
support.saleae.com/user-guide/using-logic/capture-modes#trigger-view-triggering-on-a-protocol-result

In addition, statistical analysis is possible on already completeled captures via measurement extensions:
support.saleae.com/extensions/extensions-quickstart#using-a-measurement-extension

You'll find some useful measurement extensions like "Burst stats", "Duty Cycle", the pre-installed "Clock Stats" extension, and others.

Casey

Yup, this feature would be great in Logic2. Trying to capture an intermittent fault at the moment and want to see the bus state. Could use this to look at the last transaction prior to MCU hang.

Rando

I'm also VERY interested in this feature which is pretty the same as "normal trigger-mode" on an oscilloscope. Not sure why it's not implemented already. In my opinion its just:
1) Taking trigger -> Start an internal timer
2) When internal timer ran off -> allow new trigger
3) Start 1)
Seems not to be a big deal to implement that into the source-code in a few days 🤷‍♂️

Would be great if saleae would care about this soon.

Kind regards,
Rando

Tien

A repeat triggers helps capturing data for intermittent fault, error that only happened once in many repeat trials, in a system:

1. Set LA to repeat trigger

2. System go through steps to reproduce the fault(which includes a trigger to let LA capture data)
3. If fault occurred, system stops, else loop back to step 2.

If the fault happened, the LA has the data for the last run which might yield cause for the fault. It's critically needed for automated testing and fault locating

Tim

(#68919)
"Feature Request - Looping+Trigger
Hello , We would like to have this feature. It would be great to have it. Trigger +Looping , currently with trigger it stops after trigger has occured.We would like to continue running the capture"

Tim

discuss.saleae.com/t/scripting-socket-api/108/12
"In our current use case, we’re looking for behavior on GPIO lines, so we don’t necessarily need trigger on protocol error in the sense of SPI/I2C/UART protocols, though that’d be a very powerful feature that we could use. Sorry if I was vague about what we were analyzing.

And yep, 100%, repeated triggering as described in the blurb above is exactly the “minimum viable feature” that would solve our use case."

Tim

www.youtube.com/watch?v=un8onPh5STA
A feature request from Dave (EEVBlog) for Repeating Trigger capture support. Several other people have also commented their need for this!

Tim

Tweets here:
- twitter.com/eevblog/status/1501782699845251073
- twitter.com/eevblog/status/1501376930452733952

Tim

(#66695)
"Feature Request - Normal mode. A normal mode like an oscilloscope has or the "WaveForms"-Software of digilent (e.g. for the analog discovery 2).

The logic analyzer should run all the time and if a trigger condition appears it updates the screen. It's pretty annoing to press run over an over again, when stepping through the code line-by-line."

Tim

"in most of the cases, a single signal like ChipSelect (CS of an SPI) or the CLK of a bus (I²C) or one line of an async bus (UART) would be enough. When using a clock or a dataline it definitely should be possible to avoid triggering on each edge.
......
currently I'm developing a PCB-board with SPI on which 2 different ADC-daisy-chains are attached to. For me it would be very helpful to be able to trigger on both signals at the same time in that way that I can configure it like an “OR”- or an “AND”-condition, where the OR definitely would be the more useful one."

Tim

(#64872)
"having the option, when using trigger, to have nothing happen until a first pulse is seen.
--------
Logic 1, for me, operated this way. I started the trigger and the program did no recording until it saw a pulse on logic lead 0. After the initial pulse,

all channels began recoding until the stop button was clicked. This is the feature I would like to see returned."

Tim

(#64905)
"Another function which would be really cool is if I take a scope and put it in "normal mode", then I can see a picture of a single pulse as it flys by capturing. Right now, to see anything, I have to roll the time base in so far I can't see any individual pulses until the capture is over. "

Tim

discuss.saleae.com/t/bus-display-and-continuous-trigger/128/9
"I would definitely be interested in this! I was busy searching if there was a way of doing this when I found this thread."

Tim

(#63169)
"Feature Request - the "repeated triggers" may be what we are looking for in the future. adds an Oscilloscope feature.
The wave shape will not move across the screen in real time. You don't have to stop it."

Tim

(#62990)
"Feature Request - I'd like to have a way to disable auto-scrolling before the device triggers. I find the auto-scrolling of signals to be very distracting while waiting for a trigger. Many of the things that I analyze are simple buses like SPI and I2C, with easy trieggers, and there's almost always nothing else going on while I wait for my trigger. Having the continuous scrolling makes it more difficult to quickly tell if I'm triggered or not. A global 'Preferences' setting for this would be more than sufficient."

Tim

discuss.saleae.com/t/triggering-and-scope-view-share-your-ideas-with-us/563/46

"Just got my SALEAE… I love it - but my first task with it, is measuring some analog signals, where I would love to be able to trigger on the analog signal…is this feature still in progress?"

Tim

(#60120)
"The Saleae analyser needs to have an oscilloscope-type continuous trigger, where the view is constantly updated with new data in a rolling-buffer fashion. I wasn't aware that they could not do it, and it has made the usefulness of the analyser lower than anticipated.

The 'recording' mode is very useful to see the history when debugging a certain issue and that feature has been extremely useful, however there are a lot of situations in a professional environment where you need to see plots updated live with continuous trigger. A good example is the Picoscope line up. Their MSO offerings do have this, but not the 'recording' mode.

In my view, the lack of this feature will significantly hurt the analyser's usefulness in a professional R&D environment.

Could you let me know if this feature is planned, if so what timescale is it on?"

Tim

(#59959)
"When looping, it would be very helpul if the screen display operated more like an oscilloscope where signals are positioned according to a reference signal and the reference signal is always in the same position on the screen. This helps to see time varying signals such as for example PWM duty change over time."

Tim

(#59887)
"Feature Request - Multiple trigger-captures. It would allow me to capture several sequences on random event without having to restart capture by hand each timle event has occured."

Tim

(#59850)
"There's a typical oscilloscope mode where the oscilloscope triggers repeatedly, replacing the data onscreen with new data every trigger. This is super helpful for watching an analog waveform event. Logic has a "loop" feature which is similar, but there's no way to time-align it to the trigger. If there was a way to make the "run" button have a "run and then repeat" option, or a way to have the "looping" option keep itself time-aligned to the trigger, that would solve my problem."

Ken

Enabling ideas.saleae.com/b/feature-requests/jump-to-trigger-point-after-capture/ would be the first step for this.

Max

I am debugging a SPI connection and my use case is the following. Every ~10.5ms 9 bytes are exchanged between devices and I can externally change the content of these 9 bytes. I would love to have a repeated trigger (either time based, so every 10.5ms or better 72 clock cycles after a falling edge for SPI Clock line), such that the GUI would be frozen on the relevant part of information and I could watch changes in real time. At the moment data is either zipping by too fast in live mode or I have to go back in time to see changes after the fact.
In any case I really love the new GUI!

Tim

discuss.saleae.com/t/auto-restart-capture/916
"It would be nice if it was possible to have like an auto mode available in oscilloscopes.
Start - Display from trigger on screen - wait xx ms - restart.

Really usable when looking at repeated signals when doing adjustments."

Tim

(#57511)
"Automatic retrigger after capture duration time has finished. Capturing the last event not the first one.

In my use case a cyclic test is running and the test stops if it fails. And every cyclic test logic should automatically capture certain signals. After the test stopped I got the last captured diagram. At the moment we have to implement an instrumented code triggering a debug pin when the issue occurred."

Sergey

Looping with trigger synchronization or continuous trigger allows you to track the change in synchronization of multiple devices in real time.

I have several transceivers and I need to monitor in real time how many microseconds their mutual synchronization diverges.

Such a mode is available in any oscilloscope, and also in the analyzer from Kingst: Click the @ button in the toolbar to start automatic repeat acquisition.When the collection time is reached, the software will automatically starts the next collection, it is not necessary to click the > button manually until the sampling needs to be stopped.

Andy

In repetitive debug tasks, the steps are often:
1 arm the Trigger in Logic 2
2 Run some code
3 look at the Logic2 output
4 repeat at step 1

It would be very helpful to have a flag in the trigger settings, which would automatically re-arm the trigger after the capture duration has elapsed.

Extended option:
In addition to the "capture duration" there could be an additional waiting time "hold-off time" without data capturing, before the trigger is re-armed. However, this is probably not required and would just make the settings more complex.

Tim

Posting more notes here regarding Triggering and Scope View ideas from the community:
discuss.saleae.com/t/triggering-and-scope-view-share-your-ideas-with-us/563/43

Neel

Status changed to: Open

Saleae

Hey all, we'll start working on this feature soon and we'd love to learn more about your use cases. Please share with us your experience here:
discuss.saleae.com/t/triggering-and-scope-view-share-your-ideas-with-us/563

Saleae

Merged Post: First of all - I love it, really. And it helps me so much everyday coding DSP Firmware.

For the new Live View Feature - would it be possible to set a trigger that fixes maybe rising/falling edge to a defined starting point at the view, like Oscilloscopes do ?
I actually Play with HiRes PWM and if i can fix the rising edge somewhere to the left of the window, i can see jitter and change in on-time changes more easily.
In the current release, it starts somewhere in the window.

So much thanks for your support & kind regards from Germany,
Marja

Saleae

Merged with: Trigger Point for live view

Saleae

Merged post: I would be good to have possibility to re capture each time the trigger occurs.
And save only a certain amount of time before and after.
This could be use to monitor the last action of an heartbeat without saving GB of data

Saleae

Merged with: Continuous Trigger

Saleae

Status changed to: Planned

Saleae

Thanks!
Yes, we are planning on integrating the live view and triggers (of all kinds - digital, analog and protocol results). You'd be able to select if the live view updates only on a new trigger or with any new data

Aleksandr

Whatever happened to this? It says planned, but nothing since 2 years ago. Another bump for analog and repeated type triggers to make the device work a little bit more like an oscilloscope. If you want a good example of a repeated trigger in PC connected oscilloscope, take a look at the PicoScope software: it captures a waveform on trigger and all the captured waveforms can be cycled through and saved to a file for easy analysis when you're back in the office.

Tim

Sorry for such a long silence on this topic. 3 years ago, we were fairly optimistic about including a software-based solution for repeating analog triggers to have it operate more like a traditional scope. Since then, we were able to include a basic form of protocol result triggering, and added a few new options for digital triggering.

Unfortunately, we had to re-think our approach to providing a high quality analog triggering system, and felt it best as a feature to be potentially included in next-gen hardware.

Douglas

Why hardware? Isn't this a software problem?

Is the solution not to re-center the view each time a trigger is hit?

Tim

You're absolutely right. A software-based approach might be sufficient for Logic 8, where 10 MS/s is the max analog sampling rate for the device.

However, we may start running into performance/backlogging issues if we were to also add software-based analog trigger support for Logic Pro 8 and Pro 16 with a 50 MS/s max analog sampling rate. Though, we're unsure about that theory without pouring development time into it.

We're planning on pushing sampling rate speeds even further on next-gen hardware, and I'm not entirely confident that a software-based analog trigger approach would be well-suited for it.

Douglas

I understand the thought process. A few thoughts in response.

I'd be perfectly happy having the feature in software on the condition my computer could keep up. This is already true at high sample rates, an old PC of mine years ago struggled to keep up and the software lagged behind. That was fine with me.

Of course you would want real-time with repeated triggers, but if my PC can't handle it, I can turn down the sampling rate. If I both need that sampling rate and the triggers, I guess I better get a better PC.

I'm not super familiar with the API for high-level analyzers, extensions, automation, or anything else. Is there any way to write code to hook into seeing every analog datapoint in real-time? Is there a way to control the centerpoint of the view from any of those APIs?

It strikes me the implementation for this, at its core, is to look at each sample, is it above/below some threshold, re-center the view on that datapoint. Maybe something the community could prototype up as an extension.

Thanks.

Tim

That's a good point regarding simply lowering the sampling rate. USB3 data throughput might be the main limiting factor, so if we were to introduce a completely software based solution, we may want to impose a sampling rate limit. As far as development resources go, getting this working in nex-gen hardware might be the best bang-for-buck for us, and doesn't impose such limitations.

At it's core, you're right, the implementation is quite simple, especially if skipping samples or introducing long trigger hold-offs are acceptable. We just released Automation v2 for the newer Logic 2 app (www.saleae.com/automation/), however, it doesn't have the abiliy to manipulate the viewport or read samples in real-time.

Douglas

Thanks for the thoughts on this.

A few questions.

When you talk about HW, I understood the inside of the Saleae to be an FPGA, which is programmable, which I presume future HW to be as well. If your intention is to build this feature into future HW, what stops that feature from being supported in current HW (that is, current programmable hardware)? As in, is there something that can be done to work in both current and future hardware?

I've owned two Saleae devices and I'm happy with them both but the idea of having to re-purchase to get this feature seems excessive, especially given the perceived complexity of implementation, as well as the feature being present in low-end scopes and analyzers that are in similar price bands.

Thanks.

Tim

Without sharing too much details on what we're brainstorming/working on behind the scenes, our ideal hw triggering system will likely not be FPGA-based, but instead, would ideally be realized in front-end hw.

It would be great if we could improve our new Automation API to include some basic features that could help with creating a pseudo sw-based triggering system based around simply re-centering the view.

Any sw solution more complex than the above was something we couldn't prioritize in the short term, especially if next-gen hw may not even utilize it. We currently have 4 sw engineers in the company, and they're laser focused working on other features, one of which is continuously improving on our new Automation API.

Douglas

Great, hopefully both can be realized so current and future customers can enjoy. Thanks!