The Rigol DS1054Zed is the oscilloscope you want. If you don’t have an oscilloscope, this is the scope that has the power and features you need, it’s cheap, and the people who do hardware hacks already have one. That means there’s a wealth of hardware hacks for this oscilloscope. One small problem with the ‘Zed is the fact that capturing an image from the screen is overly complicated, and the official documentation requires dedicated software and a lot of rigolmarole. Now there’s a simple python script that grabs a screen cap from a Rigol scope.

The usage of this python script is as simple as plugging the DS1054Z into your USB port and running the script. A PNG of whatever is on the screen then appears on your drive. Testing has been done on OS X, and it probably works on Linux and Windows. It’s a simple tool that does one job, glory and hallelujah, people are still designing tools this way.

This work was inspired by the efforts of [cibomahto], who spent some time controlling the Rigol with Linux and Python. This work will plot whatever is being captured by the scope in a window, in Linux, but sometimes you just need a screencap of whatever is on the scope; that’s why there were weird Polaroid adapters for HP scopes in the day.

Yes, it’s a simple tool that does one job, but if you need that tool, you really need that tool. [rdpoor] is looking for a few people to test it out, and of course pull requests are accepted.

At the time of this writing, the James Webb Space Telescope was perched upon its ride to space, ready for its much-delayed launch from the ESA spaceport in French Guiana. The $10 billion space observatory suffered one final delay (knocks on wood) when predictions of high winds aloft pushed it back from a Christmas Eve launch to a Christmas Day departure, at 12:20 UTC. Given the exigencies of the day, we doubt we’ll be able to watch the launch live — then again, past experience indicates we’ll still be wrapping presents at 4:20 PST. Either way, here’s hoping that everything comes off without a hitch, and that astronomers get the present they’ve been waiting many, many Christmases for.

In other space news, things are getting really interesting on Mars. The ESA announced that their ExoMars Trace Gas Orbiter has detected signs of water in the Valles Marineris. The satellite found a large area of increased hydrogen concentration in the top meter of Martian soil; the assumption is that the hydrogen comes from water, meaning that as much as 40% of the material in the region scanned may be water. If so, that’s a huge find, as we thought most of Mars’ water was locked in the polar regions. The Mariner Valley stretches more than 4,000 km just below the equator, and so may prove to be an important resource for future explorers.

Meanwhile, in Jezero crater, Perseverance has decided to upstage its rotorcraft sidekick for a change by finding signs of organic molecules on Mars. It’s not the first time organic compounds have been found — Perseverance’s cousin Curiosity found some too, ESA’s Mars Express mission spotted methane from on high, and then there were the equivocal but intriguing results from the Viking missions in the 1970s. But the latest evidence is really great news for the scientists who picked Jezero crater as a likely place to search for signs of past life on Mars. The organics found are not proof of life by any means, as there are many ways to make organic molecules abiotically. But then again, if you’re going to find evidence of life on Mars, you’ve got to start with detecting organics.

Back on Earth, getting your laptop stolen would be bad enough. But what if it got yoinked while it was unlocked? Depending on who you are and what you do with that machine, it could be a death sentence. That’s where BusKill could come in handy. It’s a hardware-software approach to securing a laptop when it — or you — suddenly goes missing. A dongle with a breakaway magnetic lanyard gets plugged into a USB port, and the other end of the lanyard gets attached to your person. If you get separated from your machine, the dongle sends customizable commands to either lock the screen or, for the sufficiently paranoid, nuke the hard drive. The designs are all up on GitHub, so check it out and think about what else this could be useful for.

If you like the look of low-poly models but hate the work involved in making them, our friend and Hack Chat alumnus Andrew Sink came up with a solution: an online 3D low-poly generator. The tool is pretty neat; it uses three.js and runs completely in-browser. All you have to do is upload an STL file and set sliders to get rid of as many triangles as you want. Great stuff, and fun to play with even if you don’t need to decimate your polygons.

And finally, what have you done with your oscilloscope for the last three years? Most of us can’t answer that except in the vaguest of terms, but then there’s DrTune, who took three years’ worth of screencaps from this Rigol DS1054z and strung them together into a 60-second movie. He swears he didn’t purposely sync the video to the soundtrack, which is “Flight of the Bumblebee” by Rimsky-Korsakov, but in some places it’s just perfect. See if you can guess what DrTune has been working on by watching the waveforms fly by. And watch for Easter eggs.

