sigrok - User contributions [en]

Developers/Release 0.8.0

2024-02-04T22:18:46Z

Fenugrec: typo in ubuntu bug URL

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, few users (see https://github.com/sigrokproject/sigrok-util/pull/16 ,)
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** {{checkbox|checked|(Done)}} PyEval_InitThreads() deprecated in Python 3.13 see https://bugzilla.redhat.com/show_bug.cgi?id=2245598
** {{checkbox|unchecked|Possibly some other Python2 / 3 compatibility and deprecation issues ?}}
** {{checkbox|unchecked|random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?}}
** {{checkbox|unchecked|-flto}} can break builds if driver list gets optimized out - see https://sigrok.org/bugzilla/show_bug.cgi?id=1433 , https://bugs.launchpad.net/ubuntu/+source/libsigrok/+bug/2025248

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

Developers/Release 0.8.0

2023-11-22T17:13:35Z

Fenugrec: -fLTO : link to bug reports

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, few users (see https://github.com/sigrokproject/sigrok-util/pull/16 ,)
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** {{checkbox|checked|(Done)}} PyEval_InitThreads() deprecated in Python 3.13 see https://bugzilla.redhat.com/show_bug.cgi?id=2245598
** {{checkbox|unchecked|Possibly some other Python2 / 3 compatibility and deprecation issues ?}}
** {{checkbox|unchecked|random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?}}
** {{checkbox|unchecked|-flto}} can break builds if driver list gets optimized out - see https://sigrok.org/bugzilla/show_bug.cgi?id=1433 , https://bugs.launchpad.net/ubuntu/+source/libsigrok/+bug/20252480

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

Developers/Release 0.8.0

2023-11-19T17:28:58Z

Fenugrec: clarify 'done' item

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, few users (see https://github.com/sigrokproject/sigrok-util/pull/16 ,)
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** {{checkbox|checked|(Done)}} PyEval_InitThreads() deprecated in Python 3.13 see https://bugzilla.redhat.com/show_bug.cgi?id=2245598
** {{checkbox|unchecked|Possibly some other Python2 / 3 compatibility and deprecation issues ?}}
** {{checkbox|unchecked|random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?}}
** {{checkbox|unchecked|-flto maybe breaks builds (driver list gets optimized out ? forget the details) on some distros ?}}

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

Developers/Release 0.8.0

2023-11-19T17:27:57Z

Fenugrec: checkboxes, ref to macos PR

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, few users (see https://github.com/sigrokproject/sigrok-util/pull/16 ,)
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** {{checkbox|checked|PyEval_InitThreads() deprecated in Python 3.13}} see https://bugzilla.redhat.com/show_bug.cgi?id=2245598
** {{checkbox|unchecked|Possibly some other Python2 / 3 compatibility and deprecation issues ?}}
** {{checkbox|unchecked|random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?}}
** {{checkbox|unchecked|-flto maybe breaks builds (driver list gets optimized out ? forget the details) on some distros ?}}

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

Developers/Release 0.8.0

2023-10-24T01:46:20Z

Fenugrec: PyEval_InitThreads() deprec done

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, no user reports in IRC
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** [DONE] PyEval_InitThreads() deprecated in Python 3.13; https://bugzilla.redhat.com/show_bug.cgi?id=2245598
** Possibly some other Python2 / 3 compatibility and deprecation issues ?
** random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?
** -flto maybe breaks builds (driver list gets optimized out ? forget the details) on some distros ?

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

checklist test
{{checkbox|unchecked|title}}

Developers/Release 0.8.0

2023-10-23T17:20:31Z

Fenugrec: py 3.9 deprecates some functions

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, no user reports in IRC
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** "Remove PyEval_InitThreads() and PyEval_ThreadsInitialized() functions, deprecated in Python 3.9" https://bugzilla.redhat.com/show_bug.cgi?id=2245598
** Possibly some other Python2 / 3 compatibility and deprecation issues,
** random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?
** -flto maybe breaks builds (driver list gets optimized out ? forget the details) on some distros ?

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

checklist test
{{checkbox|unchecked|title}}

Developers/Release 0.8.0

2023-10-20T18:27:53Z

Fenugrec: LTO

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, no user reports in IRC
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** I recall some Python2 / 3 compatibility fixes, forgot the details
** random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?
** -flto maybe breaks builds (driver list gets optimized out ? forget the details) on some distros ?

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

checklist test
{{checkbox|unchecked|title}}

Developers/Release 0.8.0

2023-10-20T17:52:12Z

Fenugrec:

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, no user reports in IRC
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** I recall some Python2 / 3 compatibility fixes, forgot the details
** random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware, mostly USB ?
** smuview

* what external projects depend on sigrok components or bindings ? does it actually matter ?
** Pulseview
** smuview

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

checklist test
{{checkbox|unchecked|title}}

Developers/Release 0.8.0

2023-10-20T14:43:33Z

Fenugrec: moved checklist (broken)

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, no user reports in IRC
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** I recall some Python2 / 3 compatibility fixes, forgot the details
** random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware

* what external projects depend on sigrok components or bindings ? does it actually matter ?

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

checklist test
{{checkbox|unchecked|title}}

Developers/Release 0.8.0

2023-10-20T14:43:06Z

Fenugrec: transports, bindings

This is an attempt at a checklist for the "next release" - as of 2023/10, for sigrok-cli this would be either 0.7.3 or 0.8.0 (maybe the latter would be more appropriate given that 0.7.2 was over 2 years ago ?). Other subprojects have different numbers e.g. last libsigrok was 0.5.2 .

Most of this is intended to expand on the main release guidelines here https://sigrok.org/wiki/Developers/Release_process

* what platforms "must work" ?
** linux is the most tested based on IRC traffic, but maybe we can explicitly list distros to test ?
** win : would be nice to have a list of people we can ping to get them test a build
** osx : no idea, no user reports in IRC
** *BSD : no idea, no user reports in IRC

* what currently open issues should be considered "blockers" for a release ?
** I recall some Python2 / 3 compatibility fixes, forgot the details
** random weird issues that always seem to come from Win* users running weird combinations of hardware / firmware

* what external projects depend on sigrok components or bindings ? does it actually matter ?

Transports (this would be better presented in a matrix format with feature vs OS) :

*serial (native/USB-CDC)
*USB (non-serial)
*USB
*TCP/IP
*GPIB (probably just linux ?)
*VXI ?

Developers/Release 0.8.0

2023-10-20T14:29:37Z

Fenugrec: failed checkbox attempt

Developers/Release 0.8.0

2023-10-20T14:26:33Z

Fenugrec: initial list

Protocol decoder:Spiflash

2023-04-26T16:16:22Z

Fenugrec: /* Resources */ added mx25l8006E ds

{{Infobox protocol decoder
| id = spiflash
| name = SPI flash
| description = xx25 series SPI (NOR) flash chip protocol
| status = supported
| license = GPLv2+
| source_code_dir = spiflash
| image = [[File:Macronix mx25l1605d device top.jpg|250px]]
| input = [[Protocol Decoder:spi|spi]]
| output = spiflash
| probes = —
| optional_probes = —
| options = —
}}

The '''spiflash''' protocol decoder supports the industry standard xx25 series SPI (NOR) flash chip protocol.

It is used (for example) in the [http://www.macronix.com/en-us/Product/Pages/ProductDetail.aspx?PartNo=MX25L1605D Macronix MX25L1605D] chip, and many others.

== Hardware ==

=== Chip pinout ===

The Macronix MX25L''xx''05D chips (and almost all SPI flash chips of the xx25 series) have the following pinout:

{{chip_8pin|1=CS#|2=SO|3=WP#|4=GND|5=SI|6=SCLK|7=HOLD#|8=VCC}}

=== Macronix MX25L1605D in openbiosprog-spi ===

The [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree;f=spi/mx25l1605d spi/mx25l1605d] directory in sigrok-dumps contains a set of example captures of a Macronix MX25L1605D (MX25L1605DPI-12G) SPI flash chip (16Mbit == 2Mbyte; NOR flash) that is probed, being written to, read, or erased.

The logic analyzer used was a [[ChronoVu LA8]] (at 25MHz). It is probing the SPI chip in the [http://randomprojects.org/wiki/Openbiosprog-spi openbiosprog-spi] Open Hardware USB-based SPI chip programmer. The host software used is [http://flashrom.org/FT2232SPI_Programmer flashrom].

'''Probe setup:'''

{| border="0" style="font-size: smaller" class="alternategrey sortable sigroktable"
|-
!Probe
!MX25L1605D pin

|-
| 0 (green) || CS#
|-
| 1 (orange) || SO/SIO1 (a.k.a MISO)
|-
| 2 (white) || SCLK
|-
| 3 (red) || SI/SIO0 (a.k.a MOSI)
|-
| 4 (gray) || WP#/ACC
|-
| 5 (brown) || HOLD#

|}

'''Photos:'''

<gallery>
File:Macronix mx25l1605d openbiosprog-spi.jpg|openbiosprog-spi with chip
File:Macronix mx25l1605d device top.jpg|Macronix MX25L1605D
File:Macronix mx25l1605d chronovu la8.jpg|[[ChronoVu LA8]]
File:Macronix mx25l1605d probed.jpg|Chip, probed
</gallery>

== Protocol ==

The xx25 series chips uses the standard SPI protocol and pins (MISO, MOSI, SCLK, CS#), with the additional (optional) HOLD# and WP#/ACC pins.

The host can send a large number of commands to the SPI chip (such as WREN, RDID, READ, SE, CE, PP, and many more). The commands have various length, and usually consist of one command ID byte, optional address bytes, one or more data/payload bytes, and so on (depending on the command).

See the chip datasheet for a detailed protocol/register/command description.

== Resources ==

* [http://www.macronix.com/en-us/Product/Pages/ProductDetail.aspx?PartNo=MX25L1605D Macronix MX25L1605D (dead link)] ([https://www.mxic.com.tw/Lists/Datasheet/Attachments/8554/MX25L1605D,%203V,%2016Mb,%20v1.5.pdf datasheet])
* [https://www.mxic.com.tw/Lists/Datasheet/Attachments/8384/MX25L8006E,%203V,%208Mb,%20v1.2.pdf MX25L8006E datasheet]

[[Category:Protocol decoder]]
[[Category:SPI]]

Protocol decoder:Spiflash

2023-04-26T16:15:27Z

Fenugrec: /* Resources */ dead links for datasheet

User talk:PeterMortensen

2022-12-02T19:56:54Z

Fenugrec:

[EDIT] sorry, this is supposed to go on https://sigrok.org/wiki/User_talk:PeterMortensen/IRC_shenanigans , but it somehow ended up on your personal page...

I was going to add a footnote in the IRC area for this type of information, but apparently that requires an extension that isn't available (https://sigrok.org/wiki/Special:Version ).

It would need intervention from one of the Admin users, so maybe there's a better way to present this info.

User talk:PeterMortensen

2022-12-02T19:55:57Z

Fenugrec: Created page with "I was going to add a footnote in the IRC area for this type of information, but apparently that requires an extension that isn't available (https://sigrok.org/wiki/Special:Version ). It would need intervention from one of the Admin users, so maybe there's a better way to present this info."

I was going to add a footnote in the IRC area for this type of information, but apparently that requires an extension that isn't available (https://sigrok.org/wiki/Special:Version ).

It would need intervention from one of the Admin users, so maybe there's a better way to present this info.

File format:Sigrok/v3

2017-10-07T23:38:31Z

Fenugrec: /* sigrok packets */ more big-endian

{{DISPLAYTITLE:File format:sigrok/v3}}
This page describes the proposed file/stream format (v3) for storing and transmitting sigrok related data.

<div style="background-color:#ff6666">
NOTE: This is work in progress and has not yet been implemented!
</div>

== Motivation ==

The previous [[File format:sigrok/v2|sigrok session]] file format (version 2) is a ZIP file containing multiple files (some metadata files and data files containing the actual samples). This works fine, but it also has some issues:

* In order to get to the data you want, you need to decompress the whole file.
* Appending to a file is not possible easily (and it's not efficient).
* It doesn't support storing additional information for frontends (channel colors, and so on).
* ...

== Goals ==

The following list highlights some of the goals of the new file format (v3):

* It must be able to store
** arbitrary data (logic samples, and/or analog samples, and/or protocol decoder data, and more), as well as
** arbitrary meta-/config-data and other extra information that may be useful to frontends (UI state data, user-configured probe colors, names, positions, and so on).
* It must support and facilitate stream-oriented processing (save, load, transmission, compression/decompression, and so on).
* It must support compression of the payload data.
* It must be usable independent of hardware architecture (x86, ARM, PowerPC, MIPS, and so on), operating system, endianness, float representation, and so on. All data fields must be properly specified (endianness, signedness, size, format).
* It must allow for sufficiently good performance for the common operations a frontend needs to perform on the data/file/stream (save, load, compress/uncompress, append, and so on) so that it doesn't become the bottleneck. This is especially important for stream-oriented devices which could otherwise lose samples if the processing on the host side is not sufficiently fast ([[Saleae Logic]], [[Saleae Logic16]], [[IKALOGIC ScanaPLUS]], others).
* It should be able to handle run-time changes in the data streams (via meta packets on the session bus), e.g. changing samplerates, changing probes, etc. etc.
* It should have better compression properties than ZIP (e.g. using LZO or other algorithms, this is to be evaluated). What we ideally want out of the compression algorithm is:
** Good and relatively fast compression results at only moderate CPU usage.
** Very fast decompression (LZO is probably the best one here, as it's specifically designed for this).
** Ideally, support for appending further data to already compressed data chunks (though this could be also implemented outside of the compression algorithm per se).
** Open-source license and OS portability. There should be an open-source library or code chunk for compression/uncompression and it should be widely available in Linux distros, and portable to Windows, Mac OS X, FreeBSD, Android, and so on.

== Specification ==

== UUIDs ==

The format uses random [http://en.wikipedia.org/wiki/Universally_unique_identifier UUIDs] (version 4) as per [http://tools.ietf.org/html/rfc4122 RFC4122] in various places. These UUIDs are always 16 bytes long.

A simple way to generate a random (version 4) UUID (ASCII and hex representation):


$ '''python3 -c 'import uuid; u = uuid.uuid4(); print(u); print(u.hex)''''
14c49f22-f08a-4ef2-b3d7-82ee16c3d531
14c49f22f08a4ef2b3d782ee16c3d531


== File/stream format ==

The format consists entirely of a stream of packets of various types.

These packets can be either written to or read from a file, buffer, pipe, socket, or any other source/destination.

== Packet format ==

Every packet consists of four fields:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Short-UUID'''
| 2
| An ID (2 bytes, big-endian) that maps to a previously defined 16-byte packet type UUID. The Short-UUID values can range from 0x0002 to 0xffff, which allows for 65535 different packet types in a single file/stream. The Short-UUIDs 0x0000 and 0x0001 are special and cannot be used for "normal" packets, see below. The reason for using a (Short-)UUID here instead of some simple index number is to allow for clients to define and use their own special-purpose packet types as they see fit, without having to fear any conflicts with existing packet types (or packet types that someone else might add later).

|-
| '''Reference-ID'''
| 4
| An ID (4 bytes, big-endian) that is assigned to this packet, so that other packets can reference it. Valid values: 0x00000001 - 0xffffffff. A value of 0x00000000 means that this packet doesn't have a Reference-ID. Note that a (Short-)UUID specifies a certain ''type'' of packet, whereas the Reference-ID identifies a specific ''individual'' packet. For example, there can be multiple different packets (different Reference-ID) that are of the same type (same Short-UUID).

|-
| '''Length'''
| 4
| The length of the data in this packet (number of bytes as an uint32_t; big-endian). The length does not include the length of the '''Short-UUID''', '''Reference-ID''' or '''Length''' field, only the length of the '''Data''' field.

|-
| '''Data'''
| 0..n
| The actual payload data, max. 2^32 bytes (4GiB). For some packet types the '''Data''' field is optional (in that case it is completely omitted and the '''Length''' field is set to 0). The contents of the '''Data''' field are entirely dependent on (and vary with) the type of packet.

|}

Using the common [http://en.wikipedia.org/wiki/Type-length-value type-length-value] idom for each packet allows clients to easily skip over (ignore) any packets they do not know how to handle, and instead continue on to checking/handling the next packet.

'''Example packet with a 7-byte data field (Short-UUID is 0x55aa, Reference-ID is 0x00008ab2):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 55 aa
| 00 00 8a b2
| 00 00 00 07
| 11 22 33 44 55 66 77

|}

'''Example packet without a data field (Short-UUID is 0x55aa, Reference-ID is 0x00005f31):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| 55 aa
| 00 00 5f 31
| 00 00 00 00

|}

== PACKET_MAP_UUIDS packet ==

This is a special packet that is used to map 16-byte UUIDs to 2-byte Short-UUIDs.

Since every packet has a 2-byte Short-UUID, PACKET_MAP_UUIDS must be the first packet in a file/stream, otherwise the client will not be able to interpret any other packets.

However, PACKET_MAP_UUIDS can occur multiple times in a stream. Every time PACKET_MAP_UUIDS is seen, mappings that were not yet defined are added to the list of mappings, and mappings that already existed will be overwritten with the respective new mapping.

Since PACKET_MAP_UUIDS is a packet itself, it also consists of the four common fields Short-UUID/Reference-ID/Length/Data. The Short-UUID of PACKET_MAP_UUIDS is always '''0x0000'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Special Short-UUID for magic marker'''
| 2
| A reserved special Short-UUID (2 bytes, big-endian) for the magic marker. Value: '''0x0001'''.

|-
| '''Special UUID for magic marker'''
| 16
| This is a special marker that can be used by the '''file''' utility (and other tools) to detect the file format easily. Contents: '''$sIgRoK$$sIgRoK$'''.

|-
| '''Short-UUID 1'''
| 2
| The 2-byte Short-UUID (2 bytes, big-endian) with index 1 (valid values: 0x0002 to 0xffff) that will, from now on, map to the UUID specified below.

|-
| '''UUID 1'''
| 16
| The UUID with index 1 (binary representation, 16 bytes, big-endian) which identifies the type of packet (globally unique).

|-
| '''Short-UUID 2'''
| 2
| The 2-byte Short-UUID with index 2 (valid values: 0x0002 to 0xffff ; big-endian) that will, from now on, map to the UUID specified below.

|-
| '''UUID 2'''
| 16
| The UUID with index 2 (binary representation, 16 bytes, big-endian) which identifies the type of packet (globally unique).

|-
| ...
| ...
| ...

|}

Important notes:

* The '''Data''' field contains a list of Short-UUID to UUID mappings. Since every such pair is 18 bytes in size, the '''Length''' field of PACKET_MAP_UUIDS can be used to deduce how many such mappings are contained in the '''Data''' field.
* The special "magic marker" fields (2 + 16 bytes) are required to be in every PACKET_MAP_UUIDS and are required to always be the first entries of PACKET_MAP_UUIDS. The file format can thus easily be detected by looking at the unique bytes 10-27 in the file (additionally, the file also always starts with the two bytes 0x00 0x00).
* The special Short-UUID 0x0000 must not be used in any mapping, it is reserved for PACKET_MAP_UUIDS itself.
* The special Short-UUID 0x0001 must not be used in any mapping, it is reserved for the special "magic marker", see above.
* There is no guarantee of any kind about which Short-UUIDs will be mapped (and to what). Specifically, a client can '''not''' assume that Short-UUIDs start at 0x0002, and it can '''not''' assume that Short-UUIDs are ordered in any way. The Short-UUIDs can have a completely random order and they can also have gaps.
* Mappings are generally not static in nature. Every additional PACKET_MAP_UUIDS that occurs can dynamically add or overwrite/change mappings, for example.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 00 00
| ''xx xx xx xx''
| 00 00 00 48
| <tt>00 01 24 73 49 67 52 6f 4b 24 24 73 49 67 52 6f 4b 24 77 a1 5a 17 72 eb 28 54 48 a8 a4 1c 73 97 d7 e9 22 3d 00 06 59 de f3 30 53 6a 46 b1 8e dd 62 f2 19 5d 1c 95 a3 9f ec 6b d7 63 c8 79 4a a7 a9 7a 7e df 0e 68 af c7</tt>

|}

The above PACKET_MAP_UUIDS maps three different UUIDs to the Short-UUIDs 0x77a1, 0x0006 and 0xa39f.

== sigrok packets ==

The following packets are currently defined for use in projects hosted on [http://sigrok.org sigrok.org].

The "names" (e.g. "SIGROK_PACKET_LOGIC") are for documentation purposes only, the (Short-)UUIDs are what actually matters. The names are prefixed with SIGROK_ to make it clear that other 3rd-party software may define their own additional packet types with arbitrary contents and for arbitrary purposes.

One of the reasons for splitting up different properties into many small packets (SIGROK_PACKET_CHANNEL_TYPE, SIGROK_PACKET_CHANNEL_NAME, and so on) is that this allows for future additions (of e.g. various other channel properties), without the need to change an existing packet format. Additional packets for e.g. the channel color (for use in UIs) that also back-reference a SIGROK_PACKET_CHANNEL packet can be added without the need for protocol/format changes or version field bumps.

=== SIGROK_PACKET_DEVICE ===

This is a packet type used to define a device.

This packet uses the fixed UUID '''94aa863d-bb58-4d79-b944-ab9dd30eecdf'''.

The '''Data''' field is empty.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 00

|}

=== SIGROK_PACKET_DEVICE_VENDOR_NAME ===

This is a packet type used to define a device vendor name.

This packet uses the fixed UUID '''c09c7a5c-8566-42ec-8fde-7737436b0e64'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, big-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Vendor name length'''
| 2
| The length in number of bytes of the vendor name (2 bytes, big-endian).

|-
| '''Vendor name'''
| n
| The vendor name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a vendor name "Saleae" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0c
| ''bb bb bb bb'' 00 06 Saleae

|}

=== SIGROK_PACKET_DEVICE_MODEL_NAME ===

This is a packet type used to define a device model name.

This packet uses the fixed UUID '''88058d2f-225e-4ee6-b915-9fd009944464'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, big-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Model name length'''
| 2
| The length in number of bytes of the model name (2 bytes, big-endian).

|-
| '''Model name'''
| n
| The model name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a model name "Logic16" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0d
| ''bb bb bb bb'' 00 07 Logic16

|}

=== SIGROK_PACKET_DEVICE_VERSION ===

=== SIGROK_PACKET_DEVICE_SERIAL_NUMBER ===

=== SIGROK_PACKET_DEVICE_CONNECTION_ID ===

=== SIGROK_PACKET_CHANNEL_GROUP ===

=== SIGROK_PACKET_CHANNEL_GROUP_NAME ===

=== SIGROK_PACKET_CHANNEL ===

This is a packet type used to define a channel.

This packet uses the fixed UUID '''1325b595-0d5e-40a4-ac4d-36e89224dcb9'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, big-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE) that the channel belongs to.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 04
| <tt>''bb bb bb bb''

|}

=== SIGROK_PACKET_CHANNEL_TYPE ===

This is a packet type used to define a channel type.

This packet uses the fixed UUID '''6b12bdcc-02c8-493a-a89d-662ee9d1a34d'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, big-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel type'''
| 1
| The type of the back-referenced channel. '''0x01''': Logic, '''0x02''': Analog.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 05
| ''bb bb bb bb'' 01

|}

=== SIGROK_PACKET_CHANNEL_NAME ===

This is a packet type used to define a channel name.

This packet uses the fixed UUID '''730ba9b7-638a-4b79-94dc-b9beb0735acf'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, big-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel name length'''
| 2
| The length in number of bytes of the channel name (2 bytes, big-endian).

|-
| '''Channel name'''
| n
| The channel name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a channel name "CH1" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined channel for which this name is to apply.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 09
| ''bb bb bb bb'' 00 03 CH1

|}

=== SIGROK_PACKET_LOGIC ===

This is a packet type used to store/transmit (only) digital samples, usually from a logic analyzer.

This packet uses the fixed UUID '''2236202e-9ee7-4bc6-81f6-56b4e6e029ba'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Version'''
| 2
| The version of the SIGROK_PACKET_LOGIC format in binary format (big-endian). Current version: '''0x0001'''.

|-
| '''Payload format Short-UUID'''
| 2
| A Short-UUID (2 bytes, big-endian) which identifies a certain payload format.

|-
| '''Compression scheme Short-UUID'''
| 2
| A Short-UUID (2 bytes, big-endian) which identifies a certain compression scheme that is applied to the payload data.

|-
| '''Payload length'''
| 4
| The length of the actual payload data in this SIGROK_PACKET_LOGIC packet (in number of bytes). The length only includes the '''Payload''' field. The length is given as an uint32_t number (big-endian).

|-
| '''Payload'''
| 0..n
| The actual payload data, i.e. logic analyzer samples in the specified payload format, using the specified compression scheme.

|}

'''Example packet:'''

(Packet type SIGROK_PACKET_LOGIC Short-UUID ''0xuuuu'', Reference-ID ''0xtttttttt'', 0x12 bytes packet data, SIGROK_PACKET_LOGIC version 0x0001, SIGROK_PAYLOAD_FORMAT_LOGIC_V1 payload format Short-UUID ''0xvvvv'', SIGROK_COMPRESSION_NONE compression scheme Short-UUID ''0xwwww'', 8 bytes of logic analyzer payload (uncompressed))

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 12
| 00 01 ''vv vv'' ''ww ww'' 00 00 00 08 11 22 33 44 55 66 77 88

|}

SA: How does the mapping to the individual channels work? Do we need to backreference a channel group here that declares e.g. which 8 logic channels make up one such logic packet and in which order they are stored?

=== SIGROK_PACKET_ANALOG ===

This is a packet type used to store/transmit (only) analog samples, e.g. from a multimeter, oscilloscope, sound level meter, or any other source for analog data.

This packet uses the fixed UUID '''59def330-536a-46b1-8edd-62f2195d1c95'''.

Details yet to be defined.

== List of known packet types ==

This is a short overview of known packet types that are in use. This includes the packet types used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to packet types that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Packet type
!Description

|-
| 94aa863d-bb58-4d79-b944-ab9dd30eecdf
| SIGROK_PACKET_DEVICE
| [[File format:sigrok#SIGROK_PACKET_DEVICE|See above]].

|-
| 1325b595-0d5e-40a4-ac4d-36e89224dcb9
| SIGROK_PACKET_CHANNEL
| [[File format:sigrok#SIGROK_PACKET_CHANNEL|See above]].

|-
| 5a1772eb-2854-48a8-a41c-7397d7e9223d
| SIGROK_PACKET_LOGIC
| [[File format:sigrok#SIGROK_PACKET_LOGIC|See above]].

|-
| 59def330-536a-46b1-8edd-62f2195d1c95
| SIGROK_PACKET_ANALOG
| [[File format:sigrok#SIGROK_PACKET_ANALOG|See above]].

|}

== List of known payload formats ==

This is a short overview of known payload formats that are in use. This includes the payload formats used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to payload formats that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Payload format
!Description

|-
| style="white-space: nowrap;" | d2964f38-8b13-4570-9add-add5678a0394
| SIGROK_PAYLOAD_FORMAT_LOGIC_V1
| This payload format can only store digital samples from a logic analyzer (0/1 values for a certain channel/probe/pin). It is basically identical to the format that was used in the previous ZIP-based file format versions. Details are yet to be defined.

|-
| 79e7cfd1-0f56-4d5e-968a-b66fdbdff624
| SIGROK_PAYLOAD_FORMAT_ANALOG_V1
| A certain type of payload format that can store (only) analog samples of a certain number of analog channels. Details are yet to be defined.

|}

== List of known compression schemes ==

This is a short overview of known compression schemes that are in use. This includes the schemes used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to schemes that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Compression scheme
!Description

|-
| ec6bd763-c879-4aa7-a97a-7edf0e68afc7
| SIGROK_COMPRESSION_NONE
| No compression whatsoever is used.

|-
| acd2e249-5c4d-426d-96ae-ded5b6020e6f
| SIGROK_COMPRESSION_RLE_V1
| A certain type of RLE-based compression is used. Details are yet to be defined.

|}

* JH: Do we need info about interleaving here? We could insist that all channels be de-intereleaved, or add support for interleaved streams.
* JH: Would could add support for device compression schemes. It may sometimes be desirable to be able to pass the device stream straight into the file.

== Futher notes and ideas to consider ==

* SA: Currently, the sample rate isn't declared anywhere. Do we do this on a per-device or per-channel basis? My guts tell me that it's probably wiser to do it on a per-channel basis, even if all channels have the same sample rate.
* Data should be encoded in a data aware way. This would give greater compression:
** Logic Data is most efficient stored in RLE+Huffman or Golomb coding. e.g. a clock signal may compress to one bit per edge.
*** JH: I wonder if we can do even better by XOR-ing the data with some kind of frequency tracking oscillator. This would convert a square wave into mostly continuous 0s or 1s, with occasional pulses where jitter occurs.
*** JH: This kind of thing is best prototyped with a script e.g python + the bitset library.
** FLAC (libflac) or a FLAC inspired codec (linear predicition) is probably as good as it gets for lossless analog data encoding.
* If data is stored in a format specific way, it would be best to store it as a series of stream-blocks, similar to how video containers work. Would it be possible to simply leverage a video container such as OGG? IIRC this contains headers to declare metadata about each stream, then a series of timestamped stream blocks interleaved together. The time stamp is a format specific number... for audio: the sample number, for video: the frame number, so sigrok formats can easily leverage this.
** Similarly RTP is a rather natural protocol for sigrok network streaming.

File format:Sigrok/v3

2017-10-07T23:32:47Z

Fenugrec: /* Packet format */ missed a LE->BE change for Length field

{{DISPLAYTITLE:File format:sigrok/v3}}
This page describes the proposed file/stream format (v3) for storing and transmitting sigrok related data.

<div style="background-color:#ff6666">
NOTE: This is work in progress and has not yet been implemented!
</div>

== Motivation ==

The previous [[File format:sigrok/v2|sigrok session]] file format (version 2) is a ZIP file containing multiple files (some metadata files and data files containing the actual samples). This works fine, but it also has some issues:

* In order to get to the data you want, you need to decompress the whole file.
* Appending to a file is not possible easily (and it's not efficient).
* It doesn't support storing additional information for frontends (channel colors, and so on).
* ...

== Goals ==

The following list highlights some of the goals of the new file format (v3):

* It must be able to store
** arbitrary data (logic samples, and/or analog samples, and/or protocol decoder data, and more), as well as
** arbitrary meta-/config-data and other extra information that may be useful to frontends (UI state data, user-configured probe colors, names, positions, and so on).
* It must support and facilitate stream-oriented processing (save, load, transmission, compression/decompression, and so on).
* It must support compression of the payload data.
* It must be usable independent of hardware architecture (x86, ARM, PowerPC, MIPS, and so on), operating system, endianness, float representation, and so on. All data fields must be properly specified (endianness, signedness, size, format).
* It must allow for sufficiently good performance for the common operations a frontend needs to perform on the data/file/stream (save, load, compress/uncompress, append, and so on) so that it doesn't become the bottleneck. This is especially important for stream-oriented devices which could otherwise lose samples if the processing on the host side is not sufficiently fast ([[Saleae Logic]], [[Saleae Logic16]], [[IKALOGIC ScanaPLUS]], others).
* It should be able to handle run-time changes in the data streams (via meta packets on the session bus), e.g. changing samplerates, changing probes, etc. etc.
* It should have better compression properties than ZIP (e.g. using LZO or other algorithms, this is to be evaluated). What we ideally want out of the compression algorithm is:
** Good and relatively fast compression results at only moderate CPU usage.
** Very fast decompression (LZO is probably the best one here, as it's specifically designed for this).
** Ideally, support for appending further data to already compressed data chunks (though this could be also implemented outside of the compression algorithm per se).
** Open-source license and OS portability. There should be an open-source library or code chunk for compression/uncompression and it should be widely available in Linux distros, and portable to Windows, Mac OS X, FreeBSD, Android, and so on.

== Specification ==

== UUIDs ==

The format uses random [http://en.wikipedia.org/wiki/Universally_unique_identifier UUIDs] (version 4) as per [http://tools.ietf.org/html/rfc4122 RFC4122] in various places. These UUIDs are always 16 bytes long.

A simple way to generate a random (version 4) UUID (ASCII and hex representation):


$ '''python3 -c 'import uuid; u = uuid.uuid4(); print(u); print(u.hex)''''
14c49f22-f08a-4ef2-b3d7-82ee16c3d531
14c49f22f08a4ef2b3d782ee16c3d531


== File/stream format ==

The format consists entirely of a stream of packets of various types.

These packets can be either written to or read from a file, buffer, pipe, socket, or any other source/destination.

== Packet format ==

Every packet consists of four fields:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Short-UUID'''
| 2
| An ID (2 bytes, big-endian) that maps to a previously defined 16-byte packet type UUID. The Short-UUID values can range from 0x0002 to 0xffff, which allows for 65535 different packet types in a single file/stream. The Short-UUIDs 0x0000 and 0x0001 are special and cannot be used for "normal" packets, see below. The reason for using a (Short-)UUID here instead of some simple index number is to allow for clients to define and use their own special-purpose packet types as they see fit, without having to fear any conflicts with existing packet types (or packet types that someone else might add later).

|-
| '''Reference-ID'''
| 4
| An ID (4 bytes, big-endian) that is assigned to this packet, so that other packets can reference it. Valid values: 0x00000001 - 0xffffffff. A value of 0x00000000 means that this packet doesn't have a Reference-ID. Note that a (Short-)UUID specifies a certain ''type'' of packet, whereas the Reference-ID identifies a specific ''individual'' packet. For example, there can be multiple different packets (different Reference-ID) that are of the same type (same Short-UUID).

|-
| '''Length'''
| 4
| The length of the data in this packet (number of bytes as an uint32_t; big-endian). The length does not include the length of the '''Short-UUID''', '''Reference-ID''' or '''Length''' field, only the length of the '''Data''' field.

|-
| '''Data'''
| 0..n
| The actual payload data, max. 2^32 bytes (4GiB). For some packet types the '''Data''' field is optional (in that case it is completely omitted and the '''Length''' field is set to 0). The contents of the '''Data''' field are entirely dependent on (and vary with) the type of packet.

|}

Using the common [http://en.wikipedia.org/wiki/Type-length-value type-length-value] idom for each packet allows clients to easily skip over (ignore) any packets they do not know how to handle, and instead continue on to checking/handling the next packet.

'''Example packet with a 7-byte data field (Short-UUID is 0x55aa, Reference-ID is 0x00008ab2):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 55 aa
| 00 00 8a b2
| 00 00 00 07
| 11 22 33 44 55 66 77

|}

'''Example packet without a data field (Short-UUID is 0x55aa, Reference-ID is 0x00005f31):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| 55 aa
| 00 00 5f 31
| 00 00 00 00

|}

== PACKET_MAP_UUIDS packet ==

This is a special packet that is used to map 16-byte UUIDs to 2-byte Short-UUIDs.

Since every packet has a 2-byte Short-UUID, PACKET_MAP_UUIDS must be the first packet in a file/stream, otherwise the client will not be able to interpret any other packets.

However, PACKET_MAP_UUIDS can occur multiple times in a stream. Every time PACKET_MAP_UUIDS is seen, mappings that were not yet defined are added to the list of mappings, and mappings that already existed will be overwritten with the respective new mapping.

Since PACKET_MAP_UUIDS is a packet itself, it also consists of the four common fields Short-UUID/Reference-ID/Length/Data. The Short-UUID of PACKET_MAP_UUIDS is always '''0x0000'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Special Short-UUID for magic marker'''
| 2
| A reserved special Short-UUID (2 bytes, big-endian) for the magic marker. Value: '''0x0001'''.

|-
| '''Special UUID for magic marker'''
| 16
| This is a special marker that can be used by the '''file''' utility (and other tools) to detect the file format easily. Contents: '''$sIgRoK$$sIgRoK$'''.

|-
| '''Short-UUID 1'''
| 2
| The 2-byte Short-UUID (2 bytes, big-endian) with index 1 (valid values: 0x0002 to 0xffff) that will, from now on, map to the UUID specified below.

|-
| '''UUID 1'''
| 16
| The UUID with index 1 (binary representation, 16 bytes, big-endian) which identifies the type of packet (globally unique).

|-
| '''Short-UUID 2'''
| 2
| The 2-byte Short-UUID with index 2 (valid values: 0x0002 to 0xffff ; big-endian) that will, from now on, map to the UUID specified below.

|-
| '''UUID 2'''
| 16
| The UUID with index 2 (binary representation, 16 bytes, big-endian) which identifies the type of packet (globally unique).

|-
| ...
| ...
| ...

|}

Important notes:

* The '''Data''' field contains a list of Short-UUID to UUID mappings. Since every such pair is 18 bytes in size, the '''Length''' field of PACKET_MAP_UUIDS can be used to deduce how many such mappings are contained in the '''Data''' field.
* The special "magic marker" fields (2 + 16 bytes) are required to be in every PACKET_MAP_UUIDS and are required to always be the first entries of PACKET_MAP_UUIDS. The file format can thus easily be detected by looking at the unique bytes 10-27 in the file (additionally, the file also always starts with the two bytes 0x00 0x00).
* The special Short-UUID 0x0000 must not be used in any mapping, it is reserved for PACKET_MAP_UUIDS itself.
* The special Short-UUID 0x0001 must not be used in any mapping, it is reserved for the special "magic marker", see above.
* There is no guarantee of any kind about which Short-UUIDs will be mapped (and to what). Specifically, a client can '''not''' assume that Short-UUIDs start at 0x0002, and it can '''not''' assume that Short-UUIDs are ordered in any way. The Short-UUIDs can have a completely random order and they can also have gaps.
* Mappings are generally not static in nature. Every additional PACKET_MAP_UUIDS that occurs can dynamically add or overwrite/change mappings, for example.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 00 00
| ''xx xx xx xx''
| 00 00 00 48
| <tt>00 01 24 73 49 67 52 6f 4b 24 24 73 49 67 52 6f 4b 24 77 a1 5a 17 72 eb 28 54 48 a8 a4 1c 73 97 d7 e9 22 3d 00 06 59 de f3 30 53 6a 46 b1 8e dd 62 f2 19 5d 1c 95 a3 9f ec 6b d7 63 c8 79 4a a7 a9 7a 7e df 0e 68 af c7</tt>

|}

The above PACKET_MAP_UUIDS maps three different UUIDs to the Short-UUIDs 0x77a1, 0x0006 and 0xa39f.

== sigrok packets ==

The following packets are currently defined for use in projects hosted on [http://sigrok.org sigrok.org].

The "names" (e.g. "SIGROK_PACKET_LOGIC") are for documentation purposes only, the (Short-)UUIDs are what actually matters. The names are prefixed with SIGROK_ to make it clear that other 3rd-party software may define their own additional packet types with arbitrary contents and for arbitrary purposes.

One of the reasons for splitting up different properties into many small packets (SIGROK_PACKET_CHANNEL_TYPE, SIGROK_PACKET_CHANNEL_NAME, and so on) is that this allows for future additions (of e.g. various other channel properties), without the need to change an existing packet format. Additional packets for e.g. the channel color (for use in UIs) that also back-reference a SIGROK_PACKET_CHANNEL packet can be added without the need for protocol/format changes or version field bumps.

=== SIGROK_PACKET_DEVICE ===

This is a packet type used to define a device.

This packet uses the fixed UUID '''94aa863d-bb58-4d79-b944-ab9dd30eecdf'''.

The '''Data''' field is empty.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 00

|}

=== SIGROK_PACKET_DEVICE_VENDOR_NAME ===

This is a packet type used to define a device vendor name.

This packet uses the fixed UUID '''c09c7a5c-8566-42ec-8fde-7737436b0e64'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Vendor name length'''
| 2
| The length in number of bytes of the vendor name (2 bytes, little-endian).

|-
| '''Vendor name'''
| n
| The vendor name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a vendor name "Saleae" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0c
| ''bb bb bb bb'' 00 06 Saleae

|}

=== SIGROK_PACKET_DEVICE_MODEL_NAME ===

This is a packet type used to define a device model name.

This packet uses the fixed UUID '''88058d2f-225e-4ee6-b915-9fd009944464'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Model name length'''
| 2
| The length in number of bytes of the model name (2 bytes, little-endian).

|-
| '''Model name'''
| n
| The model name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a model name "Logic16" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0d
| ''bb bb bb bb'' 00 07 Logic16

|}

=== SIGROK_PACKET_DEVICE_VERSION ===

=== SIGROK_PACKET_DEVICE_SERIAL_NUMBER ===

=== SIGROK_PACKET_DEVICE_CONNECTION_ID ===

=== SIGROK_PACKET_CHANNEL_GROUP ===

=== SIGROK_PACKET_CHANNEL_GROUP_NAME ===

=== SIGROK_PACKET_CHANNEL ===

This is a packet type used to define a channel.

This packet uses the fixed UUID '''1325b595-0d5e-40a4-ac4d-36e89224dcb9'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE) that the channel belongs to.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 04
| <tt>''bb bb bb bb''

|}

=== SIGROK_PACKET_CHANNEL_TYPE ===

This is a packet type used to define a channel type.

This packet uses the fixed UUID '''6b12bdcc-02c8-493a-a89d-662ee9d1a34d'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel type'''
| 1
| The type of the back-referenced channel. '''0x01''': Logic, '''0x02''': Analog.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 05
| ''bb bb bb bb'' 01

|}

=== SIGROK_PACKET_CHANNEL_NAME ===

This is a packet type used to define a channel name.

This packet uses the fixed UUID '''730ba9b7-638a-4b79-94dc-b9beb0735acf'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel name length'''
| 2
| The length in number of bytes of the channel name (2 bytes, little-endian).

|-
| '''Channel name'''
| n
| The channel name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a channel name "CH1" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined channel for which this name is to apply.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 09
| ''bb bb bb bb'' 00 03 CH1

|}

=== SIGROK_PACKET_LOGIC ===

This is a packet type used to store/transmit (only) digital samples, usually from a logic analyzer.

This packet uses the fixed UUID '''2236202e-9ee7-4bc6-81f6-56b4e6e029ba'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Version'''
| 2
| The version of the SIGROK_PACKET_LOGIC format in binary format (little-endian). Current version: '''0x0001'''.

|-
| '''Payload format Short-UUID'''
| 2
| A Short-UUID (2 bytes, little-endian) which identifies a certain payload format.

|-
| '''Compression scheme Short-UUID'''
| 2
| A Short-UUID (2 bytes, little-endian) which identifies a certain compression scheme that is applied to the payload data.

|-
| '''Payload length'''
| 4
| The length of the actual payload data in this SIGROK_PACKET_LOGIC packet (in number of bytes). The length only includes the '''Payload''' field. The length is given as an uint32_t number (little-endian).

|-
| '''Payload'''
| 0..n
| The actual payload data, i.e. logic analyzer samples in the specified payload format, using the specified compression scheme.

|}

'''Example packet:'''

(Packet type SIGROK_PACKET_LOGIC Short-UUID ''0xuuuu'', Reference-ID ''0xtttttttt'', 0x12 bytes packet data, SIGROK_PACKET_LOGIC version 0x0001, SIGROK_PAYLOAD_FORMAT_LOGIC_V1 payload format Short-UUID ''0xvvvv'', SIGROK_COMPRESSION_NONE compression scheme Short-UUID ''0xwwww'', 8 bytes of logic analyzer payload (uncompressed))

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 12
| 00 01 ''vv vv'' ''ww ww'' 00 00 00 08 11 22 33 44 55 66 77 88

|}

SA: How does the mapping to the individual channels work? Do we need to backreference a channel group here that declares e.g. which 8 logic channels make up one such logic packet and in which order they are stored?

=== SIGROK_PACKET_ANALOG ===

This is a packet type used to store/transmit (only) analog samples, e.g. from a multimeter, oscilloscope, sound level meter, or any other source for analog data.

This packet uses the fixed UUID '''59def330-536a-46b1-8edd-62f2195d1c95'''.

Details yet to be defined.

== List of known packet types ==

This is a short overview of known packet types that are in use. This includes the packet types used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to packet types that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Packet type
!Description

|-
| 94aa863d-bb58-4d79-b944-ab9dd30eecdf
| SIGROK_PACKET_DEVICE
| [[File format:sigrok#SIGROK_PACKET_DEVICE|See above]].

|-
| 1325b595-0d5e-40a4-ac4d-36e89224dcb9
| SIGROK_PACKET_CHANNEL
| [[File format:sigrok#SIGROK_PACKET_CHANNEL|See above]].

|-
| 5a1772eb-2854-48a8-a41c-7397d7e9223d
| SIGROK_PACKET_LOGIC
| [[File format:sigrok#SIGROK_PACKET_LOGIC|See above]].

|-
| 59def330-536a-46b1-8edd-62f2195d1c95
| SIGROK_PACKET_ANALOG
| [[File format:sigrok#SIGROK_PACKET_ANALOG|See above]].

|}

== List of known payload formats ==

This is a short overview of known payload formats that are in use. This includes the payload formats used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to payload formats that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Payload format
!Description

|-
| style="white-space: nowrap;" | d2964f38-8b13-4570-9add-add5678a0394
| SIGROK_PAYLOAD_FORMAT_LOGIC_V1
| This payload format can only store digital samples from a logic analyzer (0/1 values for a certain channel/probe/pin). It is basically identical to the format that was used in the previous ZIP-based file format versions. Details are yet to be defined.

|-
| 79e7cfd1-0f56-4d5e-968a-b66fdbdff624
| SIGROK_PAYLOAD_FORMAT_ANALOG_V1
| A certain type of payload format that can store (only) analog samples of a certain number of analog channels. Details are yet to be defined.

|}

== List of known compression schemes ==

This is a short overview of known compression schemes that are in use. This includes the schemes used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to schemes that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Compression scheme
!Description

|-
| ec6bd763-c879-4aa7-a97a-7edf0e68afc7
| SIGROK_COMPRESSION_NONE
| No compression whatsoever is used.

|-
| acd2e249-5c4d-426d-96ae-ded5b6020e6f
| SIGROK_COMPRESSION_RLE_V1
| A certain type of RLE-based compression is used. Details are yet to be defined.

|}

* JH: Do we need info about interleaving here? We could insist that all channels be de-intereleaved, or add support for interleaved streams.
* JH: Would could add support for device compression schemes. It may sometimes be desirable to be able to pass the device stream straight into the file.

== Futher notes and ideas to consider ==

* SA: Currently, the sample rate isn't declared anywhere. Do we do this on a per-device or per-channel basis? My guts tell me that it's probably wiser to do it on a per-channel basis, even if all channels have the same sample rate.
* Data should be encoded in a data aware way. This would give greater compression:
** Logic Data is most efficient stored in RLE+Huffman or Golomb coding. e.g. a clock signal may compress to one bit per edge.
*** JH: I wonder if we can do even better by XOR-ing the data with some kind of frequency tracking oscillator. This would convert a square wave into mostly continuous 0s or 1s, with occasional pulses where jitter occurs.
*** JH: This kind of thing is best prototyped with a script e.g python + the bitset library.
** FLAC (libflac) or a FLAC inspired codec (linear predicition) is probably as good as it gets for lossless analog data encoding.
* If data is stored in a format specific way, it would be best to store it as a series of stream-blocks, similar to how video containers work. Would it be possible to simply leverage a video container such as OGG? IIRC this contains headers to declare metadata about each stream, then a series of timestamped stream blocks interleaved together. The time stamp is a format specific number... for audio: the sample number, for video: the frame number, so sigrok formats can easily leverage this.
** Similarly RTP is a rather natural protocol for sigrok network streaming.

File format:Sigrok/v3

2017-10-07T23:29:28Z

Fenugrec: /* PACKET_MAP_UUIDS packet */ little -> big endian

{{DISPLAYTITLE:File format:sigrok/v3}}
This page describes the proposed file/stream format (v3) for storing and transmitting sigrok related data.

<div style="background-color:#ff6666">
NOTE: This is work in progress and has not yet been implemented!
</div>

== Motivation ==

The previous [[File format:sigrok/v2|sigrok session]] file format (version 2) is a ZIP file containing multiple files (some metadata files and data files containing the actual samples). This works fine, but it also has some issues:

* In order to get to the data you want, you need to decompress the whole file.
* Appending to a file is not possible easily (and it's not efficient).
* It doesn't support storing additional information for frontends (channel colors, and so on).
* ...

== Goals ==

The following list highlights some of the goals of the new file format (v3):

* It must be able to store
** arbitrary data (logic samples, and/or analog samples, and/or protocol decoder data, and more), as well as
** arbitrary meta-/config-data and other extra information that may be useful to frontends (UI state data, user-configured probe colors, names, positions, and so on).
* It must support and facilitate stream-oriented processing (save, load, transmission, compression/decompression, and so on).
* It must support compression of the payload data.
* It must be usable independent of hardware architecture (x86, ARM, PowerPC, MIPS, and so on), operating system, endianness, float representation, and so on. All data fields must be properly specified (endianness, signedness, size, format).
* It must allow for sufficiently good performance for the common operations a frontend needs to perform on the data/file/stream (save, load, compress/uncompress, append, and so on) so that it doesn't become the bottleneck. This is especially important for stream-oriented devices which could otherwise lose samples if the processing on the host side is not sufficiently fast ([[Saleae Logic]], [[Saleae Logic16]], [[IKALOGIC ScanaPLUS]], others).
* It should be able to handle run-time changes in the data streams (via meta packets on the session bus), e.g. changing samplerates, changing probes, etc. etc.
* It should have better compression properties than ZIP (e.g. using LZO or other algorithms, this is to be evaluated). What we ideally want out of the compression algorithm is:
** Good and relatively fast compression results at only moderate CPU usage.
** Very fast decompression (LZO is probably the best one here, as it's specifically designed for this).
** Ideally, support for appending further data to already compressed data chunks (though this could be also implemented outside of the compression algorithm per se).
** Open-source license and OS portability. There should be an open-source library or code chunk for compression/uncompression and it should be widely available in Linux distros, and portable to Windows, Mac OS X, FreeBSD, Android, and so on.

== Specification ==

== UUIDs ==

The format uses random [http://en.wikipedia.org/wiki/Universally_unique_identifier UUIDs] (version 4) as per [http://tools.ietf.org/html/rfc4122 RFC4122] in various places. These UUIDs are always 16 bytes long.

A simple way to generate a random (version 4) UUID (ASCII and hex representation):


$ '''python3 -c 'import uuid; u = uuid.uuid4(); print(u); print(u.hex)''''
14c49f22-f08a-4ef2-b3d7-82ee16c3d531
14c49f22f08a4ef2b3d782ee16c3d531


== File/stream format ==

The format consists entirely of a stream of packets of various types.

These packets can be either written to or read from a file, buffer, pipe, socket, or any other source/destination.

== Packet format ==

Every packet consists of four fields:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Short-UUID'''
| 2
| An ID (2 bytes, big-endian) that maps to a previously defined 16-byte packet type UUID. The Short-UUID values can range from 0x0002 to 0xffff, which allows for 65535 different packet types in a single file/stream. The Short-UUIDs 0x0000 and 0x0001 are special and cannot be used for "normal" packets, see below. The reason for using a (Short-)UUID here instead of some simple index number is to allow for clients to define and use their own special-purpose packet types as they see fit, without having to fear any conflicts with existing packet types (or packet types that someone else might add later).

|-
| '''Reference-ID'''
| 4
| An ID (4 bytes, big-endian) that is assigned to this packet, so that other packets can reference it. Valid values: 0x00000001 - 0xffffffff. A value of 0x00000000 means that this packet doesn't have a Reference-ID. Note that a (Short-)UUID specifies a certain ''type'' of packet, whereas the Reference-ID identifies a specific ''individual'' packet. For example, there can be multiple different packets (different Reference-ID) that are of the same type (same Short-UUID).

|-
| '''Length'''
| 4
| The length of the data in this packet (in number of bytes; big-endian). The length does not include the length of the '''Short-UUID''', '''Reference-ID''' or '''Length''' field, only the length of the '''Data''' field. The length is given as an uint32_t number (little-endian).

|-
| '''Data'''
| 0..n
| The actual payload data, max. 2^32 bytes (4GiB). For some packet types the '''Data''' field is optional (in that case it is completely omitted and the '''Length''' field is set to 0). The contents of the '''Data''' field are entirely dependent on (and vary with) the type of packet.

|}

Using the common [http://en.wikipedia.org/wiki/Type-length-value type-length-value] idom for each packet allows clients to easily skip over (ignore) any packets they do not know how to handle, and instead continue on to checking/handling the next packet.

'''Example packet with a 7-byte data field (Short-UUID is 0x55aa, Reference-ID is 0x00008ab2):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 55 aa
| 00 00 8a b2
| 00 00 00 07
| 11 22 33 44 55 66 77

|}

'''Example packet without a data field (Short-UUID is 0x55aa, Reference-ID is 0x00005f31):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| 55 aa
| 00 00 5f 31
| 00 00 00 00

|}

== PACKET_MAP_UUIDS packet ==

This is a special packet that is used to map 16-byte UUIDs to 2-byte Short-UUIDs.

Since every packet has a 2-byte Short-UUID, PACKET_MAP_UUIDS must be the first packet in a file/stream, otherwise the client will not be able to interpret any other packets.

However, PACKET_MAP_UUIDS can occur multiple times in a stream. Every time PACKET_MAP_UUIDS is seen, mappings that were not yet defined are added to the list of mappings, and mappings that already existed will be overwritten with the respective new mapping.

Since PACKET_MAP_UUIDS is a packet itself, it also consists of the four common fields Short-UUID/Reference-ID/Length/Data. The Short-UUID of PACKET_MAP_UUIDS is always '''0x0000'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Special Short-UUID for magic marker'''
| 2
| A reserved special Short-UUID (2 bytes, big-endian) for the magic marker. Value: '''0x0001'''.

|-
| '''Special UUID for magic marker'''
| 16
| This is a special marker that can be used by the '''file''' utility (and other tools) to detect the file format easily. Contents: '''$sIgRoK$$sIgRoK$'''.

|-
| '''Short-UUID 1'''
| 2
| The 2-byte Short-UUID (2 bytes, big-endian) with index 1 (valid values: 0x0002 to 0xffff) that will, from now on, map to the UUID specified below.

|-
| '''UUID 1'''
| 16
| The UUID with index 1 (binary representation, 16 bytes, big-endian) which identifies the type of packet (globally unique).

|-
| '''Short-UUID 2'''
| 2
| The 2-byte Short-UUID with index 2 (valid values: 0x0002 to 0xffff ; big-endian) that will, from now on, map to the UUID specified below.

|-
| '''UUID 2'''
| 16
| The UUID with index 2 (binary representation, 16 bytes, big-endian) which identifies the type of packet (globally unique).

|-
| ...
| ...
| ...

|}

Important notes:

* The '''Data''' field contains a list of Short-UUID to UUID mappings. Since every such pair is 18 bytes in size, the '''Length''' field of PACKET_MAP_UUIDS can be used to deduce how many such mappings are contained in the '''Data''' field.
* The special "magic marker" fields (2 + 16 bytes) are required to be in every PACKET_MAP_UUIDS and are required to always be the first entries of PACKET_MAP_UUIDS. The file format can thus easily be detected by looking at the unique bytes 10-27 in the file (additionally, the file also always starts with the two bytes 0x00 0x00).
* The special Short-UUID 0x0000 must not be used in any mapping, it is reserved for PACKET_MAP_UUIDS itself.
* The special Short-UUID 0x0001 must not be used in any mapping, it is reserved for the special "magic marker", see above.
* There is no guarantee of any kind about which Short-UUIDs will be mapped (and to what). Specifically, a client can '''not''' assume that Short-UUIDs start at 0x0002, and it can '''not''' assume that Short-UUIDs are ordered in any way. The Short-UUIDs can have a completely random order and they can also have gaps.
* Mappings are generally not static in nature. Every additional PACKET_MAP_UUIDS that occurs can dynamically add or overwrite/change mappings, for example.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 00 00
| ''xx xx xx xx''
| 00 00 00 48
| <tt>00 01 24 73 49 67 52 6f 4b 24 24 73 49 67 52 6f 4b 24 77 a1 5a 17 72 eb 28 54 48 a8 a4 1c 73 97 d7 e9 22 3d 00 06 59 de f3 30 53 6a 46 b1 8e dd 62 f2 19 5d 1c 95 a3 9f ec 6b d7 63 c8 79 4a a7 a9 7a 7e df 0e 68 af c7</tt>

|}

The above PACKET_MAP_UUIDS maps three different UUIDs to the Short-UUIDs 0x77a1, 0x0006 and 0xa39f.

== sigrok packets ==

The following packets are currently defined for use in projects hosted on [http://sigrok.org sigrok.org].

The "names" (e.g. "SIGROK_PACKET_LOGIC") are for documentation purposes only, the (Short-)UUIDs are what actually matters. The names are prefixed with SIGROK_ to make it clear that other 3rd-party software may define their own additional packet types with arbitrary contents and for arbitrary purposes.

One of the reasons for splitting up different properties into many small packets (SIGROK_PACKET_CHANNEL_TYPE, SIGROK_PACKET_CHANNEL_NAME, and so on) is that this allows for future additions (of e.g. various other channel properties), without the need to change an existing packet format. Additional packets for e.g. the channel color (for use in UIs) that also back-reference a SIGROK_PACKET_CHANNEL packet can be added without the need for protocol/format changes or version field bumps.

=== SIGROK_PACKET_DEVICE ===

This is a packet type used to define a device.

This packet uses the fixed UUID '''94aa863d-bb58-4d79-b944-ab9dd30eecdf'''.

The '''Data''' field is empty.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 00

|}

=== SIGROK_PACKET_DEVICE_VENDOR_NAME ===

This is a packet type used to define a device vendor name.

This packet uses the fixed UUID '''c09c7a5c-8566-42ec-8fde-7737436b0e64'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Vendor name length'''
| 2
| The length in number of bytes of the vendor name (2 bytes, little-endian).

|-
| '''Vendor name'''
| n
| The vendor name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a vendor name "Saleae" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0c
| ''bb bb bb bb'' 00 06 Saleae

|}

=== SIGROK_PACKET_DEVICE_MODEL_NAME ===

This is a packet type used to define a device model name.

This packet uses the fixed UUID '''88058d2f-225e-4ee6-b915-9fd009944464'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Model name length'''
| 2
| The length in number of bytes of the model name (2 bytes, little-endian).

|-
| '''Model name'''
| n
| The model name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a model name "Logic16" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0d
| ''bb bb bb bb'' 00 07 Logic16

|}

=== SIGROK_PACKET_DEVICE_VERSION ===

=== SIGROK_PACKET_DEVICE_SERIAL_NUMBER ===

=== SIGROK_PACKET_DEVICE_CONNECTION_ID ===

=== SIGROK_PACKET_CHANNEL_GROUP ===

=== SIGROK_PACKET_CHANNEL_GROUP_NAME ===

=== SIGROK_PACKET_CHANNEL ===

This is a packet type used to define a channel.

This packet uses the fixed UUID '''1325b595-0d5e-40a4-ac4d-36e89224dcb9'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE) that the channel belongs to.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 04
| <tt>''bb bb bb bb''

|}

=== SIGROK_PACKET_CHANNEL_TYPE ===

This is a packet type used to define a channel type.

This packet uses the fixed UUID '''6b12bdcc-02c8-493a-a89d-662ee9d1a34d'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel type'''
| 1
| The type of the back-referenced channel. '''0x01''': Logic, '''0x02''': Analog.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 05
| ''bb bb bb bb'' 01

|}

=== SIGROK_PACKET_CHANNEL_NAME ===

This is a packet type used to define a channel name.

This packet uses the fixed UUID '''730ba9b7-638a-4b79-94dc-b9beb0735acf'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel name length'''
| 2
| The length in number of bytes of the channel name (2 bytes, little-endian).

|-
| '''Channel name'''
| n
| The channel name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a channel name "CH1" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined channel for which this name is to apply.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 09
| ''bb bb bb bb'' 00 03 CH1

|}

=== SIGROK_PACKET_LOGIC ===

This is a packet type used to store/transmit (only) digital samples, usually from a logic analyzer.

This packet uses the fixed UUID '''2236202e-9ee7-4bc6-81f6-56b4e6e029ba'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Version'''
| 2
| The version of the SIGROK_PACKET_LOGIC format in binary format (little-endian). Current version: '''0x0001'''.

|-
| '''Payload format Short-UUID'''
| 2
| A Short-UUID (2 bytes, little-endian) which identifies a certain payload format.

|-
| '''Compression scheme Short-UUID'''
| 2
| A Short-UUID (2 bytes, little-endian) which identifies a certain compression scheme that is applied to the payload data.

|-
| '''Payload length'''
| 4
| The length of the actual payload data in this SIGROK_PACKET_LOGIC packet (in number of bytes). The length only includes the '''Payload''' field. The length is given as an uint32_t number (little-endian).

|-
| '''Payload'''
| 0..n
| The actual payload data, i.e. logic analyzer samples in the specified payload format, using the specified compression scheme.

|}

'''Example packet:'''

(Packet type SIGROK_PACKET_LOGIC Short-UUID ''0xuuuu'', Reference-ID ''0xtttttttt'', 0x12 bytes packet data, SIGROK_PACKET_LOGIC version 0x0001, SIGROK_PAYLOAD_FORMAT_LOGIC_V1 payload format Short-UUID ''0xvvvv'', SIGROK_COMPRESSION_NONE compression scheme Short-UUID ''0xwwww'', 8 bytes of logic analyzer payload (uncompressed))

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 12
| 00 01 ''vv vv'' ''ww ww'' 00 00 00 08 11 22 33 44 55 66 77 88

|}

SA: How does the mapping to the individual channels work? Do we need to backreference a channel group here that declares e.g. which 8 logic channels make up one such logic packet and in which order they are stored?

=== SIGROK_PACKET_ANALOG ===

This is a packet type used to store/transmit (only) analog samples, e.g. from a multimeter, oscilloscope, sound level meter, or any other source for analog data.

This packet uses the fixed UUID '''59def330-536a-46b1-8edd-62f2195d1c95'''.

Details yet to be defined.

== List of known packet types ==

This is a short overview of known packet types that are in use. This includes the packet types used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to packet types that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Packet type
!Description

|-
| 94aa863d-bb58-4d79-b944-ab9dd30eecdf
| SIGROK_PACKET_DEVICE
| [[File format:sigrok#SIGROK_PACKET_DEVICE|See above]].

|-
| 1325b595-0d5e-40a4-ac4d-36e89224dcb9
| SIGROK_PACKET_CHANNEL
| [[File format:sigrok#SIGROK_PACKET_CHANNEL|See above]].

|-
| 5a1772eb-2854-48a8-a41c-7397d7e9223d
| SIGROK_PACKET_LOGIC
| [[File format:sigrok#SIGROK_PACKET_LOGIC|See above]].

|-
| 59def330-536a-46b1-8edd-62f2195d1c95
| SIGROK_PACKET_ANALOG
| [[File format:sigrok#SIGROK_PACKET_ANALOG|See above]].

|}

== List of known payload formats ==

This is a short overview of known payload formats that are in use. This includes the payload formats used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to payload formats that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Payload format
!Description

|-
| style="white-space: nowrap;" | d2964f38-8b13-4570-9add-add5678a0394
| SIGROK_PAYLOAD_FORMAT_LOGIC_V1
| This payload format can only store digital samples from a logic analyzer (0/1 values for a certain channel/probe/pin). It is basically identical to the format that was used in the previous ZIP-based file format versions. Details are yet to be defined.

|-
| 79e7cfd1-0f56-4d5e-968a-b66fdbdff624
| SIGROK_PAYLOAD_FORMAT_ANALOG_V1
| A certain type of payload format that can store (only) analog samples of a certain number of analog channels. Details are yet to be defined.

|}

== List of known compression schemes ==

This is a short overview of known compression schemes that are in use. This includes the schemes used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to schemes that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Compression scheme
!Description

|-
| ec6bd763-c879-4aa7-a97a-7edf0e68afc7
| SIGROK_COMPRESSION_NONE
| No compression whatsoever is used.

|-
| acd2e249-5c4d-426d-96ae-ded5b6020e6f
| SIGROK_COMPRESSION_RLE_V1
| A certain type of RLE-based compression is used. Details are yet to be defined.

|}

* JH: Do we need info about interleaving here? We could insist that all channels be de-intereleaved, or add support for interleaved streams.
* JH: Would could add support for device compression schemes. It may sometimes be desirable to be able to pass the device stream straight into the file.

== Futher notes and ideas to consider ==

* SA: Currently, the sample rate isn't declared anywhere. Do we do this on a per-device or per-channel basis? My guts tell me that it's probably wiser to do it on a per-channel basis, even if all channels have the same sample rate.
* Data should be encoded in a data aware way. This would give greater compression:
** Logic Data is most efficient stored in RLE+Huffman or Golomb coding. e.g. a clock signal may compress to one bit per edge.
*** JH: I wonder if we can do even better by XOR-ing the data with some kind of frequency tracking oscillator. This would convert a square wave into mostly continuous 0s or 1s, with occasional pulses where jitter occurs.
*** JH: This kind of thing is best prototyped with a script e.g python + the bitset library.
** FLAC (libflac) or a FLAC inspired codec (linear predicition) is probably as good as it gets for lossless analog data encoding.
* If data is stored in a format specific way, it would be best to store it as a series of stream-blocks, similar to how video containers work. Would it be possible to simply leverage a video container such as OGG? IIRC this contains headers to declare metadata about each stream, then a series of timestamped stream blocks interleaved together. The time stamp is a format specific number... for audio: the sample number, for video: the frame number, so sigrok formats can easily leverage this.
** Similarly RTP is a rather natural protocol for sigrok network streaming.

File format:Sigrok/v3

2017-10-07T23:22:03Z

Fenugrec: /* Packet format */ change field endianness to big-endian, to match examples and intent

{{DISPLAYTITLE:File format:sigrok/v3}}
This page describes the proposed file/stream format (v3) for storing and transmitting sigrok related data.

<div style="background-color:#ff6666">
NOTE: This is work in progress and has not yet been implemented!
</div>

== Motivation ==

The previous [[File format:sigrok/v2|sigrok session]] file format (version 2) is a ZIP file containing multiple files (some metadata files and data files containing the actual samples). This works fine, but it also has some issues:

* In order to get to the data you want, you need to decompress the whole file.
* Appending to a file is not possible easily (and it's not efficient).
* It doesn't support storing additional information for frontends (channel colors, and so on).
* ...

== Goals ==

The following list highlights some of the goals of the new file format (v3):

* It must be able to store
** arbitrary data (logic samples, and/or analog samples, and/or protocol decoder data, and more), as well as
** arbitrary meta-/config-data and other extra information that may be useful to frontends (UI state data, user-configured probe colors, names, positions, and so on).
* It must support and facilitate stream-oriented processing (save, load, transmission, compression/decompression, and so on).
* It must support compression of the payload data.
* It must be usable independent of hardware architecture (x86, ARM, PowerPC, MIPS, and so on), operating system, endianness, float representation, and so on. All data fields must be properly specified (endianness, signedness, size, format).
* It must allow for sufficiently good performance for the common operations a frontend needs to perform on the data/file/stream (save, load, compress/uncompress, append, and so on) so that it doesn't become the bottleneck. This is especially important for stream-oriented devices which could otherwise lose samples if the processing on the host side is not sufficiently fast ([[Saleae Logic]], [[Saleae Logic16]], [[IKALOGIC ScanaPLUS]], others).
* It should be able to handle run-time changes in the data streams (via meta packets on the session bus), e.g. changing samplerates, changing probes, etc. etc.
* It should have better compression properties than ZIP (e.g. using LZO or other algorithms, this is to be evaluated). What we ideally want out of the compression algorithm is:
** Good and relatively fast compression results at only moderate CPU usage.
** Very fast decompression (LZO is probably the best one here, as it's specifically designed for this).
** Ideally, support for appending further data to already compressed data chunks (though this could be also implemented outside of the compression algorithm per se).
** Open-source license and OS portability. There should be an open-source library or code chunk for compression/uncompression and it should be widely available in Linux distros, and portable to Windows, Mac OS X, FreeBSD, Android, and so on.

== Specification ==

== UUIDs ==

The format uses random [http://en.wikipedia.org/wiki/Universally_unique_identifier UUIDs] (version 4) as per [http://tools.ietf.org/html/rfc4122 RFC4122] in various places. These UUIDs are always 16 bytes long.

A simple way to generate a random (version 4) UUID (ASCII and hex representation):


$ '''python3 -c 'import uuid; u = uuid.uuid4(); print(u); print(u.hex)''''
14c49f22-f08a-4ef2-b3d7-82ee16c3d531
14c49f22f08a4ef2b3d782ee16c3d531


== File/stream format ==

The format consists entirely of a stream of packets of various types.

These packets can be either written to or read from a file, buffer, pipe, socket, or any other source/destination.

== Packet format ==

Every packet consists of four fields:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Short-UUID'''
| 2
| An ID (2 bytes, big-endian) that maps to a previously defined 16-byte packet type UUID. The Short-UUID values can range from 0x0002 to 0xffff, which allows for 65535 different packet types in a single file/stream. The Short-UUIDs 0x0000 and 0x0001 are special and cannot be used for "normal" packets, see below. The reason for using a (Short-)UUID here instead of some simple index number is to allow for clients to define and use their own special-purpose packet types as they see fit, without having to fear any conflicts with existing packet types (or packet types that someone else might add later).

|-
| '''Reference-ID'''
| 4
| An ID (4 bytes, big-endian) that is assigned to this packet, so that other packets can reference it. Valid values: 0x00000001 - 0xffffffff. A value of 0x00000000 means that this packet doesn't have a Reference-ID. Note that a (Short-)UUID specifies a certain ''type'' of packet, whereas the Reference-ID identifies a specific ''individual'' packet. For example, there can be multiple different packets (different Reference-ID) that are of the same type (same Short-UUID).

|-
| '''Length'''
| 4
| The length of the data in this packet (in number of bytes; big-endian). The length does not include the length of the '''Short-UUID''', '''Reference-ID''' or '''Length''' field, only the length of the '''Data''' field. The length is given as an uint32_t number (little-endian).

|-
| '''Data'''
| 0..n
| The actual payload data, max. 2^32 bytes (4GiB). For some packet types the '''Data''' field is optional (in that case it is completely omitted and the '''Length''' field is set to 0). The contents of the '''Data''' field are entirely dependent on (and vary with) the type of packet.

|}

Using the common [http://en.wikipedia.org/wiki/Type-length-value type-length-value] idom for each packet allows clients to easily skip over (ignore) any packets they do not know how to handle, and instead continue on to checking/handling the next packet.

'''Example packet with a 7-byte data field (Short-UUID is 0x55aa, Reference-ID is 0x00008ab2):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 55 aa
| 00 00 8a b2
| 00 00 00 07
| 11 22 33 44 55 66 77

|}

'''Example packet without a data field (Short-UUID is 0x55aa, Reference-ID is 0x00005f31):'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| 55 aa
| 00 00 5f 31
| 00 00 00 00

|}

== PACKET_MAP_UUIDS packet ==

This is a special packet that is used to map 16-byte UUIDs to 2-byte Short-UUIDs.

Since every packet has a 2-byte Short-UUID, PACKET_MAP_UUIDS must be the first packet in a file/stream, otherwise the client will not be able to interpret any other packets.

However, PACKET_MAP_UUIDS can occur multiple times in a stream. Every time PACKET_MAP_UUIDS is seen, mappings that were not yet defined are added to the list of mappings, and mappings that already existed will be overwritten with the respective new mapping.

Since PACKET_MAP_UUIDS is a packet itself, it also consists of the four common fields Short-UUID/Reference-ID/Length/Data. The Short-UUID of PACKET_MAP_UUIDS is always '''0x0000'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Special Short-UUID for magic marker'''
| 2
| A reserved special Short-UUID (2 bytes, little-endian) for the magic marker. Value: '''0x0001'''.

|-
| '''Special UUID for magic marker'''
| 16
| This is a special marker that can be used by the '''file''' utility (and other tools) to detect the file format easily. Contents: '''$sIgRoK$$sIgRoK$'''.

|-
| '''Short-UUID 1'''
| 2
| The 2-byte Short-UUID with index 1 (valid values: 0x0002 to 0xffff) that will, from now on, map to the UUID specified below.

|-
| '''UUID 1'''
| 16
| The UUID with index 1 (binary representation, 16 bytes, little-endian) which identifies the type of packet (globally unique).

|-
| '''Short-UUID 2'''
| 2
| The 2-byte Short-UUID with index 2 (valid values: 0x0002 to 0xffff) that will, from now on, map to the UUID specified below.

|-
| '''UUID 2'''
| 16
| The UUID with index 2 (binary representation, 16 bytes, little-endian) which identifies the type of packet (globally unique).

|-
| ...
| ...
| ...

|}

Important notes:

* The '''Data''' field contains a list of Short-UUID to UUID mappings. Since every such pair is 18 bytes in size, the '''Length''' field of PACKET_MAP_UUIDS can be used to deduce how many such mappings are contained in the '''Data''' field.
* The special "magic marker" fields (2 + 16 bytes) are required to be in every PACKET_MAP_UUIDS and are required to always be the first entries of PACKET_MAP_UUIDS. The file format can thus easily be detected by looking at the unique bytes 10-27 in the file (additionally, the file also always starts with the two bytes 0x00 0x00).
* The special Short-UUID 0x0000 must not be used in any mapping, it is reserved for PACKET_MAP_UUIDS itself.
* The special Short-UUID 0x0001 must not be used in any mapping, it is reserved for the special "magic marker", see above.
* There is no guarantee of any kind about which Short-UUIDs will be mapped (and to what). Specifically, a client can '''not''' assume that Short-UUIDs start at 0x0002, and it can '''not''' assume that Short-UUIDs are ordered in any way. The Short-UUIDs can have a completely random order and they can also have gaps.
* Mappings are generally not static in nature. Every additional PACKET_MAP_UUIDS that occurs can dynamically add or overwrite/change mappings, for example.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| 00 00
| ''xx xx xx xx''
| 00 00 00 48
| <tt>00 01 24 73 49 67 52 6f 4b 24 24 73 49 67 52 6f 4b 24 77 a1 5a 17 72 eb 28 54 48 a8 a4 1c 73 97 d7 e9 22 3d 00 06 59 de f3 30 53 6a 46 b1 8e dd 62 f2 19 5d 1c 95 a3 9f ec 6b d7 63 c8 79 4a a7 a9 7a 7e df 0e 68 af c7</tt>

|}

The above PACKET_MAP_UUIDS maps three different UUIDs to the Short-UUIDs 0x77a1, 0x0006 and 0xa39f.

== sigrok packets ==

The following packets are currently defined for use in projects hosted on [http://sigrok.org sigrok.org].

The "names" (e.g. "SIGROK_PACKET_LOGIC") are for documentation purposes only, the (Short-)UUIDs are what actually matters. The names are prefixed with SIGROK_ to make it clear that other 3rd-party software may define their own additional packet types with arbitrary contents and for arbitrary purposes.

One of the reasons for splitting up different properties into many small packets (SIGROK_PACKET_CHANNEL_TYPE, SIGROK_PACKET_CHANNEL_NAME, and so on) is that this allows for future additions (of e.g. various other channel properties), without the need to change an existing packet format. Additional packets for e.g. the channel color (for use in UIs) that also back-reference a SIGROK_PACKET_CHANNEL packet can be added without the need for protocol/format changes or version field bumps.

=== SIGROK_PACKET_DEVICE ===

This is a packet type used to define a device.

This packet uses the fixed UUID '''94aa863d-bb58-4d79-b944-ab9dd30eecdf'''.

The '''Data''' field is empty.

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 00

|}

=== SIGROK_PACKET_DEVICE_VENDOR_NAME ===

This is a packet type used to define a device vendor name.

This packet uses the fixed UUID '''c09c7a5c-8566-42ec-8fde-7737436b0e64'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Vendor name length'''
| 2
| The length in number of bytes of the vendor name (2 bytes, little-endian).

|-
| '''Vendor name'''
| n
| The vendor name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a vendor name "Saleae" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0c
| ''bb bb bb bb'' 00 06 Saleae

|}

=== SIGROK_PACKET_DEVICE_MODEL_NAME ===

This is a packet type used to define a device model name.

This packet uses the fixed UUID '''88058d2f-225e-4ee6-b915-9fd009944464'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE).

|-
| '''Model name length'''
| 2
| The length in number of bytes of the model name (2 bytes, little-endian).

|-
| '''Model name'''
| n
| The model name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a model name "Logic16" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined device.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 0d
| ''bb bb bb bb'' 00 07 Logic16

|}

=== SIGROK_PACKET_DEVICE_VERSION ===

=== SIGROK_PACKET_DEVICE_SERIAL_NUMBER ===

=== SIGROK_PACKET_DEVICE_CONNECTION_ID ===

=== SIGROK_PACKET_CHANNEL_GROUP ===

=== SIGROK_PACKET_CHANNEL_GROUP_NAME ===

=== SIGROK_PACKET_CHANNEL ===

This is a packet type used to define a channel.

This packet uses the fixed UUID '''1325b595-0d5e-40a4-ac4d-36e89224dcb9'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined device (SIGROK_PACKET_DEVICE) that the channel belongs to.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 04
| <tt>''bb bb bb bb''

|}

=== SIGROK_PACKET_CHANNEL_TYPE ===

This is a packet type used to define a channel type.

This packet uses the fixed UUID '''6b12bdcc-02c8-493a-a89d-662ee9d1a34d'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel type'''
| 1
| The type of the back-referenced channel. '''0x01''': Logic, '''0x02''': Analog.

|}

'''Example packet:'''

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 05
| ''bb bb bb bb'' 01

|}

=== SIGROK_PACKET_CHANNEL_NAME ===

This is a packet type used to define a channel name.

This packet uses the fixed UUID '''730ba9b7-638a-4b79-94dc-b9beb0735acf'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Backreference-ID'''
| 4
| A Reference-ID (4 bytes, little-endian) referencing a previously defined channel (SIGROK_PACKET_CHANNEL).

|-
| '''Channel name length'''
| 2
| The length in number of bytes of the channel name (2 bytes, little-endian).

|-
| '''Channel name'''
| n
| The channel name (UTF-8 string).

|}

'''Example packet:'''

The following packet defines a channel name "CH1" (with the Reference-ID ''tt tt tt tt''). The Backreference-ID ''bb bb bb bb'' references a previously defined channel for which this name is to apply.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 09
| ''bb bb bb bb'' 00 03 CH1

|}

=== SIGROK_PACKET_LOGIC ===

This is a packet type used to store/transmit (only) digital samples, usually from a logic analyzer.

This packet uses the fixed UUID '''2236202e-9ee7-4bc6-81f6-56b4e6e029ba'''.

The '''Data''' field has the following contents:

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Field
!Length
!Description

|-
| '''Version'''
| 2
| The version of the SIGROK_PACKET_LOGIC format in binary format (little-endian). Current version: '''0x0001'''.

|-
| '''Payload format Short-UUID'''
| 2
| A Short-UUID (2 bytes, little-endian) which identifies a certain payload format.

|-
| '''Compression scheme Short-UUID'''
| 2
| A Short-UUID (2 bytes, little-endian) which identifies a certain compression scheme that is applied to the payload data.

|-
| '''Payload length'''
| 4
| The length of the actual payload data in this SIGROK_PACKET_LOGIC packet (in number of bytes). The length only includes the '''Payload''' field. The length is given as an uint32_t number (little-endian).

|-
| '''Payload'''
| 0..n
| The actual payload data, i.e. logic analyzer samples in the specified payload format, using the specified compression scheme.

|}

'''Example packet:'''

(Packet type SIGROK_PACKET_LOGIC Short-UUID ''0xuuuu'', Reference-ID ''0xtttttttt'', 0x12 bytes packet data, SIGROK_PACKET_LOGIC version 0x0001, SIGROK_PAYLOAD_FORMAT_LOGIC_V1 payload format Short-UUID ''0xvvvv'', SIGROK_COMPRESSION_NONE compression scheme Short-UUID ''0xwwww'', 8 bytes of logic analyzer payload (uncompressed))

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable"
|-
!Short-UUID
!Reference-ID
!Length
!Data

|-
| ''uu uu''
| ''tt tt tt tt''
| 00 00 00 12
| 00 01 ''vv vv'' ''ww ww'' 00 00 00 08 11 22 33 44 55 66 77 88

|}

