Rigol DS1000Z series (ds1054z, ds1074z, ds1104z and -s models) Bugs/Wish List

[DanielS]

Bug:

When the scope saves CSV data from the "memory" (not from the screen), the increment value is not right and has to be changed manually (Rigol's BUG ?). You must edit CSV file manually and put there sampling rate^-1

See wish list item W, at the top of this thread, it's based on this, knows issue.

W is about the file name numbering and the other CSV-related issues are about save speed and the scope refusing to actually write files under some circumstances.

Inside the CSV file, the scope stores the "increment" and in the memory dumps I looked at, that increment is 25X longer than it should be to correctly represent the expected sampling period. If the increment is 10us, I have to set the increment to 400ns (2.5MSPS) when I do math on the data to get the expected result or plot.

[kwass]

Bug:

When the scope saves CSV data from the "memory" (not from the screen), the increment value is not right and has to be changed manually (Rigol's BUG ?). You must edit CSV file manually and put there sampling rate^-1

See wish list item W, at the top of this thread, it's based on this, knows issue.

W is about the file name numbering and the other CSV-related issues are about save speed and the scope refusing to actually write files under some circumstances.

Inside the CSV file, the scope stores the "increment" and in the memory dumps I looked at, that increment is 25X longer than it should be to correctly represent the expected sampling period. If the increment is 10us, I have to set the increment to 400ns (2.5MSPS) when I do math on the data to get the expected result or plot.

Got it, thanks for clarifying that.  It's on the bug list.

[Trax]

I would also wish for the ability to connect a keyboard
and i would like the function of the print button to be modifyable, a.k.a. i would like to set it to always save as CVS

I found a bug, when setting the timebase to 10 sec the left half of the screen is not updated properly, only once the next sewwp reaches the center of the screen the left side shows the current data, befoure that its stuck on the image that was shown when the recording left the screen on the right.

btw: does anyone knows how to read the “*.trc”  and “*.wfm” formats?

[alsetalokin4017]

Is this a bug? The screenshot below shows a signal input on CH1 (yellow) via 10x probe, and the AUX "Trig Out" from the back panel BNC on CH2 (blue) via BNC patchcord (1x).

I would have expected the Trig Out pulse to be synchronized with the trigger point as indicated on the CH1 trace. Instead there appears to be a delay of about 360 ns. This delay or horizontal offset is constant at about 360 ns, no matter the horizontal timebase setting.

DS1054Z with "firmware" 04.03.SP1

[ebastler]

Is this a bug? The screenshot below shows a signal input on CH1 (yellow) via 10x probe, and the AUX "Trig Out" from the back panel BNC on CH2 (blue) via BNC patchcord (1x).

I would have expected the Trig Out pulse to be synchronized with the trigger point as indicated on the CH1 trace. Instead there appears to be a delay of about 360 ns. This delay or horizontal offset is constant at about 360 ns, no matter the horizontal timebase setting.

DS1054Z with "firmware" 04.03.SP1

Well, the scope does need some time to process the signal and to confirm that it has met the trigger condition, doesn't it? And then it can't go back in time to set the trigger output signal... I don't see how the behavior could be any different from what you describe, in any digital scope. Clearly not a bug, in my view.

[kwass]

Well, the scope does need some time to process the signal and to confirm that it has met the trigger condition, doesn't it? And then it can't go back in time to set the trigger output signal... I don't see how the behavior could be any different from what you describe, in any digital scope. Clearly not a bug, in my view.

I agree that it's not a bug, there clearly has to be some delay that's a (hopefully) small fraction of the waveform update rate (max of about 40K/sec).   It would be nice to have the delay of "about 360 ns" documented but it's nice to know that it's constant.

[ebastler]

I agree that it's not a bug, there clearly has to be some delay that's a (hopefully) small fraction of the waveform update rate (max of about 40K/sec).   It would be nice to have the delay of "about 360 ns" documented but it's nice to know that it's constant.

I just played around a bit with various trigger modes. (To the extent that I could get them to trigger on the 1 kHz calibration signal -- certainly not an exhaustive test, but including e.g. pulse width, timeout and RS-232 triggering). The 360 ns delay was maintained for all trigger modes I tested. This seems to imply that the trigger condition is fully determined by the FPGA in all cases.

I had been wondering whether, for some of the more complex modes, Rigol might use the FPGA to only determine "candidates" for triggering, then resort to the CPU to check for the full trigger condition. That would most likely have meant much reduced waveform update rates for those modes; so it's good to know that this is not the case.

[jlumme]

Recently channel 4 on my DS1074Z (modified to be DS1104Z) has started acting up and measurements are all over the place.
When I try to do self-calibration on the scope, it seems to take forever (I have waited for over 30 minutes) on the ch4 calibration, short video of the "endless operation" here: https://youtu.be/eP5VfoAjbHQ

I have aborted the calibration after waiting for over 30 minutes, as I'm assuming it would never finish
The scope was on before calibration for over 30 minutes (as recommended by Rigol), and the firmware version is 00.04.00.

Should I try updating the firmware ? Can I update it with "with DS1104 modification" installed, or I should revert first somehow ? Is there anything I can do at home ? The scope was purchased in China, but Im located in Japan, and Im not sure what is the warranty situation (and the scope is over 2 years old already I think).

Thank you for any suggestions! 

[dcac]

Recently channel 4 on my DS1074Z (modified to be DS1104Z) has started acting up and measurements are all over the place.

Did you install/activate the 500uV option? as this does not seem to be supported by the HW and can cause several issues.

When I try to do self-calibration on the scope, it seems to take forever (I have waited for over 30 minutes) on the ch4 calibration, short video of the "endless operation"

Have you successfully used the self-cal. before? if this could be a HW failure or perhaps is a bug in this early FW.

[jlumme]

Hmm. Yes, I have activated all the features..
But I can't remember if I calibrated the scope after updating the FW... if ever.. hmm.

Maybe I should try reverting the 500uV option first..

[alsetalokin4017]

Normally the self-calibration procedure takes about 17-19 minutes on my scope.

The first scope sent to me by TEquipment developed a bad glitch on CH4 after a couple of days of use. I documented the problem on a couple of videos and TEquipment and Rigol were very helpful in getting me a replacement unit promptly. I haven't had any such problems with the replacement unit.

Yes, try loading up the newest firmware. No, it won't affect your installed options. Yes, get rid of the 500uV/div option if you have it installed; use code DSER in the keygen to generate a code for all options including 100MHz bw but _not_ including the 500uV/div vertical sensitivity.

Here is what I'd do in your situation.

0. Make sure the problem with CH4 is not due to a faulty probe
1. Revert the scope back to stock no-options and 50MHz bw (send

Code: [Select]

:SYSTem:OPTion:UNINSTallto the scope by your favorite method)
2. Install the most recent firmware, which will show up as 00.04.03.SP1 on the System Information screen
3. Try the Self-Cal routine again, noting how long it takes to complete
4. Test your CH4 performance again, using a known good probe

If there is no change in the CH4 performance or the Self-Cal failure to complete, then contact Rigol for tech support. You may still be in the factory warranty period.

[jlumme]

Hi,

Thanks for the suggestion. I followed it (remove options, upgrade firmware), but unfortunately the calibration still never exits the same ch4 calibration sequence (I waited 45 minutes)
I guess I need to try to contact Rigol, and see what their support thinks of the situation..

[alsetalokin4017]

Hi,

Thanks for the suggestion. I followed it (remove options, upgrade firmware), but unfortunately the calibration still never exits the same ch4 calibration sequence (I waited 45 minutes)
I guess I need to try to contact Rigol, and see what their support thinks of the situation..

That's probably your best bet at this point. Still, there is one other thing I'd try.

Reset the scope to factory defaults using the "5th left menu button" trick -- it will come up in Chinese with only CH1 active -- change the "language" back to English (unless you can read Chinese!), and without touching anything else, go to the Utility menu and try running the Self-Cal routine again.

Also, try it a couple of times. So as to not waste _too_ much time, call anything over 30 minutes a "fail" and start a new attempt.

[jeremy]

Sorry to multipost, but here is another one for your list: https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/

Basically, the RAW mode of data acquisition over USB returns garbage, rather than the waveform.

[pascal_sweden]

Is the bug list reported periodically to Rigol? How have they responded to this list in the past?
Do they know that it is a joint effort from EEVBlog users?

[kwass]

Sorry to multipost, but here is another one for your list: https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/

Basically, the RAW mode of data acquisition over USB returns garbage, rather than the waveform.

Added to the list!

[kwass]

Is the bug list reported periodically to Rigol? How have they responded to this list in the past?
Do they know that it is a joint effort from EEVBlog users?

I don't periodically point them to this list, but I will start doing that!

[Howardlong]

Did you install/activate the 500uV option? as this does not seem to be supported by the HW and can cause several issues.

What issues are those?

[dcac]

Did you install/activate the 500uV option? as this does not seem to be supported by the HW and can cause several issues.

What issues are those?

I never tried the 500uV option myself, but from what I heard it caused unstable DC offsets and didn't really work as it should.

[Howardlong]

Did you install/activate the 500uV option? as this does not seem to be supported by the HW and can cause several issues.

What issues are those?

I never tried the 500uV option myself, but from what I heard it caused unstable DC offsets and didn't really work as it should.

The offsets aren't unstable, they're just never calibrated out. To be clear, there is no evidence I'm aware of that it "causes issues" other than on the 500uV setting where it doesn't work well if at all (for example, in extreme cases, the DC offset means the trace is always off screen).

[Karel]

Sorry to multipost, but here is another one for your list: https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/

Basically, the RAW mode of data acquisition over USB returns garbage, rather than the waveform.

https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/msg724742/?topicseen#msg724742

Basically, the RAW mode of data acquisition over USB works fine if you make sure to download not more than 250000 bytes at a time. DSRemote downloads the whole deep memory waveform data (up to 24Mpts) nicely (when using it with the DS1054Z).

I do agree however, that this workaround is necessary because of a bug in the firmware.

[Howardlong]

Folks

Here's a weird one I noticed last week out in the field. I've just got back and thought I'd try it out again, both on the MSO1074Z-S and on an Agilent MSO7104B.

There seems to be an anomaly in pattern triggering on both analogue and digital channels.

The synopsis is four digital channels providing a state and one analogue channel a rising edge trigger. The Rigol seems to mis-trigger about half the time.

If I add a fifth digital channel on the same analogue triggering channel and use the digital channel to edge trigger instead of the analogue channel, it works correctly 100% of the time.

Pattern triggering seems to work with one analogue channel edge triggering and one digital channel for state, but any more makes it mis-trigger.

The pattern trigger is:

Ch1 D0=N/A
Ch2 CLK=rising
D7 WE_=0
D6 CAS_=0
D5 RAS_=1
D4 CS_=0

Agilent:


Rigol, analogue trigger channel Ch2, state on four digital channels D4-D7:


Rigol single shot, works about half the time:


Rigol single shot, mis-triggers the other 50% of the time:


Rigol, all digital pattern trigger, using D3 as rising edge CLK instead of Ch2


I have tried adjusting analogue trigger and digital threshold levels and acquisition settings. Interestingly, switching sin(x)/x interpolation seems to make a temporal difference to the trigger when it mis-fires.

I don't know whether to believe this or not but it seems to be edge triggering off both D6 rising and Ch2 rising. Some more fiddling about strongly suggests that the triggering simply isn't being set correctly, with potentially multiple edge triggers.

Using just analogue channels on their own seems OK from the limited amount of testing I just did.

So, the workaround for now is simply to make pattern sources either all digital channels or all analogue channels for pattern triggering.

Edit: Firmware is 00.04.03.SP1, board version 6.1.1.

[Karel]

Sorry to multipost, but here is another one for your list: https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/

Basically, the RAW mode of data acquisition over USB returns garbage, rather than the waveform.

https://www.eevblog.com/forum/testgear/rigol-usbtmcvisa-interface-is-really-terrible/msg724742/?topicseen#msg724742

Basically, the RAW mode of data acquisition over USB works fine if you make sure to download not more than 250000 bytes at a time. DSRemote downloads the whole deep memory waveform data (up to 24Mpts) nicely (when using it with the DS1054Z).

I do agree however, that this workaround is necessary because of a bug in the firmware.

Correction, after downloading and reading the latest version of the programming guide:

http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0386/1/-/-/-/-/DS1000Z_Programming%20Guide_EN.pdf

my conclusion is that there is no bug in the firmware related to downloading raw data. The 250000 bytes limit
is as described in the programming guide (, it wasn't before).

So far, the scope behaves like described in the programming guide (when using the latest firmware ofcourse).

[Roeland_R]

Folks

Here's a weird one I noticed last week out in the field. I've just got back and thought I'd try it out again, both on the MSO1074Z-S and on an Agilent MSO7104B.

There seems to be an anomaly in pattern triggering on both analogue and digital channels.

The synopsis is four digital channels providing a state and one analogue channel a rising edge trigger. The Rigol seems to mis-trigger about half the time.

If I add a fifth digital channel on the same analogue triggering channel and use the digital channel to edge trigger instead of the analogue channel, it works correctly 100% of the time.

Pattern triggering seems to work with one analogue channel edge triggering and one digital channel for state, but any more makes it mis-trigger.

The pattern trigger is:

Ch1 D0=N/A
Ch2 CLK=rising
D7 WE_=0
D6 CAS_=0
D5 RAS_=1
D4 CS_=0

Agilent:


Rigol, analogue trigger channel Ch2, state on four digital channels D4-D7:


Rigol single shot, works about half the time:


Rigol single shot, mis-triggers the other 50% of the time:


Rigol, all digital pattern trigger, using D3 as rising edge CLK instead of Ch2


I have tried adjusting analogue trigger and digital threshold levels and acquisition settings. Interestingly, switching sin(x)/x interpolation seems to make a temporal difference to the trigger when it mis-fires.

I don't know whether to believe this or not but it seems to be edge triggering off both D6 rising and Ch2 rising. Some more fiddling about strongly suggests that the triggering simply isn't being set correctly, with potentially multiple edge triggers.

Using just analogue channels on their own seems OK from the limited amount of testing I just did.

So, the workaround for now is simply to make pattern sources either all digital channels or all analogue channels for pattern triggering.

Edit: Firmware is 00.04.03.SP1, board version 6.1.1.

I had the same kind of problem on my ds1054z when measuring a  SPI signal I generate with an arduino assembler program. I had to set triggers on all signals, most important was chip select. Could this be your problem? I don't see a trigger set in CS in your sreenshots.

[Howardlong]

CS, RAS, CAS and WE (all active low) are on LA channels D4 thru D7 (LHLL) respectively and are level sensitive in the pattern match, and CLK is the edge trigger in the pattern. You should only have one edge trigger channel at any one time in pattern trigger mode, the rest gate the trigger, or should do. I was trying to trigger on the CLK but only during an active write enable on the CAS strobe.

As suggested, if I use an LA rather than an analogue channel for the CLK trigger, it works.