Computing stuff tied to the physical world

Oscilloscope sampling rate

In Hardware, Linux on Jun 16, 2013 at 00:01

Just to finish the series on Raspberry Pi I/O – here’s proof of its GPIO pulsing speed:


The trouble is the irregularity caused by Linux’s multi-tasking properties, and I wanted to show you some examples of that. After a few dozen captures, I came up with this one:


Looks pretty bad, right? Tons of hickups in what was meant to be a 5.2 MHz pulse train.

Not so fast…

The sample rate used by the oscilloscope for this capture was 10 MHz, so it’s sampling the signal at 100 ns intervals. That’s extremely risky, because when the signal is also pulsing at this rate, you might end up missing each peak for a substantial amount of time. This would make it appear as if the signal was low or high all the time, despite its rapid changes.

This effect is called “aliasing”, and the solution is simple:

Do Not Sample At A Rate Close To The Frequencies In Your Signal!

I’m inclined to discard the above snapshot – it’s probably a measurement artefact.

Here’s another screen, this time at 50 MHz sample rate, i.e. 20 ns between captures:


At that rate, it’s impossible to miss pulses which are all in the range of 100 ns or longer. As you can see, there are still glitches (almost on every snapshot there is one), but it’s not as bad as the previous screen shot was suggesting.

Anyway. Enjoy your RPi and all the Linux high-level stuff it can do (like, ehm, run the Arduino IDE and cross-compile stuff for ATmega’s), but beware of treating it like a CPU which is exclusively at your service.

A Raspberry Pi is fast most of the time, but it’s (occasionally) a bit occupied with itself…

  1. Thanks for this exhaustive insight on RPi / frequencies / data transfes rates! I’m no Electronic Engineer whatsoever, but if I remember well, we should sample at a minimum of two times of the frequency rate to prevent aliasing. Am I right?

    • Sort of Luis. The Nyquist frequency is twice the frequency of the signal you are interested in but a square wave is made up of many frequencies (see Fourier analysis). Although the frequency of this square wave is around 10 MHz if you want to know when the pulse started you would need to sample on the order of the rise time.

    • Yep – see Wikipedia. I wanted to explain it in a more intuitive fashion as to why that sampling rate has to be twice or more. In this case of a square wave, the signal is composed of all the odd harmonics.

      To understand square waves and their composition from sine waves, see this 3-min video. The sound quality is awful, but the explanation is great.

  2. Don’t scopes have an envelope or peak detect measurement mode, that would let you capture something like the first trace, with the information you need?

    • Yes there are, but I’m not sure they can capture things more precisely than the signal acquisition rate. Would need to try it… peak detect mode might address this. The envelope capture mode is more a persist-like mode, which just aggregates the largest signal excursions on screen.

  3. Another potential limitation comes from the bandwidth of the triggering circuit – if the event crosses, then re-crosses, the detection threshold too quickly, no trigger is generated, no waveform captured at all.

    If you are searching for ‘runts’ or other very fast glitches, it can be better to leave the ‘scope in free running mode, then search the samples from memory after the fact. It is sometimes possible to generate a separate, single-shot trigger ‘near’ the expected event (e.g. waggling a DIO pin) to conserve sample memory.

    We are so used to ‘automatically’ deriving triggering from the input signal, that extra connector ‘EXT TRIG’ is often neglected.

Comments are closed.