Francesco Poderico said:
Actually in theory I could use the DLL inside the FPGA and changing the
clock phase with a resolution of 25 ps... so in theory I have a 1 GSPS
FPGA for repetitive signals!
Nah, 25ps resolution means you can take acquisitions shifted in time every
25ps -- 40GSPS equivalent! But, do beware of the manufacture and
temperature variation of the delay. FPGAs are made for worst-case timing
constraints, and anything that's adjustable (like a DLL) is put inside a
loop (hence, DL*L*).
Do you think it would make more attractive to buy?
Heck, make it better than a Rigol, from cheaper parts. And open source it
(if it's that kind of project). Create shock waves in the marketplace!
;-)
Actually the maximum bandwidth is 70 MHz, I'm low filtering for
aliasing.
My TDS460 says "50GS/s ET" (Equivalent Time) on 1ns/div. Looks like it's
actually filling the whole screen with that resolution, not just
interpolating between samples.
The 100MHz, ~10MS/s HP54600B goes down to 1 or 2ns/div or something like
that, but it uses sinc interpolation on such fine scales. I don't know
what a Rigol does for high sampling rates.
If you skip antialiasing filters, you get sharper displays and equivalent
time sampling. If you filter, you're basically saying: "Yep, I purchased
this 200MS/s ADC, and the FPGA to run it, and I'm taking both of them over
to the grinder and shaving off... ohh about 80% of the silicon, because...
I like the smell?"
Filtering basically negates the trigger generator, too. You could sample
continuously and do the trigger digitally instead. Which...
....I think for any particular period between trigger crossings, you'd want
to use some sort of interpolation to adjust the timing -- sample N is a
bit below the threshold, and sample N+1 crossed the threshold by so-and-so
and caused a trigger, so we know the dV/dt and can estimate where it *did*
actually cross. So we can stack this sample period on top of the other,
which crossed at whatever rate, by aligning it. Shift everything sideways
by the calculated time difference, using a suitable interpolation (a
simple quadratic spline would be reasonable, but a sinc interpolation
might be more physically significant), then stack it up for display.
The "stacking" itself could be an array of buffers (so you have a memory
of many traces, and can perform statistics on them to generate the
display -- decimate (view only one), average (which would now be a FIR
"sliding average", which AFAIK, no scope manufacturer ever does for
averaging mode!), peak detect, median, RMS + std dev., etc. This display
process could, of course, be done for either acquisition method
(continuous or triggered).
But again, such hackery, though interesting, doesn't get your bandwidth
back, it's just software diddling for not being clever enough to get the
bandwidth and trigger right in the first place.
Tim