sigrok-cli

We're happy to announce that libsigrokdecode now supports the adns5020 PD, a decoder for the Avago ADNS-5020 optical mouse sensor protocol. The decoder was contributed by Karl Palsson, thanks a lot! It stacks on top of the common SPI PD and decodes ... [More] ADNS-5020 specific registers reads and writes. There is an example file in the sigrok-dumps repository if you want to test the decoder, as well as a test config in our sigrok-test repository.   [Less]

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 ... [More] 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.   [Less]

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 ... [More] 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.   [Less]

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 ... [More] 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.   [Less]

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 ... [More] 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!   [Less]

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 ... [More] 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!   [Less]

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 ... [More] 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!   [Less]

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 ... [More] 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.   [Less]

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 ... [More] 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.   [Less]

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 ... [More] 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.   [Less]