<d1b2>
<vipqualitypost> just dropping by again to say how awesome ngscopeclient is - we have a tektronix dpo73304sx on demo right now (nearly $500k instrument!) and I was able to recreate all of the analysis features that the scope offers inside ngscopeclient! a mix of jitter measurements and histograms, eye diagrams, and some frequency domain stuff... really incredible that it's all offered so competently in a free and open source program
<d1b2>
<vipqualitypost> you're really just limited by your frontend if you can get the data in there 😄
<d1b2>
<azonenberg> I think that might be a bug, i was literally just working on that part of the code a few days ago fixing some stuff
<d1b2>
<azonenberg> but check that your methods in the driver for getting the current sample rate and memory depth are returning valid values too
<d1b2>
<azonenberg> nice 😄 did you do side by side comparisons and get similar results?
<d1b2>
<azonenberg> i've tried to validate most of the high speed serial stuff against my lecroy, the PLL I use for clock recovery is a bit different and i still want to improve that
<d1b2>
<vipqualitypost> yep!
<d1b2>
<vipqualitypost> the results are similar, not identical, but the tek has a lot more knobs to turn especially around clock recovery
<d1b2>
<azonenberg> yep. we have an open TODO specifically for implementing all of the standard reference PLLs like PCIe, FC golden, etc. with controllable bandwidth
<d1b2>
<azonenberg> my dsp-fu isn't up to it
<d1b2>
<vipqualitypost> that would be really great!
<d1b2>
<azonenberg> given the same reference clock the tek is using, my algorithms should give ~identical results (if they don't it should be considered a bug)
<d1b2>
<azonenberg> i know there are a few things in the eye pattern filter causing some rounding artifacts at the exact vertical centerline of the plot that i have to investigate
<d1b2>
<azonenberg> i.e. at T=0
<d1b2>
<vipqualitypost> i had some issues getting the data out into ngscopeclient - i need to write some scripts to better automate ingestion as i was trying to be quick and just do ti in excel and it's unable to load the full memory, etc
<d1b2>
<azonenberg> but yes, high speed serial in general is the area I think we're most competitive with the big boys
<d1b2>
<azonenberg> and even ahead in some cases, e.g. i don't know of any big-name scope that can decode QSGMII
<d1b2>
<azonenberg> anyway glad you're enjoying the tool and we should definitely make a driver for that scope one day :p
<d1b2>
<vipqualitypost> if we buy it i'd be more than happy to help 😄
<d1b2>
<azonenberg> what other models are you considering?
<d1b2>
<vipqualitypost> we've got a demo with keysight in a few weeks for a similar class of scope and to be honest i'm more excited for that one
<d1b2>
<vipqualitypost> i don't remember the model # of the top of my head but will grab it monday
<d1b2>
<azonenberg> i assume a lecroy SDA / labmaster is on the menu as well? if not you should at least consider
<d1b2>
<vipqualitypost> i wasn't in charge of arranging them, it's for a PCIe design/validation project, i can see if we can do something with them if you'd recommend?
<d1b2>
<azonenberg> I can't speak to this particular model but I've run a lecroy shop for years and I have the previous generation of this scope and love it
<d1b2>
<azonenberg> (my big beast scope is a SDA816Zi-A)
<d1b2>
<azonenberg> over the years i've owned (and used with ngscopeclient) a WaveSurfer 3034 (slow CPU, siglent rebadge running lecroy firmware IIRC), a WaveRunner 8104 (my first big-boy scope, i loved it), a HDO9204, a WaveRunner 8404M-MS which I still have, and the SDA
<d1b2>
<vipqualitypost> that's awesome!
<d1b2>
<azonenberg> i sold the wavesurfer to $dayjob's lab to replace an old tek that had kicked the bucket
<d1b2>
<azonenberg> the 1 GHz waverunner i traded in to get the 4 GHz
<d1b2>
<vipqualitypost> i've never touched a lecroy- deep down i am very much an hp/agilent/keysight fanboy, i always find them to have the best UI
<d1b2>
<azonenberg> the HDO I sold to help fund the purchase of the SDA
<d1b2>
<vipqualitypost> i'll definitely see if we can get some time on one, it'd be nice to get a feel for it
<d1b2>
<azonenberg> Yeah. It's a bit different from some of the other scopes but i really like the UI, if you're used to tek/keysight it may be a bit of a culture shock though
<d1b2>
<azonenberg> i've been using lecroys for so long teks feel weird to me :p
<d1b2>
<vipqualitypost> the tek ui is always a drag IMO
<d1b2>
<vipqualitypost> i have an MDO 4k and while performance wise i love it, the UI just always kills me
<d1b2>
<vipqualitypost> it's actually what brought me to ngscopeclient in teh first place 😄
<d1b2>
<azonenberg> anyway, i guarantee if you are seriously considering a six figure scope purchase your local lecroy rep will be falling head over heels to throw a demo your way lol
<d1b2>
<azonenberg> can't hurt to try it before deciding which to buy
<d1b2>
<vipqualitypost> yeah we're looking to buy in 6-9 mo probably
<d1b2>
<azonenberg> for background, this is lecroy's first high bandwidth 12 bit scope
<d1b2>
<azonenberg> The 8Zi SDA/WaveMaster/DDA (same platform with slightly different HW/SW options) as well as the LabMaster line all use the same in house 8 bit 40 Gsps SiGe ADC, either standalone or interleaved
<d1b2>
<azonenberg> they've been offering 12 bit scopes for a while starting with the low end and working their way up to high end
<d1b2>
<vipqualitypost> that's pretty sweet
<d1b2>
<azonenberg> I don't know the specifics of this scope's internals, I haven't seen one naked yet
<d1b2>
<azonenberg> they should send one to shahriar
<d1b2>
<azonenberg> I was at LeCroy's HQ a couple years ago and got to see their factory and meet a bunch of the engineers, and saw a labmaster mainboard and some of the adcs
<d1b2>
<azonenberg> but this was before the 8000HD was out
<d1b2>
<azonenberg> so if they had any there i wasn't allowed to see :p
<d1b2>
<vipqualitypost> tek invited us to a closed room showing for some new series scope at designcon but to be honest their new scopes don't seem very appealing
<d1b2>
<vipqualitypost> same design language as their 4/5 families
<d1b2>
<azonenberg> i can say from a scopehal / firmware perspective, i do not recommend tek's current stuff
<d1b2>
<azonenberg> the hardware is excellent
<d1b2>
<azonenberg> but the firmware is somewhat unstable at times especially if you're doing any kind of remote control or scpi stuff
<d1b2>
<azonenberg> while writing the driver for mso6 i had the scope lock up to the point of needing to be power cycled many many times
<d1b2>
<vipqualitypost> i've been tinkering on and off with a driver for my mdo4k and it's been annoying
<d1b2>
<vipqualitypost> and tha'ts like the last release of their old style stuff
<d1b2>
<azonenberg> i have no experience with recent high end keysight
<d1b2>
<azonenberg> @miek__ and some other folks have keysight lower end scopes that seem to work fine with scopehal and not have significant scpi stability issues
<d1b2>
<vipqualitypost> i got to tinker on a few when i was working there a while ago but never got to use it on some real projects
<d1b2>
<azonenberg> Tek is trying, they added a gRPC remote API for high speed data download to recent firmware
<d1b2>
<azonenberg> the problem is, you still need to use their awful scpi stack for control plane and that's where all the bugs are
<d1b2>
<vipqualitypost> i have a dsox1200 that works really well with meiks driver and also had a mso3000 that also worked well but i sold a while ago
<d1b2>
<azonenberg> I have not personally tested one of the 8000HD scopes with ngscopeclient, but lecroy's APIs have been extremely stable and orthogonal over the years
<d1b2>
<azonenberg> like, there are maybe a single digit number of functions that have some quirks handling for really old (windows XP era) scopes
<d1b2>
<azonenberg> and otherwise we have one driver that Just Works (tm) for everything from the XP scopes to current models
<d1b2>
<azonenberg> the only thing we have to change per model otherwise is the table of legal sample rates/memory depths etc
<d1b2>
<azonenberg> which is of course inhernetly model specific
<d1b2>
<azonenberg> So from that perspective alone definitely poke lecroy. And tell the sales guy you're considering it because of good ngscopeclient support
<d1b2>
<azonenberg> With a scope that pricey, that comment will carry some weight lol
<d1b2>
<azonenberg> @vipqualitypost Oh, another thing to consider about the lecroy, which I think may still be exclusive to them WRT patents etc
<d1b2>
<azonenberg> Notice the input has two rows of connectors?
<d1b2>
<azonenberg> All of their ultra high end scopes have dual frontends, there's a full bandwidth one using BMA (for most of the WaveMasters) or 2.92mm (for the highest end stuff) inputs that's 50 ohm only and super sensitive etc
<d1b2>
<azonenberg> and then above or below there's a standard frontend with maybe 3-4 GHz of bandwidth and switchable 1M / 50 ohm mode
<d1b2>
<vipqualitypost> whoah
<d1b2>
<vipqualitypost> that's very cool!
<d1b2>
<azonenberg> So you can put a regular bog-standard passive probe on there and use it as a trigger source or something
<d1b2>
<vipqualitypost> i certainly will!
<d1b2>
<azonenberg> or a power rail probe or current probe
<d1b2>
<vipqualitypost> yeah, that's really nice
<d1b2>
<azonenberg> i use that capability all the time
<d1b2>
<azonenberg> it makes it much more of a general purpose tool rather than a pure creature of high speed like some other ultra high end scopes (e.g. UXR) that have almost no low-speed capability
<d1b2>
<azonenberg> h/o let me show you a typical usage screenshot
<d1b2>
<azonenberg> it's from my prototype ethernet switch
<d1b2>
<azonenberg> looking at 5 Gbps QSGMII TX + RX with differential probes, plus I think the FPGA core power rail to see if there's any power integrity issues triggered by activity spikes when an ethernet frame shows up
<d1b2>
<vipqualitypost> yeah, that's something that was bugging me about this tek one
<d1b2>
<vipqualitypost> the inputs are so sensitive that it's basically single-use for one product we're doing
<d1b2>
<vipqualitypost> otherwise a paperweight
<d1b2>
<azonenberg> (gimme a min i'm cleaning up the scopesession it's from the glscopeclient era so the window layout didn't port over)
<d1b2>
<vipqualitypost> no worries
<d1b2>
<vipqualitypost> i did take some nice screenshots when i was using it too if those are useful for anything
<d1b2>
<azonenberg> So this is QSGMII, which is four lanes of gigabit ethernet TDMA'd onto a single 5 Gbps diff pair. basically the exact inverse of what multi-lane PCIe does
<d1b2>
<azonenberg> i'm simultaneously looking at the FPGA core power rail with an RP4030 4 GHz power rail probe (on one of the low-BW channels), the TX pair with one diff probe, and the RX pair with another diff probe
<d1b2>
<azonenberg> and then you can see the time domain waveform view as well as the spectrogram with various internal clocks and harmonics on the FPGA visible
<d1b2>
<azonenberg> you can see the design is optimized well enough that there's basically no transient at all when the packet shows up
<d1b2>
<azonenberg> Which is exactly what I was hoping to see
<d1b2>
<azonenberg> (I repeated this same test across all of the SERDES power rails, the RAM power, the PHY power, etc - anything that might have a sudden change in activity levels when an idle network link started doing stuff)
<d1b2>
<azonenberg> @vipqualitypost is this the kind of test you could see doing on your product?
<d1b2>
<vipqualitypost> potentially!
<d1b2>
<azonenberg> (I do note that triggering might be an issue with newer gen PCIe.... last time I looked LeCroy had hardware CDR triggers for 8b10b and 64b66b but not 128b130 or PAM4)
<d1b2>
<vipqualitypost> that's really awesome to see all those types of measurements mixed together
<d1b2>
<vipqualitypost> We're doing gen 4 but to be honest I haven't been super involved on that side of the project.
<d1b2>
<azonenberg> (this test was actually triggered on the QSGMII channel 4 using the hardware CDR pattern trigger on my 8Zi)
<d1b2>
<azonenberg> but yes. that has always been my goal with ngscopeclient, i want to enable new kinds of cross-domain analysis and debug
<d1b2>
<azonenberg> realistically, if you have a power integrity problem triggered by activity on a high speed serial interface, perhaps causing bit errors on said interface or an adjacent one
<d1b2>
<azonenberg> this is how you want to troubleshoot it
<d1b2>
<azonenberg> alternatively, in my case there was no visible malfunction but I now have very high confidence that there is no latent problem and I have plenty of margin
<d1b2>
<azonenberg> I've started doing full power integrity workups on all of my high speed designs as SOP since I got these power rail probes, that's why you'll see little u.fl's scattered all over my boards
<d1b2>
<azonenberg> gives me a multi GHz view of the power net at a single point, and if i'm suspicious and want to see more i can solder a coax across a power/ground via or something to target an exact ball location
<d1b2>
<azonenberg> but then when you combine that with the SERDES or whatever, you can get a much better view of what's going on
<d1b2>
<azonenberg> Not just "random dips in vcore" it's "consistent dips in vcore when an IPv6 packet arrives" or something
<d1b2>
<vipqualitypost> yeah, that kind of cross-correlation is really powerful
<d1b2>
<vipqualitypost> that was one of the reasons i picked up my tek mdo4k was for the rf/time domain cross trigger/ correlation
<d1b2>
<azonenberg> Yep
<d1b2>
<azonenberg> It all depends on the problem domain you're working in
<d1b2>
<vipqualitypost> haven't had a whole lot of times where you need it, but when you do, it's so so so helpful
<d1b2>
<vipqualitypost> and so difficult to do without proper tools
<d1b2>
<azonenberg> in my case most of what i do is high speed serdes and so what i want is that synced up with low speed control plane, power, etc
<d1b2>
<azonenberg> and all of the analysis on a single timeline
<d1b2>
<azonenberg> This is ancient, it's in glscopeclient
<d1b2>
<azonenberg> but here's the same sort of measurement on a Digilent Zybo devkit
<d1b2>
<azonenberg> in this case i'm using the RX_CTL RGMII pin on the PHY as a trigger
<d1b2>
<vipqualitypost> that rules
<d1b2>
<azonenberg> in the time domain, you can see very clear SMPS ripple then a huge low frequency transient when the frame arrives, then overshoot when the CPU goes back to idle after the reply has been sent
<d1b2>
<azonenberg> then stabilizing
<d1b2>
<azonenberg> but in the frequency domain you can see a couple of internal clocks plus the burst of broadband low frequency activity while the CPU is doing stuff
<d1b2>
<azonenberg> this is an example of what I was looking for on my board, and didn't see because my PDN was better :p
<d1b2>
<azonenberg> (and/or because my firmware had more flat power consumption and there was less of a current transient)
<d1b2>
<azonenberg> anyway, food for thought but at least for the specific use case of correlating serdes and power rail activity the lecroy is likely a superior option
<d1b2>
<vipqualitypost> that's really good to know and very likely functionality we could really use
<d1b2>
<vipqualitypost> thanks for the chat! i'm headed off to bed now, thanks again for your hard work (and everyone else who's contributed as well )