<d1b2>
<vipqualitypost> how can I get the output of the frequency measurement as a plot? I watched your video and am doing something slightly different, but also don't think I could see exactly how you were generating the plots. The average block is just giving me a measurement and I can't find out how to get a plot from latest, I think?
<d1b2>
<azonenberg> You want a plot of samples within the current waveform?
<d1b2>
<azonenberg> Or trended over many waveforms
<d1b2>
<azonenberg> in the latter case you want the "trend" filter
<d1b2>
<azonenberg> which takes a scalar and plots successive samples of it as a waveform
<d1b2>
<azonenberg> you can also look at the "trend" plot of the frequency filter which returns the instantaneous frequency of each cycle of the signal within one waveform
<d1b2>
<vipqualitypost> I don't have a live instrument hooked up now so just working on some old data. When you say waveform you mean one cycle or you mean the full collection of data within the memory?
<d1b2>
<azonenberg> One waveform is a single acquisition from the instrument
<d1b2>
<azonenberg> So if you want to plot frequency over time within that waveform just look at the trend output of the frequency filter
<d1b2>
<vipqualitypost> ah ok, so I have only one waveform. I was thinkingthat I could threshold to get the period, then plot that period on a cycle by cycle basis
<d1b2>
<azonenberg> it's already there, you're just not looking at it
<d1b2>
<vipqualitypost> ok, will try
<d1b2>
<azonenberg> Both the frequency and period filters let you plot their output as a trend
<d1b2>
<azonenberg> just drag the "trend" output under the Frequency_1 filter in the left sidebar into the waveform plot
<d1b2>
<azonenberg> (when you create a filter we default to displaying the most commonly used outputs but there's often other signals there that we don't turn on by default to avoid cluttering the dispaly)
<d1b2>
<vipqualitypost> ah, i didn't realize you could drag those into the main window area!
<d1b2>
<vipqualitypost> that's really neat, exactly what I was trying to look at.
<d1b2>
<azonenberg> Yeah thats the intent of that browser window
<d1b2>
<azonenberg> it's new, the docs havent caught up to it yet
<d1b2>
<vipqualitypost> it seems a bit wrong coming from the threshold direclty but looks more normal on the data itself
<d1b2>
<azonenberg> I think the threshold filter doesn't interpolate to sub sample precision
<d1b2>
<azonenberg> while the period/frequency filters do
<d1b2>
<azonenberg> if you want to smooth further you can apply a moving average to the output
<d1b2>
<vipqualitypost> ah, makes sense
<d1b2>
<azonenberg> which will remove some of the high frequency jitter and give you the longer term trend
<d1b2>
<azonenberg> Note that the accuracy of this measurement is dependent on the accuray of your scope's timebase
<d1b2>
<azonenberg> Which is one of the reasons I got the GPSDO, i can clock my scope off of it and get extremely stable and precise timing measurements that way
<d1b2>
<vipqualitypost> yes, i'm thinking that i will need to pick up an external time source soon, i have been trying to chase too many clocking issues the past few months.
<d1b2>
<vipqualitypost> i'm still learning a lot on these types of measurements, i've never had to look at this data before.
<d1b2>
<azonenberg> If you look at the "filters" section of the manual you will eventually get lots of detailed usage examples and details on how to use each one
<d1b2>
<azonenberg> But there's literally hundreds of pages of documentation to write, many are just a sentence or two
<d1b2>
<fredzo_72653> @azonenberg I was playing with digital probe of my SDS2000X HD and was wondering how is ParallelBus filter supposed to work ? I would have expected it to be a PacketDecoder and show bytes (or words) like UART decoder does, but instead nothing shows on the waveform display and I get warnings about RenderWaveforms not being implemented for STREAM_TYPE_DIGITAL_BUS. Is this a work in progress ?
<d1b2>
<azonenberg> Yes. the "digital bus" waveform type is a relic that needs to be completely redone
<d1b2>
<azonenberg> tl;dr the existing implementation has a std::vector for each sample which is a) horribly inefficient and b) can't be passed to the GPU
<_whitenotifier>
[scopehal] azonenberg 312e0dd - Merge pull request #891 from fredzo/siglent-sds-hd-support Better Siglent SDS HD support
<d1b2>
<fredzo_72653> Would it make sense to turn the ParallelBus filter into a PacketDecoder and pull out bytes / words directly out of it based on the bus width ?
<d1b2>
<azonenberg> We can evaluate that as a separate design decision
<d1b2>
<azonenberg> the first is how the internal representation of digital buses should look
<d1b2>
<azonenberg> one possible approach, which i am not saying is the best
<d1b2>
<azonenberg> is to have an int64 for each sample
<d1b2>
<azonenberg> and the low N bits are valid
<d1b2>
<azonenberg> i.e. for an 8-bit bus the high 7 bytes are wasted space and the low byte has the data value
<d1b2>
<azonenberg> this would be fast, but then what happens when you have a >64 bit signal?
<d1b2>
<azonenberg> (consider the case of connecting to an FPGA logic analyzer that might have large internal buses in some datapath that you want to display in ngscopeclient)
<d1b2>
<azonenberg> one possible way to solve that is to chunk the signal into blocks of say 32 or 64 bits in size
<d1b2>
<azonenberg> and then have a header field of some sort that specifies how many per sample
<d1b2>
<azonenberg> so say you have a 128 bit signal your raw data vector would be a uint32[] with entries 3:0 being the first sample, 7:4 the second, etc
<d1b2>
<azonenberg> Point is it's nontrivial and i havent had the time to think, discuss, and test out the various possible ways to do it
<d1b2>
<fredzo_72653> OK I see, not that simple if to get all the cases covered...
<d1b2>
<azonenberg> Exactly
<d1b2>
<azonenberg> It needs to happen, for sure
<d1b2>
<azonenberg> It's just not #1 on my priority list right now
<d1b2>
<fredzo_72653> I was thinking "who the hell needs a 128 bit wide logic analyzer" 😉
<d1b2>
<fredzo_72653> But I guess some do !
<d1b2>
<azonenberg> off the top of my head, when i was debugging the MCU-to-FPGA interfacing on my curve25519 accelerator
<d1b2>
<azonenberg> i was running LA traces on multiple 256-bit vectors and a lot of smaller signals simultaneously in vivado
<d1b2>
<azonenberg> I would love to be able to decode AMBA in ngscopeclient
<d1b2>
<azonenberg> and see APB transactions or somethign
<d1b2>
<azonenberg> All of that is blocked on having a working, fast data model for digital vector signals
<d1b2>
<fredzo_72653> \o/
<d1b2>
<azonenberg> but yeah, we are not one of those projects that will close a ticket after 90 days of no activity or something
<d1b2>
<azonenberg> there are literally four year old tickets on the tracker that are still open, and i still recognize need to be done, but have not had the time to execute
<d1b2>
<azonenberg> It will stay open until its done however long that takes
<d1b2>
<fredzo_72653> Thanks for the merge of my work on Siglent driver BTW !
<d1b2>
<azonenberg> No problem. it's not in mainline ngscopeclient yet as i haven't pushed an update to the submodule pointer
<d1b2>
<azonenberg> but that will come shortly
<d1b2>
<hansemro> @Fredzo your PR assumes siglent users are running latest firmware to advantage of LA/MSO being available by default. Should we then warn users if running older firmware?
<d1b2>
<vipqualitypost> I actually pretty regularly get up to the 136 channels supported on my HP 1670D!
<d1b2>
<azonenberg> (related: we need a nice GUI way for drivers and filters etc to display warning messages to users... perhaps have LogWarning messages show up in a console window in the UI? i'm not sure what's best
<d1b2>
<azonenberg> We do have a sort of console display mode in the GUI already but it's not super obvious
<d1b2>
<azonenberg> maybe it should become a standard docked-by-default thing
<d1b2>
<azonenberg> that shows stdout/stderr in the gui
<_whitenotifier>
[scopehal-apps] mldulaney eee09bc - Add three sawtooth, two sd, and one waterfall icons Signed-off-by: Mairi Savanna Dulaney <mairi@seattlebus.space>
<_whitenotifier>
[scopehal-apps] azonenberg f77fae1 - Updated to latest scopehal