azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+1/-0/±4]
<_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]
<_whitenotifier-b> [starshipraider] azonenberg 734b1d6 - Fixed page break
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
<azonenberg> monochroma: also woo shahriar replied to me, i have a shipping address for the probe now. Gonna send it out early next week
<monochroma> :D!
<monochroma> is he excited?
<azonenberg> Seems to be
<monochroma> yay
<monochroma> azonenberg: where did you get the Warranty section from?
<azonenberg> I modeled it on a bunch of other test equipment docs plus the bsd license
<monochroma> looks good but obviously i am not a lawlyer
<azonenberg> me neither :p
<Bird|otherbox> that's actually the most useful Prop65 warning that I've seen in some time
<monochroma> Bird|otherbox: XD
<monochroma> yeah, maybe add a note like "we do not recommend sharpening the probe tips"
<monochroma> :P
<azonenberg> monochroma: i do not believe the tips are BeCu
<azonenberg> only the contact of the female socket
<azonenberg> the little springy bit inside the brass shell
<monochroma> what about the SMA?
<azonenberg> Same with the SMA. The center contact only
<azonenberg> the shell is gold plated brass
<azonenberg> Bird|otherbox: because i'm trying to be useful, not just make the lawyers happy :p
<azonenberg> To be useful, a warning needs to communicate:
<azonenberg> 2) the nature of the hazard
<azonenberg> 3) actions which may be taken to reduce risk
<azonenberg> 1) the presence of a hazard
<Bird|otherbox> exactly!
<Bird|otherbox> BTW: you have to have a pretty darn cruddy instrument to not have 50ohm capability, I'm pretty sure my Rigol has it
<miek> a lot of the rigols don't have it, it's pretty uncommon on all the lower end scopes
<Bird|otherbox> huh
<Bird|otherbox> let me fire things up and check
<Bird|otherbox> actually, you're right, my bad
<Bird|otherbox> mixed things up there for a bit
<Bird|otherbox> azonenberg, a quick formatting note on 5.1 in the instructions, the (R) symbol isn't superscripted the way one'd expect it to be
<smkz> azonenberg: typo on page 3; "made possibly" should be "made possible"
<azonenberg> smkz: thanks, fixed
<azonenberg> Bird|otherbox: yeah i bought some 50 ohm bnc feedthroguhs to do 50 ohm inputs to my ds1102d back in the day
<azonenberg> re the (R) i'm aware, i havent found a better way to do it in LaTeX
<azonenberg> this is \textregistered
<azonenberg> if there's a better option let me know
<Bird|otherbox> let me do a bit of research
<azonenberg> Meanwhile, i'm off to do battle with the CDR PLL
<azonenberg> Which my more advanced experiments are breaking :p
<Bird|otherbox> azonenberg, on the \textregistered thing
<azonenberg> Fixed
<_whitenotifier-b> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-b> [starshipraider] azonenberg 3ec185e - Minor formatting fixes to manual
<_whitenotifier-b> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_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> zoomed in, you can see the CDR on the normal waveform starts out pretty much dead on
<azonenberg> (it's trying to lock to 90 degrees from the data so that you can use rising and falling recovered clock edges to sample the bits)
<azonenberg> But early on, the recovered clock on the waveform after channel emulation is almost in phase, i.e. 90 degrees off from where it should be
<azonenberg> then over the course of about 80-100ns it slews towards the correct alignment, and it's good from there on out
<azonenberg> so what's different about those waveforms that is confusing my PLL?
<_whitenotifier-b> [scopehal] azonenberg opened issue #204: Channel emulation / de-embed filters output garbage before first sample if phase shifting forward -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #204: Channel emulation / de-embed filters output garbage before first sample if phase shifting forward -
<_whitenotifier-b> [scopehal] azonenberg opened issue #205: Channel emulation / de-embed filters segfault when loading from file (null touchstone data) -
<_whitenotifier-b> [scopehal] azonenberg labeled issue #205: Channel emulation / de-embed filters segfault when loading from file (null touchstone data) -
_whitelogger has joined #scopehal
<azonenberg> oook so i've made some progress
<azonenberg> lain: so interesting observations
<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]
<_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 -
<azonenberg> lain: ^
<azonenberg> fixed
<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]
<bvernoux> Hello
<bvernoux> They reached >1MUSD Amazing
<bvernoux> I have bought one ;)
<bvernoux> As I know well Pavel Zhovner ...
<miek> the "limited" number of early bird units thing is sneaky :p
<bvernoux> hehe yes ;)
<bvernoux> It is just amazing to have sold so much stuff like that which are really limited to small community in theory
<bvernoux> THe marketing & video are very fun too ;)
<miek> yeah, i didn't know it would do numbers like that
<miek> i guess part of it might be that it's making "hacking" look more approachable, so the community is not so limited
<bvernoux> yes clearly
<bvernoux> their campaign is a huge success for that I think too
<bvernoux> Fun & Nice Video to show anyone can hack things with fun ;)
bvernoux has quit [Quit: Leaving]
maartenBE has quit [Ping timeout: 240 seconds]
maartenBE has joined #scopehal