Here's a patch to "Ignore requests to set coupling for the Hantek 6022BE",
this clears the LIBUSB errors for me.
Also in the patch:
- There is a crash because config_list() can be called with sdi == NULL.
This can be reproduced by doing:
"sigrok-cli.exe --driver hantek-6xxx --show"
- There seems to be a very unsafe loop in config_set() when setting COUPLING;
the coupling vector is assumed to be zero terminated, but is not declared
as such.
Note: The same issue is present also for other hardware, at least for
hantek-dso/api.c. The patch is only for hantek-6xxx though.
There were issues when using non-power-of-two data sizes with e.g.
the Hantek 6022BE device. For example, on Windows the acquisition would
simply hang and never complete:
hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_ERROR received 0 bytes
The issue was reported by Erik Montnemery on the mailing list, the
original patch was posted by "mmark" here (thanks!):
http://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911729/#msg911729
The issue has been verified by me on Windows and Linux, and also that
this change does indeed fix it (tested Hantek 6022BE and Sainsmart DDS120).
Neither PulseView nor sigrok-cli hang anymore on Windows, and on Linux
the log messages suggest improvements as well:
-hantek-6xxx: data_amount 712
+hantek-6xxx: data_amount: 200 (rounded to power of 2: 512)
-hantek-6xxx: receive_transfer(): calculated samplerate == 2327ks/s
-hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_OVERFLOW received 512 bytes.
+hantek-6xxx: receive_transfer(): calculated samplerate == 1969ks/s
+hantek-6xxx: receive_transfer(): status LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED received 512 bytes.
This fixes bug #821.
Some functions in std.c were using
const char *prefix = sdi->driver->name;
but were called from input/output modules as well (which don't have
a "driver" field).
As a temporary workaround, use "unknown" as prefix in such cases until
a more permanent solution is implemented.
This fixes bug #813.
This fixes the following build issue on OSX:
Undefined symbols for architecture x86_64:
"_sr_drivers_init", referenced from:
_sr_init in backend.o
This closes bug #802.
When a meter display 105.2 kΩ, libsigrok will return 105200 Ω
but it is really valuable to know that the last 2 digits are not
significant, so encoding.digits should be set to -2.
This would allow a sigrok client to display 105200 as 105.2 k
instead of 105.200 k.
055804e89e changed the outgoing
SCPI message termination by always adding a newline. This results
in the following log output:
sr: [00:00.003102] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.005648] scpi_vxi: Successfully sent SCPI command: '*IDN?
'.
sr: [00:00.005931] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
This patch restores the previous unterminated SCPI message logging:
sr: [00:00.005462] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.007515] scpi_vxi: Successfully sent SCPI command: '*IDN?'.
sr: [00:00.007860] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
As it's located in the general logging mechanism, we deal with any
additional (and unwanted) newlines this way.
This single object also contains the sr_drivers_init function, that will
always be referenced. That ensures that the drivers object files won't
be optimized out during static linking due to the fact that they are
not referenced directly.
This addresses (parts of) bug #802.
These functions were only used in the SR_DF_ANALOG_OLD case,
whereas the SR_DF_ANALOG case already used functions and lists
from src/analog.c.
This closes bug #636.
Aurelien Jacobs
Erik Montnemery
Sebastian Zagrodzki
Mike Meyer
Benjamin Larsson
Uwe Hermann
Thomas
Soeren Apel