azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | | Logs:
Tost has quit [Ping timeout: 268 seconds]
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
apo has quit [Quit: apo]
apo has joined #scopehal
sam210723 has quit [Quit: Leaving]
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #scopehal
d1b21 has joined #scopehal
d1b2 has quit [Remote host closed the connection]
d1b21 is now known as d1b2
juli969 has joined #scopehal
<d1b2> <mubes> I'm intrigued to see what can be squeezed out of those with decent supporting software.
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 268 seconds]
maartenBE has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
bvernoux1 has quit [Quit: Leaving]
Tost has joined #scopehal
Tost has quit [Ping timeout: 265 seconds]
<_whitenotifier-5> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-5> [scopehal-apps] azonenberg 5273d88 - WaveformArea: fixed rendering artifacts with really wide text
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-5> [scopehal] azonenberg 5c5f723 - eSPI: can now decode general and CH1 capabilities registers. See #407.
<azonenberg> miek: ooh, looks like a good starting point
<azonenberg> although if i were to build one, i'd be designing it for multi GHz bandwidth
<azonenberg> i'd want something competitive with the lecroy/tek options
<miek> yeah, i really like how it walks through all the design decisions and reasoning. i figure it shouldn't be too hard to adapt for higher BW and it might already be better (the author didn't have the kit to test too high)
<azonenberg> Yeah
<azonenberg> i would also redesign the power stage for our usb-pd interface
<azonenberg> those AAs are massive
<azonenberg> the board would probably be 1/4 the size
<azonenberg> and have SMA input/output rather than BNC
<azonenberg> Can you file a ticket on the starshipraider repo for a power rail probe design?
<azonenberg> link to that, the TSP teardown of the tek one, the lecroy rp4030, and any other resources you can find
<azonenberg> Hopefully i can find some time this weekend to look at the current status of the PD board and figure out what needs to be done
<azonenberg> as of now i have one assembled board @david.lenfesty sent me and one bare board that needs to be populated
<azonenberg> the parts are likely to be hard to find though
<azonenberg> (yay semiconductor shortage)
<_whitenotifier-5> [starshipraider] miek opened issue #6: Design a power rail probe -
<azonenberg> noopwafel: ping
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-5> [scopehal] azonenberg bad5a42 - eSPI decode: implemented virtual wire packet format. See #407.
<agg> miek: oh cool, thanks for the link!
<agg> might try making a quick version of that too, though probably replace the AAs with a regular USB input or something off the scope front panel
<agg> wonder if there's any mileage to be had in amplifying the AC path to overcome scope frontend noise?
<agg> I guess just being 50r output would help a bunch.
<azonenberg> Yeah
<agg> would be nice to have my scope control the offset and so forth but seems like a lot of work to just mechanically interface, let alone the i2c or whatever protocol
<agg> hurry up and release your entire ecosystem please azonenberg :P
<azonenberg> lol
<azonenberg> hurry up and get me some more minions then
<azonenberg> and make this chip shortage go away
<miek> i may be digging through the firmware on my scope to see if i could do offset control from it right now :)
<agg> urgh this chip shortage is extremely boring
<agg> really "enjoying" trying to predict what chips we might want for the next 12m, finding replacements/new suppliers for most of them already out of stock, then sitting like a dragon on a stupid hoard of some particular dcdc converter
<agg> miek: oh, cool, which scope?
<agg> from tsp's teardown of the keysight one it really doesn't look like it should be all that complex, but figuring it out without a probe to RE seems much trickier, I guess the scope fw is a good starting point
<miek> agg: an agilent mso6034a
<agg> and if I had an n7020a I wouldn't need to make one, heh
<azonenberg> agg: yeah i just scored all of the HMCAD1520s I'd need to prototype a single ZENNECK channel
<azonenberg> i have a couple of artix7s left over from another project
<azonenberg> But the rest of the frontend is going to need more work still
<miek> mine's a bit too old to support the n7020a though, so i don't know if i can persuade it to control an offset like that
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±2]
<_whitenotifier-5> [scopehal] azonenberg 0a5b905 - eSPI: Added decode for channel 2 capabilities register. See #407.
<azonenberg> Ok, this is good progress
<azonenberg> If anybody here is doing Intel BIOS/firmware development/security work, you might find this useful
<azonenberg> kc8apf: ^
<azonenberg> It currently supports x1 and x4 modes but not x2 as the board i'm testing on doesn't use x2
<azonenberg> It's not done, I'm able to identify get status, get/put flash, get PC, and get/put IO write requests
<azonenberg> but not decode any of the myet
<azonenberg> and get-status seems to always report CRC errors despite everything looking right, so i think i'm miscalculating the CRC somehow
<azonenberg> Which is odd as the same CRC code works right with every other kind of packet
<_whitenotifier-5> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-5> [scopehal] azonenberg 5293d7d - eSPI: sample quad data in response on falling clock edge for better setup margin. See #407.
futarisIRCcloud has joined #scopehal
<kc8apf> Neat
<azonenberg> No LPC bus decode but that's on the agenda, i have some other stuff ahead of it
<azonenberg> Like MIL-STD-1553
<Degi> @ power rail probe: Why not just use AC coupling with a bigger capacitor?
<Degi> 10 µF on a 10 MOhm probe should give 100 seconds tau
<azonenberg> Now you're adding a lot of capacitance to the line which loads down the circuit
<azonenberg> and changes its behavior
<Degi> Wait what
<Degi> The capacitor is in series with the scope probe which is at 10 MOhm || 2 pF
<Degi> (Or an OP amp if you want 50 Ohm output)
<azonenberg> 10M || 2 pF is not any kind of scope probe i've ever seen, most are 10+ pF
<Degi> Hm really? I thought it was 2 pF in series with the scopes builtin 20 pF to give 10:1
<Degi> But I guess it has some internal capacitance too
<azonenberg> Typical capacitive loading of a normal R-C divider probe is on the order of 10-15 pF
<Degi> Hmm
<miek> the first few minutes of that Signal Path video explain the constraints really well
<azonenberg> and their impedance even at low tens of MHz is on the order of a couple hundred ohms
<azonenberg> dropping way down after that
<Degi> Though is that bad in this case? I mean power supplies usually can supply a bunch of current...
<azonenberg> The goal is non-intrusive measurements of things like transients caused by high speed SERDES switching
<Degi> Signalpath video?
<azonenberg> or GPIO crosstalk
<azonenberg> So you need GHz of bandwidth
<Degi> Ah yes, though in that case the linked design probably doesnt work at all
<azonenberg> and *especially* for anything within the loop bandwidth of the power supply, you want fairly high loading
<Degi> I mean it has 100 nF and 10 ohm to 50 ohm scope...
<Degi> Hm, for switching regulators you probably won't get problems with that unless you have like quite high / several nF capacitance... (though linear ones could be a problem)
<azonenberg> Before we do anything else I want to do a VNA sweep of the RP4030 I ordered and see what shakes out
<Degi> How come it has 1.2 x attenuation? I saw that mentioned on the other page too, is there a specific reason for that value?
<azonenberg> That I'm not sure of
<Degi> Hmm, I wonder how good the circuitcellar probe is
<azonenberg> Good question. The guy who designed it couldn't test past 100 MHz
<azonenberg> If somebody wants to build one off his design, i could run some VNA testing on it
<Degi> I mean its similar to how I'd design it if I want a cheap probe which measures noise on a DC rail
<azonenberg> although i dont have the time to pick out parts and order it etc
<Degi> Hmm, maybe
<azonenberg> if one shows up in my mailbox i'll measure and mail back
<Degi> A bit of a problem seems to be compensation because there's going to be a dip or peak somewhere
<Degi> (I once tried designing something similar in ltspice for an isolated probe)
<miek> keysight's been a bit misleading, on their site they say 1:1 but it's actually 1.1:1 for the 2GHz probe, 1.3:1 for the 6GHz
<Degi> (Where you split DC and AC paths)
<Degi> huh
<azonenberg> Yeah, i suspect we will need to do some de-embedding to get good results with it
<azonenberg> this is what the real vendor probes do
<Degi> Do they give you s2p data to deembed?
<azonenberg> They apply unspecified correction filters to flatten response
<azonenberg> it's done automagically
<Degi> Ah, thats what the extra pins are for?
<azonenberg> details of implementation are unknown AFAIK
<Degi> Hm, how much dB of dip would be acceptable?
<azonenberg> The probus interface provides +/- 12V power, a presence detect signal, ground, and I2C
<azonenberg> in all active probes, the I2C gives access to a descriptor EEPROM that identifies the probe model, serial number, etc. Some of this eeprom format has been RE'd
<Degi> I mean it could just read out a flash over I2C... (Well I don't have one to disassemble xD)
<Degi> Neat
<azonenberg> additionally, some probes also have other I2C functionality for things like gain or offset adjustment
<azonenberg> e.g. the RP4030 has a... 30V, I think, offset range
<azonenberg> i assume this is an i2c dac somewhere
<Degi> Oh, that TSP video seems pretty near to the circuitcellar circuit
<miek> the pricing on these is crazy to me. i get that it takes a bunch of design time, but for what's inside the n7020a $3.5k is absurd
<azonenberg> Higher end WaveLink probes are individually calibrated and and some form of the frontend response is stored on the probe somehow
<Degi> oof
<azonenberg> Unsure if s-parameters or something simpler like FIR filter coefficients
<Degi> Hmm, maybe s2p and scope converts to FIR coefficients depending on the frontend?
<azonenberg> miek: and this is why i'm trying to design better probes lol
<miek> :)
<Degi> I could get like 3.5 rigols for that
<azonenberg> degi: no, i think it's more likely they VNA the probe in the factory
<azonenberg> then make a FIR filter with the inverse response
<Degi> Hmm
<azonenberg> and store the tap values on the probe eeprom
<Degi> I mean that'd work too
<Degi> Hmm
<azonenberg> correction for scope frontend performance is done separately inside the scope
<Degi> Maybe it can be reverse engineered by making a custom probe and then changing stuff in the EEPROM lol
<Degi> Ah
<azonenberg> There has been some RE of the probus eeproms already
<azonenberg> I just havent had time to look at what's known
<Degi> hm okay
<Degi> How come they have 50 kOhm? To keep noise low?
<miek> to avoid putting any significant load on the supply
<Degi> I mean why not use like 50 GOhm?
<Degi> (Or 1-10 MOhm like usual probes / multimeters)
<Degi> (Also if you used higher resistances you could use higher voltages)
<Degi> That's quite an FPGA board at 18:30
<Degi> azonenberg, is 6 dB attenuation with 1 dB ripple good enough?
<Degi> (from 5 to 7 dB)
<azonenberg> Maybe? i mean i'd prefer flatter
<Degi> Got to 5.7-6.8 dB
<Degi> Kinda hard
<miek> hm, i think the HRA marking on the opamps in the teardown points at the AD8065
<Degi> 5.94-6.21
<Degi> But needs 470 nF cap which might be hard to get
<Degi> (I guess you can combine film cap and SMD cap)
Tost has joined #scopehal
<Degi> 6.02-6.26 dB, seems better
<Degi> I mean thats a 1.05:1 voltage ratio
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<miek> i sketched out what i think is the schematic for the n7020a:
<azonenberg> miek: where did you get that from? TSP teardown?
<miek> azonenberg: yup
<miek> also tnt's thread on the autoprobe/smartprobe interface mentions that there's a +/-1mA current source for setting probe offset
<azonenberg> interesting that it's current and not voltage mode
<azonenberg> if it was me, i would have done the DC path using a high impedance resistive divider then like a +/- 5V voltage source
<azonenberg> and a voltage feedback amplifier
juli969 has quit [Quit: Nettalk6 -]
<miek> i guess it's a good way to get a precision reference to the end of a probe while avoiding issues with noise or contact/lead resistance & keeps the expensive parts in the scope
Tost has quit [Ping timeout: 265 seconds]
<azonenberg> miek: well the RP4030 is a box that mates with a probus interface and has a SMA input
<azonenberg> from what the drawings show
<azonenberg> it looks like the N7020A is similar
<azonenberg> now you know what's *really* interesting? the bandwidth of the various RP4030 accessories
<azonenberg> So it looks like the probe itself has a SMA input but it comes with a SMA-MCX cable
<azonenberg> They have short lengths of coax with MCX terminations on the end that are intended to be soldered directly to the DUT
<azonenberg> that, and a MCX cable on the DUT, give full 4 GHz BW
<azonenberg> the U.FL adapter only goes to 3
<azonenberg> and - this is the interesting part
<azonenberg> the handheld browser is only 350 MHz
<azonenberg> what i find interesting is that the browser is actually a PP066 7.5 GHz transmission line probe
<azonenberg> but with a straight-through wire instead of a resistor
<azonenberg> So why does it perform so poorly?