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/


Windows support and installers

For a long time Windows support in sigrok was somewhat lacking and/or in the TODO state, but things have improved quite a bit recently.

While there have been both a working cross-compile setup based on MinGW (additionally based on the MXE suite of scripts) as well as working NSIS-based installer executables for sigrok-cli and for PulseView for quite a while, they weren't really all that useful.

Only very few devices used to actually work in practice due to portability issues and due to certain limitations in the way libsigrok was talking to USB-based hardware devices (e.g. various logic analyzers) and serial port based devices.

All of this has changed though. A major part of the solution and fixing was done by Martin Ling (thanks a lot!) by writing specific thread-/Event-based code for the Windows platform for allowing libsigrok drivers based on libusb to properly work on Windows (transparently, i.e. without requiring changes to the drivers).

The other part of the puzzle is the new LGPL3+ libserialport shared library, also written by Martin Ling (thanks again!), which is a portable, cross-platform C libary (that is completely independent of libsigrok, i.e. it can be used by various other open-source projects without any problems, too). So far, it supports Linux, Windows, Mac OS X, and some BSDs. More on libserialport in another blog post.

With all the above-mentioned improvements we're now providing daily-built, self-contained Windows installers for sigrok-cli and PulseView, that ship with everything you need (the executables and libraries, the protocol decoders, some firmware files, some example files you can use for testing decoders and UIs, the Windows Python 3 installer you need for running protocol decoders, the Zadig tool you need for switching devices to use the libusb driver, etc. etc.).


Please make sure to read the Windows wiki page, it contains some more information related to drivers, firmware files, current device status, and so on.

We've tested the basic functionality on Windows XP and Windows 7 (and we don't expect any issues on Windows Vista or Windows 8 either), but we're happy to hear any feedback you may have and/or issues you might encounter.


New protocol decoder: ir_nec

We're happy to announce that libsigrokdecode now supports yet another protocol decoder, this time: ir_nec. The PD has been contributed by Gump Yang, thanks a lot!

This is a decoder for the so-called NEC infrared (IR) protocol, a rather widely used protocol for remote controls (for TVs, VCRs, and lots of other things).

The protocol is based on a pulse-distance encoding, i.e., a 1 bit is encoded by a pulse and a long pause after that, and a 0 is encoded by a pulse and a short pause after the pulse.

The "payload" basically consists of an 8-bit address (which is a number that is supposed to be unique for a certain vendor / device), and an 8-bit command / code which identifies which button was actually pressed.

The 8-bit address is followed by the inverted 8-bit address, the 8-bit code is also followed by its inverse. This is (or can be) used for error checking on the receiver side.

You can read up on the protocol details in various online resources.

When the proper definitions for specific remote controls are added to the PD, it can also decode the actual remote control button in a more human-readable form e.g. "Matsui TV: Mute" vs. "Address: 0x40, command: 0x10", see screenshot for an example.


Brymen BM869 support

Yes, it's time for another multimeter! This time libsigrok has gained support for the Brymen BM869 multimeter (the code was written by Aurelien Jacobs, thanks a lot!).

This is a 50000 counts True RMS DMM with various "higher-end" features compared to other, cheaper DMMs.

The PC connectivity interface Brymen BU-86X is using USB/HID internally (based on the Cypress CY7C63743 enCoRe USB chip), the protocol is relatively simple and documented by the manufacturer.

You can also browse the source code if you're interested in some of the implementation details.


New protocol decoder: rgb_led_spi

We're happy to announce that there's a new protocol decoder available in libsigrokdecode since today, rgb_led_spi (thanks to Matt Ranostay for the contribution!).

This is a small PD that decodes RGB (red/green/blue) values for a certain type of LED controller that are sent from a host/microcontroller via SPI in order to light up the LEDs in a certain color.

It can be used for decoding data to a WorldSemi WS2801 RGB LED controller, for example (see the led/ws2801 directory in the sigrok-dumps repo for sample files).

Since this (rather simple) "protocol" is transmitted over SPI, the protocol decoder can make use of the stacking feature in libsigrokdecode and simply stack upon the spi decoder (thus avoiding having to re-implement all of the SPI handling in the RGB LED decoder itself).

