Products > Test Equipment
A High-Performance Open Source Oscilloscope: development log & future ideas
<< < (12/71) > >>
rhb:

--- Quote from: nctnico on November 17, 2020, 07:11:33 pm ---
- anti-aliasing filter. Looking at it I'm not sure whether a 7th order filter is a good idea due to phase shifts.
- single ended to differential amplifier and analog offset
- gain control block and ADC.


--- End quote ---

What's required  to preserve waveform fidelity is the flattest phase delay, a Bessel-Thompson filter.  I've spent a lot of time studying the subject.  It's not well treated in the literature, but well documented in scopes.  Of course, all high order analog filters are problematic to produce.  Though with an FPGA one need only get close and the FPGA can trim the last bit.

As the order goes up the Bessel-Thompson passband approaches the Gaussian passband.  So the impulse response of a 10th order Bessel-Thompson is approximately a time delayed Gaussian spike.

Tom is the reason I dropped work on hacking the Instek GDS-2000E after I blew the scope. It no longer made sense to replace it.

Have Fun!
Reg
Someone:

--- Quote from: tom66 on November 17, 2020, 12:12:48 pm ---
--- Quote from: Someone on November 16, 2020, 10:16:31 pm ---
--- Quote from: tom66 on November 16, 2020, 08:13:55 pm ---Shifting the dots is computationally simple even with sinx/x (which is not yet implemented).  It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory.  In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset.
--- End quote ---
Noting that triggers in modern scopes are aligned more finely than the sample rate (interpolation), with the reconstruction and interpolation methods also dependent on the front end characteristics. Expect the rendering speeds to collapse in a software/GPU approach once you put in that phase alignment and sinc interpolation.
--- End quote ---
As I understand it, and please DSP gurus do correct me if I am wrong, if the front-end has a fixed response to an impulse (which it should do if designed correctly), and you get a trigger at value X but intend the trigger to be at value Y, then you can calculate the real time offset based on the difference between these samples which can be looked up in a trivial 8-bit LUT (for an 8-bit ADC).   It's reasonably likely the LUT would be device-dependent for the best accuracy (as filters would vary slightly in bandwidth) but this could be part of the calibration process and the data burned into the 1-Wire EEPROM or MCU.

In any case there is a nice trade-off that happens as the timebase drops: you are processing less and less samples.  So, while you might have to do sinx/x interpolation on that data and more complex reconstructions on trigger points to reduce jitter, a sinx/x interpolator will have most of its input data zeroed when doing 8x extrapolation, so the read memory bandwidth falls.   I've still yet to decide whether the sinx/x is best done on the FPGA side or on the RasPi - if it's done on the FPGA then you're piping extra samples over the CSI bus which is bandwidth constrained, although not particularly much at the faster timebases, so, it may not be an issue.  The FPGA has a really nice DSP fabric we might use for this purpose.

I don't think it will be computationally practical to do filtering or phase correction in the digital side on the actual samples.  While there are DSP blocks in the Zynq they are limited to an Fmax of around 300MHz which would require a considerably complex multiplexing system to run a filter at the full 1GSa/s. And that would only give you ~60 taps which isn't hugely useful except for a very gentle rolloff.
--- End quote ---
Not sure the trigger interpolation calculation is a single 8bit lookup when the sample point before and after the trigger could each be any value (restricted by the bandwidth of the front end, so perhaps 1/5 of the full range). Sounds like an area you need to look at much more deeply, as the entire capture needs to be phase shifted somewhere or the trigger will be jittering 1 sample forward/backward when the trigger point lands close to the trigger threshold. Exactly where and how to apply the phase shift is dependent on the scopes architecture. This may not be a significant problem if the acquisition sample rate is always >>> the bandwidth.

