Bug 1011

Looks to me like a duplicate of 679 and 933. Can you please check?

In particular, I recommend you use the vxi transport instead of tcp-raw.

It seems to be unrelated to bug report 933.

But it could be similar/related to bug report 679.

I will check if the error message with the vxi protocol is the same with the one stated in comment 1 of report 679 (https://sigrok.org/bugzilla/show_bug.cgi?id=679#c1).

The connection via vxi (and ethernet) does not seem to work at all with:

>sigrok-cli -d rigol-ds:conn=vxi/192.168.1.37/5555 --frames 1 -O analog

I also tried this:

>sigrok-cli -d rigol-ds:conn=vxi/192.168.1.37 --frames 1 -O analog

*** Bug 1137 has been marked as a duplicate of this bug. ***

I investigation this issue a bit. As I understand the problem is that devc->num_header_bytes is not zeroed when "Discarding short data block" condition is entered in src/hardware/rigol-ds/protocol.c. Thus when rigol_ds_read_header is executed second time the condition `if (devc->num_header_bytes < 2)` is false (old value is stored) and new data is not read.

I applied the following patch (see bug1011-patch-v1.diff). It solves the problem partially, but I got another error:

```
$ sigrok-cli -d rigol-ds --frames 1 -O analog

(...)

CH1: -0.02 V
CH1: 0.06 V
CH1: -0.02 V
CH1: -0.02 V
CH1: 0.06 V
CH1: 0.06 V
CH1: -0.02 V
CH1: 0.06 V
sr: rigol-ds: Error during reading data, aborting capture.
FRAME-END
g_variant_unref: assertion 'value->ref_count > 0' failed
```

Now sigrok-cli reads 489 (always the same number) values on CH1 (no matter how many channels are actually turned on) and then terminates like this. I didn't investigate any further for now since at the moment it's pretty late in my timezone.

It's worth noticing that my device has software version 00.04.04.SP3. The board version is 0.1.4. It's an "overclocked" (using online keygen) 100 Mhz capable device, so it's seen in devc->model->name as "DS1104Z".

I would appreciate very much some feedback since frankly I have little idea how the code works. Does the patch look OK at first glance, was the "Discarding short data block" condition even intended to be triggered on this particular oscilloscope (if I uncomment the `strcmp` part of the patch it "fixes" the code the same way), etc?

Created attachment 399 [details]
bug1011-patch-v1

Hey. +1 for this bug.

I tried the patch, and it still fails in the same way:

[...cut...]
CH1: 6.4 V
CH1: 4.8 V
CH1: 6.0 V
CH1: 5.2 V
CH1: 6.4 V
CH1: 6.0 V
sr: [00:08.481259] rigol-ds: 489 of 1200 block bytes read
sr: [00:08.531503] rigol-ds: Requesting read of 711 bytes
sr: [00:08.531888] rigol-ds: Error while reading block data, aborting capture.
sr: [00:08.531945] session: bus: Received SR_DF_FRAME_END packet.
cli: Received SR_DF_FRAME_END.
FRAME-END
sr: [00:08.532052] hwdriver: rigol-ds: Stopping acquisition.
sr: [00:08.532178] std: rigol-ds: Sending SR_DF_END packet.
sr: [00:08.532229] session: bus: Received SR_DF_END packet.
cli: Received SR_DF_END.
sr: [00:08.532358] usb: usb_source_finalize
sr: [00:08.532456] session: Stopped.
sr: [00:08.532524] hwdriver: Cleaning up all drivers.
sr: [00:08.532579] scpi_usbtmc: Returning local control.
sr: [00:08.533220] usb: Closed USB device 1.16.



If someone needs access to this scope, I would like to invite you to RevSpace, the hackerspace in The Hague, The Netherlands.

*** Bug 1037 has been marked as a duplicate of this bug. ***

Should be fixed in 69990295852d658346980f3aad5e52ff0271bcd9, thanks!

Or at least the situation improved somewhat there.

Please open a new bug for any remaining issues (but double-check the other open bugs for Rigol devices to avoid duplicates, please).