I would love to hear from you! Any feedback is helpful – please reply to this thread or start a new one!
Hi All,
This release adds digital trigger, digital measurements, and never-stop (aka circular buffer). All of these items will be cleaned up quite a bit, but the basics are there.
Low expectations please: This alpha is rough, unstable, and lacks crucial functionality. We’re releasing it so that you can provide feedback and influence the direction it takes, particularly in terms of user experience.
Hi,
Just a quick message to let you know I played with this alpha release…
great to see signals moving without having to start/stop recording! I don’t own an oscilloscope, so it would be great to be able to use this software as a simple oscilloscope.
When I exit the program (without problems) and start it again I get a popup saying that the previous run had crashed. I pressed the ‘send crash report’ button a few times.
it would be great to be able to view all signals (analog and digital) in the real-time ‘oscilloscope’ view with synchronized time scales and one common vertical time cursor.
small detail: the scale of the digital signals is incorrect (in my case -5:+5 is shown instead of 0:5 (see image)
Thanks, and sorry about that. Internal goal is to have high stability in the alpha by the end of the quarter (4 weeks).
Interesting idea, thanks. We will get the digital scope-view in there fore sure. Having a way to synchronize their time-scales seems reasonable to me. I’ve added it to our “Scope View II” epic.
Good catch, thanks. Should be fixed in alpha 6 next week.
I like the idea to have a trigger to stop the recording but I would miss the trigger to start it. Ideally, could we have a trigger to start and another to stop?
The most common use case is a GPIO devoted to the trigger, so maybe two in that case.
I’m less enthusiastic about separating the settings of the trigger from the channel. It looks like a regression for me compared to the current version 1.2.29.
“starting on trigger and then recording X seconds”
Are approximately the same thing.
In both cases there is some ambiguity about the time before the trigger - historically this has been called the “pre-trigger buffer”, but we have no such limitation here.
What happens now is that it will keep all the data that occured before the trigger – subject to when it needs to start throwing away the oldest data because the memory limit is being exceeded.
Right now the way to limit this would be to use the feature “After stopping, trim to last X seconds”.
I’m not satisfied with this UX yet to say the least. I have some ideas on how to make it super clear. But first we’re going to get the software solid enough to use for your job - before then it’s a little bit too academic since no one is really using the software. Our goal is to be there by the end of this month.
