<d1b2>
<fredzo_72653> OK I'll have a look, there's not many of them implementing that method.
<d1b2>
<fredzo_72653> The UI will shorten and/or remove the progress bar and label if there is no room for it.
<d1b2>
<josHua> OK I am back at my desk in my office, which, conveniently, is where my dho4000 is, so I will try this. I had planned to work on something else this evening but the office is the only room that has air conditioning and everywhere else in the house is 28C still.
<d1b2>
<josHua> so my thoughts on the download progress API: probably I think it should just return a float, and use chunks in whatever sizes it finds convenient internally, rather than trying to read 1% at a time?
<d1b2>
<azonenberg> I was originally planning to be bringing up my new 100G router tonight. Turns out the mobo and CPU i ordered aren't compatible so I'm working on the eye pattern unit test for the cairo removal instead :p
<d1b2>
<azonenberg> Yes
<d1b2>
<josHua> so I am going to try to clean this up a little, if that is ok with you, @fredzo_72653
<d1b2>
<azonenberg> Absolutely don't have the readout logic work around progress bar, do the opposite: read arbitrary sized chunks that are conveinient
<d1b2>
<josHua> I also think that the question of whether to display progress or not based on timing is a question for the UI, rather than for libscopehal
<d1b2>
<azonenberg> Agreed
<d1b2>
<azonenberg> Progress should always be reported
<d1b2>
<azonenberg> the UI should make the decision on whether to show it
<d1b2>
<azonenberg> (headless test cases, for example, may have different requirements than a GUI)
<d1b2>
<josHua> and finally I want to make the "status badge" higher priority than the progress bar (i.e., further to the right) and I think I want to make the progress bar disappear after either one or all of them are 100% (I have not decided which yet)
<d1b2>
<fredzo_72653> OK no problem, just make sure that downloading to small chuncks does not degrade download performance
<d1b2>
<josHua> but first I will build this and run a nice slow capture on my DHO4000
<d1b2>
<fredzo_72653> Using "1%" chuncks si the sweet spot to have a smooth progress bar without degrading performance from what I have tested
<d1b2>
<josHua> I had planned to read 32 or 64 kbytes at a time or something on Rigol, and devices with slower links could choose different chunks izes
<d1b2>
<azonenberg> I would agree, status badge is more important than progress if you dont have space for both
<d1b2>
<azonenberg> Yeah agreed. read in reasonable chunks for the transport layer
<d1b2>
<azonenberg> and then tell the driver whatever your current progress is
<d1b2>
<azonenberg> if you have to round that to an integer you can do that
<d1b2>
<azonenberg> but a float makes more sense
<d1b2>
<josHua> there is an 'advanced thing' that I do not think is going to happen for the initial version of this, where both the badge and the progress bar can shorten, but that requires... thinking with portals
<d1b2>
<azonenberg> I want to get this merged soon so i and more people can tinker with it on different scopes, fast and slow, multi scope, etc
<d1b2>
<azonenberg> my lecroys with tens to hundreds of megapoints can take a very long time to download a single waveform
<d1b2>
<josHua> the algorithm right now is that you place a thing greedily with as much space as you can (and the badges shorten to defined shortenings if there is not enough room), and having to consider many things and packing them in place seems annoying, so I want that to be a Much Later thing
<d1b2>
<azonenberg> while the thunderscope will push as fast as ngscopeclient can render it
<d1b2>
<azonenberg> This actually dovetails nicely with me wanting to remove a lot of the popup dialogs for various non-scope instruments
<d1b2>
<azonenberg> so i want to try to kind of tie that together
<d1b2>
<azonenberg> e.g. it solves the question of where to put the global on/off switch for a power supply that isn't a channel setting
<d1b2>
<azonenberg> We might want to rename this from "stream browser" to something else to reflect the more expanded function
<d1b2>
<azonenberg> but i like the direction it's going
<d1b2>
<azonenberg> Do you think you can get it to a good state for merging by later this week? good meaning that it doesn't make any uncached API calls every frame, and it's at least functional for the drivers that you've added progress callbacks for and doesn't fail horribly on others
<d1b2>
<josHua> I was searching Google Photos for 'lecroy' trying to find a stupid joke I had made a long time ago, and apparently Google Photos thinks that anything that has lights or waveforms is a Lecroy
<d1b2>
<azonenberg> lol
<d1b2>
<josHua> this is not the exact version of the joke I was looking for but it's close enough
<d1b2>
<fredzo_72653> I'll let Joshua move to float if needed, I'm done with this 😉
<d1b2>
<josHua> yep I'll take a crack at it. should I put it on my own scopehal fork or should I push to a branch on yours?
<d1b2>
<fredzo_72653> Whatever suits you, I can give you access to the repo if needed
<d1b2>
<azonenberg> Anyway, once you two are in agreement and happy with the state of the work let me know and i'll have a look
<d1b2>
<azonenberg> At this stage of the project i don't want to have too many long term diverging branches
<d1b2>
<josHua> whee it works, yes, it is downloading and inching along on my DHO4000
<d1b2>
<azonenberg> i'd rather merge often so we get more eyes on it
<d1b2>
<fredzo_72653> Invite sent ! 👍
<d1b2>
<josHua> ok cool thanks!
<d1b2>
<josHua> thinking more about this, the interplay where InstrumentChannel has SetData, and somehow it is the Oscilloscope's responsibility to queue pending waveforms and have this 'pending waveform' interface is at least a little hokey
<d1b2>
<josHua> ideally you would like the download status interface to sit next to the Data accessor on the InstrumentChannel, since that is kind of two sides of the same coin
<d1b2>
<josHua> so I think minimally this wants to mvoe to InstrumentChannel instead of OscilloscopeChannel, and, really, the relationship between that and the queued-waveform thing probably could use a rethink too
<d1b2>
<azonenberg> yeah. the intent of queueing is to allow downloading of one waveform to run concurrently with the filter graph on the previous one
<d1b2>
<azonenberg> i.e. we dont want to block the scope while the filter graph is processing data
<d1b2>
<josHua> sure, though it seems like the queuing shoudl be a feature of the channel, rather than a feature of the oscilloscope
<d1b2>
<azonenberg> but we need the waveforms used by the filter graph to be fixed and not moving around under it
<d1b2>
<azonenberg> no, because a single acquisition has data from all the channels
<d1b2>
<azonenberg> the graph doesnt re-run until it's all ready
<d1b2>
<azonenberg> Longer term I want to move away from the whole concept of a "current waveform" and have scopes simply spit out data somehow but i dont yet know how that will look, it'll be a major refactoring and not happen before v0.1 or probably v0.2
<d1b2>
<josHua> ok I understand why this is a solution to this and I do not have a better one off the top of my head, but it does seem like it kind of breaks abstraction boundaries
<d1b2>
<azonenberg> i.e. we will have a more linear pipeline of waveform data blocks running through various processes
<d1b2>
<azonenberg> vs the lock-stepped flow we have now
<d1b2>
<josHua> right
<d1b2>
<azonenberg> but integrating that with the GUI and things lke cursors will be decidedly nontrivial
<d1b2>
<josHua> yes
<d1b2>
<azonenberg> But yeah, a lot of this complexity grew over time organically as i ran into performance bottlenecks and tried to push to higher and higher wfm/s rates
<d1b2>
<josHua> this is probably related to the concept that a capture is not the same as the current state of the world
<d1b2>
<josHua> i.e., you may have programmed the instrument for a different offset, going forward, but a capture should know what offset it came with, etc
<d1b2>
<azonenberg> yeah
<d1b2>
<azonenberg> That's a real problem, there's a ticket for it
<d1b2>
<azonenberg> but it's also way too big of a problem to tackle before v0.1
<d1b2>
<josHua> yes it is
<d1b2>
<josHua> I have started in on this but have made minimal progress, mostly because I am quite tired, so I am going to bed. my plan is: 1) move these three APIs to InstrumentChannel: c++ virtual DownloadState GetDownloadState(); virtual float GetDownloadProgress(); virtual double GetDownloadStartTime(); which, in InstrumentChannel, always return DOWNLOAD_UNKNOWN. 2) override these in OscilloscopeChannel, along with adding a setter that the driver will
<d1b2>
call into, as appropriate 3) then continue with similar logic as exists, porting the existing oscilloscope setters over to that
<d1b2>
<fredzo_72653> Yea I hesitated between InstrumentChannel and OscilloscopeChannel when I implemented but figured that waveform download only made sense for Oscilloscopes 🤷♂️
<d1b2>
<fredzo_72653> Maybe it should be the other way around: SetData should move from Instrument to Oscilloscope ? IDK...
<d1b2>
<fredzo_72653> OK after checking what uses SetData, it definitely can't be on OscilloscopeChannel 🙂
<d1b2>
<josHua> yeah, the dataflow architecture is not all that clearly defined
<d1b2>
<fredzo_72653> I guess it can make sense to download a waveform from a DMM (datalogger) or a Wavegen (source waveform) 🤷♂️
<d1b2>
<chille0417> I agree to that. I have a few of instrument with datalogging capabilities that are not an oscilloscope and are quite slow to transfer data.
<d1b2>
<chille0417> I'm not sure if they will ever get into scopehal. But if they do we might need an IrDATransport lol. 🙃
<d1b2>
<chille0417> I was thinking about how to communicate with instruments, without using ngscopeclient. Wouldn't it be nice to have a scopehal-gui that could open a GUI and have just the bare minimum needed to control one single instrument? I thinking about something that looks like and behave just as ngscopeclient. It could use imgui and share the same code as ngscopeclient.
<d1b2>
<chille0417> It would also be nice to have a scopehal-cli. It could be used to set and read configuration, read scalars and export waveforms to images. It might not be super useful for a scope. But it would be great for controlling something like an AWG or DMM.
<d1b2>
<chille0417> scopehal-cli --instrument hantek:365b --dmm-mode ac-voltage --range auto --read scopehal-cli --instrument owon:hds200 --awg-frequency 10k --awg-waveform sine --awg-amplitude 2.5 --awg-enable
<d1b2>
<azonenberg> I'm certainly open to ideas for different frontends
<d1b2>
<azonenberg> Yeah that's something we need to work on
<d1b2>
<azonenberg> Yeah if you look at how we have things right now anything that outputs waveform-esque data is derived from Oscilloscope
<d1b2>
<azonenberg> e.g. VNAs
<d1b2>
<azonenberg> as far as SetData being part of the channel, that's not entirely implausible (we'd need to discuss further), but any such major refactoring seems like something we should push to beyond v0.1 if it is going to happen
<d1b2>
<fredzo_72653> @josHua 🔼 here is the fix for GetDigitalThreshold() with cache added on all drivers implementing the method. It is now safe to call it in the Render method of the StreamBrowserDialog (I have uncommented the call).
<d1b2>
<fredzo_72653> Yep that was my conclusion when I searched for he best place to put the GetDownloadState() method 🙂
<d1b2>
<fredzo_72653> @josHua I'll start working on PSU visualization in StreamBrowserDialog tomorrow if it doesn't collide with your current work.
<d1b2>
<josHua> sounds good, I imagine it will not