8 months agoasix-omega-rtm-cli: Implement RTM for ASIX OMEGA via external CLI process
Gerhard Sittig [Mon, 11 Oct 2021 20:09:44 +0000 (22:09 +0200)]
asix-omega-rtm-cli: Implement RTM for ASIX OMEGA via external CLI process

The ASIX OMEGA vendor software provides a commandline application which
puts the device in "real time mode". The process' stdout provides a
continuous RLE compressed stream of samples for the 16 input signals,
recorded at 200MHz. The sigrok driver starts and terminates this process
for the duration of the acquisition.

This simple approach makes the OMEGA device available in a basic mode of
operation. The samplerate is fixed, hardware triggers are not available.
The binary data format is used to reduce the amount of inter process
communication. The vendor's Windows software also executes in Linux
under wine(1). All device detection, USB communication via FTDI FIFO
mode, firmware download, etc are transparently dealt with. This mode of
operation is an officially supported and documented feature.

The sigrok driver accepts the OMEGARTMCLI environment variable as the
specification of the vendor application's location, or falls back to the
omegartmcli executable name which should be in PATH. The conn= spec in
the sn= format can select one out of multiple connected devices.

The driver was tested on Linux with --samples and --time as well as with
Pulseview and manual acquisition stop while a huge limit was configured
that would not take effect.

8 months agoasix-omega-rtm-cli: Initial driver skeleton.
Gerhard Sittig [Mon, 11 Oct 2021 20:06:19 +0000 (22:06 +0200)]
asix-omega-rtm-cli: Initial driver skeleton.

8 months agosw_limits: extend API to "get remaining counts" before the limit is reached
Gerhard Sittig [Tue, 12 Oct 2021 14:34:32 +0000 (16:34 +0200)]
sw_limits: extend API to "get remaining counts" before the limit is reached

The current sw_limits API provides routines which interface nicely with
config get/set and Glib data types, and which check whether a limit was
exceeded after previous submission of samples (summary result).

Device drivers may want to check _before_ a limit was reached, some may
want to cap to-get-submitted sample data such that a limit gets reached
but is not exceeded. This need becomes more obvious when devices with
efficient hardware compression "severely overshoot" the user specified
limits when the check is only done late after submission of another
chunk of data which results from uncompression.

Introduce an API routine which gets the remaining count until the limit
is reached. Phrase the implementation for cheapest cost of execution.
These routines may execute in tight loops in acquisition code paths.

8 months agoinput: accept const sdi in feed queue API
Gerhard Sittig [Tue, 12 Oct 2021 14:29:24 +0000 (16:29 +0200)]
input: accept const sdi in feed queue API

The common feed queue support code needs an sdi to submit sample data to
the session feed. Decorate this argument as const to silence compiler
warnings. This matches the sr_session_send() API.

8 months agokingst-la2016: setup usb transfer sizes to be multiple of endpoint max packet size...
Kevin Grant [Fri, 1 Oct 2021 17:04:08 +0000 (18:04 +0100)]
kingst-la2016: setup usb transfer sizes to be multiple of endpoint max packet size, as required by WinUSB RAW_IO policy

9 months agozketech-ebd-usb: Minor style fixes
Soeren Apel [Mon, 13 Sep 2021 20:13:16 +0000 (22:13 +0200)]
zketech-ebd-usb: Minor style fixes

9 months agozketech-ebd-usb: Style fixes
Frank Stettner [Sun, 5 Sep 2021 13:10:20 +0000 (15:10 +0200)]
zketech-ebd-usb: Style fixes

9 months agozketech-ebd-usb: Multiple fixes and upgrades.
King Kévin [Fri, 11 Dec 2020 20:18:55 +0000 (21:18 +0100)]
zketech-ebd-usb: Multiple fixes and upgrades.

- fix load toggling at acquisition stop
- messages are sent byte per byte with a pause in between since bytes were
  sometimes dropped
- incoming stream is parsed continuously instead of using a fixed length (the
  messages have a constant start/stop)
- add under-voltage threshold (under which the load would stop) as configuration
- add D+/D- voltage measurements as two new channels (had to rename the
  existing to avoid confusion)

9 months agokingst-la2016: Minor style fixes
Soeren Apel [Fri, 10 Sep 2021 21:31:33 +0000 (23:31 +0200)]
kingst-la2016: Minor style fixes

9 months agokingst-la2016: add support for kingst la1016
Kevin Grant [Mon, 5 Apr 2021 12:01:16 +0000 (13:01 +0100)]
kingst-la2016: add support for kingst la1016

The Kingst LA2016 and LA1016 use the same hardware, just the coding
of authentication IC U10 is different. U10 limits the LA1016 to
using an FPGA bitstream that samples at a maximum of 100MHz. Other
than that, the devices operate identically and the driver just needs
to select the correct bitstream and limit the maximum sample rate
appropriately. This commit adds support for the existing two hardware
revisions of LA1016, which require different bitstreams.

9 months agokingst-la2016: avoid filling the log file with redundant messages during long captures
Kevin Grant [Mon, 5 Apr 2021 10:31:34 +0000 (11:31 +0100)]
kingst-la2016: avoid filling the log file with redundant messages during long captures

9 months agokingst-la2016: add support for both LA2016 hardware revisions
Kevin Grant [Mon, 5 Apr 2021 09:33:20 +0000 (10:33 +0100)]
kingst-la2016: add support for both LA2016 hardware revisions

A magic number within the device eeprom identifies the device
type and hardware revision. Using this number, the correct
fpga bitstream is selected and loaded.

9 months agokingst-la2016: remove unnecessary initialisation code
Kevin Grant [Sun, 4 Apr 2021 10:21:29 +0000 (11:21 +0100)]
kingst-la2016: remove unnecessary initialisation code

The OEM software communicates with device IC U10 to perform challenge-response
authentication, ensuring the device is genuine. We have no knowledge of the
obfuscation or encryption method used. Additionally it is a rolling code, so
the response changes even with same challenge. In any case, we can just ignore
this IC U10, it does not hinder sigrok support. Removing this code from
the initialisation routine. See schematic in wiki for more info on U10.

9 months agokingst-la2016: fix segfault that often occurs when a capture is aborted
Kevin Grant [Sat, 3 Apr 2021 20:57:14 +0000 (21:57 +0100)]
kingst-la2016: fix segfault that often occurs when a capture is aborted

9 months agokingst-la2016: fix fpga register alignment for sampling configuration
Kevin Grant [Sat, 3 Apr 2021 20:46:18 +0000 (21:46 +0100)]
kingst-la2016: fix fpga register alignment for sampling configuration

9 months agokingst-la2016: fix input threshold adjustment
Kevin Grant [Sat, 3 Apr 2021 20:34:41 +0000 (21:34 +0100)]
kingst-la2016: fix input threshold adjustment

There are, in fact, two pwm outputs which must both be configured to
control the dac output which offsets input signals. See the last two
pages of the schematic (on wiki) for details.

9 months agokingst-la2016: fix the fpga register addresses
Kevin Grant [Sat, 3 Apr 2021 20:09:45 +0000 (21:09 +0100)]
kingst-la2016: fix the fpga register addresses

Fix the address of registers within the fpga which are used for contolling
input thresholds, sampling, triggering and bulk transfers. These addresses
were derived from observations of the usb bus and of the internal la2016
spi bus. See wiki for captures of spi bus activity.

9 months agokingst-la2016: replace usb control transfer brequest numbers with more meaningful...
Kevin Grant [Sat, 3 Apr 2021 19:49:25 +0000 (20:49 +0100)]
kingst-la2016: replace usb control transfer brequest numbers with more meaningful tokens

9 months agools: Fix off-by-one when setting up trigger stages
v1ne [Tue, 23 Feb 2021 21:36:34 +0000 (22:36 +0100)]
ols: Fix off-by-one when setting up trigger stages

The additional stage prevented OLS from using 4 stages.

9 months agools: Fix demuxer operation
v1ne [Tue, 23 Feb 2021 21:36:33 +0000 (22:36 +0100)]
ols: Fix demuxer operation

On my OLS with Demon Core (v3.07), the following command produces only low
levels on channels 8-15:
sigrok-cli -d ols:conn=/dev/ttyACM0 --output-format ascii:width=128 \
  --config='samplerate=200M:pattern=Internal:captureratio=50' \
  --channels 0-15 --samples 32 --triggers "12=1"

This doesn't make sense since it only triggers if channel 12 is high.
By not overwriting the channel data, I get the desired output. The data
is processed in groups of 2 bytes, so there's no need to fold back "input"
from devc->sample[2..3] because these bytes are always zero.

9 months agools: Don't silently ignore error when setting up the device
v1ne [Tue, 23 Feb 2021 21:36:33 +0000 (22:36 +0100)]
ols: Don't silently ignore error when setting up the device

9 months agools: Don't store temporary data in device context
v1ne [Tue, 23 Feb 2021 21:36:33 +0000 (22:36 +0100)]
ols: Don't store temporary data in device context

9 months agools: Provide sample count in RLE mode
v1ne [Tue, 23 Feb 2021 21:36:32 +0000 (22:36 +0100)]
ols: Provide sample count in RLE mode

It just means "number of compressed samples", but it's still highly useful
to decice how much data to capture. If this is unavailable, PulseView
provides a weird list of up to 1 TSmpl, which makes even less sense.

9 months agools: Clean up: Obey code style
v1ne [Sat, 23 Jan 2021 21:50:10 +0000 (22:50 +0100)]
ols: Clean up: Obey code style

9 months agoscpi-pps: Support for the EEZ PSU series
Martin Atkins [Sun, 25 Oct 2020 11:39:15 +0000 (04:39 -0700)]
scpi-pps: Support for the EEZ PSU series

There is currently one released model and one other model under
development. This change aims to support both of them, though it's been
tested primarily with the original H24005 series and only with the
simulator for the BB3 series.

[ gsi: address style nits ]

9 months agoscpi-pps: Data capture dynamically-probed channels
Martin Atkins [Sun, 25 Oct 2020 20:16:37 +0000 (13:16 -0700)]
scpi-pps: Data capture dynamically-probed channels

For the few device profiles that probe the device dynamically to determine
channel settings, the results end up in the dynamically-allocated
devc->channels instead of in the statically-configured
devc->device->channels field.

Previously this would crash by dereferencing a null ch_spec for the
device types that do dynamic channel configuration.

[ gsi: address minor style nits ]

10 months agoAdd support for TENMA 72-2710 V6.6 power supply
Tim Van Helleputte [Mon, 26 Jul 2021 16:17:25 +0000 (18:17 +0200)]
Add support for TENMA 72-2710 V6.6 power supply

10 months agoitech-it8500: Remove SR_MQFLAG_DC from power values.
Frank Stettner [Sun, 22 Aug 2021 10:05:42 +0000 (12:05 +0200)]
itech-it8500: Remove SR_MQFLAG_DC from power values.

10 months agohp-59306a: Rename channel groups from CHn to Rn
Frank Stettner [Sat, 7 Aug 2021 17:22:04 +0000 (19:22 +0200)]
hp-59306a: Rename channel groups from CHn to Rn

Also fix the long name in the sr_dev_driver struct

10 months agohp-59306a: Add GET for config key SR_CONF_CONN
Frank Stettner [Sat, 7 Aug 2021 17:18:39 +0000 (19:18 +0200)]
hp-59306a: Add GET for config key SR_CONF_CONN

10 months agohp-59306a: Enable/disable all outputs at once.
Frank Stettner [Sun, 25 Jul 2021 09:54:58 +0000 (11:54 +0200)]
hp-59306a: Enable/disable all outputs at once.

10 months agoinput/saleae: silence overzealous compiler warning
Gerhard Sittig [Wed, 21 Jul 2021 21:48:22 +0000 (23:48 +0200)]
input/saleae: silence overzealous compiler warning

Although the number of channels in data files saved by the Saleae export
feature remains small, recent compilers keep complaining about potential
truncation. Use a larger buffer to silence the warning message. No change
in behaviour.

10 months agodmm/bm52x: silence overzealous compiler warning
Gerhard Sittig [Wed, 21 Jul 2021 21:46:49 +0000 (23:46 +0200)]
dmm/bm52x: silence overzealous compiler warning

Although the number of recordings in the BM52x DMM remains small, recent
compilers keep complaining about potential truncation. Use a larger
buffer to silence the warning message. No change in behaviour.

10 months agotests: unbreak endianess conversion test routine (too small a buffer)
Gerhard Sittig [Wed, 21 Jul 2021 21:33:23 +0000 (23:33 +0200)]
tests: unbreak endianess conversion test routine (too small a buffer)

