<PlasmaHH>
azonenberg: you are in the main menu, you can chose between 1) brutally honest feedback mode and 2) dumb question wtf am I donig here and how mode :P
<azonenberg>
PlasmaHH: lol. why not both
<azonenberg>
Improving the new user experience is very much something we're interested in
<azonenberg>
we of course have limited resources, but it's been a priority
<PlasmaHH>
do you by any chance use gdb for debugging?
<azonenberg>
Yes that's my primary debug tool
<d1b2>
<david.rysk> if I may ask what platform are you on?
<d1b2>
<david.rysk> so far I've been using gdb on windows/linux, lldb on macOS; we're not at the point of having an MSVC build yet
<azonenberg>
yep we were talking in ##electronics, some of PlasmaHH's coworkers on windows would like to try but were put off by the lack of a msvc build flow
<azonenberg>
Some time soonish we really need to get the last few bits of FFTS removed. i've just been so busy with other stuff
<d1b2>
<david.rysk> I probably should get back to it because a lot of stuff needs adjustment for MSVC (one major thing is explicitly exporting shared lib symbols)
<PlasmaHH>
anyways, I have to go help the wife prepare dinner soon...
<PlasmaHH>
as a first thing... my expectation of the software for what I want to do is that it can do cool filter and whatnot stuff but as a first step I can run my scope with it to tinker and figure out how to run my project/measurement... from that I would expect it to work somewhat like a real scope, but I was so far unable to find auto trigger
<PlasmaHH>
and there doesn't seem to be a way to put two differently scaled waveforms into one plot...
<azonenberg>
There is no auto trigger at the moment. It's something that's been on the todo for a long time but not a priority
<azonenberg>
And yes, all waveforms in a plot have the same scale. this was a deliberate decision from a UX perspective
<azonenberg>
because we dont have a channel-select button like a real scope, you just mouse wheel to change zoom
<PlasmaHH>
and what probably takes longer to debug is why its almost locking up and spweing weird error messages for my rigol but lets tackle that when I have more time
<azonenberg>
We couldn't find any reasonable way to get that to work
<azonenberg>
You're of course free to have as many stacked plots as you want within a group
<azonenberg>
and have separate y axes for each
<azonenberg>
tl;dr auto trigger is challenging given the way most scope remote APIs work
<PlasmaHH>
I use that on a real scope often for overlaying some input and output and look how well they match etc... from a UX perspecitve I know its hard... especially since there isn't much of any status icons etc ... for changing the X axis seprately I would guess hovering over the channel name while wheel scrolling could be useful
<azonenberg>
because they don't have a "push" flow they have a "poll" flow
<azonenberg>
i.e. you poll the scope to ask if it's triggered
<d1b2>
<david.rysk> is "toggle auto trigger on the scope" more feasible for those scopes?
<azonenberg>
then when it has, you stop and download waveform for each channel
<azonenberg>
you misunderstand
<azonenberg>
the problem is that if you use a free-run trigger mode, auto included
<azonenberg>
you risk downloading ch1 after one trigger and ch2 after another
<azonenberg>
The only way to avoid this is to stop the trigger when downloading data
<azonenberg>
(and with auto trigger this is hard because there's no way to know it's actually got new data)
<azonenberg>
Our "normal" trigger is actually "single shot" trigger in a loop of trigger/download/trigger/download
<azonenberg>
This is why i've been pushing scope vendors to implement a proper remoting API with a push based flow that lets you download waveform data and immediately re-arm the trigger without round trip latency
<azonenberg>
So most likely when we implement auto trigger its not going to use the auto feature on the scope
<azonenberg>
it's going to be normal trigger plus a timeout that does a single shot *force* trigger after a timeout with no triggers has elapsesd
<azonenberg>
this is in fact how pico's auto trigger API works, it's the same function you use to arm a normal trigger but you specify a timeout where it will always trigger after that time
<azonenberg>
we dont yet use this, but it's in their API and we can implement similar functionality clientside in ngscopeclient for other scopes
<PlasmaHH>
azonenberg: since for my software it was not really as intresting I never bothered looking at how rigol implements auto triggering in the scpi area... but I can vauely remembering something about any of the status bits.. the hard part really is getting all manufacturers under the same kind of interface..
<PlasmaHH>
but I think its from the EE perspecitve somewaht important to have somthing like an auto trigger. they generally are the experimental kind of people, not knowing beforehand what to expect, first want to just look at something and then decide how to maybe trigger on it and do scope settings..
<azonenberg>
yeah i know, its something i've wanted
<azonenberg>
its just something that wasnt super critical to me, and hard enough to implement, it's been low on the list of things i can justify spending time on
<azonenberg>
we have 300+ tickets some going back years
<azonenberg>
and only a handful of devs
<PlasmaHH>
I am a CS and not EE guy myself and have seen a lot of times how EE people have a hard time adjusting to new ways of doing things if there isn't a nice easy path frmo the old to the new... ;)
<azonenberg>
Yeah one thing to keep in mind though is that we are explicitly not trying to clone the 1970s analog scope UI like a lot of DSOS are
<azonenberg>
e.g. we dont have a concept of volts per division we have full scale voltage range
<azonenberg>
you control record length and sample rate, not time/div, because you can zoom each viewport in time independently of others
<PlasmaHH>
but yeah when I have time there is some debuggnig necessary, its not working at all with the rigol, for one it seems any gui threads or so are totally starved by network transfer or so, and then it doesn't update at all despite transferring all the data via WAV:DATA?
<azonenberg>
So, the gui thread tries to do as much as possible nonblocking
<azonenberg>
and cache state clientside
<azonenberg>
it does have to do blocking transfers when it first connects to get range and offset for each analog channel
<azonenberg>
from there on basically everything should be done in a background thread
<azonenberg>
There may be bugs in the driver causing unintended dependencies between the gui and network thread, of course
<azonenberg>
but that is how it *should* work
<azonenberg>
Generally speaking lower end gear (rigol/siglent) has far less performant firmware and very slow response to scpi commands compared to stuff from higher end brands, but there are exceptions
<azonenberg>
e.g. tek's MSO4/5/6 series are a lot slower scpi-wise than you'd expect given the price tag
<azonenberg>
while pico's stuff (C API not SCPI but still) is extremely fast and comparatively inexpensive, but still more than the cheap chinese vendors
<azonenberg>
(and my own gear is using a stm32, not some fancy linux apps processor, for the scpi and responses are basically instantaneous)
<PlasmaHH>
azonenberg: yeah, from a quick look at the backtraces of all the threads it seems that the waveform thread is really busy and then the main thread e.g. when you try to open the timebase window wants to send its own commands but can't because the waveform thread has locked things... ( not sure what you are using there but if it supports the rpc based or even hislip protocols I think you can
<PlasmaHH>
have multiple commands at once on the wire )
<azonenberg>
We do not support hislip right now. its on the todo but i havent got access to anything that supports it
<azonenberg>
the rpc based protocol (VXI-11) does not support multiple queued commands
<azonenberg>
Some vendors can handle multiple queued commands on a socket others cannot
<PlasmaHH>
ah ok I think already that did
<azonenberg>
some will process them in sequence others will drop commands sent while they're busy
<azonenberg>
LeCroy's SCPI implementation is my favorite so far
<d1b2>
<david.rysk> You might be interested in Thunderscope, but that's some ways away
<azonenberg>
they have their own tcp based framing protocol (VICP) that's fast and supports arbitrarily many queued commands
<azonenberg>
good error logging on the scope
<azonenberg>
and while i won't say i've *never* crashed the stack or bluescreened the scope, it's extremely infrequent compared to the competition
<PlasmaHH>
azonenberg: gtg but I will definetly compare the rigol stuff with how I do it because I have the feeling that it was a bit faster for me transferring all the data. so far for me it looks like it tries to transfer one waveform and because it takes so long it starves everything else... ( maybe there should be some prioritization for that lock so more interactive commands have priority )
<azonenberg>
yeah we understand that the waveform download is slow which is why we try to cache everything clientside and not ever have the gui thread waiting on network
<azonenberg>
this is also what the queued command API (SendCommandQueued() etc) is for
<azonenberg>
rather than blocking until the socket is available to send a command for, say, changing voltage range or offset
<azonenberg>
instead it queues the command and then returns immediately