We're happy to announce that the GW Instek GDS-800 oscilloscope series is now supported in libsigrok.

These are devices ranging from 60MHz bandwidth up to 250MHz, with a samplerate of 100MSa/s (or 25GSa/s for equivalent-time sampling).

They have RS232 connectivity per default, but there are also options to extend them with GPIB or USB ports. A (publically documented) SCPI-based protocol is used for the communication.

The scopes are also sold under the Voltcraft brand name (and the code was actually tested on a Voltcraft DSO-6060C).

The driver was contributed by Martin Lederhilger, thanks a lot!

Yes, it's that time of the week again — libsigrokdecode supports yet another protocol decoder since somewhat recently: modbus.

In the current state the PD stacks on top of the UART decoder and decodes the Modbus RTU protocol. Support for e.g. Modbus ASCII may be added later (to the same PD), possibly also Modbus TCP or other variants (as an extra decoder).

Check the PD's wiki page or Wikipedia for some more info on Modbus in general.

As always, we have a few example files in the sigrok-dumps repo and some test-cases in the sigrok-test repo.

The decoder was contributed by Bart de Waal, thanks a lot!

Another somewhat recently added protocol decoder for libsigrokdecode is the qi PD.

This PD decodes demodulated data streams used by the Qi standard for communication from the receiver to the charging station. You can read more about the Wireless power consortium's Qi standard on Wikipedia.

As always, we have a few example files in the sigrok-dumps repo and some test-cases in the sigrok-test repo.

The decoder was contributed by Josef Gajdusek, thanks a lot!

libsigrok now supports the Velleman DVM4100 multimeter, a 6000 counts DMM with USB connectivity.

This DMM uses the Dream Tech International DTM0660 chip, which has a similar protocol as the Fortune Semiconductor FS9721_LP3 and can even be put into a mode that exactly matches the FS9721 protocol apparently (which also means it might be used in a lot more DMMs than we currently know of).

The DTM0660 protocol parser was contributed by Matthieu Gaillet, thanks a lot!

In addition to the Velleman DVM4100 this parser is also used in the PeakTech 3415 DMM, so it's very likely that this device is now also supported. Since that's untested though, we'd be happy to hear from users that actually own the PeakTech 3415!

We're happy to announce the sigrok-firmware-fx2lafw 0.1.3 release. This is an open-source firmware that allows you to use any of the popular Cypress FX2 based devices as logic analyzers.

The source code and pre-built firmware files are available from the usual place:

• sigrok-firmware-fx2lafw-0.1.3.tar.gz
• sigrok-firmware-fx2lafw-bin-0.1.3.tar.gz

This release doesn't contain any functionality changes in the firmware per se. There have been some minor documentation updates, and some not-so-minor build system improvements (thanks to Daniel Elstner!), though. The NEWS file contains some more details.

The most important change is probably the addition of two new firmware files for FX2-based devices which have the new "official" sigrok/fx2lafw USB VID/PID pairs in their I²C EEPROM:

• 1D50:608C: fx2lafw-sigrok-fx2-8ch.fw
• 1D50:608D: fx2lafw-sigrok-fx2-16ch.fw

These two VID/PID pairs are available for devices that use a Cypress FX2(LP) chip directly as 8-channel or 16-channel logic analyzer, and use the respective USB-based protocol. They are not meant for other devices which just happen to also have an FX2 (e.g. in addition to an FPGA) and/or devices that use a different USB-based protocol.

The USB VID/PIDs are allocated for sigrok/fx2lafw via the awesome "Open registry for community / homebrew USB Product IDs" service of the Openmoko project.

The new firmware files require the soon-to-be-released libsigrok>= 0.4.0 (or current git HEAD). The Windows sigrok-cli installer and PulseView installer (nightly builds) we provide already include these firmware files and a libsigrok version that is new enough.

As in previous years various sigrok developers will be at the Chaos Communication Congress (32C3) in Hamburg, Germany. The conference takes place December 27th to 30th, 2015.

There will be a sigrok assembly (on all 4 days) with a few tables and chairs to allow for sigrok hacking and development planning, various demos and Q&A for visitors, and so on.

Apart from sigrok hacking the conference also features the usual set of awesome talks related to security, hardware hacking, and lots of other interesting topics that you shouldn't miss.

If you're interested in sigrok as user or developer, please drop by and say hello. Bring your gear (if possible) for reverse engineering and driver writing purposes. Chat with us, give us your suggestions which features you'd like to see, which devices you want to be supported, which protocol decoders you'd like to have, or even help us write some drivers/decoders!

libsigrokdecode supports yet another protocol decoder since a while ago (which hasn't seen an official announce yet, though): mdio.

This is a PD for decoding the Management Data Input/Output (MDIO) protocol, sometimes also referred to as Serial Management Interface (SMI) or Media Independent Interface Management (MIIM).

As always, we have a few example files in the sigrok-dumps repo and some test-cases in the sigrok-test repo.

The decoder was contributed by Aurelien Jacobs, thanks a lot!

We've created a new sigrok-related logo that manufacturers or resellers of devices can use to advertise sigrok-compatible products: the "Works with sigrok" logo.

If you're developing or selling logic analyzers, oscilloscopes, multimeters, or any of the other supported device types, you can use this logo under the following conditions:

• Your device must be fully supported in the current git master version of libsigrok.
• The protocols used by your device must be publicly documented.
• If your device requires additional files at runtime, redistribution of these must be permitted.
• You must not imply any endorsement of your product by us.

See the Advertising sigrok compatible products wiki page for details.

We're happy to announce that the first user of the new logo is Hobby Components, who are selling FX2-based logic analyzer devices.

What's more, they're now also pre-configuring their FX2-based 8-channel logic analyzers (e.g. the Hobby Components HCTEST0006) to contain the new official sigrok VID/PID pairs for fx2lafw, so their devices will show up as "sigrok FX2 LA (8ch)" in e.g. PulseView and (only) work with our fully open-source firmware and software stack.

libsigrok now supports yet another new device. This time: the LeCroy LogicStudio.

This is a 16-channel logic analyzer with up to 1GHz sampling rate (depending on the number of channels used).

The device features a Xilinx Spartan-6 XC6SLX16, and a Cypress FX2 that takes care of the USB data transfer.

There's also an interesting mix of triggering facilities that the device supports, see the protocol docs for details.

In order to use the logic analyzer you need the respective firmware/bitstream files, which you can extract from the vendor software using the sigrok-fwextract-lecroy-logicstudio script from our sigrok-util repository.

The driver was contributed by Tilman Sauerbeck, thanks a lot!

libsigrokdecode has received support for another, quite interesting protocol decoder recently: usb_request.

This PD stacks on top of the usb_packet decoder, which in turn stacks on top of usb_signalling.

It decodes USB transactions / requests from the packets received from the usb_packet decoder:

 $ sigrok-cli -i olimex_stm32-h103_usb_hid.sr \
   -P usb_signalling:dp=DP:dm=DM,usb_packet,\
   usb_request
 BULK in: [ 00 01 00 00 ] : ACK
 BULK in: [ 00 01 00 00 ] : ACK
 BULK in: [ 00 01 00 00 ] : ACK

As usual, there are a bunch of sample files in sigrok-dumps, and some test-cases in the sigrok-test repo. Further files and test-cases are welcome!

In addition to emitting annotations (for displaying in GUIs), the PD also supports (currently) one SRD_OUTPUT_BINARY output type named "pcap".

This will emit the decoded data in the widely-used PCAP format, which you can then further process in other tools such as Wireshark:

 $ sigrok-cli -i olimex_stm32-h103_usb_hid.sr -P usb_signalling:dp=DP:dm=DM,usb_packet,\
   usb_request -B usb_request=pcap > foo.pcap

Of course you could also pipe the PCAP data directly into Wireshark as well:

 $ sigrok-cli -i olimex_stm32-h103_usb_hid.sr -P usb_signalling:dp=DP:dm=DM,usb_packet,\
   usb_request -B usb_request=pcap | wireshark -k -i -

The protocol decoder was contributed by Stefan Brüns, thanks a lot!

We're happy to announce that libsigrok now supports the Korad KAxxxxP series of programmable power supplies, including the popular Korad KA3005P.

These are all 1-channel lab power supplies with various different max. voltage and current properties.

Velleman also resells them under the name PS3005D and LABPS3005D, as does Farnell/Tenma using their usual model names of 72-xxxx. See the Korad KAxxxxP series wiki page for details. If you know of other vendors who resell these devices, please let us know.

The protocol used by the power supplies is documented on our wiki page, together with various quirks and bugs in the device firmware and/or vendor documentation.

If you own a not-yet-supported device from this series, you can easily add support by telling the libsigrok driver about the "ID" that the power supply returns upon the "*IDN?" command, e.g. like this. Please send us a patch if you do so!

The driver was contributed by Hannu Vuolasaho, thanks a lot!

So here I am hanging out at the local hacker space in Richmond. We, the group that meet up every Tuesday evening are small, yet perfectly formed. This evening Paul (MØTZO), a friendly radio ham, and co-founder of our group brought along an interesting device to encode GPS location data in APRS (Automatic Packet Reporting System) packets. These packets are fed into to a VHF radio transmitter which transmits the signal at 144.8 MHz. A network of receivers, run by amateur radio operators receives the packets, and streams them over the internet. An interesting device indeed.

Tonight we were just playing with Paul's GPS board, which contains a U-Blox Neo 6 GPS receiver. As with most GPS receivers, simply powering it on is enough to make it emit coordinates encoded in NMEA 0183 sentences transmitted over UART at 9600bps.

These are trivial to receive with an fx2-based logic analyzer and sigrok-cli:

$ sigrok-cli --driver=fx2lafw --config samplerate=50k \
    --continuous -P uart:baudrate=9600:tx=0 -B uart=tx

With the UART protocol decoder and the ASCII binary output, we can see the NMEA sentences:

Here we can see that we're locked on and receiving coordinates. "cat -v" is used to protect the terminal state from being clobbered by any errant binary data being emitted.

Yawn. Let's make this more interesting.

There is a very interesting package called gpsd. This is a GPS location server than can connect to various types of GPS devices, and can serve the position information over the network. And best of all, thanks to the power of UNIX pipes, we can feed the data from sigrok directly into it:

$ gpsd -N <(sigrok-cli --driver=fx2lafw --config samplerate=50k \
    --continuous -P uart:baudrate=9600:tx=0 -B uart=tx)

There are a variety of gpsd clients available. There's a nice ncurses based client, gpsmon:

And best of all, KDE's Marble integrates with gpsd. Here we see Marble, showing a live stream of location data captured by the fx2lafw firmware, decoded by sigrok, handled by gpsd, plotted by Marble on OpenStreetMap map data - a complete free-software stack! Pretty freetarded:

As in previous years various sigrok developers will be at the Chaos Communication Congress (31C3) in Hamburg, Germany. The conference takes place December 27th to 30th, 2014.

There will be a sigrok assembly (on all 4 days) with a few tables and chairs to allow for sigrok hacking and development planning, various demos and Q&A for visitors, and so on.

Apart from sigrok hacking the conference also features the usual set of awesome talks related to security, hardware hacking, and lots of other interesting topics that you shouldn't miss.

If you're interested in sigrok as user or developer, please drop by and say hello. Bring your gear (if possible) for reverse engineering and driver writing purposes. Chat with us, give us your suggestions which features you'd like to see, which devices you want to be supported, which protocol decoders you'd like to have, or even help us write some drivers/decoders!

We're happy to announce that libsigrokdecode now supports the am230x protocol decoder.

This PD decodes the custom protocol of the Aosong AM230x and DHT11 temperature and humidity sensors.

A short description of the protocol is available on the respective wiki page, along with pointers to further reading.

There are also a bunch of teardown photos of these sensors, in case you were wondering what those look like inside. Turns out they usually use some ST STM8S (or other) microcontroller and measure temperature and humidity "directly" without further ICs. The exception being the Aosong AM2303 which actually uses a Dallas/Maxim DS18B20 (1-Wire) sensor for the measurement.

Thanks a lot to Johannes Roemer for contributing the decoder!

We're happy to announce that libsigrokdecode now supports the pwm protocol decoder.

The PD was contributed by Torsten Duwe and Sebastien Bourdelin, thanks a lot!

This decoder will show the duty cycle of any signal, which in practice can mean various things. E.g. Class-D amplifiers can use PWM to encode audio data.

We have a test file in the sigrok-dumps repository containing audio data.

The decoder also supports a binary output facility which you can use to decode the audio (a direct export to WAV is planned as well, though).

 $ sigrok-cli -i pwmtest.sr -P pwm:data=4 -B pwm=raw > PWM.raw
 $ sox -t raw -e unsigned -b 8 -r 64000 PWM.raw PWM.wav
 $ aplay PWM.wav

libsigrok now supports yet another multimeter, the MASTECH MS8250B.

This is a 4000 counts autorange DMM with USB connectivity (via an internal USB-to-serial IC built into the DMM).

Apart from the usual measurement ranges it also features a nice non-contact voltage detector functionality.

Thanks to Baruch Even for contributing and testing the code for this DMM (which is now part of the serial-dmm driver via a relatively small patch)!

We're happy to announce that libsigrokdecode now supports three new, closely related, protocol decoders: arm_tpiu, arm_itm, and arm_etmv3.

Here's a quick overview of the protocols that are decoded:

• The TPIU (Trace Port Interface Unit) is a stream formatter and multiplexer that combines data from several sources into one stream. It is used inside an ARM-based microcontroller or SoC to combine ITM and ETM trace output into a single port.
• ARM ITM (Instrumentation Trace Macroblock) allows tracing of software events, and also with the help of DWT (Debug, Watchpoint and Trace) the tracing of exceptions and data watchpoints. It also supports periodic sampling of PC values.
• ARM ETM (Embedded Trace Macroblock) allows tracing of every instruction executed on the CPU. Currently only ETM version 3 (the newest version, present in Cortex-M3 and other ARMv7-m) is supported.

The data is captured on the SWO (TRACESWO) pin, e.g. on commonly available ARM SWD (serial wire debug) programmers/debuggers. Hint: libsigrokdecode also ships with an SWD decoder, if you're interested in that...

You can test the decoders with some sample files from the sigrok-dumps repository. If you optionally supply the location of ARM (cross-)toolchain utilities such as arm-none-eabi-objdump or arm-none-eabi-addr2line you can decode even more information, including source code snippets (see screenshot below)!

That opens up a whole new bunch of debugging possibilities; you can basically debug your code by not only tracing instructions but also tracing them in relation to other signals you're capturing with your logic analyzer at the same time (e.g. GPIOs you're toggling, UART, SPI, I²C, or whatever else may be going on in the system you're debugging)!

All three decoders were contributed by Petteri Aimonen (including sample *.sr files and a small test-suite for our sigrok-test repository), thanks a lot!

Happy debugging!

libsigrok now supports the BayLibre ACME device.

This a BeagleBone Black cape with an I²C-attached Texas Instruments INA226 current/power monitor and an I²C-attached TI TMP435 temperature sensor.

The sensors are supported in mainline Linux. The drivers expose a standard interface via the Linux sysfs pseudo file system, which the libsigrok driver uses.

The driver was contributed by Bartosz Golaszewski (of BayLibre), thanks a lot!

Bartosz will also present a Sigrok: Adventures in Integrating a Power-Measurement Device talk at the Embedded Linux Conference on March 24, 2015 (schedule) in San Jose, CA.

libsigrok now supports a new device class, tachometers! The first supported device of this type is the UNI-T UT372.

It's a USB-attached device (uses one of the WCH CH9325 ICs commonly found in UNI-T gear) that can measure RPM and counts.

The protocol of the device (now documented in the sigrok wiki) was reverse engineered by Mike Walters, using a somewhat unusual and quite interesting technique. Instead of the usual method of sniffing the USB traffic and then staring at hex numbers until things start to make sense, he used the following method:

After a first quick look at the USB traffic it was pretty clear that the packets usually look something like this:

    070?<3=7<60655>607;007885

Now, instead of trying to figure out which bit and byte means what by looking at many of these packets, Mike instead generated his own packets that looked like the real packets from the UT372. He sent them to the vendor's PC software (via a custom-built "emulator" on a USB-enabled Arduino), which then interpreted and displayed the values and flags that it thought were sent by an actual UT372 device.

By randomly flipping bits in these packets and observing how the PC software's interpretation of the packets differed, Mike was able to figure out the individual protocol details a lot faster than using other methods.

Shortly after the protocol was known, Martin Ling wrote a libsigrok driver for the UT372 by hooking up a device-specific ut372 parser to the existing uni-t-dmm driver in libsigrok (which already handles the somewhat "special" CH9325 details).

Thanks a lot to Mike Walters and Martin Ling for their contributions!

It's been a while since the eeprom24xx protocol decoder was added to libsigrokdecode, but there hasn't been an "official" announce yet, so here goes.

The eeprom24xx PD can decode the I²C-based protocol of (almost) all 24xx series EEPROMs from various vendors.

Supported chips include for example the Microchip 24LC64 or 24AA025UID, the ST M24C01 or M24C02, the Siemens SLx24C01 or SLx24C02, and others. Various other chip families can be added relatively easily via chip spec entries in the decoder's lists.py file.

These ICs usually have only very few bytes of storage (e.g. 128 or 256 bytes), where the memory is organized into pages (the page size is e.g. 8 or 16 bytes). They usually support various types of accesses (command sequences) such as "byte write", "page write", "current address read", "random read", "sequential random read", "sequential current address read", and others.

Apart from a common command subset, some of the chips also support custom non-standard commands such as "set write protection" or "read write protection status" (on ICs that have write-protectable areas), and some others.