Bug 1011 - DS1054Z no waveform after pressing run, DS1054Z invalid data block header
Summary: DS1054Z no waveform after pressing run, DS1054Z invalid data block header
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Driver: rigol-ds (show other bugs)
Version: 0.4.0
Hardware: All Windows
: Normal major
Target Milestone: ---
Assignee: Nobody
: 1037 1137 (view as bug list)
Depends on:
Reported: 2017-08-11 11:16 CEST by nistro71
Modified: 2020-06-25 00:21 CEST (History)
5 users (show)

bug1011-patch-v1 (1.48 KB, patch)
2018-03-20 21:54 CET, Aleksander Alsekseev

Note You need to log in before you can comment on or make changes to this bug.
Description nistro71 2017-08-11 11:16:14 CEST
There is no waveform displayed when pressing run for the Rigol DS1054Z.
The DS1054Z is connected via ethernet and is detected by PulseView and sigrok-cli.

Here the error for the command line version.

>sigrok-cli -d rigol-ds:conn=tcp-raw/ --scan
The following devices were found:
rigol-ds - Rigol DS1054Z 00.04.03 with 4 channels: CH1 CH2 CH3 CH4

>sigrok-cli -d rigol-ds:conn=tcp-raw/ --frames 1 -O analog
sr: rigol-ds: Received invalid data block header 'co'.
sr: rigol-ds: Read error, aborting capture.
g_variant_unref: assertion 'value->ref_count > 0' failed

The problem could be the same for other operating systems different from Windows, due to protocol decoding problems.
Comment 1 Soeren Apel 2017-08-11 20:08:50 CEST
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.
Comment 2 nistro71 2017-08-12 01:38:49 CEST
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).
Comment 3 nistro71 2017-08-20 14:14:51 CEST
The connection via vxi (and ethernet) does not seem to work at all with:

>sigrok-cli -d rigol-ds:conn=vxi/ --frames 1 -O analog
Comment 4 nistro71 2017-08-20 14:17:11 CEST
I also tried this:

>sigrok-cli -d rigol-ds:conn=vxi/ --frames 1 -O analog
Comment 5 Uwe Hermann 2018-03-20 17:45:57 CET
*** Bug 1137 has been marked as a duplicate of this bug. ***
Comment 6 Aleksander Alsekseev 2018-03-20 21:53:40 CET
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.
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?
Comment 7 Aleksander Alsekseev 2018-03-20 21:54:33 CET
Created attachment 399 [details]
Comment 8 Peetz0r 2018-07-17 21:22:54 CEST
Hey. +1 for this bug.

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

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.
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.
Comment 9 Uwe Hermann 2020-06-25 00:14:59 CEST
*** Bug 1037 has been marked as a duplicate of this bug. ***
Comment 10 Uwe Hermann 2020-06-25 00:21:01 CEST
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).