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
vup2 has joined #scopehal
vup2 has quit [Read error: Connection reset by peer]
someone--else has quit [Quit: Connection closed]
vup2 has joined #scopehal
vup2 has joined #scopehal
vup2 has quit [Client Quit]
xzcvczx has joined #scopehal
<xzcvczx> >_< dammit libera.chat why do you not autoreconnect
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
azonenberg_mobil has joined #scopehal
<azonenberg_mobil> soo i just realized something
<azonenberg_mobil> The planned DUDDELL design has one adc per frontend. but the hmcad1520 has four inputs
<azonenberg_mobil> meaning, if we wanted, we could have up to four separate inputs per channel with different configs and a mux to pick between them
<azonenberg_mobil> not saying we should, but we could
<azonenberg_mobil> as a hypothetical example we could have a 1M ohm bnc and a 50 ohm SMA and completely separate frontends for each
bvernoux has joined #scopehal
CarlosEDP has quit [Quit: Bridge terminating on SIGTERM]
CarlosEDP has joined #scopehal
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
azonenberg_mobil has quit [Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org]
someone--else has joined #scopehal
someone--else has quit [Quit: Connection closed]
_whitelogger has joined #scopehal
someone--else has joined #scopehal
<Degi> Uhh nice
<Degi> And one input with no BW limit for sampling CCDs and similar
someone--else has quit [Quit: Connection closed]
<azonenberg> Yeah. I think on the main board I would break out one or more of those other inputs to a header that we leave unpopulated
<azonenberg> the intent being that we could make a secondary/alternate front end that would mate with that header
<azonenberg> and provide whatever mode you wanted
someone--else has joined #scopehal
<someone--else> do high-end scopes actually have anti-aliasing filters? asking for a friend
<azonenberg> All scopes do, otherwise you get aliasing :p
<azonenberg> although they are often higher order filters with a sharper response than a simple R-C LPF or something
<azonenberg> and there's often some DSP postprocessing to flatten things out and compensate for passband loss of the filter
<someone--else> I agree that all scopes should have these, but not sure about what actually happens in the industry
<someone--else> e.g. do all the scopes with sample rates which vary wrt number of active channels have switchable filters?
<azonenberg> Typically there is a single fixed filter or maybe a few
<azonenberg> Also, keep in mind that in many cases the sample rate doesnt actually vary
<azonenberg> i.e. you're sampling at full rate and decimating
<azonenberg> So if you are "sampling" at 1 Gsps with a 10 Gsps ADC, the scope might be downsampling 10:1 and only storing every tenth sample to memory
<azonenberg> Which allows a DSP FIR filter with arbitrary characteristics to be used for antialiasing
<someone--else> yep, but some scopes mux the adcs so they only achieve max sample rate for 2 channels of 4
<azonenberg> but you still need a hardware AA filter with cutoff of <= 5 GHz
<azonenberg> as you can't DSP aliasing before the ADC
<azonenberg> And yes. In those cases, bandwidth is often better than nyquist in all cases, but you do risk aliasing at the lower rates
<azonenberg> so for example my picoscope is 500 MHz BW but if you use all eight channels plus the digital pods, you're limited to 625 Msps
<azonenberg> and i dont think there is a filter to help with that
<someone--else> so there is aliasing
<azonenberg> If you only use the 8 channels and no digital, you can do 1.25 Gsps which has nyquist of 625 MHz, so no aliasing with the 500 MHz frontend BW
<azonenberg> (although there might still be a little aliasing depending on how sharp the cutoff is)
<someone--else> yep
<azonenberg> i know LeCroy will warn you with certian sample rate combinations that aliasing is possible
<someone--else> so it seems people put filters there but often not bother with switchable filters if max sample rate depends on a number of channels
<azonenberg> Yes. Because most scopes with shared hardware like that are cost optimized
<azonenberg> not tuned for performance
<azonenberg> Switchable filters cost money
<someone--else> makes sense
<someone--else> non-existing filters cost even less though
<azonenberg> Well you're going to get total garbage if you don't have *some* antialiasing filter
<azonenberg> but having one filter with -3 dB cutoff at the scope's BW spec is easy and cheap
<azonenberg> like i said most higher end scopes use high-order filters
<someone--else> I agree, a simple non-switchable filter is cheap enough to have on any scope
<someone--else> wrt garbage - I think that depends on the actual >nyquist frequency content; in many cases it will be fine
<electronic_eel> someone--else: don't underestimate the high freq content of digital signals, they'll easily go beyond your scopes bw
<someone--else> sure, but if the frequency content is mostly in sharp rise/fall times and not the fundamental being >nyquist, then it will maybe lead so some more ringing, but not complete garbage
<azonenberg> Yeah i have a 16 GHz scope and i still see artifacts in my signals sometimes caused by insufficient BW
<azonenberg> there's 16 GHz ripple in some of my fast risetime measurements that as far as i can tell is the result of a sharper edge being band-limited
<azonenberg> When i get budget i will probably want to bump this scope up to the 20 GHz version :p
<someone--else> ringing in an anti-aliased scope might be cause by a non-gaussian/bessel filter
<someone--else> which should be fixable by adding such filter before the scope input
<someone--else> with some bandwidth reduction
<electronic_eel> if the scopes dsp doesn't take proper care of such ringing - would it be possible to post-process the data yourself to remove it?
<electronic_eel> i guess you'd have to properly characterize the scopes input first though
<azonenberg> So, this actually gets into what i was talking about wrt tdr de-embedding
<azonenberg> i would like to be able to record a measurement of a step then do some DSP magic to de-embed that response from a tdr trace
<azonenberg> You won't be able to tell how much is from the scope and how much is from the pulse generator
<azonenberg> but i think it should be possible to compensate for the product of those responses
<someone--else> it might be possible to de-embed the DUT compared to thru line?
<someone--else> but what's you proposing is also possible
<someone--else> I think some Keysight hardware has a feature which allows to dial in the processed TDR step risetime; they might be doing something similar by transforming sampled waveform to an ideal step with a specified risetime
<someone--else> and then using the reverse filter on the user TDR trace
someone--else has quit [Quit: Connection closed]
<azonenberg> That's the idea
someone--else has joined #scopehal
<someone--else> both methods might be equivalent in a sense
<someone--else> i.e. giving the same final resolution on same hardware
<azonenberg> someone--else: that's what my WIP implementation tries to do
<azonenberg> I calculate an ideal step (single sample rise time, hard 0 to 1) at the same time as the real measured pulse
<azonenberg> fft both
<azonenberg> figure out the gain and phase angle needed for each bin
<azonenberg> then output that to a .s2p you can de-embed
<azonenberg> i think it's on the right track but it's very noisy
<azonenberg> not currently usable
<someone--else> I think I did something similar in prototype software for the sampling scope, except the step was gaussian
<someone--else> remember the problem with noise was there too
<someone--else> needs filtering to a reasonable bandwidth
<someone--else> like -20db scope bandwidth or something
<azonenberg> even within the passband its noisy
<azonenberg> probably the fft amplifying quantization noise of the scope or something
<azonenberg> I think i need to do a frequency domain smoothing step
<azonenberg> basically assume the gain and phase response doesnt vary oo much from one bin to the next
<azonenberg> and apply some rounding to the s-parameters
<someone--else> could be if the amount of gain in the passband is too much
<azonenberg> no you misundsedstand
<azonenberg> its not the output time domain waveform thats noisy
<azonenberg> the *frequency domain* data is noisy
<someone--else> ah
<azonenberg> its not a smooth curve
<Degi> Does the noise get much more above the max frequency of the scope?
<someone--else> is the ideal step frequency domain data smooth?
<Degi> In how far smooth?
<someone--else> in the same region where the resulting data is noisy
<someone--else> since I assume the recorded waveform should be reasonably smooth
<someone--else> in frequency domain
<azonenberg> I'll play with it more later today or tomorrow or something
<azonenberg> and share some of my data once i'm a bit more confident in it
<azonenberg> i also havent visualized a lot of the data yet
<azonenberg> as well as i'd like
bvernoux has quit [Quit: Leaving]