Writing four times 48 bits to a buffer that is two times 64 bits will
exceed that buffer. Fix an issue introduced in commit 8f87c5284bf0.

10 months agodoc: update README.devices for conn=sn=<serno> (driver specific)
Gerhard Sittig [Wed, 4 Aug 2021 19:06:30 +0000 (21:06 +0200)]
doc: update README.devices for conn=sn=<serno> (driver specific)

Mention the optional availability of the conn=sn=<serno> format to
select one of several connected devices.

10 months agodcttech-usbrelay: accept conn=sn=<serno> user specs in probe
Gerhard Sittig [Wed, 4 Aug 2021 18:52:41 +0000 (20:52 +0200)]
dcttech-usbrelay: accept conn=sn=<serno> user specs in probe

Add support for the "-d dcttech-usbrelay:conn=sn=<serno>" syntax.

This dramatically increases usability when multiple cards are attached
(a very likely condition given the low channel count of these devices),
while other means to select one card out of a set of cards either don't
exist or are heavily constrained: Identical VID:PID numbers are shared
across all card variants. HIDAPI paths are rather platform dependent and
may even be incompatible with the conn= syntax. Some platforms may even
refuse to open() paths which result from their own enumeration. Which
leaves relay card serial numbers as the only reliable and portable
method for selection. Being convenient is just a bonus.

11 months agoconrad-digi-35-cpu: Remove CH1 from device.
Frank Stettner [Fri, 23 Jul 2021 09:59:03 +0000 (11:59 +0200)]
conrad-digi-35-cpu: Remove CH1 from device.

This device is write only and does not transmit any measurement data.
Therefore a channel is not necessary.

11 months agodcttech-usbrelay: support specs in addition to paths
Gerhard Sittig [Fri, 23 Jul 2021 17:50:45 +0000 (19:50 +0200)]
dcttech-usbrelay: support specs in addition to paths

Extend the scan code path, accept user provided conn= specs in the
"" format. Everything else is assumed to be a hidapi compatible
"path" and may suffer from conn= parser limitations. Unfortunately the
hidapi API won't let us lookup paths from bus.addr specs which would
work when multiple cards need to be told apart.

11 months agodcttech-usbrelay: accept conn= spec different from hidapi enum details
Gerhard Sittig [Thu, 22 Jul 2021 06:03:11 +0000 (08:03 +0200)]
dcttech-usbrelay: accept conn= spec different from hidapi enum details

Rework the scan and probe routines. Skip the USB enumeration's result
set when the user provided a conn= spec, instead exclusively open the
specified device. It's acceptable when this user spec does not match
the details which the hidapi enumeration would yield. [ This version
prepares but does not implement yet support for "funny" hidapi(3) paths
on platforms beyond Linux. ]

This also weakens the logic which determines the relay count from the
USB product string. Any trailing number is accepted. Which allows to use
compatible devices with differing vendor/product strings when conn= is
specified. The previous "USBRelay" prefix check remains in place for
automatic enumeration.

Beautify diagnostics, even phrase debug and spew level messages such
that they can be presented to users. Makes -l 5 look more consistent.

11 months agodcttech-usbrelay: rework scan (enumeration) and probe (identification)
Gerhard Sittig [Thu, 22 Jul 2021 05:59:34 +0000 (07:59 +0200)]
dcttech-usbrelay: rework scan (enumeration) and probe (identification)

Move all of the sdi creation into the probe routine which communicates
to the relay card. Extend diagnostics in that code path. Which leaves
pure USB enumeration in the scan routine.

11 months agodcttech-usbrelay: adjust serial number and connection string logic
Gerhard Sittig [Thu, 22 Jul 2021 05:09:48 +0000 (07:09 +0200)]
dcttech-usbrelay: adjust serial number and connection string logic

Store the USB relay card's serial number such that users can tell apart
multiple connected cards. Hold the HIDAPI path in the 'connection_id'
member because 'conn' is something internal, not for display purposes.

11 months agocontrib: add udev rule for V-USB based HID devices (USB relay card)
Gerhard Sittig [Wed, 21 Jul 2021 18:44:25 +0000 (20:44 +0200)]
contrib: add udev rule for V-USB based HID devices (USB relay card)

Add the USB identification of the USBRelay<n> card. Which
happens to be shared with other V-USB based firmware projects. Thus is
rather generic. The USB relay card is just the first supported device
of that kind.

11 months agodcttech-usbrelay: implement multiplexer driver for USB relay card
Gerhard Sittig [Wed, 21 Jul 2021 18:30:29 +0000 (20:30 +0200)]
dcttech-usbrelay: implement multiplexer driver for USB relay card

Implement support for the " USBRelay<n>" card. This V-USB
based HID device communicates HID reports to control up to 8 relays. The
driver depends on the HIDAPI external dependency for maximum portability.

Support for the conn= parameters is limited. A path that HIDAPI can open
is expected, which depends on the platform and HIDAPI implementation,
and may not always be expressed by means of sigrok command line options.
See README.devices for a discussion.

The USB serial number is not considered. This is an implementation
detail of the relay card's firmware. HID reports carry a five character
identifier for the board.

Relay state is cached in the driver. It's assumed that relay state won't
change outside of libsigrok control as long as the device is opened. The
single request to activate/deactivate all relays at once is supported.

11 months agodcttech-usbrelay: Initial driver skeleton.
Gerhard Sittig [Wed, 21 Jul 2021 18:03:52 +0000 (20:03 +0200)]
dcttech-usbrelay: Initial driver skeleton.

11 months agohp-3478a: Fix switching from 4-wire to 2-wire measurement.
Frank Stettner [Mon, 24 May 2021 11:02:00 +0000 (13:02 +0200)]
hp-3478a: Fix switching from 4-wire to 2-wire measurement.

The measured quantity flags for the measurement mode can only contain one flag
at maximum. Therefore the quantity flags handling can be simplified, which also
fixes a bug when switching from 4-wire resistance measurement to 2-wire mode.

11 months agohp-3478a: Only match when conn= is given to avoid false probe positives.
Frank Stettner [Mon, 24 May 2021 10:56:52 +0000 (12:56 +0200)]
hp-3478a: Only match when conn= is given to avoid false probe positives.

