--------
Some devices supported by libsigrok need a firmware to be uploaded every time
-the device is connected to the PC (usually via USB), before it can be used.
+the device is connected to the PC (usually via USB), before it can be used.
-The default location where libsigrok expects the firmware files is:
+The default locations where libsigrok expects the firmware files are:
+ $SIGROK_FIRMWARE_DIR (environment variable)
+ $HOME/.local/share/sigrok-firmware
$prefix/share/sigrok-firmware
+ /usr/local/share/sigrok-firmware
+ /usr/share/sigrok-firmware
($prefix is usually /usr/local or /usr, depending on your ./configure options)
'sigrok-firmware' repository/project under a license which allows us
to redistribute them.
+ - dreamsourcelab-dslogic: The DreamSourceLab DSLogic/DSCope device series
+ requires various firmware files and FPGA bitstream files.
+ These can be extracted/downloaded from the vendor's GitHub repo using a
+ tool from our 'sigrok-util' repository/project.
+
- fx2lafw: Logic analyzers based on the Cypress FX2(LP) chip need the
firmware files from the 'sigrok-firmware-fx2lafw' repository/project.
- The firmware is written from scratch and licensed under the GPLv2+.
+ The firmware is written from scratch and licensed under the GNU GPLv2+.
+
+ - hantek-6xxx: Certain oscilloscopes based on the Cypress FX2(LP) chip, such
+ as the Hantek 6022BE/6022BL, SainSmart DDS120, and Rocktech BM102, need the
+ firmware files from the 'sigrok-firmware-fx2lafw' repository/project.
+ The firmware is written from scratch and licensed under the GNU GPLv2+.
- hantek-dso: The Hantek DSO-2090 (and other supported models of the same
series of Hantek PC oscilloscopes) need firmware files.
These can be extracted from the vendor's Windows drivers using a tool
from our 'sigrok-util' repository/project.
- - nexus-osciprime: The Nexus Computing OsciPrime PC oscilloscope needs
- firmware files. These are available from the vendor website.
+ - lecroy-logicstudio: The LeCroy LogicStudio requires FPGA bitstream files.
+ These can be extracted from the vendor's Windows software using a tool
+ from our 'sigrok-util' repository/project.
+ Additionally, it requires a Cypress FX2 firmware. This can be extracted
+ from the vendor's Windows software using another tool. Details:
+
+ http://sigrok.org/wiki/LeCroy_LogicStudio#Firmware
+
+ - saleae-logic16: The Saleae Logic16 needs a firmware file for the
+ Cypress FX2 chip in the device, as well as two FPGA bitstream files.
+ These can be extracted from the vendor's Linux application using a tool
+ from our 'sigrok-util' repository/project.
+
+ - saleae-logic-pro: The Saleae Logic Pro 16 needs a firmware file for the
+ Cypress FX3 chip in the device, as well as an FPGA bitstream file.
+ These can be extracted from the vendor's Linux application using a tool
+ from our 'sigrok-util' repository/project.
+
+ - sysclk-lwla:
+
+ - The Sysclk LWLA1034 requires various bitstream files.
+ These files are available from our 'sigrok-firmware' repository/project
+ under a license which allows us to redistribute them.
+
+ - The Sysclk LWLA1016 requires various bitstream files.
+ These can be extracted from the vendor's Windows drivers using a tool
+ from our 'sigrok-util' repository/project.
+
+ - sysclk-sla5032: The Sysclk SLA5032 needs an FPGA bitstream file.
+ This file can be copied (and renamed) from the Windows vendor software
+ installation directory. Details:
+
+ https://sigrok.org/wiki/Sysclk_SLA5032#Firmware
The following drivers/devices do not need any firmware upload:
- agilent-dmm
- - alsa
- - brymen-dmm
- - chronovu-la8
+ - appa-55ii
+ - arachnid-labs-re-load-pro
+ - atten-pps3xxx
+ - baylibre-acme
+ - beaglelogic
+ - cem-dt-885x
+ - center-3xx (including all subdrivers)
+ - chronovu-la
- colead-slm
+ - conrad-digi-35-cpu
- demo
+ - fluke-45
- fluke-dmm
+ - ftdi-la
+ - gmc-mh-1x-2x (including all subdrivers)
+ - gwinstek-gds-800
+ - gwinstek-gpd
+ - hameg-hmo
+ - hantek-4032l
+ - hp-3457a
+ - hp-3478a
+ - hung-chang-dso-2100
+ - ikalogic-scanalogic2
+ - ikalogic-scanaplus
+ - ipdbg-la
+ - kecheng-kc-330b
+ - kern-scale
+ - korad-kaxxxxp
- lascar-el-usb
+ - lecroy-xstream
- link-mso19
- - mic-985xx
+ - manson-hcs-3xxx
+ - maynuo-m97
+ - mic-985xx (including all subdrivers)
+ - microchip-pickit2
+ - mooshimeter-dmm
+ - motech-lps-30x
+ - norma-dmm
- openbench-logic-sniffer
- - rigol-ds1xx2
- - serial-dmm
+ - pce-322a
+ - pipistrello-ols
+ - rdtech-dps
+ - rigol-dg
+ - rigol-ds
+ - rohde-schwarz-sme-0x
+ - scpi-dmm
+ - scpi-pps
+ - serial-dmm (including all subdrivers)
+ - serial-lcr (including all subdrivers)
+ - siglent-sds
+ - teleinfo
+ - testo
- tondaj-sl-814
- - uni-t-dmm
- - victor-dmm
+ - uni-t-dmm (including all subdrivers)
+ - uni-t-ut32x
+ - yokogawa-dlm
- zeroplus-logic-cube
+ - zketech-ebd-usb
Specifying serial ports
-----------------------
Many devices supported by libsigrok use serial port based cables (real RS232
-or USB-to-serial ones) to connect to a PC.
+or USB-to-serial ones, CDC class) to connect to a PC. These serial cables are
+supported by the libserialport library. Some vendors prefer to use HID chips
+instead of CDC chips in their serial cables. These cables can get supported
+by means of the hidapi library. Note that each chip type requires specific
+support in the libsigrok library. Bluetooth connected devices may be supported
+as well when they communicate by means of RFCOMM channels, or one of the
+implemented BLE notification/indication approaches, and one of the Bluetooth
+supporting platforms is used.
For all these devices, you need to specify the serial port they are connected
to (e.g. using the 'conn' option in sigrok-cli). It is not possible to scan
Example:
$ sigrok-cli --driver <somedriver>:conn=/dev/ttyUSB0 ...
+ $ sigrok-cli --driver <somedriver>:conn=hid/cp2110 ...
+ $ sigrok-cli --driver <somedriver>:conn=bt/rfcomm/01-23-45-67-89-ab ...
+
+Formal syntax for serial communication:
+
+ - COM ports (RS232, USB CDC):
+ conn=<com-port>
+ - USB HID cables:
+ conn=hid[/<chip>]
+ conn=hid[/<chip>]/usb=<bus>.<dev>[.<if>]
+ conn=hid[/<chip>]/raw=<path>
+ conn=hid[/<chip>]/sn=<serno>
+ conn=hid[/<chip>]/iokit=<path>
+ chip can be: bu86x, ch9325, cp2110, victor
+ path may contain slashes
+ path and serno are "greedy" (span to the end of the spec)
+ - Bluetooth Classic and Bluetooth Low Energy (BLE):
+ conn=bt/<conn>/<addr>
+ conn can be: rfcomm, ble122, nrf51, cc254x
+ addr can be "dense" or separated, bt/cc254x/0123456789ab or
+ bt/rfcomm/11-22-33-44-55-66 or bt/ble122/88:6b:12:34:56:78
+ (note that colons may not be available when the conn= spec is taken
+ from a string that separates fields by colon, e.g. in the "--driver
+ <name>:conn=<spec>" example, that is why the dense form and the use
+ of dashes for separation are supported)
+
+Some of the drivers implement a default for the connection. Some of the
+drivers can auto-detect USB connected devices.
+
+Beyond strict serial communication over COM ports (discussed above), the
+conn= property can also address specific USB devices, as well as specify TCP
+or VXI communication parameters. See these examples:
+
+ $ sigrok-cli --driver <somedriver>:conn=<vid>.<pid> ...
+ $ sigrok-cli --driver <somedriver>:conn=tcp-raw/<ipaddr>/<port> ...
+ $ sigrok-cli --driver <somedriver>:conn=vxi/<ipaddr> ...
+ $ sigrok-cli --driver <somedriver>:conn=usbtmc/<bus>.<addr> ...
+
+Individual device drivers _may_ implement additional semantics for the
+conn= specification, which would not apply to other drivers, yet can be
+rather useful for a given type of device.
+
+ $ sigrok-cli --driver <somedriver>:conn=sn=<serno>
+
+
+Specifying serial port parameters
+---------------------------------
-The following drivers/devices require a serial port specification:
-
- - agilent-dmm
- - brymen-dmm
- - colead-slm
- - fluke-dmm
- - link-mso19
- - mic-985xx
- - nexus-osciprime
- - openbench-logic-sniffer
- - serial-dmm
- - tondaj-sl-814
+Every serial device's driver has default serial port parameters like baud
+rate, number of data bits, stop bits and handshake status. If a device requires
+different parameters, pass them as option "serialcomm" with the driver name.
+See libsigrok docs for the function serial_set_paramstr() for complete specs.
-The following drivers/devices do not require a serial port specification:
+Example:
- - alsa
- - asix-sigma
- - chronovu-la8
- - demo
- - fx2lafw
- - hantek-dso
- - lascar-el-usb
- - rigol-ds1xx2
- - uni-t-dmm
- - victor-dmm
- - zeroplus-logic-cube
+ $ sigrok-cli --driver <somedriver>:conn=<someconn>:serialcomm=9600/7n1/dtr=1
Permissions of serial port based devices
(see below for details).
-Permissions for USB devices (udev rules file)
----------------------------------------------
+Permissions for USB devices (udev rules files)
+----------------------------------------------
When using USB-based devices supported by libsigrok, the user running the
libsigrok frontend (e.g. sigrok-cli) has to have (read/write) permissions
for the respective USB device.
-On Linux, this is accomplished using either 'chmod' (not recommended) or
-using the udev rules file shipped with libsigrok (recommended).
+On Linux, this is accomplished using udev rules. libsigrok ships a rules
+file containing all supported devices which can be detected reliably
+(generic USB-to-serial converters are omitted, as these are used for a wide
+range of devices, e.g. GPS receivers, which are not handled by libsigrok).
-The file is available in contrib/z60_libsigrok.rules. It contains entries
-for all libsigrok-supported (USB-based) devices and changes their group
-to 'plugdev' and the permissions to '664'.
+The file is available in contrib/60-libsigrok.rules. This file just contains
+the list of devices and flags these devices with ID_SIGROK="1". Access is
+granted by the 61-libsigrok-plugdev.rules or 61-libsigrok-uaccess.rules files,
+allowing access to members of the plugdev group or to currently logged in
+users, respectively.
When using a libsigrok package from your favorite Linux distribution, the
-packager will have already taken care of properly installing the udev file
-in the correct (distro-specific) place, and you don't have to do anything.
-The packager might also have adapted 'plugdev' and '664' as needed.
+files should already be installed in /usr/lib/udev/rules.d/, i.e.
+60-libsigrok.rules and one of the access granting rules files. Use of
+61-libsigrok-uaccess.rules is encouraged on systemd distributions.
+
+The access policy can be locally overridden by placing appropriate rules in
+/etc/udev/rules.d/, disabling or ammending the default policy. See the
+udev documentation, e.g. man 7 udev, for details.
If you're building from source, you need to copy the file to the place
-where your distro expects such files. This is beyond the scope of this README,
-but generally the location could be e.g. /etc/udev/rules.d, or maybe
-/lib/udev/rules.d, or something else. Afterwards you might have to restart
-udev, e.g. via '/etc/init.d/udev restart' or similar, and you'll have to
-re-attach your device via USB.
+where udev will read these rules. Local rules should go to /etc/udev/rules.d.
+Keep the file naming, otherwise interaction between the libsigrok rules and
+rules shipped by the system will be broken.
+
+Please consult the udev docs for details.
-Please consult the udev docs of your distro for details.
+
+Non-default drivers for commodity chips
+---------------------------------------
+
+Some vendors include common USB chips in their products yet assign device
+specific VID:PID pairs. Which results in the necessity for extra steps
+before the serial port can be used:
+
+- GW Instek VCP, found in GDM-8000 and probably other meters: Install the
+ vendors Windows driver to get access to a COM port. Or force the driver
+ assignment on Linux:
+ # modprobe cp210x
+ # echo 2184 0030 > /sys/bus/usb-serial/drivers/cp210x/new_id
Cypress FX2 based devices
UNI-T multimeters (and rebranded devices, e.g. some Voltcraft models) can
ship with different PC connectivity cables:
+ - UT-D02 (RS232 cable)
- UT-D04 (USB/HID cable with Hoitek HE2325U chip, USB VID/PID 04fa:2490)
- UT-D04 (USB/HID cable with WCH CH9325 chip, USB VID/PID 1a86:e008)
- - UT-D02 (RS232 cable)
+ - UT-D07 (Bluetooth adapter, ISSC BL79 BLETR chip)
+ - UT-D09 (USB/HID cable with SiL CP2110 chip, USB VID/PID 10c4:ea80)
The above cables are all physically compatible (same IR connector shape)
with all/most currently known UNI-T multimeters. For example, you can
driver _without_ the '-ser' drivername suffix (internally all of these models
are handled by the 'uni-t-dmm' driver).
+You also need to specify the USB vendor/device IDs of the cable.
+Autodetection is not possible here, since various other products use the
+USB VID/PID of those cables too, and there is no way to distinguish them.
+
Since the UT-D04 cables are USB based (but don't use a USB-to-serial chip)
there is no need to specify a serial port via 'conn', of course.
However, the user running the frontend does also need to have permissions
Examples (sigrok-cli):
- $ sigrok-cli --driver uni-t-ut61e ...
- $ sigrok-cli --driver voltcraft-vc820 ...
+ $ sigrok-cli --driver uni-t-ut61e:conn=1a86.e008 ...
+ $ sigrok-cli --driver voltcraft-vc820:conn=04fa.2490 ...
UNI-T UT-D04 cable issue on Linux
done
-ALSA driver
------------
-
-The 'alsa' driver can be used to sample analog data using a PC's soundcard.
-I.e. the sound card can act as a simple oscilloscope (with some limitations)
-using commercial or DIY "sound card scope probe" cables.
-
-Since ALSA is a Linux-specific sound system, this driver will inherently
-only compile and work on Linux.
-
-We might write additional drivers to make a similar functionality available
-on other OSes at some point.
-
-
-Link Instruments MSO-19
------------------------
-
-The driver for the Link Instruments MSO-19 mixed-signal oscilloscope (MSO)
-is currently using libudev (which is a library for the Linux-specific udev
-system). Thus, this driver can currently only compile and work on Linux.
-
-We plan to fix this though, so that it'll work on all other OSes, too.
-
-
-ChronoVu LA8 USB VID/PIDs
--------------------------
-
-The ChronoVu LA8 logic analyzer is available in two revisions. Previously,
-the LA8 shipped with a USB VID/PID of 0403:6001, which is the standard ID
+Enabling multimeter / data logger measurement output
+----------------------------------------------------
+
+Some multimeters or data loggers will not start outputting measurement data
+unless a certain action has been performed by the user beforehand. This is
+usually mentioned in the vendor manual of the respective device, but here's
+a short list for convenience:
+
+ - BBC Goertz Metrawatt M2110: Briefly press the "Start/Reset" button on the
+ interface panel on top.
+ - Brymen BM257s: Press HOLD during power-on.
+ - Digitek DT4000ZC: Briefly press the "RS232" button.
+ - EEVBlog 121GW: Hold "1ms PEAK" until the "BT" indicator is shown.
+ - ES51919 based LCR meters (DER EE DE-5000, PeakTech 2170, UNI-T UT612):
+ Press the button with the "RS232" or "USB" or "PC link" label (usually
+ the "up" cursor button).
+ - Gossen Metrawatt Metrahit 1x/2x devices, driver gmc-mh-1x-2x-rs232:
+ - Power on the device with the "DATA" button pressed.
+ - Metrahit 2x devices must be configured for the respective interface type.
+ - Gossen Metrawatt Metrahit 2x devices, driver gmc-mh-2x-bd232:
+ - 'BD232' interface:
+ The multimeter must be configured for the respective interface type.
+ - 'SI232-II' interface ("PC Mode"):
+ The multimeter must be configured for interface type 'BD232' (all),
+ 'SI232 online' (28-29S) or 'SI232 store' (22-26x). The interface must
+ be configured to the same baud rate as the host (default 9600).
+ Multimeter and interface must be configured to the same address.
+ - GW Instek GDM-397: Press the "REL/RS232C (USB)" button for roughly 1 second.
+ - GW Instek VCP: See the discussion on manual driver assignment to common
+ USB to UART chips with non-default USB identification.
+ - MASTECH MS6514: Press the "Setup/PC-Link" button for roughly 3 seconds.
+ - Meterman 38XR: Press the "RS232" button.
+ - Metrix MX56C: Press the PRINT button to have the meter send acquisition
+ data via IR. Hold the PRINT button to adjust the meter's transmission
+ interval.
+ - Norma DM950: If the interface doesn't work (e.g. USB-RS232 converter), power
+ on the device with "FUNC" pressed (to power the interface from the DMM).
+ - PCE PCE-DM32: Briefly press the "RS232" button.
+ - RadioShack 22-812: Press and hold "SELECT" and "RANGE" together.
+ - TekPower TP4000ZC: Briefly press the "RS232" button.
+ - Tenma 72-7750: Briefly press the "RS232C" button.
+ - UNI-T UT60G: Briefly press the "RS232C" button.
+ - UNI-T UT61B/C/D: Press the "REL/RS232/USB" button for roughly 1 second.
+ - UNI-T UT71x: Press the "SEND/-/MAXMIN" button for roughly 1 second.
+ Briefly pressing the "EXIT" button leaves this mode again.
+ - UNI-T UT181A: In the "SETUP" menu set "Communication" to "ON".
+ - UNI-T UT325: Briefly press the "SEND" button (as per manual). However, it
+ appears that in practice you don't have to press the button (at least on
+ some versions of the device), simply connect the device via USB.
+ - V&A VA18B/VA40B: Keep the "Hz/DUTY" key pressed while powering on the DMM.
+ - Victor 70C/86C: Press the "REL/RS232" button for roughly 1 second.
+ - Voltcraft VC-830: Press the "REL/PC" button for roughly 2 seconds.
+ - Voltcraft VC-870: Press the "REL/PC" button for roughly 1 second.
+
+
+ChronoVu LA8/LA16 USB VID/PIDs
+------------------------------
+
+The ChronoVu LA8/LA16 logic analyzer is available in two revisions. Previously,
+the device shipped with a USB VID/PID of 0403:6001, which is the standard ID
for FTDI FT232 USB chips.
-Since this made it hard to distinguish the LA8 from any other device
+Since this made it hard to distinguish the LA8/LA16 from any other device
with this FTDI chip connected to the PC, the vendor later shipped the
-LA8 with a USB VID/PID of 0403:8867.
+device with a USB VID/PID of 0403:8867.
-The 'chronovu-la8' driver in libsigrok supports both VID/PID pairs and
-automatically finds devices with either VID/PID pair. However, currently
-the driver will assume any device with VID/PID 0403:6001 is a ChronoVu LA8.
+The 'chronovu-la' driver in libsigrok supports both VID/PID pairs and
+automatically finds devices with either VID/PID pair.
OLS
---
-The Dangerous Prototypes Openbench Logic Sniffer (OLS) logic analyzer is
-supported by the 'ols' driver in libsigrok. This driver assumes a somewhat
-recent firmware has been flashed onto the OLS (it doesn't need a firmware
-upload every time it's attached via USB, since the firmware is stored in the
-device permanently).
+The Dangerous Prototypes Openbench Logic Sniffer (OLS) logic analyzer
+driver in libsigrok assumes a somewhat recent firmware has been flashed onto
+the OLS (it doesn't need a firmware upload every time it's attached via USB,
+since the firmware is stored in the device permanently).
The most recent firmware version that is tested is 3.07.
$ sigrok-cli --driver ols:conn=/dev/ttyACM0 ...
-Rigol DS1xx2 oscilloscopes
---------------------------
+JTAGulator
+----------
+
+The Grand Idea Studio JTAGulator also implements the SUMP protocol and
+thus is covered by the OLS driver. See the vendor's wiki on details how
+to enable the Logic Analyzer mode of operation.
-The 'rigol-ds1xx2' driver (for the Rigol DS1052E and some other, similar DSOs)
-currently uses the Linux usbtmc kernel driver. This means it can currently
-only be built and used on Linux (i.e., it's non-portable).
+ https://github.com/grandideastudio/jtagulator/wiki/Logic-Analyzer
-The use of a kernel module also means it is dependent on the kernel version
-used, as well as on whether this specific module is available in the kernel.
-Additionally, the usbtmc kernel module has been known to have various bugs
-in some versions. These are some (but not all) drawbacks of using a kernel
-module as opposed to a libusb-based driver that works in user-space.
-We plan to change the driver to use the 'librevisa' user-space shared
-library (which uses libusb) soon, which will fix all these issues and make
-the driver portable at the same time.
+Mooshimeter
+-----------
+
+The Mooshim Engineering Mooshimeter is controlled via Bluetooth Low Energy
+(sometimes called Bluetooth 4.0), as such it requires a supported Bluetooth
+interface available. The 'conn' option is required and must contain the
+Bluetooth MAC address of the meter.
+
+Example:
+
+ $ sigrok-cli --driver mooshimeter-dmm:conn=12-34-56-78-9A-BC ...
+
+Since the Mooshimeter has no physical interface on the meter itself, the
+channel configuration is set with the 'channel_config' option. The format
+of this option is 'CH1,CH2' where each channel configuration has the form
+'MODE:RANGE:ANALYSIS', with later parts being optional. In addition for
+CLI compatibility, the ',' in the channels can also be a '/' and the ':' in
+the individual configuration can be a ';'.
+
+Available channel 1 modes:
+
+ - Current, A: Current in amps
+ - Temperature, T, K: Internal meter temperature in Kelvin
+ - Resistance, Ohm, W: Resistance in ohms
+ - Diode, D: Diode voltage
+ - Aux, LV: Auxiliary (W input) low voltage sensor (1.2V max)
+
+Available channel 2 modes:
+
+ - Voltage, V: Voltage
+ - Temperature, T, K: Internal meter temperature in Kelvin
+ - Resistance, Ohm, W: Resistance in ohms
+ - Diode, D: Diode voltage
+ - Aux, LV: Auxiliary (W input) low voltage sensor (1.2V max)
+
+Only one channel can use the shared inputs at a time (e.g. if CH1 is measuring
+resistance, CH2 cannot measure low voltage). Temperature is excepted from
+this, so the meter can measure internal temperature and low voltage at the
+same time.
+
+Additionally, the meter can calculate the real power of both channels. This
+generally only makes sense when CH1 is set to current and CH2 is set to a
+voltage and so it is disabled by default. It must be enabled by enabling the
+'P' channel (the third channel).
+
+The range of the channel specification sets the maximum input for that channel
+and is rounded up to the next value the meter itself supports. For example,
+specifying 50 for the voltage will result in the actual maximum of 60.
+Specifying 61 would result in 600. If omitted, sigrok will perform
+auto-ranging of the channel by selecting the next greater value than the
+latest maximum.
+
+The analysis option sets how the meter reports its internal sampling buffer
+to sigrok:
+
+ - Mean, DC: The default is a simple arithmetic mean of the sample buffer
+ - RMS, AC: The root mean square of the sample buffer
+ - Buf, Buffer, Samples: Report the entire sample buffer to sigrok. This
+ results in packets that contain all the samples in the buffer instead
+ of a single output value.
+
+The size of the sample buffer is set with the 'avg_samples' option, while
+the sampling rate is set with the 'samplerate' option. So the update rate
+is avg_samples/samplerate. Both are rounded up to the next supported value
+by the meter.
+
+Example:
+ $ sigrok-cli -c channel_config="Aux;0.1/T" --driver mooshimeter-dmm...
+ $ sigrok-cli -c channel_config="A;;AC/V;;AC" --driver mooshimeter-dmm...
projects / libsigrok.git / blobdiff