A High-Performance Open Source Oscilloscope: development log & future ideas

[nctnico]

I have been thinking about this a bit. I think a good approach would be to have several filter banks and use a mux to switch between them to select a different roll-off for a different bit-width and maximum samplerate. A higher order filter using passive components is not very difficult and not very expensive to implement.

It is quite expensive to do for 100MHz+ and across 4 channels, though.  Remember, these things also need to be tested during production with a sweep generator, and possibly need manual adjustment.  There are a few manual adjustment varicap points on even cheap oscilloscopes, which appears to be for matching input capacitance.  I'd really like to avoid doing that with the filters, and I don't think there's the grunt to do real time DSP on the ADC samples and correct AFE response there (unless it was very limited in response, and ~all the DSP blocks were used.)

I have tested my Rigol DS1000Z, and it aliases in 4 channel mode.  I think it's just something that's rather difficult to avoid, and the operator just needs to be careful not to exceed the parameters of their instrument.  If the measurement is really crucial, then an external analog filter could be used.

I think the production can be greatly automated (and the user is also able to do a full recalibration from/by the instrument itself). I have found and ordered some neat parts for self calibration of the attenuators but I need to try them first to see if they deliver before wetting too many appetites.

The filters don't need adjustment; 5% L / C parts will do just fine and 2% parts aren't extremely expensive. Typically you'll see some variation in bandwidth from oscilloscopes so no worries there.

[tom66]

I'm more concerned about inter-channel variation.  If you apply a signal near rolloff point on all 4 channels of an oscilloscope, how much would you expect amplitude to vary?  What about the effects on rise time?  I would expect matching to be better than +/-1dB, and rise times to be within +/-10% of each other,  but I admit this is not something I have tested. 

It would be useful to do some Monte-Carlo simulations on any filters you consider to see how influential certain parts would be. 

[nctnico]

I'm more concerned about inter-channel variation.  If you apply a signal near rolloff point on all 4 channels of an oscilloscope, how much would you expect amplitude to vary?  What about the effects on rise time?  I would expect matching to be better than +/-1dB, and rise times to be within +/-10% of each other,  but I admit this is not something I have tested. 

It would be useful to do some Monte-Carlo simulations on any filters you consider to see how influential certain parts would be.

Certainly 
But since the filter doesn't need different component placement, the first step I want to take is to have a board design to do some testing on. Due to the parasitic capacitances the board itself is as much a component as the rest. I expect it will take a few board spins before getting the board right. If each step also includes converging towards a final design then this approach will catch two flies with one stone.

[gf]

I'm more concerned about inter-channel variation.  If you apply a signal near rolloff point on all 4 channels of an oscilloscope, how much would you expect amplitude to vary?  What about the effects on rise time?  I would expect matching to be better than +/-1dB, and rise times to be within +/-10% of each other,  but I admit this is not something I have tested. 

It would be useful to do some Monte-Carlo simulations on any filters you consider to see how influential certain parts would be.

Were it prohibitively costly to sweep each AFE during production with a VNA, and to store the measured response as calibration data, in oder that corrections can calculated and applied in the digital domain?

[Marco]

If you do Chebyshev for the capture ... how well can you correct the group delay with a high order digital filter?

[rhb]

@nctnico

Here's the same information from another author who also provides Matlab scripts, though I've not downloaded them yet.


Elsie calculates the same result:





In any case you can do a first order trapezoid approximation as the convolution of a pair of boxcar(f) functions. One boxcar whose width depends upon the length of the ramp and another that corresponds to length of the flat section of the trapezoid.  That's a bar napkin math problem and the result is sufficiently accurate to make the problem of the aliased sidelobes obvious.

I showed the minimum phase impulse response for a 50% and 80% of Nyquist corners using a trapezoidal approximation a long time ago.  That extra 75 MHz of BW going from 50% to 80% comes at the expense of a lot of ringing in the time domain.

A high order Bessel-Thomson filter has an impulse response which asymptotically approaches  a delayed Gaussian spike.  That's the best possible band limited representation of a Dirac function.  That is the best we can do.

I have a 100 ps pulse generator from Leo Bodnar.  What do you think that is supposed to look like on a DSO sampling at 1 ns?  I want a symmetric Gaussian spike.  That corresponds to the least waveform error for the BW available.  If you want to argue it should be different, I don't care to discuss it.  Do whatever you like.

