<d1b2>
<azonenberg> @fredzo_72653 Can you submit that caching bit as a separate PR so I can merge it now?
<d1b2>
<azonenberg> just the driver changes to add caching
<d1b2>
<josHua> out has been clocked from work. I had been promising myself all day that I would get the candy of getting to poke at open source stuff if I finished my work and I finally did, so we'll see if I can actually convince myself to do it.
<d1b2>
<josHua> @fredzo_72653 @azonenberg I think my plan is I will adapt SCPITransport::ReadRawData to take a callback for progress reporting and to read chunks. eventually I will want RecvLooped to provide a progress callback, but that is more plumbing than I wish to do at this instant and shall be Future Work
<d1b2>
<azonenberg> Hmm. The other option is to refactor each driver to simply call ReadRawData multiple times and report progress after each chunk
<d1b2>
<azonenberg> I don't have a really strong feeling as to which is better
<d1b2>
<josHua> that is what is currently done, but there is a good point around 'the underlying layer knows if there is a good time to report this, and what an optimal chunk size is'
<d1b2>
<azonenberg> Yeah
<d1b2>
<azonenberg> also it avoids having to add chunking to each driver
<d1b2>
<azonenberg> instead you can just pass the callback from the base class once
<d1b2>
<josHua> you still have to pass in a lambda, but the lambda is simple
<d1b2>
<josHua> though in the case of the Riglol, the lambda is somewhat more complicated because progress is actually 'progress of this 250k-point chunk', not 'progress of the entire download'
<d1b2>
<josHua> ok, I have this refactored the way I want it, I think. in so doing, I broke the start-time-muting logic, but I'll fix that up momentarily
<_whitenotifier>
[scopehal] azonenberg 3388cbe - Merge pull request #911 from fredzo/oscilloscope-download-progress-api Oscilloscope download progress API
<d1b2>
<josHua> oh my claim is that you shoudl probably squash and merge these commits since a bunch have weird intermediate state but this is OK with me too
<d1b2>
<azonenberg> @josHua merged the PR but not updating the scopehal pointer in -apps yet
<d1b2>
<azonenberg> there's a few issues to fix on my end
<d1b2>
<josHua> I updated the pointer in my branch for #765 since obviously it is mandatory there. I'm going to try to put the 'slow capture / fast capture' hysteresis back and then I'm going to declare happiness with this
<d1b2>
<azonenberg> Sounds good
<d1b2>
<azonenberg> There's a few warnings that -Werror in my gcc version
<d1b2>
<josHua> /o\
<d1b2>
<azonenberg> so i have to fix those before i update the pointer upstream
<d1b2>
<azonenberg> looks like an easy fix just have to rebuild and find them on this box since i moved from the lab to my desk
<d1b2>
<azonenberg> ok so it looks like it doesnt like you giving the lambda and the argument to the lambda the same name
<d1b2>
<azonenberg> Yay. Going to bed shortly, I need to spend some time working on doxygen and close some of my open editor tabs before i do anything else
<d1b2>
<azonenberg> Do you think it's ready to review and merge yet?
<d1b2>
<josHua> I think it's ready to review, at least, architecturally, and I think it is ready for someone else to play with. as I noted in that comment, I haven't looked at the diff as a whole yet, so it is very possible that there are embarrassing TODOs or other micro-level code quality errors that woudl be trivially caught by, like, reading it
<d1b2>
<azonenberg> I'll have a look tomorrow then and see
<d1b2>
<azonenberg> I want to get my hands on it and start adding my own sidebar features
<d1b2>
<azonenberg> since this really ties into my refactoring of the other instrument dialogs anyway
<d1b2>
<azonenberg> generally unifying everything to use ChannelPropertiesDialog and eliminate global instrument settings dialogs
<d1b2>
<josHua> while I was walking around earlier today I was also thinking of using the STream Browser for other discoverability things. like adding a 'Connect a new instrument...' hyperlink that would just do the sugar of popping open the 'Add' menu, to make it very obvious where you're going to start
<d1b2>
<azonenberg> Let's get this merged before you do too much more tinkering. That said, I'm all for improving the discoverability in general
<d1b2>
<azonenberg> and making the first-run experience less confusing
<d1b2>
<josHua> I agree
<d1b2>
<azonenberg> The other thing i still have to do is finish the eye pattern unit test (which has turned up some interesting edge cases i have to work on)
<d1b2>
<azonenberg> and get the new cairo-free mask hit test code merged
<d1b2>
<josHua> if I'm going to spen dmore time on this in the near future I probably want to squash some annoying state sync bugs in the Rigol driver also (the Rigol driver often somehow does not manage to set the scope to the sample rate it wants, or such things)
<d1b2>
<azonenberg> oh fun
<d1b2>
<azonenberg> Yeah that should get fixed
<d1b2>
<josHua> but really for my hobby time I need to spend time on my own crowdsupply project also
<d1b2>
<josHua> hm, one interesting application of this that I could not really meaningfully do with the scope's on board capability is measure what the unfiltered bandwidth of the unit is, using a Bodnar pulse generator
<d1b2>
<josHua> the Bodnar pulse generator produces a low-rise-time (specified at 30ps) 10MHz square wave, so I can take a very long capture of this and have ngscopeclient do an FFT of it and see how it compares to an ideal spectrum of a 10MHz square wave
<d1b2>
<fredzo_72653> Great, thanks for the merge @azonenberg! So need for a separate PR for digital threshold caching right ? @josHua nice job to have moved the download progress update to ReadRawData(), that will make implementing progress bar in other drivers much easier! I think you broke progress on Siglent driver though from what I read \o/ but no worries, I'll fix it tonight 😉
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 [Remote host closed the connection]
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 [Remote host closed the connection]
ALTracer has joined #scopehal
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
octorian has quit [Remote host closed the connection]
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
octorian has joined #scopehal
ALTracer has quit [Ping timeout: 252 seconds]
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 [Remote host closed the connection]
ALTracer has joined #scopehal
ALTracer has quit [Client Quit]
<d1b2>
<josHua> it ran happily overnight without crashing, at least
ALTracer has joined #scopehal
ALTracer has quit [Remote host closed the connection]
ALTracer has joined #scopehal
t4nk_fn has quit [Remote host closed the connection]
t4nk_freenode 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
<d1b2>
<fredzo_72653> Yep I missed the commit where you fixed the digital channel index, you just left one bad index on the download finish call, no big deal. That being said, the 32k chunck size is too big for progress on digital channels (where data is smaller since it is 8 points per byte).
<d1b2>
<fredzo_72653> Is it OK if I lower it to preserve smooth progress ?
<d1b2>
<josHua> sure, but presumably that is fast enough that it should be visually smooth anyway?
<d1b2>
<josHua> 8k or so should be fine too without substantial performance degradation
<d1b2>
<fredzo_72653> Not great as you can see, I'll try 8k
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
<d1b2>
<josHua> oh, I consider that to be more than good enough 🙂
ALTracer has quit [Read error: Connection reset by peer]
ALTracer has joined #scopehal
<d1b2>
<fredzo_72653> Yes your right, lowering the chunck size doesn't change a thing, prosgress is too fast for our eyes to see 🙂 The step at 50% is only due to the scope's pagination 😅
<d1b2>
<fredzo_72653> @josHua did you see my comment on the StreamBrowserDialog PR ? I think we should not show badges on fast download time channels to prevent flicjering:
<d1b2>
<azonenberg> yeah i wouldnt go much below 4-8K as thats probably the kernel buffer size
<d1b2>
<azonenberg> and yes agreed this is exactly what i suggested the timeout to prevent
<d1b2>
<azonenberg> maybe if the refresh speed is above some rate just show a green "active" or similar?
<d1b2>
<josHua> I did see that comment, I'm ok either way, feel free to make that change -- I have a few other things I need to do today
<d1b2>
<azonenberg> so you can still tell triggering vs stopped
<d1b2>
<azonenberg> (if you have a bunch of scopes in different trigger groups)
<d1b2>
<josHua> that would be a good solution to that, I was thinking I liked the flicker as an indicator that the system is alive
<d1b2>
<fredzo_72653> OK I'll see what I can do not problem
<d1b2>
<josHua> so maybe the logic should be that if the channel is not slow, and the most recent download started within the 'becomes slow' hysteresis window, then we render 'active' no matter what the state
<d1b2>
<fredzo_72653> This whole thing is starting to look pretty good BTW ! 🙂
<d1b2>
<josHua> yeah this feels a lot more usabler
<d1b2>
<azonenberg> Yeah i'm really liking the direction its going
<d1b2>
<azonenberg> i cant wait to get it merged and integrate support for more types of instrument
<d1b2>
<david.rysk> yeah this is nice
<d1b2>
<azonenberg> i expect it'll evolve a bit once we get more people using it
ALTracer has quit [Ping timeout: 252 seconds]
<d1b2>
<josHua> oh yeah, so, while I was letting this run overnight to make sure it did not eat it, I captured a long running accumulating FFT of a Leo Bodnar pulse generator, and I realized it would be interesting to use this to figure out what the scope's front end spectral response actually is
<d1b2>
<josHua> specifically, I captured this. the 'obvious' thing to do is to overlay the curve of an ideal 10MHz square wave over the FFT, and see how far down each harmonic is from what one should expect. can I get ngscopeclient to do that for me somehow?
<d1b2>
<josHua> the third harmonic ought be -4.77 dB from the fundamental, and the fifth ought be -6.99 dB, and the seventh ought be -8.45 dB. but there is a much larger falloff in the first few harmonics than I ought expect from a square wave.
<d1b2>
<azonenberg> Interesting
<d1b2>
<azonenberg> Hmmmm
<d1b2>
<azonenberg> i wonder if there's a scaling error somewhere
<d1b2>
<azonenberg> I just tried with a simulated ideal squarewave at 10 MHz
<d1b2>
<azonenberg> I get 6.127 dBm for the first harmonic and -3.454 for the third and -7.0709 for the fifth
<d1b2>
<azonenberg> note that this is power not ampitude we're measuring here
<d1b2>
<josHua> the peak amplitude varies quite a bit with selection of FFT window, I wonder if I need to be integrating under the curve of each peak
<d1b2>
<josHua> measuring power does not make sense though, because... we are measuring voltage, and the fourier transform of voltage is still voltage
<d1b2>
<azonenberg> Yeah as of now the fft defaults to outputting power assuming a 50 ohm load
<d1b2>
<azonenberg> since its intended for RF
<d1b2>
<azonenberg> file a ticket for adding more output formats i guess?
<d1b2>
<azonenberg> glscopeclient had an option for integrating in-band power in a FFT trace. it doesnt look like we ever got that in ngscopeclient
<d1b2>
<azonenberg> file a ticket for that
<d1b2>
<azonenberg> oh wait no
<d1b2>
<azonenberg> we do, it shows up in the cursors window as an extra column
<d1b2>
<josHua> aha ok so everything being in dBmW makes a lot more sense
<d1b2>
<josHua> divide dBmW by 2 to get something close to dBmV, and now it seems to look right
<d1b2>
<fredzo_72653> @josHua I had to remove calls to ChannelDownloadStatusUpdate() with DOWNLOAD_NONE at the end of AcquireData() to prevent flickering, hope you don't mind...
<d1b2>
<josHua> hm, why so?
<d1b2>
<josHua> that should not be necessary
<d1b2>
<fredzo_72653> We might still have to tweek the switching logic from fast to slow maybe to have it consistent across channels of a given scope
<d1b2>
<fredzo_72653> In the current state you maight have the first channel in fast mode while the rest of them are in slow mode, juste because the first channel well ends first !...
<d1b2>
<josHua> ok maybe I will look at this tonight 🙂 I am going to try to forc emyself to do boring work
<d1b2>
<azonenberg> yeah the mode to use should be set per instrument not per channel
<d1b2>
<fredzo_72653> About that, it makes the badge disappear for a glimpse when looping on AcquireData() calls
<d1b2>
<fredzo_72653> Sorry guys I have to go to bed !... (1am here)