On Wed, 2021-06-02 at 11:12 +0200, Sylvain Pelissier wrote:
>
> Thank you for the merge. Everything works well except for the
> frequency measurement. I have the following errors:
>
> $ LD_LIBRARY_PATH=$HOME/sr/lib $HOME/sr/bin/sigrok-cli -d scpi-dmm --samples 1
> sr: scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
> sr: scpi_usbtmc: USBTMC invalid bulk in header.
> P1: 1.18959832 kHz
Yes some of the meter's functions are slow to enter their mode
(when you change the MQ), or start the first reading (when
acquisition starts). There is a lengthy discussion of that in the
recent commit messages (for this very purpose, for others to see
now, and have available during future research). And I haven't
found a reliable method of killing that issue.
Would be nice to get feedback from persons who are more familiar
with SCPI in general, and the affected Agilent gear in specific.
Can't tell whether other models which are supported by scpi-dmm
are affected, only noticed the issue during research for the
get/set range support. Soon will no longer have access to the
devices that I used.
> And with a more verbose output:
> $ LD_LIBRARY_PATH=$HOME/sr/lib $HOME/sr/bin/sigrok-cli -d scpi-dmm
> --samples 1 -l 5
> [ ... ]
Your mail client has the annoying habit of breaking the text's
readability by re-flowing what should have been a quote and
should have kept its layout.
What this log shows is exactly what I report in the commit
messages and the reason why I added these delays in the first
place:
> [ ... ]
> sr: [00:00.091329] scpi-dmm: dev_acquisition_start: Precision: '"FREQ
> +3.00000000E+00,+3.00000000E-05"'
> sr: [00:00.091439] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
> sr: [00:00.093027] scpi: Got response: '1', length 1.
> sr: [00:00.093266] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
> sr: [00:00.103415] session: bus: Received SR_DF_HEADER packet.
> cli: Received SR_DF_HEADER.
> sr: [00:00.113774] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
> sr: [00:01.113965] scpi_usbtmc: USBTMC bulk in transfer error:
> LIBUSB_ERROR_TIMEOUT.
> sr: [00:01.124265] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
> sr: [00:01.199217] scpi_usbtmc: USBTMC invalid bulk in header.
> sr: [00:01.209478] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
> sr: [00:01.305108] scpi: Got response: '1', length 1.
> sr: [00:01.305200] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
> sr: [00:01.306370] scpi: Got response: '1', length 1.
> sr: [00:01.306477] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
> sr: [00:01.308532] scpi: Got response: '"FREQ
> +3.00000000E+00,+3.00000000E-05"', length 38.
> sr: [00:01.308661] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
> sr: [00:01.309830] scpi: Got response: '1', length 1.
> sr: [00:01.309964] scpi_usbtmc: Successfully sent SCPI command: 'FETCH?'.
> sr: [00:01.311347] scpi: Got response: '+1.21169603E+03', length 15.
> sr: [00:01.311415] session: bus: Received SR_DF_ANALOG packet (1 samples).
> cli: Received SR_DF_ANALOG (1 samples).
> P1: 1.21169615 kHz
The 'INIT' request is sent, '*OPC?' is _not_ responded to, before
later '*OPC?' requests do get answered and the measurement result
becomes available. No amount of delay that I added after INIT
helped in my local setup. While every addition of delay degrades
the perception of the driver's operation. :( Not delaying at all
made me lose USB connections, not able to recover from that for
minutes. So the current mainline implementation is the best that
I could come up with.
Should other SCPI keywords get used to initiate the acquisition?
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
