Products > Test Equipment

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

<< < (56/71) > >>

rhb:

--- Quote from: 2N3055 on December 18, 2020, 09:20:32 am ---Digital scope with a screen (distinction from digitizer that samples data inside data acquisition system) need to serve two functions:
- emulate behaviour of a CRT oscilloscope on a screen
- function as a digitizer in a background, so that all data that it captured is sampled properly and doesn't contain any nonsense in mathematical way.

First point is well served with decimating to screen with peak detect.

[snip]

--- End quote ---

You clearly have never compared a good analog scope trace at different settings with a "peak detect" DSO using a *very*  short  (<10% of sample interval) pulse.

If you had, you would realize that peak detect is a *very* poor imitation of an analog scope. The Fourier transform does not conform to the displayed trace. Of course, you do need to understand what you are looking at in  both time and frequency by inspection.

"Peak detect" is a crude bodge to make up for improper downsampling by decimation without appropriate low pass filtering.

If you want to understand why things are this way, I'll be happy to pose the problems.  But I had to do them 35 years ago in Linear Systems and have no interest in repeating my school exercises.  I learned the lessons.

After a lot of consideration, I have concluded that a proper DSO should offer the user the option of  either Bessel-Thomson or Buterworth LPF to suit  the use case.  In any* case, it *must* suppress aliases by -6 dB per bit at Nyquist.  Should you be so foolish as to not do the exercises in order to actually learn how it really works, you're on your own. 

Have Fun!
Reg

2N3055:

--- Quote from: rhb on December 30, 2020, 12:59:19 am ---
--- Quote from: 2N3055 on December 18, 2020, 09:20:32 am ---Digital scope with a screen (distinction from digitizer that samples data inside data acquisition system) need to serve two functions:
- emulate behaviour of a CRT oscilloscope on a screen
- function as a digitizer in a background, so that all data that it captured is sampled properly and doesn't contain any nonsense in mathematical way.

First point is well served with decimating to screen with peak detect.

[snip]

--- End quote ---

You clearly have never compared a good analog scope trace at different settings with a "peak detect" DSO using a *very*  short  (<10% of sample interval) pulse.

If you had, you would realize that peak detect is a *very* poor imitation of an analog scope. The Fourier transform does not conform to the displayed trace. Of course, you do need to understand what you are looking at in  both time and frequency by inspection.

"Peak detect" is a crude bodge to make up for improper downsampling by decimation without appropriate low pass filtering.

If you want to understand why things are this way, I'll be happy to pose the problems.  But I had to do them 35 years ago in Linear Systems and have no interest in repeating my school exercises.  I learned the lessons.

After a lot of consideration, I have concluded that a proper DSO should offer the user the option of  either Bessel-Thomson or Buterworth LPF to suit  the use case.  In any* case, it *must* suppress aliases by -6 dB per bit at Nyquist.  Should you be so foolish as to not do the exercises in order to actually learn how it really works, you're on your own. 

Have Fun!
Reg

--- End quote ---

Sometimes I wonder did you ever used a scope in  your life...
Or learn how to read..
Read again what I wrote. I know that peak detect is mathematically incorrect for further analysis. But it is correct for the screen.

We have been here before and I did tell you to this simple experiment that is easy to reproduce:

Take a 100MHz carrier and AM modulate it with 100 Hz, and put scope on 2 ms/div you'll see this:


Scope is sampling at 100 MS/s. At half Nyquist.
And it is showing same as analog scope would do...


rhb:
 I can easily contrive cases where it doesn't mater.  I can also create cases where it does. Your assertion is only correct  if you ignore the Fourier transform of the screen image.

I don't wish to be rude, but this is basic DSP 101.

Buy one of Leo bodnar's 100 ps pulse generators, feed it to an analog scope and a DSO with peak detect and we can discuss further.  Until then.

Have Fun!
Reg

tautech:
Reg, maybe you have forgotten the lessen rf-loop gave you here:
https://www.eevblog.com/forum/testgear/scope-wars/msg3121780/#msg3121780

2N3055:

--- Quote from: rhb on December 30, 2020, 01:45:37 am --- I can easily contrive cases where it doesn't mater.  I can also create cases where it does. Your assertion is only correct  if you ignore the Fourier transform of the screen image.

I don't wish to be rude, but this is basic DSP 101.

Buy one of Leo bodnar's 100 ps pulse generators, feed it to an analog scope and a DSO with peak detect and we can discuss further.  Until then.

Have Fun!
Reg

--- End quote ---

You are rude because you don't read but are still being condescending and patronizing. I wrote:


Digital scope with a screen (distinction from digitizer that samples data inside data acquisition system) need to serve two functions:
- emulate behaviour of a CRT oscilloscope on a screen
- function as a digitizer in a background, so that all data that it captured is sampled properly and doesn't contain any nonsense in mathematical way.

First point is well served with decimating to screen with peak detect.


So to repeat, again, because we spoke of this before and you learned nothing the first time:

In order for scope to show, visually, on the screen, what people expect to see from time domain instrument, and make it similar to CRT scope it has to deal with the data in different manner, than what you would do if you sample data for spectral analysis, or for mathematically correct DSP analysis of any sort.

In order to deal with these contradictory requirements, high end mixed domain scopes either have modes in which they reconfigure data engines to work in Scope/RF SA mode, or they use powerful FPGA/ASIC and continuously sample at full speed, and then create 3 data streams through 3 separate datapump/decimation/DSP blocks to have screen/SA/propper measurement and further raw data analysis.

For lesser platforms, priority for scopes was to function as scopes so they have screen/propper data buffer architecture, with FFT for spectral analysis on top of normal scope data as afterthought. One inexpensive scope that has MDO approach is GW Instek that has SA mode, where they reconfigure data engine to work in more realtime SA mode.

So to simplify so you can understand this time, you're not supposed to analyse Peak detect data. Nobody ever said that, on several occasion I said explicitly it is incorrect data for any kind of further analysis (not  completely though, you can extract P-P envelope from it for instance).  Peak detect data is perfect data for screen though.
To be completely correct, absolutely correct data to plot, like David Hess said before, would be histogram of data to decimate, encoded in intensity by distribution density at value bins.
That would be perfect CRT emulation.
In real life Peak detect does decent representation, because it will still show very fast and rare peaks, instead for them to be hidden by being too dim to see.. If you would use histogram to calculate pixel brightness, you would still need to not make it completely linear, but bump up black point to be able to see rare events. Some compression would need to be there.

You need to separate screen stream and data buffer stream in the very beginning of data processing, and treat them separately, for them to both be correct.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod