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

[nctnico]

I never said high trigger rates (waveforms/s) are never necessary. Sometimes they are and in that case I simply select a shorter memory length to speed up the acquisition process. However aiming for insanely high waveforms/s quickly lands you in an area where there are diminishing returns. The oscilloscope manufacturers tend to claim a high waveform update rate makes it more likely to catch glitches but in the end they never get to 100% due to blind time (which can be avoided BTW at the cost of ending up with a weirdly drawn signal). However measuring is about 100% certainty so if you want to capture a glitch with 100% percent certainty during a given interval the only way out is deep memory (+analysis) or triggering (combined with infinite persistence and/or saving a screendump).

[tom66]

There's no reason you can't take the Rigol approach (likely the same on other instruments as well) and give the user a choice of 'Auto' vs a memory depth selection.

In 'Auto' the scope always optimises for waveform rate which IMO is the good, default optimisation (I think this is what most people expect unless they are using the scope for a special application.) 

If you select say 120k points but are on a short timebase, then the update rate drops appropriately and the available capture exceeds that of the visible window.  In fact, all the timebase control does in this instance, is inform the oscilloscope what 'auto' mode it should use and how many points it should apply.  In essence, there is no actual difference in a capture at 120k points at say 10us/div and one at 50ns/div,  they both capture the same data.   It is just a matter of how it is displayed to the user and the timebase control is more of a horizontal zoom control.

In all modes, if there is free waveform RAM, use that RAM to store a history buffer.  120k points gets 2000 waveforms for instance. 

[Zucca]

Trust me, nobody cares about waveforms per second!

+1
If I want high waveforms per second I do not search a device in the Open Source jungle.

[2N3055]

I agree that it is not needed to have 1 MWfrms/sec, but in normal interactive mode it should have enough for fluid display. From what was said previously that is already OK.. 20-25 kWfms per second is more than enough for interactive work..

[tom66]