Edit:  The server borked the figure file naming.

[gf]

If you do Chebyshev for the capture ... how well can you correct the group delay with a high order digital filter?

Sure, not everything can be compensated. E.g. a multiplication with 0 cannot be undone.
But dou you think that Chebyshev is a realistic assumption for an AFE's frequency response?

[Marco]

But dou you think that Chebyshev is a realistic assumption for an AFE's frequency response?

It can be implemented at RF frequencies, I don't think it rings too badly on a step response that you need to sacrifice too much dynamic range.

So if the quantization and other noise doesn't make high order digital group delay compensation unstable, it's an option. That's the big if.

[tom66]

The biggest issue I see with digital filters is do we do them in real time or on post-captured data? 

The DSP48E1 blocks in the Artix-7 fabric are useful up to around 300MHz in the standard speed grade. Assume maybe 250MHz to be safe.  Each block does a MAC operation with a 48-bit result, so with a symmetric filter that gives us one tap per DSP block.  We'd only need 12 or 14-bit result data,  IIRC the blocks have configurable rounding logic so that will be fine, we can probably truncate results with little harm.

To process 1GSa/s raw data you would need to run four parallel streams of DSP blocks in ~40 tap filter chains, which would create a lot of logic complexity and I don't exactly know how that would work when you switch to multichannel modes, there's a data dependency headache to be resolved.

Whereas if it was done post-processed, assuming 1232 points (100ns/div setting) at 50k waves/sec, that's only 61.6 MSa/s to process.  Plenty comfortable to do this after capture by reading back from the RAM and writing into another buffer before rendering (once the 32-bit interface is in place so we have sufficient bandwidth to do this;  or using an FPGA-side MIG with a small external RAM, the exact architecture needs to be worked out.)

In raw bandwidth terms there's enough DSP to do ~200 tap filters in a 7020 at around 250kwaves/sec, or e.g. 400 taps at 125kwaves/sec or even 2000 taps at 25kwaves/sec...,  although memory bandwidth might start being an issue if samples are stored in an unfavourable order so that needs to be considered.  How much correction could you do with a 200 tap filter on post-captured data?  How much benefit would there be in going up to something like a 7030 with 400 DSP slices and a faster Kintex fabric;  or an UltraScale?

[gf]

If the ADC always runs at full speed, and the currently selected sampling rate is lower, then at least the decimation filtering needs to be done in real time, before storing the samples.

[tom66]

That's true, but what does a decimation filter need to look like?  Would an IIR type response be acceptable (sum pairs of samples and shift) or does it need to be a true FIR-type filter?  The latter is considerably more expensive to implement, but I fear it's the only way to achieve the required decimation response.

[Marco]

In raw bandwidth terms there's enough DSP to do ~200 tap filters

In theory you could do FFT overlap add, doesn't have to be straight FIR.

[gf]

but what does a decimation filter need to look like?

A common approach seems to be a CIC decimator, which is computationally cheap (requires not even multipliers), and to adjust its (non-flat) passpand afterwards to the desired shape with a compensation filter (running at the lower rate). The latter could be basically done in the post-processing too, if DSP resources don't suffice to do it real-time.

One point with running a FIR filter in the post-processing is that you lose N-1 samples of each captured buffer (where N is the number of taps), since the captured buffers do no longer form a gapless stream of samples.

In theory you could do FFT overlap add, doesn't have to be straight FIR.

Starting at how many taps is it computationally cheaper than brute-force FIR?

[nctnico]

@nctnico

Here's the same information from another author who also provides Matlab scripts, though I've not downloaded them yet.

I just had the chance to review the results. It turns out I made a mistake indeed. For 1Gs/s and a 200MHz bandwidth a Bessel filter (together with several other 1st order roll-offs within the AFE) might do it. For 500Ms/s and a 200MHz bandwidth a much steeper filter it needed.

[rhb]

The ADC should always run full speed. The case of an ADC with different sample rates at different bit depths requires a filter for each speed.  This results in the simplest and easiest architecture to implement.  Everything that can be done in SW is.

A moving average (boxcar in time) filter is two adds and N+1 storage locations.  An arbitrary filter profile can be constructed by placing multiple such filters with different values of N in sequence.  In the frequency domain each filter has a sinc(f) profile.  By varying the lengths of the filters you can place zeros in one profile on a peak in another profile and systematically suppress the stop band.  And in fact sinc(f)**N for N>2 has quite  good stop band performance without doing that.

If you  are downsampling, you can loop on a subset of the filter poles using a single DSP block.  As a consequence, the resource requirements are quite low.

While  the filtering operation is performed, it's very simple to put in the phase shift term without requiring significant  additional operations. 

Here is a canonical set of references:

Best DSP intro I have seen and the one I grab if I want to check a formula.

An Introduction to Digital Signal Processing
John H. Karl
Academic Press 1989

This was my grad school  Linear Systems text.  There is a pictorial dictionary of Fourier transforms in the back which once mastered will allow you to do meticulously correct  analysis of complex DSP problems on a cocktail napkin.  The math text I use most.

The Fourier Transform and Its Applications
Ronald N. Bracewell
McGraw-Hill 1978 2nd ed (there's also a 3rd)

The best summary of Nyquist-Shannon-Weiner ever.  I've relied on it since the 2nd edition.  The successive editions added worked examples of ever more arcane problems such as sign bit. If you don't understand this you don't understand DSP even if that's all you do all day.

Random Data
Bendat & Piersol
Wiley 4th ed

Practical issues such as word length  and digital filters from an EE viewpoint.

Theory and Application of Digital Signal Processing
Rabiner & Gold
Prentice-Hall 1975

The source of the 2nd set of Bessel function plots and arguably the best written of all my analog filter design texts.

Design and Analysis of Analog Filters
Larry D. Paarmann
Springer 2001

[edit:  Best intro to the state of the art

A Wavelet Tour of Signal Processing
Mallat
Academic Press 3rd edbook

edit]



@nctnico  200 MHz corner and 500 MHz Nyquist will give very fine results.  A 5th order filter will be ~ -32 dB at Nyquist and if one picks up another -10 dB elsewhere in the AFE the 8 bit case is done.  Though, personally I'd go to a 7th order just to be sure I had the roll off.  Steep slopes cause heavy ringing, so they are not a good idea.

[nctnico]

If the ADC always runs at full speed, and the currently selected sampling rate is lower, then at least the decimation filtering needs to be done in real time, before storing the samples.

No DSO uses a decimation filter in case of a lower sampling rate becaue this conflicts with the specified bandwidth. The only decimation 'allowable' in realtime is peak-detect. Unless ofcourse there is a specific signal filtering feature the user enables.

For post-processing a quick peak detect -ish decimation is used to compress the data quickly into a display record. This can lead to odd behaviour for specific signals like sweeps though which isn't easy to solve. Compressing the data realtime is a more time sensitive operation compared to sampling because any delay will result in sluggish operation.

This is for the GW Instek GDS-2204E but similar intermodulation effects can be made to appear on other (much more expensive) DSOs as well:

@nctnico  200 MHz corner and 500 MHz Nyquist will give very fine results.  A 5th order filter will be ~ -32 dB at Nyquist and if one picks up another -10 dB elsewhere in the AFE the 8 bit case is done.  Though, personally I'd go to a 7th order just to be sure I had the roll off.  Steep slopes cause heavy ringing, so they are not a good idea.

I have to see about the exact impedances to be used in the circuit but so far anything over 5th order is resulting in unpractical part values. And as tom66 noted a Monte-Carlo simulation needs to be done to verify component variation sensitivity. Other roll-offs in the AFE will likely be 1st order anyway.

[gf]

The only decimation 'allowable' in realtime is peak-detect

Don't forget ERES. This is basically a decimation filter - whatever filter response they may have realized.
[ I guess in most cases just a boxcar averaging of the samples in the decimation interval, i.e. the lower fs/2 still falling on the main lobe of the sinc frequency reponse, not at a zero. ]

[tom66]

The ADC must run at full speed to function as a digital trigger source.

But, in some cases, less data must be stored,  although the trigger is always going to work on realtime data.  The CIC filter looks like an interesting, inexpensive way to downsample.  It's certainly better than alternative of just throwing away (N-1)/N samples.

My experience is the Rigol DS1000Z does not downsample correctly - the scope will alias very easily - but the Agilent DSOX2000A does not.

[nctnico]

The ADC must run at full speed to function as a digital trigger source.

But, in some cases, less data must be stored,  although the trigger is always going to work on realtime data.  The CIC filter looks like an interesting, inexpensive way to downsample.  It's certainly better than alternative of just throwing away (N-1)/N samples.

My experience is the Rigol DS1000Z does not downsample correctly - the scope will alias very easily - but the Agilent DSOX2000A does not.

Do not filter! Throwing away samples is the only correct way (when in sample mode); otherwise you'll be distorting the signal due to phase delays introduced by filtering. The DSOX2000A likely does some kind of peak-detect because the display part works with decimated data while other DSOs do not.

[rf-loop]

The ADC must run at full speed to function as a digital trigger source.

But, in some cases, less data must be stored,  although the trigger is always going to work on realtime data.  The CIC filter looks like an interesting, inexpensive way to downsample.  It's certainly better than alternative of just throwing away (N-1)/N samples.

My experience is the Rigol DS1000Z does not downsample correctly - the scope will alias very easily - but the Agilent DSOX2000A does not.

Do not filter! Throwing away samples is the only correct way (when in sample mode); otherwise you'll be distorting the signal due to phase delays introduced by filtering.

 

[2N3055]

The ADC must run at full speed to function as a digital trigger source.

But, in some cases, less data must be stored,  although the trigger is always going to work on realtime data.  The CIC filter looks like an interesting, inexpensive way to downsample.  It's certainly better than alternative of just throwing away (N-1)/N samples.

My experience is the Rigol DS1000Z does not downsample correctly - the scope will alias very easily - but the Agilent DSOX2000A does not.

Do not filter! Throwing away samples is the only correct way (when in sample mode); otherwise you'll be distorting the signal due to phase delays introduced by filtering. The DSOX2000A likely does some kind of peak-detect because the display part works with decimated data while other DSOs do not.

Agree!

DSOx/MSOX3000T is also very resilient to aliasing, screen representation keeps outside signal envelope far into sampling rates that should alias badly.  I also think they use peak detect internally for display all time, and decimate for waveform buffer in accordance with sample rate.
I tried enabling /disabling peak detect and saw no difference, so I presume that's it.

[Marco]

otherwise you'll be distorting the signal due to phase delays introduced by filtering.

You get exactly the delay you want with digital filtering. if you really want a 100th order Gaussian response filter you can get it in digital, analogue not so much. The subsampled signal will never be the original signal, all you get to chose is what type of distortion you want ... no distortion is not an option.

Outside of subsampling, I'm told Tek has response correction on by default. The analogue filter introduces group delay based distortion, digital can correct it.

[tom66]

Well, throwing away samples is certainly easier than filtering them.  But, I don't understand why you'd go to so much trouble to build a good antialias filter for the AFE side if you just risk aliasing when your sample rate drops off?  Switching to an automatic 'peak detect' mode is an option,  although it would double the memory required as you need to store a min and max for each sample.

I see ERES or equivalent as being comparably easy to achieve.  Bin N samples (where N is a power of two) into an accumulator, take the top N bits (probably 16 bits so it functions with 14 bit mode up to 4x ERES) and then save into RAM. 

I need to rewrite the acquisition Verilog so it can handle all 4 channel configurations (well, 3 modes as only 1/2/4 are truly supported and 3 channel mode is treated as a subset of 4ch mode.)  Then it needs to be able to discard samples on a binary division rate (all but 2nd, all but 4th, all but 8th, etc.)  and re-order these into RAM correctly.  The 'real trick' here is then getting that data lined up with the digital trigger.  And then ideally include the capability for MSO support.  Needs a good amount of thought to make that work.

[nctnico]

Well, throwing away samples is certainly easier than filtering them.  But, I don't understand why you'd go to so much trouble to build a good antialias filter for the AFE side if you just risk aliasing when your sample rate drops off?

Aliasing is not a bad thing perse but the user needs to be aware of it. Without filtering you'll still be able to measure the RMS and peak-peak values of a signal which has a fundemental at a higher frequency then Nyquist for the lowered samplerate. IOW: you will still be able to make out the amplitude. In case of narrow pulses you'll miss some pulses. With automatic filtering you will suddenly see no signal or a completely different signal on your screen after changing the time/div which will confuse the user.

[tom66]

Makes sense - but, in that case, why not omit the input filter altogether and allow the user to cautiously use their instrument up to Nyquist?  All filters risk eliminating signals that you intend to look at - part of operating a scope is understanding approximately what you expect to appear on the screen before you even probe it.