[[File:Open workbench logic sniffer.jpg|thumb|right|Openbench Logic Sniffer]]

The [http://www.gadgetfactory.net/gf/project/butterflylogic/ Openbench Logic Sniffer] (OLS) is an FPGA-based logic analyzer, supporting 32 probes for probing up to 100MHz signals and advanced trigger functionality. It is a fully open source device — the circuit design, VHDL code for the FPGA, firmware for the PIC microcontroller and Java-based client software are all freely available. The project is a collaboration between [http://www.gadgetfactory.net/ Gadget Factory] and [http://dangerousprototypes.com/ Dangerous Prototypes].

The device started life as the [http://www.sump.org/projects/analyzer/ Sump Logic Analyzer], which was meant to be run on a Digilent FPGA development board. The Openbench Logic Analyzer unit is a custom-designed board with low cost in mind: it can be bought for $45 from [http://www.seeedstudio.com/depot/preorder-open-workbench-logic-sniffer-p-612.html?cPath=61_76 Seeed Studio].

Communication between the board and the PC is done via a USB port connected to a PIC 18F24J50 microcontroller, which presents a standard USB ACM profile. The host handles this as a serial port, running at 115200 bps. An overview of the endpoint profile is [[Openbench Logic Sniffer/info|here]].

The communications protocol between the board and the PC is below, taken from the original Sump documentation.

== Communications Protocol ==

All communication is done using a standard RS232 connection with 8 data bits, 1 stop bit and no parity. The transfer rate can be set to 115200, 57600, 38400 or 19200 bps. XON/XOFF software flow control is available.

When sending captured data the analyzer will send blocks of four bytes, the first containing the lowest channels. No start or end sequence exists. The host can assume an end of transmission if no data has been received for the duration of one byte.

The protocol used by hardware version 0.5 and older is not covered here. Hardware 0.6 uses protocol version 0, and hardware 0.7 uses protocol version 1. Unless otherwise stated, commands exist in both versions.

The following list provides a short overview of commands understood by the analyzer.

=== Short Commands ===

These commands are exactly one byte long.

'''Reset (0x00)'''
: Resets the device. Should be sent 5 times when the receiver status is unknown. (It could be waiting for up to four bytes of pending long command data.)

'''Run (0x01)'''
: Arms the trigger.

'''ID (0x02)'''
: Asks for device identification. The device will respond with four bytes. The first three ("SLA") identify the device. The last one identifies the protocol version which is currently either "0" or "1".

'''XON (0x11)'''
: Put transmitter out of pause mode. It will continue to transmit captured data if any is pending. This command is being used for xon/xoff flow control.

'''XOFF (0x13)'''
: Put transmitter in pause mode. It will stop transmitting captured data. This command is being used for xon/xoff flow control.

=== Long Commands ===

Are five bytes long. The first byte contains the opcode. The bytes are displayed in the order in which they are sent to the serial port starting left. The bits within one byte are displayed most significant first.

'''Set Trigger Mask (0xc0, 0xc4, 0xc8, 0xcc)'''
: Defines which trigger values must match. In parallel mode each bit represents one channel, in serial mode each bit represents one of the last 32 samples of the selected channel. The opcodes refer to stage 0-3 in the order given above. (Protocol version 0 only supports stage 0.)
: [[Image:1100xx00.png]]

'''Set Trigger Values (0xc1, 0xc5, 0xc9, 0xcd)'''
: Defines which values individual bits must have. In parallel mode each bit represents one channel, in serial mode each bit represents one of the last 32 samples of the selected channel. The opcodes refer to stage 0-3 in the order given above. (Protocol version 0 only supports stage 0.)
: [[Image:1100xx01.png]]

'''Set Trigger Configuration (0xc2, 0xc6, 0xca, 0xce)'''
: Configures the selected trigger stage. The opcodes refer to stage 0-3 in the order given above. The following parameters will be set:

:: '''delay'''
::: If a match occures, the action of the stage is delayed by the given number of samples.
:: '''level'''
::: Trigger level at which the stage becomes active.
:: '''channel'''
::: Channel to be used in serial mode. (0-31 in normal operation; 0-15 when demux flag is set)
:: '''serial'''
::: When set to 1 the stage operates as serial trigger, otherwise it used as parallel trigger.
:: '''start'''
::: When set to 1 a match will start the capturing process. The trigger level will rise on match regardless of this flag. (Command available as of protocol version 1.)

: [[Image:1100xx10.png]]

'''Set Divider (0x80)'''
: When x is written, the sampling frequency is set to f = clock / (x + 1).

: [[Image:10000000.png]]

'''Set Read & Delay Count (0x81)'''
: Read Count is the number of samples (divided by four) to read back from memory and sent to the host computer. Delay Count is the number of samples (divided by four) to capture after the trigger fired. A Read Count bigger than the Delay Count means that data from before the trigger match will be read back. This data will only be valid if the device was running long enough before the trigger matched.
: [[Image:10000001.png]]

'''Set Flags (0x82)'''
: Sets the following flags:

:: '''demux'''
::: Enables the demux input module. (Filter must be off.)
:: '''filter'''
::: Enables the filter input module. (Demux must be off.)
:: '''channel groups'''
::: Disable channel group. Disabled groups are excluded from data transmissions. This can be used to speed up transfers. There are four groups, each represented by one bit. Starting with the least significant bit of the channel group field channels are assigned as follows: 0-7, 8-15, 16-23, 24-31.
:: '''external'''
::: Selects the clock to be used for sampling. If set to 0, the internal clock divided by the configured divider is used, and if set to 1, the external clock will be used. Filter and demux are only available with internal clock.
:: '''inverted'''
::: When set to 1, the external clock will be inverted before being used. The inversion causes a delay that may cause problems at very high clock rates. This option only has an effect with external set to 1.

: [[Image:10000010.png]]

2010-03-17T01:33:34Z

Biot: /* General */

TODO

2010-03-17T01:32:32Z

Biot: /* libsigrok */

This is a random list of TODO items for the code and/or ideas for improvements.

== General ==

* Remove dependency on glib and gmodule (various reasons), at least in libsigrok, probably also in sigrok-cli.

== libsigrok ==

* Test whether the libusb 1.0 Windows port works (seems to build fine using Mingw).
* Merge all header files in a single sigrok.h (possibly another sigrok-internal.h which is not visible to the lib users).
* sigrok_errno:
<blockquote>
Most backend functions return status as an integer, which is SIGROK_OK if all went well, or SIGROK_NOK and similar if an error occurred.

However there is no way to pass any information back as to what went wrong -- and this is important for user-friendliness.

Perhaps an error code is not enough; maybe something like sigrok_errno(errorcode, "unsupported device") is better.

Both the cmdline and GUI interfaces need this, really, so it should be a backend library thing.
</blockquote>

== libsigrokdecode ==

* Keep this independent of libsigrok and any logic analyzer hardware. It should work purely on streams / buffers of bytes to be usable by other projects.

== sigrok-cli ==

== sigrok-gui ==

== Decoders ==

Public relations

2010-03-16T01:38:09Z

Biot:

This page combines information about our PR work.

== Places to announce sigrok ==

* [http://hackaday.com/contact-hack-a-day/ submit as a project to hackaday]
* [http://hackaday.com/2009/03/06/tools-saleae-logic-logic-analyzer/ comment on saleae logic analyzer post on hackaday]
* [http://www.adafruit.com/blog/ adafruit blog]
* [http://dangerousprototypes.com/2010/02/25/prototype-open-logic-sniffer-logic-analyzer-2/ dangerous prototypes blog]

== Projects to contact ==
* [http://scopegrab32.sourceforge.net/ scopegrab32] Fluke(TM) scope grabber software
* [http://users.on.net/~merrifield/fluke/scopegrab.html ScopeGrab] Fluke(TM) scope grabber software
* [http://optics.eee.nottingham.ac.uk/tek/ VXI-11 RPC Protocol over Ethernet Linux drivers] Protocol used for Tektronix Oscilloscopes and Function generators
* [http://www.febo.com/geekworks/data-capture/tds-2012.html Tektronix TDS-10xx/20xx Oscilloscope GPIB Software]
* [http://www.mtoussaint.de/qtdmm.html QtDMM] Multimeter DMM readout software
* [http://xoscope.sourceforge.net/ Xoscope]
* [http://www.eig.ch/fr/laboratoires/systemes-numeriques/projets/osqoop-l-oscilloscope-libre/index.html osqoop]
* [http://luke.no-ip.org/code/ glscope]
* [http://www.sump.org/projects/analyzer/ sump]
* [http://sourceforge.net/projects/minila/ minila]

== People into hardware hacking (send personal mail) ==

* Travis Goodspeed (open source hardware hacker)
* Harald Welte (open source hardware hacker)
* Peter Stuge (open source hardware hacker)
* Jack Gassett (OLS, [http://gadgetfactory.net/ Gadget Factory])
* Ian Lesnet (OLS, [http://dangerousprototypes.com Dangerous Prototypes])

Hardware driver API

2010-03-15T20:33:10Z

Biot:

Every plugin is built as a shared library, dynamically loaded by the backend at startup. The plugin must define a structure as follows:

#include "sigrok.h"

struct device_plugin {
/* plugin-specific */
char *name;
int api_version;
int (*init) (char *deviceinfo);
void (*cleanup) (void);

/* device-specific */
int (*open) (int device_index);
void (*close) (int device_index);
char *(*get_device_info) (int device_index, int device_info_id);
int (*get_status) (int device_index);
int *(*get_capabilities) (void);
int (*set_configuration) (int device_index, int capability, char *value);
int (*start_acquisition) (int device_index, gpointer session_device_id);
void (*stop_acquisition) (int device_index, gpointer session_device_id);
};

#define SIGROK_HARDWARE_PLUGIN struct device_plugin plugin_info

This structure is the only symbol imported into the backend namespace. The plugin's variables thus cannot conflict with the global sigrok namespace.

* '''name'''
<blockquote>
A string describing this driver. It will be referenced in saved session files.
</blockquote>

* '''api_version'''
<blockquote>
Currently defined as 1.
</blockquote>

The other members of the structure are pointers to plugin callbacks:

* '''init(char *device)'''
<blockquote>
Called when the plugin is initially loading into sigrok, typically at program start. The parameter refers to a device name or special file, whichever is applicable for the plugin. Devices which don't need a supplied device, such as USB devices, can simply ignore this parameter.

The function returns the number of devices found, and 0 if no suitable device was found. If a device was found, any initialization it needs must be performed here; for example, uploading firmware should be done here.
</blockquote>

* '''cleanup()'''
<blockquote>
Called before the plugin is unloaded. Release any resources the plugin might be holding.
</blockquote>

* '''open(int device_index)
<blockquote>
Open the specified device. The device index starts at 0.
</blockquote>

* '''close(int device_index)
<blockquote>
Close the specified device.
</blockquote>

* '''get_device_info(int device_index, int device_info_id)'''
<blockquote>
Returns information about the given device. The type of information is given as device_info_id, one of a set of defined constants. The return value must be cast according to the type of information returned:

* DI_IDENTIFIER: string identifying this specific device in the system, in case more than one is connected.
* DI_NUM_PROBES: the number of probes connected to this device (integer).
* DI_SAMPLE_RATES: the samples rates this device supports, as a 0-terminated array of float.
</blockquote>

* '''get_status(int device_index)'''
<blockquote>
Returns an integer describing the status of the plugin's connection to a device. This may be one of the following:

* ST_NOT_FOUND: The device was not found.
* ST_INITIALIZING: The device was found, but is still initializing.
* ST_INACTIVE: The device is live, but not in use.
* ST_ACTIVE: The device is currently in use.
</blockquote>

* '''get_capabilities()'''
<blockquote>
This function returns zero-terminated integer array with the plugin's capabilities, in the form of a set of defined constants. Some of these are informative, and some can be used to configure the plugin (or its connected device). The capabilities tables below have an overview of all possible capabilities.
</blockquote>

* '''set_configuration(int device_index, int capability, char *value)'''
<blockquote>
This is used to configure the plugin and/or connected device. The capability is one of the constants returned from the get_capabilities() call. The value depends on the parameter that is to be configured.
</blockquote>

* '''start_acquisition(int device_index, gpointer session_device_id)'''
<blockquote>
Start acquisition on the specified device. The session_device_id will be passed along with the data feed of this session, as the first parameter to session bus callbacks.
</blockquote>

* '''stop_acquisition(int device_index, gpointer session_device_id)'''
<blockquote>
Stop acquisition on the specified device. This causes a DF_END packet to be sent to the sesion bus.
</blockquote>

== Informative capabilities ==

* HWCAP_LOGIC_ANALYZER
<blockquote>
This plugin supplies a logic analyzer.
</blockquote>

== Configurable capabilities ==

* HWCAP_SAMPLERATE
<blockquote>
The sample rate in Mhz.
</blockquote>
* HWCAP_LIMIT_SECONDS
<blockquote>
How long the acquisition should last.
</blockquote>
* HWCAP_LIMIT_SAMPLES
<blockquote>
How many samples to acquire in the session.
</blockquote>

Public relations

2010-03-15T18:56:44Z

Biot: /* Places to announce sigrok */

Public relations

2010-03-15T18:55:37Z

Biot: /* People into hardware hacking (send personal mail) */

Public relations

2010-03-15T18:39:04Z

Biot: