<d1b2>
<vipqualitypost> it's no rush, just something i bumped into today
<d1b2>
<vipqualitypost> do you have any ideas on constructing a PSD in ngscopeclient? i made an FFT and then wasn't sure how to square the data other than feeding the same input to both nodes of mutliply, but the result looked weird so I was trying to get the FFT out of ngscopeclient into python to just double check stuff
<_whitenotifier>
[scopehal] azonenberg f4a2e7f - Added Doxygen comments to TestWaveformSource. Renamed GenerateNoisySinewaveMix to GenerateNoisySinewaveSum to more accurately reflect what it does.
<d1b2>
<azonenberg> I dont think we have a PSD filter as of now
<d1b2>
<azonenberg> File a ticket and we can add one
<d1b2>
<azonenberg> Would you want it to integrate continuously or what?
<d1b2>
<azonenberg> the fft filter naturally outputs dBm by default
<d1b2>
<azonenberg> but it's of a single acquisition not long term average or anything
<d1b2>
<vipqualitypost> Single shot is fine, i have enough memory depth on my scope.
<d1b2>
<azonenberg> Then whats wrong with just a normal fft giving output in dbm>?
<d1b2>
<azonenberg> i'm not familiar with the difference between a normal fft power output and a psd, if any
<_whitenotifier>
[scopehal] azonenberg 8a29a06 - Partial Doxygen coverage of TektronixOscilloscope
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 255 seconds]
Degi_ is now known as Degi
<d1b2>
<vipqualitypost> FFT is just giving you the spectrum, the PSD gives you the power over the spectra over a bandwidth. For my use case here I am trying to calculate the jitter from a PSD representing the phase noise. I have access to a nice (but old) HP vector signal analyzer that can natively make this type of phase noise measurement, but I'm curious if it's possible to reconstruct the same data from my scope using ngscopeclient.
<d1b2>
<vipqualitypost> Sorry I keep coming in here and rambling about jitter, it's been a few interesting weeks...
<cyrozap>
which includes changes published in PRs.
<azonenberg>
ah oops let me fix that
<azonenberg>
it should have been BY-NC
<azonenberg>
Fixed
<cyrozap>
btw, if I might pile on the icon bikeshedding, IMO you should use a DIMM icon to represent DRAM. That's going to be more recognizable as DRAM to more people than a BGA footprint or bitcell schematic. Sure, a BGA or schematic might be more "technically correct", but icons are not technical drawings, they're abstract symbols meant to convey an idea in a quickly-recognizable form. For instance, the "save"
<cyrozap>
icon is based on floppy disk, despite modern computers saving data to NVMe. Sure, an icon of an NVMe drive might be more "technically correct", but it will fail at its primary purpose, which is to enable the user to quickly find the button to save their work.
<azonenberg>
i mean, the save icon may evolve over the next few years given what percentage of computer users know what a floppy even is :p
<azonenberg>
and yeah i'm not opposed to using a dimm
<joshua_>
DIMMs have an irritating aspect ratio for what there is space for in those icons, though
<azonenberg>
yeah lol
<cyrozap>
Thanks for the license change, though I'd recommend dropping the "NC" as well unless you have a really, _really_ good reason for keeping the website license nonfree.
<azonenberg>
i was thinking kinda diagonal to vertical
<azonenberg>
vertical to slightly diagonal sodimm plus signals or text
<cyrozap>
Right, sure, my point is it just has to represent the idea of a stick of DRAM--so long as it's recognizable it doesn't have to be proportioned correctly or even have the right number of DRAM chips on it at all.
<azonenberg>
Yeah of course
<azonenberg>
anyway gimme a minute to finish what i'm doing and i'll post a screenshot of the entire filter palette as it stands
<azonenberg>
and we can discuss any other stuff
<azonenberg>
There's a bunch of new work from tetrikitty too
<d1b2>
<macaba> Something I'm interested in too. I've implemented my own library for averaged PSD and NSD (aka VSD) in both linear and logarithmic space. I was wondering if I should try to use the ngscopeclient plugin interface to pull that lib in.
<d1b2>
<macaba> The standard output for averaged NSD in log space would look like this
<d1b2>
<azonenberg> So, x axis log rendering would need some significant changes to how we render stuff
<d1b2>
<azonenberg> file a ticket but it's not happening any time soon. even y axis log is tricky with the existing renderer hence why we cheat by having the fft output be pre-logged
<d1b2>
<macaba> I had assumed log-log was already possible, I'll file the ticket.
<d1b2>
<azonenberg> yeah as of now x axis coordinates have to be int64 multiples of a base unit
<d1b2>
<azonenberg> normally Hz or fs
<d1b2>
<azonenberg> i think we have mHz and uHz units somewhere
<d1b2>
<azonenberg> There's going to be a big refactoring of units soon (likely after v0.1) to enable a lot of improvements on that front
<d1b2>
<azonenberg> But with the TS launch coming soon my focus right now is on getting stability and documentation and packaging issues taken care of, with minimal to no new feature development aside from what i urgently need for active projects at work
<d1b2>
<azonenberg> i want to get it to be something we're willing to put in front of all of the backers ASAP
<d1b2>
<azonenberg> @macaba my initial thought of how we'd do this is to do it similar to how we do dBm in a way
<d1b2>
<azonenberg> where we'd have a unit for log frequency, internally store it as like dBHz or so
<d1b2>
<azonenberg> but then convert back to linear for display when pretty printing
<d1b2>
<azonenberg> (choosing the correct space for axis ticks would also have to change to make them nonlinear)
<d1b2>
<macaba> I guess in the most generic case; the ability to specify an equation for major tick, minor tick, XY position, to map all these to linear space.
<d1b2>
<macaba> Probably some ability to control the tick label content too.
<d1b2>
<fredzo_72653> (that's a COSPAS/SARSAT beacon frame)
<d1b2>
<josHua> building this now
<d1b2>
<josHua> @fredzo_72653 hm I previously had my scope in HiRes acquisition mode from the front panel, and probably we should have the driver set it back to normal acquisition mode since the driver doesn't otherwise know how to control this
<d1b2>
<josHua> RFE: right clicking on 'CHAN1' in the stream browser tab at left to change vertical offset numerically without having to go to th efilter graph first
<d1b2>
<josHua> RFE: on-screen indication for "I am idle"; "I am waiting to capture"; "I have captured but I am downloading the waveform"
<d1b2>
<josHua> the captures that I just took testing this with ngscopeclient though tell me more than I had ever been able to tell from the front panel of the scope
<d1b2>
<david.rysk> I think that could go in the status bar?
<d1b2>
<azonenberg> You can threshold it, at which point it's just serial data
<d1b2>
<azonenberg> yo ucan then write a decode for the protocol
<d1b2>
<josHua> that would be good, I would be happy to have a toolbar indicator of such, like my scope has, for 'stopped', 'waiting for trigger', 'running', and I guess in this case, '100Mbit is for chumps, get a faster scope bruh'
<d1b2>
<azonenberg> we don't have any generic "serial data as bytes" decode if thats what you're looking for?
<d1b2>
<azonenberg> Good call, file a ticket
<d1b2>
<josHua> wilco
<d1b2>
<azonenberg> This gets a little trickier when you have multiple instruments in play since they're all asynchronous to each other except for lockstepped trigger groups
<d1b2>
<azonenberg> So you'd need an indicator per instrument
<d1b2>
<josHua> that'd be fine too -- or this could be a status indicator in the stream browser at left, in the default view, which would be per instrument
<d1b2>
<azonenberg> we have a "manage instruments" dialog that is probably the best spot for it
<d1b2>
<azonenberg> which displays all of the active instruments, trigger groups, etc
<d1b2>
<azonenberg> then maybe there can be a separate indication for "some instrument is busy" or something like that
<d1b2>
<josHua> #79 I think is for busy processing, which does not happen to me because Apple Silicon go brr -- in my case, the UI is perfectly responsive, and I can't tell whether it ignored me when I clicked capture, or if it triggered a capture
<d1b2>
<azonenberg> without being specific as to what
<d1b2>
<azonenberg> File a separate ticket then for displaying instrument busy status
<d1b2>
<josHua> wilco, I'm working on the first ticket still 🙂
<d1b2>
<azonenberg> I think most instruments would be able to handle it in ScopeThread but we might have to retool a few drivers to handle special cases
<d1b2>
<azonenberg> in particular the RemoteBridgeOscilloscope based drivers generally always report 'triggered' and then block in acquireData waiting for stuff to show up
<d1b2>
<azonenberg> which isn't compatible with the trivial implementation of this workflow
<d1b2>
<azonenberg> (perhaps fixing that is the right solution)
<d1b2>
<josHua> or there can be other states added, like 'busy of some kind'
<d1b2>
<azonenberg> anyway, first step is getting the ticket so it doesnt get forgotten in the chaos of getting ready for v0.1
<d1b2>
<fredzo_72653> Well you have the UART one isn't it ?
<d1b2>
<josHua> attempting to connect to my DHO4000 while I am already connected to it went quite poorly
<d1b2>
<azonenberg> yes but that assumes uart stop/start bit framing is my point
<d1b2>
<azonenberg> if its literally ook uart, threshold + uart decodes would work
<d1b2>
<azonenberg> yeah most scopes do not handle concurrent connections well
<d1b2>
<josHua> specifically it caused the whole UI to lock up
<d1b2>
<fredzo_72653> That doesn't surprise me much !...
<d1b2>
<josHua> is there a way to disconnect and reconnect the scope without restarting ngscopeclient?
<d1b2>
<azonenberg> You can close the entire session
<d1b2>
<azonenberg> there is currently no way to disconnect from a single instrument
<d1b2>
<azonenberg> It's planned, but difficult from an implementation perspective
<d1b2>
<josHua> ok cool, I was just thinking this int erms of testing the 12 bit stuff
<d1b2>
<fredzo_72653> Ah OK sorry I missed the "generic" non it's not UART, no start/stop bits but rather sync frame + manchester encoded data. OK I'll see if I can work something out : training level 2 😉
<d1b2>
<azonenberg> This kinda ties into a broader part of our object ownership refactoring and "who is using what" tracking
<d1b2>
<azonenberg> i.e. not just using smart poitners and such so we don't free an object somebody is using
<d1b2>
<azonenberg> but knowing who is using it
<d1b2>
<azonenberg> so if you desired to disconnect from a scope that's still in use, being able to find evryone who might have a reference to it and tell them the scope is going bye-bye
<d1b2>
<azonenberg> the same applies to deletion of filters
<d1b2>
<azonenberg> It's going to happen, but likely not before v0.1
<d1b2>
<azonenberg> both are priorities for v0.2
<d1b2>
<josHua> hm, something got stuck when I restarted ngscopeclient and now my scope is stuck in 2GSa/s mode rather than 4GSa/s mode
<d1b2>
<josHua> @azonenberg to answer the question, by the way, this machine has absolutely no qualms about doing a FFT on 50 million points. it seems that it simply does not care
<d1b2>
<azonenberg> 😄
<d1b2>
<azonenberg> just eats waveform data for breakfast?
<d1b2>
<azonenberg> those things seem to be beasts at running ngscopeclient because of the unified memory
<d1b2>
<josHua> yeah, the DHO4000 natively is basically useless when you start turning the capture lengths up, it just absolutely chugs
<d1b2>
<azonenberg> yep. it's a shame, if they had just put a SFP+ on the thing
<d1b2>
<azonenberg> it probably would have been an amazing companion to ngscopeclient lol
<d1b2>
<azonenberg> or thunderbolt or whatever
<d1b2>
<josHua> I dunno if it's even saturating the network interface
<d1b2>
<azonenberg> well what i implied was
<d1b2>
<azonenberg> a beefy network interface and the ability to stream sample data straight off the FPGA to it
<d1b2>
<azonenberg> and not be bottlenecked on whatever raspberry pi or beaglebone phone-class soc they're running :p
<d1b2>
<josHua> yeah it is a rockchip shit
<d1b2>
<josHua> now, that said, if they are saturating the network interface, even still we could probably do better. DPCM + Huffman or something should be able to meaningfully compress most captures
<d1b2>
<josHua> (I know because I hold a patent on doing that for digital images.)
<d1b2>
<azonenberg> My experience with other scopes is that siglent/rigol class devices normally can only push a few tens of Mbps of sample data
<d1b2>
<josHua> I wonder where the holdup is
<d1b2>
<azonenberg> Inefficient software in the critical path not designed for any hardware offload?
<d1b2>
<azonenberg> idk, they are probably just not optimixzing for remoting performance at all
<d1b2>
<josHua> yes, I mean, where specifically all the CPU time is going
<d1b2>
<azonenberg> i mean you're talking to the guy who iperf'd a stm32h7 at 500+ Mbps UDP streaming
<d1b2>
<azonenberg> if their rockchip is slower than a stm32, i'll be amused :p
<d1b2>
<josHua> I think they have one of the 64 bit rockchips rather than the Cortex-A7 shitbox in the Bambu X1 that I have been hacking on at least
<d1b2>
<david.rysk> yeah once we made AcceleratorBuffer not allocate memory twice at least 😄
<d1b2>
<david.rysk> At least a few of the lower end scopes seem to use a Zynq
<d1b2>
<azonenberg> Yep. it still needs more work on non-unified-memory systems
<d1b2>
<azonenberg> in particular, if we fail to allocate device memory on a dGPU
<d1b2>
<azonenberg> we should fall back to using host memory over pcie rather than crashing
<d1b2>
<azonenberg> (and perhaps take other actions to reclaim device memory like moving historical waveforms out of device memory)
<d1b2>
<josHua> this one is a Rockchip, at least, from last time I looked at the firmware
<d1b2>
<azonenberg> That is a planned todo for some time before the v0.1 release
<d1b2>
<azonenberg> as i see it as a key stability issue
<d1b2>
<david.rysk> I need to dig out my Siglent SDS2104X-Plus again and see what to do with it, wish we still had useful contacts at Siglent
<d1b2>
<david.rysk> I haven't updated the OS yet, they closed the easy security hole lol
<d1b2>
<david.rysk> (it would run a script off the USB at boot)
<d1b2>
<david.rysk> it will still run commands from a uboot script off the USB at boot though
<d1b2>
<david.rysk> I also have a Thunderscope beta unit, but I need LiteX firmware to be able to test it on Mac
<d1b2>
<david.rysk> there's some WIP DriverKit work which I'd like to play with
<d1b2>
<josHua> it seems to take 25msec for the scope to think about responding to WAV:DATA? before it sends the first bundle of 250 ksamples of data, and then it takes 22msec to actually send the 250 ksamples
<d1b2>
<david.rysk> @josHua any particular pain points on macOS (with ngscopeclient)?
<d1b2>
<david.rysk> @azonenberg and I (with some contribution from @johnsel) are working to remove the dependency on Cairo, which is more of an annoyance on Windows but still kinda a pain on macOS too
<d1b2>
<david.rysk> and then there's some path handling stuff I need to rewrite... and hopefully we can bundle an .app soonish
<d1b2>
<josHua> so when it is actually sending data it manages to achieve 90 megabit/second of target data throughput (is it 10/100 or gbit?), but it halves that because it's busy thinking about it
<d1b2>
<josHua> I wonder if we could do better by pipelining requests to it
<d1b2>
<josHua> installing it from git was painful mostly because my system was migrated from an Intel machine and I have half an ARM homebrew install and half an Intel homebrew install, but that's largely on me. the Dear Imgui metaphors are unfamiliar to me which was my big pain point, and there are some weird xplat issues there (reopening a saved session on a hidpi monitor places the window somewhere strange, for instance); similarly, UI metaphor wise for a
<d1b2>
Mac user, I wish I could use the Magic Touchpad (or, better: my spacemouse) to more precisely navigate a capture
<d1b2>
<david.rysk> > the Dear Imgui metaphors are unfamiliar to me which was my big pain point yeah I find this kinda annoying but there's not much we can do about that with a full rewrite
<d1b2>
<david.rysk> the other stuff... yeah that needs to be fixed, probably should open/check for issues and assign them to myself
<d1b2>
<josHua> input device I have filed issues for
<d1b2>
<david.rysk> the open/save windows... that's a problem across platform iirc
<d1b2>
<david.rysk> @azonenberg are you storing window positions in the session?
<d1b2>
<josHua> oh what the heck, I didn't realize this thing had superspeed USB
<d1b2>
<azonenberg> my experience is that a lot of the cheap scopes do not tolerate pipelining at ALL
<d1b2>
<azonenberg> with siglent we have to send commands at no more than 20 Hz to a lot of the models
<d1b2>
<azonenberg> which is na arbitrary rate limit
<d1b2>
<azonenberg> but if we send too fast some commands just get dropped
<d1b2>
<azonenberg> We use native open/save dialogs on Windows, and on Linux via GTK, if not fullscreened
<d1b2>
<azonenberg> we switch to the imgui dialog if fullscreened because the native dialog tries to pop up under the application and is invisible
<d1b2>
<azonenberg> (this should be fixed)
<d1b2>
<azonenberg> For Mac, we need to figure out how to asynchronously launch a file browser in the main thread
<d1b2>
<azonenberg> i don't know if this is even possible
<d1b2>
<azonenberg> (i.e. having the file browser not block the main thread and thus allow other stuff to execute in the background while you're choosing the file)
<d1b2>
<azonenberg> or alternatively just spawn a new process and have the dialog live in it :p
<d1b2>
<azonenberg> we use the standard imgui persistence mechanism
<d1b2>
<azonenberg> i dont know what properties it saves
<d1b2>
<josHua> loosk like by default the fastest this goes is 100 Mbit
<d1b2>
<josHua> well this is probably worth fucking with ... later
<d1b2>
<duskwuff> minor doc gripe: the table of contents in the manual appears to have gone AWOL
<d1b2>
<azonenberg> That's a bug i recently discovered
<d1b2>
<azonenberg> i've removed all links i knew about to the top level ngscopeclient-manual.html page
<d1b2>
<azonenberg> as a temporary workaround
<d1b2>
<azonenberg> everything should link to contentsname.html
<d1b2>
<azonenberg> but i need to figure out whats going on in the html generation and fix it
<d1b2>
<azonenberg> If anybody has the time to work on it, be my guest. i've been super busy at work and what limited time i had free has gone to developer docs
<d1b2>
<azonenberg> so i've put the end user docs on ice for a bit. in a week or so i plan to start a big push on end user docs working on things like updating all the screenshots to reflect the current UI
<d1b2>
<azonenberg> removing references to things that have moved, etc
<d1b2>
<fredzo_72653> About that I managed reach out to Siglent support about a bug they have on LA paginated data download (the scope always sends the first page, no matter what start point you set). They said they could reproduce the bug and will fix it in the next firmware release.
<d1b2>
<fredzo_72653> (that on the SDS2000X HD not sure if it exists on the X plus too)
<d1b2>
<david.rysk> Let me know how to repro and I’ll check
<d1b2>
<david.rysk> I’d just like faster transfer in general
<d1b2>
<david.rysk> So we don’t need to have that rate limit
<pirate>
so, i'm having a difficult time even getting a sodimm to look good in the smol space
<d1b2>
<fredzo_72653> Easy if you have LA probe : sample a signal with mdepth > 2,5Mpts (on the digital channel, say 5Mpts) and the scope will start to paginate the result. If it has the bug you will see twice the first half of the waveform :
<d1b2>
<fredzo_72653> Maybe on the older models ? I rewrote a good part of the acquisition logic for the newer models (SDS2000X+ and above) and I'm pretty sure there is no rate limite on scopehal side.
<joshua_>
aw chibi sodimm
<d1b2>
<azonenberg> I actually quite like that
<d1b2>
<azonenberg> //Enable command rate limiting //TODO: only for some firmware versions or instrument SKUs? transport->EnableRateLimiting(chrono::milliseconds(50));
<d1b2>
<azonenberg> line 137
<d1b2>
<azonenberg> If we can do some testing to remove that from models where it's not needed that would be great