SA: How does the mapping to the individual channels work? Do we need to backreference a channel group here that declares e.g. which 8 logic channels make up one such logic packet and in which order they are stored?

=== SIGROK_PACKET_ANALOG ===

This is a packet type used to store/transmit (only) analog samples, e.g. from a multimeter, oscilloscope, sound level meter, or any other source for analog data.

This packet uses the fixed UUID '''59def330-536a-46b1-8edd-62f2195d1c95'''.

Details yet to be defined.

== List of known packet types ==

This is a short overview of known packet types that are in use. This includes the packet types used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to packet types that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Packet type
!Description

|-
| 94aa863d-bb58-4d79-b944-ab9dd30eecdf
| SIGROK_PACKET_DEVICE
| [[File format:sigrok#SIGROK_PACKET_DEVICE|See above]].

|-
| 1325b595-0d5e-40a4-ac4d-36e89224dcb9
| SIGROK_PACKET_CHANNEL
| [[File format:sigrok#SIGROK_PACKET_CHANNEL|See above]].

|-
| 5a1772eb-2854-48a8-a41c-7397d7e9223d
| SIGROK_PACKET_LOGIC
| [[File format:sigrok#SIGROK_PACKET_LOGIC|See above]].

|-
| 59def330-536a-46b1-8edd-62f2195d1c95
| SIGROK_PACKET_ANALOG
| [[File format:sigrok#SIGROK_PACKET_ANALOG|See above]].

|}

== List of known payload formats ==

This is a short overview of known payload formats that are in use. This includes the payload formats used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to payload formats that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Payload format
!Description

|-
| style="white-space: nowrap;" | d2964f38-8b13-4570-9add-add5678a0394
| SIGROK_PAYLOAD_FORMAT_LOGIC_V1
| This payload format can only store digital samples from a logic analyzer (0/1 values for a certain channel/probe/pin). It is basically identical to the format that was used in the previous ZIP-based file format versions. Details are yet to be defined.

|-
| 79e7cfd1-0f56-4d5e-968a-b66fdbdff624
| SIGROK_PAYLOAD_FORMAT_ANALOG_V1
| A certain type of payload format that can store (only) analog samples of a certain number of analog channels. Details are yet to be defined.

|}

== List of known compression schemes ==

This is a short overview of known compression schemes that are in use. This includes the schemes used in projects hosted at [http://sigrok.org sigrok.org], as well as pointers to schemes that other (3rd-party) software is known to use.

{| border="0" style="font-size: smaller;" class="alternategrey sigroktable sortable"
|-
!UUID
!Compression scheme
!Description

|-
| ec6bd763-c879-4aa7-a97a-7edf0e68afc7
| SIGROK_COMPRESSION_NONE
| No compression whatsoever is used.

|-
| acd2e249-5c4d-426d-96ae-ded5b6020e6f
| SIGROK_COMPRESSION_RLE_V1
| A certain type of RLE-based compression is used. Details are yet to be defined.

|}

* JH: Do we need info about interleaving here? We could insist that all channels be de-intereleaved, or add support for interleaved streams.
* JH: Would could add support for device compression schemes. It may sometimes be desirable to be able to pass the device stream straight into the file.

== Futher notes and ideas to consider ==

* SA: Currently, the sample rate isn't declared anywhere. Do we do this on a per-device or per-channel basis? My guts tell me that it's probably wiser to do it on a per-channel basis, even if all channels have the same sample rate.
* Data should be encoded in a data aware way. This would give greater compression:
** Logic Data is most efficient stored in RLE+Huffman or Golomb coding. e.g. a clock signal may compress to one bit per edge.
*** JH: I wonder if we can do even better by XOR-ing the data with some kind of frequency tracking oscillator. This would convert a square wave into mostly continuous 0s or 1s, with occasional pulses where jitter occurs.
*** JH: This kind of thing is best prototyped with a script e.g python + the bitset library.
** FLAC (libflac) or a FLAC inspired codec (linear predicition) is probably as good as it gets for lossless analog data encoding.
* If data is stored in a format specific way, it would be best to store it as a series of stream-blocks, similar to how video containers work. Would it be possible to simply leverage a video container such as OGG? IIRC this contains headers to declare metadata about each stream, then a series of timestamped stream blocks interleaved together. The time stamp is a format specific number... for audio: the sample number, for video: the frame number, so sigrok formats can easily leverage this.
** Similarly RTP is a rather natural protocol for sigrok network streaming.

Mcupro Logic16 clone

2016-04-10T02:02:54Z

Fenugrec: /* Hardware (2014-01-25 variant) */ confirmed FPGA !

{{DISPLAYTITLE:mcupro Logic16 clone}}
{{Infobox logic analyzer
| image = [[File:Mcupro_Logic16_overview.png|180px]]
| name = mcupro Logic16 clone
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = 1.5V (operates with 3.3V logic)
| memory = none
| compression = yes
| website = [http://www.aliexpress.com/store/product/USB-Logic-Analyzer-100M-max-sample-rate-16Channels-10B-samples-MCU-ARM-FPGA-debug-tool/614202_1916810169.html aliexpress.com]
}}

The '''mcupro Logic16 clone''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

This is a clone of the [[Saleae Logic16]].

See [[mcupro Logic16 clone/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware (Actel variant) ==

* '''FPGA''': [https://www.actel.com/documents/PA3_DS.pdf Actel A3P125]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal''': 24MHz

== Hardware (Cyclone variant) ==

* '''FPGA''': [https://www.altera.com/products/fpga/cyclone-series/cyclone/support.html#Cyclone-Device-Handbook--All-Sections- Altera Cyclone EP1C3T100]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': 100MHz
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': [http://www.stcmcu.com/datasheet/stc/STC-AD-PDF/STC15.pdf STCMCU 15F10], 8051 compatible

== Hardware (2015-01-08 variant) ==

The PCB is marked "Saleae Logic 16 By MCUPro 2015-1-8". Readily identifiable by the irregular PCB traces, and switching power supplies. This comes in a different case, identical to the [[Noname_XL-LOGIC16-100M]].

* '''FPGA''': Markings ground off
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 150k/680k resistors pair
* '''1.5V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 160k/240k resistors pair
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': Looks like 32MHz?
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': Not required?

== Hardware (2014-01-25 variant) ==

The PCB is marked "Saleae Logic 16 mcupro 2014.1.25".

* '''FPGA''': Markings ground off, but pinout and JTAG (IDCODE 0x020810dd) indicate an Altera Cyclone EP1C3T100.
* '''USB interface chip''': Markings sometimes ground off ? CY7C68013A
* '''Crystal (FX2)''': marked "DKF 24.000"
* '''Crystal (FPGA)''': marked "RAK32.00"
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics (see [https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p10a.pdf Micron M25P10] too)
* '''I²C EEPROM''': None ? (CY7C I2C port wired to FPGA pins)
* '''Bootstrap controller''': Markings ground off, pinout could indicate a [http://www.stcmcu.com/datasheet/stc/STC-AD-PDF/STC15.pdf STCMCU 15F10x] 8051-based mcu?
* '''3.3V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 150k/680k resistors pair
* '''1.5V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 160k/240k resistors pair
* '''Channel input buffering''': none, only simple resistor (510R) + TVS diode array protection (possibly [http://www.semtech.com/images/datasheet/srv05-4.pdf Semtech SRV05])

The bottom two channels are not GND, but SCK (sample clock out) and HCK (half of SCK out).

== Photos (Actel) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro_Logic16_top.jpeg|PCB, top
File:Mcupro_Logic16_bottom.jpeg|PCB, bottom
</gallery>

== Photos (Cyclone) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro Logic16 Variant2 top.jpg|PCB with Altera Cyclone, top
File:IMG 0207 v1.JPG|PCB with Altera Cyclone, bottom
File:Mcupro Logic16 Variant2 top flash+uC.jpg|PCB, top, 1MBit flash and STCMCU uC
</gallery>

== Photos (2015-01-08 variant) ==

<gallery>
File:Xl-logic16-100m-external.jpg|Device, top
File:Mcupro-2015-1-8-top-overview.jpg|PCB, top
File:Mcupro-2015-1-8-bottom-overview.jpg|PCB, bottom
File:Mcupro-2015-1-8-voltage-regulators.jpg|PCB, 3.3 and 1.5 voltage regulators
File:Mcupro-2015-1-8-bottom-markings-intact.jpg|PCB, bottom - chip markings intact
</gallery>

== Photos (2014-01-25 variant) ==

<gallery>
File:seleae-logic16-aliexpress-clone.jpg|Device, top
File:Mcupro-2014-1-25-top_ortho.jpg|PCB top detail
File:Mcupro-2014-1-25-bottom_ortho.jpg|PCB bottom detail
File:Mcupro-2014-1-25-top-overview.jpg|PCB, top
File:Mcupro-2014-1-25-bottom-overview.jpg|PCB, bottom

</gallery>

== Protocol ==

See [[Saleae_Logic16#Protocol]].

== Firmware ==

;Actel variant
: This logic analyzer works with unmodified Saleae software. The Actel FPGA has on-chip flash storage, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;Cyclone variant
: This logic analyzer works with unmodified Saleae software. The PCB contains an SPI flash chip, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;2015-01-08 variant
: Only requires an upload of Cypress FX2LP firmware to operate. Open-source binaries from [https://github.com/gregani/la16fw gregani] work, but must be renamed to '''saleae-logic16-fx2.fw'''. It also requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).
;2014-01-25 variant
: Seems to have the bitstream in internal flash, so it only requires an upload of Cypress FX2LP firmware in order to operate. This requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).

The firmware extraction steps are identical to [[Saleae_Logic16#Firmware|steps for Saleae Logic16]], however you only need to have '''saleae-logic16-fx2.fw''' installed.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Mcupro Logic16 clone

2016-04-07T20:26:53Z

Fenugrec: /* Hardware (Cyclone variant) */ datasheet link for STC15F10x mcu

{{DISPLAYTITLE:mcupro Logic16 clone}}
{{Infobox logic analyzer
| image = [[File:Mcupro_Logic16_overview.png|180px]]
| name = mcupro Logic16 clone
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = 1.5V (operates with 3.3V logic)
| memory = none
| compression = yes
| website = [http://www.aliexpress.com/store/product/USB-Logic-Analyzer-100M-max-sample-rate-16Channels-10B-samples-MCU-ARM-FPGA-debug-tool/614202_1916810169.html aliexpress.com]
}}

The '''mcupro Logic16 clone''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

This is a clone of the [[Saleae Logic16]].

See [[mcupro Logic16 clone/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware (Actel variant) ==

* '''FPGA''': [https://www.actel.com/documents/PA3_DS.pdf Actel A3P125]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal''': 24MHz

== Hardware (Cyclone variant) ==

* '''FPGA''': [https://www.altera.com/products/fpga/cyclone-series/cyclone/support.html#Cyclone-Device-Handbook--All-Sections- Altera Cyclone EP1C3T100]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': 100MHz
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': [http://www.stcmcu.com/datasheet/stc/STC-AD-PDF/STC15.pdf STCMCU 15F10], 8051 compatible

== Hardware (2015-01-08 variant) ==

The PCB is marked "Saleae Logic 16 By MCUPro 2015-1-8". Readily identifiable by the irregular PCB traces, and switching power supplies. This comes in a different case, identical to the [[Noname_XL-LOGIC16-100M]].

* '''FPGA''': Markings ground off
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 150k/680k resistors pair
* '''1.5V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 160k/240k resistors pair
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': Looks like 32MHz?
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': Not required?

== Hardware (2014-01-25 variant) ==

The PCB is marked "Saleae Logic 16 mcupro 2014.1.25".

* '''FPGA''': Markings ground off, pinout would indicate a Cyclone EP1C3 (JTAG IDCODE not confirmed yet)
* '''USB interface chip''': Markings sometimes ground off ? CY7C68013A
* '''Crystal (FX2)''': marked "DKF 24.000"
* '''Crystal (FPGA)''': marked "RAK32.00"
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics (see [https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p10a.pdf Micron M25P10] too)
* '''I²C EEPROM''': None ? (CY7C I2C port wired to FPGA pins)
* '''Bootstrap controller''': Markings ground off, pinout could indicate a [http://www.stcmcu.com/datasheet/stc/STC-AD-PDF/STC15.pdf STCMCU 15F10x] 8051-based mcu?
* '''3.3V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 150k/680k resistors pair
* '''1.5V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 160k/240k resistors pair
* '''Channel input buffering''': none, only simple resistor (510R) + TVS diode array protection (possibly [http://www.semtech.com/images/datasheet/srv05-4.pdf Semtech SRV05])

The bottom two channels are not GND, but SCK (sample clock out) and HCK (half of SCK out).

== Photos (Actel) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro_Logic16_top.jpeg|PCB, top
File:Mcupro_Logic16_bottom.jpeg|PCB, bottom
</gallery>

== Photos (Cyclone) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro Logic16 Variant2 top.jpg|PCB with Altera Cyclone, top
File:IMG 0207 v1.JPG|PCB with Altera Cyclone, bottom
File:Mcupro Logic16 Variant2 top flash+uC.jpg|PCB, top, 1MBit flash and STCMCU uC
</gallery>

== Photos (2015-01-08 variant) ==

<gallery>
File:Xl-logic16-100m-external.jpg|Device, top
File:Mcupro-2015-1-8-top-overview.jpg|PCB, top
File:Mcupro-2015-1-8-bottom-overview.jpg|PCB, bottom
File:Mcupro-2015-1-8-voltage-regulators.jpg|PCB, 3.3 and 1.5 voltage regulators
File:Mcupro-2015-1-8-bottom-markings-intact.jpg|PCB, bottom - chip markings intact
</gallery>

== Photos (2014-01-25 variant) ==

<gallery>
File:seleae-logic16-aliexpress-clone.jpg|Device, top
File:Mcupro-2014-1-25-top_ortho.jpg|PCB top detail
File:Mcupro-2014-1-25-bottom_ortho.jpg|PCB bottom detail
File:Mcupro-2014-1-25-top-overview.jpg|PCB, top
File:Mcupro-2014-1-25-bottom-overview.jpg|PCB, bottom

</gallery>

== Protocol ==

See [[Saleae_Logic16#Protocol]].

== Firmware ==

;Actel variant
: This logic analyzer works with unmodified Saleae software. The Actel FPGA has on-chip flash storage, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;Cyclone variant
: This logic analyzer works with unmodified Saleae software. The PCB contains an SPI flash chip, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;2015-01-08 variant
: Only requires an upload of Cypress FX2LP firmware to operate. Open-source binaries from [https://github.com/gregani/la16fw gregani] work, but must be renamed to '''saleae-logic16-fx2.fw'''. It also requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).
;2014-01-25 variant
: Seems to have the bitstream in internal flash, so it only requires an upload of Cypress FX2LP firmware in order to operate. This requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).

The firmware extraction steps are identical to [[Saleae_Logic16#Firmware|steps for Saleae Logic16]], however you only need to have '''saleae-logic16-fx2.fw''' installed.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Mcupro Logic16 clone

2016-04-07T20:26:13Z

Fenugrec: /* Hardware (2014-01-25 variant) */ clarified I2C EEPROM => bootstrap IC

{{DISPLAYTITLE:mcupro Logic16 clone}}
{{Infobox logic analyzer
| image = [[File:Mcupro_Logic16_overview.png|180px]]
| name = mcupro Logic16 clone
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = 1.5V (operates with 3.3V logic)
| memory = none
| compression = yes
| website = [http://www.aliexpress.com/store/product/USB-Logic-Analyzer-100M-max-sample-rate-16Channels-10B-samples-MCU-ARM-FPGA-debug-tool/614202_1916810169.html aliexpress.com]
}}

The '''mcupro Logic16 clone''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

This is a clone of the [[Saleae Logic16]].

See [[mcupro Logic16 clone/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware (Actel variant) ==

* '''FPGA''': [https://www.actel.com/documents/PA3_DS.pdf Actel A3P125]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal''': 24MHz

== Hardware (Cyclone variant) ==

* '''FPGA''': [https://www.altera.com/products/fpga/cyclone-series/cyclone/support.html#Cyclone-Device-Handbook--All-Sections- Altera Cyclone EP1C3T100]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': 100MHz
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': STCMCU 15F10, 8051 compatible

== Hardware (2015-01-08 variant) ==

The PCB is marked "Saleae Logic 16 By MCUPro 2015-1-8". Readily identifiable by the irregular PCB traces, and switching power supplies. This comes in a different case, identical to the [[Noname_XL-LOGIC16-100M]].

* '''FPGA''': Markings ground off
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 150k/680k resistors pair
* '''1.5V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 160k/240k resistors pair
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': Looks like 32MHz?
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': Not required?

== Hardware (2014-01-25 variant) ==

The PCB is marked "Saleae Logic 16 mcupro 2014.1.25".

* '''FPGA''': Markings ground off, pinout would indicate a Cyclone EP1C3 (JTAG IDCODE not confirmed yet)
* '''USB interface chip''': Markings sometimes ground off ? CY7C68013A
* '''Crystal (FX2)''': marked "DKF 24.000"
* '''Crystal (FPGA)''': marked "RAK32.00"
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics (see [https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p10a.pdf Micron M25P10] too)
* '''I²C EEPROM''': None ? (CY7C I2C port wired to FPGA pins)
* '''Bootstrap controller''': Markings ground off, pinout could indicate a [http://www.stcmcu.com/datasheet/stc/STC-AD-PDF/STC15.pdf STCMCU 15F10x] 8051-based mcu?
* '''3.3V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 150k/680k resistors pair
* '''1.5V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 160k/240k resistors pair
* '''Channel input buffering''': none, only simple resistor (510R) + TVS diode array protection (possibly [http://www.semtech.com/images/datasheet/srv05-4.pdf Semtech SRV05])

The bottom two channels are not GND, but SCK (sample clock out) and HCK (half of SCK out).

== Photos (Actel) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro_Logic16_top.jpeg|PCB, top
File:Mcupro_Logic16_bottom.jpeg|PCB, bottom
</gallery>

== Photos (Cyclone) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro Logic16 Variant2 top.jpg|PCB with Altera Cyclone, top
File:IMG 0207 v1.JPG|PCB with Altera Cyclone, bottom
File:Mcupro Logic16 Variant2 top flash+uC.jpg|PCB, top, 1MBit flash and STCMCU uC
</gallery>

== Photos (2015-01-08 variant) ==

<gallery>
File:Xl-logic16-100m-external.jpg|Device, top
File:Mcupro-2015-1-8-top-overview.jpg|PCB, top
File:Mcupro-2015-1-8-bottom-overview.jpg|PCB, bottom
File:Mcupro-2015-1-8-voltage-regulators.jpg|PCB, 3.3 and 1.5 voltage regulators
File:Mcupro-2015-1-8-bottom-markings-intact.jpg|PCB, bottom - chip markings intact
</gallery>

== Photos (2014-01-25 variant) ==

<gallery>
File:seleae-logic16-aliexpress-clone.jpg|Device, top
File:Mcupro-2014-1-25-top_ortho.jpg|PCB top detail
File:Mcupro-2014-1-25-bottom_ortho.jpg|PCB bottom detail
File:Mcupro-2014-1-25-top-overview.jpg|PCB, top
File:Mcupro-2014-1-25-bottom-overview.jpg|PCB, bottom

</gallery>

== Protocol ==

See [[Saleae_Logic16#Protocol]].

== Firmware ==

;Actel variant
: This logic analyzer works with unmodified Saleae software. The Actel FPGA has on-chip flash storage, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;Cyclone variant
: This logic analyzer works with unmodified Saleae software. The PCB contains an SPI flash chip, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;2015-01-08 variant
: Only requires an upload of Cypress FX2LP firmware to operate. Open-source binaries from [https://github.com/gregani/la16fw gregani] work, but must be renamed to '''saleae-logic16-fx2.fw'''. It also requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).
;2014-01-25 variant
: Seems to have the bitstream in internal flash, so it only requires an upload of Cypress FX2LP firmware in order to operate. This requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).

The firmware extraction steps are identical to [[Saleae_Logic16#Firmware|steps for Saleae Logic16]], however you only need to have '''saleae-logic16-fx2.fw''' installed.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Saleae Logic16

2016-04-07T18:05:04Z

Fenugrec: /* Hardware */ updated C7C68013A datasheet URL

{{Infobox logic analyzer
| image = [[File:Saleae Logic16 bottom.png|180px]]
| name = Saleae Logic16
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = configurable: for 1.8V to 3.6V systems: VIH=1.4V, VIL=0.7V for 5V systems: VIH=3.6V, VIL=1.4V
| memory = none
| compression = yes
| website = [http://www.saleae.com/logic16/ saleae.com]
}}

The '''Saleae Logic16''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

The case requires a '''Torx T5''' screwdriver to open.

See [[Saleae Logic16/Info]] for more details (such as '''lsusb -v''' output) about the device.

See [[Saleae Logic]] for the predecessor product of the Saleae Logic16.

== Hardware ==

* '''FPGA''': [http://www.xilinx.com/support/index.html/content/xilinx/en/supportNav/silicon_devices/fpga/spartan-3a.html Xilinx Spartan-3A XC3S200A], 200K gates ([http://www.xilinx.com/support/documentation/data_sheets/ds529.pdf datasheeet])
* '''USB interface chip''': [http://www.cypress.com/?mpn=CY7C68013A-56PVXC Cypress CY7C68013A-56PVXC (FX2LP)] ([http://www.cypress.com/file/138911/download datasheet])
* '''Ultralow capacitance ESD protection''': 4x [http://www.st.com/web/catalog/sense_power/FM114/CL1137/SC1490/PF109008 ST DVIULC6-4SC6] ([http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00065974.pdf datasheet])
* '''2Kbit I2C EEPROM''': [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010774 Microchip 24AA02] ([http://ww1.microchip.com/downloads/en/DeviceDoc/21709J.pdf datasheet]) (marking: "B2TH", starts with "B2" always, the last 2 characters are a "traceability code")
* '''2.5MHz, 1.5A synchronous step down switching regulator (1.2V)''': [http://www.semtech.com/power-management/switching-regulators/sc189 Semtech SC189] ([http://www.semtech.com/images/datasheet/sc189.pdf datasheet]) (marking: "189C")
* '''2.5MHz, 1.5A synchronous step down switching regulator (3.3V)''': [http://www.semtech.com/power-management/switching-regulators/sc189 Semtech SC189] ([http://www.semtech.com/images/datasheet/sc189.pdf datasheet]) (marking: "189Z")
* '''N-MOSFET''': 2x 2N7002 type MOSFET (marking: "72Y7"). Connected as "low-side" switch/LED driver and inverter.

'''Pinouts and connections:'''

'''JTAG header (FPGA):'''

The '''J3''' pin header is a JTAG connector wired to the FPGA. The pins are (from left to right, the right-most pin, pin number 1, is square):

{| border="0" style="font-size: smaller" class="sigroktable"
|-
!5
!4
!3
!2
!1

|-
| GND
| TMS
| TCK
| TDO
| TDI

|}

'''Testpoints:'''

{| border="0" style="font-size: smaller" class="sigroktable"
|-
!T1
!T2
!T3

|-
| 1.2V
| 3.3V
| GND (FX2)

|}

'''Cypress FX2:'''


{{chip_56pin
| 1=(FPGA 15, IO_L05P_3) PD5
| 2=(FPGA 13, IO_L04N_3) PD6
| 3=(FPGA 10, IO_L03N_3) PD7
| 4=GND
| 5=(FPGA 90, IO_0) CLKOUT
| 6=VCC
| 7=GND
| 8=(FPGA 3, IO_L01P_3) RDY0/*SLRD
| 9=(FPGA 16, IO_L05N_3) RDY1/*SLWR
| 10=AVCC
| 11=(24MHz crystal) XTALOUT
| 12=(24MHz crystal) XTALIN
| 13=AGND
| 14=AVCC

| 15=(USB D+) DPLUS
| 16=(USB D-) DMINUS
| 17=AGND
| 18=VCC
| 19=GND
| 20=(FPGA 84, IO_L02N_0) *IFCLK
| 21=RESERVED
| 22=(EEPROM SCL) SCL
| 23=(EEPROM SDA) SDA
| 24=VCC
| 25=(FPGA 40, IO_L08P_2) PB0
| 26=(FPGA 78, IO_L01N_0) PB1
| 27=(FPGA 77, IO_L01P_0) PB2
| 28=(FPGA 49, IO_L10N_2) PB3

| 29=PB4 (FPGA 46, MOSI)
| 30=PB5 (FPGA 41, IO_L08N_2)
| 31=PB6 (FPGA 37, IO_L07N_2)
| 32=PB7 (FPGA 93, IO_L05P_0)
| 33=GND
| 34=VCC
| 35=GND
| 36=CTL0 (FPGA 94, IO_L05N_0)
| 37=CTL1 (FPGA 97, IP_0)
| 38=CTL2 (FPGA 100, PROG_B)
| 39=VCC
| 40=PA0 (FPGA 54, DONE)
| 41=PA1 (FPGA 48, INIT_B)
| 42=PA2 (FPGA 53, CCLK)

| 43=PA3 (FPGA 51, MISO)
| 44=PA4 (FPGA 98, IO_L06P_0)
| 45=PA5 (FPGA 85, IO_L03P_0)
| 46=PA6 (FPGA 30, IO_L04P_2)
| 47=PA7 (FPGA 9, IO_L03P_3)
| 48=GND
| 49=RESET# (3.3V via D2 (diode?))
| 50=VCC
| 51=*WAKEUP (3.3V)
| 52=PD0 (FPGA 6, IO_L02N_3)
| 53=PD1 (FPGA 4, IO_L01N_3)
| 54=PD2 (FPGA 5, IO_L02P_3)
| 55=PD3 (FPGA 44, IO_L09N_2)
| 56=PD4 (FPGA 12, IO_L04P_3)

}}


'''Other FPGA connections:'''

{| border="0" style="font-size: smaller" class="sigroktable"
|-
!28
|CH0
!52
|CH8
|-
!29
|CH1
!56
|CH9
|-
!32
|CH2
!57
|CH10
|-
!33
|CH3
!60
|CH11
|-
!34
|CH4
!61
|CH12
|-
!36
|CH5
!62
|CH13
|-
!43
|CH6
!64
|CH14
|-
!50
|CH7
!65
|CH15
|-
!73
|colspan="3"|LED (active low)
|}

== Photos ==

<gallery>
File:Saleae Logic16.jpg|Device, front
File:Saleae Logic16 bottom.jpg|Device, bottom
File:Saleae Logic16 PCB top.jpg|PCB, top
File:Saleae Logic16 PCB bottom.jpg|PCB, bottom
File:Saleae logic16 xilinx xc3s200a.jpg|Xilinx XC3S200A
File:Saleae logic16 cypress fx2lp.jpg|Cypress FX2LP
File:Saleae logic16 eeprom b2th.jpg|I2C EEPROM
File:Saleae logic16 dl46.jpg|ST DVIULC6-4SC6
File:Saleae logic16 189z 189c.jpg|Voltage regulators
File:Saleae logic16 72y7.jpg|N-MOSFETs

</gallery>

== Firmware ==

=== Firmware and FPGA bitstream usage ===

You can use the [http://sigrok.org/gitweb/?p=sigrok-util.git;a=tree;f=firmware/saleae-logic16 sigrok-fwextract-saleae-logic16] tool to extract (from the "Logic" Linux binary) the FX2 firmware and the FPGA bitstreams required for using the Saleae Logic16:

$ '''sigrok-fwextract-saleae-logic16 Logic'''
saved 5214 bytes to saleae-logic16-fx2.fw
saved 149516 bytes to saleae-logic16-fpga-18.bitstream
saved 149516 bytes to saleae-logic16-fpga-33.bitstream

Copy these files to the directory where your [[libsigrok]] installation expects them (usually '''/usr/local/share/sigrok-firmware''') and they will be found and used automatically by the libsigrok '''saleae-logic16''' driver.

=== Technical firmware details ===

The firmware for the FX2LP is embedded in the vendor application as a set of Intel HEX lines. Each line is uploaded individually with a separate control transfer. The firmware currently occupies the address range [0x0000-0x145d], but is uploaded out of order.

See [[Saleae Logic16/Firmware]] for more details on the vendor firmware.

== Protocol ==

'''Sample format''':

The samples (as received via USB) for the enabled probes (3, 6, 9, or 16) are organized as follows:

'''0xLL 0xLL 0xMM 0xMM 0xNN 0xNN 0xPP 0xPP 0xQQ 0xQQ 0xRR 0xRR ...'''

In the above example, 3 probes are enabled. For each probe there are 2 bytes / 16 bits (e.g. 0xLL 0xLL for probe 0), then the next probe's data is received (0xMM 0xMM for probe 1), then 0xNN 0xNN for probe 2. When 2 bytes have been received for all enabled probes, the process restarts with probe 0 again.

The 16 bits of data per probe seem to contain the pin state of the respective probe (1: high, 0: low) at 16 different sampling points/times (which ones depends on the samplerate).

'''Configuration''':

Endpoint 1 is used for configuration of the analyzer. The transfers are "encrypted" using a simple series of additions and XORs. Two kinds of transfers are used; a 3 byte out transfer starting with 0x81 followed by a 1 byte in transfer, and a 4 byte out transfer starting with 0x80. It's quite plausible that these provide raw read/write access to memory locations.

{| border="0" style="font-size: smaller; white-space: nowrap;" class="alternategrey sigroktable"
!colspan="2"|Channel number configuration
|-
| 3 channels
| <tt>0x80 0x01 0x02 '''0x07''' 0x80 0x01 0x03 '''0x00'''</tt>
|-
| 6 channels
| <tt>0x80 0x01 0x02 '''0x3f''' 0x80 0x01 0x03 '''0x00'''</tt>
|-
| 9 channels
| <tt>0x80 0x01 0x02 '''0xff''' 0x80 0x01 0x03 '''0x01'''</tt>
|-
| 16 channels
| <tt>0x80 0x01 0x02 '''0xff''' 0x80 0x01 0x03 '''0xff'''</tt>
|}

{| border="0" style="font-size: smaller; white-space: nowrap;" class="alternategrey sigroktable"
!colspan="2"|Sampling frequency
|-
| 500kHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0xc7'''</tt>
|-
| 1MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x63'''</tt>
|-
| 2MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x31'''</tt>
|-
| 4MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x18'''</tt>
|-
| 5MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x13'''</tt>
|-
| 8MHz
| <tt>0x80 0x01 0x0a '''0x01''' 0x80 0x01 0x04 '''0x13'''</tt>
|-
| 10MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x09'''</tt>
|-
| 12.5MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x07'''</tt>
|-
| 16MHz
| <tt>0x80 0x01 0x0a '''0x01''' 0x80 0x01 0x04 '''0x09'''</tt>
|-
| 25MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x03'''</tt>
|-
| 32MHz
| <tt>0x80 0x01 0x0a '''0x01''' 0x80 0x01 0x04 '''0x04'''</tt>
|-
| 40MHz
| <tt>0x80 0x01 0x0a '''0x01''' 0x80 0x01 0x04 '''0x03'''</tt>
|-
| 50MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x01'''</tt>
|-
| 80MHz
| <tt>0x80 0x01 0x0a '''0x01''' 0x80 0x01 0x04 '''0x01'''</tt>
|-
| 100MHz
| <tt>0x80 0x01 0x0a '''0x00''' 0x80 0x01 0x04 '''0x00'''</tt>
|}

== Resources ==

* [http://downloads.saleae.com/Logic+Guide.pdf Manual]
* [http://www.saleae.com/downloads Vendor software]
* [http://community.saleae.com/ SDKs]

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Protocol decoder:Aud

2016-04-07T15:52:41Z

Fenugrec: added "infobox"

{{Infobox protocol decoder
| id = aud
| name = AUD
| description = Renesas/Hitachi Advanced User Debugger (AUD) protocol
| status = supported
| license = GPLv2+
| source_code_dir = aud
| image = [[File:PV_example_AUD.png|250px]]
| input = logic
| output = aud
| probes = AUDCK, nAUDSYNC, AUDATA3-AUDATA0
| optional_probes = —
| options = —
}}

= Renesas/Hitachi AUD (Advanced User Debugger) =

The AUD (Advanced User Debugger) port of certain Renesas / Hitachi microcontrollers has two modes of peration, "Branch Trace mode" and "RAM monitor mode".

Currently the protocol decoder implementation only recognizes "Branch Trace" mode.

The AUD protocol is described in the microcontroller datasheets, such as [http://www.renesas.eu/products/mpumcu/superh/sh7050/sh7058/Documentation.jsp rej09b0046 - SH7058 Hardware manual]

Refer to the AUD chapter for functional description, and the AC characteristics chapter for timing diagrams.

== Interface description ==
The interface itself is 4 data lines, and 4 control lines (reset, clock, mode, sync):
# AUDCK
# nAUDSYNC
# nAUDRST
# nAUDMD
# AUDATA3
# AUDATA2
# AUDATA1
# AUDATA0

== Modes of operation ==
=== Branch trace mode ===
In this mode, the mcu generates the clock signal on AUDCK (typically 20MHz) and shifts out a 4-bit nibble every clock. The value reconstructed from those nibbles is the destination address of any jump, branch, or call instruction changing the PC register. Specialized or very fast hardware is required to read the data. FPGA / CPLD based interfaces, or a logic analyzer capable of sampling at least 6 simultaneous channels at >= 80MSps, can do this. 40MSps gives very inconsistent results since the sampling clock is certainly at least a few ppm away from the target clock, and the AUDCK edges are sometimes missed.

Alternately, a logic analyzer capable of state analysis at 20MHz (capturing on rising edges of AUDCK) should be sufficient. Unfortunately, cheap hardware like Logic/Logic16 clones do not support this.

=== RAM monitor mode ===
The AUD port accepts commands to read/write to the RAM. Decoding this mode is not implemented at the moment.

== Timing diagrams ==
[[File:AUD_timing.png]]

File:PV example AUD.png

2016-04-07T15:48:25Z

Fenugrec:

== Licensing ==
{{PD}}

Protocol decoder:Aud

2016-04-07T15:35:41Z

Fenugrec: Created page with "= Renesas/Hitachi AUD (Advanced User Debugger) = The AUD (Advanced User Debugger) port of certain Renesas / Hitachi microcontrollers has two modes of peration, "Branch Trace..."

= Renesas/Hitachi AUD (Advanced User Debugger) =

The AUD (Advanced User Debugger) port of certain Renesas / Hitachi microcontrollers has two modes of peration, "Branch Trace mode" and "RAM monitor mode".

Currently the protocol decoder implementation only recognizes "Branch Trace" mode.

The AUD protocol is described in the microcontroller datasheets, such as [http://www.renesas.eu/products/mpumcu/superh/sh7050/sh7058/Documentation.jsp rej09b0046 - SH7058 Hardware manual]

Refer to the AUD chapter for functional description, and the AC characteristics chapter for timing diagrams.

== Interface description ==
The interface itself is 4 data lines, and 4 control lines (reset, clock, mode, sync):
# AUDCK
# nAUDSYNC
# nAUDRST
# nAUDMD
# AUDATA3
# AUDATA2
# AUDATA1
# AUDATA0

== Modes of operation ==
=== Branch trace mode ===
In this mode, the mcu generates the clock signal on AUDCK (typically 20MHz) and shifts out a 4-bit nibble every clock. Therefore , specialized or very fast hardware is required to read the data. FPGA / CPLD based interfaces, or a logic analyzer capable of sampling at least 6 simultaneous channels at >= 80MSps, can do this. 40MSps gives very inconsistent results since the LA sampling clock is always at least a few ppm away from the target clock, and the AUDCK edges are sometimes missed.

Alternately, a logic analyzer capable of state analysis at 20MHz (capturing on rising edges of AUDCK) should be sufficient. Unfortunately, cheap hardware like Logic/Logic16 clones do not support this.

=== RAM monitor mode ===
The AUD port accepts commands to read/write to the RAM. Decoding this mode is not implemented at the moment.

== Timing diagrams ==
[[File:AUD_timing.png]]

File:AUD timing.png

2016-04-07T15:34:51Z

Fenugrec: AUD protocol timing diagrams. Source : "SH-2E SH7058 F-ZTAT TM Hardware manual", Renesas document # rej09b0046 .

AUD protocol timing diagrams. Source : "SH-2E SH7058 F-ZTAT TM Hardware manual", Renesas document # rej09b0046 .

Mcupro Logic16 clone

2016-04-07T02:49:15Z

Fenugrec: /* Hardware (2014-01-25 variant) */ channel input info

{{DISPLAYTITLE:mcupro Logic16 clone}}
{{Infobox logic analyzer
| image = [[File:Mcupro_Logic16_overview.png|180px]]
| name = mcupro Logic16 clone
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = 1.5V (operates with 3.3V logic)
| memory = none
| compression = yes
| website = [http://www.aliexpress.com/store/product/USB-Logic-Analyzer-100M-max-sample-rate-16Channels-10B-samples-MCU-ARM-FPGA-debug-tool/614202_1916810169.html aliexpress.com]
}}

The '''mcupro Logic16 clone''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

This is a clone of the [[Saleae Logic16]].

See [[mcupro Logic16 clone/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware (Actel variant) ==

* '''FPGA''': [https://www.actel.com/documents/PA3_DS.pdf Actel A3P125]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal''': 24MHz

== Hardware (Cyclone variant) ==

* '''FPGA''': [https://www.altera.com/products/fpga/cyclone-series/cyclone/support.html#Cyclone-Device-Handbook--All-Sections- Altera Cyclone EP1C3T100]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': 100MHz
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': STCMCU 15F10, 8051 compatible

== Hardware (2015-01-08 variant) ==

The PCB is marked "Saleae Logic 16 By MCUPro 2015-1-8". Readily identifiable by the irregular PCB traces, and switching power supplies. This comes in a different case, identical to the [[Noname_XL-LOGIC16-100M]].

* '''FPGA''': Markings ground off
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 150k/680k resistors pair
* '''1.5V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 160k/240k resistors pair
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': Looks like 32MHz?
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': Not required?

== Hardware (2014-01-25 variant) ==

The PCB is marked "Saleae Logic 16 mcupro 2014.1.25".

* '''FPGA''': Markings ground off, pinout would indicate a Cyclone EP1C3 (JTAG IDCODE not confirmed yet)
* '''USB interface chip''': Markings sometimes ground off ? CY7C68013A
* '''Crystal (FX2)''': marked "DKF 24.000"
* '''Crystal (FPGA)''': marked "RAK32.00"
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics (see [https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p10a.pdf Micron M25P10] too)
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 150k/680k resistors pair
* '''1.5V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 160k/240k resistors pair
* '''Channel input buffering''': none, only simple resistor (510R) + TVS diode array protection (possibly [http://www.semtech.com/images/datasheet/srv05-4.pdf Semtech SRV05])

The bottom two channels are not GND, but SCK (sample clock out) and HCK (half of SCK out).

== Photos (Actel) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro_Logic16_top.jpeg|PCB, top
File:Mcupro_Logic16_bottom.jpeg|PCB, bottom
</gallery>

== Photos (Cyclone) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro Logic16 Variant2 top.jpg|PCB with Altera Cyclone, top
File:IMG 0207 v1.JPG|PCB with Altera Cyclone, bottom
File:Mcupro Logic16 Variant2 top flash+uC.jpg|PCB, top, 1MBit flash and STCMCU uC
</gallery>

== Photos (2015-01-08 variant) ==

<gallery>
File:Xl-logic16-100m-external.jpg|Device, top
File:Mcupro-2015-1-8-top-overview.jpg|PCB, top
File:Mcupro-2015-1-8-bottom-overview.jpg|PCB, bottom
File:Mcupro-2015-1-8-voltage-regulators.jpg|PCB, 3.3 and 1.5 voltage regulators
File:Mcupro-2015-1-8-bottom-markings-intact.jpg|PCB, bottom - chip markings intact
</gallery>

== Photos (2014-01-25 variant) ==

<gallery>
File:seleae-logic16-aliexpress-clone.jpg|Device, top
File:Mcupro-2014-1-25-top_ortho.jpg|PCB top detail
File:Mcupro-2014-1-25-bottom_ortho.jpg|PCB bottom detail
File:Mcupro-2014-1-25-top-overview.jpg|PCB, top
File:Mcupro-2014-1-25-bottom-overview.jpg|PCB, bottom

</gallery>

== Protocol ==

See [[Saleae_Logic16#Protocol]].

== Firmware ==

;Actel variant
: This logic analyzer works with unmodified Saleae software. The Actel FPGA has on-chip flash storage, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;Cyclone variant
: This logic analyzer works with unmodified Saleae software. The PCB contains an SPI flash chip, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;2015-01-08 variant
: Only requires an upload of Cypress FX2LP firmware to operate. Open-source binaries from [https://github.com/gregani/la16fw gregani] work, but must be renamed to '''saleae-logic16-fx2.fw'''. It also requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).
;2014-01-25 variant
: Seems to have the bitstream in internal flash, so it only requires an upload of Cypress FX2LP firmware in order to operate. This requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).

The firmware extraction steps are identical to [[Saleae_Logic16#Firmware|steps for Saleae Logic16]], however you only need to have '''saleae-logic16-fx2.fw''' installed.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Mcupro Logic16 clone

2016-04-07T02:31:08Z

Fenugrec: /* Photos (2014-01-25 variant) */ added higher res, ortho PCB photos

{{DISPLAYTITLE:mcupro Logic16 clone}}
{{Infobox logic analyzer
| image = [[File:Mcupro_Logic16_overview.png|180px]]
| name = mcupro Logic16 clone
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = 1.5V (operates with 3.3V logic)
| memory = none
| compression = yes
| website = [http://www.aliexpress.com/store/product/USB-Logic-Analyzer-100M-max-sample-rate-16Channels-10B-samples-MCU-ARM-FPGA-debug-tool/614202_1916810169.html aliexpress.com]
}}

The '''mcupro Logic16 clone''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

This is a clone of the [[Saleae Logic16]].

See [[mcupro Logic16 clone/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware (Actel variant) ==

* '''FPGA''': [https://www.actel.com/documents/PA3_DS.pdf Actel A3P125]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal''': 24MHz

== Hardware (Cyclone variant) ==

* '''FPGA''': [https://www.altera.com/products/fpga/cyclone-series/cyclone/support.html#Cyclone-Device-Handbook--All-Sections- Altera Cyclone EP1C3T100]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': 100MHz
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': STCMCU 15F10, 8051 compatible

== Hardware (2015-01-08 variant) ==

The PCB is marked "Saleae Logic 16 By MCUPro 2015-1-8". Readily identifiable by the irregular PCB traces, and switching power supplies. This comes in a different case, identical to the [[Noname_XL-LOGIC16-100M]].

* '''FPGA''': Markings ground off
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 150k/680k resistors pair
* '''1.5V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 160k/240k resistors pair
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': Looks like 32MHz?
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': Not required?

== Hardware (2014-01-25 variant) ==

The PCB is marked "Saleae Logic 16 mcupro 2014.1.25".

* '''FPGA''': Markings ground off, pinout would indicate a Cyclone EP1C3 (JTAG IDCODE not confirmed yet)
* '''USB interface chip''': Markings sometimes ground off ? CY7C68013A
* '''Crystal (FX2)''': marked "DKF 24.000"
* '''Crystal (FPGA)''': marked "RAK32.00"
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics (see Micron M25P10 [https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p10a.pdf datasheet] too)
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 150k/680k resistors pair
* '''1.5V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 160k/240k resistors pair

The bottom two channels are not GND, but SCK (sample clock out) and HCK (half of SCK out).

== Photos (Actel) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro_Logic16_top.jpeg|PCB, top
File:Mcupro_Logic16_bottom.jpeg|PCB, bottom
</gallery>

== Photos (Cyclone) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro Logic16 Variant2 top.jpg|PCB with Altera Cyclone, top
File:IMG 0207 v1.JPG|PCB with Altera Cyclone, bottom
File:Mcupro Logic16 Variant2 top flash+uC.jpg|PCB, top, 1MBit flash and STCMCU uC
</gallery>

== Photos (2015-01-08 variant) ==

<gallery>
File:Xl-logic16-100m-external.jpg|Device, top
File:Mcupro-2015-1-8-top-overview.jpg|PCB, top
File:Mcupro-2015-1-8-bottom-overview.jpg|PCB, bottom
File:Mcupro-2015-1-8-voltage-regulators.jpg|PCB, 3.3 and 1.5 voltage regulators
File:Mcupro-2015-1-8-bottom-markings-intact.jpg|PCB, bottom - chip markings intact
</gallery>

== Photos (2014-01-25 variant) ==

<gallery>
File:seleae-logic16-aliexpress-clone.jpg|Device, top
File:Mcupro-2014-1-25-top_ortho.jpg|PCB top detail
File:Mcupro-2014-1-25-bottom_ortho.jpg|PCB bottom detail
File:Mcupro-2014-1-25-top-overview.jpg|PCB, top
File:Mcupro-2014-1-25-bottom-overview.jpg|PCB, bottom

</gallery>

== Protocol ==

See [[Saleae_Logic16#Protocol]].

== Firmware ==

;Actel variant
: This logic analyzer works with unmodified Saleae software. The Actel FPGA has on-chip flash storage, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;Cyclone variant
: This logic analyzer works with unmodified Saleae software. The PCB contains an SPI flash chip, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;2015-01-08 variant
: Only requires an upload of Cypress FX2LP firmware to operate. Open-source binaries from [https://github.com/gregani/la16fw gregani] work, but must be renamed to '''saleae-logic16-fx2.fw'''. It also requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).
;2014-01-25 variant
: Seems to have the bitstream in internal flash, so it only requires an upload of Cypress FX2LP firmware in order to operate. This requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).

The firmware extraction steps are identical to [[Saleae_Logic16#Firmware|steps for Saleae Logic16]], however you only need to have '''saleae-logic16-fx2.fw''' installed.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

File:Mcupro-2014-1-25-top ortho.jpg

2016-04-07T02:29:51Z

Fenugrec: mcupro Logic16 clone, "2014-1-24" variant, PCB top, perspective corrected

== Summary ==
mcupro Logic16 clone, "2014-1-24" variant, PCB top, perspective corrected
== Licensing ==
{{CC-BY-SA-3.0}}

File:Mcupro-2014-1-25-bottom ortho.jpg

2016-04-07T02:27:23Z

Fenugrec: mcupro Logic16 clone, "2014-1-24" variant, PCB bottom w/ perspective corrected

== Summary ==
mcupro Logic16 clone, "2014-1-24" variant, PCB bottom w/ perspective corrected
== Licensing ==
{{CC-BY-SA-3.0}}

Mcupro Logic16 clone

2016-04-06T19:21:04Z

Fenugrec: /* Hardware (Cylone variant) */ "Cyclone" typo

{{DISPLAYTITLE:mcupro Logic16 clone}}
{{Infobox logic analyzer
| image = [[File:Mcupro_Logic16_overview.png|180px]]
| name = mcupro Logic16 clone
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = 1.5V (operates with 3.3V logic)
| memory = none
| compression = yes
| website = [http://www.aliexpress.com/store/product/USB-Logic-Analyzer-100M-max-sample-rate-16Channels-10B-samples-MCU-ARM-FPGA-debug-tool/614202_1916810169.html aliexpress.com]
}}

The '''mcupro Logic16 clone''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

This is a clone of the [[Saleae Logic16]].

See [[mcupro Logic16 clone/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware (Actel variant) ==

* '''FPGA''': [https://www.actel.com/documents/PA3_DS.pdf Actel A3P125]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal''': 24MHz

== Hardware (Cyclone variant) ==

* '''FPGA''': [https://www.altera.com/products/fpga/cyclone-series/cyclone/support.html#Cyclone-Device-Handbook--All-Sections- Altera Cyclone EP1C3T100]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': 100MHz
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': STCMCU 15F10, 8051 compatible

== Hardware (2015-01-08 variant) ==

The PCB is marked "Saleae Logic 16 By MCUPro 2015-1-8". Readily identifiable by the irregular PCB traces, and switching power supplies. This comes in a different case, identical to the [[Noname_XL-LOGIC16-100M]].

* '''FPGA''': Markings ground off
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 150k/680k resistors pair
* '''1.5V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 160k/240k resistors pair
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': Looks like 32MHz?
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': Not required?

== Hardware (2014-01-25 variant) ==

The PCB is marked "Saleae Logic 16 mcupro 2014.1.25".

* '''FPGA''': Markings ground off, pinout would indicate a Cyclone EP1C3 (JTAG IDCODE not confirmed yet)
* '''USB interface chip''': Markings sometimes ground off ? CY7C68013A
* '''Crystal (FX2)''': marked "DKF 24.000"
* '''Crystal (FPGA)''': marked "RAK32.00"
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics (see Micron M25P10 [https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p10a.pdf datasheet] too)
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 150k/680k resistors pair
* '''1.5V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 160k/240k resistors pair

The bottom two channels are not GND, but SCK (sample clock out) and HCK (half of SCK out).

== Photos (Actel) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro_Logic16_top.jpeg|PCB, top
File:Mcupro_Logic16_bottom.jpeg|PCB, bottom
</gallery>

== Photos (Cyclone) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro Logic16 Variant2 top.jpg|PCB with Altera Cyclone, top
File:IMG 0207 v1.JPG|PCB with Altera Cyclone, bottom
File:Mcupro Logic16 Variant2 top flash+uC.jpg|PCB, top, 1MBit flash and STCMCU uC
</gallery>

== Photos (2015-01-08 variant) ==

<gallery>
File:Xl-logic16-100m-external.jpg|Device, top
File:Mcupro-2015-1-8-top-overview.jpg|PCB, top
File:Mcupro-2015-1-8-bottom-overview.jpg|PCB, bottom
File:Mcupro-2015-1-8-voltage-regulators.jpg|PCB, 3.3 and 1.5 voltage regulators
File:Mcupro-2015-1-8-bottom-markings-intact.jpg|PCB, bottom - chip markings intact
</gallery>

== Photos (2014-01-25 variant) ==

<gallery>
File:seleae-logic16-aliexpress-clone.jpg|Device, top
File:Mcupro-2014-1-25-top-overview.jpg|PCB, top
File:Mcupro-2014-1-25-bottom-overview.jpg|PCB, bottom
</gallery>

== Protocol ==

See [[Saleae_Logic16#Protocol]].

== Firmware ==

;Actel variant
: This logic analyzer works with unmodified Saleae software. The Actel FPGA has on-chip flash storage, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;Cyclone variant
: This logic analyzer works with unmodified Saleae software. The PCB contains an SPI flash chip, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;2015-01-08 variant
: Only requires an upload of Cypress FX2LP firmware to operate. Open-source binaries from [https://github.com/gregani/la16fw gregani] work, but must be renamed to '''saleae-logic16-fx2.fw'''. It also requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).
;2014-01-25 variant
: Seems to have the bitstream in internal flash, so it only requires an upload of Cypress FX2LP firmware in order to operate. This requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).

The firmware extraction steps are identical to [[Saleae_Logic16#Firmware|steps for Saleae Logic16]], however you only need to have '''saleae-logic16-fx2.fw''' installed.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]

Mcupro Logic16 clone

2016-04-06T19:15:55Z

Fenugrec: /* Hardware (2014-01-25 variant) */ added tentative FPGA + IC info

{{DISPLAYTITLE:mcupro Logic16 clone}}
{{Infobox logic analyzer
| image = [[File:Mcupro_Logic16_overview.png|180px]]
| name = mcupro Logic16 clone
| status = supported
| source_code_dir = saleae-logic16
| channels = 3/6/9/16
| samplerate = 100/50/32/16MHz
| samplerate_state = —
| triggers = none (SW-only)
| voltages = -0.9V — 6V
| threshold = 1.5V (operates with 3.3V logic)
| memory = none
| compression = yes
| website = [http://www.aliexpress.com/store/product/USB-Logic-Analyzer-100M-max-sample-rate-16Channels-10B-samples-MCU-ARM-FPGA-debug-tool/614202_1916810169.html aliexpress.com]
}}

The '''mcupro Logic16 clone''' is a USB-based, 16-channel logic analyzer with 100/50/32/16MHz sampling rate (at 3/6/9/16 enabled channels).

This is a clone of the [[Saleae Logic16]].

See [[mcupro Logic16 clone/Info]] for more details (such as '''lsusb -v''' output) about the device.

== Hardware (Actel variant) ==

* '''FPGA''': [https://www.actel.com/documents/PA3_DS.pdf Actel A3P125]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal''': 24MHz

== Hardware (Cylone variant) ==

* '''FPGA''': [https://www.altera.com/products/fpga/cyclone-series/cyclone/support.html#Cyclone-Device-Handbook--All-Sections- Altera Cyclone EP1C3T100]
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': [http://www.atmel.com/Images/doc3256.pdf Atmel 24C02N]
* '''3.3V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-3.3]
* '''1.5V voltage regulator''': [http://ams-semitech.com/attachments/File/AMS1117_20120314.pdf Advanced Monolithic Systems AMS1117-1.5]
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': 100MHz
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': STCMCU 15F10, 8051 compatible

== Hardware (2015-01-08 variant) ==

The PCB is marked "Saleae Logic 16 By MCUPro 2015-1-8". Readily identifiable by the irregular PCB traces, and switching power supplies. This comes in a different case, identical to the [[Noname_XL-LOGIC16-100M]].

* '''FPGA''': Markings ground off
* '''USB interface chip''': [http://www.cypress.com/?docID=45142 Cypress CY7C68013A]
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 150k/680k resistors pair
* '''1.5V voltage regulator''': [http://www.techcodesemi.com/cn/products_info.asp?pid=26 TD 6810] adjustable version + 160k/240k resistors pair
* '''Crystal (FX2)''': 24MHz
* '''Crystal (FPGA)''': Looks like 32MHz?
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics
* '''Bootstrap controller''': Not required?

== Hardware (2014-01-25 variant) ==

The PCB is marked "Saleae Logic 16 mcupro 2014.1.25".

* '''FPGA''': Markings ground off, pinout would indicate a Cyclone EP1C3 (JTAG IDCODE not confirmed yet)
* '''USB interface chip''': Markings sometimes ground off ? CY7C68013A
* '''Crystal (FX2)''': marked "DKF 24.000"
* '''Crystal (FPGA)''': marked "RAK32.00"
* '''FPGA bitstream''': 25P10 1MBit SPI NOR flash, ST Microelectronics (see Micron M25P10 [https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p10a.pdf datasheet] too)
* '''I²C EEPROM''': Markings ground off
* '''3.3V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 150k/680k resistors pair
* '''1.5V voltage regulator''': unknown switching regulator (marked "IC5CJ" ?) + 160k/240k resistors pair

The bottom two channels are not GND, but SCK (sample clock out) and HCK (half of SCK out).

== Photos (Actel) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro_Logic16_top.jpeg|PCB, top
File:Mcupro_Logic16_bottom.jpeg|PCB, bottom
</gallery>

== Photos (Cyclone) ==

<gallery>
File:Mcupro_Logic16_case_top.jpeg|Device, top
File:Mcupro_Logic16_case_bottom.jpeg|Device, bottom
File:Mcupro Logic16 Variant2 top.jpg|PCB with Altera Cyclone, top
File:IMG 0207 v1.JPG|PCB with Altera Cyclone, bottom
File:Mcupro Logic16 Variant2 top flash+uC.jpg|PCB, top, 1MBit flash and STCMCU uC
</gallery>

== Photos (2015-01-08 variant) ==

<gallery>
File:Xl-logic16-100m-external.jpg|Device, top
File:Mcupro-2015-1-8-top-overview.jpg|PCB, top
File:Mcupro-2015-1-8-bottom-overview.jpg|PCB, bottom
File:Mcupro-2015-1-8-voltage-regulators.jpg|PCB, 3.3 and 1.5 voltage regulators
File:Mcupro-2015-1-8-bottom-markings-intact.jpg|PCB, bottom - chip markings intact
</gallery>

== Photos (2014-01-25 variant) ==

<gallery>
File:seleae-logic16-aliexpress-clone.jpg|Device, top
File:Mcupro-2014-1-25-top-overview.jpg|PCB, top
File:Mcupro-2014-1-25-bottom-overview.jpg|PCB, bottom
</gallery>

== Protocol ==

See [[Saleae_Logic16#Protocol]].

== Firmware ==

;Actel variant
: This logic analyzer works with unmodified Saleae software. The Actel FPGA has on-chip flash storage, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;Cyclone variant
: This logic analyzer works with unmodified Saleae software. The PCB contains an SPI flash chip, so it only requires an upload of Cypress FX2LP firmware in order to operate.
;2015-01-08 variant
: Only requires an upload of Cypress FX2LP firmware to operate. Open-source binaries from [https://github.com/gregani/la16fw gregani] work, but must be renamed to '''saleae-logic16-fx2.fw'''. It also requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).
;2014-01-25 variant
: Seems to have the bitstream in internal flash, so it only requires an upload of Cypress FX2LP firmware in order to operate. This requires a [[libsigrok]] more recent than 2014-08-22 to work (see bug [http://sigrok.org/bugzilla/show_bug.cgi?id=680#c4 #680]).

The firmware extraction steps are identical to [[Saleae_Logic16#Firmware|steps for Saleae Logic16]], however you only need to have '''saleae-logic16-fx2.fw''' installed.

[[Category:Device]]
[[Category:Logic analyzer]]
[[Category:Supported]]