Happy LED blinking!

Gossen Metrawatt Metrahit multimeter support

A few weeks ago libsigrok received support for various Gossen Metrawatt multimeters, a line of DMMs we didn't yet support at all.

The respective gmc-mh-1x-2x driver (for the Gossen Metrawatt Metrahit 1x/2x series multimeters) was contributed by Matthias Heidbrink (thanks a lot!).

It already supports a number of devices, e.g. the

Other devices are already being worked on, and/or can be added to the driver by interested users (patches welcome!).

The driver was tested with the Metrahit RS232 PC interface, support for other interfaces may follow (again, patches and people who can test with these interfaces are highly welcome).


jhol's sigrok year in review (and 30c3)

Happy New year - 2014! I was barely used to the idea of 2013! - where does the time go?

So I decided it's time for a quick roundup of the year from my own very personal perspective.

Project Status

By any measure, 2013 was a great year for sigrok. The project has grown to over 100kLOC and the number of contributors is growing steadily. Last month was the project's best ever month for contributors - with 12 different people contributing code.

For me it's been particularly heartening to see that many people are interested in contributing. Some have come to provide whole drivers, others providing major features, others contributing all kinds of tweaks and bug fixes. It's great to see the people think that sigrok is a project worth giving their time to. There is even now a commercial fork of sigrok by the DSLogic team.

This year Uwe and Bert continue to be the commit-count-kings building features at all levels of the stack.

In recent months Martin Ling has provided a fresh burst of energy adding the libserialport library and writing drivers for many (all?) Rigol oscilloscopes.

In April we had the first ever PulseView release.

I'm really glad we reached this milestone, because there have been some false starts on the sigrok GUI front. I was keen for the project to get to the point where it was very basically usable. I absolutely did not want to add another tombstone to a graveyard of dead sigrok GUIs. Therefore, v0.1 was not meant to be anything very special, just enough to "close the loop", and provide a basic minimal, not to buggy GUI for sigrok.

Now that this has been achieved, I have been able to add some more exciting features to the project - most notably support for sigrok signal decoding.

PulseView pulseview-0.1.0-195-gdfb9f75 with mixed-signal data, and decoding.

Because of Martin's recent work, there is agreement that we need to make an all-sigrok release as soon as possible. However, PulseView decode support still has some way to go. Therefore, as a compromise I've decided to make decode support a compile-time option in v0.2, which allows fans of the bleeding edge to test this code, but without compromising the overall quality of PulseView in this release.

Once the release is done, I hope decode support will be completed within a short time, and then we can release PulseView v0.3 with the feature enabled.

PulseView is in reasonably good shape, but it's still quite small, and progress is slow. 12 people have contributed to the code in the last year, but I remain by far the largest contributor, contributing 79% of commits in the past 12-months. Some have said that they find the C++ rather impenetrable, but my hope for 2014 is that we broaden out the contributor base so that the project is not so dependent on one person.

It is now easier than ever to contribute to PulseView. I always find GUIs are particularly difficult to design by committee, but once there are some coherent concepts in place, it is much easier for people to understand how their feature should fit into the general scheme of things.


Many of the regular contributors to sigrok, including myself, met at 30c3 in Hamburg for four days of intense sigrok hacking. For me this was my first time to visit the conference, and my first time to meet many of the guys who I've been working alongside for the past two years.

The Sigrok Table at 30C3

We were extremely busy. There's nothing quite like face-to-face meeting to tackle large scale design questions, so much of the time was spent in design meetings trying to bash things out - which to my surprise was quite fruitful, resolving many of the big questions. Whether these ideas ever become code remain to be seen.

Walking round the conference there were a couple of cases where people were using sigrok to solve actual problems. Uwe met a team of guys investigating network controller backdoors, using sigrok to collect SPI data - this without any of us telling them to use the project.

Most of the time was spent working on the code. We hoped to complete the release during the conference. We didn't quite reach this goal - but we are very close. Therefore hopefully there will be a sigrok release within the next couple of weeks.

Finally, I have news that the sigrok project has made the news - specifically Aljazeera TV. The piece is mostly about NSA surveillance, but watch carefully at 0:13 to see a nice sweep of the sigrok table - with some guy, but I don't know who he is.

Hameg HMO scope support and SCPI backend code

The list of contributed hardware drivers for libsigrok is getting longer yet again. This time, support for the Hameg HMO series oscilloscopes (tested on Hameg HMO1524) has been added by poljar (Damir Jelić), thanks a lot! It has recently also been successfully tested on a Hameg HMO2024 at 30C3 in Hamburg.

This driver should support the Hameg HMO compact series device (70MHz - 200MHz) for now, other devices can be added later though. It also makes use of the recently added probe groups feature to allow setting coupling, trigger slope, timebase and so on independently for each scope channel. Currently the driver supports the serial port connectivity of the scope.

Since SCPI commands are used for controlling and querying the scope, poljar also added an initial set of common SCPI related functions to libsigrok, which other drivers can also make use of later. Those functions initially assumed a serial port transport, but have been made more generic in the mean time by Martin Ling (thanks!), now supporting SCPI over USBTMC and SCPI over TCP too.

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.

Probe groups support

libsigrok has gained a long-overdue feature recently: support for so-called probe groups.

Until now, various config options for drivers have always applied to all probes of a device. For example, on a 2-channel oscilloscope like the Rigol DS1052E you could set e.g. the "Volts per division" config option to a certain value (say, 2V). However, the setting would always be applied to all probes (i.e., both channels of the scope). It was not possible to set different values for each individual probe.

The new probe groups feature (via the respective API changes in the drivers and libsigrok backend code) allows each driver to define groups of probes that have the same properties and the same settings. This applies to all kinds of drivers/devices (not just oscilloscopes), including multimeters, logic analyzers, MSOs, thermometers, and so on.

The following example sigrok-cli call will change the V/div setting on a Rigol DS1052E scope to 2V, but only on the "CH1" probe group (which happens to only contain one probe, the first channel of the scope):

 $ sigrok-cli --driver rigol-ds1xx2:conn=/dev/usbtmc0 --probe-group CH1 -c vdiv=2V --set

It does not change the V/div setting of all other probe groups (i.e., the second channel of the scope in this case).

Thanks a lot to Martin Ling for coming up with the proposal for probe group support in libsigrok, as well as the initial implementation!

So far the rigol-ds1xx2 driver has been converted to actively use the new probe groups feature. Various other drivers will follow over time.

libsigrok 0.2.2 released!

Hi everyone!

We're happy to announce the release of libsigrok 0.2.2! This is a minor bugfix release without any API changes, but it also adds support for a few new devices.

We added support for one new logic analyzer in this release, the Saleae Logic16. This is a streaming 16-channel device with a max. samplerate of 100MHz (when 3 channels are used; lower samplerates must be used if you use more channels). The driver was contributed by Marcus Comstedt, thanks a lot! You can use the sigrok-fwextract-saleae-logic16 tool from our sigrok-util repository to extract the required bitstream and firmware files from the vendor software.

We now also support a few more multimeters (all of them with RS232 connectivity):

And two new thermometers (temperature dataloggers):

  • UNI-T UT325, a 2-channel temperature logger with USB connectivity
  • Center 309 (a.k.a. Voltcraft K204), a 4-channel temperature logger with RS232 connectivity

Finally, the first "device" in the "Energy meters" category that we support: the EDF Teleinfo (thanks Aurelien Jacobs!). This is not a specific piece of gear per se, but rather a standard protocol that is used for energy metering purposes in France.

Apart from the expanded device support, there is also the new csv input module (file format), thanks Marc Schink! That means you can now read logic analyzer data from various CSV-like files into libsigrok (and then do everything with that data you can do normally, e.g. convert to other formats, display, run protocol decoders on it and so on).

There have also been a number of improvements and fixes for various drivers (e.g. uni-t-dmm, ols, rigol-ds1xx2, agilent-dmm) and some random bugfixes and portability fixes in the rest of the code. Feel free to browse the NEWS file or git log for the details.

You can download the libsigrok-0.2.2.tar.gz tarball from as usual.

Have fun!


Subscribe to RSS - blogs