Error message

  • Warning: count(): Parameter must be an array or an object that implements Countable in theme_table() (line 1998 of /data/
  • Warning: count(): Parameter must be an array or an object that implements Countable in theme_table() (line 2061 of /data/
  • Deprecated function: implode(): Passing glue string after array is deprecated. Swap the parameters in drupal_get_feeds() (line 394 of /data/
  • Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in menu_set_active_trail() (line 2405 of /data/

Bert Vermeulen's blog

A new, better Openbench Logic Sniffer

The venerable Openbench Logic Sniffer has long been a popular logic analyzer: it's cheap, capable and entirely open source. Unfortunately the project was abandoned long ago, so no new features were ever added. The one major problem with the OLS was always its limited available memory: it has no memory chip on the board, using only the small amount of memory available on the FPGA to store samples. Its slow, PIC-based USB interface made it impossible to use a streaming architecture, like the fx2lafw devices.

Enter the Saanlima Pipistrello: an inexpensive but very capable FPGA development board. It has a newer Spartan-6 FPGA, 16MiB flash, 64MiB DRAM and an FTDI-based USB interface. It also comes with lots of ports: HDMI, audio, Micro-SD, PMOD, and 48 GPIO pins in a Papilio Wing configuration. The board is completely open source: schematics and Eagle design files are available under the CC-BY-SA 4.0 license. The board itself sells for $155 at the Saanlima Store.

A buffer wing is also available. This protects the FPGA with 5V-tolerant transceivers. Highly recommended: I destroyed many unbuffered pins on my OLS board long ago.

The original OLS verilog code couldn't use DRAM for storage, so the Saanlima folks adapted it. Proper edge triggers were also added to the FPGA code, something that was cumbersome on the OLS. They also contributed a sigrok driver, which has been merged into libsigrok. Thanks, Magnus!

ELCE 2013 presentation and slides

If you were unable to attend the Embedded Linux Conference Europe 2013, a video of the sigrok presentation at the event is now available:

You can download the slides here.

Thanks again to Matt Ranostay.

sigrok at ELCE

The first conference presentation on sigrok is long overdue, but it's finally happening: Matt Ranostay is giving a talk at ELCE in Edinburgh, October 24-25. He will be giving an overview of the current state of the project. Thanks, Matt!

Quite a few sigrok developers will be at ELCE, and so we're also going to have a technical showcase stand, where we hope to demonstrate, among other things, PulseView's new integration with libsigrokdecode. If you're around, do drop by and say hello!

We'll also have a developer meetup, of course. We always have lots of designs in the planning stages, and getting together really helps to hash out the details. If you want to learn more about the internals of sigrok, or just have a say on where you want things to go, you're welcome to join us.

Collecting measurements

The collectd project is the de facto standard setup for server statistics: it grabs all kinds of local statistics (network counters, disk I/O, etc) and logs it locally or to a remote collectd, say on a dedicated statistics machine. It's a very modular system: everything is in plugins, including input sources like SNMP and OneWire. The default output plugin is the venerable RRDtool. This stores values and averages them over time, and creates graphs on demand.

Collectd has just released version 5.4, now with a sigrok plugin. That means any device which can be accessed via libsigrok can feed information to collectd, for storage and graphing with RRDtool or any other output plugin. This is intended for the many analog devices supported in libsigrok, not the oscilloscopes and logic analyzers of course.

These graphs were made using a CEM DT-8852 sound level meter and UNI-T UT325 thermometer:


These show my clunky old air conditioning unit adding a whopping 19 dB(A) to the noise level, and the effect that has on the temperature. I also watched a very loud movie with lots of explosions in the evening! Here's the collectd configuration that generated the above:

LoadPlugin "sigrok"
<Plugin "sigrok">
    LogLevel 3
    <Device "Sound level">
        Driver "cem-dt-885x"
        conn "/dev/ttyUSB3"
        MinimumInterval 1
    <Device "Temperature">
        Driver "uni-t-ut32x"
        conn "1a86.e008"
        MinimumInterval 1
What's obviously missing from the above is a measurement of the power usage of that air conditioning unit. I'm not sure I want to know...

Two Sound Level Meters

We now have support for two more sound level meters in libsigrok. Both can do live streaming, and do standalone logging for later retrieval.

First is the CEM DT-8852, a large handheld unit. It has all the usual features you'd expect in a sound level meter, and claims IEC 61672-1 Class 2 compliance. Particularly interesting is the fact that it can stream its dB measurements to the host at 20Hz; this sort of device generally streams at 1 or 2Hz.

The firmware is somewhat... temperamental. It was a particular challenge getting the driver to control settings on the device. The vendor software typically takes between 0.1 and 10 seconds before changing a setting actually takes effect on the hardware. The sigrok driver does considerably better: it's reliably under 1.5 seconds, and usually much faster. It all works very well now: the sigrok driver has workarounds for all known bugs.

The second new SLM driver is for the Kecheng KC-330B. It has a "USB stick" form factor, and so is intended mostly for standalone logging. It doesn't work very well: logging can only be started manually, by pressing the button, and even then it's not so sure to actually work. The sigrok driver only supports streaming from this device for that reason: the data logging functionality on the device is just too unreliable.

Releasing... everything

It's been a while since we last released a new version of libsigrok. A lot of work has gone into the library since then, but we somehow never got around to doing releases — there was always some major API change coming, or a driver that was nearly finished.

So here's a release now, and it's a good one. We're simultaneously releasing the following:

As announced earlier, libsigrok now supports analog sources, such as oscilloscopes. But this has actually led to many other classes of hardware as well, and we wrote tons of drivers. We've added support for the following:

Logic Analyzers



  • Hantek DSO-2090
  • Rigol DS1052D, DS1052E, DS1102D, DS1102E


  • Agilent U1231A, U1232A, U1233A
  • Brymen BM857
  • Digitek DT4000ZC/TekPower TP4000ZC
  • Fluke 187, 189, 287, 289 and the Scopemeter 199B
  • Mastech MAS345
  • Metex ME-31, M-3640D
  • PCE PCE-DM32
  • PeakTech 3410, 4370
  • RadioShack 22-168, 22-805, 22-812
  • Tecpel DMM-8060, DMM-8061
  • UNI-T UT61D, UT61E
  • V&A VA18B
  • Victor 70C, 86C
  • Voltcraft VC-820, VC-840

Sound level meters

  • Colead SL-5868P
  • Tondaj SL-814

Temperature, humidity and CO loggers

  • Lascar EL-USB (various models)
  • MIC 98581, 98583

All of these devices have their own page in our wiki, with full teardowns and protocol documentation. You can find an overview here.

Existing drivers have seen many bugfixes and improvements as well: check the NEWS file for details. There are also input modules for the VCD and WAV file formats, and an output module that pretty-prints analog output with appropriate units.

The commandline client, sigrok-cli, has been updated to deal with the analog devices, and has had an overhaul of the commandline options; this should make it a bit more intuitive to use. Check the man page for details and some examples.

The python decoder library, libsigrokdecode, now exposes decoder options to clients. There is also a new decoder for the Dallas DS1307 RTC chip's protocol.

Up until now, sigrok-cli has been the only officially supported sigrok client. That's changing: we're happy to announce that PulseView is getting its first release as well, and will be officially supported from now on. That means releases of libsigrok and pulseview will be kept in sync, with respect to API/ABI compatibility. We also enforce this in the git development repository. When PulseView gets support for protocol decoding, we'll keep it in sync with libsigrokdecode as well.

All four releases are considered pretty stable; we don't know of anything that crashes at the moment. If you find a bug, please take the time to post a bug report.




In order to better keep track of reported bugs and submitted patches, we've set up a bug tracking system:

Please use this to report bugs found in any sigrok project. Attached bugfix patches are most welcome, of course, as are patches that add a new feature. However, feature requests should be directed to the mailing list or IRC channel. We want to keep the list of open bugs as small as possible.

A matter of parsing

Supporting a new piece of hardware in sigrok entails writing a driver for libsigrok. As a bare minimum, the driver consists of a C source file with a struct sr_dev_driver in it. That struct contains the name of the driver and a set of callbacks libsigrok will do when that driver is used — things like initializing the device, starting acquisition and so on. libsigrok provides an internal API which drivers can use to send data across the "session bus" — something which the frontend application listens on.

However, writing code is the last thing you do. When you get started, first make a page on the wiki for that device. Check out the page for a similar device, and copy its source over. This will get the page structure and categories down. Take some pictures of the device, particularly of the insides. It may well help you with the driver later on. Some guidelines for taking good PCB pictures are here.

Next, take a look at the protocol. Generally this involves running a copy of Windows in a VM (Virtualbox or VMware will do nicely) on a Linux host. When you use the device through the vendor-provided Windows software, you can sniff the USB (or whatever) traffic on the Linux host. There are many techniques to reverse engineering protocols, but essentially it involves staring at hexdumps until you understand the connection between what the vendor software sends to the device, and what the device does in response.

Whatever you find out about the protocol, document it! You want to be able to pick up where you left off, even if there's a couple of weeks between working on this. By all means, use the wiki page you created as a working document — it's not just a place to put finished protocol docs. If you get stuck, somebody else might see something in your notes that you missed.

For some devices you might even skip the VM + Windows step. Some low-end multimeters and other measurement devices don't really communicate with the vendor software: they just send data out periodically — usually a few times per second — and don't even have an input channel on which to take commands. These are generally devices with a keypad or similar controls, and a display. By simply listening to what it puts out, verifying this against what you see on the display, and putting the device through its various modes and options with the controls, you have everything you need to grok the protocol.

Once you're satisfied you've got the whole protocol documented, it's time for the driver. Creating the driver's various source files and integrating it into the build is quite a bit of work, and requires a lot of fiddling around with autotools. So to make things easier, we have a tool to do all this for you. It's called, unsurprisingly, "new-driver", and can be found in the sigrok-util repository.

Clone the repository, and run it from the source directory:

$ git clone git://
$ cd sigrok-util/source

Let's say your device is called the "Magic Widget S15". Invoke new-driver like this:

$ ./new-driver Magic Widget S15

This will show some output as it works, and leave behind a single file when it's done: 0001-magic-widget-s15-Initial-driver-skeleton.patch

Apply this to your libsigrok tree:

$ cd /path/to/libsigrok
$ git am /path/to/0001-magic-widget-s15-Initial-driver-skeleton.patch

That's it! The configure script will now know about your new driver, and doing the usual configure/make steps will build it. You'll find it in your source tree in the hardware directory:

$ ls -l hardware/magic-widget-s15
total 16
-rw-rw-r-- 1 bert bert 3692 Nov 13 02:49 api.c
-rw-rw-r-- 1 bert bert 1035 Nov 13 02:49
-rw-rw-r-- 1 bert bert 1157 Nov 13 02:49 protocol.c
-rw-rw-r-- 1 bert bert 1919 Nov 13 02:49 protocol.h

The file api.c contains the struct sr_dev_driver which registers it with libsigrok. An overview of the struct and the callbacks it contains is on the hardware driver API page. All the callbacks have a stub function in api.c, with a TODO comment marking the spot where you come in. Take a look at another driver for a similar device to see how various callbacks might be implemented. The protocol.h file is included from both C files, and contains mostly the device context struct. This is specific to your driver, not shared across libsigrok. The protocol.c file is where you implement the protocol parser for your device. It has a single stub function defined:

SR_PRIV int magic_widget_s15_receive_data(int fd, int revents, void *cb_data)

This function gets called whenever your device sent some data. The stub grabs your device context, which will have a device handle you can use to read the data and send libsigrok the results.

Everything else is just a matter of parsing.


Since the sigrok project started, we’ve focused on logic analyzers. They were the initial inspiration for the project, and were at that time just getting affordable — at least compared to the bad old days when such gear cost thousands of dollars. Since then, prices have continued dropping and capabilities have increased; the Openbench Logic Sniffer is just $50, and will happily sample at 100MHz. Cheap FX2-based boards can be had for as low as $15. But logic analyzers were never the limit of our ambition. sigrok groks your signals for you — ALL your signals! We consider any kind of test and measurement equipment in scope of the project; if it can be queried or controlled, we’ll take it on.

To that end, we’ve recently merged in support for processing analog data, as well as the first driver using it. The driver is hantek-dso, and supports the Hantek DSO-2090 USB oscilloscope. It’s part of a series of five similar models, all of which we plan to support. The only output module supporting analog data for now just outputs voltage levels as text, suitable for importing into other tools.


Capture from a DSO-2090, before postprocessing, as plotted by qtiplot

We will, of course, also support saving analog data in .sr files. If you know of any other file formats that are commonly used for transferring oscilloscope output, do let us know! We’re always happy to put it on our TODO list, and even happier to take patches.

We also have a Hantek DSO-5200A, a higher-end model in the same series, so it will be supported quite soon. We can’t buy every device out there, however, so we will need help if we’re going to support the DSO-2150, DSO-2250 and DSO-5200. If you own one of these, you can help! Opening up your device and taking pictures of the internals for the wiki is already a great step forward; helping us to test the driver on a model we don’t own ourselves is even better.

Detailed pictures of the PCB and components should also help us to determine what exactly the difference is between these models. We know the 2xxx series share the same firmware and most of their specifications, for example, so the difference is likely in the analog frontend only. But is it possible to do a simple upgrade from one model to another? This is not unheard of; in the case of the Rigol DS1052E and the Hantek 5062B bench oscilloscopes the hardware is identical to higher-end models.

Next on the agenda are drivers for the Link Instruments MSO-19 and the PoLabs PoScope. The MSO-19 in particular is a very popular device, and both are interesting for us in that they’re Mixed Signal Oscilloscopes (MSOs): they can output both analog and digital signals. We can handle both separately, but getting them at the same time — and keeping them in sync — is another challenge entirely.

Several of the FX2 boards we support also have analog frontends; we plan to add support for these to the fx2lafw firmware and driver both.

We’re also in the planning stages of support for other devices that output various kinds of analog data. More on that later, watch this space!

About fx2lafw

At the end of May we released libsigrok 0.1.1. It had various fixes and improvements, but the main reason we released it was to get a release out the door before merging in the work on analog data I’d been doing in another branch.

But there was one major feature in that release which I think deserves a bit more attention. It was the first time we’ve included a driver that communicates with a device which runs firmware we ALSO wrote. This firmware is called fx2lafw, and I think it’s absolutely fantastic.

The all singing, all dancing FX2

Some of the first generation of inexpensive logic analyzers, i.e. within reach for non-megacorporation budgets, were the CWAV USBee SX and the Saleae Logic. That is to say, they’re under $200. But when you look at what’s inside, as we inevitably do, it becomes apparent that there’s really very little there. Essentially, these boards are based on a Cypress EZ-USB FX2LP chip — the FX2, for short — and a small number of components to support it. The FX2 is a generic USB interface chip, based around an 8-bit 8051 microcontroller core. It runs quite slowly, nowhere near enough to keep up with a modern high-speed USB bus. But it has some built-in peripherals which allow it do fully automated transfers from GPIO pins to the USB bus, without ever touching the 8051 core. You basically tell it which pins to sample, and which USB endpoint to send the results to, and off it goes — leaving the CPU core idle. This feature is intended for transferring data from external devices, such as hard disks, onto a USB bus.
A Cypress FX2 chip
But of course that data doesn’t have to come from a device that’s getting clocked to send data to the FX2. It takes whatever appears on the digital I/O pins, which is what a logic analyzer does. So this can be used as a simple single-chip logic analyzer. There’s a bit more to a full product than that, of course — you have to provide some sort of analog frontend, probes, a USB connector, and an enclosure. You’d also have to invest in a website/store, arrange manufacturing, and provide support. But you could sell it without all of that if you really wanted to provide something cheap that will mostly work. Enter the Chinese clones.
If you pare it down to its bare essentials, the FX2 needs an 24MHz oscillator, a small EEPROM chip, a USB connector and a few passives. Connect your own probes to broken-out GPIO pins, and you have a basic logic analyzer. So that’s what happened: various FX2 boards started showing up on Taobao, Alibaba and Ebay. There are well over a dozen different designs, some for as low as $15. Some of the clones appear to be copying other clones.
Writing logic analyzer software is not so quickly done however, as we’ve noticed here at sigrok. These people aren’t exactly going to spend the time and effort to write great software for it; so they just sell it as “Saleae/USBee compatible”, and tell you to go download software from those companies. That’s not only the PC software, but also the firmware for the FX2, which that software talks to. It’s fundamentally wrong, of course. You might make an argument that if a bare-bones FX2 board will do the job, there’s nothing wrong with making them cheap and shovelling them out the door via Ebay. But using somebody else’s firmware and software without permission is not OK.

Doing the right thing

We’ve long supported the Saleae Logic in sigrok of course; it was our very first driver. But we used the Saleae firmware. We couldn’t distribute it legally, so we published a procedure that showed people how to extract the firmware from their own, hopefully legal, driver installation.
That’s fine as it goes, but we thought we could do one better. This is where fx2lafw comes in. It’s firmware for the FX2, written from scratch, that implements the automatic sampling mode. It uses our own protocol, and communicates with our own driver, and is 100% free and open source software. It was very much a team effort: the firmware was written jointly by Uwe Hermann and Joel Holdsworth, and the sigrok driver it talks to is based on my original Saleae driver.
The fx2lafw page on the wiki currently lists some 37 FX2-based devices we know of. We've verified many to work with fx2lafw, but we know the rest will work as well. If you have one that's not listed as 100%, please do try it out and let us know!
Some of the clone makers are already linking to sigrok; we’d like all of them to do that. If and when we get a good logic analyzer GUI for sigrok, we hope they’ll stop the shenanigans altogether. But the most important thing is that you can now have a very inexpensive basic logic analyzer that uses only 100% free software. And that is a good thing indeed.
Subscribe to RSS - Bert Vermeulen's blog