The HP 3478A device would not reliably identify by means of SCPI queries. The
previous scan() implementation would have matched any connected SCPI device,
then upset these devices by emitting non-SCPI requests.

Tighten the scope of the hp-3478a probe, only scan for devices when a conn=
spec was provided. This avoids false positives and malfunction of other
devices, and still lets users address the problematic device. This is similar
to serial-dmm and unspecific cables and has proven to work there.

11 months agoscpi_vxi: Unbreak MacOS build (vxi.h inclusion order).
Frank Stettner [Wed, 23 Jun 2021 08:53:24 +0000 (10:53 +0200)]
scpi_vxi: Unbreak MacOS build (vxi.h inclusion order).

Undo the #include statement order change of commit 7414fb55cb1f. It's
essential on MacOS to include vxi.h early to keep related u_long et al
data types available. See commit d40b8557a962 for a discussion.

Also drop the inclusion of rpc/rpc.h from scpi_vxi.c because it is not
used in that source file, instead is a vxi.h dependency and is included

[ gsi: rephrase commit message ]

11 months agohp-3478a: avoid NULL dereference in config API routines
Gerhard Sittig [Mon, 28 Jun 2021 05:34:23 +0000 (07:34 +0200)]
hp-3478a: avoid NULL dereference in config API routines

The 'sdi' parameter to config API calls can be NULL. Only dereference
after checking its validity.

Reported-By: Alexandre Ferreira <>
12 months agodoc: update IRC reference to Libera.Chat
Gerhard Sittig [Wed, 16 Jun 2021 18:52:01 +0000 (20:52 +0200)]
doc: update IRC reference to Libera.Chat

12 months agorigol-ds: fix use-after-free
Ralf [Mon, 7 Jun 2021 05:08:06 +0000 (07:08 +0200)]
rigol-ds: fix use-after-free

This amends commit 4fad41a8a4f3 which fixed a leak but introduced the
use after free.

12 months agoscpi_vxi: fix memory leak for SCPI response data in VXI support code
Daniel Anselmi [Fri, 21 May 2021 12:30:17 +0000 (14:30 +0200)]
scpi_vxi: fix memory leak for SCPI response data in VXI support code

Routine scpi_vxi_read_data() invokes device_read_1(), which provides a
static buffer where dynamically allocated memory for SCPI response data
is kept. Release this memory after getting a copy of the response data,
before the next device_read_1() call loses the reference.

Valgrind stats without the fix:

  ==238825== LEAK SUMMARY:
  ==238825== definitely lost: 45,547,737 bytes in 18,331 blocks
  ==238825== indirectly lost: 0 bytes in 0 blocks
  ==238825== possibly lost: 48,154 bytes in 14 blocks
  ==238825== still reachable: 42,859 bytes in 288 blocks
  ==238825== suppressed: 0 bytes in 0 blocks

Valgrind stats with the fix:

  ==239413== LEAK SUMMARY:
  ==239413== definitely lost: 40 bytes in 2 blocks
  ==239413== indirectly lost: 0 bytes in 0 blocks
  ==239413== possibly lost: 0 bytes in 0 blocks
  ==239413== still reachable: 38,613 bytes in 287 blocks
  ==239413== suppressed: 0 bytes in 0 blocks

Remaining leaks in scpi_vxi_open() are of lesser severity because they
don't accumulate during execution.

[ gsi: rebase to recent master, reword commit message ]

12 months agoscpi_vxi: readability nits in the SCPI via VXI source code
Gerhard Sittig [Sun, 6 Jun 2021 14:06:51 +0000 (16:06 +0200)]
scpi_vxi: readability nits in the SCPI via VXI source code

Address style nits to improve readablity and future maintenance.
Move system header includes before application level includes. Move
assignments out of variable declaration blocks. Separate function calls
and assignments from error checks and flow control. Break a long line.
Add braces around conditional multi line statements.

All these adjustments are cosmetical. Behaviour does not change.

12 months agocontrib: add udev rule for Agilent 34460A USBTMC
Sylvain Pelissier [Tue, 25 May 2021 11:01:26 +0000 (13:01 +0200)]
contrib: add udev rule for Agilent 34460A USBTMC

12 months agoscpi-dmm: Add support for Agilent 34460A
Sylvain Pelissier [Mon, 17 May 2021 11:39:00 +0000 (13:39 +0200)]
scpi-dmm: Add support for Agilent 34460A

[ gsi: rebase and squash, specify delays like Keysight 34465A ]

12 months agoscpi-dmm: add short measurement delay for 34465A
Gerhard Sittig [Sat, 22 May 2021 13:19:05 +0000 (15:19 +0200)]
scpi-dmm: add short measurement delay for 34465A

With Keysight 34465A the VOLT:AC and FREQ functions keep suffering from
USB timeouts and pipe errors. Add a 10ms delay between initiating the
acquisition and checking for completion before fetching the result.

The weird thing is that when successful responses are seen after
temporary failure, enlarging the delay does not make them go away.
Instead the USB errors keep moving to a different spot. Measurements do
arrive though, so this is just annyoing but not a blocker.

  sr: [00:00.134038] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.136043] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
  sr: [00:00.136119] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +3.00000000E+00,+3.00000000E-06"'
  sr: [00:00.136251] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.184211] scpi: Got response: '1', length 1.
  sr: [00:00.184481] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
  sr: [00:00.234800] session: bus: Received SR_DF_HEADER packet.
  cli: Received SR_DF_HEADER.
  sr: [00:00.245597] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.246050] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:01.256495] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.291871] scpi_usbtmc: USBTMC invalid bulk in header.
  sr: [00:01.302392] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.401959] scpi: Got response: '1', length 1.
  sr: [00:01.402135] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.403392] scpi: Got response: '1', length 1.
  sr: [00:01.403566] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:01.405769] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
  sr: [00:01.406020] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.407500] scpi: Got response: '1', length 1.
  sr: [00:01.407674] scpi_usbtmc: Successfully sent SCPI command: 'FETCH?'.
  sr: [00:01.409107] scpi: Got response: '+9.00555531E+01', length 15.

Experimentation suggests that 200ms timeouts reduce the probability of
these USB communication errors. But if functions tend to respond that
differently, are delay time specs per MQ required? The implementation of
the driver currently assumes a single delay spec.

12 months agoscpi-dmm: model and MQ dependent delay before measurement
Gerhard Sittig [Sat, 22 May 2021 08:39:10 +0000 (10:39 +0200)]
scpi-dmm: model and MQ dependent delay before measurement

Some models are slow to start a measurement acquisition in specific MQs
(meter functions). An "*OPC?" query went unanswered after "INIT" was
sent. This was observed on 34405A in temperature, frequency, resistance,
AC voltage and current mode.

Add an optional per-model measurement delay that is used when the MQ
specifies that the delay is applicable. Because functions are changed
rarely but measurements are taken many times, only the first reading
is delayed while later readings are seen at the expected interval. Not
delaying the first reading will result in device errors.

  sr: [00:00.875162] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.881666] scpi: Got response: '"FREQ +1.00000E+00,+1.00000E-05"', length 32.
  sr: [00:00.881700] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +1.00000E+00,+1.00000E-05"'
  sr: [00:00.881840] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.883966] scpi: Got response: '1', length 1.
  sr: [00:00.884139] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
  sr: [00:01.884420] session: bus: Received SR_DF_HEADER packet.
  cli: Received SR_DF_HEADER.
  sr: [00:01.895260] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.895766] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:02.906302] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.910703] scpi_usbtmc: USBTMC invalid bulk in header.
  sr: [00:02.921244] scpi_usbtmc: USBTMC bulk out transfer error: LIBUSB_ERROR_PIPE.
  sr: [00:02.931802] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.932276] scpi: Got response: '1', length 1.
  sr: [00:02.932425] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.934790] scpi: Got response: '1', length 1.
  sr: [00:02.935155] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:02.941564] scpi: Got response: '"FREQ +1.00000E+00,+1.00000E-05"', length 32.

  sr: [00:00.173408] hwdriver: scpi-dmm: Starting acquisition.
  sr: [00:00.173569] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.334312] scpi: Got response: '1', length 1.
  sr: [00:00.334544] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.341070] scpi: Got response: '"RES +1.00000E+02,+1.00000E-03"', length 31.
  sr: [00:00.341307] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.343636] scpi: Got response: '1', length 1.
  sr: [00:00.343872] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.350093] scpi: Got response: '"RES +1.00000E+02,+1.00000E-03"', length 31.
  sr: [00:00.350157] scpi-dmm: dev_acquisition_start: Precision: '"RES +1.00000E+02,+1.00000E-03"'
  sr: [00:00.350342] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.352524] scpi: Got response: '1', length 1.
  sr: [00:00.352832] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
  sr: [00:00.352901] session: bus: Received SR_DF_HEADER packet.
  cli: Received SR_DF_HEADER.
  sr: [00:00.363675] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.364363] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:01.374904] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.375380] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:02.385872] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.232457] scpi_usbtmc: USBTMC invalid bulk in header.
  sr: [00:03.243003] scpi_usbtmc: USBTMC bulk out transfer error: LIBUSB_ERROR_PIPE.
  sr: [00:03.253464] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.256568] scpi: Got response: '1', length 1.
  sr: [00:03.256902] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.259440] scpi: Got response: '1', length 1.
  sr: [00:03.259713] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:03.266070] scpi: Got response: '"RES +1.00000E+08,+1.00000E+3"', length 30.
  sr: [00:03.266456] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.268501] scpi: Got response: '1', length 1.
  sr: [00:03.268961] scpi_usbtmc: Successfully sent SCPI command: 'READ?'.
  sr: [00:03.353589] scpi: Got response: '+9.90000000E+37 ', length 16.

Declare a 2500ms measurement initiation delay for 34405A which was found
by experimentation. This is huge but was found to be necessary.

Of course all other meter functions are unaffected by this commit. As
are the meters which specify no delay.

12 months agoscpi-dmm: model and MQ dependent delay when switching functions
Gerhard Sittig [Sat, 22 May 2021 08:22:28 +0000 (10:22 +0200)]
scpi-dmm: model and MQ dependent delay when switching functions

Some models are slow to switch meter functions to specific MQs. This was
observed with 34405A and AC V/I modes, where USB connections timed out
and suffered from pipe errors.

Add an optional delay after "CONF:<mode> [<range>]" SCPI requests. The
duration of the delay is per model, the use of the delay is per MQ on
that model. The 200ms delay for 34405A was found by experimentation.

Speaking about 34405A: Only the "INIT" request in temperature mode
remains as an issue, which is not covered by this commit's approach.

12 months agoscpi-dmm: use different Agilent SCPI command for range and measurment
Gerhard Sittig [Sat, 22 May 2021 08:29:37 +0000 (10:29 +0200)]
scpi-dmm: use different Agilent SCPI command for range and measurment

Don't use the "[SENS:]<mode>:RANGE..." request on Agilent protocol
speaking devices. Use "CONF:<mode> [<range>]" instead. This was tested
with all devices which reference this model.

In theory there is the question whether previously configured ranges
should be re-used when (exclusively) the MQ is switched. It's assumed
that this is not useful, instead users or their applications should
select the function first and optionally pick the range then. Re-use of
e.g. 10k resistance range when switching to capacitance might be seen as
confusing (and results in errors in the device).

Use the combination of INIT and FETCH? to get measurements. The READ?
request is more complex and might "undo" what INIT already initiated.
This improves perception of the 34405A meter's operation.

12 months agoscpi-dmm: rephrase read timeout decls, put "unit" after "ms value"
Gerhard Sittig [Sat, 22 May 2021 08:08:23 +0000 (10:08 +0200)]
scpi-dmm: rephrase read timeout decls, put "unit" after "ms value"

Rephrase the SCPI read timeouts in scpi-dmm model declarations. Shuffle
the order of product terms such that the milliseconds "unit" goes last,
and the milliseconds value goes first. Assume that "2500 * 1000 [us]"
better reflects the intention than "1000 * 2500" does.

12 months agofluke-45: drop serial port echo test, was disabled for years
Gerhard Sittig [Sat, 22 May 2021 12:12:22 +0000 (14:12 +0200)]
fluke-45: drop serial port echo test, was disabled for years

The Fluke 45 driver's ECHO_TEST broke other people's SCPI device
identification and was disabled in 2018-11. Remove the dead code which
is impossible to resurrect. Its purpose was questionable to begin with.

Should users be affected, then the echo would break the identification
phase. The check cannot be done before identification without affecting
other connected devices, cannot be done after the identification either
when that very identification systematically fails. Should a user meet
this condition then applications' logs are available to see why *IDN?
fails, assuming that users are not aware of their serial port or device
configuration. The request's reflection in the place of a response gives
a strong hint.

12 months agohp-3457a: only probe when conn= was specified, to not break SCPI devices
Gerhard Sittig [Sat, 22 May 2021 12:09:29 +0000 (14:09 +0200)]
hp-3457a: only probe when conn= was specified, to not break SCPI devices

Only scan for hp-3457a devices when the user specified which connection
to use. This avoids breaking SCPI devices by emitting non-standard
requests before reliable device identification.

12 months agoscpi-pps: don't break SCPI devices when scanning for HP-IB devices
Gerhard Sittig [Sat, 22 May 2021 11:54:52 +0000 (13:54 +0200)]
scpi-pps: don't break SCPI devices when scanning for HP-IB devices

Only scan for hpib-pps devices when a user provided conn= specification
was given. This avoids breaking SCPI devices by emitting non-standard
requests before reliable device identification.

12 months agoscpi: style nits in sr_scpi_scan(), prefer common helper
Gerhard Sittig [Sat, 22 May 2021 10:53:34 +0000 (12:53 +0200)]
scpi: style nits in sr_scpi_scan(), prefer common helper

Improve readability and simplify maintenance of the sr_scpi_scan()

Move initial assignment and subsequent update of variables in closer
proximity, don't hide assignments in declaration blocks. Use common
helper code where available. Split complex conditions into individual
terms which are easier to review and reason about. Don't mix calls and
value checks and flow control in the same statement.

12 months agosiglent-sds: move model dependent request emission to after identification
Gerhard Sittig [Sat, 22 May 2021 10:26:18 +0000 (12:26 +0200)]
siglent-sds: move model dependent request emission to after identification

Device or model or protocol variant specific commands should only be
used after the device reliably got identified. The "CHDR OFF" command
upsets other devices and needs to move after *IDN? and model checks.

12 months agohp-59306a: only match when conn= is given to avoid false probe positives
Gerhard Sittig [Sat, 22 May 2021 10:25:27 +0000 (12:25 +0200)]
hp-59306a: only match when conn= is given to avoid false probe positives

The HP 59306A device was made in 1973 and would not reliably identify
by means of SCPI queries. The previous scan() implementation would have
matched any connected SCPI device, then upset these devices by emitting
non-SCPI requests.

Tighten the scope of the hp-59306a probe, only scan for devices when a
conn= spec was provided. This avoids false positives and malfunction of
other devices, and still lets users address the problematic device. This
is similar to serial-dmm and unspecific cables and has proven to work

How to reproduce the issue:

  (while any auto enumerating SCPI device is connected)
  $ sigrok-cli --scan

12 months agomotech-lps-301: make better use of serial extract options helper
Gerhard Sittig [Sat, 22 May 2021 11:35:29 +0000 (13:35 +0200)]
motech-lps-301: make better use of serial extract options helper

Pre-assign default values before having user specified options scanned.
This avoids the necessity to post-process the result. Move the initial
assignment to where its corresponding update is to improve readability.

12 months agoserial: extend semantics of connection and comm params extraction helper
Gerhard Sittig [Sat, 22 May 2021 11:27:43 +0000 (13:27 +0200)]
serial: extend semantics of connection and comm params extraction helper

The sr_serial_extract_options() routine is a hidden gem, has existed for
almost eight years, and is exclusively used by the motech-lps-301 driver
(was also used by hameg-hmo at some point in the past). Being so useful
and doing something to terribly popular, more drivers should use it.

Extend the API to make either of the out parameters genuinely optional,
and guarantee that pre-assigned defaults will survive in the absence of
user specs. Update the Doxygen comment.

13 months agoscpi-dmm: avoid get/set range calls for some of the Agilent DMM functions
Gerhard Sittig [Fri, 21 May 2021 16:37:05 +0000 (18:37 +0200)]
scpi-dmm: avoid get/set range calls for some of the Agilent DMM functions

While queries for the range are supported for voltage, current,
resistence, capacitance, the same queries in temperature, frequency,
diode, continuity modes not only fail but even lose the USB connection
to the device. This was consistently observed with 34405A and 34465A.

Suppress get and set range requests for the known problematic modes of
the Agilent protocol speaking meters.

13 months agoscpi-dmm: add four-wire resistance to list of 34405A MQs
Gerhard Sittig [Fri, 21 May 2021 16:55:57 +0000 (18:55 +0200)]
scpi-dmm: add four-wire resistance to list of 34405A MQs

Although the 34405A does not support this function, other Agilent
protocol using meters do (currently 34465A, very probably others which
are about to get added in the future).

It's assumed that announcing the availability of that MQ for a set of
meters while only some of them support it is preferrable over exploding
numbers of copies of tables which only slightly vary among each other.

13 months agoscpi-dmm: prepare introduction of per-MQ driver flags
Gerhard Sittig [Fri, 21 May 2021 16:35:01 +0000 (18:35 +0200)]
scpi-dmm: prepare introduction of per-MQ driver flags

This mechanical edit adds a flags field and the initializer element to
make the compiler happy. Behaviour does not change. See a word diff for
improved review experience.

13 months agoscpi-dmm: add support to get/set range on Agilent protocol using meters
Gerhard Sittig [Thu, 20 May 2021 20:00:47 +0000 (22:00 +0200)]
scpi-dmm: add support to get/set range on Agilent protocol using meters

Add support to get and set the auto/manual range on Agilent protocol
speaking devices (34405A, 34465A). The range values are mere numbers
without a unit or MQ associated with them. Support to list available
ranges is prepared but not used (not needed on these meters). Common
logic could open code the lists of ranges from the model description
if desired in a future implementation.

13 months agoscpi-dmm: use INIT instead of MEAS for Agilent to start acquisition
Gerhard Sittig [Thu, 20 May 2021 22:30:51 +0000 (00:30 +0200)]
scpi-dmm: use INIT instead of MEAS for Agilent to start acquisition

Though measurement values come in, the 34405A and 34465A meters kept
beeping when acquisition is started. Stopped beeping when the MEAS
keyword was changed to INIT, which is used for other Agilent devices
using the HP protocol variant.

This change is acceptable because it was tested on all DMMs which use
the Agilent protocol (according to scpi-dmm profiles).

13 months agoscpi-dmm: Keysight 34465A is a 6.5 digit meter, bump digits count
Gerhard Sittig [Thu, 20 May 2021 21:11:56 +0000 (23:11 +0200)]
scpi-dmm: Keysight 34465A is a 6.5 digit meter, bump digits count

Increase the default digit count in the 34465A model description. Though
most measurements get the precision from the current reading, this data
is used as a fallback when the response won't provide the detail.

13 months agoscpi-dmm: move OPC availability check to after IDN device identification
Gerhard Sittig [Thu, 20 May 2021 21:08:19 +0000 (23:08 +0200)]
scpi-dmm: move OPC availability check to after IDN device identification

Assume that *IDN? requests don't involve expensive processing, and thus
don't require *OPC? before their execution. This makes scpi-dmm follow
the good tradition to only use non-standard or model dependent features
after the device was successfully identified. Which avoids confusion on
unrelated devices.

Exclusively check for *OPC? availability on Owon devices, because these
motivated the introduction of the test in the first place. This avoids
confusion on other devices where short timeouts result in errors because
the response is not retrieved although the command is supported (observed
on Agilent meters connected via USBTMC).

13 months agocontrib: add udev rule for Keysight USBTMC
Gerhard Sittig [Thu, 20 May 2021 18:53:14 +0000 (20:53 +0200)]
contrib: add udev rule for Keysight USBTMC

Add the USB identification of a Keysight 34465A digital multimeter.

13 months agosiglent-sds: prefer common glib routine to get vector's length
Gerhard Sittig [Sun, 16 May 2021 12:57:54 +0000 (14:57 +0200)]
siglent-sds: prefer common glib routine to get vector's length

Replace an open coded loop with a call to common glib code.

13 months agoscpi: readability nits in vector getters, style nit in malloc call
Gerhard Sittig [Sun, 16 May 2021 17:51:52 +0000 (19:51 +0200)]
scpi: readability nits in vector getters, style nit in malloc call

Improve readability of SCPI uint8 and float vector get routines. Move
assignment and use of variables closer together to simplify review.
Allocate the glib array based on the text split result's length. Move
data processing to the "straight" path and handle failed conversion as
an exceptional condition in an error path.

Eliminate a redundant data type reference in a malloc call.

13 months agosiglent-sds: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 12:54:48 +0000 (14:54 +0200)]
siglent-sds: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

The implemented approach is modelled after pull request 114 by
Matti Eiden, to get the leak fixes in while the PR is queued.

This addresses part of bug #1683.

Submitted-By: Matti Eiden <>
13 months agohameg-hmo: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 17:42:53 +0000 (19:42 +0200)]
hameg-hmo: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

Move an existing assigment such that the initial assignment, the memory
allocation, use of response data, and resource release are in closer
proximity, and thus are easier to reason about during maintenance.
Behaviour does not change.

This is motivated by bug #1683.

13 months agorigol-ds: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 12:48:42 +0000 (14:48 +0200)]
rigol-ds: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

The approach to release allocated memory is simlar or identical to the
corresponding parts of pull request 95, in an attempt to get the reported
leak fixes in, yet reduce the potential for conflicts where this commit
deviates from the PR. Most work was done by Ralf. Thank you!

This addresses part of bug #1683.

Submitted-By: Reported-By: Ralf <>
Tested-By: Reported-By: Ralf <>
13 months agoscpi-dmm: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 12:52:49 +0000 (14:52 +0200)]
scpi-dmm: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

This addresses part of bug #1683.

13 months agorigol-dg: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 12:45:47 +0000 (14:45 +0200)]
rigol-dg: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

Move an existing release call to an earlier location, to avoid leaking
memory when an error path is taken.

This addresses part of bug #1683.

13 months agolecroy-xstream: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 12:44:57 +0000 (14:44 +0200)]
lecroy-xstream: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

This addresses part of bug #1683.

13 months agohp-3457a: style nits in the probe routine
Gerhard Sittig [Sun, 16 May 2021 13:30:42 +0000 (15:30 +0200)]
hp-3457a: style nits in the probe routine

Unobfuscate a string comparison. Eliminate redundant data type specs
in malloc calls.

13 months agohp-3457a: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 12:43:58 +0000 (14:43 +0200)]
hp-3457a: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

This addresses part of bug #1683.

13 months agofluke-45: free memory that was allocated by SCPI get routines
Gerhard Sittig [Sun, 16 May 2021 12:40:00 +0000 (14:40 +0200)]
fluke-45: free memory that was allocated by SCPI get routines

The SCPI get routines may allocate memory for response data which
callers have to free after use.

This implementation is incomplete. The fluke-45 driver's context holds
a "global" copy of the most recently received response. While the data
is freed in the next receive call, one item remains allocated for the
driver's remaining life time. Which is considered non-critical.

Also moves an operator in a complex multi-line expression to a different
location to follow the project's style.

This addresses part of bug #1683.

13 months agoscpi: document callers' responsibility to free getters' allocated memory
Gerhard Sittig [Sun, 16 May 2021 17:47:44 +0000 (19:47 +0200)]
scpi: document callers' responsibility to free getters' allocated memory

Some of the SCPI getter routines allocate memory for response data which
callers need to free after use. Document this responsibility in more
places, and rephrase existing locations for consistency. See a word-diff
for the essence of the commit.

It's assumed that the separate paragraph in the function description is
better perceived than something that's hidden in the parameter or return
value discussion. Also reference the corresponding free routine by name
for callers' convenience (data types will differ among routines). Some
free routines can be called unconditionally, others require NULL checks
at the caller's.

Reported-By: Ralf <>
13 months agoscpi: make sure to either return valid SCPI response data or NULL
Gerhard Sittig [Sun, 16 May 2021 11:48:24 +0000 (13:48 +0200)]
scpi: make sure to either return valid SCPI response data or NULL

Assign NULL early in those SCPI get routines which return allocated
memory to their callers. So that the return value is either a valid
pointer to memory or NULL regardless of the routine's exit code. This
simplifies call sites and increases robustness.

13 months agoserial_libsp: extend diag in code path which opens serial ports
Gerhard Sittig [Sun, 9 May 2021 17:27:22 +0000 (19:27 +0200)]
serial_libsp: extend diag in code path which opens serial ports

Opening a serial port involves two libserialport calls, while only the
second call's return value gets inspected. Check the lookup before the
open, too, and provide its details in a diag message.

13 months agoserial-dmm: Add PeakTech 2025 meter support.
Rafael G. Martins [Thu, 1 Apr 2021 19:01:57 +0000 (21:01 +0200)]
serial-dmm: Add PeakTech 2025 meter support.

This meter seems to be a rebranded Victor 86D. Vendor procotol
documentation matches FS9922 RS232 protocol.

13 months agordtech-dps: Add missing devc initialisation.
Frank Stettner [Sun, 9 May 2021 16:55:08 +0000 (18:55 +0200)]
rdtech-dps: Add missing devc initialisation.

14 months agocontrib/60-libsigrok.rules: add udev rule for Microchip PICkit2
Gerhard Sittig [Thu, 28 Mar 2019 16:43:24 +0000 (17:43 +0100)]
contrib/60-libsigrok.rules: add udev rule for Microchip PICkit2

14 months agoinput/csv: trim surrounding whitespace from header line channel names
Gerhard Sittig [Mon, 6 Jan 2020 08:59:21 +0000 (09:59 +0100)]
input/csv: trim surrounding whitespace from header line channel names

When CSV import grabs channel names from the first line in the file then
the text strictly between column separators (a comma) was used. Which
resulted in channel names like " channel 1". Trim leading and trailing
space before unquote, to better fulfill most users' expectation. Users
still can quote the input data for special cases if desired.

14 months agordtech-dps: research to reduce serial comm transfer volume again
Gerhard Sittig [Sun, 25 Apr 2021 08:03:47 +0000 (10:03 +0200)]
rdtech-dps: research to reduce serial comm transfer volume again

The DPS devices default to a rather low UART communication bitrate. The
generous retrieval of more Modbus registers than strictly necessary for
the periodic acquisition of analog channel values and state tracking may
or may not be an issue.

Instrument all call sites in api.c to the device state gathering calls
such that the protocol.c side transparently can reduce the transfer
volume depending on which level of detail the caller may expect given
its current context. Under optimal circumstances this might cut the
traffic in half, which DPS devices may benefit from.

This commit adds the infrastructure to potentially reduce transfer
volume, but does not change behaviour. The "config" reasons may need
further partitioning if Modbus register access really turns out to be
a severe bottleneck. The API lends itself to that extension easily. The
approach which gets prepared in this commit needs to get runtime tested
by those who got access to the hardware.

14 months agordtech-dps: introduce support for RD6006 and other Riden RD models
Gerhard Sittig [Sun, 25 Apr 2021 07:03:22 +0000 (09:03 +0200)]
rdtech-dps: introduce support for RD6006 and other Riden RD models

The RD devices differ from DPS devices in their default communication
bitrate (115200), register content endianess (BE), and register set
layout (addresses for registers). In either case 16bit registers get
accessed by means of Modbus communication over a serial channel. The
interpretation of the registers' values mostly is the same as for DPS
devices once a register with the same meaning got identified. Device
identification includes a 32bit serial number which DPS devices appear
to not provide.

All other product features are the same, and map to identical sigrok
mechanisms. That's why re-using the rdtech-dps driver to add rdtech-rd
support is considered desirable. This implementation shares all code
"above" the raw register addressing and raw value interpretation. All
logical processing, configuration interface, state tracking and data
submission to the session feed, are shared among the different device

Declare support for the RD6006, RD6012, and RD6018 models. Their specs
were taken from the 2020.12.2 instruction manual. The driver was tested
with an RD6006 device (firmware version 1.28). Unfortunately automatic
device detection is not possible or will not be reliable, which is why
users need to specify the respective model by picking one of the two
drivers. Within a driver variant the device identification and use of
the device are automatically dealt with.

14 months agordtech-dps: layer separation between API and protocol, style nits
Gerhard Sittig [Tue, 13 Apr 2021 21:52:59 +0000 (23:52 +0200)]
rdtech-dps: layer separation between API and protocol, style nits

The existing power supply driver for Riden DPS/DPH devices unfortunately
duplicated intimate details of modbus communication and register layout
including interpretation of raw register values across several source
files. Do separate the physical transport and the register layout and
register fields interpretation layers. This brings the driver in line
with the usual api.c and protocol.c arrangement of responsibilities, and
prepares the future addition of other similar devices.

Address a few style nits while we are here. Include <config.h> in all
source files, and alpha-sort include directives. Address minor data type
nits. Reduce indentation in code paths. Propagate more error codes.
Update comments which lagged behind the code, adjust grammer (eliminate
"actual" false friends). Eliminate a few magic numbers and redundancies,
switch to the more recent endianess aware byte stream reader API where
beneficial, to eliminate redundant offset math.

Other nits seem to have gone unnoticed before: The indices of all sigrok
channels were identical (all zero). Signed print formats were used for
unsigned data.

This implementation compiles, but wasn't runtime tested due to lack of
hardware. A rough estimate of transfer volume and transport throughput
suggests that the 10ms cycle time no longer can be kept, may end up
around 25ms (40 cycles per second). This can get avoided by adding more
code to tell the configuration requests, the acquisition start, and the
measurements grabbing during acquisition apart. It's assumed though that
the 10ms glib poll interval did not translate to such fast measurement
gathering. The firmware may typically provide data at lower rates anyway.

The generic source code may look overly complicated or redundant at
first glance, but compilers' generated code will greatly get optimized.
Simplified maintenance because of reduced cognitive load is considered
more important.

14 months agohp-59306a: Initial HP 59306A driver.
Frank Stettner [Sat, 24 Apr 2021 14:44:50 +0000 (16:44 +0200)]
hp-59306a: Initial HP 59306A driver.

[ gsi: drop libgpib dependency, minor style adjustment ]

14 months agohp-59306a: Initial driver skeleton.
Frank Stettner [Sat, 24 Apr 2021 11:46:25 +0000 (13:46 +0200)]
hp-59306a: Initial driver skeleton.

14 months agoAdd device type SR_CONF_MULTIPLEXER.
Frank Stettner [Sat, 24 Apr 2021 14:43:23 +0000 (16:43 +0200)]
Add device type SR_CONF_MULTIPLEXER.

14 months agoAmend #119 to use vector instead of tuple
Soeren Apel [Sun, 28 Mar 2021 21:17:17 +0000 (23:17 +0200)]
Amend #119 to use vector instead of tuple

This way, we don't need to bump glibmm to 2.54, which we otherwise would