| ------------------------------------------------------------------------------- |
| README.devices |
| ------------------------------------------------------------------------------- |
| |
| This README contains various notes for users of libsigrok (or frontends |
| that are based on libsigrok) about device- and/or driver-specific issues. |
| |
| |
| Firmware |
| -------- |
| |
| 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 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) |
| |
| For further information see the section below and also: |
| |
| http://sigrok.org/wiki/Firmware |
| |
| |
| Per-driver firmware requirements |
| -------------------------------- |
| |
| The following drivers/devices require a firmware upload upon connection: |
| |
| - asix-omega-rtm-cli: There is no native sigrok support for ASIX OMEGA |
| devices. But the vendor's RTM CLI application can be used in streaming |
| mode, which transparently handles the device detection and firmware |
| download. The firmware ships with the vendor application. See below |
| for details how to make the vendor application available to the sigrok |
| driver. |
| |
| - asix-sigma: The ASIX SIGMA and SIGMA2 require various firmware files, |
| depending on the settings used. These files are available from our |
| '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 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. |
| |
| - kingst-la2016: The Kingst LA series of logic analyzers needs MCU firmware |
| and FPGA netlists. The 'sigrok-util' repository contains a script to |
| extract these files from the vendor software. |
| |
| - 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 |
| - 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 |
| - manson-hcs-3xxx |
| - maynuo-m97 |
| - mic-985xx (including all subdrivers) |
| - microchip-pickit2 |
| - mooshimeter-dmm |
| - motech-lps-30x |
| - norma-dmm |
| - openbench-logic-sniffer |
| - 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 (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, 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 |
| for such devices without specifying a serial port. |
| |
| 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>[/param=value] |
| 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) |
| additional parameter keywords can be: channel, handle_rx, handle_tx, |
| handle_cccd, value_cccd, mtu |
| |
| 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 |
| --------------------------------- |
| |
| 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. |
| |
| Example: |
| |
| $ sigrok-cli --driver <somedriver>:conn=<someconn>:serialcomm=9600/7n1/dtr=1 |
| |
| |
| Permissions of serial port based devices |
| ---------------------------------------- |
| |
| When using devices supported by libsigrok that use serial port based cables |
| (real RS232 or USB-to-serial ones) to connect to a PC, you need to ensure |
| that the user running the libsigrok frontend has (read/write) permissions to |
| access the serial port device (e.g. /dev/ttyS0, /dev/ttyUSB0, and so on). |
| |
| You can use 'chmod' to apply permissions as you see fit, and/or 'chown' to |
| change the owner of the serial port device to a certain user or group. |
| |
| For USB-to-serial based devices, we recommended using our udev rules file |
| (see below for details). |
| |
| |
| 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 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/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 |
| 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 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. |
| |
| |
| Assigning drivers to devices (Windows, Zadig) |
| --------------------------------------------- |
| |
| On Windows systems it may be necessary to assign drivers to devices |
| before libusb based applications can access them. It may be necessary |
| to re-run this driver assignment after firmware upload in case the |
| device changes its USB identification as a consequence of loading the |
| firmware image. |
| |
| The https://sigrok.org/wiki/Windows wiki page discusses this subject, |
| and other platform specific aspects. |
| |
| |
| 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 |
| ------------------------- |
| |
| Devices using the Cypress FX2(LP) chip without any specific USB VID/PID will |
| be enumerated with VID/PID 04b4:8613 (the default for "unconfigured FX2"). |
| These are usually "FX2 eval boards" (that can also be used as LAs, though). |
| |
| On Linux, the 'usbtest' driver will usually grab such devices, and they will |
| thus not be usable by libsigrok (and frontends). |
| |
| You can fix this by running 'rmmod usbtest' as root before using the device. |
| |
| |
| UNI-T DMM (and rebranded models) cables |
| --------------------------------------- |
| |
| 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-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 |
| use either of the UT-D04 USB/HID cables or the UT-D02 RS232 cable with |
| the UNI-T UT61D multimeter. |
| |
| When using the UT-D02 RS232 cable with any of the supported UNI-T DMMs, |
| you have to use the respective driver with a '-ser' drivername suffix |
| (internally all of these models are handled by the 'serial-dmm' driver). |
| |
| You also need to specify the serial port via the 'conn' option, e.g. |
| /dev/ttyUSB0 (attached via a USB-to-serial cable) or /dev/ttyS0 (actual |
| RS232 port) on Linux (see above). |
| |
| Finally, the user running the frontend (e.g. sigrok-cli) also needs |
| permissions to access the respective serial port (see above). |
| |
| Examples (sigrok-cli): |
| |
| $ sigrok-cli --driver uni-t-ut61e-ser:conn=/dev/ttyUSB0 ... |
| $ sigrok-cli --driver voltcraft-vc820-ser:conn=/dev/ttyS0 ... |
| $ sigrok-cli --driver uni-t-ut61e-ser:conn=hid/cp2110 |
| |
| Using any of the UT-D04 et al USB/HID cables can be done in two different |
| ways: Use transparent serial over HID support in libsigrok, by giving the |
| -ser driver a conn=hid/... serial port spec. This re-uses the 'serial-dmm' |
| driver, results in better coverage of these code paths, and reduces |
| maintenance overhead. Or by running non-ser drivers and passing USB |
| specific connection details. When the driver _without_ the '-ser' suffix |
| is used, the models are handled by the 'uni-t-dmm' driver. These duplicate |
| drivers only exist for historical reasons, the redundancy may result in |
| differences of behaviour between the two implementations. When in doubt, |
| check if the '-ser' driver works for you. |
| |
| In the USB specific driver case you need to specify the cable's vendor |
| and product IDs. 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. The sigrok software errs on the safe side, and won't |
| communicate to serial ports unless explicitly instructed by the user. |
| |
| The user running the frontend does also need to have permissions to |
| access the respective USB device (see above). |
| |
| Examples (sigrok-cli): |
| |
| $ 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 |
| --------------------------------- |
| |
| The UNI-T UT-D04 cable with Hoitek HE2325U (or WCH CH9325) chip seems to have |
| a very specific problem on Linux. Apparently it requires to be put into |
| suspend (and woken up again) before it is usable. This seems to be a |
| Linux-only issue, Windows is not affected by this since apparently the |
| Windows kernel does this for every USB device, always. |
| |
| Thus, if you want to use any of the UNI-T DMMs with this specific cable, |
| you'll have to run the following script (as root) once, every time you attach |
| the cable via USB. The script was written by Ralf Burger. |
| |
| See also: http://erste.de/UT61/index.html |
| |
| #!/bin/bash |
| for dat in /sys/bus/usb/devices/*; do |
| if test -e $dat/manufacturer; then |
| grep "WCH.CN" $dat/manufacturer > /dev/null && echo auto > ${dat}/power/level && echo 0 > ${dat}/power/autosuspend |
| fi |
| done |
| |
| |
| UNI-T UT-D04 cable issue on Windows |
| ----------------------------------- |
| |
| There have been reports that CH9325 based cables are not detected on |
| Windows out of the box when they are assigned to libwdi drivers. Though |
| they may be usable in that case when the USB address is manually specified. |
| This can happen when some "USB to serial" driver is assigned which does not |
| provide a genuine COM port that enumerates naturally. Manually assigning a |
| "USB input device" driver can improve HIDAPI compatibility and make the |
| cable show up in sigrok's serial port enumeration. |
| |
| |
| 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. |
| |
| |
| ASIX OMEGA in RTM CLI mode |
| -------------------------- |
| |
| The asix-sigma driver can detect the Omega devices' presence, but does |
| not support their protocol and emits a diagnostics message. The firmware |
| image is not available for distribution, and information on the protocol |
| is not available. That's why native support is in some distant future. |
| Yet basic operation of Omega devices is available by using the vendor's |
| command line application for real time mode (RTM CLI). |
| |
| The vendor application targets Windows (on x86), but also executes on |
| Linux when 32bit libraries for FTDI communication are provided. The |
| user manual discusses the installation. The sigrok asix-omega-rtm-cli |
| driver uses the vendor provided omegartmcli.exe binary to configure the |
| device for streaming, and to acquire sample data. |
| |
| Either make an "omegartmcli" executable available in PATH. This can be |
| the vendor's executable or some wrapper around it or a symlink to it. |
| Or specify the executable's location in the OMEGARTMCLI environment |
| variable. The sigrok driver accepts an optional serial number (six or |
| eight hex digits) to select one out of several connected devices. |
| |
| (optional) |
| $ export "OMEGARTMCLI=$HOME/.wine/drive_c/progx86/ASIX/SIGMA/omegartmcli.exe" |
| |
| (optional) |
| $ OMEGASN=":conn=sn=a6030123" |
| |
| (example use) |
| $ sigrok-cli -d asix-omega-rtm-cli${OMEGASN} --show |
| $ sigrok-cli -d asix-omega-rtm-cli${OMEGASN} -o capture.sr --time 10s |
| $ sigrok-cli -d asix-omega-rtm-cli${OMEGASN} -o capture.sr --samples 100m |
| $ pulseview -d asix-omega-rtm-cli${OMEGASN} |
| |
| The RTM mode of operation samples 16 channels at a fixed rate of 200MHz. |
| Hardware triggers are not available in this mode. Glib should handle |
| platform specific details of external process execution, but the driver |
| was only tested on Linux so far. Acquisition start in sigrok applications |
| may take some time before sample data becomes available (roughly one |
| second here on a slow machine). This is an implementation detail of the |
| RTM CLI approach including execution under wine. |
| |
| The reliability of that setup in the presence of fast changing input |
| signals is yet to get determined. It's assumed that slow input signals |
| are operational. It's essential that the _average_ rate of changes in |
| the input signal in combination with the hardware compression are such |
| that the FTDI FIFO can communicate all involved data via USB2.0 to the |
| application. Intermediate bursts of rapid changes shall not be an issue |
| given the Omega devices' deep memory which RTM uses for buffering. |
| |
| Native support for the Asix Omega devices depends on the availability of |
| a protocol description and use of the protocol depends on the firmware's |
| availability at the user's site. Which then would allow to capture to |
| DRAM at high rates without the communication bottleneck, before the data |
| gets communicated to the PC after the acquisition has completed. Compare |
| the native sigrok support for Asix Sigma. |
| |
| |
| 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/LA16 from any other device |
| with this FTDI chip connected to the PC, the vendor later shipped the |
| device with a USB VID/PID of 0403:8867. |
| |
| 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 |
| 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. |
| |
| If you use any older firmware and your OLS is not found or is not working |
| properly, please upgrade to at least this firmware version. Check the |
| Dangerous Prototypes wiki for firmware upgrade instructions: |
| |
| http://dangerousprototypes.com/docs/Logic_Sniffer_upgrade_procedure |
| |
| Also, you need to specify a serial port for the OLS in the frontends, e.g. |
| using the 'conn' option in sigrok-cli, and you also need to have the |
| permissions to access the serial port (see above). |
| |
| Example: |
| |
| $ sigrok-cli --driver ols:conn=/dev/ttyACM0 ... |
| |
| |
| 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. |
| |
| https://github.com/grandideastudio/jtagulator/wiki/Logic-Analyzer |
| |
| |
| 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... |