Most messages from the DMM parsers are not hard errors, lower to
sr_dbg() so that the sigrok-cli output doesn't get cluttered (by default)
with debug output such as:
P1: 0.001100 V DC AUTO
sr: fs9721: Sync nibble in byte 0 (0x00) is invalid.
P1: 0.001100 V DC AUTO
(using -l 4 or -l 5 will still allow the user to see such messages)
The sample buffer is a still a bit of a mystery, but this should help.
The variables in play:
triggerbar/ramsize_trigger - These two variables added together indicate
how many samples we want captured. ramsize_trigger - triggerbar
indicades how many samples must be captured. The ratio between the two
is determined by capture ratio.
memory_size - This indicates the number of samples in the circular
capture buffer. stop_address, now_address, and trigger_address are
pointers within the zeroplus that wrap based on this size.
now_address - The address that the zeroplus was about to write to when
it finished capturing, and now the address that will be read from when
reads are done from the capture buffer
stop_address - The address that the zeroplus last wrote to when it
completed capture.
trigger_address - The sample address for which the trigger occured.
status - This one is a bit tricky. Some testing has shown that if the
zeroplus has captured memory_size or less samples, the STATUS_READY bit
is set. For all captures generated with more samples than this,
STATUS_READY was cleared. However, boundary conditions are difficult to
test and values such as, memory_size + 1 have not been tested. We use
this to determine if the capture has wrapped through the sample buffer.
More testing is required, but this improves behavior in a number of
cases, specifically capturing sample amounts that are not a power of 2
of the sample buffer size. Before, random data was passed to libsigrok.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Experimentation with the windows driver has found no situation where
this is set to anything other than 1. The zerominus software also never
sets this to anything other than one. Revert the code change made in
0ab0cb942f.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
If there is no trigger, don't try to capture anything before it. There
won't be any because we trigger immediately.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
This will need some additional work when support is added for compression
modes since group D is disabled for RLE compression and C and D are
disabled for "double" compression.
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
We have to wait a bit longer than 1s for a valid DMM packet to arrive,
since for various DMMs some modes (Hz/% for example) the packets will
arrive a lot less often than in other modes. If the waiting period is
too short detection of the DMM will fail.
CC libsigrok_hw_gmc_mh_1x_2x_la-protocol.lo
protocol.c:133:32: warning: equality comparison with extraneous
parentheses
[-Wparentheses-equality]
} else if ((devc->scale1000 == 2)) {
~~~~~~~~~~~~~~~~^~~~
protocol.c:133:32: note: remove extraneous parentheses around the
comparison to
silence this warning
} else if ((devc->scale1000 == 2)) {
~ ^ ~
Here is what the datasheet says about this:
"If judge bit is 1, it means frequency mode. If judge bit is 0,
it means duty cycle mode."
But this is plain wrong. Reality proves this is the other way around.
Depending on the chip, the limit value for the buzzer is between 25 and 35 Ω,
so this code set the limit for continuity to 25 Ω to be on the safe side.
This fixes the following warning:
asix-sigma.c: In function 'receive_data':
asix-sigma.c:1064:4: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
devc->state.lastts = *(uint16_t *) buf - 1;
^
This is helpful in many cases, e.g. when trying to identify which of the
16000 system error codes from
http://msdn.microsoft.com/en-us/library/ms681381%28VS.85%29.aspx
has been encountered (which is not trivial if you only have an,
e.g. German, string message alone).
This reworks the triggerbar/trigger address logic to match the values sent
by the windows app for all models (The zerominus tool was used to reprogram
the USB device ID on a single device). Additionally, the DONT_CARE_TRIGGERBAR
register is always set by the windows app and does not seem to indicate that
these registers are "don't care"'s.
While captures using a trigger do set the STATUS_READY bit, immediate
captures do not set the STATUS_READY bit, they just clear the STATUS_BUSY
bit. This was confirmed with packet captures using the "official" driver/app.
Reading a frame over the DS1xx2 RS232 connection now sometimes works,
but most of the time stalls part way through with g_poll showing the
fd as not ready.
This patch adds a function for a common operation of all serial based drivers.
It extracts the serial options from the options linked list that is passed down
to every hardware driver.
This patch adds a function to read and parse a SCPI response which contains a
comma separated list of unsignet 8-bit integer numbers (e.g "1,0,64").
This is particularly useful if the instrument sends digital measurement data
in this format.
This patch adds a function to read and parse a SCPI response which contains a
comma-separated list of floating-point numbers (e.g. "1.0e-5,2.0e-4,3.0e-3").
This is particularly useful if the instrument sends analog measurement
data in this format.
The SCPI standard specifies the "*OPC?" command (Operation complete query) which
queries the instrument for its operative state. When all pending operations are
complete, the instrument responds with a "1".
Some manufacturers block before completing all operations and don't respond
with anything and some of them respond with a "0". This function handles both
cases uniformly.
This patch adds helper functions to read an SCPI response and parse the response
as an integer, boolean, floating-point or double-precision floating-point number.
The Standard Commands for Programmable Instruments (SCPI) defines a standard
for syntax and commands to use in controlling programmable test and measurement
devices.
SCPI documentation:
http://www.ivifoundation.org/docs/scpi-99.pdf
This patch adds helper functions for sending SCPI commands, reading a SCPI
response and reading and parsing a SCPI "*IDN?" response.
SR_CONF_PATTERN_MODE was not handled in config_list(), yielding
non-working OLS support in PulseView (due to an assert), and a missing
pattern list in sigrok-cli's --show output.
This fixes bug #184.
The scan() function was opening the port in non-blocking mode, the dev_open()
function however was not using the SERIAL_NONBLOCK flag. This led to hangs
in certain situations.
This fixes the OLS e.g. on NetBSD.
A new sp_port is created every time we call serial_open (sp_get_port_by_name
implicitly creates one for us), so free it every time we call serial_close.
Without a SR_DF_END samples could be cached in the internal buffer of an output
module and never flushed, therefore they would be missing in the final output.
By sending a SR_DF_END packet we force the output to be flushed.
Disable drivers that need serial port support if libserialport is not found.
Also, disable building various other serial port related code in that case.
The bandwith in Rigol DS1xx2D/E scopes can be upgraded to 150 MHz in software.
So detect also scopes with the upgraded bandwith.
using libsigrok-0.2.1 + this change + commit da970d24ec (required for newer kernels):
[dan@eagle sigrok]$ sigrok-cli --scan -d rigol-ds1xx2 -l 5
sr: libsigrok loglevel set to 5.
sr: Sanity-checking all drivers.
sr: Sanity-checking all input modules.
sr: Sanity-checking all output modules.
srd: libsigrokdecode loglevel set to 5.
sr: hwdriver: Initializing driver 'rigol-ds1xx2'.
sr: serial: Opening serial port '/dev/usbtmc0' (flags 1).
sr: serial: Opened serial port '/dev/usbtmc0' (fd 7).
sr: serial: Wrote 5/5 bytes (fd 7).
sr: serial: Closing serial port /dev/usbtmc0 (fd 7).
sr: rigol-ds1xx2: response: /dev/usbtmc0 [Rigol Technologies,DS1152D,DS1EU150XXXXXX,00.04.01.00.02]
sr: hwdriver: Scan of 'rigol-ds1xx2' found 1 devices.
The following devices were found:
rigol-ds1xx2 - Rigol Technologies DS1152D 00.04.01.00.02 with 18 probes: CH1 CH2 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15