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
<dingwat> heh, that's the opposite of what I was seeing
<dingwat> I can try on another win10 machine and see the results
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
<d1b2> <rapgenic> Hi all, I have a R&S RTO1014 (series RTO1000) and I'd be interested to use scopehal with it (or even attempt at adding support if necessary). I had a look at the scopehal repo and saw two possible files indicating support for R&S scopes: RSRTO6Oscilloscope.h/cpp and RohdeSchwarzOscilloscope.h/cpp, which seem to be indipendent from each other. Which one do you think I should look at to investigate if my scope is supported, or work on to
<d1b2> support it? Thanks
<d1b2> <azonenberg> So there's two generations of R&S scope
<d1b2> <azonenberg> everything older than the RTO6 used one platform/command set (the RohdeSchwarzOscilloscope driver)
<d1b2> <azonenberg> the RTO6, RTP, and all new models introduced since then use the RTO6 family driver which is a completely new software platform
<d1b2> <azonenberg> You will probably want to use the older driver unless your scope family was introduced in the last few years
<d1b2> <rapgenic> I understand thank you a lot. I will have a look at the older one (since the series RT01000 is certainly a predecessor of RTO6)
<d1b2> <azonenberg> I know RTM3000 uses the older driver
<d1b2> <azonenberg> that's what we wrote the older driver for originally
<d1b2> <azonenberg> I don't think RTO1000 is a family anyone's ever attempted to use
<d1b2> <azonenberg> But if you're lucky it won't be too different
bvernoux has joined #scopehal
<d1b2> <azonenberg> as a minimum you will probably need to add new entries to the table of available sample rates / memory depths as this is hard coded per model in almost every driver
<d1b2> <rapgenic> About that I was doing some research this morning, and it seems that R&S provides a single driver for RTP, RTO & RTE families (also available in source) called rsscope, which apparently includes support for my series as well... So maybe (with lots of question marks) a single driver might be possible for all the families?
<d1b2> <rapgenic> I have to keep studying though 🙂
<d1b2> <azonenberg> On our side we have them separate because it keeps the code simpler
<d1b2> <azonenberg> you certainly could put a giant pile of if statements in every method to check which model you're running
<d1b2> <azonenberg> if you took that to the extreme you could make lecroy and keysight be the same driver :p
<d1b2> <azonenberg> it's just not beneficial to code readability or maintainability lol
<d1b2> <rapgenic> Yeah I can understand it's always difficult to find the balance between generality and readability
<d1b2> <rapgenic> So if (and again lots of question marks here) I tried to support my scope as well, and ended up writing some driver, would you prefer that I modify the current one (maybe trying to add some kind of generality) or rather that I write a completely different one?
<d1b2> <azonenberg> That's a bit of a judgment call depending on how sweeping the changes are
<d1b2> <azonenberg> Do the initial investigation and see what's different about your scope vs what's in there now
<d1b2> <azonenberg> and we can talk over what makes the most sense
<d1b2> <azonenberg> some scopes have totally new command sets every product
<d1b2> <azonenberg> OTOH, a LeCroy scope running Windows XP isn't that different API-wise from a Teledyne LeCroy released this year
<d1b2> <azonenberg> Where R&S falls in that continuum i couldn't tell you
<d1b2> <rapgenic> Understood 👍 as always back to studying then
<d1b2> <vipqualitypost> sorry for disappearing: i'm actually not looking at data per se, but we're having an issue with some weird noise in an 80MHz ADC and I'm suspecting that the problem is jitter, as we were able to reduce the noise by changing some stuff in the FPGA to try and get tighter timing, but I want to quantify the jitter and have not found a good method to do so yet, but eye pattern seems like it would be able to give us an idea of how tight the
<d1b2> timing actually is
<d1b2> <azonenberg> So we can actually do jitter analysis in ngscopeclient too
<d1b2> <azonenberg> If that's what you're trying to do
<d1b2> <azonenberg> How is the data structured - parallel clock+data or what?
<d1b2> <vipqualitypost> yeah, parallel
<d1b2> <vipqualitypost> i haven't been looking at data, just trying to characterize the clock line since that's what I was thinking was the problem
<d1b2> <vipqualitypost> I didn't realize you could do jitter analysis in ngscopeclient! is there a section in the manual for that or is it pretty obvious?
<d1b2> <vipqualitypost> the jitter spec for clock on our part is pretty tight, about 80fs RMS but I'm seeing like... nearly a nanosecond of trigger jitter, but that is not really any effective way to measure that, i think.
<d1b2> <azonenberg> So this is one of the features we really should document better
<d1b2> <azonenberg> but the basic idea is, you use the CDR PLL to lock to the waveform in question
<d1b2> <vipqualitypost> CDR?
<d1b2> <azonenberg> clock/data recovery
<d1b2> <vipqualitypost> ah
<d1b2> <azonenberg> then you use the TIE filter to compute the delta (time interval error) between the PLL clock edges and actual waveform edges
<d1b2> <azonenberg> which gives you the actual jitter at each edge in the input
<d1b2> <azonenberg> you can then either view that as-is or plot it as a histogram
<d1b2> <vipqualitypost> oh that makes perfect sense
<d1b2> <vipqualitypost> you're making me excited for monday
<d1b2> <azonenberg> or (currently broken due to a regression i haven't had time to fix) FFT it and see spectral peaks in the jitter
<d1b2> <azonenberg> if this is something you'd want to use i can try and prioritize the fix
<d1b2> <vipqualitypost> so I hooked the clock up to my specan, and I can see the peaks that show up in the PSD in the processed data as sidebands in the RF spectrum, but have been unable to see anything time domain
<d1b2> <vipqualitypost> I do want to use it, but the only scope that I have that has bandwidth to actually look at this also does not currently have a driver (I have been tinkering away on one for a while but as always get yanked onto other stuff)
<d1b2> <vipqualitypost> so don't worry about getting that up and running, but I am definitely going to try and finish that driver and then check that out.
<d1b2> <vipqualitypost> hmmmm, i forgot you can import raw data- i imagine this probably does not do well and there is not enough data to reconstruct an eye, but what do you think about that?
<d1b2> <azonenberg> Depends on how much data
<d1b2> <azonenberg> the more the merrier with eyes and jitter analysis
<d1b2> <vipqualitypost> i guess no limit to how much i could bring over, i'll give that a try
<d1b2> <vipqualitypost> i have 20Mpts so maybe just a few trips with a usb stick would be enough
<d1b2> <vipqualitypost> just using demo scope, but this makes sense and was very easy to set up
<d1b2> <vipqualitypost> so for a clock line without symbols, the symbol rate would just the the same as the clock rate right? ie one symbol per cycle?
<d1b2> <vipqualitypost> oh one thing i've been meaning to ask- is it possible to move "decoded" traces? like after i get the threshold, it puts the trace on the graph, but usually it's like not aligned where I want but I can't seem to drag it or do anything with it. ideally I would stack it at the top of the subwindow that it lives in, or inline with the little label for the channel
<d1b2> <azonenberg> What you're showing there is a bug
<d1b2> <azonenberg> the PLL trace should be aligned with the channel name
<d1b2> <vipqualitypost> that would be what I wanted too 😛
<d1b2> <azonenberg> File a ticket with as much info as you can get on OS, window manager, whatever
<d1b2> <vipqualitypost> yep, will do
<d1b2> <azonenberg> If you're doing jitter measurements of a clock, treat the clock as a 0-1-0-1 serial data pattern
<d1b2> <azonenberg> i.e. a 1 MHz clock is 2 Mbps data as far as the PLL is concerned
<d1b2> <vipqualitypost> that would make sense since you're triggering on one of those edges
<d1b2> <vipqualitypost> cool, thanks
<d1b2> <azonenberg> At some point we plan to make the output of the PLL more configurable (and support multiple options for loop filters etc)
<d1b2> <azonenberg> right now it's using a fixed loop design and produces a DDR output with each edge centered in the middle of the data period
<d1b2> <azonenberg> (i.e. a clock suitable for sampling the input on both edges)
<_whitenotifier-9> [scopehal-apps] VIPQualityPost opened issue #719: Decoded traces not properly aligned in window (macos apple silicon) - https://github.com/ngscopeclient/scopehal-apps/issues/719
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg> ok well this is weird i'm getting crashes in nvidia's spir-v library when trying to render sparse digital waveforms specifically from my trigger crossbar doing a PRBS check
<azonenberg> going to have to test that on another machine with a different gpu/driver version...
<d1b2> <vipqualitypost> when importing data should I take any care to align the ends of datasets to avoid abrupt changes? or that won't matter much?
<azonenberg> ends of datasets? no that shouldnt matter
<azonenberg> all of the clock recovery stuff etc only cares about full cycles
<azonenberg> it'll ignore any partial sutff after the last edge in the dataset