We’ve heard of the FNIRSI 1014D scope, but we’ve had the impression that it might not be a great scope, although it is economical. [Learn Electronics Repair] had heard from another YouTuber that it was “a piece of junk.” However, he wanted to look at it compared to another inexpensive scope, the Rigol DS1052E. His results were different from what we usually hear. To be clear, he didn’t think it was a perfect scope, but he did find it very usable for his purpose.

The 46-minute-long video does more than just a casual look. He uses both scopes in some real-world measurements. If you are in the market for a scope in this price range, it is worth the time to watch.

Honestly, we are as guilty as the next person of getting obsessed with specifications. One PC is good because it scores 1% higher on a benchmark than another. But in real life, you’ll never notice the difference. That may be what’s happening here.

On the other hand, everyone’s use cases are different. Besides that, your choice of a tool as integral to your day as a scope or a soldering iron is pretty personal. You like what you like, and it doesn’t always have to make sense.

If you have either of these scopes — or both — what do you think of the review? Leave us a note in the comments. We actually looked at the original review that this video refers to. We know that not all FNIRSI scopes live up to their supposed specifications.

There are a huge number of products available in the modern world that come with network connectivity now, when perhaps they might be better off with out it. Kitchen appliances like refrigerators are the classic example, but things like lightbulbs, toys, thermostats, and door locks can all be found with some sort of Internet connectivity. Perhaps for the worse, too, if the security of these devices isn’t taken seriously, as they can all be vectors for attacks. Even things like this Rigol oscilloscope and its companion web app can be targets.

The vulnerability for this oscilloscope starts with an analysis of the firmware, which includes the web control application. To prevent potentially bricking a real oscilloscope, this firmware was emulated using QEMU. The vulnerability exists in the part of the code which involves changing the password, where an attacker can bypass authentication by injecting commands into the password fields. In the end, the only thing that needs to be done to gain arbitrary code execution on the oscilloscope is to issue a curl command directed at the oscilloscope.

In the end, [Maunel] suggests not connecting this oscilloscope to the Internet at all. He has informed the producer about it but as of this writing there has not been a resolution. It does, however, demonstrate the vulnerabilities that can be present in network-connected devices where the developers of the software haven’t gone to the lengths required to properly secure them for use with the modern Internet. Even things not connected to a traditional Internet connection can be targets for attacks.

The trouble with fixing electronics is that most devices are just black boxes — literally. Tear it down, look inside, but it usually doesn’t matter — all you see are black epoxy blobs, taunting you with the fact that one or more of them are dead with no external indication of the culprit.

Sometimes, though, you get lucky, as [FeedbackLoop] did with this Rigol spectrum analyzer fix. The instrument powered up and sort of worked, but the noise floor was unacceptably high. Even before opening it up, there was clearly a problem; in general, spectrum analyzers shouldn’t rattle. Upon teardown, it was clear that someone had been inside before and got reassembly wrong, with a loose fastener and some obviously shorted components to show for it. But while the scorched remains of components made a great place to start diagnosis, it doesn’t mean the fix was going to be easy.

Figuring out the values of the nuked components required a little detective work. The blast zone seemed to once hold a couple of resistors, a capacitor, a set of PIN diodes, and a couple of tiny inductors. Also nearby were a pair of chips, sadly with the markings lasered off. With some online snooping and a little bit of common sense, [FeedbackLoop] was able to come up with plausible values for most of these — even the chips, which turned out to be HMC221 RF switches.

Cleaning up the board was a bit of a chore — the shorted components left quite a crater in the board, which was filled with CA glue, and a bunch of missing pads. This called for some SMD soldering heroics, which sadly didn’t fix the noise problem. Replacing the two RF switches and the PIN diodes seemed to fix the problem, albeit at the cost of some loss. Sometimes, good enough is good enough.

This isn’t the first time [FeedbackLoop] has gotten lucky with choice test equipment in need of repairs — this memory module transplant on a scopemeter comes to mind.

