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!

Norma DM950 support

We're happy to announce that libsigrok now supports yet another multimeter, the Norma DM950 (a.k.a. Normameter 950, a.k.a. Siemens B1028).

This is a 21000 counts autorange DMM with RS232 connectivity.

Many thanks to Matthias Heidbrink for writing the driver and figuring out the protocol! As always we have a nice wiki page for this device now, including teardown photos, protocol description, and so on.

The DMM uses a custom microcontroller internally, and the protocol is a SCPI-like ASCII based protocol with the familiar-looking "IDN?" strings and so on. Please also check the driver source code if you're interested in the details.

There are various other DMM models from this series which can be supported relatively easily via this driver. Please contact us (and/or the driver author, "mh") in the #sigrok IRC channel on Freenode if you own one of these devices and can test further patches. Thanks!


New protocol decoder: parallel

libsigrokdecode now supports a new protocol decoder (PD) named parallel.

This PD can decode various simple synchronous, parallel buses that have one clock line and a (pretty much) arbitrary number of data lines.

The decoder can be configured to sample the data lines (e.g. D0-D3 for a 4-bit sync parallel bus, D0-D7 for an 8-bit bus, or D0-D31 for a 32-bit bus, and so on) on either the rising or falling clock edge.

It can then print the data in various formats (currently only 'hex' is supported, but more can be added easily), e.g. 0x55 for an 8-bit bus or 0x55667788 for a 32-bit bus, and so on.

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.

sigrok + UNIX = Awesome! - part II - Audio

So today I have another example of the powerful ways sigrok-cli can be used, this time with digital audio.

In the modern world there are a wide variety of devices that handle digital audio internally including HiFi equipment and mobile phones. Common signalling schemes include S/PDIF, and various clocked serial PCM schemes. I²S is a specific variant of PCM signalling. It has 3 signals: Clock, Word Select (which signals the beginning of sample words for the left or right channels), and Data which transmits the audio samples MSB first.

sigrok has had support for I²S decoding for a while, and now in the latest Git builds of PulseView, it's possible to see the decode results. This example was taken from the 32-bit I²S example in the sigrok-dumps repository.

But once again thanks to the power of UNIX, sigrok-cli is the far more powerful tool, because it allows us to do interesting things with the decoded information.

The basic syntax for I²S decoding is as follows:

$ sigrok-cli -i -P i2s:sck=0:ws=1:sd=2 -A i2s=right

i2s: "Right channel: f6780000" "Right: f6780000" "R: f6780000" "R"
i2s: "Right channel: f4b80000" "Right: f4b80000" "R: f4b80000" "R"
i2s: "Right channel: f3ac0000" "Right: f3ac0000" "R: f3ac0000" "R"
i2s: "Right channel: f3060000" "Right: f3060000" "R: f3060000" "R"

Here 32-bit samples are being printed for the right channel only. In itself this is very cool, but we can go much further.

The next step is to extract the data as binary.

sigrok-cli -i -P i2s:sck=0:ws=1:sd=2 -A i2s=right | \
    cut -c22-25 | xxd -r -p > file.bin

The cut command strips all the text except for the 4 most significant hexadecimal nibbles, and in the same way as in the previous blog posting, we use xxd's reverse mode to convert this hexadecimal data to binary.

We now have a binary dump of the PCM data for the channel.

But I want more.

The SoX suite has some really handy tools for manipulating audio, and we can use these tools to convert the audio to a WAV file.

sigrok-cli -i -P i2s:sck=0:ws=1:sd=2 -A i2s=right | \
    cut -c22-25 | xxd -r -p | \
    sox -t raw -B -b 16 -c 1 -e signed-integer -r 16k - right.wav

Here we tell sox that it will receive a raw data stream, containing big endian, 16-bit, signed integer mono audio at 16kHz sample rate, and that it should output the data to a wav file.

Opening the wav file in Audacity, we can see the decoded analog waveform:

...or we can use the sox play tool to play the audio directly out of the headphones:

sigrok-cli -i -P i2s:sck=0:ws=1:sd=2 -A i2s=right | \
    cut -c22-25 | xxd -r -p | \
    play -t raw -B -b 16 -c 1 -e signed-integer -r 16k -

I've never had the chance to try it, but I really want to see if it's possible to do this in real time on a live device.

At this time, it will be a tall order to ask this of libsigrokdecode, but it may nonetheless be possible. It would require a logic analyser capable of continuous streaming, such as the FX2 family of devices, and the I²S logic data would need to be acquired at the lowest possible sample rate without aliasing. If the logic data is captured at a higher sample rate, libsigrokdecode stands no chance of processing all of it.

There is some talk of various ways we can make great increases to libsigrokdecode's performance, so in the future this type of realtime activity should be rather easier to do.

sigrok + UNIX = Awesome!

I've decided it's time to start blogging about the power of sigrok when used together with all the other tools on a typical UNIX machine. This sort of thing usually wouldn't be documented, because it's not really sigrok functionality, but for me these are the most powerful tricks of all.

Here's an example...

Example I - LogicPort BitBanging

Lee Jones has recently started working on a driver for the Intronix LogicPort. The original manufacturer has declined to provide any documentation about the protocol, so Lee has been working hard on reverse engineering it.

The LogicPort internally consists of a Altera EP1C4F324C6 FPGA, with a FTDI FT245BL USB interface.

For USB devices, our typical workflow is to run the vendor software inside a Windows VM and setup a USB passthrough. Then, in the Linux host machine we use usbmon (sometimes via Wireshark) to inspect the packets sent and received. To implement a driver, the developer must then try to replicate this protocol in the driver.

Lee discovered that early in the process of initialising the device, a large block of binary data is sent by the PC to the device. This is a hexadecimal dump of just the beginning part of the packet:

05070507 05070507 05070507 05070507 05070507 05070507 05070507 05070507
04060507 04060507 05070507 04060406 05070507 04060406 04060507 04060507
04060406 05070507 05070406 04060406 04060406 05070507 05070406 04060406

We suspected that this data is actually being used to cause the FTDI chip to bit-bang an SPI waveform to configure the FPGA. But how can we get more clarity? Answer: with sigrok.

  • First we need to convert this hexadecimal data to binary. xxd has a handy reverse mode that can input hex, and output binary:
    • xxd -r -p dump.txt > dump.bin
  • PulseView has basic support for importing binary data; currently it will assume any file ending in .bin is 8-probe logic data. Opening the file in PulseView, we can see the waveform clearly:
    PulseView now also has very basic support for protocol decoding, which allows us to see the bytes of SPI data.
  • Pretty though PulseView decoding is, sigrok-cli is actually more powerful in the end, because with sigrok-cli we can extract the actual bytes from the SPI data stream. Currently sigrok-cli has some problems with its binary input module (these are being addressed in bug #166), so this has to be done in two steps:
    • First, convert the binary data to a sigrok session file:
      • sigrok-cli -I binary:numprobes=2 -i dump.bin -o
    • Second, do the decode from the session file:
      • sigrok-cli -i -P spi:mosi=0:sck=1
      • Data is decoded:
        • spi: "FF/1FFE"
          spi: "FF/1FFE"
          spi: "5C/1FFE"
    • Finally we can use some UNIX magic to extract the firmware binary:
      • sigrok-cli -i -P spi:mosi=0:sck=1 | cut -c7-8 | xxd -r -p > firmware.bin
      • (One day sigrok-cli will acquire a feature to decode directly into binary, but for now this pipeline works fine)

I think this stuff is really cool. I'm out of time for now, but I'll try and write up some more examples in following posts.


Subscribe to RSS - blogs