Hey all,
We’re starting to work on continuous triggering for digital, analog, and protocol data and we’d love to hear from you and learn more about the use cases you’d be using this tool for:
Any feedback would be highly appreciated! 
Cheers,
Rani
p.s.
If you prefer, you’re welcome to schedule a call with us here:
The very basic continuous triggering mode found on most (all?) standalone scopes would be useful:
This scenario comes up often when debugging UART signals, or if using a line to mark the start of an event, or countless other scenarios.
First of all, thanks a lot!
A couple of questions:
Automatically re-trigger based on the same criteria, but do this in the background and don’t keep the plot scrolling with new data until a new trigger happens.
What does it mean? Are you interested in a continuous trigger with holdoff time?
In what case do you use it? if it’s ok to ask of course.
The reason that I’m asking is to understand if we can build more tools beyond basic triggers to help you debug even faster.
When the device re-triggers, do not change the view at all, simply update the data.
Of course, our number one rule is: Never change the view if the user hasn’t asked for it 
This scenario comes up often when debugging UART signals, or if using a line to mark the start of an event, or countless other scenarios.
Do you need analog or protocol triggers or only digital triggers?
My take is that this is a conventional scope’s “normal” mode where it displays the signal from the last trigger event until the next trigger event comes along.
The more closely you use/leverage typical scope functionality, the easier it will be for users to understand how this mode works. To me, the most basic function is to define a trigger condition (like you already have) and whenever that trigger condition happens, start re-plotting data at the screen’s trigger position. (Filling in data before the trigger if the trigger is not on the very left hand side of the screen.) The user can choose to have the screen erased first, or have each trigger’s worth of data plotted on top of the last (to show glitches for example).
I’d like to be able to set the trigger location horizontally, and not have it move, even if after the trigger more data comes in and goes off the right hand edge of the screen.
I’d like to be able to trigger on analog levels (rising/falling/either) as well as digital.
To go for the moon - the ability to trigger on decoded analyzer data would be amazing, but sounds hard to do in real-time.
From there you can make it as complex as you want - keep adding more and more scope features. Like delayed trigger, complex trigger, etc.
There are times when I’d like to be able to use an ‘auto’ mode for the trigger, where it doesn’t wait for a trigger but just fills my screen with data, then immediately starts over from the left hand side of the screen. That way, if I want to show exactly 10ms of data over and over, I just make my screen exactly 10ms wide and I’ll be able to show exactly that much time continuously.
To me the fundamental feature here is that instead of simply scrolling the data under the window, you re-draw the same window with new data (no scrolling). Then you control when the data starts drawing on the left side of the screen (trigger, auto mode, etc.) and you have yourself a scope.
This will be fantastically useful to me in my daily work. When Logic 2.0 added the ability to live scroll data as it was being captured it really changed the way I used my Saleae. Now I just kind of always have it watching my circuit, scrolling by, in case something interesting happens. Giving us the ability use this as a scope it going to make it even more of a useful always-on tool.
Definitely include protocol triggers, including protocol errors if possible. I spent a lot of time recently trying to capture specific I2C behavior and being able to trigger on a START, NAK, or even a held clock line might have come in handy at various times in the project.
Thanks for the detailed response. It’s super helpful! 
I’ll share my personal concern - if I understand you correctly, you’d like us to “copy-paste” all of the functionality of a traditional scope. While it might end up as a great product, it won’t be exceptionally good and won’t take advantage of our software capabilities. For this reason, I’m interested in the use cases for each of the features you described. If we’ll have a deep understanding of them, I believe that we can build tools the are better than traditional scopes.
Again, nothing is wrong with these scopes, but I truly believe that we can build tools that will allow you to debug your hardware/firmware faster.
We’ll do that for sure. We worked hard on the analyzers performance exactly for that - to be able to run most of them in realtime.
Yup, you’re totally right. Take advantage of what Logic can do ‘special’ compared to normal tools. I agree. But inventing a whole new set of functions and terminology means users will need to spend time to learn how you chose to ‘be different’. If what you can add is significant, then this re-education may be worth it. But trying to move away from the features and terms that users are familiar with may cause confusion.
That said, Logic will never fully replace my scope(s). I never expect it to. The hardware isn’t there to do really fast repetitive triggering across wide voltages, etc. No worries - you can do many things even better than real scopes.
I do believe that once Logic has even a basic ‘scope view’ (or whatever you end up calling it), it will replace 95% of what I need my scope for now, because most of the time I don’t need any of the really higher end features that a real scope has. I just need simple repetitive triggering. And Logic can totally do that.
OK, so here’s a simple use case where I currently need to turn to my scope:
I’m writing Arduino code to output an RC servo digital pulse. I want to watch just one ‘cycle’ (20ms worth) of the pulse, but have it update every 20ms. So I’d like to set a rising edge trigger on channel 1, set my vertical width to 20ms, and then watch as the falling edges moves forward and backward from 1ms to 2ms in real time. How can Logic make this a better experience than a normal scope? Because I could use my mouse wheel to quickly zoom in on just the falling edge of the pulse (maybe have the left edge of the screen 1ms after trigger and the screen width be 1ms wide, thus showing the full range of the pulse) to see exactly how its jittering in real time at a high temporal resolution, and even have an automatic measurement of the high time of that pulse, so that I can see that it’s only going from 1.2ms to 2.0ms in width, thus showing that there’s a bug in my code at the low end of the pulse width.
Yes, I could set up a test with the current Logic software, and capture for several seconds, and then manually walk through each pulse after the capture is complete to see how long each one is, but what a PITA. Scope mode shows me real time what’s going on .
I absolutely agree with you. We don’t need to re-invent the wheel, but we can build tools on top of the “traditional” ones.
In your example, a simple tool could have been an extension that calculates the average/min/max width for you instead of you reviewing the jitter in realtime. You can maybe write a Python test that gives you 
/
if the jitter is in range. It has to be super easy to build of course, and hopefully there will be many community extensions like this over time.
Thanks again!
Sure, you’re right. Once you know exactly what you’re looking for you can write a specific test, or an analyzer, or whatever. But scope mode - to me - is about probing around your circuit without knowing what the problem is. You’re looking for things that “don’t look right”, but not sure exactly what that’s going to be. Having a very fast refreshing live display is crucial for that purpose. This is a lot of what I use a traditional scope for - and Logic could do that very well, since I already have Logic connected to my circuit. (I almost always have on of my Logic’s connected to some part of my circuit, but only pull the scope if I need some real-time probing)
Hardware stability testing: Measure current consumption, Power rail stability, power sequencing, etc.
How do you do these today? By looking at the graph? Creating a Python measurement? Exporting the raw data?
Port in the lower analog sampling rates from Logic 1.
We’ll bring it back at some point. Sorry about the delay 
Thanks!
How do you do these today? By looking at the graph? Creating a Python measurement? Exporting the raw data?
Right now it is a combination of looking at the graph (& using timing markers for Power Sequencing) and exporting the raw data to excel for basic math. I would love to use python in the future but it is currently easier to just use excel on datasets that are small enough.
Bonus Feature: Settable default scaling for analog channels. I find myself getting lost in the analog channels especially if the line was already high (because the software centers the signal.)
Bonus Bonus Feature: Multiple Saleaes at a time.
I would love to use python in the future but it is currently easier to just use excel on datasets that are small enough.
Why is it easier? (we’d love to fix it and make it easier)
Settable default scaling for analog channels
Are you using the auto-scale button on the top right side of the channel? If not, why?
Multiple Saleaes at a time
Do you mean multiple instances of the app? I’ll have to ask again - what for?
I would love to use python in the future but it is currently easier to just use excel on datasets that are small enough.
Why is it easier? (we’d love to fix it and make it easier)
The workflow that is currently easier to do in excel is (Subtract Channel 2 from Ch1) (Multiply by Resistor Value) (Do various statistical things to project DUT performance).
Just adding in simple analog math functions will do a lot. But, excel is an engineering hammer looking for nails.
Settable default scaling for analog channels
Are you using the auto-scale button on the top right side of the channel? If not, why?
I have used the auto-scale. The issue is that it scales to the signal that has been logged not the signal that I am expecting.
Multiple Saleaes at a time
Do you mean multiple instances of the app? I’ll have to ask again - what for?
The ability to log data from multiple saleae devices at a time. I had a logic pro8 & a pro16 connected to a test fixture that was not behaving. The physical size of the fixture made it difficult to cable everything back to one saleae.
Thanks a lot for the detailed response!
One thing that I’m not sure about - do you need any triggers (analog, digital, or protocols) for your work?