It used to be only high-end test equipment that had some sort of remote control port. These days, though, they are quite common. Historically, test gear used IEEE-488 (also known as GPIB or, from the originator, HPIB). But today, your device will likely talk over a USB port, a serial port, or a LAN connection. You’d think that every instrument had unique quirks, and controlling it would be nothing like controlling another piece of gear, especially one from another company. That would be half right. Each vendor and even model indeed has its unique command language. There has been a significant effort to standardize some aspects of test instrument control, and you can quickly write code to control things on any platform using many different programming languages. In a few posts, I will show you just how easy it can be.

The key is to use VISA. This protocol is defined by the IVI Foundation that lets you talk to instruments regardless of how they communicate. You do have to build an address that tells the VISA library how to find your device. For example: “TCPIP::192.168.1.92::INSTR.” But once you have that, it is easy to talk to any instrument anywhere.

I say that thinking it is a problem is half right because talking to the box is one task of the two you need to complete. The other is what to say to the box and what it will say back to you. There are a few standards in this area, but this is where you get into problems.

Rigol

Way back in 2015, I picked up a Rigol DS1052E and wanted to play with the remote control via USB. The resulting code (on GitHub) uses Qt and expects to open a USB port. The command language is simple and, helpfully, includes commands that simulate pressing keys on the front panel. I would find out that my latest Rigol scope, a DHO924S, doesn’t provide those KEY commands nor does my DS1154z.

So, for a 2023 version, I wanted to abstract some of the complexity away to simplify a future switch between different scopes. I was watching a video review of a DHO900-series scope, and the reviewer complained that while the scope would show its screen via a web interface (and you can operate it via that virtual touchscreen), he missed having access to the knobs next to the screen when using the scope remotely. I realized it would be possible to write a small program to control the scope and provide the “missing” controls as a panel that could sit next to the scope’s web interface.

Python

Since I also wanted to use this in scripts and I was freshly off the Hackaday Supercon badge, which used MicroPython, I decided to do this all in Python. My general plan of attack was simple:

• Use VISA to connect to the scope
• Abstract the direct SCPI commands using Python methods or properties in a class that represents the scope
• Create a GUI to use adjacent to the web interface

This post is about the first two items. I’ll cover the GUI next time. However, I didn’t totally wrap the entire SCPI command set in the Python class. Instead, I just provided what I needed for the task at hand. As you’ll see, it is easy to add whatever you like.

PyVisa

The first order of business was to install PyVisa. This sounds like it would be all you need, but it isn’t. Instead, it is a wrapper around a “real” VISA backend. Two popular choices are NI-VISA from National Instruments (free, although you probably have to register) or the open-source pyvisa-py. Try this:

pip3 install pyvisa pyvisa-py

Note that, as of now, pyvisa-py supports TCP/IP, GPIB, USB, and serial. That covers most bases, but if you need something different, you may have to try a different backend.

When you install pyvisa, it should leave a binary (in ~/.local/bin for me) called pyvisa-info. Run that, and it will tell you if it finds backends and will also tell you other things you might need to install. For example, I have no GPIB bus instruments and didn’t install that driver, so it warns me that I should install it if I want to talk to GPIB devices. I don’t, so I’m good. If you get bad error messages from pyvisa-info, you should fix them before you try to go further.

While SCPI defines some commands, mostly it is hit-and-miss. For example, a Tektronix scope might use CURVe? to get waveform data, while a Rigol might use WAV:DATA? , and other brands might only need DATA?. There are a few things you can usually count on, though.

When you see a question mark (like :WAV:DATA?) you are expecting the scope (or whatever it is) to answer you. When you don’t see a question mark, you are just sending data. In addition, when you see something like CURVe? written down, that means you are allowed to omit the “e” which saves a little time and communication bandwidth. So CURV? and CURVE? are the same thing.

Using PyVISA

To open a connection to a scope in Python, you will first need to import pyvisa. After that, you’ll create a resource manager and pass it a special open string. Here’s an excerpt from my scope abstraction class (find everything on GitHub):

# do the connect
def connect(self,usb,cxstring):
   if usb==0:
      cxstr="TCPIP::"+cxstring+"::INSTR"
   else:
      cxstr="USB0::0x1AB1::0x044C::"+cxstring+"::INSTR"
   self.visa=pyvisa.ResourceManager('@py')
   self.scope=self.visa.open_resource(cxstr)
   self.connected=True

