Having spent a while recently trying to fix an ancient oscilloscope, it occurred to me that it might be quicker to make one from a Raspberry Pi.
Update: scroll down for more on trimmers and relays in the input analogue signal chain.
After all, the Pi accepts keyboard and mouse connections, has a capable graphics processor, and has a choice of graphics outputs: HD-quality HDMI for a separate monitor, or a DSI output that matches with the Foundation’s own 800×480 7in touch screen – onto whose back a Pi can be mounted.
I quickly discovered that is the other end of the scope signal chain where the challenge lies: bridging the gap between the Raspberry Pi and a scope probe BNC connector, without loosing signal fidelity, and with sufficient speed.
There have been some heroic efforts to do this, and some innovators have really pushed the boundaries of what is possible, including clever software manipulation that achieves 10Msample/s though Raspberry Pi’s 40pin GPIO interface. And there are plenty of folk that have managed to hit 1Msample/s for a single channel.
But what would it take to turn it into a real scope – say one with 10 or 20MHz of bandwidth?
Who better to ask than Pico Technology, the UK-based PC oscilloscope firm that already makes a 10MHz USB scope-in-a-box (the 2204A, pictured) that will plug into Raspberry Pi for under £100 – half the price of some bare-board USB scopes.
How easy would it be to make a custom scope add-on board – known as a HAT (hardware attached on top) Pi-speak.
Possible, but not trivial, was the response of Pico’s sales and marketing manager Trevor Smith.
What stops it being a simple case of putting an ADC on a PCB, he said, is data bandwidth.
“The industry rule-of-thumb is having a sample rate of five times the maximum analogue bandwidth,” said Smith, “so for 10MHz bandwidth you need an ADC running at 50Msample/s/channel, which is 100Msample/s x 8bits for two channels – not trivial.”
And this is not going to pass easily across the GPIO or any of the USB channels on a Raspberry Pi.
“If every time you made an acquisition you sent it up the USB cable, the USB cable would become a bottleneck,” said Smith.
At this point, you either work back from the data bottleneck and accept what ever sample rate that allows, or you do what USB scope makers do: use local digital signal processing to compress data before it has to go though the USB cable – a technique that could be applied to a scope HAT, said Smith, regardless of which Pi interface was used.
One of the things that is important in an oscilloscope is screen update rate: the user needs to see a lively display when the signal is changing, although there is no need for updates faster than the user can perceive.
This means that the system bottleneck is not a limit if it can pass data at the maximum useful rate. “USB is fast enough for humans,” said Smith.
In most USB scopes, on-board data processing is handled by an FPGA – this is true of Pico’s products – and what goes on in that FPGA is a key item of scope manufacturer intellectual property. For basic operation however, it does not have to be that complicated.
The FPGA’s job is to mediate between front-end ADCs, local memory and the data pipe: directing data from ADCs to RAM as fast as the selected sweep rate and memory capacity will allow, and directing data from RAM to the host via the chosen compression process.
“The FPGA is sending a result summary to the PC to display,” said Smith. “You wouldn’t want 10,000 points sent up time after time after time. Say you have thousands of points, and don’t need thousands of points on display – FPGA works out what needs to be sent.”
According to him, a simple form of compression is sending min-max pairs. For example: if there are 100,000 samples in the memory, but the display is only 1,000 pixels across, blocks of 100 samples are scanned to find the minimum and maximum sample value in the block, and only these two numbers are sent.
The scope software running on the host then displays a vertical line between min and max value for that location along the horizontal time graph, thickening the trace as though all the samples were present.
“If you had simply sent one in every 100 points, you would miss glitches, and a major function of a scope is to look for glitches,” said Smith.
Refreshed at 50Hz – 50 traces one over another – the user gets a lively display.
Ultimately, “the update rate is determined by performance of FPGA, not so much the USB,” said Smith.
Beyond 10MHz, he added, another design challenge is memory bandwidth between FPGA and memory “A lot of effort goes into designing the memory interface,” Smith said.
As well as removing the need for fast interfaces, the on-board FPGA reduces the host workload as the computer now only has to control the FPGA and display waveforms.
That said, the host computer can get involved when things like fast Fourier transforms (FFTs) need calculating for a frequency domain display. In this case, all data in the sample memory might need shifting through the data pipe before the calculation can be performed, stopping real-time operation for a bit.
If the scope hardware is asked to act as a digitiser – “You might want to throw data at MATLAB,” for example, said Smith – then the FPGA has the job of arranging the fastest real-time operation possible within the limits of the connecting bus – although this mode of operation is probably beyond the needs of a Raspberry Pi scope HAT. In professional-grade PC scopes, USB 3 interfaces can help here.
On the other side of the input ADC or ADCs, each channel gets an input attenuator and input amplifier.
“At low frequency, the attenuator can be done with resistors plus capacitors quite readily,” said Smith. “If trying to achieve 1MHz or more, you have to start matching characteristics of the front end attenuator with the signal chain.”
There would have to be ac/dc switching and attenuation adjustment, some of which can be done with electronic switches, although there are good reasons for using relays (bi-stable types save power) in critical positions like the ac/dc coupling switch.
“Relays are a balancing act, you could use solid states, and some topologies do,” said Smith. “Don’t forget that when a scope is off then applying an input signal should not damage the scope or provide a safety hazard – rail-ESD diodes are often overlooked in components. The safe compromise for inexperienced analogue designers is generally mechanical relays so you don’t have to consider many parasitic parts. Mechanical relays can be excellent at switching – between an exceptionally good resistive and capacitive isolation path, to a very low impedance path – at the cost of higher power, or switching complexity if using latching parts.”
On the subject of trimmers, Smith said: “If you don’t care so much about pulse response then you can use cheap components and compromise on the accuracy of your waveform – not something that Pico would ever allow. If you want good response then you will need to either use high-tolerance or binned fixed components, and evaluate your design carefully – which is expensive and long winded; or use trimmers and spend your time trimming. There are topologies that would allow you to get rid of the trimmer, but cost in power and complexity. On this design I suspect trimmers are the right compromise.”
Another analogue decision would be to create a local negative rail, or to shift the incoming signal somewhere between 0 and 5V.
All this should be possible in the area of a HAT, even though there will almost certainly be at lease one trimmer capacitor per channel to tweak response.
Does Smith have more advice?
“You are trying to achieve pretty good linearity out to the bandwidth of the scope. You need to pay attention to the linearity of the whole signal chain: attenuator, amplifier and ADC,” he said. “Frequency response and pulse response don’t always run together. You can end up with fairly good flatness, and then you put a pulse in and get all sorts of ringing and over-shoot.”
On the subject of grounding: “for us, the signal grounds need to be bought out onto proper signal connectors – BNCs.
Getting solid connections between the input socket, attenuator, amplifier and ADCs helps keep down noise.
“You want a front end that is low-enough in noise to be compatible with resolution of the scope you are trying to build. You don’t want more than half a division of noise on the screen, on the most sensitive range,” said Smith. “We have 10 divisions vertically in our display and the most sensitive range is 1mV/division, which is 10mV/screen, so you would want <500uV of noise – most people’s 8bit scopes struggle to meet that, but it is a nice goal.”
With two side of the PCB to play with, a Raspberry Pi HAT with enough performance to call itself a proper 10MHz scope looks distinctly plausible.
Unless someone delves into the Broadcom chips deeply enough to unlock the secrets of Pi’s 2Gbit/s MIPI CSI-2 camera interface, and then finds it suitable for scope use, there is going to have to be an FPGA on a 10MHz scope HAT, and developing suitable firmware for that would be a labour of love. Analogue-wise, the devil will be in the detail.
It would certainly be easier to buy a PicoScope 2204A.