Author Topic: Compensating bandwidth with software  (Read 6269 times)

0 Members and 1 Guest are viewing this topic.

Online gf

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: de
Re: Compensating bandwidth with software
« Reply #25 on: April 14, 2019, 09:09:56 pm »
The high frequencies will fold around the fs/2 point. So if you filter digitally between the bandwidth and fs/2 then you'll still filter away the unwanted frequencies. The only requirement is that the unwanted frequencies are attenuated by at least bits*6dB at fs/2 + (fs/2 -BW).

Thanks. As long as BW is sufficiently below fs/2, this is indeed an option.
(I was rather assuming that amlost the whole range up to fs/2 were supposed to be utilized.)
 

Online gf

  • Super Contributor
  • ***
  • Posts: 1183
  • Country: de
Re: Compensating bandwidth with software
« Reply #26 on: April 14, 2019, 11:30:02 pm »
If you are not too severely aliased you can get away with sampling without an anti-alias filter. But just like the wagon wheels turning backwards, you can make a waveform backwards.

At least I do not wonder if I feed e.g. a 10.2 MHz signal into my scope and see this signal showing up as ~8.5 Hz signal when the timebase is set to a slow value of 100ms/div (-> 2.5 kSPS).

When it arrived it had <3% overshoot on a step, meeting the traditional  standard set by Tektronix.

In fact I find it pretty annoying if the waveform on the scope suggests the presence of overshoot, although the signal does not suffer from overshoot at all. W/o AA filter I can switch to the points display and check the non-interpolated raw samples. I the overshoot is however introduced by an AA filter prior to sampling, the points display won't help either.

Do you happen to know how much bandwidth below fs/2 needs to be renounced (using an optimal filter) in order to achieve < 3% overshoot in the time domain, while still providing sufficient AA cut-off for 8 bits resolution?
 

Online rhb

  • Super Contributor
  • ***
  • Posts: 3483
  • Country: us
Re: Compensating bandwidth with software
« Reply #27 on: April 15, 2019, 02:16:04 pm »
Fc needs to be Fs/4 to get an optimal step response.  My testing using the filter option on the MSOX3104T showed that if I applied a low pass filter with 750 MHz corner I got a clean step.  But there was no documentation of what type of filter was being used.  And there are other issues I've not yet resolved to my satisfaction

The appropriate filter is a maximally flat delay filter.  The proper way to do it is to apply an analog anti-alias filter to suppress the input -6 dB per bit at Fn.  So with Fc = Fs/4 it requires one pole per bit.  Then follow that with a Wiener least squared error FIR filter or a least summed absolute amplitude filter using the FPGA to clean up any errors in the analog filter response and give the optimal rise time and overshoot.

There is a valid argument for allowing the user to choose between minimum rise time and minimum overshoot with a user threshold for the overshoot.  My LeCroy DDA-125 has a minimum rise time of <250 ps.  But at the cost of a 20% overshoot.  This was acceptable because rise time was the measurement of greatest importance testing disk drives.  Not very good for a general purpose DSO though.

I'm so furious over the step responses I've taken on a 2-3 year project to fix the problem.  To date I've spent close to $3k getting set up to do the work.
 
The following users thanked this post: gf

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 16620
  • Country: us
  • DavidH
Re: Compensating bandwidth with software
« Reply #28 on: April 16, 2019, 01:07:39 am »
Both Tektronix and Keysight have written application notes explaining away the compromised pulse response of their DSOs that have a maximally flat response.  The argument comes down to more accurate results for measurements like rise and fall times and ETS like results can be achieved with averaging to remove the residual aliasing.  Of course if you were going to average, then ETS would have prevented the problems and delivered better results.

Ultimately I think the lesson to take away from the previous discussion is that no practical supposed anti-aliasing filter is going to allow a DSO to operate accurately at close to its Nyquist frequency.  If the pulse response is corrupted, then a faster DSO is required for accurate measurements.  Sampling at 2.5 times the bandwidth?  Just laugh.  Low frequency Gaussian (1) roll-off DSOs have a pulse response which is corrupted in a different way but at least it can be easily modeled.

Do not rely on a 100 MHz instrument for 3.5 nanosecond transition time measurements.

