<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+1/-0/±4] https://git.io/JJ2lf
<_whitenotifier-b>
[starshipraider] azonenberg 6b478ea - Continued work on probe manual
<azonenberg>
monochroma: btw, have you ever seen another probe that published frequency response data including the ground accessories rather than just of the probe itself in an ideal fixture?
<monochroma>
don't think so, but i also don't have any high speed probes :P
<monochroma>
other than your solder down ones
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJ2la
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJ20A
<_whitenotifier-b>
[starshipraider] azonenberg 3ec185e - Minor formatting fixes to manual
<_whitenotifier-b>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJ2Ef
<_whitenotifier-b>
[scopehal] azonenberg 17ba6a9 - DeEmbedDecoder: fixed truncation of de-embedded waveforms, allowed viewport to be rescaled to actual waveform bounds in case S-parameters have significant gain/loss
<miek>
huh, i was just looking into feedthroughs and ... i hadn't realised how bad they can perform. i'd never considered that you still have that 10-15pF in parallel with it, so it doesn't look like 50ohm for long
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
<azonenberg>
miek: lol. yeah, that and you have the huge unterminated stub from there to the scope input
<azonenberg>
soooo anybody have ideas on what might be going on here?
<azonenberg>
at top we synthesize a PRBS through a Kintex-7 LVDS output driver at 1.25 Gbps
<azonenberg>
then i shift it down to zero DC bias and run a CDR PLL on it
<azonenberg>
then do a fairly minimal channel emulation (on one of the nice mini-circuits cables) and CDR on that in orange
<azonenberg>
then the bottom two graphs i plot the total interval error, i.e. the delta from waveform zero crossing to the nearest edge of the CDR clock
<azonenberg>
you can see it's pretty flat with just a few ps of noise on the original waveform
<azonenberg>
but when i do the channel emulation, there's something really weird going on early on, then it takes a while to recover and eventually achieves lock
<azonenberg>
see my twitter thread. Basically, there is garbage before the first sample in my waveforms that have a phase shift due to cable length effects
<azonenberg>
i *think* this is because the inverse fft can't just *not produce output* when the input is phase shifted
<azonenberg>
so i think it ends up rotating??
<azonenberg>
or something like that
<azonenberg>
because the fft doesn't just brick wall
<azonenberg>
something has to be output at time zero
<azonenberg>
and if there's a phase shift, i'm not quite sure where that data comes from
<azonenberg>
but it confuses my CDR, because it's not aligned to the embedded clock in the rest of the signal :p
<azonenberg>
sooo i think what i need to do is calculate the group delay of the s-parameters at a relatively low frequency
<azonenberg>
and discard anything earlier than that
<azonenberg>
unless there is a better way to figure this out from the fft itself?
<lain>
mmm I don't know off the top of my head but I suspect there is a way to trivially calculate the number of samples you need to discard
<azonenberg>
me too
<azonenberg>
lol
<azonenberg>
And i think i have to discard at the beginning or end
<azonenberg>
depending on the direction of the phase shift
<azonenberg>
so truncate the end when de-embedding and the beginning when emulating a channel
<azonenberg>
But the first step either way is to figure out the magnitude of the phase shift. Which is not constant obviously
<azonenberg>
I'm going to approximate by calculating the group delay at the lowest few frequencies, call that the group delay of the channel, then add 10% or so to be safe
<lain>
like, with FIR filters, you discard the number of taps worth of samples iirc
<lain>
because that's just going to be transient response at startup
<lain>
once the pipeline is full, then you can begin to use the output
<azonenberg>
yeah but here it depends on the phase response of the channel
<azonenberg>
so i think i have to actually calculate group dealy
<azonenberg>
delay*
<azonenberg>
Which is pretty trivial
<azonenberg>
it's just -dPhase/dFreq
Nero_ has joined #scopehal
Nero_ is now known as Guest70879
Guest70879 is now known as NeroTHz
<_whitenotifier-b>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JJ2PF
<_whitenotifier-b>
[scopehal] azonenberg 0e54ac9 - Fixed incorrect interpolation in Touchstone files with significant gain/attenuation near DC. Fixed bug where de-embed/channel emulation filters would output garbage during the phase shift window. Fixes #204.
<_whitenotifier-b>
[scopehal] azonenberg closed issue #204: Channel emulation / de-embed filters output garbage before first sample if phase shifting forward - https://git.io/JJ2zQ
<azonenberg>
I still want to fine tune my CDR more because this bug is not related to my difficulty locking to 10Gbase-R
<azonenberg>
I think if i'm reeeally careful i have a chance of pulling it off
<lain>
nice! and yeah now that I think about it, you're exactly right, it just happens that the delay of an N-tap FIR filter is typically N samples, except when it's not, which has to do with the value of N and something I forget :P
<azonenberg>
lain: that's a 1Gbase-X ethernet signal, btw
<azonenberg>
middle = as seen by the scope
<lain>
aha
<azonenberg>
bottom = emulating an AKL-PT1 using the leaf ground
<azonenberg>
(actual S-parameter data for the one i'm sending to shahriar)
<azonenberg>
top = after de-embedding the minicircuits cables between the fixture and scope
<azonenberg>
Minimal change, since they're very nice cables, but it's there if you look
<noopwafel>
azonenberg: do you have a preference for SCPI commands for bridges? LeCroy-style?
<azonenberg>
what do you mean "style"
<azonenberg>
you mean no colon prefix? or what
<azonenberg>
my thought was that it would read each line exactly as is
<noopwafel>
I mean e.g. commands for configuring triggers
<azonenberg>
i was thinking of the bridge working much lower level
<noopwafel>
things like colon prefixes are trivial to change
<azonenberg>
When you see a command come from a client, put into a transmit fifo
<noopwafel>
oh, sorry: I mean for bridging comms with scopes which don't talk SCPI.
<azonenberg>
Oh
<azonenberg>
oh
<noopwafel>
(I seem to be collecting them.)
<azonenberg>
my thought was that we'd write drivers that derive directly from Oscilloscope, not SCPIOscilloscope
<azonenberg>
and have the scopehal API be the common ground
<azonenberg>
that's what i do for e.g. my fpga la's
<azonenberg>
trying to pretend to be a specific scope seems like a waste of effort
<azonenberg>
unless you can think of a reason why you'd want to do this?
<azonenberg>
What I *do* want to do eventually is allow you to marshal *the entire Oscilloscope class API* across a network
<azonenberg>
so you can do things like plug a picoscope into a PC then access it remotely
<azonenberg>
but that would likely be protobufs or similar using a remote procedure call interface, not scpi
<noopwafel>
well, for picoscope, the API is proprietary blobs, so right now I have SCPI bridge hack
<azonenberg>
so your goal is specifically working around incompatible licenses?
<noopwafel>
and for the scope I'm poking at now, I have a driver full of libusb
<azonenberg>
that might be helpful for something like sigrok but the BSD license scopehal is distributed under is compatible with proprietary licenses
<noopwafel>
if you're happy linking in libusb then .. I guess it's easier to just directly write a driver
<azonenberg>
Yeah just do that
<azonenberg>
i have no problems with pulling in libusb as long as it's an optional dependency
<azonenberg>
i.e. check if libusb is installed and if not, disable that driver
<noopwafel>
hm, LGPL
<noopwafel>
I guess fine
<azonenberg>
LGPL is fine, gtk and a bunch of other stuff we use is LGPL
<azonenberg>
the big thing to avoid is stuff like FFTW that are full GPL
<noopwafel>
ok. thanks!
<azonenberg>
as that would require someone linking to scopehal to release their source
<noopwafel>
right, and this is not great for the wide-adoption thing
<azonenberg>
Yeah
<noopwafel>
so ok, let me (after more Rigol fixes..) produce a prototype for the libusb thing, which probably involves dramatic expansion of the Oscilloscope API at some point
<azonenberg>
I expect we will have to expand the API a lot for variuos stuff. in particular LA pattern triggers and protocol triggers are completely unsupported
<azonenberg>
the lecroy driver has some bandaids to support channel interleaving if you configure it on the scope
<noopwafel>
right, that kind of thing :)
<azonenberg>
but we have neither APIs nor a UI to turn it on and off
<noopwafel>
triggers are where I hit a dead-end with sigrok
<azonenberg>
There's also a bunch of UI work needed around triggering in general
<azonenberg>
for example, right now there's the little triangle on the right side of the active trigger channel you can drag to adjust the trigger level
<azonenberg>
but if you change the vertical gain or offset and it goes offscreen, there goes your trigger control :p
<azonenberg>
the icon should clip to the edge of the channel so you can still grab it to move it
<azonenberg>
We have a ticket for that but i've been busy fixing other things
m4ssi has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
_whitelogger has joined #scopehal
m4ssi has quit [Ping timeout: 265 seconds]
m4ssi has joined #scopehal
NeroTHz has quit [Read error: Connection reset by peer]
m4ssi has quit [Remote host closed the connection]