GlScopeClient: A Permissively-Licensed Remote Oscilloscope Utility

One of the most convenient things about modern digital oscilloscopes is that you can access the recorded data on a computer for later analysis, advanced protocol debugging, or simply the convenience of remote capture. The problem is that the software isn’t always ideal. Vendor-supplied utilities are typically closed-source and they try to nickel-and-dime you for every a-la-carte protocol and/or feature. The open-source options come with their own issues, from performance-limiting designs, to incomplete features, to license constraints. Faced with these issues, [Andrew Zonenberg] decided to take matters into his own hands and create glscopeclient, a permissively-licensed open-source remote oscilloscope utility.

The eventual goal is to allow you to do remotely anything you would normally do using the scope’s front panel, plus capture and analyze data on the computer side. The code uses a modular architecture that allows for various backends to talk to different scopes. At the moment, the only backend fully implemented is for LeCroy scopes, although this is enough to demonstrate the power of the idea. The obvious “gl” in the name gives away the secret — the code uses OpenGL for rendering, which allows for some very fancy graphics at high frame rates.

Behind the slick look, however, are some serious debugging tools. Protocol analyzers include USB, UART, JTAG, eye pattern analysis, plus FFT-based spectra with waterfall displays. The code is in GitHub, and most of the announcements and discussion seem to happen on [Andrew]’s twitter account, which you can follow @azonenberg. It’s a work-in-progress, but a serious one, and something we’re going to keep our eyes on.

You can check out a video of the program after the break.

Now, if you want to literally talk to your oscilloscope, we covered that, too.

24 thoughts on “GlScopeClient: A Permissively-Licensed Remote Oscilloscope Utility

    1. What would you prefer? To get the performance I’m targeting, you need to get pretty low level.

      The LeCroy and other current backends are limited by the scopes, but once I start adding custom acquisition hardware to the stack I’m planning to target tens of thousands of WFM/s. You’re not going to get that kind of performance with something ilke Python.

      1. I was thinking C or Assembly. :^| C++ seems like can be easier since more libraries available and not the translation runtime mess.

        I know I’ve been hesitant to learn Python since I left off with being annoyed the version of MATLAB wasn’t able to convert into C as previous version can, or into C++, to get rid of the MCR. Then again some might have been pissed or insecure I used Espresso and not Meth and wanting to parallel process to improve development performance since 3rd shift had free processors to use and manually running experiments wasn’t my cup of tea. The closest I got to programming in Python was looking into Python to C/C++ code converters.

        Neat application and looking forward to see how can interface with the TDS-XXX family and wondering if there might be shortcuts in development decompiling the TDS-XXXX related aps.

        1. Everyone knows, that if you want performance, you go with Java, not slow languages like C/C++ or ASSembly.

          All you need is a few cores [ as few as 4 ] , a few GB of RAM [ as little as 16 ], and just a few hundred GB for helper libraries, and you are all set.

          Once booted, the application gets Faster! A boot time of just a few mintues is normal!

        1. There’s a WIP Rigol driver already. Right now it’s mostly read-only: you can view waveforms and do all the usual analysis, but changing most settings like channel coupling or trigger mode has no effect. No technical roadblocks to full support, just a matter of finding time in my busy schedule to implement.

          As far as Siglent stuff goes, the ones I’ve got my hands on to date seem to be very similar to the LeCroy SCPI command set. A friend of mine is working on a SDS1204 (LeCroy WaveAce based) driver which needs to override a handful of functions from my existing LeCroy driver to work around firmware bugs. The SDS3000X is basically a WaveSurfer 3000 series scope which is supported by the existing LeCroy driver – while I have not tested the Siglent badged version I expect it to work fine.

          1. To clarify, the WIP Rigol driver is for the DS1100Z series and only supports Ethernet transport, although USB/RS232 could be easily added if there was demand from users. I haven’t used enough other Rigol hardware to know how similar the command sets are between models.

          2. USB support would certainly be nice, as it seems that the USB interface in DS1054 is much faster than Ethernet. I’ve tried doing “streaming” from the scope by taking lots of screenshots, and I’ve got much higher frames per second with USB.

  1. Also for anyone planning to fool around with the tool – you probably want to grab scopehal-cmake which is the master repo that pulls in this one plus the drivers, protocol decoders, etc from their own repos. scopehal-apps by itself isn’t much use.

    1. Couldn’t get it to build using scopehal-cmake on mint linux. Once I got past the sub module publickey problem, the build failed when compiling the scope window object complaining about no default constructor for Gtk::RadioMenuItem. Will try again later. Thanks.

      1. What gtkmm version were you using? I do most of my development on Debian Stretch which has 3.22.0-1.

        It looks like the default constructor for Gtk::RadioMenuItem was added in 3.22 so if you have older that might be a problem?

    1. Definitely looks like it could be made to work. I have a ticket on the Github repo for R&S support already but don’t have access to any hardware for testing.

      Do you have access to an RTM3000 that you could arrange for me to get remote access to? Access to hardware is the biggest holdup for new hardware support. I run a 100% LeCroy shop and a friend offered me VPN access to her Rigol so that’s the current test setup.

  2. “One of the most convenient things about modern digital oscilloscopes is that you can access the recorded data on a computer for later analysis, advanced protocol debugging, or simply the convenience of remote capture. ”

    Missed opportunity for a reading list demonstrating such.

    1. Sigrok is GPL and my tool is permissively licensed, so linking to sigrok is a no-no.

      My architecture is also a lot more flexible than theirs WRT driver support which means things aren’t necessarily directly compatible. For example, I allow instruments that do run-length encoding of samples, or instruments where different channels have unequal sample rates.

    1. Create a new class deriving from SCPIOscilloscope (or the base Oscilloscope class if you have some oddball/super optimized hardware that doesn’t use SCPI) and implement all of the virtual functions.

      If you want to discuss in more detail hop in #scopehal on Freenode IRC?

  3. This is excellent! My old oscilloscope is soon due for replacement, and am going to make sure the next one is supported by this project. What do you recommend? 4 ch and 500MHz meets most of my needs.

Leave a Reply to Andrew Zonenberg Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.