Changing triggers (e.g. from low to high) would sometimes cause the
acquisition to seemingly "hang" due to missing variable initializations
(in reality the device would wait for incorrect triggers and/or on
incorrect channels).
This fixes bug #1535.
Prefer the common conversion helper for little endian 16bit signed data.
The previous local implementation only worked for positive values, and
yielded incorrect results for negative temperatures.
This fixes bug #1463.
Including the `functional` header is necessary in order to use `std::function` in the definition of `LogCallbackFunction` when compiling with gcc 7.3.0.
The Ruby bindings currently don't build (at least with Ruby 2.7
and/or SWIG 4.x). Disable them as a temporary workaround until we
have a more permanent fix.
src/resource.c:414: warning: unbalanced grouping commands
conversion.c:81: warning: argument 'lo_thr' from the argument list of sr_a2l_schmitt_trigger has multiple @param documentation sections
src/analog.c:611: warning: return value 'SR_ERR_ARG' of sr_rational_div has multiple documentation sections
src/device.c:205: warning: explicit link request to 'TRUE' could not be resolved
src/device.c:205: warning: explicit link request to 'FALSE' could not be resolved
src/device.c:231: warning: explicit link request to 'TRUE' could not be resolved
src/device.c:231: warning: explicit link request to 'FALSE' could not be resolved
src/serial.c:246: warning: explicit link request to 'NULL' could not be resolved
src/strutil.c:602: warning: explicit link request to 'NULL' could not be resolved
src/device.c:94: warning: unable to resolve reference to 'sr_channel_free()' for \ref command
src/strutil.c:597: warning: unable to resolve reference to 'sr_hexdump_free()' for \ref command
src/strutil.c:622: warning: unable to resolve reference to 'sr_hexdump_new()' for \ref command
src/device.c:430: warning: The following parameters of sr_dev_inst_channel_add(struct sr_dev_inst *sdi, int index, int type, const char *name) are not documented: parameter 'sdi'
src/session.c:163: warning: The following parameters of fd_source_new(struct sr_session *session, void *key, gintptr fd, int events, int timeout_ms) are not documented: parameter 'events'
Since we've now seen lots of devices in the wild that come with the
"HCS-" prefix in the ID, it's probably safe to assume all of them
could have it.
This fixes bug #1530.
The previous implementation got stuck in an infinite loop when data
acquisition started, but the device got disconnected before the data
acquisition terminates. An implementation detail ignored communication
errors, and never saw the expected condition that was required to
continue in the sample download sequence. Unbreak that code path.
Even though the devices/websites/manuals usually say 0..30V, the
hardware actually accepts up to 31V, both via serial as well as by
simply rotating the knob on the device (and our driver already
reflects that).
The same is true for current, it's usually 0..5A as per docs, but many
(probably all) devices accept 5.1A via serial and knob.
Thus, set the max current of all devices to 5.1A (or 3.1A for 3A
devices). We're assuming they all have this property, and we've seen
this in practice on at least three different versions of the device.
On a recently acquired Korad KA3005P power supply, the ID supplied by the
device is not known by libsigrok.
$ sigrok-cli --driver=korad-kaxxxxp:conn=/dev/ttyACM0 --scan
sr: korad-kaxxxxp: Unknown model ID 'KORAD KA3005P V4.2' detected, aborting.
This fixes bug #1522.
Thanks to bitaround@gmail.com for the amperage fix.
The DMMs report as an event to which mode the user switched (by turning the
rotary switch): "*0", "*1", etc.
Most other DMMs have few modes, but the U127x DMMs have up to 11 different
modes (i.e., "*10" is a valid event).
Uwe Hermann
Jan Metzger
Christian Fruth
Peter van der Perk
Tom Matthews
v1ne
Gerhard Sittig
Elen Eisendle
Andreas Sandberg
Juan M. Bello-Rivas
Daniel Trnka
David Sastre Medina
jirjirjir
Soeren Apel
Martin Ling
Dave Buechi