In this case, I’m using a known scope, so I assume the USB IDs will be the same. If you are using a different instrument, this will change. Helpfully, if you open the Rigol’s web interface, you’ll find both connect strings written down for you to copy.

The connect member function takes just the IP address or scope name and fills in the rest. The usb flag determines if it treats the input as an IP address or a name. The resource manager argument tells the library which “backend” to use. In this case, I’m using pyvisa-py (@py). If you omit the @py string, the library will use the IVI library which will work with backends like NI-VISA and other vendor-specific libraries. If it can’t find an IVI library it will fall back to using pyvisa-py. You can also pass a full path name to the library you want to use. If you prefer, you can set the PYVISA_LIBRARY environment variable instead. There is also a .pyvisarc file you can use for configuration.

May I See Some ID?

Nearly every instrument supports the query *IDN? to return an identification string. The code defines two methods to send data to the instrument. The write method sends data with no return. The query method gets a return and chops off the trailing new line:

# send a query and return a response
def query(self,string):
   s=self.scope.query(string)
   if isinstance(s,str):
      return s[0:len(s)-1]
   else:
      return s

# just send
def write(self,string):
   return self.scope.write(string)

# get ID
def id(self):
   return self.query("*IDN?")

Once you have that, the rest is just writing little wrapper functions. The only real problem is that the scope doesn’t offer — that I could find — any way to simulate a front panel key. However, some of the front panel keys behave differently depending on other modes. For example, each click of a knob might represent a different value when the scope is set on a slow sweep vs a fast sweep. Or, for another example, the trigger level knob doesn’t have a corresponding SCPI command. Instead, you must set the level for the specific trigger you want to use. That means you must know what triggering mode is set since each one uses a different command to set the level.

If you are writing a script, this isn’t a big problem because you can just set the triggering mode to a known value before you set the level correctly. But for a user interface, it is a problem because you have to write code to emulate the scope’s behavior. Or you can simply do what I did. Make a reasonable assumption and live with it.

The Result So Far

Just as a test, I wrote a little script at the bottom of rigol_scope.py to connect to a fixed IP address (since this is just a test) and put the scope in single mode every 10 seconds.

if __name__=="__main__":
   import time
# test script
   scope=Scope()
   scope.connect(0,"192.168.1.92")
   while True:
      print("here we go again...")
      scope.single()
      time.sleep(10)
      print(scope.trig_status())

The next step is a GUI, but that will wait until next time. However, writing the code as a class like this has at least three advantages:

1. It would be easy to support multiple scopes; just instantiate more objects
2. It is also easy to provide the same abstracted interface to a different scope
3. You can use the object in other scripts or programs without having to carry along GUI code

Besides that, you could even support multiple GUIs with the same object. Anything you enhance or fix in the scope object benefits all the programs.

This isn’t the first time we’ve looked at PyVISA. Or, for that matter, SCPI.

Featured image: The delightfully named “Sine wave 10 kHz displayed on analog oscilloscope” by [Pittigrilli].

Last time, I assembled a Python object representing a Rigol oscilloscope. Manipulating the object communicates with the scope over the network. But my original goal was to build a little GUI window to sit next to the scope’s web interface. Had I stuck with C++ or even C, I would probably have just defaulted to Qt or maybe FLTK. I’ve used WxWidgets, too, and other than how many “extra” things you want, these are all easy enough to use. However, I had written the code in Python, so I had to make a choice.

Granted, many of these toolkits have Python bindings — PyQt, PySide, and wxPython come to mind. However, the defacto GUI framework for Python is Tkinter, a wrapper around Tk that is relatively simple to use. So, I elected to go with that. I did consider PySimpleGUI, which is, as the name implies, simple. It is attractive because it wraps tkinter, Qt, WxPython, or Remi (another toolkit), so you don’t have to pick one immediately. However, I decided to stay conservative and stuck with Tkinter. PySimpleGUI does have a very sophisticated GUI designer, though.

About Tkinter

The Tkinter toolkit lets you create widgets (like buttons, for example) and give them a parent, such as a window or a frame. There is a top-level window that you’ll probably start with. Once you create a widget, you make it appear in the parent widget using one of three layout methods:

1. Absolute or relative coordinates in the container
2. “Pack” to the top, bottom, left, or right of the container
3. Row and column coordinates, treating the container like a grid

