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/


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.

ISO-TECH IDM103N‎ multimeter support

Thanks to Aurelien Jacobs libsigrok now supports a new multimeter, the ISO-TECH IDM103N. This is a 4000 counts DMM with RS232 connectivity.

The respective patch for enabling this DMM also adds a generic es519xx.c parser (based on the old es51922.c which will be obsoleted soon), which should be able to handle various Cyrustek ES519xx DMM ICs. That'll make it easy to add more DMMs using one of these Cyrustek chips later.

Another new thing in libsigrok is the SR_UNIT_REVOLUTIONS_PER_MINUTE (RPM) unit, which allows us to properly support the DMM's RPM feature.

Saleae Logic16 support

We're happy to announce that libsigrok now supports the Saleae Logic16 logic analyzer.

This is the successor product of the well-known Saleae Logic (an 8-channel logic analyzer with a max. samplerate of 24MHz and streaming capabilities).

The Logic16 has 16 channels and can sample at rates of up to 100MHz, depending on the number of channels used. If you only need 3 channels you can sample at 100MHz, or 50MHz for 6 channels, or 32MHz for 9 channels, or 16MHz when using all 16 channels.

The property of the Logic16 that makes it really interesting is that it can still stream out the data live over USB (like the Logic) and is thus not limited to any internal buffer size of the logic analyzer itself, while at the same time allowing a samplerate higher than 24MHz. This makes it possible to capture fast signals for longer periods of time (as opposed to just a few milliseconds as is the case for many other devices) which can be very useful in practice.

It also has the advantage that you can switch between two different voltage threshold settings, allowing you to debug either 1.8V / 3.3V systems, or 5V systems.

Of course it still has the same limitations as the Logic, too. Whether the continuous byte stream from the Logic16 can be received quickly enough over USB without missing any bytes depends on various random factors, such as the USB controller in your PC, the OS/kernel version used, the amount of other USB devices connected and how much data those transfer at the same time, etc. etc. But still, for many cases it works well enough to make it quite useful.

Many thanks to Marcus Comstedt for figuring out how the Logic16 protocol works, and for writing the libsigrok driver! He also documented the protocol in the wiki, as well as various firmware internals. We also have some teardown photos, pinouts of the ICs used in the Logic16 and their connections, EEPROM layout and other info in the wiki, if you're interested in this kind of stuff.

The device uses a Cypress FX2 USB chip and a Xilinx Spartan-3A XC3S200A FPGA internally. The first needs a firmware upload when the Logic16 is attached to USB, the latter needs an FPGA bitstream upload upon USB connection (as well as another bitstream upload whenever the voltage threshold setting is changed).

Thanks to Marcus Comstedt again who provided the sigrok-fwextract-saleae-logic16 tool which you can use to extract the FX2 firmware and the two FPGA bitstreams from the vendor software. See the manpage for details.

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...

libsigrok 0.2.1 released!

Hi everyone!

We're happy to announce the new libsigrok 0.2.1 release. This is mostly a bugfix release with a few additional new drivers to support more hardware. No major API changes were performed.

We added support for two new logic analyzers. One of them is the IKALOGIC Scanalogic-2, a 4-channel device with a max. samplerate of 20MHz. The driver was contributed by Marc Schink (thanks a lot!), who also wrote up some nice documentation about the USB HID based protocol in the wiki.

The other device we now support is also an IKALOGIC device (just a coincidence), namely the new ScanaPLUS, a 9-channel logic analyzer with a fixed samplerate of 100MHz, which compresses the captured data and streams it to the PC. This device uses an FPGA internally and an FTDI FT232H for data transfers. The protocol is thus not USB HID based like on the Scanalogic-2. We documented the ScanaPLUS USB protocol in the wiki too, if you want to have a look at the details.

We now also support two additional sound level meters, the CEM DT-8852 and the Kecheng KC-330B. Please check the previous blog post about these devices.

Finally, support for four new multimeters has been added, the UNI-T UT60A and UNI-T UT60E (thanks Florian Knodt!), the Voltcraft M-3650D (thanks Florian Steinhardt!) and the Voltcraft VC-830. They were all pretty easy to add to our generic 'serial-dmm' driver which can support a wide variety of serial-based DMMs with "simple" protocol.

Apart from that we added a few new config keys, config info types, and error codes. We also did the usual bunch of code cleanups, documentation improvements, and bugfixes. Please read the NEWS file for details.

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

Have fun!

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.


Subscribe to RSS - blogs