Similarly if you think a 60 tap filter isn't very useful recall that Lecroy ERES uses 25 taps to obtain its 2 bits of enhancement. P.S. don't restrict the thinking to DSP blocks as 18x18 multipliers, or that they are the only way to implement FIR filters. Similarly while running decimation/filtering at the full ADC rate before storing to acquisition memory makes for a nice architecture concept suited to realtime/fast update rates, its not the only way and keeping all "raw" ADC samples in acquisition memory (Lecroy style) to be plotted later has its own set of benefits and more closely matches your current memory architecture (from what you explained).

If memory is your cheap resource then some of the conventional assumptions are thrown out.
nfmax:

--- Quote from: rhb on November 17, 2020, 07:55:06 pm ---
--- Quote from: nctnico on November 17, 2020, 07:11:33 pm ---
- anti-aliasing filter. Looking at it I'm not sure whether a 7th order filter is a good idea due to phase shifts.
- single ended to differential amplifier and analog offset
- gain control block and ADC.


--- End quote ---

What's required  to preserve waveform fidelity is the flattest phase delay, a Bessel-Thompson filter.  I've spent a lot of time studying the subject.  It's not well treated in the literature, but well documented in scopes.  Of course, all high order analog filters are problematic to produce.  Though with an FPGA one need only get close and the FPGA can trim the last bit.

As the order goes up the Bessel-Thompson passband approaches the Gaussian passband.  So the impulse response of a 10th order Bessel-Thompson is approximately a time delayed Gaussian spike.

Tom is the reason I dropped work on hacking the Instek GDS-2000E after I blew the scope. It no longer made sense to replace it.

Have Fun!
Reg

--- End quote ---

There are a class of filters with a linear-phase (Bessel-like) passband and an equiripple stopband, originally described by Feistel & Unbehauen [1], for which Williams [2] gives some limited design tables: I have used these with success as anti-aliasing filters where waveform fidelity is important. There is a conference paper by Huard et al. [3] - which I don't have a copy of, unfortunately - that describes more recent progress in similar filter designs. Huard worked at Tektronix, which may be a clue about the applications being addressed!

[1] Feistel, Karl Heinz, and Rolf Unbehauen. Tiefpässe Mit Tschebyscheff-Charakter Der Betriebsdämpfung Im Sperrbereich Und Maximal Geebneter Laufzeit. Frequenz 19, no. 8 (January 1965). https://doi.org/10.1515/FREQ.1965.19.8.265.

[2] Williams, Arthur Bernard, and Fred J. Taylor. Electronic Filter Design Handbook. 3rd ed. New York: McGraw-Hill, 1995. ISBN 978-0-07-070441-1

[3] Huard, D.R., J. Andersen, and R.G. Hove. Linear Phase Analog Filter Design with Arbitrary Stopband Zeros. In [Proceedings] 1992 IEEE International Symposium on Circuits and Systems, 2:839–42. San Diego, CA, USA: IEEE, 1992. https://doi.org/10.1109/ISCAS.1992.230091.
nuno:
First of all, as many others have said, very good job! Especially for a one man's band.

I totally agree with ntcnico's view on having more stuff be done on higher level processing, because the lower you go the less and less people will contribute to it. Ideally I would like to see minimal hardware and everything be done in software (I know it's not possible). It's also one way it can distinguish from the current low level entry scopes on the market.

It's totally understandable the use of the compute module, but newer versions seem to be able to break the interfaces.... so why not use the main RPI boards? It would be much more future proof as well as being more upgrade-friendly as new and more powerful RPIs come out. Just food for thought.

I always prefer to have a standalone instrument, because my computer (even phone) is always too busy,like running my development environment, browsing the web, email, etc... as it is it already has too little screen space available.

And although I'm not against touch screens and agree they may have an advantage say, handling (a lot of) menus, I also hate grease on my screens, as they interfere with readability. Touch is also bad at precision and there's no instant haptic feedback. As long as I can easily add some keys to the instrument (even if a custom USB keyboard), I'm OK with it.

I can see people designing their own cases and 3D printing them.
Spirit532:
Have you considered implementing Andrew Zonenberg's glscopeclient for your UI?
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod