Oversampling, decimation, dithering

[colinh]

Hi, I'm not sure which forum this fits in best

I'm writing a toy logic analyser / oscilloscope in assembler for my toy OS (written in assembler) [ie. no C, no libraries]. At the moment I'm just sampling the system timer (SYST_LO) register (at 44 Msamples/s) but I'll be switching to (8 pins from) GPIO_0 when I'm back home and can rig up a signal generator.

I'm sort of familiar with the Nyquist frequency / low-pass filters and with oversampling/decimation (+ noise) to increase the resolution of an ADC but I'm not entirely sure how this applies to a logic analyser.

Say I have a time base of 10 µs (ie one division, 40 pixels, represents 10 µs) then I have 440 samples from which I want to choose 40 to display. I'm effectively sampling at 4 MHz and could display a 2 MHz signal (ie. a pin alternating between 1 and 0 at 2 MHz).

To get my 40 samples (for one division) I could simply take each 11th one from the sample buffer. But to avoid aliasing I'm considering adding a pseudorandom(*) dither of up to +/- 5. Ie. instead of taking samples 1, 12, 23, 34, 45, ... taking e.g. 1, 10, 27, 29, 48, ...

Is this the right way to go about it?

(*) I'm reading about PRNGs on wikipedia. An XORshift RNG looks like a fun one to implement.

[Gert van Loo]

A logic analyser does not do any post-processing.
You display each sample using the sample time as time-base.

The display format I like is the plain square wave.

Don't try to do anything fancy like the new logic analysers from Agilent (HP).
These have some ghastly method where the draw a slanted line where it goes from 1 to 0 (or vice versa)
It completely distorts what you are looking for especially if you have edges close together.
It the best example I ever have seen of a SW person writing code for something he/she has never used in their life.

[colinh]

A logic analyser does not do any post-processing.
You display each sample using the sample time as time-base.

OK, but isn't there the danger then of misrepresentations? Say, in my example, a pin is switching at 4 MHz, and I'm displaying 40 pixels for 10 µs, then the display will be of a flat line, at arbitrarily one level or the other, won't it?

I could look at all the available (over)samples and display both high and low pixels [at a particular X coordinate] (or use a special colour or something) to indicate that the signal is actually switching...

[...] It the best example I ever have seen of a SW person writing code for something he/she has never used in their life.

Right! No diagonals or anything silly I admit that I haven't used a logic analyser yet, although there have been times I would have liked one. Actually, now I do have one. Nearly. A Hameg HMO3522, but I don't have the 8 channel logic probe yet

[joan]

...
OK, but isn't there the danger then of misrepresentations? Say, in my example, a pin is switching at 4 MHz, and I'm displaying 40 pixels for 10 µs, then the display will be of a flat line, at arbitrarily one level or the other, won't it?
...

No, I'd draw a solid bar to show there has been a transition between 0 and 1. A flat line would be misleading.
Have a look at piscope which uses some of the techniques you are talking about.

[colinh]

No, I meant if I sample at 4 MHz to get 40 samples to display 40 pixels (for 10 µs), if the pin happens to be switching at 4 MHz I'll be sampling at exactly the same point in the cycle and keep getting the same value, which will look like an unchanging signal.


Piscope looks very nice by the way.

[joan]

No, I meant if I sample at 4 MHz to get 40 samples to display 40 pixels (for 10 µs), if the pin happens to be switching at 4 MHz I'll be sampling at exactly the same point in the cycle and keep getting the same value, which will look like an unchanging signal.
...

Okay, I misunderstood what you were saying. But that's the problem with sampling, you can get erroneous results, especially if you get in sync with the signal.

[Gert van Loo]

There is now way to avoid getting erroneous data when sampling.
It is up to the user to make sure that they know how the equipment works,
have some idea what they are doing and thus to understand what that means for the result.

In your example you are making a small thought error:
You start with stating a signal which you know what it is and then from there
work your way to an error.

In the real world it works just the opposite: you don't know what your signal
looks like and you have to find out, through measuring (in which you know
what errors your measurement equipment contains) derive what the real signal (probably!) is.