Do note the present performance is dot mode only.  Rigol achieve 50 kwfm/s on dot mode on the DS1000Z series,  the headline 25 kwfm/s figure is given in vector mode (a refreshing change that they don't quote the absolute fastest, unrealistic figure!)

I expect vector mode will be a bit slower, it depends on how many vectors need to be drawn.  I've an optimal algorithm in mind but it's limited to 2 pixels/cycle due to the ARM ALU size.  Maybe with NEON I can do more (64-bit add with 4 or 8 terms if using 16 or 8-bit saturating arithmetic) but it would require carefully hand coded assembly.  That's if I decide to further optimise ArmWave which as I've indicated here I'm not certain is the best route yet. 

[Marco]

if you want to capture a glitch with 100% percent certainty during a given interval the only way out is deep memory (+analysis) or triggering (combined with infinite persistence and/or saving a screendump).

It's much easier to compare a capture against bounds relative to a reference signal on the fly than doing digital persistence on the fly. Linear memory access vs. defacto random access.

[tv84]

It's much easier to compare a capture against bounds relative to a reference signal on the fly than doing digital persistence on the fly.

Can you elaborate on what you mean by "digital persistence on the fly"?

[tom66]

I feel persistence will be quite easy to implement.  In infinite persistence, pixels are only updated if the value is greater than the previous - this can be adjusted at the final framebuffer stage so there are relatively few pixel values to compare.  For variable persistence a moving average filter could be used although that would have a non-linear decay function (not sure if this is a problem.) Alternatively N buffers (~1024x256x16) would need to be stored and summed together although this would get computationally very expensive for longer persistence periods.

It seems that Tek use an interesting approach for variable persistence on their newer scopes. They apply a random noise function to the previous buffer, which models the approximate desired persistence.  The disadvantage of this method is that the trace constantly looks noisy.

[Marco]

Can you elaborate on what you mean by "digital persistence on the fly"?

Trying to updating the bucket counts for persistence at full sample rate is pretty much impossible, determining if it's within a given bound of a reference signal fairly trivial.

[tom66]

Trying to updating the bucket counts for persistence at full sample rate is pretty much impossible, determining if it's within a given bound of a reference signal fairly trivial.

What do you mean by this?
Testing every sample against a reference signal is still fairly expensive.

Mask testing after the waveform is captured is relatively easy and could be done in the rendering engine.  The mask could be defined by some % of the signal e.g. 99% of all samples which could be gathered after say ~30 seconds of persistence data is collected.

[Marco]

Testing every sample against a reference signal is still fairly expensive.

Instead of linearly storing a byte per sample, you need to also retrieve two for the upper and lower bounds and do two comparisons. it's fairly expensive, but not unreasonably expensive like it gets for digital phosphor.

[tom66]

What would the upper and lower bounds here be?  Surely the lower bound is always going to be zero?  You could store the peak min/max value for each horizontal pixel in the post-processing stage, but I'm not sure what value this would have?

[Marco]

They are part of the mask for a reference signal for pass/fail testing. The mask will be computed based on an area around the current sample, so you can't really determine that on the fly just from the reference signal, so you need the two values per sample to compare against.

[rhb]

I have proposed computing statistics so as to be able to trigger on "trace outside x.x sigma bound" and even histograms. This is not a "start of sweep" trigger, but a data event trigger.  I've given careful thought to the resource requirements and it seems quite tractable to me for an Ultrascale implementation.

It's important to distinguish between things which must be done in real time and which simply need to appear to be done in real time.  Most of what a DSO does does not need to be done in hard real time.  A screen refresh delay is of no concern.  Trigger point alignment, AFE correction, anti-alias filtering, downsampling and a few other things must be done in hard real time, but once the data are in the format needed for the selected data view, the time constraints become quite relaxed.

I have the view that a DSO should do everything it is possible to do with the resources available.

My primary concern now is the AFE input filter.  It should be a high order Bessel-Thomson filter to provide accurate waveform shape.  I've got every reference I can find, but unfortunately, the maximally flat phase gets skimpy treatment and I've still not figured out how to analyze and design one from first principles.  I can do a design by hand or with software, but I can't write the derivation on a whiteboard.  More work required.
I'd very much like to see threads discussing how to time synchronize waveforms, implement advanced triggers, do signal processing operations e.g. FFT, etc.

I keep reading a lot of "you can't do this", "you have to do that", but precious little, "this is how you implement that". It would be nice to have more of the latter and less of the former.

Have Fun!
Reg

[tom66]

Indeed.  That was the key realisation for this project, that most of the work can be done 'after the fact',  once  you have captured the data.  Provided you have a sufficiently large buffer and data rate between your capture engine and display engine you can do quite a lot with non-realtime processors.

[nctnico]

I'm working on an AFE filter. Right now I've arrived at a 5th order Bessel with -3dB at 200MHz. Assuming a samplerate of 500Ms/s it could be a bit steeper (higher order) but then the parts get to unrealistic values. But there will be a 1st order roll-off as well so the -3dB point might need some further tweaking. I think other oscilloscopes use steeper filters at the cost of introducing more phase shift.

I've also recalculated the attenuator part of the schematic I posted earlier. It seems quite usefull and ticks all the boxes (including having a constant capacitance towards the probe); better than I remember.

[rhb]

I'm working on an AFE filter. Right now I've arrived at a 5th order Bessel with -3dB at 200MHz. Assuming a samplerate of 500Ms/s it could be a bit steeper (higher order) but then the parts get to unrealistic values. But there will be a 1st order roll-off as well so the -3dB point might need some further tweaking. I think other oscilloscopes use steeper filters at the cost of introducing more phase shift.

I've also recalculated the attenuator part of the schematic I posted earlier. It seems quite usefull and ticks all the boxes (including having a constant capacitance towards the probe); better than I remember.

The -3 dB point needs to be around 125 MHz to produce a good step response.  At 80% of Nyquist the edge rings badly.  Also there is no way for a 5th order Bessel to prevent significant aliasing.  With a 50% of Nyquist corner, a 5th order filter will only be about -30 dB at Nyquist whereas you need -42 dB for an 8 bit ADC.

An 80% corner,  5th order filter will be about -7.5 dB at Nyquist with the consequence that FFT displays will be hopelessly borked in certain cases.

Reg

[nctnico]

First see how it behaves and go from there. As already stated: the Bessel filter won't be the only part limiting the frequency response. Analog filters also wrap around in the digital domain so you don't need to get to -48dB at Nyquist.

[rhb]

[snip]
 Analog filters also wrap around in the digital domain so you don't need to get to -48dB at Nyquist.

WTF?  This is so basic I'm speechless!

Edit: To make clear, an 8 bit ADC can digitize a <7 bit signal range.  Hence the -42 dB stated previously.  This is 80 year old mathematics.  If you want to argue with that, I'll just wander off.

[nctnico]

[snip]
 Analog filters also wrap around in the digital domain so you don't need to get to -48dB at Nyquist.

WTF?  This is so basic I'm speechless!

Just think about it and look at it from a practical point of view. Frequency continues to roll off, signals consist of harmonics and at 200MHz you are already over the limit of what can be measured with a standard hi-impedance probe.  The probe itself will already cause a significant high frequency attenuation.

There is a ton of information available on this forum about anti-aliasing filters and DSOs. But since this thread is about an open source design you are free to fit whatever filter you like. I will go for what is the standard approach (which is to have a bandwidth of fs/2.5) for now.

In a nutshell:
From an error perspective: 1% is more than 2 bits (2 bits = 12dB). So if the attenuation is 3dB at 0.4fs, 48 - 12 = 36dB at Nyquist (0.5 fs) and 48dB at 0.6 fs then the amplitude error is less than 1% due to aliasing. Another issue to factor in is that in order to show the shape of a waveform you will at the very least want to see the first 2 (base and 1st) and preferably at least 3 of the harmonic frequencies. For an aliasing error to occur a harmonic frequency would need to be between 0.5 fs and 0.6 fs (and be closer to .5 fs to have the biggest impact). Remember that an oscilloscope isn't a precision instrument nor a data acquisition device and at the -3dB point the amplitude error is already near 30% !

In the end it is all about compromises; getting the highest bandwidth with the least horrible step response. And there is always the option to include two filters; one with the best step response and one with the highest bandwidth.

[tom66]

Does raise the question of how to use the 12-bit 640MSa/s mode.  I had considered limiting that to 500MSa/s as that fits in an even multiple of 16-bit samples with 4 bits unused.   But that makes the 4ch Nyquist 62.5MHz and if you have a 12 bit ADC with ~10.5 ENOB after AFE noise, then you need filter to be rolling off to -63dB with say a -3dB bandwidth of 40-50MHz.  Even enabling the full 640MSa/s is still only 80MHz Nyquist so practical upper B/W limit is still ca 50MHz.

I don't think that is practical so 12-bit mode will always have some risk of aliasing if used on 4ch mode.  Switching filters (other than a simple 20MHz Varicap filter) seems impractical and in any case a single pole filter driven by a varicap is unlikely to roll off quickly enough to be useful for 12-bit mode.

So what do you do?

[Marco]

My primary concern now is the AFE input filter.  It should be a high order Bessel-Thomson filter to provide accurate waveform shape.  I've got every reference I can find, but unfortunately, the maximally flat phase gets skimpy treatment and I've still not figured out how to analyze and design one from first principles.

I know nothing about it but what google told me and a history of stuff from college I forgot after the exam, but I found the Incomplete Gaussian Filter from this paper rather elegant. Looks easy to implement and doesn't try to reflect a ton of energy into your buffer.

[rhb]

Just think about it and look at it from a practical point of view. Frequency continues to roll off, signals consist of harmonics and at 200MHz you are already over the limit of what can be measured with a standard hi-impedance probe.  The probe itself will already cause a significant high frequency attenuation.

There is a ton of information available on this forum about anti-aliasing filters and DSOs. But since this thread is about an open source design you are free to fit whatever filter you like. I will go for what is the standard approach (which is to have a bandwidth of fs/2.5) for now.

In a nutshell:
From an error perspective: 1% is more than 2 bits (2 bits = 12dB). So if the attenuation is 3dB at 0.4fs, 48 - 12 = 36dB at Nyquist (0.5 fs) and 48dB at 0.6 fs then the amplitude error is less than 1% due to aliasing. Another issue to factor in is that in order to show the shape of a waveform you will at the very least want to see the first 2 (base and 1st) and preferably at least 3 of the harmonic frequencies. For an aliasing error to occur a harmonic frequency would need to be between 0.5 fs and 0.6 fs (and be closer to .5 fs to have the biggest impact). Remember that an oscilloscope isn't a precision instrument nor a data acquisition device and at the -3dB point the amplitude error is already near 30% !

In the end it is all about compromises; getting the highest bandwidth with the least horrible step response. And there is always the option to include two filters; one with the best step response and one with the highest bandwidth.

Here is the log magnitude spectrum of Bessel filters from order 1 to 10 from .


Handbook of Filter Synthesis
Anatol I. Zverev
Wiley 1967 & 2005

As can be seen from the attached figure, with Fc = 200 MHz,  at 250 MHz  there is less than -6 dB of attenuation even for a 10th order Bessel filter.  At 1 GHz, a 5th order Bessel is down about -50 dB.

With that I shall leave you to figure out what you got wrong.

Have Fun!
Reg

[nctnico]

@rhb: There must be something wrong with the tables you are using. The filter generator & simulator tool I'm using shows a decent attenuation at Nyquist. Unfortunately I'm on the road so I don't have access to it so that has to do for now.

Does raise the question of how to use the 12-bit 640MSa/s mode.  I had considered limiting that to 500MSa/s as that fits in an even multiple of 16-bit samples with 4 bits unused.   But that makes the 4ch Nyquist 62.5MHz and if you have a 12 bit ADC with ~10.5 ENOB after AFE noise, then you need filter to be rolling off to -63dB with say a -3dB bandwidth of 40-50MHz.  Even enabling the full 640MSa/s is still only 80MHz Nyquist so practical upper B/W limit is still ca 50MHz.

I don't think that is practical so 12-bit mode will always have some risk of aliasing if used on 4ch mode.  Switching filters (other than a simple 20MHz Varicap filter) seems impractical and in any case a single pole filter driven by a varicap is unlikely to roll off quickly enough to be useful for 12-bit mode.

So what do you do?

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.

[tom66]

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.