The main window is available from the Tk() method:

import tkinter as tk
root=tk.Tk()
root.title('Example Program')
button=tkButton(root, text="Goodbye!", command=root.destroy)
button.pack(side='left')
root.mainloop()

That’s about the simplest example. Make a button and close the program when you push it. The mainloop call handles the event loop common in GUI programs.

Newer Widgets

Some tkinter widgets look old-fashioned, but newer variants can automatically replace the old ones. The new widgets are packaged as tkinter.ttk. These new widgets have slight differences, but most of the basic setup remains the same. The appearance functions are different, though. For example, a normal button uses fg and bg to set the foreground and background colors. A ttk button uses a style system that is more complex to set up, but also more powerful.

It is dead simple to use the new widgets. Normally, you’d import the whole GUI library with an import. You can import ttk from the tkinter module and then refer to the widgets explicitly (e.g., ttk.Button). However, it is common to simply import everything from tkinter and then use tkinter.ttk to override anything that is in the ttk library. For example:

from tkinter import *
from tkinter.ttk import *

Now, every reference to Button, for example, will resolve to ttk.Button. There are 18 “new” widgets, including some that don’t appear in the original tkinter, like Combobox and Treeview.

GUI Builder?

I started out looking for a good GUI builder for tkinter and I didn’t really find much. There’s a website that doesn’t seem to work well (and doesn’t handle ttk), a project that uses a paid GUI builder and then translates its output to tkinter, and PAGE.

PAGE is actually not bad but a little quirky. What I didn’t like was that it does the ordinary placement layout, which means a form you design might look bad on some machines due to font sizes or other factors. So a button might be placed at, say, 0.034 x 0.267 from the top corner of its container. In other words, 3.4% across and 26.7% down. However, if you spend some time with it, it does work and probably generates code that looks ok more than it fails to render nicely.

However, I finally decided just to build the GUI manually. It isn’t that hard. If you want a simple experience, check out PySimpleGUI I mentioned earlier. The layout there is a list of lists. Each list is a row in the GUI. That’s it. So: [ [ Row_1_column_1, Row_1, column_2,...],[Row_2_column_1,....],...]. That’s very simple to deal with. But doing it directly in tkinter is not bad, either.

Layout

I used a simple class to lay out my GUI and tried to keep it agnostic to the scope more or less. It creates a Scope object (from the last post) and manipulates it, but it doesn’t understand the commands or the communications. If you are a traditional GUI programmer, the scope object is the model and the GUI class is the view and the controller.

Most of the work occurs in the class constructor. There are three main parts:

1. Some internal state variables like connected and the scope object, which, initially is None.
2. The creation of GUI widgets. This doesn’t show anything; it simply creates the objects. This section also creates some ttk styles for use with the Run/Stop button.
3. The final section arranges the widgets in their parents.

You have to get used to the idea that you specify the parent widget in step 2, but you set the widget’s position in step 3. For example, consider this excerpt from the code:

   self.clabel=LabelFrame(self.top,text='Control')
   self.rsbtn=Button(self.clabel,text="Run/Stop",command=self.do_rs,style="GoBtn.TButton")
   . . . # create more stuff
   self.rsbtn.pack(side="left")
   . . .  # more buttons here
   self.clabel.pack(side='top',fill='both',expand='yes')

The first line creates a labeled frame attached to the top window. Then, the code makes a button that is a child of the label. It has some text, a style, and a function to call when you push the button.

Custom Components

For the scope controller, I needed some direction pads. That is, four arrow buttons going in different directions and a center button you can push. The tkinter library has nothing like that, but that’s not a problem. You can simply build it yourself. The tkinter widgets are just classes, and you can easily extend them to make your own variations and composite widgets.

First, I needed a small button, and out of laziness, I decided to create a custom component. I simply derived a new class from Button and set a default width of 1 in the constructor. Truthfully, I should have just hardcoded the width. If you are going to supply a width, why not just use a regular button? Anyway, here’s the entire code:

# Create a tiny button
from tkinter import *
from tkinter.ttk import *

class Button1(Button):
def __init__(self, parent,text='',command=None,width=1):
   Button.__init__(self,parent,text=text,command=command,width=width)

