azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
Fridtjof has quit [Quit: ZNC - http://znc.in]
Stary has quit [Quit: ZNC - http://znc.in]
Stary has joined #scopehal
Fridtjof has joined #scopehal
<_whitenotifier-4> [scopehal] azonenberg opened issue #922: PicoVNA: weirdness around memory depth - https://github.com/ngscopeclient/scopehal/issues/922
<d1b2> <azonenberg> @fredzo_72653 how does the stream browser code handle downloading waveforms from several channels in parallel?
<d1b2> <azonenberg> the PicoVNA takes a long time to do a sweep with a lot of points, but returns all s-parameters at once
<d1b2> <azonenberg> so you get all channels updating simultaneously
<_whitenotifier-4> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-docs/compare/e31f7e0db63c...42e69aedf875
<_whitenotifier-4> [scopehal-docs] azonenberg 42e69ae - Initial skeleton docs for 2-port shunt-through filter
<d1b2> <azonenberg> @fredzo_72653 also we should change "voltage range" to "range" (and eventually update the API names to match)
<d1b2> <azonenberg> since y axis unit is not always voltage
<d1b2> <fredzo_72653> I used "Vertical range" in https://github.com/ngscopeclient/scopehal/pull/921 didn't I ?
<d1b2> <fredzo_72653> But yes the method name is a bit missleading
<d1b2> <fredzo_72653> Parallel download progress should not be a problem (DemoOscilloscope does so too with the #pragma omp parallel for directive) The only thing is that the threshold used to hide/show download bar is based on the download time of the last channel which could be a problem if the last channel takes significantly less time than the others.
<d1b2> <fredzo_72653> Sorry i meant I used "Vertical range" in * https://github.com/ngscopeclient/scopehal-apps/pull/788
<d1b2> <azonenberg> well what i mean is, my current code only shows progress on the first channel
<d1b2> <azonenberg> i'm trying to figure out if its somethign i'm doing
<d1b2> <azonenberg> or if it's in the sidebar code
<d1b2> <azonenberg> will debug
<d1b2> <azonenberg> when i created the api, voltage was the only unit we had :p
<d1b2> <fredzo_72653> Well that's odd because the hide/show download status is global for a given instrument, so if you have it on first channel, you should have it on all unluss they report DOWNLOAD_NONE or DOWNLOAD_UNKNOWN status
<d1b2> <azonenberg> Yeah thats why i need to look at my code
<d1b2> <azonenberg> We'll see. i'm chasing a bunch of stuff at once and still have to review and merge the other PRs
<_whitenotifier-4> [scopehal-docs] azonenberg pushed 2 commits to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-docs/compare/42e69aedf875...01f566d0d644
<_whitenotifier-4> [scopehal-docs] azonenberg 01f566d - Merge pull request #93 from fredzo/master Added hid transport documentation section.
<_whitenotifier-4> [scopehal-docs] azonenberg closed pull request #93: Added hid transport documentation section. - https://github.com/ngscopeclient/scopehal-docs/pull/93
<d1b2> <josHua> it should work fine with downloads in parallel
<joshua_> @azonenberg what is the VNA story with scopehal these days? is it currently a useful VNA client? or going to be a useful VNA client? if so, should I (or someone) write a nanovna driver?