<_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.
<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 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-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
<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>
<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>
<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 :