azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
bvernoux has joined #scopehal
massi has joined #scopehal
someone-else has joined #scopehal
bvernoux has quit [Ping timeout: 265 seconds]
bvernoux has joined #scopehal
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 256 seconds]
<someone-else> hi, doing some market research
<someone-else> if one had a 5-10GHz active probe with max 4Vpp input range, what would be the most useful way to center this range around ground potential? e.g. 0..+4V -1..+3V -2..+2V etc
<someone-else> it's possible to make this adjustable, but a fixed input range would be so much simpler (no dac/micro/usb etc)
bvernoux has joined #scopehal
<electronic_eel> someone-else: there are lot's of different ways to bias the signals used out there. the signal could be ac-coupled around ground, you could also want to use it to probe a 3v3 power rail. there are also lvpecl, lvds and so on
<electronic_eel> i don't think it would live to it's full potential if you don't have a way to set the range
bvernoux1 has quit [Ping timeout: 265 seconds]
<electronic_eel> if you don't want a dac, maybe just some fixed levels created by voltage dividers you can select from?
<electronic_eel> or an external biasing input you can use if you don't like the presets?
<someone-else> sure, but, say, -1..+3V or so would fit most of currently used high-speed data standards up to and including (barely) lvpecl
<electronic_eel> but you wouldn't be able to use it to probe the 3v3 power rail, you'd want 0v...4v for this
<someone-else> makes sense
<someone-else> on the other hand, one can probe power rails using a simpler Z0 probe with 500ohm impedance
<someone-else> active probe would be most useful for high-speed data links
<someone-else> GHz high-impedance voltage dividers are very cursed, trying to avoid
<electronic_eel> what does the amplifier in the probe need to set the range?
<someone-else> mostly just shifting power supplies around ground
<someone-else> but then there's offset and gain correction - gets more and more complicated once you start thinking about adjusting things via dacs
<someone-else> maybe we can update the original question with 5Vpp input range instead of 4Vpp
<someone-else> would this make choosing a fixed input range easier?
<someone-else> any 3.3V logic + over/undershoot should then fit
<electronic_eel> yes, i'd think that would cover most cases then
<electronic_eel> so 5vpp would be the maximum usable signal range. what is the damage level?
<someone-else> damage level would be somewhat larger but not by much, i.e. a volt below or above at the most
<someone-else> haven't done any long-term reliability testing yet
<electronic_eel> what if you accidently mix up the two inputs then? for example connect the negative side to 3v3. i don't think that kind of mistake is too uncommon.
<electronic_eel> or would that be no problem because it is still within the allowed range?
<someone-else> it's a single-ended probe, so the negative input is just ground
<someone-else> so probe will be fine, provided scope/DUT are common ground, might be bad for the DUT though..
<someone-else> have to run, back in an hour
someone-else has quit [Quit: Connection closed]
<electronic_eel> ah, ok, so no problem for the probe.
someone-else has joined #scopehal
Famine_ has joined #scopehal
Famine- has quit [Ping timeout: 265 seconds]
bvernoux has quit [Ping timeout: 265 seconds]
bvernoux has joined #scopehal
massi has quit [Remote host closed the connection]
<azonenberg> someone-else: What amplifier are you thinking of using?
<azonenberg> because i feel like i covered the available COTS options pretty well
<azonenberg> If you AC couple it's easy
<someone-else> it's an emitter follower
<azonenberg> oh so just a single transistor?
<someone-else> yep
<azonenberg> Good luck getting the right flatness
<azonenberg> if you can pull it off i'll be impressed
<azonenberg> Single ended not differential?
<someone-else> se
<someone-else> but there's a board with two copies side by side, not tested yet
<someone-else> it's actually working fine with ~4GHz -3dB bandwidth right now
<someone-else> can be dialed higher, but becomes ringy
<someone-else> can probably get to 10GHz with DSP correction
<someone-else> ringing is happening due to tip inductance-input capacitance resonance
<someone-else> getting rid of it by increasing the tip resistors lowers the bandwidth to ~4GHz
<someone-else> the best part about using emitter follower these days is there are 300,000 in stock
<someone-else> there's a lmh3401 board yet to be tested, too, but I don't have high hopes for it
GenTooMan has quit [Ping timeout: 264 seconds]
<electronic_eel> ti markets the lmh3401 just for 2 ghz - there is probably a good reason for that
<someone-else> electronic_eel: it's probably because they have higher standards for flatness/THD than I do
<someone-else> which are important for receiver adc driving and such and not so much for scopes/probes
<electronic_eel> hmm, why is flatness not important for a scope probe? because you plan to do heavy corrections in software?
GenTooMan has joined #scopehal
<someone-else> well, flatness is important, but to a lesser degree
<someone-else> DSP corrections are possible, too
<azonenberg> I've already tested the LMH3401 or 5401 and wasnt happy with performance
<electronic_eel> dsp corrections are usually not possible for triggering. so you can't overdo it without affecting proper triggering
<azonenberg> electronic_eel: that's something I want to support in my bigger scopes down the road
<azonenberg> gateware triggering after realtime FPGA de-embed on the ADC data
<azonenberg> by pushing a response network to the FPGA
<electronic_eel> ok, that sounds interesting. would require a decent fpga, right? so commercial highend scopes have something similar?
<someone-else> electronic_eel: I'm using a sampling scope anyway, so trigger is not particularly affected for repetive signals
<someone-else> R&S has fully digital trigger on some of their faster scopes
<someone-else> fully digital as in post-adc
<electronic_eel> does "fully digital" mean you can upload a touchstone file and it does deembedding?
<someone-else> azonenberg: lmh3401's main problem is single-ended output configuration, I think
<someone-else> electronic_eel: I don't know, it's probably not user-accessible
<electronic_eel> so it only works for their own probes with cal data in some eeprom? that would be so corporate-bad as always
<someone-else> azonenberg: this might be solved by using lmh3401 with two scope channels, perhaps. but this would defeat the point since one can just use two single-ended probes then
<azonenberg> electronic_eel: Well you'd need a beefy FPGA to keep up with the 12 lanes of JESD204B coming off the ADC anyway :p
<someone-else> electronic_eel: probably, what to expect from them
<someone-else> *what else
<azonenberg> as an example, for my new proposed ZENNECK design, I'll have one XC7A200T *per channel* to run the ADC and DDR buffer
<azonenberg> So I'll have 740 DSP48E1 blocks to process the waveform data
<electronic_eel> bah, makes it much less useful. their engineers should know that in these speed regions you can't just slap a high-end probe on the dut and the problem is solved. you may need to develop stuff like custom interposers and so on to properly probe your signals. can't get that stuff off-the-shelf for every problem
<azonenberg> LeCroy has their "eye doctor" software package that lets you do s-param de-embedding with arbitrary networks post trigger
<azonenberg> but not pre trigger
<azonenberg> I know there is flatness correction being done for the scope frontend as well as active probe response but IDK where in the pipeline that is
<azonenberg> AFAIK most LeCroy stuff uses hardware edge triggering
<azonenberg> sine they have the TDC for trigger interpolation
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J10mW
<_whitenotifier-1> [scopehal-apps] azonenberg 328dd13 - Styles: updated progress bar text color so it doesn't look weird on some themes
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J10cI
<_whitenotifier-1> [scopehal] azonenberg 99d4777 - Implemented decoding of CMD1 for EMMC. Added merging of CMD1 and CMD13 replies. Fixes #514.
<_whitenotifier-1> [scopehal] azonenberg closed issue #514: Decoding for eMMC SEND_OP_COND / CMD1 - https://git.io/JrJmI
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J10Cv
<_whitenotifier-1> [scopehal] azonenberg 23a9d18 - SDCmdDecoder: merge STOP_TRANSMISSION command with a multi-block read/write
<_whitenotifier-1> [scopehal] azonenberg opened issue #520: eMMC: Decoding of SEND_EXT_CSD command output - https://git.io/J10E6
<_whitenotifier-1> [scopehal] azonenberg labeled issue #520: eMMC: Decoding of SEND_EXT_CSD command output - https://git.io/J10E6
<_whitenotifier-1> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J10gc
<_whitenotifier-1> [scopehal] azonenberg b393611 - Implemented decoding of eMMC CMD6 SWITCH for writing EXT_CSD register
<_whitenotifier-1> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/J10g4
<_whitenotifier-1> [scopehal-apps] azonenberg 822ec4a - Updated submodules
bvernoux has quit [Read error: Connection reset by peer]
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
balrog has quit [Read error: Connection reset by peer]
balrog has joined #scopehal