Hi Gerhard,(and Christo)...
I figured it out. I'm running Linux so I can run sigrok w/STRACE. I
found STRACE and sigrok's loglevel=5 are the same. Both produced too
much data. But I did see what looked like communication and what looked
like many communication failures. I started looking through the fluke
45 code. Noticed a compiled out "echo" detection code segment (because
it didn't work well?). Going on, I repeated the log test at level 4.
Now I could clearly see the DMM was echoing the command causing sigrok
to get confused. I can change echo from the DMM's front panel. Now
sigrok-cli is reporting values seen on the DMM. I found I had to drop
the baud rate to 1200 from 9600 to get dependable operation.
P1: -0.01 mV DC
P1: -0.01 mV DC AUTO
P1: -0.02 mV DC
P1: -0.03 mV DC AUTO
P1: -0.03 mV DC AUTO
P1: -0.03 mV DC
P1: -0.02 mV DC AUTO
P1: -0.02 mV DC
P1: -0.02 mV DC
-thanks!
On 6/2/21 11:17 AM, Gerhard Sittig wrote:
On Tue, 2021-06-01 at 07:20 -0500, stuart wrote:
Hi Christo,
Well, this is getting interesting:
./sigrok-cli --driver fluke-45:conn=/dev/ttyUSB0:serialcomm=9600/8n1 --scan
The following devices were found:
FLUKE [S/N: 6123456] with 2 channels: P1 P2
And turning on logging and setting it to 5 have pushed out and
endless stream of events. I'll look at this in more detail later,
but after failing a transaction where sigrok sent "*IDN?" closing
and re-opening the ttyUSB0 port, sigrok endlessly sends out
"FUNC1?", "AUTO?", "FUNC2" & "AUTO?". The repeats these 4 commands
endlessly.
You are assuming. Don't do that. _Show_ the output that you got,
so that others can reason about it. Or keep the information to
yourself, and consult the driver source at your site for your
amusement. The driver is small, and easy to read if you follow
the code paths starting from the api.c source file.
Here is why I think your interpretation is incorrect: If the
early scan had failed, then the acquisition had not started.
Because the identification succeeded, the acquisition gets
initiated. That's why the meter's current mode is queried. No
measurement value is taken because the meter's current function
could not get identified. That's why seeing the responses is so
important if you want to receive a helpful answer.
If the textual presentation of the SCPI communication is not
enlightening, you may have to sniff the serial traffic to get the
raw content. The driver does hard string comparisons. Control
characters or unexpected whitespace could interfere while the
issue might go unnoticed, depending on how the logging is done.
Is unusual end-of-line involved which affects the MQ detection?
Do you have other cables that you can try? Would not be the first
time that individual USB to UART adapters get in the way, while
others work fine. Is the communication 8bit clean, or is some
ASCII plus parity scheme involved? Some USB "cables" are terrible
in this respect (seen with cheap handheld meters).
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