As you can see, creating a custom widget doesn’t have to be a big deal. Normally a good base class for custom widgets is Frame. A frame can hold other widgets; by default, it is invisible. Just what you need. In this case, though, it made more sense to customize the Button class.

I did use Frame as the base class for the direction pad. I create some buttons that use a lambda — an anonymous, inline function — for their actions. This lets the code easily call a single callback for all the buttons. The default callback breaks everything back out to functions like up or down.

At first, that might seem crazy. Why not just assign the function directly to the key? The answer is reusability. There are several ways to use the custom component:

1. Set a non-default callback. This is a single function to process all keys.
2. Create a new subclass and replace the default callback. Again, this is a single function for all keys.
3. Create a new subclass and replace each of the low-level functions. This provides separate functions for each key.

The layout is simple, using the grid call to set a row and column:

 def __init__(self,parent,callback=None):
   Frame.__init__(self,parent)
   self.callback=callback
   self.upbtn=Button1(self,text="^",command=lambda: self.press(Dpad.UP))
   self.dnbtn=Button1(self,text="V",command=lambda: self.press(Dpad.DOWN))
   self.rtbtn=Button1(self,text=">",command=lambda: self.press(Dpad.RIGHT))
   self.lfbtn=Button1(self,text="<",command=lambda: self.press(Dpad.LEFT))
   self.exebtn=Button1(self,text="*",command=lambda: self.press(Dpad.EXEC))
   self.upbtn.grid(row=0, column=1)
   self.lfbtn.grid(row=1, column=0)
   self.rtbtn.grid(row=1, column=2)
   self.dnbtn.grid(row=2,column=1)
   self.exebtn.grid(row=1,column=1)

Now, the main code can create two different direction pads without problems.

The Whole Enchilada

You can find the entire code on GitHub. Once you get past the GUI layout, most of the code just calls the object from the last time that actually talks to the scope.

There are two interesting things, though. Since the DHO900 doesn’t give you a way to emulate key presses, the program has to understand a bit about the state of the device. For example, pressing the Run/Stop button works differently if the scope is already running or already stopped. So, the program needs to know the current state to send the right command.

It is possible to query the scope at the time of the command, of course. However, I wanted the program to track the state periodically and update certain UI elements. For example, I wanted the Run/Stop button to show red or green based on what would happen if you pressed the button. The trigger type combo box, too, should reflect the current trigger state even if someone manually changes it.

Luckily, tkinter provides a way to add delay processing to the event loop using after. The code calls it against the top window with a delay in milliseconds. When the timeout expires, the tick function runs. To keep the timer function going, tick must also rearm itself by calling after again. Before that, though, the code queries the state of the scope and updates the UI along with some state variables in the UI object.

The program seems to work well and should be much easier to port to a different scope now. If you can’t tell, GUIs are generally not my thing, although I build them when I have to. For simple stuff, tkinter isn’t half bad.

Once you can control your scope and grab data from it, there are lots of fun things you can do. Things can quickly get out of hand — but in a good way.

The Rigol DHO800 and DHO900 series use Android underneath, and as you might expect, this makes them easier to hack. A case in point: [VoltLog] demonstrates that you can add WiFi to the scope using a cheap USB WiFi adapter. This might seem like a no-brainer on the surface, but because the software doesn’t know about WiFi, there are a few minor hoops to jump through.

The first issue is that you need a WiFi adapter the built-in OS already knows how to handle. The community has identified at least one RTL chipset that works and it happens to be in the TP-Link TL-WN725N. These are old 2.4 GHz only units, so they are widely available for $10 or less.

But even with the correct hardware, the scope doesn’t have any menus to configure the WiFi interface. To solve that, you need to temporarily use a USB hub and a USB keyboard. Once you have everything plugged in, you can use the Super + N keyboard shortcut to open up the Android notification bar, which is normally hidden. Once you’ve setup the network connection, you won’t need the keyboard anymore.

Or maybe not — it turns out the keyboard does allow you to change a few other things. For example, [VoltLog] used it to increase the screen brightness more than the default maximum setting.

The only other issue appears to be that the scope shows it is disconnected even when connected to WiFi. That doesn’t seem to impact operation, though. Of course, you could use a WiFi to Ethernet bridge or even an old router, but now you have a cable, a box, and another power cord to deal with. This solution is neat and clean. You bet we’ve already ordered a TP-Link adapter!

WiFi scopes are nothing new. We suspect Rigol didn’t want to worry about interference and regulatory acceptance, but who knows? Besides, it is fun to add WiFi to wired devices.

Imagine an electronics lab. If you grew up in the age of tubes, you might envision a room full of heavy large equipment. Even if you grew up in the latter part of the last century, your idea might be a fairly large workbench with giant boxes full of blinking lights. These days, you can do everything in one little box connected to a PC. Somehow, though, it doesn’t quite feel right. Besides, you might be using your computer for something else.

I’m fortunate in that I have a good-sized workspace in a separate building. My main bench has an oscilloscope, several power supplies, a function generator, a bench meter, and at least two counters. But I also have an office in the house, and sometimes I just want to do something there, but I don’t have a lot of space. I finally found a very workable solution that fits on a credenza and takes just around 14 inches of linear space.

How?

How can I pack the whole thing in 14 inches? The trick is to use only two boxes, but they need to be devices that can do a lot. The latest generation of oscilloscopes are quite small. My scope of choice is a Rigol DHO900, although there are other similar-sized scopes out there.

If you’ve only seen these in pictures, it is hard to realize how much smaller they are than the usual scopes. They should put a banana in the pictures for scale. The scope is about 10.5″ wide (265 mm and change). It is also razor thin: 3″ or 77 mm. For comparison, that’s about an inch and a half narrower and nearly half the width of a DS1052E, which has a smaller screen and only two channels.

If you get the scope tricked out, you’ve just crammed a bunch of features into that small space. Of course, you have a scope and a spectrum analyzer. You can use the thing as a voltmeter, but it isn’t the primary meter on the bench. If you spend a few extra dollars, you can also get a function generator and logic analyzer built-in. Tip: the scope doesn’t come with the logic analyzer probes, and they are pricey. However, you can find clones of them in the usual places that are very inexpensive and work fine.

There are plenty of reviews of this and similar scopes around, so I won’t talk anymore about it. The biggest problem is where to park all the probes.

The Little Box

So what’s the other box? Well, it is hard to categorize. It is a power supply. But it is also a multimeter. It also has at least one other unusual feature for a power supply. The unit is the diminutive OWON SPM3103. There are several similar models that have different voltage and current capabilities and — for a power supply — none of them are inexpensive, but you can find them for just over $100 if you shop.

At first, it looks like the usual cheap power supply you see everywhere. However, it is quite different. It has a color screen. You can switch the screen to show the power supply output or use it as a bench meter. However, it is more than just a power supply with a meter jammed in.

There are several types of screens you can select using the buttons on the power supply’s front. You can, of course, display a standard power supply screen that shows volts and amps. You can set the voltage and the current limit, too. It makes sense, too, that you can select a meter screen that has a bar graph and 20,000 counts.

The meter has all the features you’d expect: autoranging (if you want it), continuity, capacitance, and a diode test. It also has hold and delta functions.

However, you can also select a screen that shows you both screens at once. There’s also a graph output that shows voltage and current from the supply over time which is handy.

There are a few other tricks. You can control the device via USB using SCPI. You can also save and load a few preset slots so you can’t switch between settings quickly. There’s also a ten-step memory that lets you define a “program.” For example, you might make step 1 start at 12V with a 5A current limit for 2 seconds to allow something with a high surge current to start. Then you could to 13.8V at 1A for the next 24 hours.

[Kerry Wong] reviewed a similar device in a video last year. You can watch it below. It works well, although the user interface takes a bit of time to get used to. There are a few quirks you can see in the video.

So those two boxes give you a capable bench in a very small space. Still plenty of desk space for a portable soldering iron, a device programmer, or a development board. Just to recap, the setup has a four-channel mixed-signal scope that can also act as a frequency counter, a spectrum analyzer, and it has a built-in signal generator. It also has a 20,000-count meter and power supply. There’s even a 1 amp USB power connector if you need it. Not bad for less than half of my credenza.

What else would you add to your ultimate tiny bench? If you have a Rigol scope like this one, WiFi is an option. If you want to orchestrate both instruments, you’ll need some SCPI skills. If you insist on using a laptop, there are plenty of multifunction boxes out there that can turn a computer into a reasonable test instrument.