<d1b2>
<fredzo_72653> @azonenberg 🔼 PR to fix time-base settings from ngscopeclient on DHO models. Its working nicely on my DHO900 but will need testing on DHO1000/4000. @josHua if you can take a look with your DHO4000: is kind of guessed the samplerate et memory depth values for this model... Also on the DHO800/900 the timebase factor needed to calculate the horizontal scale from srate and mdepth is not constant (varries from 10 to 20 depending on the
<d1b2>
srate...). Maybe you'll have to check if it's the same on the DHO4000.
<d1b2>
<azonenberg> wrt horizontal scale, my guess is this has to do with whether interleaving is active
<d1b2>
<azonenberg> i.e. are you sampling with one or two ADCs per channel
<d1b2>
<fredzo_72653> Does not seem so: it varies event if only one channel is active
<d1b2>
<azonenberg> huh
<d1b2>
<azonenberg> interesting
<d1b2>
<azonenberg> does it only turn on at really high sample rates?
<d1b2>
<azonenberg> i.e. its possible they auto enable interleaving with one channel but only at the highest sample rates
<d1b2>
<fredzo_72653> I had to create an excel sheet to understand what was happening!...
<d1b2>
<azonenberg> That feels like some kind of clock divider setting
<d1b2>
<fredzo_72653> Yes that's what I thought... Srate values are quite odd on this model : starts at 1.25Gsa/s and gets divided but then drops to 156.250 Msa/s
<d1b2>
<azonenberg> That's not odd at all
<d1b2>
<fredzo_72653> right the next one is odd 😉
<d1b2>
<azonenberg> at least, not at someone who spends a lot of time in the SERDES world
<d1b2>
<azonenberg> 156.25 is 1250 / 8
<d1b2>
<azonenberg> it's a very common clock rate for 1.25 Gbps SERDES with an 8-bit datapath, or a reference clock for a 1.25 Gbps SERDES PLL
<d1b2>
<azonenberg> also 125 and 312.5 (divided by 4 and 10 respectively)
<d1b2>
<azonenberg> or 625 for divide by two if you're just using DDR flipflops
<d1b2>
<azonenberg> you see these frequencies in 10GbE too for the same reason
<d1b2>
<azonenberg> 312.5 MHz is 10 Gbps / 32
<d1b2>
<azonenberg> (although depending on how the clocking is structured since the line rate is 10.3125 Gbps, you sometimes see 322.265625 MHz or multiples/divisions of it)
<d1b2>
<azonenberg> so basically it seems like they have a 1.25 Gsps ADC and divide down by integers from there
<d1b2>
<fredzo_72653> Yes I guess there's a logic explanation for these values, I just don't see it from here 🙂
<d1b2>
<azonenberg> Yeah, i just recognized integer divisions of 1.25 GHz instantly because it's such a common clock frequency
<d1b2>
<azonenberg> especially for ethernet
<d1b2>
<fredzo_72653> Andrew if I may take some more of your time, I have seg faults when using EyePattern with the DHO driver
<d1b2>
<fredzo_72653> Thread 12 received signal SIGSEGV, Segmentation fault. [Switching to Thread 40216.0xa6a4] 0x00007fff63d709cb in EyePattern::DensePackedInnerLoop (this=this@entry=0x14d15010, waveform=0x14bc7630, clock_edges=std::vector of length 2218, capacity 4096 = {...}, data=data@entry=0x1dbd6040, wend=wend@entry=99999, cend=cend@entry=2217, xmax=xmax@entry=2047, ymax=ymax@entry=1023, xtimescale=xtimescale@entry=707788800,
<d1b2>
<azonenberg> Likely unrelated, i.e. its a driver crash or an eye filter crash
<d1b2>
<azonenberg> i cant imagine a filter crash being specific to a driver
<d1b2>
<azonenberg> Hmm. Can you save a scopesession with the offending waveform, clock. and data but the clock not supplied to the eye filter?
<d1b2>
<azonenberg> and if so, does it crash reliably when you connect the clock?
<d1b2>
<azonenberg> if you can get that, i'll try and debug on my end
<d1b2>
<fredzo_72653> No it crashes after a few tenth of seconds of acquisition
<d1b2>
<azonenberg> yeah but you have to hae set up the decode fully if it's reaching that point
<d1b2>
<azonenberg> i'm talking about capturing waveforms first, then setting up the eye filter without connecting the clock
<d1b2>
<azonenberg> so it shouldnt actually run th efilter
<d1b2>
<azonenberg> then set up whatever filters you're using to generate the clock
<d1b2>
<azonenberg> at this point you should have no crashes since the filter isn't being evaluated
<d1b2>
<fredzo_72653> The clock is UART
<d1b2>
<azonenberg> you're using the uart cdr filter? ok
<d1b2>
<fredzo_72653> Uart Clock recovery filter
<d1b2>
<azonenberg> anyway if you can acquire data first, save it, set up as much of the filter graph as possible before it crashes., saving after making each connection
<d1b2>
<azonenberg> and tell me what the missing link is to make it crash
<d1b2>
<azonenberg> ok. can you save the session in that state?
<d1b2>
<azonenberg> and send me the session (make sure to include the _data directory as that's where the waveforms live)
<d1b2>
<azonenberg> i'll load offline and see if i see anything wrong with it
<d1b2>
<azonenberg> My guess is the uart cdr filter is doing something the eye filter doesn't like
<d1b2>
<azonenberg> the eye filter is supposed to be bounds checking all of the clocks to make sure they're valid and preventing it from scribbling over offscreen pixel locations but i'm guessing something is buggy there
<d1b2>
<fredzo_72653> Now it's running OK with the complete setup :
<d1b2>
<azonenberg> Ok will have a look in a bit, about to make lunch
<d1b2>
<fredzo_72653> OK thx, have a nice lunch, it dinner time here 🙂
<d1b2>
<josHua> I will look in a moment. Did you back out my anti-fix for yoffset in there? If not, you should.
<d1b2>
<fredzo_72653> xoffset you mean ? did not touch that no, it seamed to work for me
<d1b2>
<azonenberg> @fredzo_72653 so the issue is the mismatch between how the driver behaves and how all other drivers do
<d1b2>
<azonenberg> in that T=0 should be the start of the acquisition, not the trigger timestamp
<d1b2>
<fredzo_72653> Oh that's what causes the segfault ?
<d1b2>
<fredzo_72653> Or do you mean josHua's "anti-fix" ?
<d1b2>
<azonenberg> i mean the anti-fix
<d1b2>
<azonenberg> this is unrelated to the crash which i havent had a chance to look at
<d1b2>
<azonenberg> it just causes the gui to act differently with this one scope model than every other
<d1b2>
<azonenberg> which is obviously bad for what's supposed to be a universal tool 🙂
<d1b2>
<fredzo_72653> OK got it
<d1b2>
<fredzo_72653> Yes I figured that trigger point was à T=0 which is not consistent with what you said it should be
<d1b2>
<fredzo_72653> I'll take a look
<d1b2>
<fredzo_72653> to fix that
<d1b2>
<azonenberg> Yeah. We specifically measure time differently from how a lot of scopes do (trigger=0) as this works better with e.g. multiple instruments
<d1b2>
<azonenberg> if you can add that change to the current PR i'll review once you get that done
<d1b2>
<fredzo_72653> OK no problem
<d1b2>
<fredzo_72653> I'm out of luck for the sanitizer, it does not seem to be available on windows 😕
<d1b2>
<azonenberg> ah ok i'll see what i can find on my end then with your dump when i have time