(1) They do not really have a Gaussian roll-off but it is pretty close.  But consider *why* they have an almost Gaussian rolloff instead of a single pole roll-off; the transition band is not the product of a single stage.  This answer also explains why the maximally flat response of a higher bandwidth DSO is not the result of an anti-aliasing filter; it is the result of equalization to clean up the response unless it is designed in for market segmentation based on bandwidth.  Take a really close look at the difference in pulse shape between a Rigol 50 MHz DS1054Z and 100 MHz DS1104Z.  Or compare the pulse shape of your pet DSO at full bandwidth and with the 20 MHz bandwidth limiter active.  If they are different, then one of them is not Gaussian.


 

Online rhb

  • Super Contributor
  • ***
  • Posts: 3483
  • Country: us
Re: Compensating bandwidth with software
« Reply #29 on: April 16, 2019, 01:52:04 pm »
The Fourier transform of a boxcar BW filter is a sinc(t) quite independent of the sample rate.  So if you want accurate step responses you must have a gradual filter slope at the upper frequency limit.  We did not see such things before the advent of DSOs because they were too hard to build in analog form. In the limit it requires an infinite number of poles.

For an 8 bit ADC, a single pole filter would require an Fc  8 octaves below Nyquist.  Sampling at 1 GSa/s to provide a 4 MHz BW DSO would not sell very well.  So multipole filters are very necessary for a practical instrument.

Seismic processing is *very* obsessive about pulse shape.  For marine work the boat goes out to deep water, drops of a buoy with a recorder and a hydrophone at sufficient depth below the surface.   Not having been involved in that work, I don't know off the top of my head what "sufficient" is.  As the the signature test, as it is called, is done in deep water there is only a single reflection at the sea surface to contend with.  The boat makes a pass shooting and the response at small angles from vertical is recorded.  The array of guns is designed to optimize the pulse shape around a narrow range of angles near vertical.

From this an inverse (Wiener prediction error) filter which compresses the actual waveform to a symmetric (aka zero phase) band limited impulse is computed.   This filter is typically applied as the first step in processing.  It can be applied at any point if all the processing steps are linear, but many processors are skeptical that is actually the case.

It used to be the case that one also applied a correction for the minimum phase response of the anti-alias filters and amplifiers in the AFE of the recording system.  However, I would expect that correction is now applied in the recording system using an FPGA.  The corrections are instrument specific and it is *very* hard to determine when boats made changes to their recording systems when reprocessing old data.  And finding the instrument impulse tests is often impossible.

As part of my FOSS DSO FW project I am examining the problem of the optimal anti-alias filter in detail.  I am also examining the optimal interpolation filter.  While it is commonly described as being sinc(t),  that is actually not the proper operator.  The proper operator is the minimum phase Fourier transform of the filter transfer function.  It is a sinc(t) if and only if the filter is a zero phase boxcar.  That's not physically realizable in a purely analog form.

All the DSOs (6 OEMs)  I've looked at apply a symmetric, zero phase interpolator.  As a consequence, there is a precursor ripple that precedes a step.  On some instruments you can avoid that by turning off the interpolator or switching to dot mode.  However, some instruments always apply the interpolator even when in dot mode.

I'd like to note that the Gaussian is not the only filter shape which is symmetric under a Fourier transform.  A sech(x) form is also shares the time-frequency symmetry properties of a Gaussian.
 

Offline David Hess

  • Super Contributor
  • ***
  • Posts: 16620
  • Country: us
  • DavidH
Re: Compensating bandwidth with software
« Reply #30 on: April 16, 2019, 10:07:47 pm »
For an 8 bit ADC, a single pole filter would require an Fc  8 octaves below Nyquist.  Sampling at 1 GSa/s to provide a 4 MHz BW DSO would not sell very well.  So multipole filters are very necessary for a practical instrument.

Yet most practical DSOs do not have this!  So how can they be practical?

Quote
Seismic processing is *very* obsessive about pulse shape.  For marine work the boat goes out to deep water, drops of a buoy with a recorder and a hydrophone at sufficient depth below the surface.   Not having been involved in that work, I don't know off the top of my head what "sufficient" is.  As the the signature test, as it is called, is done in deep water there is only a single reflection at the sea surface to contend with.  The boat makes a pass shooting and the response at small angles from vertical is recorded.  The array of guns is designed to optimize the pulse shape around a narrow range of angles near vertical.

These are specialized applications operating at low frequencies where anti-aliasing filters in the linear analog, sampling analog, and digital domain are completely practical.  An example of this are the "better than Bessel" integrated filters made by Linear Technology.  Increasing digital integration has made higher sampling rates and post acquisition DSP with minimal filtering in the analog domain the most economical way these days although it becomes very expensive albeit still viable at the highest bandwidths and sample rates which gets back to the subject of this discussion.

Quote
It used to be the case that one also applied a correction for the minimum phase response of the anti-alias filters and amplifiers in the AFE of the recording system.  However, I would expect that correction is now applied in the recording system using an FPGA.  The corrections are instrument specific and it is *very* hard to determine when boats made changes to their recording systems when reprocessing old data.  And finding the instrument impulse tests is often impossible.

These corrections were also applied to analog oscilloscopes to correct things like dribble up in delay lines.  With proper testing, you can actually see the result of this.  These filters can generate preshoot in the transient response if the applied edge is fast enough which is rather disconcerting on an analog instrument.  I have seen it on the Tektronix 2465 series oscilloscopes but *not* the older but slightly faster 7800 and 7900 instruments suggesting a design difference.

Quote
All the DSOs (6 OEMs)  I've looked at apply a symmetric, zero phase interpolator.  As a consequence, there is a precursor ripple that precedes a step.  On some instruments you can avoid that by turning off the interpolator or switching to dot mode.  However, some instruments always apply the interpolator even when in dot mode.

I have seen that before and concluded it was the Gibbs phenomenon.  I did not have a fast enough pulse generator to test it on a Tektronix MDO5000 when I had a chance but the DSP bandwidth filters exhibited it and the hardware analog filters did not as expected.

As part of my FOSS DSO FW project I am examining the problem of the optimal anti-alias filter in detail.  I am also examining the optimal interpolation filter.  While it is commonly described as being sinc(t),  that is actually not the proper operator.  The proper operator is the minimum phase Fourier transform of the filter transfer function.  It is a sinc(t) if and only if the filter is a zero phase boxcar.  That's not physically realizable in a purely analog form.

It seems we have parallel DSO projects going.  I am less worried about anti-aliasing and correcting the response in the digital domain because I want to make something more like an improved DPO style DSO where variable sample rate and variable depth histograms are created during decimation for essentially zero blind time.  The objective is a real time index graded display which is completely faithful to an analog display but with complete digital measurement capability.

Performance of this design is completely dominated by memory bandwidth so large record lengths are useless because the memory never has time to be accessed.  I would be ideal for an ASIC or FPGA using internal memory only.

 

Online rhb

  • Super Contributor
  • ***
  • Posts: 3483
  • Country: us
Re: Compensating bandwidth with software
« Reply #31 on: April 17, 2019, 12:16:21 am »
25 is dot mode with the sinc(t) turned off.  26 is vector mode with the sinc(t) turned on.  It's an ignorance issue.  The Gibbs' phenomenum is completely different. The input is a 100 ps pulse generator from Leo Bodnar.

The R&S RTB2k has a 2 pole anti-alias filter according to Rich in a response to questions someone asked.  You can also pickup additional low pass filtering by choosing an output buffer amp with the appropriate gain-BW product.  Whatever you choose for the BW, the higher frequencies *must* be suppressed by 6 dB per bit at that frequency and above.

DSP started with seismic in 1952 using paper, pencil and a desk calculator.  Enders Robinson did it for his PhD under Norbert Wiener.   It didn't become possible to do it by machine until the early 60's.   No one else could afford it, so it was strictly limited to oil exploration.  Texas Instruments was a subsidiary of Geophysical Services, Inc.  that built recording gear for GSI.  Mobil Oil manufactured their own geophones.  Most large oil companies did similar things because they didn't want to wait for a commercial product.  They only stopped when commercial products were as good or better.

I'm starting with the AFE to DRAM chain because I want to implement LeCroy style stackable math operations.  There is no need to update the screen faster than 60 fps, so I don't see an issue with writing to DRAM  via the FPGA at high speed and reading the buffers at lower speeds.

I don't think most of the people developing DSO FW have ever used a scope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf