Introduce quirks support for devices which provide incomplete metadata.
Add conservative logic to unbreak the Logic Shrimp. Amend previously
received information when it was incomplete, but don't interfere if a
future firmware version fixes the issue.
Without this change, the device gets detected but "has zero channels"
and would be unusable. Because when a device provides metadata, these
details are used exclusively, no fallbacks apply.
There is no reason to close the entire device in acquisition_stop and
this actually breaks pulseview on serial devices using this callback
when running multiple acquisition cycles
This fixes bug #1271.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
The Mooshimeter driver uses mem*() and str*() library calls. Include the
<string.h> header file to silence compiler warnings.
...
./src/hardware/mooshimeter-dmm/protocol.c: In function 'lookup_tree_path':
./src/hardware/mooshimeter-dmm/protocol.c:275:3: warning: implicit declaration of function 'strchr' [-Wimplicit-function-declaration]
end = strchr(path, ':');
^
./src/hardware/mooshimeter-dmm/protocol.c:275:9: warning: incompatible implicit declaration of built-in function 'strchr' [enabled by default]
end = strchr(path, ':');
^
...
Even working BLE devices won't immediately succeed in the first call to
connect(2), which is why the "in progress" phase was added. But absent
peers made the previous implementation try forever, getting stuck in the
sr_bt_connect_ble() call.
Try to balance these two constraints. Do terminate BLE connect attempts
after a generous timeout. When this 20s period passed, there probably is
a configuration error or unresponsive peer. Yet the timeout needs to be
in this ballpark to not erroneously fail for working setups.
This adds support for the Mooshim Engineering BLE based Mooshimeter.
Because the meter requires raw BLE packets, the driver uses the BLE
layer directly. Since the meter has no physical way of configuring it,
the actual configuration is set entirely with sigrok device options.
When libsigrok is compiled with link-time-optimization, the linker
stumbles over the section named the same as the function. Whether this
is a compiler/linker bug or a coding error is unknown.
Renaming the special section (to the same as already used on OS X) avoids
the problem.
This fixes bug #1416.
Doxygen version 1.8.16 introduced an issue which breaks the compilation
of sigrok's C++ binding (https://github.com/doxygen/doxygen/issues/7190).
Don't set the FILE_PATTERNS variable at all, instead of assigning an
empty value. This resolves bug #1422.
This adds basic support for the Rigol MSO5000 series. It has
the same problems as the DS4000 series: Live capture provides
one digital channel per byte. Buffered memory returns the data
compressed (one byte has 8 digital channels), but the banks are
read separately. It's not possible to read uint16.
Introduce the lcr/vc4080.c source file which implements the parser for
the serial data stream of the Voltcraft 4080 LCR meter. Add the meter to
the list of supported devices in the serial-lcr driver, as well as the
PeakTech 2165 LCR meter which is another compatible device.
This implementation contains a workaround for USB based serial cables
which seem to suffer from incomplete parity handling (observed with the
FT232R based PeakTech cable). Similar approaches were seen in existing
DMM drivers.
This implementation supports the main and secondary displays. The D and Q
"displays" which are communicated in the serial packets appear unreliable
and redundant, users can have the D and Q values shown in the supported
displays.
Commit cb5cd1538f introduced packet request support in the serial-lcr
device driver. Calls were added to the detection of the device's
presence, and the periodic acquisition of measurement data. Add another
call to the device configuration retrieval that follows the presence
detection, without it communication timed out with no data received.
Also slightly raise the timeout for this device configuration gathering
phase. With one second sharp, the VC4080 was detected, but getting its
current configuration kept failing. This device's serial communication
is extra slow (1200 bps) and the packets are rather large (39 bytes).
Which made the stream detect's receive routine stop checking for the
availability of more data while a packet was being received.
Move the initial device probe (LCR packet validity check), the creation
of the device instance after successful probe, and the subsequent packet
inspection after resource allocation out of the scan routine. This shall
improve readability of the serial-lcr driver's probe logic, and reduces
diffs when handling of multiple connections gets added later.
Add a developer comment, the serial-lcr driver needs to handle multiple
connections when the conn= spec is ambiguous (multiple cables of the
same type, with the same VID:PID).
The HID transport for serial communication was rather noisy at log
levels of 4 and above. Now that test coverage was increased and
operation is stable, drop a lot of the excessive and redundant debug
messages in regular code paths.
According to the latest available version of the manual, as
for the RTB2000 and RTM3000 series, the RTA4000 series also
uses a slightly different dialect than other previously
supported models, in particular when it comes to the POD
(logic channel groups) handling.
I do not have such model available for testing therefore, as
for the RTB2000 and RTM3000 support recently introduced, I do
not know whether or not the RTA4000 also understands the
existing dialect. In doubt, the new official dialect is
implemented by this patch.
According to the latest available version of the manual, they
both use a slightly different dialect than currently supported
models, in particular when it comes to the POD (logic channel
groups) handling.
I do not have any of the above models available for testing
therefore I do not know whether or not they also understand
the existing dialect. In doubt, the new official dialect is
implemented by this patch.
Update the oscilloscope state with new settings only after
they have been successfully stored in the device to avoid
an inconsistent state in case of SCPI SET command failure.
The hameg-hmo driver returns an incorrect sample rate: to reproduce this
bug, set the maximum sample rate from the ACQUIRE menu.
This patch fixes the driver so that the correct sample rate is returned.
During the initial configuration phase of the hameg-hmo driver
only send an OPC command if a SCPI command has been previously
sent to the device so that bogus SCPI timeouts are avoided.
The current starting index for the POD name is currently wrong as it is zero.
The official POD numbering starts instead at 1 (see device panel, buttons
and manual), so the current index used for message printing and groups
naming in the driver needs to be incremented by one.
Avoid double memory freeing leading to segmentation fault in when a SCPI
command fails to get a string due conditions such as a timeout or an invalid
command.
When setting the type of slope for the edge trigger function, also set the
trigger type to edge because it is not necessarily configured that way and
therefore such functionality might fail to work properly!
This fixes parts of bug #1328.
Update the Hameg/Rohde&Schwarz HMO driver (hameg-hmo) so that it
is possible to configure the logic threshold for digital signals.
The user can get or set the logic threshold configuration using
the channel group POD0 (and/or POD1 where available), for example:
sigrok-cli --driver hameg-hmo --get logic_threshold -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold=TTL --set -g POD0
sigrok-cli --driver hameg-hmo --get logic_threshold_custom -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold_custom=0.7 --set -g POD0
Sylvain Pelissier
Gerhard Sittig
Sylvain Munaut
Marc Schink
Uwe Hermann
Derek Hageman
Stefan Brüns
Kate J. Temkin
Jan Luebbe
Sebastian Reichel
Miklos Marton
Elen Eisendle
Guido Trentalancia