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

[alsetalokin4017]

When you select "Large" or "ExtraLarge" fonts you have the option to turn off some measurements, so you can clean up the irrelevant ones that way. But you can only have 3 "Large" or 2 "ExtraLarge" measurements up at a time.

But I agree, when a measurement is not being used, or if it's "deleted", it should be gone altogether, not just greyed/starred out.

[ManicMaurice]

Sure! I wondered if there is anyone who actually likes the possibility to 'restore' a deleted measurement (and keeping it at the same original place). 

That would be a great option too. Maybe they could retool the left hand measurement menu. Selection of each of the items could open into a secondary menu similar to selecting the Coupling option on the Channel menu. This sub menu could include the options Item 1, Item 2, Item 3, Item 4, Item 5 & Cancel.  Each of the measurement slots along the bottom of the screen would be hard positioned. In other words, if you only had Item 1 and Item 3 populated with a measurement there would be blank spots in place of Item 2, Item 4, & Item 5. Selecting an Item that is already populated by a measurement will replace that current measurement with the new selection. Selecting Cancel would close the sub menu and leave the currently displayed measurements unchanged.

[danadak]

When scope acquisition is set to averaging mode, and looking at FFT,
make the FFT averaged as well. That should get the noise floor to stop
bouncing around several divisions and smooth out the trace.

Also when FFT displayed does not appear in Ultrascope view.

Regards, Dana.

[kwass]

When scope acquisition is set to averaging mode, and looking at FFT,
make the FFT averaged as well. That should get the noise floor to stop
bouncing around several divisions and smooth out the trace.

I've added this to the wish list.

Also when FFT displayed does not appear in Ultrascope view.

I don't want to include the Ultrascope issues in this thread, since this is just about the current firmware.

[Gabri74]

Seems strange to me that no one mentioned this before, but the bandwidth limiting option is not kept across reboot of
the DSO for any channel.
I always have to re-enable it when powering on the DSO.

[kwass]

Seems strange to me that no one mentioned this before, but the bandwidth limiting option is not kept across reboot of
the DSO for any channel.
I always have to re-enable it when powering on the DSO.

Good catch!  I've confirmed this and added it to the bug list at the top of this thread.

[oliver602]

Adjusting horizontal and vertical position and trigger etc seam dead slow compared to the 1000E. Display is very laggy. I'd like to see some optimisation here. As it is now it'd be nice if they hadn't removed the 50% button. I am wondering why no one else mentioned this, am I missing something?

[ebastler]

As it is now it'd be nice if they hadn't removed the 50% button. I am wondering why no one else mentioned this, am I missing something?

I agree. You can push the trigger level control, of course, but that acts as a "0%" button, setting the trigger level to 0V. Not sure when that function would be needed...  Just reprogramming that button to "50%" would do the trick.

[kwass]

Adjusting horizontal and vertical position and trigger etc seam dead slow compared to the 1000E. Display is very laggy. I'd like to see some optimisation here. As it is now it'd be nice if they hadn't removed the 50% button. I am wondering why no one else mentioned this, am I missing something?

I've added these to the wish list.

[alsetalokin4017]

So... apparently there is a new firmware for the DS1Z series, more recent than the 00.04.02.SP4 version from December.

http://beyondmeasure.rigoltech.com/acton/fs/blocks/showLandingPage/a/1579/p/p-0019/t/page/fm/0

In spite of the zipfile name in the link, the zipfile has inside it a folder:
DS1000ZUpdate_00.04.03.00.01
which contains the firmware update file:
DS1000ZUpdate.GEL
The new file is dated 11 March 2015 and is 3.9 MB, as compared to the earlier December version with 3.2 MB.

Has anyone applied this new firmware to their scope? Are there any differences to speak of? Have any of the issues in this Bug/Wish List been addressed or implemented?

I'm hesitant to try it myself without any further information.

[HardWareMan]

I've got this one from Rigol support:

Unpacked size is 3,76 MiB (3 945 259 bytes).

What I noticed it finally began to be stored WFM file with memory depth of 12M. Saving to 24M are still problems: 2 or more channels is ok (2 with 12M or 3/4 with 6M), but 1 channel with 24M still hangs scope at ~70% of saving progress, need power cycle to restore.

BTW, Is anyone has software for offline watching this WFM files? I've experience with DS1052E and it's 2-channel WFM perfectly fits for UltraScope. But DS1074Z-S save 4-channel WFM and I cant open it. Beside, I passed through 3 FW versions (from 00.02.xx to 00.04.03) and every FW save WFM file in own format (they significantly different).

[dcac]

DS1054Z  00.04.02.SP4

Odd behaviour when you try to save Waves after using the Recorder.

If you leave the Recorder On (stopped, but On) and try to save the currently displayed waveform the Recorder seems to restart and captures new waveforms (if trigger signal still is present) and then it seems to save the last recorded/displayed wave, although that wave seems somewhat corrupted if you load it back.

If you turn the Recorder Off and try to save the currently displayed wave you (most of the time) get "Function limited" when pressing OK in the Storage/Save/file menu.

I can't really understand why saving a 'Recorder captured' waveform would be any different from saving a '(normally) Trigger captured' waveform, at least it seems odd to have an "Recorder" function but you cannot 'save' the result ?!

Also, the HW frequency counter, when pressing Run/Stop to stop, the value show "<15 Hz",  I would probably prefer it to freeze the last running value instead (like the SW measured values) or perhaps just go blank, showing "<15 Hz" to me seems confusing.

Great news, alsetalokin4017 pointed out that with the latest FW 04.03 the HW frequency counter will freeze the last running/relevant value when going into Stop mode, so this 'bug' is fixed then.

But saving Waves when you use the recorder is still very troublesome, some improvements seems to been made though, the 'Function limited' notice is gone anyway.
But what still happens is the moment you press OK to save the selected/displayed wave in the file-menu, the recorder is restarted and new waves are collected (if trigger is still present). So you'll just loose all your recorded data, and then it seems the last wave in the new sequence is then actually saved.

So the *only* way to save a wave captured with the recorder, is to select/display the wave, turn recorder off, and then goto storage and save the wave. But at that time you cannot go back and re-enable recorder to select another wave.

[Anand]

New issue:
https://www.eevblog.com/forum/testgear/rigol-ds1054z-fft-bug%28s%29/

[wd5gnr]

This is related to B, but not exactly. The decoders apparently work on the screen only. So on decoders like RS232, once you drag past the start bit, the decoder goes crazy until you line up with another start bit for it to sync on.

This is especially annoying when you trigger on RS232 but don't have the trigger on the screen (or have the trigger in the center). It just merrily decodes assuming the first thing on the screen that looks like a start bit is a start bit.

Example:
1) From the start (text is *** Labtool...)


2) Move some off the screen:


3) Move more until synchronized:


If that's too hard, it would be ok (but not ideal) if you at least had a "move left/move right" button that moved from start bit to start bit. Like I say, related to "B" on your list, but not exactly.


In addition, when setting up an RS232 trigger having an ASCII option (keyboard) would be nice. Or even letting us cheat and open the ASCII table like exists under Decode options.

[kwass]

Anand and wd5gnr, I've incorporated your comments at the top of this thread.

[miguelvp]

This is related to B, but not exactly. The decoders apparently work on the screen only. So on decoders like RS232, once you drag past the start bit, the decoder goes crazy until you line up with another start bit for it to sync on.

This is especially annoying when you trigger on RS232 but don't have the trigger on the screen. It just merrily decodes assuming the first thing on the screen that looks like a start bit is a start bit.

...

If that's too hard, it would be ok (but not ideal) if you at least had a "move left/move right" button that moved from start bit to start bit. Like I say, related to "B" on your list, but not exactly.


In addition, when setting up an RS232 trigger having an ASCII option (keyboard) would be nice. Or even letting us cheat and open the ASCII table like exists under Decode options.

Did you try to use the deep memory with decode?

Pages 14-17:
http://www.tequipment.net/assets/1/26/DSDemoGuide_022014.pdf

Edit: press the Horizontal Scale knob in to enable Zoom.

[wd5gnr]

No, zoom doesn't do it either. It does work, but the decoder (and the event table) are only showing what's on the screen (the zoomed screen in the case of delay trigger). There is no navigation ring on the 1000. If you slide across as soon as the start bit leaves the "zone" you scramble data until you get a good start bit at the left of the screen. Nice try though.

