From: Gerhard Sittig <redacted>
Date: Sat, 22 May 2021 13:19:05 +0000 (+0200)
Subject: scpi-dmm: add short measurement delay for 34465A
X-Git-Url: https://sigrok.org/gitaction?a=commitdiff_plain;h=18426d1c0e36b2b26d9dfc53eaac64b857e941c8;p=libsigrok.git

scpi-dmm: add short measurement delay for 34465A

With Keysight 34465A the VOLT:AC and FREQ functions keep suffering from
USB timeouts and pipe errors. Add a 10ms delay between initiating the
acquisition and checking for completion before fetching the result.

The weird thing is that when successful responses are seen after
temporary failure, enlarging the delay does not make them go away.
Instead the USB errors keep moving to a different spot. Measurements do
arrive though, so this is just annyoing but not a blocker.

  sr: [00:00.134038] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.136043] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
  sr: [00:00.136119] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +3.00000000E+00,+3.00000000E-06"'
  sr: [00:00.136251] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.184211] scpi: Got response: '1', length 1.
  sr: [00:00.184481] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
  sr: [00:00.234800] session: bus: Received SR_DF_HEADER packet.
  cli: Received SR_DF_HEADER.
  sr: [00:00.245597] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.246050] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:01.256495] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.291871] scpi_usbtmc: USBTMC invalid bulk in header.
  sr: [00:01.302392] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.401959] scpi: Got response: '1', length 1.
  sr: [00:01.402135] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.403392] scpi: Got response: '1', length 1.
  sr: [00:01.403566] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:01.405769] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
  sr: [00:01.406020] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.407500] scpi: Got response: '1', length 1.
  sr: [00:01.407674] scpi_usbtmc: Successfully sent SCPI command: 'FETCH?'.
  sr: [00:01.409107] scpi: Got response: '+9.00555531E+01', length 15.

Experimentation suggests that 200ms timeouts reduce the probability of
these USB communication errors. But if functions tend to respond that
differently, are delay time specs per MQ required? The implementation of
the driver currently assumes a single delay spec.
---

diff --git a/src/hardware/scpi-dmm/api.c b/src/hardware/scpi-dmm/api.c
index 73a046ff..a823196d 100644
--- a/src/hardware/scpi-dmm/api.c
+++ b/src/hardware/scpi-dmm/api.c
@@ -261,7 +261,7 @@ SR_PRIV const struct scpi_dmm_model models[] = {
 		1, 6, cmdset_agilent, ARRAY_AND_SIZE(mqopts_agilent_34405a),
 		scpi_dmm_get_meas_agilent,
 		ARRAY_AND_SIZE(devopts_generic_range),
-		0, 0, 0, 0, FALSE,
+		0, 0, 10 * 1000, 0, FALSE,
 		scpi_dmm_get_range_text, scpi_dmm_set_range_from_text, NULL,
 	},
 	{