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
<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