[miguelvp]

Maybe setting your time base will help.

Edit: I find it strange that you are triggering on the undershot signal BTW (as in not properly grounded probing). Which brings one thing, you can trigger on RS232 on a specific Data value or on Start.

[electr_peter]

Rigol DS1054Z decodes only from the screen memory. Decoding from sample memory is not implemented (although there are some hints in manual and menu that it could be able to do decode from memory). This severely limits usability and explains all the effects OP are seeing (I have also experienced it on my scope), but it is what it is.
Also see this: https://www.eevblog.com/forum/testgear/ds1054z-decode-timebase-problem/

[wd5gnr]

Rigol DS1054Z decodes only from the screen memory. Decoding from sample memory is not implemented (although there are some hints in manual and menu that it could be able to do decode from memory). This severely limits usability and explains all the effects OP are seeing (I have also experienced it on my scope), but it is what it is.
Also see this: https://www.eevblog.com/forum/testgear/ds1054z-decode-timebase-problem/

Triggering on RS232 makes it worse. The trigger works, but if the trigger is center screen, it is unlikely the decoding will find a start bit on the left part of the screen, so the results will scramble.

As pointed out, this is known limitation. The manual talks about picking the source of the decode, but it is always set to trace and grayed out.

[wd5gnr]

Small bug: When connecting network and USB up you get a message to the effect: Multiple Remote I/O. Use Remote I/O to select. However, in the remote I/O menu, USB will show On, LAN and GPIB will show Off and there is no way to change it. When you plug in the USB the network is dead.

Feature: Wish there was an Auto option to make it confirm so that when I accidentally press Auto instead of Run, I don't lose my whole setup. Or how about an "Undo Auto" option that restores the scope's settings to just before you pressed Auto. Either one would work. They already have a slew of auto options, but I don't think this is one of them. Other than locking it out which is what I've done. Do note, though, once you lock it out, you can't unlock it without a USB or network connection so...

[kwass]

Small bug: When connecting network and USB up you get a message to the effect: Multiple Remote I/O. Use Remote I/O to select. However, in the remote I/O menu, USB will show On, LAN and GPIB will show Off and there is no way to change it. When you plug in the USB the network is dead.

I've added this.

Feature: Wish there was an Auto option to make it confirm so that when I accidentally press Auto instead of Run, I don't lose my whole setup. Or how about an "Undo Auto" option that restores the scope's settings to just before you pressed Auto. Either one would work. They already have a slew of auto options, but I don't think this is one of them. Other than locking it out which is what I've done. Do note, though, once you lock it out, you can't unlock it without a USB or network connection so...

I found that you can re-enable the AUTO functionally but setting the scope to start with the default options then power cycle it.

[ebastler]

[re: decoding from screen memory]

Triggering on RS232 makes it worse. The trigger works, but if the trigger is center screen, it is unlikely the decoding will find a start bit on the left part of the screen, so the results will scramble.

Well, that's easy to resolve, isn't it? Just set a negative delay, i.e. move the trigger point towards the left side of the screen, to maximize the amount of decodable signal on screen which follows the start bit.

[wd5gnr]

Not unless you calculate the amount of negative delay corresponds to an entire word. Otherwise, you get what I show in the middle picture. The left of the screen is not a start bit, so the display doesn't recover until you move it some more. If you know what the data is you expect that's not a big deal. But if you don't it is difficult because you have to keep track of which bits are start bits yourself.

[ebastler]

Not unless you calculate the amount of negative delay corresponds to an entire word. Otherwise, you get what I show in the middle picture. The left of the screen is not a start bit, so the display doesn't recover until you move it some more. If you know what the data is you expect that's not a big deal. But if you don't it is difficult because you have to keep track of which bits are start bits yourself.

Yes, of course - you have to make sure that the start bit appears on the left side of the screen. In your middle picture, you have moved the trigger point outside of the screen window, so the trace again starts with a partial, ill-defined data frame. But you don't have to calculate anything, do you? Just turn the delay time knob until the vertical "trigger" indicator is moved towards the far left of the screen, but still remains on screen. No need to know about the precise data rate or frame duration in  advance.