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
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 4 commits to master [+0/-0/±11] https://github.com/ngscopeclient/scopehal-apps/compare/e082092ade4a...10a66161db1f
<_whitenotifier-3> [scopehal-apps] azonenberg 3b55a01 - Disable protocol analyzer popup menu if no analyzer filters exist. If filter exists and window is open, don't allow spawning another. See #732.
<_whitenotifier-3> [scopehal-apps] azonenberg e61e09e - Merge branch 'master' of github.com:ngscopeclient/scopehal-apps
<_whitenotifier-3> [scopehal-apps] azonenberg 61799ba - PacketManager: Added a few trace messages
<_whitenotifier-3> [scopehal-apps] azonenberg 10a6616 - Fixed a few posible assertion failures during session close-and-restart caused by imgui pre-creating splits that we didn't expect to be there
mxshift has quit [Ping timeout: 252 seconds]
mxshift has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<d1b2> <vipqualitypost> what's the best way to update my build? i was just trying to git pull and then re-build, but that doesn't seem to quite work
<d1b2> <azonenberg> You probably didn't update the submodules. Your checkout should probably have git config submodule.recurse true set
<d1b2> <azonenberg> which should make a pull also update submodules
<d1b2> <azonenberg> (maybe we can add a note to documentation about this as a FAQ or something, submodules seem to cause a lot of folks trouble)
<d1b2> <vipqualitypost> also, for building the manual mentions using make -j4 but that has never worked for me - i always end up using cmake --build .. is that me doing something weird or should that be changed in the manual?
<d1b2> <azonenberg> i always build with make. are you running make from the build directory?
<d1b2> <vipqualitypost> yeah
<d1b2> <azonenberg> i have no idea what's up with your setup. I run cmake .. (config flags) once then just make in the build dir
<d1b2> <azonenberg> (usually -j32 or something since i have a lot of cores and ram)
<d1b2> <vipqualitypost> hmm
<d1b2> <vipqualitypost> just tried and i get make: *** No targets specified and no makefile found. Stop.
<_whitenotifier-3> [scopehal-apps] VIPQualityPost commented on issue #738: Scaling margin issues on Windows - https://github.com/ngscopeclient/scopehal-apps/issues/738#issuecomment-2319779569
<d1b2> <azonenberg> from the build dir try running cmake .. -DCMAKE_BUILD_TYPE=DEBUG
<d1b2> <azonenberg> then make -j4 or whatever
<d1b2> <vipqualitypost> no difference
<d1b2> <azonenberg> oh wait
<d1b2> <azonenberg> you're on windows?
<d1b2> <vipqualitypost> right now, yeah
<d1b2> <azonenberg> i think cmake wants to use ninja to build not make
<d1b2> <azonenberg> check pending PRs for scopehal-docs
<d1b2> <azonenberg> somebody submitted a proposed fix i have not validated
<d1b2> <vipqualitypost> ah
<d1b2> <vipqualitypost> ok, let me go try that. is there anything bad about building with cmake --build? performance and stability has been fine
<d1b2> <azonenberg> I've never used that mode, i dont know how it works or if there's any downsides
<d1b2> <david.rysk> works fine, just build in a separate dir than the source
<d1b2> <azonenberg> (in particular, if it does any parallelism or does the whole build sequentially)
<d1b2> <david.rysk> in fact that's a better option generally
<d1b2> <david.rysk> well ninja will always do parallel build
<d1b2> <azonenberg> @david.rysk can you look at the proposed PR for scopehal-docs windows?
<d1b2> <david.rysk> I did, looked fine
<d1b2> <azonenberg> Ok... i forget, do you have commit access? if so, go and merge it
<d1b2> <david.rysk> I do, just been too busy
<d1b2> <david.rysk> I think
<d1b2> <david.rysk> I'm not sure
<d1b2> <azonenberg> ok well please do so when convenient, if not let me know and i'll fix that
<d1b2> <david.rysk> alright no I don't
<d1b2> <david.rysk> there's also packaging instructions but I've had no time to check those
<d1b2> <azonenberg> hold off on the merge until you've had time to validate then
<d1b2> <azonenberg> packaging really needs work
<d1b2> <azonenberg> (including removing that awful binary blob if we havent already)
<d1b2> <azonenberg> also @david.rysk you'll be happy to know i now have the first of two FFTs in the demo scope gpu-ified
<d1b2> <azonenberg> (not merged yet)
<d1b2> <david.rysk> yay!
<d1b2> <azonenberg> should only be another hour or so to get it all done
<d1b2> <david.rysk> I mean even if they're CPU, if we don't have to rely on ffts for those, that'd be nice
<d1b2> <azonenberg> We have no CPU fft lib anymore
<d1b2> <azonenberg> we're all in on vkfft
<d1b2> <azonenberg> No point, because vulkan is so core to the application
<d1b2> <azonenberg> anything that can run it at all can run vkfft
<d1b2> <azonenberg> the only reason to keep CPU side FFTs around is unit tests to validate we are using vkfft correctly and that vkfft itself works properly
<d1b2> <azonenberg> Which is the only other use of FFTS, but since we don't redistribute those binaries i want to transition those to FFTW
<d1b2> <vipqualitypost> by the way, i really like the filter palette!
<d1b2> <vipqualitypost> is there a way to have nodes inherit the threshold from the parent node? the default is 0V but when I'm looking at DC coupled signals and trying to make a chain of filters, I need to go through and find the threshold for each to set it appropriately
<d1b2> <vipqualitypost> obviously still adjustable if you want, but just that the default when creating a new node from dragging the output of an existing node to just take that parameter along with it
<d1b2> <azonenberg> Thanks 🙂 It's brand new so if you have specific feedback on how to improve it, now is the perfect time
<d1b2> <azonenberg> I'm trying to make the UI more filter graph centric at a high level and i figured putting the filter set more in-your-face was a good way to do that
<d1b2> <azonenberg> power users can always hide it
<d1b2> <azonenberg> as far as "inherit the threshold" what exactly are you trying to do?
<d1b2> <azonenberg> what's the specific chain of filters?
<d1b2> <azonenberg> because most of the time i threshold a signal once and then pass the digital signal somewhere. For TIE and CDR yes, you do have to specify more than once
<d1b2> <azonenberg> I don't work with DC coupled signals fast enough that i care about jitter often enough for this to be a major annoyance
<d1b2> <azonenberg> or is there another path you're using i'm not aware of?
<d1b2> <vipqualitypost> ok, must be just my workflow then - i'm mostly doing TIE and CDR stuff right now. i actually usually capture AC coupled signals, there is no reason for this one to be DC, but I just had this specific trace capture hanging around and have been using it to play with processing.
<d1b2> <vipqualitypost> the ACRMS jitter of this signal seems larger than I would have expected, but I'm not totally sure that i'm calculating it correctly yet either.
<d1b2> <azonenberg> Yeah we can explore that. Making jitter calculations track third party tools more closely is on the TODO, one of the key things there is that i want to implement some PLLs that match standard reference PLLs rather than being homegrown
<d1b2> <azonenberg> but i dont know the DSP math enough to do that and havent had time to study it
<d1b2> <azonenberg> also, you can use the "AC couple" filter to remove a DC offset from a signal before doing anything else
<d1b2> <vipqualitypost> do you have a third party tool to reference? just curious generally how people are doing those types of measurements. I have been reading a bit on them and learning quite a lot
<d1b2> <azonenberg> (it computes the mean and subtracts from all samples)
<d1b2> <azonenberg> I have the LeCroy SDA-II software option on both of my big iron scopes
<d1b2> <vipqualitypost> I was looking for an AC couple filter but didn't find one before! Let me search again
<d1b2> <azonenberg> so i can acquire a waveform and calculate an eye, jitter, etc on the scope and with scopehal
<d1b2> <azonenberg> and compare the results
<d1b2> <azonenberg> we're usually close-ish, but not as close as i want
<_whitenotifier-3> [scopehal] azonenberg pushed 3 commits to master [+1/-1/±11] https://github.com/ngscopeclient/scopehal/compare/e619d6d7a973...cddb69f740ec
<_whitenotifier-3> [scopehal] azonenberg 0f73a71 - Continued transitioning TestWaveformSource away from FFTS
<_whitenotifier-3> [scopehal] azonenberg ca6cb78 - Merge branch 'master' of github.com:ngscopeclient/scopehal
<_whitenotifier-3> [scopehal] azonenberg cddb69f - TestWaveformSource: Removed final usage of FFTS. Still does final group delay correction, normalization, and noise insertion on the CPU but otherwise GPU accelerated.
<d1b2> <azonenberg> @david.rysk see above, can you test on a mac and verify this works?
<d1b2> <azonenberg> if so, we can move FFTS to a test-only dependency (will need some build script refactoring) as a stepping stone to full deprecation
<d1b2> <vipqualitypost> i just built it on arm mac (thanks for your submodule hint earlier) and builds/works seemingly fine (calculate FFT?)
<d1b2> <azonenberg> No, this is the demo scope specifically
<d1b2> <azonenberg> the demo scope used to do software FFTs for channel emulation on the PRBS31 and 8B10B signals
<d1b2> <azonenberg> Now it's all done on the GPU and we no longer use FFTS
<d1b2> <azonenberg> the software library
<d1b2> <azonenberg> Which means now the only user of FFTS should be unit tests, although i haven't removed it from the cmake scripts yet
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal/compare/cddb69f740ec...97e3f6370e37
<_whitenotifier-3> [scopehal] azonenberg 97e3f63 - Removed FFTS references from libscopehal cmakelists
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/10a66161db1f...a57426e90c97
<_whitenotifier-3> [scopehal-apps] azonenberg a57426e - Updated to latest scopehal. Moved FEFTS check to BUILD_TESTING block since it's now only used when building unit tests
<d1b2> <azonenberg> Woop, FFTS is now officially gone from the build except for unit tests
<d1b2> <david.rysk> yay! trying build now
<d1b2> <azonenberg> (unit tests are temporarily broken by this, fix coming in a minute)
<d1b2> <azonenberg> but the build with BUILD_TESTING off should work
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/a57426e90c97...1a704437bf09
<_whitenotifier-3> [scopehal-apps] azonenberg 1a70443 - Fixed broken build for unit tests
<_whitenotifier-3> [scopehal] azonenberg closed issue #660: Replace FFTS with vkFFT In all library (non-test) code - https://github.com/ngscopeclient/scopehal/issues/660
<_whitenotifier-3> [scopehal] azonenberg commented on issue #660: Replace FFTS with vkFFT In all library (non-test) code - https://github.com/ngscopeclient/scopehal/issues/660#issuecomment-2319984622
<_whitenotifier-3> [scopehal-apps] azonenberg commented on issue #739: macOS build failing with ffts.h error - https://github.com/ngscopeclient/scopehal-apps/issues/739#issuecomment-2319985651
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/1a704437bf09...66924513f488
<_whitenotifier-3> [scopehal-apps] azonenberg 6692451 - Moved ffts.h inside APPLE_SILICON ifdef guard to prevent false test failures on macos
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-apps/compare/66924513f488...7ae9f10061a5
<_whitenotifier-3> [scopehal-apps] azonenberg 7ae9f10 - Fixed one more ffts.h include for macos
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Ekho has joined #scopehal
<_whitenotifier-3> [scopehal] fredzo opened pull request #879: Siglent sds2000 xhd fix - https://github.com/ngscopeclient/scopehal/pull/879
<_whitenotifier-3> [scopehal-apps] fredzo opened pull request #740: Siglent sds2000 xhd fix - https://github.com/ngscopeclient/scopehal-apps/pull/740
bvernoux has joined #scopehal
<_whitenotifier-3> [scopehal-apps] membranophonist commented on issue #739: macOS build failing with ffts.h error - https://github.com/ngscopeclient/scopehal-apps/issues/739#issuecomment-2321412908
bvernoux has quit [Quit: Leaving]
<d1b2> <azonenberg> @fredzo_72653 what are your thoughts on inverting the preference setting for SDS HD
<d1b2> <azonenberg> have it be a default-off setting to force 8 bit mode
<d1b2> <azonenberg> while the normal mode is 8 bit if non-HD and 16 bit if HD
<d1b2> <johnsel> did my work help you any bit?
<d1b2> <azonenberg> I referenced it somewhat but was also making more sweeping changes to the demo scope
<d1b2> <azonenberg> in order to change the channel model
<d1b2> <johnsel> HURRAY
<d1b2> <azonenberg> (which had been on the wishlist for a while)
<d1b2> <johnsel> finally a an indirect useful contribution
<d1b2> <azonenberg> now we use an actual vna-derived lossy channel model
<d1b2> <azonenberg> so the demo scope waveforms look a lot more physically plausible than what we had lol
<d1b2> <johnsel> sure I wouldn't expect you not to make things more fancy
<d1b2> <johnsel> but great work, finally dropping ffts
<d1b2> <azonenberg> i mean that had been on the todo for ages and this was a good time as any to do it
<d1b2> <azonenberg> anyway, we still need docs updated and we still need ffts -> fftw in unit tests
<d1b2> <azonenberg> if you feel like working on either of those
<d1b2> <johnsel> david didn't poke you about it?
<d1b2> <johnsel> because he asked me yesterday about my work on it
<d1b2> <azonenberg> what i meant was the better channel model
<d1b2> <johnsel> ooh lol
<d1b2> <david.rysk> my annoyance with FFTW is that the most recent release is from September 2021
<d1b2> <david.rysk> and is missing ARM Mac fixes
<d1b2> <johnsel> I meant to joke that as good as any was someone poking you for it over a long period of time
<d1b2> <david.rysk> so you have to patch it locally or use a bleeding edge build
<d1b2> <azonenberg> wait so are all the fft libs unmaintained? lol
<d1b2> <david.rysk> oh it's maintained
<d1b2> <david.rysk> they're just doing the old "release when we feel it's ready"
<d1b2> <azonenberg> oh ok
<d1b2> <azonenberg> I am OK with those unit tests not running on arm mac for now
<d1b2> <azonenberg> especially if its still being maintained and there will be an update eventually
<d1b2> <david.rysk> homebrew and macports may ship a patched version
<d1b2> <azonenberg> ultimately i just want ffts and cairo gone and am not super picky about how :p
<d1b2> <david.rysk> I haven't checked yet
<d1b2> <david.rysk> yeah cairo is the main thing left
<_whitenotifier-3> [scopehal] azonenberg closed pull request #879: Siglent sds2000 xhd fix - https://github.com/ngscopeclient/scopehal/pull/879
<_whitenotifier-3> [scopehal] azonenberg pushed 4 commits to master [+5/-2/±20] https://github.com/ngscopeclient/scopehal/compare/97e3f6370e37...e1bbbeb498a2
<_whitenotifier-3> [scopehal] azonenberg e1bbbeb - Merge pull request #879 from fredzo/siglent-sds2000XHD-fix Siglent sds2000 xhd fix
<d1b2> <david.rysk> I am looking at this https://github.com/a-e-k/canvas_ity
<d1b2> <david.rysk> but there might be better options
<d1b2> <david.rysk> we just need something that can draw lines in a buffer of uint32_t's and fill polygons
<d1b2> <azonenberg> We can also convert the buffer over to uint8 or bool if you find a library that can handle such surfaces
<d1b2> <azonenberg> saving ram in the process
<d1b2> <azonenberg> we only use the uint32 format because thats what cairo wanted
<d1b2> <azonenberg> @fredzo_72653 in particular, for LeCroy the way we do this type of preference is that we default to the native ADC format (8 bit for 8-bit scopes, 16-bit for HD scopes)
<d1b2> <azonenberg> and the override forces 16 bit transfer mode even on 8 bit scopes
<d1b2> <azonenberg> because there's not a significant speed benefit, and forcing 16 bit transfer mode gives you some better resolution for the internal flatness corrections even on 8 bit scopes so eye patterns etc look better
<d1b2> <fredzo_72653> @azonenberg that's what I did at first and then had second thoughts thinking using 16bit parameter would be more consistent with the Teledyne Driver and the m_highDefinition parameter in Siglent driver... I can change it back the other way around if you prefer, just let me know ! 🙂 Thanks for the merge BTW !
<d1b2> <azonenberg> So i'm actually wondering about a 3-way switch
<d1b2> <azonenberg> force 8, force 16, auto
<d1b2> <azonenberg> (for both)
<d1b2> <azonenberg> for lecroy, at least, that would make sense
<d1b2> <azonenberg> since they do have >8 bits of resolution internally even with 8 bit ADCs due to the flatness correction DSP they do
<d1b2> <fredzo_72653> Oh yeah that would make sense too !
<d1b2> <azonenberg> idk if siglent does the same or if the low bits are all zero in word mode for 8 bit scopes
<d1b2> <azonenberg> Yeah i think that makes the most sense, do it for siglent and then i'll look at a similar change for lecroy as well
<d1b2> <azonenberg> with your fix is the siglent working well for you aside from slowness?
<d1b2> <fredzo_72653> Okay let me check if I can find how to make a 3way toggle ! 😉
<d1b2> <fredzo_72653> Oh yeah the fix woks perfectly, and its not that slow actually
<d1b2> <azonenberg> You'll want to use an "enum" preference and create a mapping of name-value pairs
<d1b2> <fredzo_72653> Around 5-6 fps for small memory depth (<2k)
<d1b2> <azonenberg> oh thats actually better than a lot of other siglents
<d1b2> <azonenberg> Can you send me some data points for my spreadsheet https://docs.google.com/spreadsheets/d/1Aw3pIdjKqfiHG1SAWSzkXyH3VJw_Mj2g_8I6pCXu0nY/edit?gid=0#gid=0
<d1b2> <david.rysk> which model siglent is this?
<d1b2> <david.rysk> mine is an sds2000x plus
<d1b2> <david.rysk> the HD is better and more expensive
<d1b2> <azonenberg> firmware version, memory depth, full scope model, number of channels active, memory depth, transfer mode, and WFM/s reported by performance metrics dialog
<d1b2> <fredzo_72653> It's a 2000X HD with all options including 500Mhz BW
<d1b2> <david.rysk> (like double the price)
<d1b2> <fredzo_72653> Yeah I had a chance to grab one before they turned black and got mine for around 2k euros.
<_whitenotifier-3> [scopehal-apps] fredzo synchronize pull request #740: Siglent sds2000 xhd fix - https://github.com/ngscopeclient/scopehal-apps/pull/740
<d1b2> <fredzo_72653> 🔼 @azonenberg made the 3 way switch mod, should be good but could not test it yet (I'm note with my scope right now 😉 )
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-apps/compare/7ae9f10061a5...409af0adb16e
<_whitenotifier-3> [scopehal-apps] azonenberg 409af0a - Updated to latest scopehal
<_whitenotifier-3> [scopehal-apps] azonenberg closed pull request #740: Siglent sds2000 xhd fix - https://github.com/ngscopeclient/scopehal-apps/pull/740
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 4 commits to master [+19/-0/±29] https://github.com/ngscopeclient/scopehal-apps/compare/409af0adb16e...d7d775b459c3
<_whitenotifier-3> [scopehal-apps] azonenberg d7d775b - Merge pull request #740 from fredzo/siglent-sds2000Xhd-fix Siglent sds2000 xhd fix
<d1b2> <fredzo_72653> 🔼 thanks for the merge Andrew !
_whitelogger has quit [Ping timeout: 252 seconds]
_whitelogger has joined #scopehal
<_whitenotifier-3> [scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://github.com/ngscopeclient/scopehal-docs/compare/d3b57d0f9093...6350c89f487e
<_whitenotifier-3> [scopehal-docs] azonenberg 6350c89 - Initial skeleton docs for J1939 bitmask and analog filter
<_whitenotifier-3> [scopehal] azonenberg pushed 2 commits to master [+4/-0/±8] https://github.com/ngscopeclient/scopehal/compare/e1bbbeb498a2...f24458465125
<_whitenotifier-3> [scopehal] azonenberg d8b7ecf - Initial implementation of J1939 bitmask decoder
<_whitenotifier-3> [scopehal] azonenberg f244584 - Initial implementation of J1939AnalogDecoder
<_whitenotifier-3> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://github.com/ngscopeclient/scopehal-apps/compare/d7d775b459c3...c83e22ad6d6c
<_whitenotifier-3> [scopehal-apps] azonenberg c83e22a - Updated to latest scopehal
<d1b2> <azonenberg> Great. and which commit ID of ngscopeclient / libscopehal were those with?
<d1b2> <fredzo_72653> Really not that bad I think (except for large memory depth...) !
<d1b2> <azonenberg> (older data is missing this but i'm trying to track it in new table entries)
<d1b2> <azonenberg> and scope firmware version
<d1b2> <azonenberg> And was that all in 8 bit transfer mode?
<d1b2> <azonenberg> you put B/sa as 1
<d1b2> <fredzo_72653> Nope this is in 16bit mode
<d1b2> <azonenberg> ok let me correct that in my sheet then
<d1b2> <azonenberg> You see what i mean about the enormous overhead per channel for data download though
<d1b2> <fredzo_72653> I completed my sheet :
<d1b2> <fredzo_72653> Yep you were totally right, nuber of SCPI commands have no impact on acquisition rate, it's only about triggering time and data transfer
<d1b2> <azonenberg> Yeah. This does vary a lot from scope to scope
<d1b2> <azonenberg> There are others where saving a few commands can be a big speedup
<d1b2> <fredzo_72653> I made one more test in 8bit mode on 5Mpts, huge impact too :
<d1b2> <fredzo_72653> 1.12 (8bit) vs 0.72 (16bit) Wfm/s
<d1b2> <azonenberg> Yeah it just tanks performance as soon as you go to deeper memory
<d1b2> <azonenberg> as opposed to say the thunderscope which will happily push 25 WFM/s on 4 channels with 10M points per channel 😄
<d1b2> <fredzo_72653> Arf not the same tool !
<d1b2> <fredzo_72653> Not the same usage...
<d1b2> <azonenberg> The point stands though, that most of the other entry level scopes have really slow PC interfaces
<d1b2> <azonenberg> its not just siglent
<d1b2> <fredzo_72653> Yep, can't argue against that !...
<d1b2> <azonenberg> in fact their newer models like the 2000x hd and the 6000 series are actually quite good as the low-end brands go
<d1b2> <josHua> this reminds me that I should take a swing at getting capture from the dho4000 into scopehal
<d1b2> <azonenberg> Ingest ALL the data 😄
<d1b2> <fredzo_72653> I have a DHO800 on the table too, I'll have a test tomorrow, it's getting late here in France 😉
<d1b2> <josHua> I think dho4000 is currently not supported in scopehal
<d1b2> <fredzo_72653> I added DHO800/1000/4000 to Sigrok, should be doable for ngscopeclient too 😉
<d1b2> <azonenberg> Awesome, we'll gladly take a driver if you want to write one
<d1b2> <fredzo_72653> It's not that far from MSO5000 AFAIR