scpi-dmm: add short measurement delay for 34465A
authorGerhard Sittig <gerhard.sittig@gmx.net>
Sat, 22 May 2021 13:19:05 +0000 (15:19 +0200)
committerGerhard Sittig <gerhard.sittig@gmx.net>
Tue, 1 Jun 2021 06:20:59 +0000 (08:20 +0200)
commit18426d1c0e36b2b26d9dfc53eaac64b857e941c8
tree8e203d0f1e33e3f8bd5dede0a21bd3497da5e341
parente90551c3f84f9d463d1453ba2e512e109e75edde
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.
src/hardware/scpi-dmm/api.c