<azonenberg>
pirate: we might be interested in fedora/epel packaging assistance once we've got the prerequisites out of the way, just want to get that done first
<azonenberg>
Which i think turned out really nice. We'll definitely have some small tweaks to make to a few but it's a huge improvement already
<azonenberg>
cyrozap: i saw, havent had a chance to look
<azonenberg>
i'm finally back at my desk after weeks of being in the office
<azonenberg>
So thats four hours a day i suddenly have back
<azonenberg>
Going through PRs then need to make a pass through the documentation and update a bunch of the user manual stuff
<azonenberg>
Also... I'm setting the time for the next developer call. Seems like the best availability for everyone is 14:00 Pacific / 21:00 UTC on Tuesday the 1st
<azonenberg>
Zoom link will be shared here shortly before but for now, mark your calendars
<_whitenotifier>
[scopehal-apps] fredzo 67be80b - Added 8bit/16bit data transfer mode setting for Rigol DHO models.
<_whitenotifier>
[scopehal-apps] mldulaney 9a138d5 - Fix fsk filter to include top and bottom keepout areas Signed-off-by: Mairi Savanna Dulaney <mairi@seattlebus.space>
<_whitenotifier>
[scopehal-apps] mldulaney 4db8f46 - make dram chibi Signed-off-by: Mairi Savanna Dulaney <mairi@seattlebus.space>
<_whitenotifier>
[scopehal-apps] ... and 3 more commits.
<d1b2>
<josHua> over in 1b2 discord #electronics, ngscopeclient has been an enormous benefit in debugging strange behavior of a Chinese-market Buck controller. using the onboard UI of the HDO4000 would have been really painful for this. this gives me a very good incentive to try to speed up the Rigol capture driver, if possible (I wonder if superspeed USBTMC is any good on this device)
ALTracer has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
ALTracer has quit [Ping timeout: 252 seconds]
ALTracer has joined #scopehal
ALTracer has quit [Quit: Quit]
<d1b2>
<fredzo_72653> IDK if you've noticed, but if you need higher refresh rate, moving to 1kpt memory depth (with single channel) will turn ngscopeclient acquisition in "live" mode (instead of consecutive single triggers). This allows to reach about 12 wfm/s refresh rate.
<d1b2>
<azonenberg> Oh cool
<d1b2>
<azonenberg> @josHua if you have any ideas for SMPS-specific filters let me know
<d1b2>
<johnsel> @azonenberg me and David were talking, he says the invite is open to all. I said, that's not how I understand the situation. I'm sure you know which I'm referring to
<d1b2>
<johnsel> and also, was or was there no Keysight InfiniiVision 3000T X-Series driver support at the moment?
<d1b2>
<azonenberg> The 3000T series should be supported by the agilent driver if the docs are correct
fayr has quit [*.net *.split]
JSharp has quit [*.net *.split]
fayr has joined #scopehal
JSharp has joined #scopehal
<d1b2>
<josHua> Having long captures was really nice for the work I was doing to be able to view a waveform at multiple scales. I would be happy with even one wfm/s rather than the current 7 or 8 seconds to download a waveform.
<d1b2>
<fredzo_72653> Yep... not sure there's much we can do about that... 250 000 samples per page is really not much compared to what we have on Siglent scopes (5M)
<d1b2>
<fredzo_72653> Mayby your DHO4000 can handle larger pages ? Can you check how many bytes are returned by WAV:DATA? when no sart/end point are specified ?
<d1b2>
<fredzo_72653> (250000 is whant DHO800 returns)
<d1b2>
<josHua> I'm not sure about filters, but here are some things I kind of wish I had yesterday evening: 1) It would be nice for cursors to snap to high d/dt edges (maybe hold down shift to override snapping?) when your mouse is near the high d/dt edge in both x and y. 2) It would be nice to have multiple cursors, for instance, to show period and duty cycle. 3) It would be nice to be able to select a range in the waveform view to compute, say, an average
<d1b2>
frequency over. In general, what I'm sort of thinking here is that a lot of what I was doing while debugging was interactive exploration of a long capture (this is the 'enabling technology' of ngscopeclient over a crummy on-scope UI), inside the waveform viewer. And so I often wanted to ask questions like 'what am I seeing on my screen right now?', rather than 'what is an aggregate value that I am seeing over this entire 50 Mpoint capture?'.
<d1b2>
<azonenberg> 1) I thought there was already a wishlist item for this
<d1b2>
<azonenberg> apparently not, please file a ticket. it's been on my long term mental radar for a while
<d1b2>
<azonenberg> 2) how would the UI around that work? its a nice concept but seems challenging to get righ
<d1b2>
<azonenberg> 3) There is a "window" filter that lets you extract an arbitrary sub-region of a waveform, which can then be applied to filters
<d1b2>
<azonenberg> So in theory this can be used to window any filter
<d1b2>
<azonenberg> but we can probably come up with some UI sugar to make this easier to do
<d1b2>
<azonenberg> (in particular having draggable start/end points for the window)
<d1b2>
<azonenberg> File a ticket for that as well
<d1b2>
<josHua> 2) the UI for this I think would be to add multiple cursors in different colors (perhaps a 'window' filter woudl bel inked to a cursor?), with a 'select active cursor' switch somewhere (or in the right click menu)? and an implicit change as to which cursor is active if you click righ ton the edge of a different cursor
<d1b2>
<azonenberg> @josHua So, the challenge with a bunch of this stuff is just the variability of the potential system states and speeds
<d1b2>
<azonenberg> like, you ask about "percentage of waveform downloaded" progress updates while with the thunderscope we can push ten megapoints at 25 Hz on four channels
<d1b2>
<azonenberg> Supporting scopes that span many orders of magnitude in performance and having a clean UI in all cases is nontrivial
<d1b2>
<azonenberg> Not saying we shouldn't do it, just that the UI for it needs to consider both extremes of the spectrum
balrog_ is now known as balrog
<d1b2>
<azonenberg> (perhaps one way to do this would be to start displaying progress indicators 50ms into a waveform download or something)
<d1b2>
<fredzo_72653> OK so I tested removing rate limiting on Siglent driver and was able to reproduce communication issues with SDS2000X HD too, BUT I figured the problem only occurred when two commands are sent on the same line separated by a semicolon (e.g. ":WAVEFORM:SOURCE C1; :WAVEFORM:DATA?". So I tested without rate limiting but sending each command on a separate line and the problem was solved. Impact on performance is small though (moved from 8.2
<d1b2>
Wf/s to 8.5 Wf/s on 1kpt waveform acquisition).
<d1b2>
<azonenberg> Interesting
<d1b2>
<azonenberg> What about on the faster scopes?
<d1b2>
<fredzo_72653> IDK if that would work with SDS2000X+, someone would have to test and confirm
<d1b2>
<azonenberg> (also rate limiting will affect performance on things like loading a session or dragging triggers and stuff like that too... so if we can get rid of it on some scopes that would be great)
<d1b2>
<fredzo_72653> Yes that was the most significant gain : session start when grabbing all the scope parameters
<d1b2>
<fredzo_72653> What do you mean by faster scopes ?
<d1b2>
<fredzo_72653> 2000X HD is on the "faster" side right (comapred to 2000X+) ?
<d1b2>
<azonenberg> well i mean like 6000A series and such
<d1b2>
<fredzo_72653> Anyway it's the only Siglent I have (sadly ;-))
<d1b2>
<azonenberg> i recall the 6000A performing better than the 2000x+ at least
<d1b2>
<azonenberg> but i dont know how common the platform is
<d1b2>
<fredzo_72653> My understanding is that they have a common software platform from 2000X+ to 7000A, but different hardware (obviously) and firmware lifecycle across models
<d1b2>
<azonenberg> yeah thats the point, i dont know how much faster the CPUs on the 6000A vs 2000X HD is
<d1b2>
<azonenberg> which likely affects scpi performance
<d1b2>
<azonenberg> but i dont actually know where the bottleneck is
<d1b2>
<fredzo_72653> So new features and bugfix will appear on one model first and the propagate to the rest of the line
<d1b2>
<azonenberg> i.e. are they just saturating the cpu or is there some slow bus between capture memory and cpu, etc
<d1b2>
<fredzo_72653> Yep no idea either...
<d1b2>
<fredzo_72653> So what do you think @azonenberg , should I prepare a PR with command line separation and deactivation of rate limiting for newer models (from 2000X+ and above) ?
<d1b2>
<azonenberg> Yeah i think so
<d1b2>
<azonenberg> i would keep the rate limit on for 2000x+ though
<d1b2>
<azonenberg> at least until someone with one tests it
<d1b2>
<azonenberg> But if you wanna enable it for newer models that are fixed, great
<d1b2>
<josHua> I think that all cases is not necesary! Thunderscope doesn't need to always report a percentage of completion -- it can be an optional feature of a driver. But the DHO4000 driver probably always should because these things are slow.
<d1b2>
<azonenberg> What i mean is the UI needs to account for it
<d1b2>
<azonenberg> We'd most likely add two methods to the instrument class, one for "is progress available" and a second for actually getting the current progress
<d1b2>
<josHua> I should mock up some not-wired-up UI in ImGui code to show how I think this would work
<d1b2>
<azonenberg> It needs to account for multiple instruments too. the most natural place for me to put it would be the "manage instruments" dialog but that's a bit out of view
<d1b2>
<azonenberg> also, LeCroy can get slow for deep waveforms (100M points) but is fast for shallow ones
<d1b2>
<azonenberg> So i think we should still have it be situational
<d1b2>
<josHua> ah I want it in the stream browser at left, along with #760 in there too
<d1b2>
<azonenberg> i.e. displayed if an AcquireData() call has taken more than 50ms
<d1b2>
<azonenberg> Hmmm
<d1b2>
<azonenberg> Feel free to send some mockups. I've got other stuff on my plate but will certainly consider feedback
<d1b2>
<azonenberg> I may poke technobaboo (GUI design consultant i've paid for a few hours from) as well
<d1b2>
<azonenberg> i was gonna set up a call with them some time soon once i had finished implementing feedback from the previous session
<d1b2>
<josHua> I was thinking the interface from the driver would be one method for 'tell me everything you know about your capture states'? which is a tagged enum of: * "I am not ready to capture for some reason / in a fault state" * "I am completely idle, but ready to capture if you asked" * "I am trigger-armed but waiting for my trigger group to trigger" * "I have triggered and am downloading data to the host, and, optionally, I am x% complete"
<d1b2>
<azonenberg> So we have that somewhat already in terms of the PollTrigger() driver method
<d1b2>
<azonenberg> What we lack is the progress feedback. also, trigger groups are a ngscopeclient feature not a libscopehal feature at the moment
<d1b2>
<azonenberg> i.e. the driver has no idea if it's in a group or not
<d1b2>
<azonenberg> it just knows you armed the instrument's trigger or not
<d1b2>
<josHua> sure, 'I am waiting for my trigger to fire' then
<d1b2>
<azonenberg> so "I am armed and awaiting a trigger event"
<d1b2>
<azonenberg> yeah
<d1b2>
<josHua> this may be a bit mask of flags, too
<d1b2>
<azonenberg> anyway, that exists already. Better visual feedback of it would be fine, in the instrument properties dialog at minimum
<d1b2>
<azonenberg> however most of the RemoteBridgeOscilloscope-derived drivers do not fully implement this interface the way they should
<d1b2>
<azonenberg> i've wanted to go back and fine tune and see if there is a way to fix it but tl;dr they always return 'trigger fired' and then AcquireData() blocks until waveforms show up
<d1b2>
<josHua> like CAPTURE_READY | CAPTURE_ARMED | CAPTURE_DOWNLOADING, I suppose. there could be scopes that are CAPTURE_ARMED | CAPTURE_DOWNLOADING, and there could be scopes that are ~(CAPTURE_ARMED & CAPTURE_DOWNLOADING)
<d1b2>
<josHua> sure, I mean, even for those, we could add a different state, "I am waiting to give you data for some reason, but I do not really know why", and let the UI figure it out
<d1b2>
<azonenberg> in any case, adding an API to return "current progress of downloading data" is probably a good idea. It would require some changes to some drivers in order to support that (i.e. not doing one big read call)
<d1b2>
<azonenberg> PollTrigger() currently is something you should only call from InstrumentThread
Yamakaja has joined #scopehal
Yamakaja has joined #scopehal
<d1b2>
<azonenberg> Since it is not idempotent (it affects instrument state when you query it)
<d1b2>
<josHua> oo there is a CodePen for Dear Imgui Javascript bindings, maybe I could just, like, type this
<d1b2>
<azonenberg> So we'd need to mirror that state somewhere the gui thread can freely query
<d1b2>
<azonenberg> But yeah the big driver change needed will be defining an API for "current status of waveform download". The rest is fairly straightforward GUI stuff
<d1b2>
<josHua> ok I have mocked up some UI in this ImGui Sandbox and it is... stuck in this text editor
<d1b2>
<josHua> argh
<d1b2>
<fredzo_72653> Bad news, after I did more testing I realized that some command are dropped when completely removing rate limiting (like "WAVEFORM:WIDTH" which kind of breaks acquisition logic \o/) :-/// I was able to reduce it to 5ms thought, that's better than nothing...
<d1b2>
<josHua> I have no idea how to get this to use the nicer font
<d1b2>
<azonenberg> we actually load a ttf font manually
<d1b2>
<azonenberg> its a pain
<d1b2>
<josHua> aha so it is not a default or something
<d1b2>
<azonenberg> nope its not in imgui
<d1b2>
<josHua> this has a lot of hardcoded stuff anyway, it is just the environment I was using to mess with it
<d1b2>
<josHua> updated, now with 100% more scopehal DejaVuSans
<d1b2>
<azonenberg> Lol
<d1b2>
<azonenberg> (on that note, i eventually want to try having preferences default to your OS default font so it fits better rather than shippign our own font)
<d1b2>
<azonenberg> vendoring dejavu was simply the lowest effort solution
<d1b2>
<josHua> the problem with a cross platform GUI is that it is native nowhere
<d1b2>
<josHua> maybe the '4gsps', '50 msamples', '50mV', '-5V' should be blue and underlined, such that it is obvious that they can be clicked on, and then clicking on them causes the relevant config box top op up
<d1b2>
<azonenberg> I'm still actively exploring the stream browser UI and ways to make it better
<d1b2>
<azonenberg> But single clicks there are a no-go
<d1b2>
<azonenberg> sinec the primary intended use of the browser is to click and drag to a waveform view or the filter graph
<d1b2>
<azonenberg> so opening any config has to be double click based
<d1b2>
<josHua> why is single click a no-go? click and drag is different than click
<d1b2>
<azonenberg> (to keep things consistent, we dont want some config to be opened by single and some by double)
<d1b2>
<azonenberg> I dont like the idea of single click on a draggable object doing anything other than selecting it (if this makes sense)
<d1b2>
<josHua> also possibly only the header TreeNode is draggable, you would not expect to drag the 'sample rate' groupbox
<d1b2>
<azonenberg> Yeah
<d1b2>
<azonenberg> anyway, i'll think about it and we can also discuss more on the developer call tuesday if we ahvent figured out a plan by then
<d1b2>
<azonenberg> are you gonna be on the call?
<d1b2>
<josHua> I feel like I have just been suckered into becoming a developer
<d1b2>
<josHua> what time is the call?
<d1b2>
<azonenberg> 14:00 seattle time tuesday
<d1b2>
<josHua> sighs deeply sure, I can join.
<d1b2>
<azonenberg> lol
<d1b2>
<josHua> send an invite to joshua@accelerated.tech?