I'd like to add support for my DS4024 and other DS4000 series oscilloscopes. So far I've noticed two issues: The vertical scaling of samples is fixed to 10 divs for 256 points in protocol.c, line 680: vdiv = devc->vdiv[ch->index] / 25.6; while the DS4024 uses 8 divs for the full range. We should probably use the :WAV:Y{INC,OR,REF} functions for proper scaling where they are available. I will look at the programming manuals of the supported series and find out which support these functions. Hopefully we can just use them for all scopes :) The other, and probably bigger, issue is yet another Rigol USBTMC quirk - scpi_usbtmc_remote() and scpi_usbtmc_local() lead to timeouts and breakage. The first time after plugging in, the output of sigrok-cli -d rigol-ds:conn=usbtmc -C 1 --scan -l 5 contains sr: [00:00.000531] usb: Opened USB device (VID:PID = 1ab1:04b1, bus.address = 1.10). sr: [00:00.000535] scpi_usbtmc: Interface 0 configuration 1. sr: [00:00.000537] scpi_usbtmc: Bulk IN EP 5 sr: [00:00.000539] scpi_usbtmc: Bulk OUT EP 6 sr: [00:00.000540] scpi_usbtmc: Interrupt EP 1 sr: [00:00.000783] scpi_usbtmc: Device capabilities: SCPI, L4, T6, SR1, RL1, DT1 sr: [00:00.000793] scpi_usbtmc: Locking out local control. sr: [00:01.000985] scpi_usbtmc: Failed to enter local lockout state: LIBUSB_ERROR_TIMEOUT. sr: [00:01.001089] scpi_usbtmc: Successfully sent SCPI command: '*IDN?'. sr: [00:01.001983] scpi: Got response: 'RIGOL TECHNOLOGIES,DS4024,DS4A200500078,00.02.03.SP1', length 52. This still recognizes the device, but is not usable (at least in PV - probably because the device gets closed?). The second time, the log looks like sr: [00:00.000531] usb: Opened USB device (VID:PID = 1ab1:04b1, bus.address = 1.10). sr: [00:00.000535] scpi_usbtmc: Interface 0 configuration 1. sr: [00:00.000537] scpi_usbtmc: Bulk IN EP 5 sr: [00:00.000539] scpi_usbtmc: Bulk OUT EP 6 sr: [00:00.000541] scpi_usbtmc: Interrupt EP 1 sr: [00:01.000947] scpi_usbtmc: Device capabilities: L4, T6, SR0, RL0, DT0 sr: [00:01.001139] scpi_usbtmc: Successfully sent SCPI command: '*IDN?'. sr: [00:02.001318] scpi_usbtmc: USBTMC bulk out transfer error: LIBUSB_ERROR_TIMEOUT. sr: [00:02.001366] rigol-ds: Couldn't get IDN response, retrying. If you remove/return early from scpi_usbtmc_remote() and scpi_usbtmc_local(), the device works fine, as far as I've tested it, and it is possible to read waveforms from it. I'm unfamiliar with the internal of sigrok, so any advice how to handle this properly would be appreciated.
Using FORMAT_RAW instead of FORMAT_IEEE488_2 prevents the issue with REN_CONTROL, so unless there's a reason not to use this that's probably the way to go.
But scanning for it will still use the commands, and thus make the device unusable until it's reconnected...
Just found the blacklist for RL1 and started using that. I'm attaching an initial patch.
Created attachment 428 [details] Initial patch to add support for the Rigol DS4000 series
Created attachment 429 [details] Improved patch for DS4k - Fixed comment in the blacklist - Get the vertical origin and use that instead of the channel offset
To read Memory data, the procedure on DS4000 scopes is :STOP :WAV:POINts <number of points you want> :WAV:RESet :WAV:BEGin the POIN part can probably be replaced or extended with the STAR/STOP commands the driver is using at the moment. RES/BEG are commen with the DS2000, but the DS1000Z does not have it, which is a bit unfortunate (protocol versions are 3 and 4, respectively). After this setup, you repeatedly call :WAV:STATUS? and :WAV:DATA? until the status is IDLE. Maybe we should start splitting rigol_ds_receive up into smaller functions - it's already over 100 lines as it is, and with the new protocol version that will probably have to be added it's not going to get prettier.
Fixed in 6b04525ba2ffe72742e5cbe25da8bc3dc65b2453, thanks!