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

[kwass]

Please follow this link to the discussion thread on version 00.04.04.03.02 forward:

  https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-buglist-continued-(from-fw-00-04-04-03-02)/



Here's my attempt to catalog the bugs and wish list items for the Rigol DS1000Z oscilloscopes.   This should apply to the regular and -s versions, but may not apply to the MSO versions)  I'll try to modify this top post as people add their found bugs and wish list items.  Hopefully Rigol will see this thread and respond to it.

This list is for software version: 00.04.02 and 00.04.03  only, with the current hardware (possibly only board 0.1.1).


Rigol fixed the following bugs (according to their documentation between 4.02 and 4.03):

• Modified the method of key board test and screen test and optimized processing speed.
• The display of keyboard lights and the show of menu was wrong while switch the timebase mode between YT and ROLL in the Normal trigger mode.
• The saved data of REF waveform was wrong while STOP the system then open the channel.
• The output of AUX was wrong while the function of Pass/Fail was closed.
• The display of LA signal was wrong while adjust the delay calibration of LA signal.
• The position of LA wave and label of LA channel was wrong while load the file of LA waveform then RUN the system.
• The wave of channel1 can not be displayed while open the scan mode then switch the channel2 over and over again.
• The position of LA wave was wrong while load the file of LA waveform before change the position of the LA channel.
• The memory data of LA channel was wrong when use the remote command to read.
• Save the CSV file failed while the system stopped.
• Fixed the bug of unlocked the key board failure when save the file.

Bugs:

1) The new Large and Extra Large measurement fonts are nice, but they are reset to Normal on each power cycle.  This should be retained like all the measurement settings are.

2) The Select Item sub-menu on the Measurement menu has 5 check boxes implying that it should be useable for Normal font too, but it's grayed out.  The only way to remove a measurement from the screen using Normal font is a power off/on cycle.

One member has already suggested that the left side menu as a series of on/off toggles as the means for including/removing the measurement.  This in conjunction with the Select Item sub-menu (which could turn on/off the display position of an item) might give maximum flexibility and ease of use.

3) The FFT function only works for channel 1.  However it will work for the other channels as long as channel 1 is turned on.  It's actually more complicated than that for more details see this thread: https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478

Also, the FFT cdisplay shows bad aliasing under most circumstances.  See this thread for more details: https://www.eevblog.com/forum/testgear/rigol-ds1054z-fft-bug%28s%29/

4) The Large and Extra Large fonts cover up items that display at the bottom of the screen.  For example the brightness indicator and the math equation. 

5) Some users have reported that the zero line of the trace is not perfectly centered after doing a calibration.  This is not an issue on all units, however, so might be more of a hardware variability item.  Users expect that all traces along with their channel number indicator should perfectly centered on the display (on top of each other) after a calibration.

(See this post for some post-calibration screen shots:  https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-%28ds1054z-ds1074z-ds1104z-and-s-models%29-bugswish-list/msg584977/#msg584977)

If it's not possible for the calibration routine to automatically do this, maybe allow the user to manually set the channel offset at the exact center and save that value until the next calibration.

6) Writing full memory to a CSV file takes an extremely long time.  Write speeds seem to be about 0.15 MB/sec instead of the expected 10MB/sec or so.

7) When show measurements from the MATH trace the units don't match to the units selected (or computed) in the MATH function.  For example:  Ch 1= Volts, Ch 2=Amps, Math= Ch1 x Ch2 will show Watts on the trace but MATH measurements will show Volts, instead of correctly showing Watts.

8 ) The 20M Bandwidth Limit setting for each channel is not saved, it resets of OFF each power cycle.

9) If the following settings are used:

  Input signal: probe compensation 1kHz square wave from the scope
  Trigger: DC / CH1 / 1.5V
  Aquisition: High Res / 120k mem. depth
  Horizontal position: 0ps
  Horizontal scale: 50us/div

  The scope will display the waveform shifted by around 75us.    See details in this picture:



10) Some users have reported scope lock ups when setting memory depth to AUTO, timebase to 1us, zooming in and changing the persistence from MIN something else. Apparently not all users experience this problem but those that do can reproduce it every time.  See this thread for much more detail: https://www.eevblog.com/forum/testgear/rigol-ds1054z-freeze-up-bug/

11) Remote I/O menu will not allow selection of LAN if USB is ON.  You need to unplug the USB device first.

12) Inside the CSV file, the scope stores the "increment", in the memory dumps that increment is 25X longer than it should be to correctly represent the expected sampling period.  For example: if the increment is 10us, one has to set the time increment to 400ns (2.5MSPS) in order to get the correct plot of data.

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


Wish List Items:

A) Full screen X-Y mode, the current display is tiny.  Also, allow screen persistence to be set in X-Y mode.

B) Decoders should allow DATASRC to be either Trace or Memory.  This is documented in the manual but apparently only Trace is implemented, so this might be a bug.  Even the SCREEN option could be improved so that decoding starts at a start-bit not at the left edge of the screen.

C) When displaying a math function allow the underlying channels to be hidden.

D) Compress and move the waveform to the bottom of the screen when Measure All is on as is done, optionally, for FFT display.  Also for measurement history.

E) Allow Measure All to be selected in the AUTO options menu.

F) Allow the user to hide the left and right side menus.  Also the left side menu is often irrelevant and that screen space could be used for other display items.

G) When selecting a channel, show some corresponding channel color around the settings instead of having everything in just white.  Maybe just change the color of the tiny CH1, CH2, CH3, CH4 label next to the Coupling setting.

H) Use a larger font for the popup keyboard.

I) Save the last few file names in the Storage menu for faster access.  Maybe use the left side menu for this?  Alternatively, just remember the last file name entered and allow the user to increment any trailing digits.  So TEST0001 would go to TEST0002 automatically (or will a key press).

J) Allow the trace Display Persistence Time to be turned off -- instead of just MIN.  The scope would then just show each waveform as it's captured and blank the display before showing the next.  Even the MIN persistence level can hide some detail.

K) Allow larger fonts for certain items.  For example:  timebase, trigger level and channel gain (volts/div).  Also use a larger icon showing the coupling (DC/AC/GND) next to the channel gain.

L) Use a different color for the math trace, something that stands out better, maybe red?

M) Allow the user to select a color for the A and B cursors, individually.  Currently they are distinguished by a solid and dotted line both in white.

N) Allow for selectable FFT size (number of points: 128, 256, 512, 1024) calculation -- ie, trade off speed for accuracy.

O) Show the trigger type and coupling method (DC/AC/LFR/HFR) next to the trigger type icon in the upper right corner.

P) Consider moving the selection of the trigger coupling method to the top-level trigger menu instead of the Setting sub-menu.  Same for the Holdoff.

Q) Allow for variable high and low pass filtering for each channel, as was done in the earlier 1000 series scopes.

R) Add boxes for Math and Ref to the bottom bar alongside the channel info.  Color coding them and added relevant info such as gain or offset offset voltage.

S) Allow for a simple screen title.  Maybe allow more text to be added via a PC connection, perhaps a query that could be responded to with a key press on the scope.

T) Hardware frequency counter shows "<15Hz" when the STOP button is pressed even though it had been showing a valid value.  It would be best to freeze this value like other measurements are.

U) Ability to save a Recorded data to USB drive.

V) Consider checking the way the menu system works, as follows:

Push a soft menu button to open a menu, push the same button again to close the menu.
When a menu is open you can use the light blue up/down arrows to select an item in the menu, or use the multifunction knob if you prefer that.  When you have the correct item highlighted in the menu, push the soft menu button again to select the item and close the menu (or push the multifunction knob if you prefer).

W) Change file file numbering scheme so that instead of using the first available file number simply use a sequential number (stored in persistent memory) until reset by the user.

X) Use a meaningful amount of decimals in the horizontal position display (e.g. '0.00000000 ps' should be something like 0.0 ns since the smallest step size is 0.1ns)

Y) Have the FFT function compute an average if the channel it's set to is set to "average" in Acquire menu.  Other single-argument math functions seem to do this.

Z) Allow a push of the trigger level control to set the trigger level at the 50% level or at the 0% level - as it currently does.

AA) Improve the response of the vertical and horizontal position movements, they have quite a bit of lag.

AB) It would be helpful to be able to see the on-screen ASCII table when setting up an RS-232 trigger.

AC) Add (wired/wireless) USB keyboard support for navigating menus and character input.

AD) Add a menu option to allow the user to set the offset voltage (or whatever the current units are).  This is in addition to the normal offset control knob.

AE) Allow MATH to be used in the X-Y mode.  This means that instead of 6 options of what to display there would be 20 options (so that MATH can be either X or Y). 

[Muttley Snickers]

I dont own one as yet but these would have been nice for me:

D) Real Time Clock

E) Mouse Support



Muttley

[kwass]

D) Real Time Clock

The hardware doesn't allow for that, so I don't think we can reasonably add that to the wish list, but this would be nice to have.

E) Mouse Support

I suppose that this would be possible with the current hardware, but I don't think that Rigol offers mouse support on even their high-end scopes.  I'd like to keep the wish list limited to things that would appear to be not too hard to code -- but for all I know even items A, B and C might be hard to do depending on how they wrote their firmware.

[Lightages]

External trigger on rear panel BNC...

I don't think asking for a hardware change in a firmware will get you far. 

I think asking for some things here is interesting, but I wonder how much will result from it.

Rigol has made a really cheap scope with a bunch of features. IMHO they have failed with some things but for the price I am sure it can't be made much better. For example the FFT only on channel #1. No big deal, just use channel #1 when you need FFT!

One of the other things that bug me, the FFT is SLOOOOOWWWW. When compared to the DS1052E it simply is a snail and IMHO almost unusable. I am sure that with all the things they are trying to pull off with the single processor that it probably cannot get faster.

Another thing that is simply a mess is the measurement displays. If you "clear" them they don't go away. They still just sit there with a grey color and interfere with adding a different measurement. The only way to get rid of them and start from scratch is to clear all and reboot.

Another, make it so the right menus can be disabled and show more screen. As it is now the displayed waveform has basically no more screen than the DS1052E. Yes I know it is higher resolution.

Last one for now, make the persistence so it can be 100% disabled.

The problem with any of these requests is they might not have much room to make improvements because of memory and timing restraints in the hardware. This is what you get for a bottom feeder price with so many features.

[pickle9000]

From the poor eyesight guy.

- Keyboard 5 s S 8 all blend together, make the keyboard bigger, way bigger.
- A little color around the ch1-4 selections. I know there are other indications but you push these buttons so a slight colour change would be a good indicator that they are active. Don't change the text colour that will make it harder to read.

Annoying bits.

- When Measure All is pushed the waveform will not move to a more visible area. That's pretty standard.
- Under Auto Options can't there be an option to turn on the Measure All.?
- Under storage, save the last five items so you can either reload them or see what you did.
- Under the vertical and horizontal menu have a location to save the current "on" items. That way you could just hit one button to load your usual measurements.

[kwass]

For example the FFT only on channel #1. No big deal, just use channel #1 when you need FFT!

Agreed, it's just a small bug, not a wish list item.

Another thing that is simply a mess is the measurement displays. If you "clear" them they don't go away. They still just sit there with a grey color and interfere with adding a different measurement. The only way to get rid of them and start from scratch is to clear all and reboot.

This is fixed in the latest firmware, there's a Select Item sub-menu

Another, make it so the right menus can be disabled and show more screen. As it is now the displayed waveform has basically no more screen than the DS1052E. Yes I know it is higher resolution.

Yeah, that would be nice, I'll add that to the list.

Last one for now, make the persistence so it can be 100% disabled.

100% disabled to me would mean that you'd never see anything.  Are you looking for an analog-type display -- real time trace mode?  Is that even possible with this hardware?

[kwass]

From the poor eyesight guy.

- Keyboard 5 s S 8 all blend together, make the keyboard bigger, way bigger.
- A little color around the ch1-4 selections. I know there are other indications but you push these buttons so a slight colour change would be a good indicator that they are active. Don't change the text colour that will make it harder to read.

It would be good to have more readable fonts in some places.   I'll add these suggestions.

Annoying bits.

- When Measure All is pushed the waveform will not move to a more visible area. That's pretty standard.
- Under Auto Options can't there be an option to turn on the Measure All.?
- Under storage, save the last five items so you can either reload them or see what you did.

I agree, the measure all is pretty useless because of that -- adding to the list.....

- Under the vertical and horizontal menu have a location to save the current "on" items. That way you could just hit one button to load your usual measurements.

You can sort of do that now with the new Select Item sub-menu.  But it's not quite what you're asking for I think.

[pickle9000]

- After a cal 0v does not line up dead center on the graticule, it's not off just not dead center. Just seems weird.

[kwass]

OP did not specifically say "firmware changes for the next update", therefore I believe it is reasonable to ask for Rigol to modify the hardware in DS1000AZ or whatever their next hardware revision nomenclature may be, just as they included the 50 ohm terminator in the DS2000A series.

I was really thinking just about firmware changes, since a lot of people have these scope and would just like to have the bugs fixed and/or some nice little extras added.

It will have about as much chance of getting Rigol's consideration as any of the suggestions that may come up in this thread, unless someone like Teneyes or any of the other regular Rigol correspondents makes a deal out of it.

I disagree.  They picked up on the measurement font size discussion and added the Large and Extra Large options in the new firmware.  (They did this silently not mentioning it when they released the firmware, perhaps it's a work in progress.)  As I recall this was discussed in a one of the threads in this forum and didn't get the high profile coverage that the jitter and AC coupling problems did in the BLOG forum.

[kwass]

- After a cal 0v does not line up dead center on the graticule, it's not off just not dead center. Just seems weird.

I saw the discussion about this, but don't quite understand.  Is the trace dead center and just the channel number indicator off by a pixel or so?  That's what mine looks like after a cal.

[Lightages]

The select sub menu item does nothing to fix the ghost measurement items still hanging around until a clear all and reboot. It only has effect on selecting which items to see when using larger fonts.

[Lightages]

Oh yes, the persistence option. The display shows some amount of persistence all the time, meaning showing a blend of history with real time. Without persistence the display would show only the latest acquisition each screen refresh. The persistence as implemented hides some noise in the signal.

[pickle9000]

- After a cal 0v does not line up dead center on the graticule, it's not off just not dead center. Just seems weird.

I saw the discussion about this, but don't quite understand.  Is the trace dead center and just the channel number indicator off by a pixel or so?  That's what mine looks like after a cal.

It's only off by a pixel or two (perhaps less). Basically after a cal you would expect all traces to line up perfectly, dead center. That may change an hour later but just after a cal it should be perfect. What makes it unusual to me is that I have never seen any digital scope do it. It's one of those things that is just expected and never stated.

[kwass]

It's only off by a pixel or two (perhaps less). Basically after a cal you would expect all traces to line up perfectly, dead center. That may change an hour later but just after a cal it should be perfect. What makes it unusual to me is that I have never seen any digital scope do it. It's one of those things that is just expected and never stated.

After a cal the traces on my 1054z are perfectly centered (of course this changes over time after a cal).  The color of the trace is the last channel turned on and I see no hint of other channel "under" that.  I'm guessing that there is some slight variability in the hardware and/or temperature gradients that make this differ from scope to scope.  I put a very low speed fan in my scope so perhaps this allows for a more even temperature across the channels.

If this is the case, I don't see how firmware can correct it.

[kwass]

The select sub menu item does nothing to fix the ghost measurement items still hanging around until a clear all and reboot. It only has effect on selecting which items to see when using larger fonts.

Yes, of course!  I hope that they're planning to fix this, why are there 5 check boxes in the Select sub-menu if the large and extra large font's can only show 3 and 2 measurements.  I'm putting this in the BUG section.

[kwass]

Oh yes, the persistence option. The display shows some amount of persistence all the time, meaning showing a blend of history with real time. Without persistence the display would show only the latest acquisition each screen refresh. The persistence as implemented hides some noise in the signal.

OK.  I've got it on the wish list.

[LaurentR]

3) The FFT function only works for channel 1.  However it will work for the other channels as long as channel 1 is turned on.

The FFT issue is a tad bit more complex than that and it's definitely a bug, not a missing feature. On my scope, I originally couldn't FFT on channel 1 unless channel 2 was on 
It has to do with the "SourceA" setting for dual-operand math operators. Try this:
* Turn Math ON
* Pick a 2-operand op (e.g. A+B)
* Select Ch2 as SourceA
* Set Operation to ON
* Now change the op to FFT.
* Set Source to Ch2
* Voila, it works, even if Ch1 is Off (and now FFT on Ch1 may not work anymore )

So it seems that regardless of the "Source" setting for the FFT, if the "SourceA" setting for any 2-operand op is set to a channel that's Off, you get the DataInvalid message. I did report it to Rigol, who managed to reproduce the issue.

See this thread for some extra reference:
https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478

[avvidclif]

I asked and it was reported to Rigol as a change that the Measurement select buttons on the left side for Horizontal and Vertical measurements be set up as a toggle. IE: Push once for on and again for off. It didn't make this upgrade version.

Oh well, maybe later.

[kwass]

I asked and it was reported to Rigol as a change that the Measurement select buttons on the left side for Horizontal and Vertical measurements be set up as a toggle. IE: Push once for on and again for off. It didn't make this upgrade version.

Oh well, maybe later.

I've incorporated this into the wish list.

[kwass]

3) The FFT function only works for channel 1.  However it will work for the other channels as long as channel 1 is turned on.

See this thread for some extra reference:
https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478

Thanks for reminding me of all the details on this.  I've link to it.

[Mark_O]

Wish List Items:

...

F) Allow the left and right menus to be hidden and expand the waveform to fill the extra screen space.

A nice list of Wishes, overall.  But this one is highly unlikely to ever happen.  The 1000z is hard-coded to display 12 time divisions (600 pixels), and may even have some hardware elements locked to that.  This was done to increase the display speed.  I can't see them ever changing that. 

And I suspect if you asked them directly (and they answered), they'd say if you really want 14 divisions, buy their DS2000 instead.  Their goal was not to kill all sales of their high-end product lines, by making their lowest cost econo-scope fully feature-compatible with them.

[pickle9000]

Wish List Items:

...

F) Allow the left and right menus to be hidden and expand the waveform to fill the extra screen space.

A nice list of Wishes, overall.  But this one is highly unlikely to ever happen.  The 1000z is hard-coded to display 12 time divisions (600 pixels), and may even have some hardware elements locked to that.  This was done to increase the display speed.  I can't see them ever changing that. 

And I suspect if you asked them directly (and they answered), they'd say if you really want 14 divisions, buy their DS2000 instead.  Their goal was not to kill all sales of their high-end product lines, by making their lowest cost econo-scope fully feature-compatible with them.

Nailed that one, never happen.

[Lightages]

Yeah I don't think it will be changed. I did not know that the screen size was hard coded. How sis you determine that?

[Mark_O]

Another, make it so the right menus can be disabled and show more screen. As it is now the displayed waveform has basically no more screen than the DS1052E.  Yes I know it is higher resolution.

Yes, there is twice the rez (600 vs 300 pixels), so the equivalent of 24 divisions on the 1000E. 

But that extra horizontal space is put to good use.  The permanent controls and menus on the side bars eliminate one of my biggest gripes about the 1000E (and D, and C, and CD) series.  Having the menus pop up and down constantly.  To me, that was just a PITA, and I think Rigol made the right choice there.  We somehow managed to get by with 10 divisions for decades, the 1000Z has 12, and some are unhappy it doesn't have 14 (as the DS2000 does).  Why stop there?  Why not 16, 18, or 20?

[kwass]

Yeah I don't think it will be changed. I did not know that the screen size was hard coded. How sis you determine that?

I'm going to scratch this off the list.  I think that Rigol should see a list of feasible changes not a lot of pie in the sky items.

[fonak]

Here's my attempt to catalog the bugs and wish list items for the Rigol DS1000Z oscilloscopes.   This should apply to the regular and -s versions, but may not apply to the MSO versions)  I'll try to modify this top post as people add their found bugs and wish list items.  Hopefully Rigol will see this thread and respond to it.

This list is for software version: 00.04.02.SP4 only.

I'll get this started by posting a few that I've come across (some of which appear elsewhere in this forum).

Bugs:

1) The new Large and Extra Large measurement fonts are nice, but they are reset to Normal on each power cycle.  This should be retained like all the measurement settings are.

2) The Select Item sub-menu on the Measurement menu has 5 check boxes implying that it should be useable for Normal font too, but it's grayed out.  The only way to remove a measurement from the screen using Normal font is a power off/on cycle.

One member has already suggested that the left side menu as a series of on/off toggles as the means for including/removing the measurement.  This in conjunction with the Select Item sub-menu (which could turn on/off the display position of an item) might give maximum flexibility and ease of use.

3) The FFT function only works for channel 1.  However it will work for the other channels as long as channel 1 is turned on.  It's actually more complicated than that for more detaisl see this thread: https://www.eevblog.com/forum/testgear/another-rigol-1000z-bug/msg568478/#msg568478


Wish List Items:

A) Full screen X-Y mode, the current display is tiny.

B) Decoders should allow DATASRC to be either Trace or Memory.  This is documented in the manual but apparently only Trace is implemented, so this might be a bug.

C) When displaying a math function allow the underlying channels to be hidden.

D) Compress and move the waveform to the bottom of the screen when Measure All is on.

E) Allow Measure All to be selected in the AUTO options menu.

F) Allow the left and right menus to be hidden and expand the waveform to fill the extra screen space.

G) When selecting a channel, show some corresponding channel color around the settings instead of having everything in just white.  Maybe just change the color of the tiny CH1, CH2, CH3, CH4 label next to the Coupling setting.

H) Use a larger font for the popup keyboard.

I) Save the last few file names in the Storage menu for faster access.  Maybe use the left side menu for this?

J) Allow the trace Display Persistence Time to be turned off -- instead of just MIN.  The scope would then just show each waveform as it's captured and blank the display before showing the next.  Even the MIN persistence level can hide some detail.


-Katie

Hi

Below is my list of Bugs and wishes.

Bugs:

4) Brightness slider is covered when the 3 measurements are visible in Large Font Size mode. There is plenty of space for this and other indicators (e.g. HW counter) in the lower right corner of the screen (right side of the channel selector bars)

5) Offset between channels 1 and 2 when they are both on low range (1mV). SelfCal does not fix this.

6) MATH Chanel information (e.g. MATH (CH1+CH2)     1.000V ) in lower left corner of the screen is covered when the 3 measurements are visible in Large Font Size mode.


Wish List Items:

K) Different color for MATH trace (maybe green or red). The color MATH trace is very similar to the color CH4 line.

L) Selectable FFT size for example: 128, 256, 512, 1024 points (accuracy vs speed).

M) Selectable digital Low and High pass filter for measurment channels like in the DS1052E.

N) Automatic measurements end cursor for FFT (e.g frequency and amplitude of the first harmonic and other usefull measurements ).

O) No information on the main screen about Edge trigger couplink mode (i.e. small icon or text DC, AC, LFR, HFR  next to speaker ikon in the lower right corner).

P) To small coupling icon on the channel selector bars.

R) Channel selector bar for MATH and REF.

S) Button for Trigger Coupling should be in the Trig main menu ( lowest tab), not in the settings tab.

T) A little bigger and bold font for Time Base (maybe another color - red) and Trigger Level on the upper bar.

U) Cursors A and B with a different color or shade. Faster and smoother cursor update are also welcome.

W) Selectable items for History Graph ( selection menu like in large font mode for automatic measurments).

Y)  Compress and move the waveform to the bottom of the screen when DispHistory is on. Selectable time base for History Graph are also welcome (e.g 1, 2, 5 ,10, 20, 50, 100 ms /s /min/h ).

Sorry for my poor English

regards

[DanielS]

Another vote from me for the ability to turn menus off.

Even if menus off might not be able to allow for more waveform space if limited by FPGA resources, it would still be nice if measurements and other useful data could take this space once measurements are setup instead of menus which no longer serve any purpose.

[kwass]

4) Brightness slider is covered when the 3 measurements are visible in Large Font Size mode. There is plenty of space for this and other indicators (e.g. HW counter) in the lower right corner of the screen (right side of the channel selector bars)

Good catch, I'll add it to the list.  I think that the larger font sizes are still a work in progress which is why they didn't even mention this in the last firmware release.

5) Offset between channels 1 and 2 when they are both on low range (1mV). SelfCal does not fix this.

As noted earlier my scope (for one) doens't have this issue so I think it's hardware/temperature related and possibly not fixable.  But I'll put it on the list just the same.

6) MATH Chanel information (e.g. MATH (CH1+CH2)     1.000V ) in lower left corner of the screen is covered when the 3 measurements are visible in Large Font Size mode.

I'll note that too.

Wish List Items:

K) Different color for MATH trace (maybe green or red). The color MATH trace is very similar to the color CH4 line.

L) Selectable FFT size for example: 128, 256, 512, 1024 points (accuracy vs speed).

M) Selectable digital Low and High pass filter for measurement channels like in the DS1052E.

N) Automatic measurements end cursor for FFT (e.g frequency and amplitude of the first harmonic and other useful measurements ).

O) No information on the main screen about Edge trigger couplink mode (i.e. small icon or text DC, AC, LFR, HFR  next to speaker ikon in the lower right corner).

P) Too small coupling icon on the channel selector bars.

R) Channel selector bar for MATH and REF.

S) Button for Trigger Coupling should be in the Trig main menu ( lowest tab), not in the settings tab.

T) A little bigger and bold font for Time Base (maybe another color - red) and Trigger Level on the upper bar.

U) Cursors A and B with a different color or shade. Faster and smoother cursor update are also welcome.

W) Selectable items for History Graph ( selection menu like in large font mode for automatic measurements).

Y)  Compress and move the waveform to the bottom of the screen when DispHistory is on. Selectable time base for History Graph are also welcome (e.g 1, 2, 5 ,10, 20, 50, 100 ms /s /min/h ).

R) Channel selector bar for MATH and REF.

Could you please explain this further?

I'll work on adding these in, but some seem excessive to me, like automatic measurement on the FFT display.  This isn't a spectrum analyzer!

[kwass]

Another vote from me for the availability to turn menus off.

Even if menus off might not be able to allow for more waveform space if limited by FPGA resources, it would still be nice if measurements and other useful data could take this space once measurements are setup instead of menus which no longer serve any purpose.

I've noted this, thanks.

[mamalala]

5) Offset between channels 1 and 2 when they are both on low range (1mV). SelfCal does not fix this.

As noted earlier my scope (for one) doens't have this issue so I think it's hardware/temperature related and possibly not fixable.  But I'll put it on the list just the same.

I have the same/similar issue on my DS1054Z. After a self-cal, no matter how long the unit was on before, there is always a slight positive offset on all channels. There is little, if any, offset between channels when only one is active (ETA: but see below). I made a few (lousy) photos of the offset stuff here: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg580489/#msg580489

Another "offset" issue that seems rather strange. Depending on what combinations of channels are on at the same time, the traces are either perfectly overlapping, or having a small offset between them that is otherwise not present when looking at only a single channel at a time and comparing those.

In any case, i also think that after an auto-cal the traces should be centered around the center line, with no offset in either direction. Same goes for the channel marker on the left side of the grid. The marker seems to be pointing at the bottom of the trace, not the center.

Greetings,

Chris

[kwass]

In any case, i also think that after an auto-cal the traces should be centered around the center line, with no offset in either direction. Same goes for the channel marker on the left side of the grid. The marker seems to be pointing at the bottom of the trace, not the center.

I've noted this too.

[mamalala]

Just wanted to add:

In case the offset problem is due to some component variations in the scopes that the auto-cal routine can't catch, it would be great if there would be a way to manually set the offset calibration. I.e. the channel marker is pointing exactly at the center line, and one uses one of the knobs to adjust the offset of the trace while the marker stays in place, and then that offset can be stored as cal-value, if needed for each V/div separately. And that for all four channels, of course.

Greetings,

Chris

[kwass]

Just wanted to add:

In case the offset problem is due to some component variations in the scopes that the auto-cal routine can't catch, it would be great if there would be a way to manually set the offset calibration. I.e. the channel marker is pointing exactly at the center line, and one uses one of the knobs to adjust the offset of the trace while the marker stays in place, and then that offset can be stored as cal-value, if needed for each V/div separately. And that for all four channels, of course.

Good idea!

[electr_peter]

Wish List Items:
A) Full screen X-Y mode, the current display is tiny.

• Increase X-Y display to full screen in square format;
• add option to hide original source channels;
• add persistence selection specifically for X-Y display (with zero persistence, some levels of persistence, infinite persistence with persistence reset button (so scaling and moving X, Y channels would not reset persistence, reset only via button)).

B) Decoders should allow DATASRC to be either Trace or Memory.  This is documented in the manual but apparently only Trace is implemented, so this might be a bug.
C) When displaying a math function allow the underlying channels to be hidden.
D) Compress and move the waveform to the bottom of the screen when Measure All is on as is done, optionally, for FFT display.  Also for measurement history.

[fonak]

4) Brightness slider is covered when the 3 measurements are visible in Large Font Size mode. There is plenty of space for this and other indicators (e.g. HW counter) in the lower right corner of the screen (right side of the channel selector bars)

Good catch, I'll add it to the list.  I think that the larger font sizes are still a work in progress which is why they didn't even mention this in the last firmware release.

5) Offset between channels 1 and 2 when they are both on low range (1mV). SelfCal does not fix this.

As noted earlier my scope (for one) doens't have this issue so I think it's hardware/temperature related and possibly not fixable.  But I'll put it on the list just the same.

6) MATH Chanel information (e.g. MATH (CH1+CH2)     1.000V ) in lower left corner of the screen is covered when the 3 measurements are visible in Large Font Size mode.

I'll note that too.

Wish List Items:

K) Different color for MATH trace (maybe green or red). The color MATH trace is very similar to the color CH4 line.

L) Selectable FFT size for example: 128, 256, 512, 1024 points (accuracy vs speed).

M) Selectable digital Low and High pass filter for measurement channels like in the DS1052E.

N) Automatic measurements end cursor for FFT (e.g frequency and amplitude of the first harmonic and other useful measurements ).

O) No information on the main screen about Edge trigger couplink mode (i.e. small icon or text DC, AC, LFR, HFR  next to speaker ikon in the lower right corner).

P) Too small coupling icon on the channel selector bars.

R) Channel selector bar for MATH and REF.

S) Button for Trigger Coupling should be in the Trig main menu ( lowest tab), not in the settings tab.

T) A little bigger and bold font for Time Base (maybe another color - red) and Trigger Level on the upper bar.

U) Cursors A and B with a different color or shade. Faster and smoother cursor update are also welcome.

W) Selectable items for History Graph ( selection menu like in large font mode for automatic measurements).

Y)  Compress and move the waveform to the bottom of the screen when DispHistory is on. Selectable time base for History Graph are also welcome (e.g 1, 2, 5 ,10, 20, 50, 100 ms /s /min/h ).

R) Channel selector bar for MATH and REF.

Could you please explain this further?

I'll work on adding these in, but some seem excessive to me, like automatic measurement on the FFT display.  This isn't a spectrum analyzer!

R) Channel selector bar for MATH and REF.

1 image is equal to 1000 words (see atachment)

[pickle9000]

- Would be very useful to be able to put a user / project name on the display so when an image of the display is saved you have a reference for documentation.
- Be able to display a message from software on a PC. Ideally it would also have a Yes / No / Close button attached. I have a background in production testing and was often asked "Why can't I have a message on the scope screen to let me know?".

[fonak]

Just wanted to add:

In case the offset problem is due to some component variations in the scopes that the auto-cal routine can't catch, it would be great if there would be a way to manually set the offset calibration. I.e. the channel marker is pointing exactly at the center line, and one uses one of the knobs to adjust the offset of the trace while the marker stays in place, and then that offset can be stored as cal-value, if needed for each V/div separately. And that for all four channels, of course.

Greetings,

Chris

In atachments there are screens of my self-calibrated scope ( 1mV/Div range, all imputs are disconnected, FW, 00.04.02.SP4 ).
 
Thanks mamalala for this idea

[kwass]

1 image is equal to 1000 words (see atachment)

Got it!  Thanks for the nice picture!

[DanielS]

In case the offset problem is due to some component variations in the scopes that the auto-cal routine can't catch, it would be great if there would be a way to manually set the offset calibration. I.e. the channel marker is pointing exactly at the center line, and one uses one of the knobs to adjust the offset of the trace while the marker stays in place, and then that offset can be stored as cal-value, if needed for each V/div separately. And that for all four channels, of course.

Much simpler than that: I suspect the offset comes from the analog ground switch. Simply have a manually-initiated offset auto-cal where the user must either disconnect all channels (the inputs still get pulled to ground by the input attenuator) or put terminators on inputs for lower noise. After that, the scope can use those values to compensate its analog-switched ground until the next user-initiated calibration.

[mamalala]

In case the offset problem is due to some component variations in the scopes that the auto-cal routine can't catch, it would be great if there would be a way to manually set the offset calibration. I.e. the channel marker is pointing exactly at the center line, and one uses one of the knobs to adjust the offset of the trace while the marker stays in place, and then that offset can be stored as cal-value, if needed for each V/div separately. And that for all four channels, of course.

Much simpler than that: I suspect the offset comes from the analog ground switch. Simply have a manually-initiated offset auto-cal where the user must either disconnect all channels (the inputs still get pulled to ground by the input attenuator) or put terminators on inputs for lower noise. After that, the scope can use those values to compensate its analog-switched ground until the next user-initiated calibration.

That's the thing, i'm not certain that this is an issue with the  signal itself or if the issue is with their cal routine. At least on my unit it just looks as if they simply set the 0-point at the lowest value they see in the signal. Only in the 10 mV range the trace/signal on the screen even goes below the center line as well. In all other ranges it literally sits right on top of it. But then, looks can be deceiving, so...

Greetings,

Chris

[kwass]

- Would be very useful to be able to put a user / project name on the display so when an image of the display is saved you have a reference for documentation.
- Be able to display a message from software on a PC. Ideally it would also have a Yes / No / Close button attached. I have a background in production testing and was often asked "Why can't I have a message on the scope screen to let me know?".

I've added these.

[kwass]

That's the thing, i'm not certain that this is an issue with the  signal itself or if the issue is with their cal routine. At least on my unit it just looks as if they simply set the 0-point at the lowest value they see in the signal. Only in the 10 mV range the trace/signal on the screen even goes below the center line as well. In all other ranges it literally sits right on top of it. But then, looks can be deceiving, so...

For the record, I have no complaints about the zeroing after a cal.  Here are 4 screen shots taken 24 hours after calibration, showing all 4 channels at 1mv/div (note the probe is set to x10) and ground coupled (no probes attached).

[pickle9000]

That's the thing, i'm not certain that this is an issue with the  signal itself or if the issue is with their cal routine. At least on my unit it just looks as if they simply set the 0-point at the lowest value they see in the signal. Only in the 10 mV range the trace/signal on the screen even goes below the center line as well. In all other ranges it literally sits right on top of it. But then, looks can be deceiving, so...

For the record, I have no complaints about the zeroing after a cal.  Here are 4 screen shots taken 24 hours after calibration, showing all 4 channels at 1mv/div (note the probe is set to x10) and ground coupled (no probes attached).

Channel 4 is the only one that looks close to normal on yours.

I don't have a major issue with this, I have other gear. That said will voltage measurements match between channels? My guess would be no not exactly.  Could be out by a couple mV.

[Kohanbash]

I asked and it was reported to Rigol as a change that the Measurement select buttons on the left side for Horizontal and Vertical measurements be set up as a toggle. IE: Push once for on and again for off. It didn't make this upgrade version.

Oh well, maybe later.

I've incorporated this into the wish list.

+1

I have been using the DS1074z-s for a while and not having this feature has been most my regular annoyance with this scope.

[mamalala]

For the record, I have no complaints about the zeroing after a cal.  Here are 4 screen shots taken 24 hours after calibration, showing all 4 channels at 1mv/div (note the probe is set to x10) and ground coupled (no probes attached).

Yea, your traces are all offset into the positive direction as well

Greetings,

Chris

ETA: Attached is an edited version of the first of your screenshots, that's how i think it should look like instead.

ETA2: Also, note how it mangles the rendering of the waveforms, depending on which is "in front" (i.e. selected). The one from channel two is rather thin and above the center line, while the one from channel four is thicker and goes below the center line. Yet you can barely see anything from channel four in the second screenshot, where channel two is selected. One would expect to see way more of the blue channel four below it.

[poida_pie]

B) Decoders should allow DATASRC to be either Trace or Memory.  This is documented in the manual but apparently only Trace is implemented, so this might be a bug.

-Katie

Yes, impliment decoding from memory. This is most useful.

[c4757p]

Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...

[pickle9000]

Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...

The offset is there immediately after a cal.

[DanielS]

Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...

I think most people who point at the 1000Z's offset calibration are remarking about how calibration actually fails to actually make channels line up with their reference markers. Most of us would expect the references to line up with the averaged noise line, exactly like kwass' ch4 picture. All of his other channels are off by a few mV.

Adjusting the analog input bias until the ADC's average output reads 0 or mid-scale is easy, which is why we are surprised that Rigol's firmware appears to be failing at it.

I wish I could investigate a bit from my end but I have not received my 1054Z yet. Allied finally has some in stock but my account manager appears to be MIA so I am unable to complete the order. (Or maybe he is giving me the silent treatment for demanding either a pre-updated scope or an explicit authorization to upgrade the firmware with Allied's blessing.)

[tautech]

Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...

Does a push of the V/div button set each to 0 V as in most other DSO's?
Does this zero them exactly?

[mamalala]

Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...

Thing is that these offset are there always. And it get's _really_ funny depending on what channels you have turned on and in what sequence. Even worse, the offset and amplitude will change for  the same channel depending on what channels were on before and then turned off. Attached are some photos i made (yea, i still have not hooked it up to the computer, sorry). The images where taken after tthe unit was on for about half an hour.

1: Only channel 3 active

2: Again only Ch. 3 active, but after randomly turning on/off the other channels
Note that this is not due to warmup of the scope. After randomly turning on/off channels again it will sometimes fall back to what is in the first image, sometimes to what is in this image, sometimes something else

3: Ch. 3 and 1 on, Ch. 1 being selected. Note how Ch. 3's trace dropped down a bit

4: Ch. 3 and 4 on, Ch. 3 selected. Now Ch. 3 is even further down

5: Ch. 3 and 2 on. Ch. 2 selected. Ch. 3 is now a tad further down even.

6: Only Ch. 2 on. Note the amplitude and offset while it is set to 100V/div (10x probe setting)
Of course after fiddling with other channels it sometimes becomed a thinner trace.

No probes were connected to any channel. All i did was randomly selecting channels, turning them on/off, switching through the V/div settings randomly. Especially the last image shows a real problem: Am i to expect that i have about 20V p-p noise there, with a +10V offset, although nothing at all is connected?

They have a real problem with that offset/cal stuff there. And again, it's not static either, a single channel massively varies depending on what other channels where on/off/selected/etc. previously.

That just ain't right.

Greetings,

Chris

[pickle9000]

Those offset calibration shots at 24 hours are not bad at all considering the input frontend is discrete. You can hardly complain about what looks like maybe half or three-quarters of a millivolt...

Does a push of the V/div button set each to 0 V as in most other DSO's?
Does this zero them exactly?

You can push the Position knob to move the trace to the center graticule. It does not solve the problem because it is using the cal as a zero reference an it is off by a bit. Basically the cal is the issue.

[mamalala]

You can push the Position knob to move the trace to the center graticule. It does not solve the problem because it is using the cal as a zero reference an it is off by a bit. Basically the cal is the issue.

As it seems it's not only the  cal, it seems to get confused what cal values to use for a given channel when using or having used other channels.

Greetings,

Chris

[pickle9000]

You can push the Position knob to move the trace to the center graticule. It does not solve the problem because it is using the cal as a zero reference an it is off by a bit. Basically the cal is the issue.

As it seems it's not only the  cal, it seems to get confused what cal values to use for a given channel when using or having used other channels.

Greetings,

Chris

I haven't noticed that but will keep an eye on it, I may have missed it. The position of the zero marker does change when a cal is done. Even if it comes out wrong, you'd expect it to be the same wrong every time. I've run the cal about 12 times on a well warmed up unit and the variations seem random.

[Michal_S]

I would qualify extremely slow CSV export of full memory as a bug. It takes around half an hour! It's not that complex operation to take so long. It should be up to a few times longer than storing to WFM file to account for additional processing, not more.

[Mark_O]

- Be able to display a message from software on a PC. Ideally it would also have a Yes / No / Close button attached. I have a background in production testing and was often asked "Why can't I have a message on the scope screen to let me know?".

I've added these.

Seriously?     I have no doubt this would be useful for pickle, and probably others as well.  But you're talking about something that no other scope I am aware of has ever had.  And you're thinking that asking Rigol for this will have some benefit? 

IMO, there's no point muddying the waters with things that have basically 0 chance of ever being considered.  I mean, there are 'wishes', and there are 'blue sky fantasies'.  And I can tell you an 'ancient Chinese secret' that the longer your laundry list is, the greater the chance that the whole thing will get thrown away, and never looked at.

[DanielS]

Hmm, two different people posted offset calibration images and on both of them, only ch4 is zeroed out correctly. Coincidence?

[baljemmett]

Seriously?     I have no doubt this would be useful for pickle, and probably others as well.  But you're talking about something that no other scope I am aware of has ever had.  And you're thinking that asking Rigol for this will have some benefit? 

Most, if not all, HP/Agilent/Keysight DSOs seem to support displaying a message to the user via the :SYST:DSP command (it's listed in the programming manuals for the 54100A and DSOX2000 and also works on my old 1650B logic analyser); not sure how common this is with other manufacturers, as it isn't one of the commands required by SCPI as far as I can tell.  Some pre-SCPI HP gear also supports similar functionality, so it could just be something HP like to throw in.  Don't think I've seen a version with support for response buttons, though...

Although that doesn't take away from your point that the more you ask for, the less likely you are to see even the big things taken care of!

[c4757p]

Some pre-SCPI HP gear also supports similar functionality, so it could just be something HP like to throw in.  Don't think I've seen a version with support for response buttons, though...

Yeah, I know for a fact the 3468A multimeter can do this. You can get a response too:

Code: [Select]

send ("D2HELLO WORLD\r\n");
send ("D2SOME QUESTION\r\n");
send ("D2ANSWR:PRES SRQ\r\n");
send ("D2IN 5 SECONDS\r\n");
pause (5);
if (had_srq ()) ...
send ("D1\r\n");

 

I suppose you'd have to insert some delay between the lines, or perhaps "press SRQ to scroll"

[kwass]

Channel 4 is the only one that looks close to normal on yours.

I don't have a major issue with this, I have other gear. That said will voltage measurements match between channels? My guess would be no not exactly.  Could be out by a couple mV.

I'm baffled.  In all four screen shots -- from my scope -- all four channels are ON, I took these shots by simply highlighting each channel in turn and hitting PRINT.  So if channel 4 looks OK to you it's directly on top of 1,2,3 and hiding those traces. It looks like the firmware turns off the markers if they peak out from underneath another marker by less than a few pixels.

However, I do see what you all are referring too as far as the offset of the channel markers.  That looks to only be off by about 1 pixel, maybe 2.  That's close enough for me on something with a vertical gain accuracy specified as +/- 4% (below 10mv, +/- 3% otherwise) and an offset accuracy of 1% (which translates to 4.8 pixels).  I'd say it more than meets its spec -- on my scope -- other units might not meet the spec, which is why I noted this in the BUGs section at the top of this thread.

[DanielS]

I'd say it more than meets its spec -- on my scope -- other units might not meet the spec, which is why I noted this in the BUGs section at the top of this thread.

I would say it is not so much an issue of "meeting the spec" as it is an issue of there being no excuses for it to exist in the first place: compute the average (DC) value of no-input noise and subtract it from future ADC input or adjust the analog bias to reduce the ADC input offset and then apply the remainder of the bias error digitally. The visible offset error should be less than 1LSB.

[JDubU]

I haven't noticed that but will keep an eye on it, I may have missed it. The position of the zero marker does change when a cal is done. Even if it comes out wrong, you'd expect it to be the same wrong every time. I've run the cal about 12 times on a well warmed up unit and the variations seem random.

I have a DS2072 that initially did the same thing.
Now I've found that I get the best and most consistent calibration result by running the self cal in an electrically quiet environment (away from computers, LED lamps, etc.) and also tightly covering all of the input BNC connectors with a single piece of aluminum foil (implements a low impedance common ground plane and shield).

[pickle9000]

I would qualify extremely slow CSV export of full memory as a bug. It takes around half an hour! It's not that complex operation to take so long. It should be up to a few times longer than storing to WFM file to account for additional processing, not more.

It is slow to a stick, does work though.

[Michal_S]

(...)extremely slow CSV export (...)

It is slow to a stick, does work though.

It sure does, though it's not very useful if you can save two-three files (of 24MSa) per hour.

[pickle9000]

- Be able to display a message from software on a PC. Ideally it would also have a Yes / No / Close button attached. I have a background in production testing and was often asked "Why can't I have a message on the scope screen to let me know?".

I've added these.

Seriously?     I have no doubt this would be useful for pickle, and probably others as well.  But you're talking about something that no other scope I am aware of has ever had.  And you're thinking that asking Rigol for this will have some benefit? 

IMO, there's no point muddying the waters with things that have basically 0 chance of ever being considered.  I mean, there are 'wishes', and there are 'blue sky fantasies'.  And I can tell you an 'ancient Chinese secret' that the longer your laundry list is, the greater the chance that the whole thing will get thrown away, and never looked at.

It's unusual but if this scope is targeted at education, new users or training then it's probably worth it. It's a minor change software wise, they will have most of the code in place already.

Just being able to ask a user to wait for a process to complete is a good idea. If you are in a classroom situation you could do walk the student through basic operations. On a repair bench integrate a predefined setup load and include test points. Of course this can be done in software on a pc and force the operator to look at the pc.. Anyway, I do think it's a good idea and a minor effort. 

[kwass]

(...)extremely slow CSV export (...)

It is slow to a stick, does work though.

It sure does, though it's not very useful if you can save two-three files (of 24MSa) per hour.

I've never tried that before, but just did, it's horribly slow.  Something around 45 minutes to write a 350MB file.  That's around 1/10 of USB 1.1 speed, let alone about USB 2.0.  I've added this to the "bugs" section.

[leppie]

Has no one mentioned the seemingly non-existent hi-res mode?

[pickle9000]

(...)extremely slow CSV export (...)

It is slow to a stick, does work though.

It sure does, though it's not very useful if you can save two-three files (of 24MSa) per hour.

I've never tried that before, but just did, it's horribly slow.  Something around 45 minutes to write a 350MB file.  That's around 1/10 of USB 1.1 speed, let alone about USB 2.0.  I've added this to the "bugs" section.

To be fair I've seen this before, the large waveform memory exaggerates the issue.

[Mark_O]

Most, if not all, HP/Agilent/Keysight DSOs seem to support displaying a message to the user via the :SYST:DSP command (it's listed in the programming manuals for the 54100A and DSOX2000 and also works on my old 1650B logic analyser); not sure how common this is with other manufacturers, as it isn't one of the commands required by SCPI as far as I can tell. 

Thanks for the correction.     I was unaware of those capabilities, and it's good to know.  It's not an illogical thing to have, and I can see how it would be useful to pickle9000.  I've got an older HP logic analyzer I haven't unboxed after a move.  I should check to see if it supports it, though I doubt it's something I'd ever use, not being in a production environment.

[Mark_O]

"Why can't I have a message on the scope screen to let me know?"

...  Of course this can be done in software on a pc and force the operator to look at the pc.

And you've just identified the main reason not to go to the extra effort.  If you're sending SCPI commands from a PC, you've got a PC there.  Just put the message on that screen, which will be vastly superior as an interactive display medium, and user-interaction device.

[KuchateK]

Top annoyances for me are: decoders working on screen not memory, measurement left on the screen after removal. Actually removal process is convoluted and takes too much time. Proposed On/Off for measurements would save ton of time.

But in addition to that I have something extra.

Flatten trigger menu.

Remove "Setting" option and bring items under that sub-menu to the front. They are all important and frequently used. Lack of any indication of trigger coupling requires unnecessary key press to verify that setting. Bring coupling and holdoff to the front, noise reject can occupy second page.

Scope has nice system of long menus with indicators of currently visible page, use that. This will make it more consistent with channel options that have "two pages" and the rest of the menus.

[kwass]

Flatten trigger menu.

Remove "Setting" option and bring items under that sub-menu to the front. They are all important and frequently used. Lack of any indication of trigger coupling requires unnecessary key press to verify that setting. Bring coupling and holdoff to the front, noise reject can occupy second page.

Scope has nice system of long menus with indicators of currently visible page, use that. This will make it more consistent with channel options that have "two pages" and the rest of the menus.

These are good suggestions.  We've got an on-screen indicator of trigger coupling on the wish list already, item (O) and moving the Coupling to the top level trigger menu as item (P).  I've added Holdoff.

[smgvbest]

I had asked Rigol about the Decode working on screen only and was informed the DS1000Z series has very little FPGA space left.
I would assume if that is true they are keeping their Limited resources for bug fixes not features and I would assume they are looking across the whole product line which includes the MS01000Z as well.   So while implementing the decode may work on a base DS1000Z the MSO1000Z would run out of space so that makes the feature something that can not be implemented.

From a support POV if this is true it would be a nightmare.   If they implemented the better decode on the DS1000Z but did not on the MSO1000Z I know I would be upset because I paid more for scope with LA capabilities so to have the support in the DS but not MSO would upset users so Rigol would be in a bad position.   Best stance as a company is to fix bugs but not add features that can not be supported across the whole line of the supported boards.

Thats mine opinion FWIW based on a simple reply from Rigol,  take it for what it's worth.

I do say that the decode function is not worth buying if this is the case.

[pickle9000]

I had asked Rigol about the Decode working on screen only and was informed the DS1000Z series has very little FPGA space left.
I would assume if that is true they are keeping their Limited resources for bug fixes not features and I would assume they are looking across the whole product line which includes the MS01000Z as well.   So while implementing the decode may work on a base DS1000Z the MSO1000Z would run out of space so that makes the feature something that can not be implemented.

From a support POV if this is true it would be a nightmare.   If they implemented the better decode on the DS1000Z but did not on the MSO1000Z I know I would be upset because I paid more for scope with LA capabilities so to have the support in the DS but not MSO would upset users so Rigol would be in a bad position.   Best stance as a company is to fix bugs but not add features that can not be supported across the whole line of the supported boards.

Thats mine opinion FWIW based on a simple reply from Rigol,  take it for what it's worth.

I do say that the decode function is not worth buying if this is the case.

Yikes! I wonder how bad is bad.

[kwass]

....
I would assume if that is true they are keeping their Limited resources for bug fixes not features and I would assume they are looking across the whole product line which includes the MS01000Z as well.   So while implementing the decode may work on a base DS1000Z the MSO1000Z would run out of space so that makes the feature something that can not be implemented.

.....

I do say that the decode function is not worth buying if this is the case.

I think it's fair to say that at least initially Rigol intended for the decode function to work on the entire memory contents as it's in the manual and they have a button for it.   Assuming that what they told you is true, that they ran out of room to implement this, they just never got around to changing the manual and removing the button in the firmware.  This has put them in a bad position as far as not meeting their advertised expectations.  Unless they can find room for this in all models they're not looking too good on this point. 

I agree that, as-is, the decode function is of minimum utility and not  worth paying for -- it's almost as expensive as a Saleae Logic 8.

[smgvbest]

@kwass

Can you point me to were in the manual it say's that?  I looked from the decode section and could not find anything that specifically says that.

Thank you

[kwass]

@kwass

Can you point me to were in the manual it say's that?  I looked from the decode section and could not find anything that specifically says that.

Thank you

It's at the top of page 7-5 (page 165 in the PDF) here:
http://www.batronix.com/pdf/Rigol/UserGuide/DS1000Z_UserGuide_EN.pdf

Press DataSrc to select “Trace” or “Memory” as the data source

[smgvbest]

Interesting
In that copy you linked to Jan 2014 has it as you say.
I have the Jun 2014 copy and References to Memory in the Datasrc are removed from everywhere except the Storage Menu.

[kwass]

Interesting
In that copy you linked to Jan 2014 has it as you say.
I have the Jun 2014 copy and References to Memory in the Datasrc are removed from everywhere except the Storage Menu.

So they seem to have made a half-heated attempt to backtrack on their original intention of allowing decoding from memory.   I wonder if they don't see this as a big deal for users that buy the decoding option.

[DanielS]

So they seem to have made a half-heated attempt to backtrack on their original intention of allowing decoding from memory.   I wonder if they don't see this as a big deal for users that buy the decoding option.

I could imagine decoding from memory being extremely useful when combined with segmented memory to record I2C or SPI packet bursts.

[etl17]

But to be fair, when you inspect each recorded segment the decoding works.
What would be the most interesting use case for decoding from memory would be the ability to search for specific values / events.....

[kwass]

But to be fair, when you inspect each recorded segment the decoding works.
What would be the most interesting use case for decoding from memory would be the ability to search for specific values / events.....

True, but there are a couple of major limitations with this approach.

- I2C doens't work because the start byte will be missing.

- It's really hard to navigate through memory when you only see a tiny bit of the decoded sequence at a time.

- The even table export function is useless (with a full memory decode you could search for sequential events and do other processing)


One nifty feature that I have used is the ability to trigger off a particular, decoded byte.  If you happen to have data with a unique byte marking the data of interest this somewhat mitigates the limited decode issue.

[Horstelin]

I think I found a new Bug:

(DS1054Z,  SW 00.04.02.SP4)

Just using Channel 4 (all others off) the hardware frequency counter was showing 120 Hz instead of a hundred until... you turned another channel on. Weirdly I can't reproduce the error after a restart of the Scope:



 

[kwass]

I think I found a new Bug:

(DS1054Z,  SW 00.04.02.SP4)

Just using Channel 4 (all others off) the hardware frequency counter was showing 120 Hz instead of a hundred until... you turned another channel on. Weirdly I can't reproduce the error after a restart of the Scope:

I just saw this too (feeding it 1000Hz into Ch 4 with just Ch4 on, but the counter showing <15Hz)  but can't reproduce it now.  It appears that you have to have previously used a certain option (or options) prior to trying this for the bug to show.  I tried lots of tests directly after a power on and can't make it happen again.  It's going to be hard to list this as a bug unless/until we can come up with a scenario to recreate it.

[DanielS]

Messed around with my DS1054Z some more since I got it. I think I am going to bump the severity of that zero offset calibration up a notch or two from "don't care" to "nag" since it messes up all the non-self-referenced vertical measurements.

Just for kicks, I tried doing a self-calibration with 50 ohms terminators on the inputs instead of nothing. That appears to have cut the DC offset errors roughly in half on both of my DS1054Zs. Offsets still jump around a bit when enabling and disabling channels though.

[BlueBill]

I think I found a new Bug:

(DS1054Z,  SW 00.04.02.SP4)

Just using Channel 4 (all others off) the hardware frequency counter was showing 120 Hz instead of a hundred until... you turned another channel on. Weirdly I can't reproduce the error after a restart of the Scope:

 

I recall only channel 1 has a hardware frequency counter.

[Lightages]

You can select the channel you wish but I think you also have to have the trigger set to the same channel too.

[smgvbest]

As well as if the signal level isn't high enough the counter doesn't register the correct value from what I've observed

[DanielS]

Another wish-bug: the scope always defaults to the Chinese "keyboard" input method so, every time I want to enter a name, I need to remember to switch it to plain English first. My UI language is set to English, why in heck would I want my keyboard to default to Chinese when the UI is set to any latin-alphabet language in the first place?

It would also be nice if the base file name for automatic save and print file numbering could be edited, even if the changes themselves were only temporary.

[kwass]

Another wish-bug: the scope always defaults to the Chinese "keyboard" input method so, every time I want to enter a name, I need to remember to switch it to plain English first. My UI language is set to English, why in heck would I want my keyboard to default to Chinese when the UI is set to any latin-alphabet language in the first place?

That sounds like a bug, but I don't see that happening on my scope.  Can you give a more specific example along with your firmware version.

It would also be nice if the base file name for automatic save and print file numbering could be edited, even if the changes themselves were only temporary.

There's something like this on the wish list already.  I'll augment it with your suggestion.

[DanielS]

Another wish-bug: the scope always defaults to the Chinese "keyboard" input method so, every time I want to enter a name, I need to remember to switch it to plain English first. My UI language is set to English, why in heck would I want my keyboard to default to Chinese when the UI is set to any latin-alphabet language in the first place?

That sounds like a bug, but I don't see that happening on my scope.  Can you give a more specific example along with your firmware version.

I don't see how much more specific I can be: turn the scope on, start trying to enter a file name (Storage->Save), realize it defaulted to Chinese, switch it back to Latin entry mode, finish doing whatever it is I was doing, turn the scope off, next time I power it on and need to enter a file name, the input method is back to Chinese.

I haven't updated the firmware yet - still on SP3.

[kwass]

I don't see how much more specific I can be: turn the scope on, start trying to enter a file name (Storage->Save), realize it defaulted to Chinese, switch it back to Latin entry mode, finish doing whatever it is I was doing, turn the scope off, next time I power it on and need to enter a file name, the input method is back to Chinese.

I haven't updated the firmware yet - still on SP3.

From the top of this thread:

This list is for software version: 00.04.02.SP4 only, with the current hardware (possibly only board 0.1.1).

I think that they changed the entry system in SP4 which is why I couldn't understand/see the problem you stated.

[rosbuitre]

Hi
Today I received my new DS1074Z
First mistake I see an entry showing a Board Version 0.2.2, in another 0.1.1
happened to anyone?, does other weird things that go up after
SP3 was installed, install the new SP4 and the same error

Regards
Osvaldo

[rosbuitre]

Another error?
With the two channels and pressing auto, OK
Disconnect channel 1 and 2 becomes unstable, disconnect the 2 and 1 OK, and 1V.
Only channel 2, auto and 500mV

Regards
Osvaldo

[tautech]

Another error?
With the two channels and pressing auto, OK
Disconnect channel 1 and 2 becomes unstable, disconnect the 2 and 1 OK, and 1V.

Trigger is set to CH1. 

[rosbuitre]

Another error?
With the two channels and pressing auto, OK
Disconnect channel 1 and 2 becomes unstable, disconnect the 2 and 1 OK, and 1V.

Trigger is set to CH1. 

Tomorrow what I see  and what the board version, which can be?

Regards

[DanielS]

From the top of this thread:

This list is for software version: 00.04.02.SP4 only, with the current hardware (possibly only board 0.1.1).

I think that they changed the entry system in SP4 which is why I couldn't understand/see the problem you stated.

Well, I just tried saving a file, had to switch the keyboard from Chinese to regular in "Storage->Save->New File" first as usual, turned the scope off, turned it back on, saved another new file, and the keyboard defaulted to Chinese with SP4 as well. So, my DS1054Z with SP4 still forgets that I do not write Chinese between reboots.

New wish-list item: downloading screen caps from the LXI web interface - simply add a page where the current screen output can be grabbed by refreshing the page, then the user can save that image whichever way they want. The LXI interface is already there, already has full access to scope functions including screen caps and already has a web server providing LXI device information pages. Adding a page to see the current screen output with manual refresh should be close to trivial.

[Dave Turner]

If the FPGA(s) etc are approaching maximum capability, then perhaps we should consider trade-offs.

What might be sacrificed for the requested improvements? 

OK I'm teasing a little because no-one truly want's to lose a capability - but!!!

[DanielS]

If the FPGA(s) etc are approaching maximum capability, then perhaps we should consider trade-offs.

The majority of tweaks on the list are UI-related and I seriously doubt the FPGA is involved with the UI itself beyond triggering, accumulating waveform data and calculating measurements/stats/events that require full sample rate processing. Same goes for the LXI, USB and related features - much too expensive to do in RTL.

Things like correcting the input DC offsets are mostly a software thing too, albeit with reuse of existing FPGA functions and other hardware: software puts the input muxes on enabled channels to GND, reads the FPGA's DC value measurements, adjusts input bias until all active channels read as close to zero DC as possible, restores the input muxes' original settings, done. The 1000z already does it during Self-Cal, but that is hopeless when offsets vary depending on channel combination or sometimes, even with the order in which they were enabled. Many scopes do this sort of quick-cal whenever channels get turned on/off or a vertical scale gets changed. If Rigol wrote their self-cal routines well, this "feature" should cost little more than a single function call to the relevant existing function that iteratively zeroes off currently enabled channel(s). They might want to use the previous calibration values as a starting point to skip the part of self-cal where inputs get railed though - the current self-cal routines appear to start from scratch every time.

[Dave Turner]

DanielS -  I  stated 'FPGAS etc' to include all forms of reprogrammable media as opposed to hardware limitation.

Whilst admittedly teasing a little I'm also serious. What might be omitted to allow for extra facility in another direction?

Would it be possible to reprogram the scope to be more suited for different scenarios? I don't know, but the concept is interesting.

[DanielS]

DanielS -  I  stated 'FPGAS etc' to include all forms of reprogrammable media as opposed to hardware limitation.

According to the storage menu, there is 90MB free on the SoC's visible storage area on my DS1054Z. While this may not seem like much, you can cram an awful lot of math, other algorithms and even UI stuff in 1MB of native binary code and text strings if you are the least bit careful about using storage efficiently. I doubt the system RAM is anywhere near down to its last MB free either. I am mostly concerned about the FPGA because FPGA resources are far more limited and can disappear on a whim, not to mention that each extra logic block used means that many fewer resources available to route signals on and that many more signals that need to get routed, so even the smallest feature addition or alteration in an FPGA can cause major timing closure issues when the device is almost full.

As for re-writing the scope's firmware, the thought crossed my mind (and no doubt many other people here too) but that would be rather hard to do without a full board reverse-engineering to know exactly how everything is connected together. It certainly would be an interesting challenge to find out how much of the FPGA is left once all the ADC-rate features have been duplicated and see how much I remember about working with 1GSPS ADCs from 12 years ago on Virtex2Pro FPGAs.

[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.   

[kwass]

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.

I've added these to the list.

[smgvbest]

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.

Totally agree about that.  you would think that would be default behavior

[toyman]

Wish List Items:
A) Full screen X-Y mode, the current display is tiny.

• Increase X-Y display to full screen in square format;
• add option to hide original source channels;
• add persistence selection specifically for X-Y display (with zero persistence, some levels of persistence, infinite persistence with persistence reset button (so scaling and moving X, Y channels would not reset persistence, reset only via button)).

I was disappointed to find no persistence available in X-Y mode, so I would love to see that added as well.

[Datman]

About offsets: I've noticed the same problem on my new DS1054Z  00.04.02.SP4. I have been surprised of that, but I think the problem is due to offsets and tolerances on the error amplifier reading offset during calibration. I don't remember if errors on the 4 channels are similar or different: if they are similar, it could be an offset issue on the error amplifier.

I'm surprised anyone have had anything to say about trace noise... Do you all have seen the problem but you are satisfied for the price, or do you have no noise?

I've also received 4 (4!) probes with the x1/x10 switch defective: if I select x1 and I measure resistance between the tip and the BNC, I read a minimum 245 ohm resistance (the right value), but with a continous, random variation to 800 - 1000 ohm - open circuit! Until resistance remains in the kohm range, I don't see anything on the scope because input impedance is very high, but when resistance goes to infinite I see it clearly on the trace.

What are your experiences about it? I've written an email to the italian seller I bought it from. A few minutes ago he answered asking me ship to him the scope to test it...

[kwass]

I was disappointed to find no persistence available in X-Y mode, so I would love to see that added as well.

Added to the list.

[Fungus]

I'd like to see the menu system changed.

When you press a soft menu button at the moment it opens the corresponding menu on screen then you can:
a) Press the same menu button again to go down through the list of available options
or
b) Turn the multifunction knob to select an item from the options

When you have the item highlighted you have to push the multifunction knob to select it. This is where the problem happens - it's very easy to accidentally change the menu selection when you push the knob. This selects the wrong item and is very annoying.

I also think it's confusing to newbies to use a menu button to open a menu but then there's no obvious button to close it again (pushing the multifunction knob to close a menu isn't intuitive at all).


IMHO it would be much better (and more intuitive) to do it this way:

Push a soft menu button to open a menu, push the same button again to close the menu.
When a menu is open you can use the light blue up/down arrows to select an item in the menu, or use the multifunction knob if you prefer thatt.

When you have the correct item highlighted in the menu, push the soft menu button again to select the item and close the menu (or push the multifunction knob if you prefer)

This would be a very simple change to the firmware but really improve the user interface.

[electr_peter]

When you have the item highlighted you have to push the multifunction knob to select it. This is where the problem happens - it's very easy to accidentally change the menu selection when you push the knob. This selects the wrong item and is very annoying.

https://www.eevblog.com/forum/testgear/rigol-1054z-detents-suggestions-for-stiffening/

I also think it's confusing to newbies to use a menu button to open a menu but then there's no obvious button to close it again (pushing the multifunction knob to close a menu isn't intuitive at all).

Press "Clear", it closes opened menus.

[Datman]

We know that there isn't a RTC and there will not be in the future.
The problem is that when we make a screenshot, the file will be numbered with the first number free among the pictures already on the memory. (A)
Instead of that, I think it would be better if the new file would be numbered with a number after the higher already present, also if there are numbers free because pictures have been previously deleted. (B)
Another option is a sequential number: the scope keeps logged the last number used and for the next picture he will give the next number. (C)

A): files on the memory: 1, 2, 3, 5, 6, 7, 8. The next file, the last, will be number 4...
B): files on the memory: 1, 2, 3, 5, 6, 7, 8. The next file, the last, will be number 9.
C): memory #1: files 4, 7, 8, 11
      memory #2: files 1, 2, 3, 5, 6, 9
      The last file saved by the scope is number 11. The next file will be 12, wherever I will write it. It will be also possible to reset the counter or renaming the last file saved: after saving a file I can go to the rename function or do nothing.

[Lightages]

I have noticed an intermittent bug. I cannot reproduce it reliably. Sometimes, under certain conditions and when the trigger point is far off the screen, when trying to return to a normal view the trace is displayed as if has zero persistence at all. It appears like a trace displayed on a DS1052E. Only when the trigger is re-centered using the push function on the horizontal position button does the waveform regain its normal CRT like appearance.

[Fungus]

When you have the item highlighted you have to push the multifunction knob to select it. This is where the problem happens - it's very easy to accidentally change the menu selection when you push the knob. This selects the wrong item and is very annoying.

https://www.eevblog.com/forum/testgear/rigol-1054z-detents-suggestions-for-stiffening/

I also think it's confusing to newbies to use a menu button to open a menu but then there's no obvious button to close it again (pushing the multifunction knob to close a menu isn't intuitive at all).

Press "Clear", it closes opened menus.

Sure ... but the idea of this thread is to fix things - get it done right and you won't need workarounds.

Those changes would be very easy to program - no fancy algorithms needed.

[kwass]

Sure ... but the idea of this thread is to fix things - get it done right and you won't need workarounds.

Those changes would be very easy to program - no fancy algorithms needed.

I think it would be better if the new file would be numbered with a number after the higher already present, also if there are numbers free because pictures have been previously deleted.

I've added these to the (growing very long) list.

[Datman]

I think the best would be numbering screenshots with a sequential number, so all my screenshots will have a different number (until I reset the counter) also if I use more then one USB memory or I copy files to a computer and I delete them on the USB memory: it will be impossibile to make a mistake, because ALL screenshots from my scope will have different names!

Obviously, it requires to write a few bytes in a EEPROM area in the scope...

[kwass]

I think the best would be numbering screenshots with a sequential number, so all my screenshots will have a different number (until I reset the counter) also if I use more then one USB memory or I copy files to a computer and I delete them on the USB memory: it will be impossibile to make a mistake, because ALL screenshots from my scope will have different names!

Changed.

[alsetalokin4017]

OK... I can't find mention of this particular error or "Bug", I apologise if it has been mentioned already. I've posted it in a couple of other threads and frankly I am surprised by the few responses I have gotten, which are essentially  "Oh, I don't ever use that feature so it doesn't matter". Well, it certainly  matters to me because I _do_ use the features and it is important to me that they work properly.

When the CH1 "units" are set to "A" for amps, and the CH2 "units" are set to "V" for volts, and the Math is set to do CH1xCH2, the Offset and Scale come up automatically correctly in "W" units for Watts. But this "W" unit is not passed on to the Measurements, neither selected from the LH screen menus or in the All Measure table. These units stay in whatever you've put in for the CH1 units, in my case "A". This seems like a "fail" in the software. I hope some other users can check my work to see if this is happening on all the scopes, and if so, I hope that it can be put on the list for Rigol to correct with the next firmware revision.
Please see the scopeshots below.

Scope is from new production, ordered on Feb 9 and just arrived to me on April 8 from TEquipment.
Software is 00.04.02.SP4, board 0.1.1, unlocked with no problem.

(I have also experienced some of the offset issues noted above and I think I have a hardware problem on CH4 that may require me to return the scope for a warranty replacement, but that's not related to this "bug".)

[pickle9000]

I think this thread would make a good video for Dave. Most of what's on here will never be addressed, is that bad?

My general feeling on this sort of thing is that it's very important to know the limitations of your equipment. The DS1000Z is a good example of a bit of gear that has had one major fault fixed and many small ones not. Should that stop you from buying it?

Everyone always want's things to be perfect, it's the engineering way. Reality is that price, quality and function are what makes the decisions. Rigol's decisions are based on money as are all companies. Things that change the bottom line will be fixed other "may be fixed" if it is found it can increase sales.   

[DanielS]

My general feeling on this sort of thing is that it's very important to know the limitations of your equipment. The DS1000Z is a good example of a bit of gear that has had one major fault fixed and many small ones not. Should that stop you from buying it?

I think it has been said many times that despite its many flaws and quirks, the DS1xxxZ are still great bang-per-buck scopes if none of their shortcomings are deal-breakers to you.

It is good enough for troubleshooting purposes, as a backup, secondary scope or budget/beginner scope. For people who need accuracy beyond reasonable doubt, data export that does not fail half the time for obscure reasons and takes forever when it does work, etc., they might want to look for a better primary scope.

[pickle9000]

My general feeling on this sort of thing is that it's very important to know the limitations of your equipment. The DS1000Z is a good example of a bit of gear that has had one major fault fixed and many small ones not. Should that stop you from buying it?

I think it has been said many times that despite its many flaws and quirks, the DS1xxxZ are still great bang-per-buck scopes if none of their shortcomings are deal-breakers to you.

It is good enough for troubleshooting purposes, as a backup, secondary scope or budget/beginner scope. For people who need accuracy beyond reasonable doubt, data export that does not fail half the time for obscure reasons and takes forever when it does work, etc., they might want to look for a better primary scope.

I picked one up to see what all the noise was about. It is a good scope, I find myself using it often on the bench. It's my only 4 channel so for that alone it's worth it. From a production testing standpoint I find it amazing how few out of the box failures they have. I'd love to have a tour of that production line, and see the testing procedures.

[kwass]

...
When the CH1 "units" are set to "A" for amps, and the CH2 "units" are set to "V" for volts, and the Math is set to do CH1xCH2, the Offset and Scale come up automatically correctly in "W" units for Watts. But this "W" unit is not passed on to the Measurements, neither selected from the LH screen menus or in the All Measure table. These units stay in whatever you've put in for the CH1 units, in my case "A". This seems like a "fail" in the software. I hope some other users can check my work to see if this is happening on all the scopes, and if so, I hope that it can be put on the list for Rigol to correct with the next firmware revision.

I've added this to the bug list at the top of this thread.

[bitwelder]

On my wish list:
- use a meaningful amount of decimals in the horizontal position display (e.g. the silly '0.00000000 ps' that also Dave commented on)
- use a darker tone of gray for deleted measurements, so they get almost invisible (as they are still 'live' measurements, my eye gets distracted by their updates)

[ManicMaurice]

- use a darker tone of gray for deleted measurements, so they get almost invisible (as they are still 'live' measurements, my eye gets distracted by their updates)

I'll go one better. How about when measurements are cleared when they are removed from the screen. 

[bitwelder]

I'll go one better. How about when mesurements are cleared they are removed from the screen. 

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). 

[kwass]

On my wish list:
- use a meaningful amount of decimals in the horizontal position display (e.g. the silly '0.00000000 ps' that also Dave commented on)

I've added this to the list.  We already have an item about clearing the deleted measurements.

[DanielS]

I'll go one better. How about when mesurements are cleared they are removed from the screen. 

It is really odd and somewhat annoying how the scope remembers deleted measurements and there is no way to get rid of them for good short of removing all measurements and rebooting the scope. When you take screen caps to attach to a document, it can be quite distracting to have irrelevant measurements still on screen.

[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.

[leppie]

Typos:

Wishlist, item N: 513 should be 512

My wishlist:

- USB keyboard support for navigating menus and character input.
- Menu item for vertical position/offset, seems the only way to change this is via the knob. Perhaps an oversight?

Suggestions:

New firmware has been released and should shown on first post, along with striked out fixes and regressions (if any).
You could maybe even add fixes from the changelog to the first post? 


PS: Oh! And thanks 

[kwass]

- Menu item for vertical position/offset, seems the only way to change this is via the knob. Perhaps an oversight?

PS: Oh! And thanks 

Thank YOU for all that! 

I don't quite understand your wish list item for a vertical offset menu option.  How exactly would that work?  Doesn't this have to be a knob controlled function, or do you want to be able to type in offset in volts (or whatever the current units are)?

[Anand]

6) Writing full memory to a CSV file takes an extremely long time.  Write speeds seem to be about 0.15 MB/sec instead of the expected 10MB/sec or so. (fixed in 4.03)

Are you sure that this got fixed? I've saved a 1MB file in 9 seconds on an usb disk. And I'm still waiting (25min+) for a 24Meg memory dump to finish... :/

[wd5gnr]

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.

The decode on delay seems to only decode the zoomed in part. I had a recent project at my day job where we were decoding RS422 data out of the data buffer. With 100's of bytes in each packet, it would have been very painful to have to align each screen. I'll try the delay again to make sure, but I'm pretty sure I tried that and found it still only showed what was on the zoomed in part. Funny story: the old scope at work didn't have much sample memory so I brought in my DS1102E. We could capture the whole packet, but it doesn't decode. However, pulling the CSV file and running it through a quick awk script worked really well.

[ebastler]

The decode on delay seems to only decode the zoomed in part. I had a recent project at my day job where we were decoding RS422 data out of the data buffer. With 100's of bytes in each packet, it would have been very painful to have to align each screen.

Ah, now I understand. I had missed the "zoom" bit before. Indeed, if you trigger only once to capture an extended trace, then want to zoom in and scroll through the trace to decode it byte by byte, triggering does not help much. I am not aware of a workaround unfortunately, besides the painful manual positioning of each screen which you mention.

[kwass]

6) Writing full memory to a CSV file takes an extremely long time.  Write speeds seem to be about 0.15 MB/sec instead of the expected 10MB/sec or so. (fixed in 4.03)

Are you sure that this got fixed? I've saved a 1MB file in 9 seconds on an usb disk. And I'm still waiting (25min+) for a 24Meg memory dump to finish... :/

Based on comments that I had read I thought that it was fixed.  I haven't had a chance to test it myself, so will put it back on the list based on your testing.

[LogAmp90]

MINOR DISPLAY BUG:

Holding buttons down causes incorrect highlighting.

Example:
On the math menu, with Operation OFF, HOLD the "Operation" soft key for about 4 seconds and release the button.
The light blue highlight box will appear around the "OFF" text and nothing else happens.  To clear the highlighting, press
the button normally which of course also actually performs the action.

This can be done with many of the menu buttons.  Simply a logic bug in the firmware.  Seems like some button state timer is timing out and not checking the highlight state.

These highlight operations seem rather slow as they often don't show up with quick button presses anyhow.  I think the CPU is overtaxed which makes the UI a bit sluggish.  Still a great scope though.  I'm not sending mine back. 

[leppie]

- Menu item for vertical position/offset, seems the only way to change this is via the knob. Perhaps an oversight?

PS: Oh! And thanks 

Thank YOU for all that! 

I don't quite understand your wish list item for a vertical offset menu option.  How exactly would that work?  Doesn't this have to be a knob controlled function, or do you want to be able to type in offset in volts (or whatever the current units are)?

Yes, the latter. Also, the offset just appears as small graphic. Having it in on a menu too would make it more readable.

[wd5gnr]

I noticed something today that is perhaps not exactly a bug, but perhaps more than a wish.

I grabbed a lot of sample data from an RS232 instrument. When I zoomed in, all the data that wasn't showing was "lost" until I zoomed out.

This is all with the same buffer of data (e.g., scope stopped):

Zoom out to see all of it:


Now delayed sweep zoom and all of it is there:


Zoom in without delayed sweep:


Now zoom it -- data is "gone" except for what was on the tube


It is stuff like this that makes the big sample memory less useful than you think it would be.

[miguelvp]

I noticed something today that is perhaps not exactly a bug, but perhaps more than a wish.

I grabbed a lot of sample data from an RS232 instrument. When I zoomed in, all the data that wasn't showing was "lost" until I zoomed out.

This is all with the same buffer of data (e.g., scope stopped):

...

It is stuff like this that makes the big sample memory less useful than you think it would be.

How about using the segmented memory capability of your scope?

You can try this (I don't have an RS232 signal handy at the moment and I don't have a DS1000 series I do however have a DS2000 one so it should be the same).

Set the trigger mode to RS232 and use "Data" for "When" to trigger. Set the right Polarity and Baud rate for the RS232 trigger, also set the Sweep to Normal, although it might work with Auto.

Set the trigger level and the delay and zoom into one packet.

On the Acquire menu set it to normal and change the memory depth to your lower setting (14KPoints on the DS2000), make sure you can see the full signal.

Set the decode to RS232 and the baud rate and polarity, data bits, stop bit etc..

Then press the record button.

It should capture only the data and ignore the idle time, not sure if it will be able to decode this way or if you can look at the event table this way, but at least only the data signals would be captured.

With the big playback dial you can go frame by frame of only the data.

Then press the Utility menu, select Record, and change the Mode to Play back, that might be the same as using the front end but it allows you to set a range of  frames to look at and an interval to speed up or slow down the playback.

Again, not sure how this translates to the DS1000z scope but it should be about the same.

[wd5gnr]

Yes I have segmented memory (record on the Rigols) but that's not the point. The point is, most of the features (decoding, delayed sweep zoom, etc.) only apply to the screen which makes the big sample buffer not as useful. For that matter, just starting with the screen zoomed out is an acceptable work around, it is just cheesy.

[tomy983]

Wish List Items:

A) Full screen X-Y mode, the current display is tiny.  Also, allow screen persistence to be set in X-Y mode.

I don't know If it was discussed already, I tried to look but couldn't find anything. Anyway...

My 1054z, which I received recently with the latest 4.03 firmware already installed, has on the horizontal menu a soft menu button called "Display" and the selected option is "Split".
Unfortunately, looks like I cannot change from split to anything else (no effect on pressing the corresponding key).

Looks like Rigol actually took a step towards allowing full screen for the xy mode... Well, they added a button for it 

[mauroh]

Regarding the X-Y mode, I'm not able to set a math function as X or Y
Es X=ch1 and Y=ch1-ch2
I was playing with a circuit to display the transistor curves but without this option it is useless.
I can see the "math" trace in the upper part of the display, but it is not possible to select it as source.

Is it possible to add this in the wish list?

Thanks
    Mauro

[kwass]

Regarding the X-Y mode, I'm not able to set a math function as X or Y
Es X=ch1 and Y=ch1-ch2
I was playing with a circuit to display the transistor curves but without this option it is useless.
I can see the "math" trace in the upper part of the display, but it is not possible to select it as source.

Is it possible to add this in the wish list?

Good idea!  I've added it to the list, but I have no idea if anyone from Rigol is looking at this thread.

[alsetalokin4017]

I guess I've found Yet Another bug. See the screenshots below. The Math trace is displaced about 1 1/2 divisions to the right from where it should be. The amount of the error depends on horizontal position; near the left of the screen it's less than 1 division and near the right, over 2 divisions. I don't yet know the "minimum" set of conditions to reproduce this bug, but it happens for me at present when I am using all 4 channels, have Math set to CH1 x CH4 and timebase set to 500 ns/div. Acquire mode "Average". At other timebase and/or Acquire settings the Math trace looks correct horizontally.

Firmware 04.03

(Also happens in "zoom" horizontal mode, with main timebase set to whatever and "zoom" window TB set to 500 ns/div.)

[Warhawk]

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

Pictures here:
https://www.eevblog.com/forum/projects/rigol-ds1000z-csv-to-ltspice-(pwl)-parser-(testers-welcomed-!)/msg673153/#msg673153

edit: Please confirm somebody

[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

Pictures here:
https://www.eevblog.com/forum/projects/rigol-ds1000z-csv-to-ltspice-(pwl)-parser-(testers-welcomed-!)/msg673153/#msg673153

edit: Please confirm somebody

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

[kwass]

I guess I've found Yet Another bug. .

Firmware 04.03

I can not reproduce this on my scope with firmware 04.02.  Is this due to hardware variation too?

[alsetalokin4017]

I guess I've found Yet Another bug. .

Firmware 04.03

I can not reproduce this on my scope with firmware 04.02.  Is this due to hardware variation too?

I have no idea. Other people have said that there are several board versions of this scope, but I have never seen anyone report anything other than "Board Version 0.1.1" except immediately after "unlocking" options and 100MHz bandwidth. But even those generally go back to reporting Board Version 0.1.1 after rebooting once or twice, as far as I know.

The conditions to reproduce this one may be more specific than other bugs that have been reported. I haven't had time to explore it all that much; I can only state that it occurs for me under the conditions shown.

In the scopeshots below, the first one shows the Math trace displaced to the right. Average Acquire mode, max mem depth. In the second trace I've just changed the "zoom" timebase to 200 ns/div and the Math trace is back where it belongs. Trigger channel may or may not make some difference as well.

[GonzoTheGreat]

I guess I've found Yet Another bug. See the screenshots below. The Math trace is displaced about 1 1/2 divisions to the right from where it should be. The amount of the error depends on horizontal position; near the left of the screen it's less than 1 division and near the right, over 2 divisions. I don't yet know the "minimum" set of conditions to reproduce this bug, but it happens for me at present when I am using all 4 channels, have Math set to CH1 x CH4 and timebase set to 500 ns/div. Acquire mode "Average". At other timebase and/or Acquire settings the Math trace looks correct horizontally.

(Also happens in "zoom" horizontal mode, with main timebase set to whatever and "zoom" window TB set to 500 ns/div.)

I confirm this bug with firmware v04.03

I hate it because this bug causes an erroneus math waveform to be displayed and it is hard to notice on non-sparse source waveforms.
With the other bugs you could see immediately, that there was something wrong (e.g. freeze) but with this one you might never know if you don't look closely.

This bug is insidious and means that you cannot trust your scope.

[Howardlong]

Yesterday when I tried it was unable to reproduce it on 4.0.2 with four channels and math AxB with your timebase setiings.

Rather than state I just don't ever get this fault, I now see it may be dependent on zoom. May I suggest that you provide a sequence of steps from a factory default set up? You may well find that more people have the fault that way, rather than us drawing false conclusions from an unrepresentative configuration. That seemed to be the case in the last bug you drew attention to, once we'd had the full config from factory reset more people were able to demonstrate the bug.

[MarkF]

I would like to address the small font for the measurements.  Although I would like to see them one point size larger, I just realized that it's not really the size that is the problem, it's the font family.

For example if you compare the shape of the 6, 8 and 9, you will see that there are only 2 or 3 pixels difference between them.  Compare that to a verdana font and you will see a significant difference that is much easier to read.  I'm not suggesting Rigol use the verdana font.  Any font the has a significant difference in the shapes between all the numbers.  Also, I would not want to see a vertical offset in some numbers as seen in some font families.

As far as the extra large option that has been added, that is just insane!

Here is an example.  Even though it's small, it's still easy to read.  I'm using this font for a 1.25"  OLED display that is 128x96 pixels.  I can display 21 horizontal characters.

[alsetalokin4017]

Yesterday when I tried it was unable to reproduce it on 4.0.2 with four channels and math AxB with your timebase setiings.

Rather than state I just don't ever get this fault, I now see it may be dependent on zoom. May I suggest that you provide a sequence of steps from a factory default set up? You may well find that more people have the fault that way, rather than us drawing false conclusions from an unrepresentative configuration. That seemed to be the case in the last bug you drew attention to, once we'd had the full config from factory reset more people were able to demonstrate the bug.

Well, study the first screenshot below. It contains the setup information that I need to reproduce the fault clearly and easily. Instead of an actual measurement situation that others may not find convenient to emulate, here the signal input is about 300 kHz positive-going squarish pulse train of about 12 or 13 percent HI duty cycle from my FG. Both channel probes (10x attenuation) 1 and 4 are connected to the same output from the FG. The other channels have no signal input. At least one of the unused channels must be turned on, though.
Persistence is set to "min" and all the other user settings are default values, except what's shown on the screen in terms of Acquire mode, channel settings, trigger parameters, etc.

SO with this signal, for me the key settings seem to be: Average acquire mode, at least 3 channels on, Math Ch1xCh4. (Or, evidently, any other combo of channels in the Math multiplication -- the second shot below is using a different channel combo, and different order, in the Math multiplication, but other settings the same as the previous shot.)

ETA: With this signal the bug also happens with A+B math....

[alsetalokin4017]

I guess I've found Yet Another bug. See the screenshots below. The Math trace is displaced about 1 1/2 divisions to the right from where it should be. The amount of the error depends on horizontal position; near the left of the screen it's less than 1 division and near the right, over 2 divisions. I don't yet know the "minimum" set of conditions to reproduce this bug, but it happens for me at present when I am using all 4 channels, have Math set to CH1 x CH4 and timebase set to 500 ns/div. Acquire mode "Average". At other timebase and/or Acquire settings the Math trace looks correct horizontally.

(Also happens in "zoom" horizontal mode, with main timebase set to whatever and "zoom" window TB set to 500 ns/div.)

I confirm this bug with firmware v04.03

I hate it because this bug causes an erroneus math waveform to be displayed and it is hard to notice on non-sparse source waveforms.
With the other bugs you could see immediately, that there was something wrong (e.g. freeze) but with this one you might never know if you don't look closely.

This bug is insidious and means that you cannot trust your scope.

Unfortunately I agree. It is particularly frustrating because this exact computation (instantaneous Power, from multiplication of V and I inputs) was the main reason for acquiring this scope in the first place.

Well, this one only _seems_ to be happening at 500 ns/div, whether zoomed to that timebase or set in main timebase. So should I just stick a piece of tape on the knob, saying "Don't Use 500 ns/div for Math multiplication".... along with all the other pieces of tape with other "no-no" buggy settings?

/rant

[Warhawk]

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

Pictures here:
https://www.eevblog.com/forum/projects/rigol-ds1000z-csv-to-ltspice-(pwl)-parser-(testers-welcomed-!)/msg673153/#msg673153

edit: Please confirm somebody

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

It may have changed, but I don't see anything like that in the buglist:

"W) Change file file numbering scheme so that instead of using the first available file number simply use a sequential number (stored in persistent memory) until reset by the user."

[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.

[alank2]

I tried a DS1074Z-S and had to return it.  I was buying it mostly for the signal generator and thought I could perhaps sell my other scope because it is a scope too.  The problem was that I encountered too many bugs.  Some of these bugs may already be known.

One was that it was blinking on the 5nS timebase for some reason.  Instead of a solid display like you see at 10nS or slower, it would be fine fine fine, and then flicker a bit.

The signal gen is where I had most problems.  I got the feeling I was trying to use something no one has ever tested, I figured by now most features would be tried and bugs would be known and made known to Rigol.  I tried loading some arbitrary waveforms, but every time I would do this the amplitude would reset to 10mV for some reason.  I would then the button on it and set it back to 2.5V, but the output would NOT change.  Only once I tried to do anything with the offset would it actually change the output for some reason.  What is really dumb is that the offset can only be zero because the amplitude is 2.5V, but that doesn't matter, just trying to change the offset seems to set the channel and finally make the new amplitude take hold.  I finally gave up trying to load an arbitrary waveform file, though the square wave and ramp wave ones seemed to do much better than the sine wave one I tried.  I decided to just use the internal editor to create an arbitrary waveform.  I entered 16 points for a sinewave by hand and at the end, it was all jaggy and not right.  I did that with create.  When I used edit to go back in and apply it a second time, then it corrected itself and was ok.  If you save it and try to reload it, it won't load properly.  I finally gave up and decided to return it.

[gojimmypi]

HDMI!!!

Here's my attempt to catalog the bugs and wish list items for the Rigol DS1000Z oscilloscopes.   
...(snip)...

Is Rigol listening? (hope so)

I think it would be ridiculously awesome to have an HDMI output that mirrors what you see on the otherwise small screen: resulting in not only easier to read screens at the bench, but also the ability to more easily record what you see.

OR

Even easier and simpler (no hardware mod): implement something in software that allows the user to "cast" the screen onto a Chromecast device on the local ethernet:

http://www.amazon.com/dp/B00DR0PDNE/

https://support.google.com/chromecast/answer/2998336

maybe even a web browser:

https://support.google.com/chromecast/answer/2998338

that would seriously ROCK! 

[marber]

I'm debugging an SPI communication issue with a chip that uses SPI mode 3, and while using the Rigol DS1000Z's SPI decoding, I noticed something odd:

It decodes individual bits in an 8-bit SPI transfer as '0xFF'.

This happens when 'Polarity' is (incorrectly) set to GND=1 - otherwise it decodes it as '00' which is not incorrect but confusing enough for a 1 bit value. Edge is set to 'falling'; when set to rising edge (which is what I need) it doesn't decode at all. Likewise, if I change Polarity it doesn't decode either. Width is set to 8. If I zoom out further, it doesn't decode the full 8 bit 'packet' either, just the individual bits.

Bug, or am I just missing something?

DS1074Z-S 'upgraded', Software Version 00.04.03.SP1, Board Version 4.1.1.

[kwass]

The scope only uses the screen memory buffer for decoding.  You pretty much need to be able to see all the bits in each character yourself for accurate decoding.  It's a severe limitation and one that Rigol will hopefully address in a future upgrade, it's (B) on the wishlist at the top of this thread.

[marber]

The scope only uses the screen memory buffer for decoding.  You pretty much need to be able to see all the bits in each character yourself for accurate decoding.  It's a severe limitation and one that Rigol will hopefully address in a future upgrade, it's (B) on the wishlist at the top of this thread.

Yes, but it has all 8 bits available, so it's able to decode the full byte. Granted, it doesn't have the falling edge of CS to aid this in the screenshot I provided, but a) when I zoom out a bit to include that it still doesn't decode the full packet, and b) it certainly shouldn't be decoding individual bits as 0xFF (or even 0x7F as I saw later).

[Howardlong]

I'm debugging an SPI communication issue with a chip that uses SPI mode 3, and while using the Rigol DS1000Z's SPI decoding, I noticed something odd:

It decodes individual bits in an 8-bit SPI transfer as '0xFF'.

This happens when 'Polarity' is (incorrectly) set to GND=1 - otherwise it decodes it as '00' which is not incorrect but confusing enough for a 1 bit value. Edge is set to 'falling'; when set to rising edge (which is what I need) it doesn't decode at all. Likewise, if I change Polarity it doesn't decode either. Width is set to 8. If I zoom out further, it doesn't decode the full 8 bit 'packet' either, just the individual bits.

Bug, or am I just missing something?

DS1074Z-S 'upgraded', Software Version 00.04.03.SP1, Board Version 4.1.1.

I suspect there may be something not quite right with your decoder set up, maybe the CLK/CS/MOSI not assigned to the correct channels?

[marber]

I suspect there may be something not quite right with your decoder set up, maybe the CLK/CS/MOSI not assigned to the correct channels?

Yeah, but I checked every setting available multiple times. CLK, CS and MOSI are certainly correct.

I only started seeing this when I went to set it up for SPI mode 3, i.e. active low CLK and on rising edge - it successfully decoded packets in a SPI mode 0 setup before, with otherwise unmodified settings.

[Howardlong]

I suspect there may be something not quite right with your decoder set up, maybe the CLK/CS/MOSI not assigned to the correct channels?

Yeah, but I checked every setting available multiple times. CLK, CS and MOSI are certainly correct.

I only started seeing this when I went to set it up for SPI mode 3, i.e. active low CLK and on rising edge - it successfully decoded packets in a SPI mode 0 setup before, with otherwise unmodified settings.

See photo: I tried all four SPI modes, all OK.

[marber]

See photo: I tried all four SPI modes, all OK.

Strange. I think I'll do a factory settings reset later just to be sure, and then try to reproduce it and post the exact settings.

What firmware are you running on? Also, you're using an MSO, which I think is subtly different hardware/firmware especially in the logic analyzer / decoding department, isn't it? That may or may not make the difference as well...

[Howardlong]

See photo: I tried all four SPI modes, all OK.

Strange. I think I'll do a factory settings reset later just to be sure, and then try to reproduce it and post the exact settings.

What firmware are you running on? Also, you're using an MSO, which I think is subtly different hardware/firmware especially in the logic analyzer / decoding department, isn't it? That may or may not make the difference as well...

I'm not with the scope right now, but it's the version DS/MSO1000Z version that was released about a month or so ago that everyone's complaining about the UI response speed, ISTR 04.03.02.03. Board version 6.1.1.

There may be some differences, but I deliberately left the MSO channels off and used the same channels as you and the same settings to the extent that I could see (and guess!).

[marber]

I'm not with the scope right now, but it's the version DS/MSO1000Z version that was released about a month or so ago that everyone's complaining about the UI response speed, ISTR 04.03.02.03. Board version 6.1.1.

Right. My firmware is at least one version older - it reports as 04.03.SP1. It may already be fixed, but with people complaining about the latest version, I'll wait with upgrading.

There may be some differences, but I deliberately left the MSO channels off and used the same channels as you and the same settings to the extent that I could see (and guess!).

Before a factory reset, I decided to play a bit more first while it still has the same settings. I tracked it down to decode setting "Mode CS" vs "Mode Timeout" - in the latter it decodes correctly as a full frame, in CS mode it shows the behavior I've been seeing.

I've attached screenshots of all settings of the Decode menu.

I could understand mode CS not working as the CS line goes down outside the screen in my screenshots, and the DS1000Z won't decode outside the screen area. However if I zoom out just enough to have CS go down within the range of the screen (last screenshot, CS going down in the left behind the table) the scope still decodes individual bits as FF/7F. No longer readable on the decode trace in that zoom range, but the event table shows the same values.

I wonder if the signal quality may also have an effect (with the auto thresholds perhaps?). Obviously the signal quality is pretty bad in these captures - it's on a large breadboard going all over the place.

[Jeff5341]

I have an MSO 1104z. Nice Scope for the money. I wish they would have chosen green for the channel 2 or 4  trace. I often use all four channels, and sometimes get channels 2 and 4 (light and dark blue) mixed up when changing circuit test points. A better match of the probe color rings to the corresponding traces would be nice.

[MarkF]

I have an MSO 1104z. Nice Scope for the money. I wish they would have chosen green for the channel 2 or 4  trace. I often use all four channels, and sometimes get channels 2 and 4 (light and dark blue) mixed up when changing circuit test points. A better match of the probe color rings to the corresponding traces would be nice.

They use green for the logic analyzer channels.  But, I agree.  I would much rather they used green for channel 4 and used the dark blue (or some other color) for the logic analyzer.  I too am always getting the dark and light blue channels mixed up.

[Karel]

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

Can you please be more specific? For example, which platform and/or software is used to test this?

For sure, RAW mode of data acquisition over USB works fine on linux!!

Please correct this.

Thank you.

[Karel]

3) The FFT function only works for channel 1.  However it will work for the other channels as long as channel 1 is turned on.

Not true, at least not with latest firmware.

There is, however, a new bug: the TMC command :MATH:SOUR1 CHAN1 or :MATH:SOUR1 CHAN2 is ignored by the scope,
so, it's impossible to select the source channel for the FFT via remote connection.

[ankerwolf]

Hello Karel,

There is, however, a new bug: the TMC command :MATH:SOUR1 CHAN1 or :MATH:SOUR1 CHAN2 is ignored by the scope,
so, it's impossible to select the source channel for the FFT via remote connection.

Test following:
  :MATH:FFT:SOUR?         // ok - entgegen S.107
  :MATH:FFT:SOUR CHAN1    // ok - entgegen S.107

LG Wolfgang

[Karel]

Hello Karel,

There is, however, a new bug: the TMC command :MATH:SOUR1 CHAN1 or :MATH:SOUR1 CHAN2 is ignored by the scope,
so, it's impossible to select the source channel for the FFT via remote connection.

Test following:
  :MATH:FFT:SOUR?         // ok - entgegen S.107
  :MATH:FFT:SOUR CHAN1    // ok - entgegen S.107

LG Wolfgang

Thanks but that doesn't work either.
And Rigol's programming guide from July 2015 says :MATH:SOUR1 CHAN1

[Karel]

I believe I found another bug.

When the FFT is activated in splitscreen and "trace" mode, when you remotely change the horizontal timebase, the string
"FFT: CH2 10.00 dBV  12.5KHz/Div 500K Sa/s" will not be updated and as a result will show wrong values.

[ankerwolf]

Hello Karel,

Thanks but that doesn't work either.
And Rigol's programming guide from July 2015 says :MATH:SOUR1 CHAN1

It does work ! Look at my Log & Picture before and after ...
I know, the Manual does say an other syntax 

Code: [Select]

*IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZAxxxxxxxx,00.04.03.SP2

:MATH:FFT:SOUR?
CHAN2

:MATH:FFT:SOUR CHAN1

:MATH:FFT:SOUR?
CHAN1


LG Wolfgang

[Karel]

Hello Karel,

Thanks but that doesn't work either.
And Rigol's programming guide from July 2015 says :MATH:SOUR1 CHAN1

It does work ! Look at my Log & Picture before and after ...
I know, the Manual does say an other syntax 

Code: [Select]

*IDN?
RIGOL TECHNOLOGIES,DS1104Z,DS1ZAxxxxxxxx,00.04.03.SP2

:MATH:FFT:SOUR?
CHAN2

:MATH:FFT:SOUR CHAN1

:MATH:FFT:SOUR?
CHAN1


LG Wolfgang

You are right, using telnet it works...

edit:
Found it, I tried :MATH:FFT:SOUR1 CHAN1 instead of :MATH:FFT:SOUR CHAN1

Thanks again, that was very helpfull.

[ankerwolf]

Hello Karel,

I believe I found another bug.
When the FFT is activated in splitscreen and "trace" mode, when you remotely change the horizontal timebase, the string
"FFT: CH2 10.00 dBV  12.5KHz/Div 500K Sa/s" will not be updated and as a result will show wrong values.

That is right! It ist a BUG.

But when you turn the Horizontal-Knob remotely, then it works.

Code: [Select]

:SYST:KEY:DECR HSCALE,1


[Karel]

But when you turn the Horizontal-Knob remotely, then it works.

Code: [Select]

:SYST:KEY:DECR HSCALE,1


What is this, another undocumented "feature" of Rigol? Where did you find that command?

[ankerwolf]

Hello Karel,

What is this, another undocumented "feature" of Rigol?

Yes, look here:
https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg731215/?topicseen#msg731215

LG Wolfgang

[Mechatrommer]

havent read all pages, maybe this is a repeat anyway... nothing special just some UI brought from less buggy and enjoyfull DS1052E series, i dont ask for new features, just expecting the same or better performance as what i used to (older DS1052E), namely:

1) encoders for intensity, channel position, horizontal time position, and trigger level (the four smaller knobs at the top of two bigger knobs)... the new DS1054Z knobs respond are very slow, with exception to intensity knob when used to select sub menu which is overly sensitive (super fast). the older DS1052E smaller knobs respond and speed all are about perfect, not too fast not too slow. i dont know why the later programmer want to reinvent the new speed rate from better to worse.

2) clipped signals should not be visible, just as older DS1052E, instead of confusing ceiling or bottomed horizontal (clipped) line. again, why reinvent from better to worse?

3) when we set horizontal time far from center, or trigger level far up or down... and then we set time div or V/div to smaller value, making time offset or trigger level goes out of bound, and then the scope will reset the time offset and trigger level to smaller magnitude, when we restore our previous time/div and V/div, time offset and trigger level is not what it was... older DS1052E does not exhibit this symptom, it remembers the larger offset and trigger level set by user earlier. this new DS1054Z cannot remember it (reset to nearly zero), maybe too much memory all 24Meg are used up for data capture, no space for user settings

still new with this ver 4.03 DS1054Z (modded to DS1104Z already), will search for another bugs, hopefully not much...

[Mechatrommer]

some confusion or WTF moment during an attempt to transfer data from ds1000z to my pc... i thought the label at the top is memory depth for 1 channel since enabling the other channel will half the memory, so i thought they must be shared (600 for one, 600 for the other), but it turned out to be even worst (at data dso->pc transfer at least)... rigol, cant you capture 600 pts per channel? so i can have 1.2Kpts memory for both ch1 and ch2 shared? maybe this involve hardware limitation but i'm not sure, i'm just confused with the top memory depth label... and with this shared-half-the-memory, i cant even get the whole screen capture for every channel at this particular setting (during stop mode, pictures below) ..

and this expose a really serious issue, because from extrapolation of the concept, maximum memory usage is not shared, but half-the-half like the following table: this i guess will affect decoding recording depth as well... and max no of points the off-(pc)-processing FFT can be done when multiple channels are activated...

1 channel visible: 24Mpts capture per channel
2 channel visible: 6Mpts capture per channel (12Mpts / 2)
3 channel visible: 2Mpts capture per channel (6Mpts / 3)
4 channel visible: 1.5Mpts capture per channel (6Mpts / 4)

at 4 channels visible, 24 - 6 = 18Mpts of memory are useless... how can such a design?

[ebastler]

some confusion or WTF moment during an attempt to transfer data from ds1000z to my pc... i thought the label at the top is memory depth for 1 channel since enabling the other channel will half the memory, so i thought they must be shared (600 for one, 600 for the other), but it turned out to be even worst (at data dso->pc transfer at least)... rigol, cant you capture 600 pts per channel? so i can have 1.2Kpts memory for both ch1 and ch2 shared? maybe this involve hardware limitation but i'm not sure, i'm just confused with the top memory depth label... and with this shared-half-the-memory, i cant even get the whole screen capture for every channel at this particular setting (during stop mode, pictures below) ..

It seems that in your second attempt (with two channels enabled), you only transferred the first half of the trace on the scope screen to the PC. My guess is that the scope does indeed use 600 points per channel, as advertised. But it transfers both channels in an interleaved way. So you need to transfer 1200 data points to the PC and will have both traces complete.

Could you give that a try? I think your interpretation, and the extrapolation to a "really serious issue", may be incorrect here.

[Karel]

1 channel visible: 24Mpts capture per channel
2 channel visible: 6Mpts capture per channel (12Mpts / 2)
3 channel visible: 2Mpts capture per channel (6Mpts / 3)
4 channel visible: 1.5Mpts capture per channel (6Mpts / 4)

Nope, it's like how it's written in the manual:

1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

[Mechatrommer]

It seems that in your second attempt (with two channels enabled), you only transferred the first half of the trace on the scope screen to the PC. My guess is that the scope does indeed use 600 points per channel, as advertised. But it transfers both channels in an interleaved way. So you need to transfer 1200 data points to the PC and will have both traces complete.
Could you give that a try?

i tried that before making the post. i requested available buffer size by using :wav:preamble, returned 600... to avoid frustration and "just maybe" situation, i requested position 601-1200 manually, errk failed, dso returned zero byte...

Nope, it's like how it's written in the manual:
1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

maybe thats what happening in the scope. but what is transferred to pc is like my post. i'll try again better code to ensure it is not just an extrapolation... i hope you are right..

[Mechatrommer]

1 channel visible: 24Mpts capture per channel
2 channel visible: 6Mpts capture per channel (12Mpts / 2)
3 channel visible: 2Mpts capture per channel (6Mpts / 3)
4 channel visible: 1.5Mpts capture per channel (6Mpts / 4)

Nope, it's like how it's written in the manual:
1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

wait a minute. that is not how its stated... here the exact terms... page 250 or 18-1 (User Guide) page 256 on latest dec 2015 revision also the same..

Analog channel:
standard 12M pts (single-channel),
6M pts (dual-channel),
3M pts (3/4-channel);

optional 24 Mpts (single-channel),
12 Mpts(dual-channel),
6 Mpts (3/4-channel)

it doesnt say "per channel" so it may means like what i mean above..

[Karel]

Nope, it's like how it's written in the manual:
1 channel visible: 24Mpts capture per channel
2 channel visible: 12Mpts capture per channel
3/4 channel(s) visible: 6Mpts capture per channel

maybe thats what happening in the scope. but what is transferred to pc is like my post. i'll try again better code to ensure it is not just an extrapolation... i hope you are right..

If you don't trust Rigol's programming guide, try DSRemote and you will see that it works as described.

[Mechatrommer]

DSRemote? where can i get that? i followed visa programming guide, and that is what i got... i checked on the dso graticule, yes. internal of the dso, its working as your speced, but visa viScanf command sadly returns what is not wanted

[Karel]

DSRemote? where can i get that? i followed visa programming guide, and that is what i got... i checked on the dso graticule, yes. internal of the dso, its working as your speced, but visa viScanf command sadly returns what is not wanted

http://www.teuniz.net/DSRemote/

[Mechatrommer]

that link is the source code, i need Windows executable that can be executed out of the box.

[Karel]

that link is the source code, i need Windows executable that can be executed out of the box.

You don't need to be afraid for Linux. It installs as easy as windows and it comes for free.

So, don't hesitate and try it.

[Mechatrommer]

You don't need to be afraid for Linux. It installs as easy as windows and it comes for free.

linux is not my problem, time is... and furthermore, i need to verify this in windows environment using the provided visa32.dll path...

[Mechatrommer]

hi again, today i retried the bug after dicking around a while with my scope... https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg861267/#msg861267 ... and to my surprise the bug disappeared, i can get the right 600pts ch1 data now while ch2 is active, no interleaved spagetthy bullshit anymore. so i played reboot, download the scope several times, sometime i can reproduce the bug, sometime i can get the scope correct, when its correct, it seems to be correct forever now. i believe it has something with trigger state of the scope. i pretty believe this is intermittent bug, maybe i should get rid of asking the scope goes into "NORMAL" trigger mode and then goes to "SINGLE" and wait until the scope triggered ie "STOP" mode. i'll leave my earlier report as is in case rigol people watching and take this case into consideration.

[Mechatrommer]

and then it reveals another bug. i downloaded both channel 1&2 data that i thought now correct. when i superimpose them, i realized phase shift on ch1 data, its like both of them are not saved/sampled into the internal memory at the same time...ch1 seems to be saved ~120ns earlier... (currently on FW 2.3.11, SW 4.3.2.3 (sp2) BOOT 0.0.1.3)

[miguelvp]

Are you using :WAVeform:XORigin? and :WAVeform:YORigin? on each channel to get the origin time and voltage per waveform?
Also you should query for XINCrement, YINCrement, XREFerence, YREFerence and then depending on the MODE you will need other parameters to make sure you can define the capture correctly.

:WAVeform:PREamble? has all of them combined with extra information as well.

Edit:
But this applies to the channel selected in:
:WAVeform:SOURce

Or do you have another way to get both at the same time? Maybe if you shared your code we can look at what can be wrong.

[Mechatrommer]

:WAVeform:PREamble? has all of them combined with extra information as well.

i dont think it helps. it doesnt have XORigin or XREFerence relative to the other channels. for example XREF ch1 relative to ch2, or another value relative to ch3 etc. for example in my case here, preamble is...

0,1,300,1,2.000000e-09,-3.000000e-07,0,4.281250e-02,0,118          for SOUR:CHAN1 and..
0,1,300,1,2.000000e-09,-3.000000e-07,0,4.230469e-02,-47,120       for SOUR:CHAN2

the difference is in YORi and YREF which is not the above problem (x-axis phase shift) so lets forget Y data. and i dont know what XREF and XORi refering or relative to what? i have -3.000000e-07 XORigin, its -300ns, so i doesnt make sense since time offset in the above picture is 120ns, XREF is useless, its 0. even if i manage to find offset ch1 data in relative to ch2 data. to correctly show them on screen, i have to x-offset either one resulting in... not so nice figure...

[ebastler]

May I suggest that this discussion on troubleshooting the data transfer be moved to a separate thread? Given Karel's repeated statements that he has not experienced any issues in his software, I think it is more likely than not that you are just struggling with the PC programming side, or maybe with unclear specifications of the Rigol side. And in any case, I think the extended troubleshooting discussion is becoming a bit long for this thread, which was meant as a collection of observations and suggestions. It deserves its own thread.

[Mechatrommer]

this thread is about bug wishlist right?

which was meant as a collection of observations and suggestions

i did exactly this, i didnt mean or ask to get it fixed. and then people chime in suggesting noobs solutions. so i chime in again how about someone with a possible fix PM me to ask my source code for peer review? this will be much shorter... i posted here in hope that rigol people can consentrate on this one thread. if i make another thread, it will just dissapear unheard in the middle of the sea...

[ebastler]

this thread is about bug wishlist right?

Yeah, but Rigol's bugs, not your programming bugs. 
(Sorry, couldn't resist...)

[Mechatrommer]

Yeah, but Rigol's bugs, not your programming bugs. 
(Sorry, couldn't resist...)

are you sure? any function calls through visa driver to the dso should be taken cared of by them.. returning bullshit spaghetti or phase shifted data is not suppose to happen in any call sequence, at worst the dso should return 0 byte data.. and fyi, i read through majority of the programming guide, i've done this yesterday, i've done this 5 years ago on my DS1052E.. i hope you have a slight clue about software development...

[alsetalokin4017]

Do these bugs happen using DSRemote on Linux?  I haven't seen them....

[Karel]

and then it reveals another bug.

When I write software, and something isn't working as expected, I always assume that I made an error before pointing
to somebody else. It happened many times to me, that I couldn't find an error in my code till having a look at it again
after a couple of days.

Also, most bugs can be reproduced, at least by a couple of other users with the same device.

[Karel]

There's something strange indeed. I measure a time difference of 100nSec. between the two channels after downloading the data.

The DS1000Z series oscilloscopes contains just one ADC. This means that the four channels are not simultaneously sampled.
Ergo, the horizontal position of channels 2, 3 and 4 are off with 0.25/sf seconds.
But that doesn't explain the difference of 100nS.

[Mechatrommer]

Also, most bugs can be reproduced, at least by a couple of other users with the same device.

1) same code run at 2 different time, produced 2 different output one is correct one is not. the only difference is due to that in the second time, i tinkered the dso earlier. so the code is at fault?

2) its understandable why you cant reproduce my bug because you dont have my code, and i dont ask you to. if you are interested and have the environment then PM me i can give you my code and the exact steps to reproduce it, Windows XP and VB6 is easy to install and use friendly

3) probably your code is not making the call sequence that produce the bug, my code did. so you are on the safe side. its like saying, do it my way, its the only way. fwiw, i havent violated the programming guide and its not been mentioned that, you cant do this you cant do that. if it did, i wouldnt have done that...

[Karel]

I guess you missed my last reply.

[Mechatrommer]

But that doesn't explain the difference of 100nS.

the 120nS is not fixed, its only specific to my earlier case. whatever the exact value is doesnt matter, "time shift" does exist. and the software bugs i reported above, happened during dso trigger state "STOP", either manually pressing "STOP" or "SINGLE" button on the scope, or automated trigger and stop from the SW, but as i said, its intermitent. during running mode and downloading 1200 pts per channel, the time shift is not visible though. so this is not "everytime" scenario...

[Karel]

But that doesn't explain the difference of 100nS.

the 120nS is not fixed, its only specific to my earlier case. whatever the exact value is doesnt matter, "time shift" does exist. and the software bugs i reported above, happened during dso trigger state "STOP", either manually pressing "STOP" or "SINGLE" button on the scope, or automated trigger and stop from the SW, but as i said, its intermitent. during running mode and downloading 1200 pts per channel, the time shift is not visible though. so this is not "everytime" scenario...

I suggest you make a nice bugreport and sent it to Rigol. They don't read this thread.
Let's hope they fix it soon, but knowing Rigol....

[Mechatrommer]

I suggest you make a nice bugreport and sent it to Rigol.

please send me the link i will be happy to copy paste everything here to there.

They don't read this thread.

so there not much use of this thread, only member gathering to show hey i did this bug, can you? yeah i can can too! everybody happy... and i noticed, the Original Post contained several fixed issues in the latest version and havent been updated for months... maybe its time for a new thread for 4.3.2.3.SP2 bugs thread?...

[Karel]

I suggest you make a nice bugreport and sent it to Rigol.

please send me the link i will be happy to copy paste everything here to there.

http://www.rigolna.com/tech-support/

If you don't receive a confirmation with a support ticket number and the name of the assigned engineer,
keep on sending the bug report every 2 or 3 working days.

[Mechatrommer]

thanks, i sent them direct to the link of my post. let them suck arse. the bug description area is too small only suitable to put a topic there. if they take action, good. if not lets think of another brand next time...

[Karel]

thanks, i sent them direct to the link of my post. let them suck arse. the bug description area is too small only suitable to put a topic there. if they take action, good. if not lets think of another brand next time...

The problem is, even if you considder the remote connection unusable, the DS1054Z is still the best bang for buck.

[Mechatrommer]

the DS1054Z is still the best bang for buck.

cant argue anymore. i'm a person who find a way around to make things work and i dont consider the SDK interface as total useless, just a few intermittent problems (bugs).

[kwass]

thanks, i sent them direct to the link of my post. let them suck arse. the bug description area is too small only suitable to put a topic there. if they take action, good. if not lets think of another brand next time...

I've given up maintaining the list at the top of this thread, it's over a year old and they haven't addressed really anything on this list.  I've emailed them links to it several times and I know other people have as well.  Rigol seems totally uninterested in user feedback --- unless it comes from Dave.  I also think that they're only interested in selling hardware not supporting it, so they're probably just moving on to something new and will never release new firmware for this scope.

It (the firmware) was good enough to generate a lot of sales, fixing the firmware probably won't generate any additional sales, so why bother.

[Mechatrommer]

I've given up maintaining the list at the top of this thread, it's over a year old and they haven't addressed really anything on this list.

have you update your firmware to the latest version? i tested some of the list, they are fixed already. then you can remove what are already fixed. and make a neater list for what are not fixed in the latest revision. i suspect they were watching and took action, but they are not telling you nice that they will tackle it...

[Mechatrommer]

here my quick finding after testing a few of your bug list...

1) FIXED (large font setting is retained after reboot)
2) i dont understand what the statement wants. deselecting the checkbos will hide the measurement, probably that what it does.
3) FIXED. FFT works on other channels even if CH1 is off
4) if they fixed this, someone will mourn, measurement got covered by math function, if they move the label to top, someone may mourn the signal got covered, so its hard to satisfy everybody, imho.
5) probably hardware limitation on some unit, i dont experience this. easy workaround... shift the vertical offset until signal is at 0.
6) probably hardware or software limitation. saving bigger file regardless of format, took long time. what do you expect on a $399 scope?
7) havent tried
not fixed.
9) FIXED. see attached
.... not tried
13) i successfully downloaded nongarbage 24M yesterday...

so you see most bugs reported here are fixed, or at least i've not experience them so far...

[Karel]

The "time difference" bug that causes a time shift of +/- 100nSec. between two channels when downloading the deep
memory waveform data, has been reported to Rigol and has been confirmed by Rigol engineers.
No info however when this bug will be fixed.

[alsetalokin4017]

I guess I should post this here....

5 Bugs at once:

[metrologist]

Sorry to go newb on you, but 5 bugsatonce, not sure I can identify them:

1. obvious typo
2. Math trace seems slightly offset. Not sure how the scale works, is it 25V/div, and the math should show 64V?
3. Channel 3 RMS value, but the channel coupling is ground.

The trigger markers do not meet at the same crossing. Is that Delay 210ns?

[alsetalokin4017]

Sorry to go newb on you, but 5 bugsatonce, not sure I can identify them:

1. obvious typo
2. Math trace seems slightly offset. Not sure how the scale works, is it 25V/div, and the math should show 64V?
3. Channel 3 RMS value, but the channel coupling is ground.

The trigger markers do not meet at the same crossing. Is that Delay 210ns?

Heh... 4 are obvious and 1 not.
1. Pluses typo
2. Miscounted pulses
3. RMS value on grounded channel
4. Math horizontal scale-offset error
and, not obvious from the still picture:
5. Measurements are frozen, not updating.

Triggering is correct, shifted 210 ns left from center marker by the horizontal position control, really irrelevant, used just to get a solid number of pulses on-screen. Trigger voltage value and position wrt CH2 trace is correct, no problems there.

Math vertical scale is approximately correct, 100 "units" per division, tops at around 80 units with inputs about 9v x 9v from channels. But Math is _way_ off horizontally.

[metrologist]

Are all math operations off or just certain operations under some conditions? I seem to recall 500ns time scale mentioned, so is that a requirement?

Thanks

[alsetalokin4017]

Are all math operations off or just certain operations under some conditions? I seem to recall 500ns time scale mentioned, so is that a requirement?

Thanks

500 ns/div is a requirement, 3 or 4 channels turned on is a requirement, average acquire mode is required, number of averages not important, 2 will work.
As far as I can tell all numerical Math operations are affected. I have not tried the Decode functions.

[JPortici]

Today i discovered a new problem: I can't save files on usb memories if there is more than 14GB of free space.
I actually wanted to report another bug: the latest saved file wouldn't actually be saved. if i saved two screenshots i would only find the first once i removed the usb key

So i formatted a 16GB kingston usb stick (actually 14.5GB), but this time NOTHING would be saved at all! WTF! Then i digged up an ancient 1GB memory from somewhere else (actually 820MB), it saved every time.
Then i put some random data in the 16GB kingston, around 500MB. I tried again. Now it went back to the original bug.
I suppose the captured data doesn't like to be alone 

Anyway, attached screenshots show that i can get fft to work on CH2 without having CH1 switched on. Assuming the OP is up to date with the bugs...
(ehr pseudorandom noise wasn't the best example but i have a sinewave now and it's working perfectly anyway)

[bitseeker]

Hi JPortici. The maximum supported size is 8 GB. However, there may also be a problem with large file system clusters, even if the overall drive size is OK. See the discussion beginning with my post at https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg782828/#msg782828

[JPortici]

I knew it. Though I don't remember reading anything in the manual about max size*, maybe i skipped something. aw hell at this point i can report that with less than 14 GB of free space the scope will save all files but the last

*I didn't even think about troubleshooting because it was almost working normally, so if it was only referred there i would have missed it.

[bitseeker]

Yeah, I didn't see it in the manual until someone pointed it out. It's not in the most obvious location.

[bap2703]

The "time difference" bug that causes a time shift of +/- 100nSec. between two channels when downloading the deep
memory waveform data, has been reported to Rigol and has been confirmed by Rigol engineers.
No info however when this bug will be fixed.

Hi there,

Any news about a possible bugfix ?
I encountered this issue before seeing that it is a (not well) known bug : chan1 is always phase shifted when reading the full memory. I haven't investigated if there is a particular relationship that can help predict this shift.

Example with chan1&2 hooked to the probe compensation signal.

As seen on the scope:

Everything fine here

As retrieved on a computer:

If you pay attention the shift can already be noticed at both ends of the chan1 waveform.

As retrieved on a computer, zoomed at the point of trigger:

The scope triggers at 50% of channel 1's amplitude. As it was horizontally centered it should it should be at the point 3000 like the blue trace (6K points acquired per channel).

An interesting feature not shown on this example due to the waveform shape is that the extra data causing the phase shift at the beginning is really extra data : these points are not just the end of the acquisition mispositioned at the beginning. (assuming the X axis is not distorted)
And since the signal is correctly displayed on the scope itself it means that the scope actually has both:

• points end of the trace used to display on the scope
• extra points at the beginning displayed when retrieving on a computer

This is also true when using the "maximum" sample size.
That would mean the scope acquires and stores more than 24M samples. It would be great to be able to use that :p

[bitseeker]

In another thread, a vendor in Australia was told by Rigol that a firmware update for the 1000Z was coming in July. So, in the pretty near future we'll see what all gets fixed.

Edit: Added link to reference.

[Dwaine]

Does anyone have any beta firmware that will be the July firmware release?   Some early testing?

[bitseeker]

Nope. They don't work like that that I've ever seen. We'll all get it when it's released and then discover things.

[alsetalokin4017]

I may not be among the very first to adopt the new firmware!  I think I'll "wait and see" if anybody else finds some major buzzkills before I install it into my scope.

Does anyone have any beta firmware that will be the July firmware release?   Some early testing?

Surely you jest. We will all get to "beta test" the new firmware when it is released.

Remember the old advice never to rely on software versions that began with "0.something"?   

[Fungus]

I may not be among the very first to adopt the new firmware!  I think I'll "wait and see" if anybody else finds some major buzzkills before I install it into my scope.

No worries. This will be The One.

[alsetalokin4017]

I may not be among the very first to adopt the new firmware!  I think I'll "wait and see" if anybody else finds some major buzzkills before I install it into my scope.

No worries. This will be The One.

Good. Then of course you will immediately install it when it is available, you will test all the scope's functions (even the ones you don't need yourself) and give us a nice thorough report. Won't you?

Like you did with the last firmware update?   No.... wait.... 

[Fungus]

Good. Then of course you will immediately install it when it is available, you will test all the scope's functions (even the ones you don't need yourself) and give us a nice thorough report. Won't you?

Like you did with the last firmware update?   No.... wait....

What's this? Personal attacks in multiple threads? 

[Marcos]

When he's telling you the truth you consider that "personal attacks" ?
Fungus mate, why do you always expect to see only great references for your "beloved" Rigol Scope?
Are they paying you for this?

[Fungus]

When he's telling you the truth you consider that "personal attacks" ?

What "truth" was there in his post. As far as I can tell there wasn't a single factual statement that could be tested. It was all speculation and opinion and all directed personally at someone (me, in this case).

Fungus mate, why do you always expect to see only great references for your "beloved" Rigol Scope?

I don't.

This thread is a place for listing Rigol bugs, discussing shortcomings, etc., right? Do you see me posting in here trying to defend the DS1054Z? Nope. I've even posted a few complaints myself.

Do I go into threads which were specifically started to discuss Rigol bugs and try to defend it or start attacking people for being mean? Nope.

Do I call out the handful of people who try to derail every single thread that mentions a DS1054Z by "Rigol Bashing". Yep, guilty (raises hand).

[Gabri74]

Maybe I've found a new bug in the measure/statistic function   

- 2 channels on with width measurement
- statistics on
- 1st channel is connected to a debug pin to measure max/min duration
  of a touchscreen IRQ event callback on a MCU
- Normal duration is around 650ns, when finger pressed it should vary from 650ns to about 6us

This is what happens:

- pic 1, finger not pressed, you can see on the display 2 alternating width, one of ~650ns and one of 1.8us
Measure statistic is already wrong, because it takes into account minimum value only
- pic 2, finger pressed. Now we have a series of different duration pulses, from 650ns to 1.8us. Statistic max/average are wrong
- pic 3, acqusition stopped... still wrong
- pig 4, waveform moved with horizontal knob, statistic updated with 1.8us value (but now min/avg are wrong, but I guess that's ok in stop mode)

 

Any toughs ?

[Fungus]

Any toughs ?

They all look OK to me. The gap in the 0V baseline is measured correctly in every picture.

I suspect that if you want "average" to mean anything then you'll need more than one baseline-gap visible on screen.

[Gabri74]

I suspect that if you want "average" to mean anything then you'll need more than one baseline-gap visible on screen.

Thanks for your replay.
So, If I understand correctly, the statistics only works on the displayed data for ONE trigger event? I.e. Id does not
accumulate measures from multiple trigger events ?   
Looking through the manual now...

[Fungus]

So, If I understand correctly, the statistics only works on the displayed data for ONE trigger event? I.e. Id does not
accumulate measures from multiple trigger events ?   

I think it works from what's visible on screen.

On your screendumps there's only one place where the signal isn't ambiguous. That's what it measures.

[alsetalokin4017]

I suspect that if you want "average" to mean anything then you'll need more than one baseline-gap visible on screen.

Thanks for your replay.
So, If I understand correctly, the statistics only works on the displayed data for ONE trigger event? I.e. Id does not
accumulate measures from multiple trigger events ?   
Looking through the manual now...

No, that's not right. For this particular "average" shown in the Statistics measurement, the scope is taking the average, max, min, std dev, of consecutive samples of the screen data, which occur at around 3 times per second or so, more or less, depending on how much other stuff is going on. That is, yes, it does accumulate measures from multiple trigger events, or rather screen updates. It is still working on the data displayed on screen though.  This is different from selecting an "average" from the left-hand Measurements menu, where you get an average across several cycles of a waveform displayed on screen during one screen update.  So you can even use the Statistics display to get the average, max, min, std.dev.  of "Average" measurements from the left-hand menu.

[Gabri74]

the scope is taking the average, max, min, std dev, of consecutive samples of the screen data, which occur at around 3 times per second or so, more or less, depending on how much other stuff is going on

Thanks for your replies. So ultimately statistics are useful for slow changing signals or signals with a low std dev.
If I need to characterize a pseudo-randomly variable signal in terms of min/max/avg value they are not to be trusted   

[borjam]

New firmware version!

http://int.rigol.com/Support/SoftDownload/3

Code: [Select]

[Supported Model]    All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date]  2016/05/31

[Updated Contents]
--------------------
v00.04.04.00.07  2016/07/19
     - Added the full-screen display in the XY mode
     - Modified the Trace data of average sample mode
     - Fixed the bug of system halted for wave persistance in the Zoom mode
     - Fixed bugs about Measure


Now. Who dares?

 

[bitseeker]

Good one, borjam!

Well, I hope they fixed more than they documented in that release note. But I shall be patient and see what the more adventurous forum members report about this new version. I'll stay on SP1 for now.

[Mechatrommer]

installed. XY and FFT can viewed as fullscreen now (FFT ovelapped with CH display, but XY mode no CH view overlapping, not the best thing), FFT in memory mode can halt signal display, i need to change timescale, press buttons etc to get it running again, few second stopped again, this is repeatable behaviour, but i guess when i set memory length to max 6M, when set to auto seems fine (no halt, but still slow). "pluses" typo is still there so i guess this is a "during the non busy week" rigol project "in the lab" after so many months.

[bitseeker]

When you set memory depth to auto, is it using a lot less than 6M?

[Roeland_R]

installed. XY and FFT can viewed as fullscreen now (FFT ovelapped with CH display, but XY mode no CH view overlapping, not the best thing), FFT in memory mode can halt signal display, i need to change timescale, press buttons etc to get it running again, few second stopped again, this is repeatable behaviour, but i guess when i set memory length to max 6M, when set to auto seems fine (no halt, but still slow). "pluses" typo is still there so i guess this is a "during the non busy week" rigol project "in the lab" after so many months.

Is it possible to go back to an older firmware now ?

[Mechatrommer]

Is it possible to go back to an older firmware now ?

according to the mainstream... no. and why should i? the rotary knobs perform poorly now, and they performed poorly before. (hint: press stop before adjusting knobs to proper positions for better performance) but i do find myself reaching all channels more and more now, thats all i care most.

When you set memory depth to auto, is it using a lot less than 6M?

no difference to FFT appearance and performance. it seems FFT has its own wisdom at selecting memory depth. its just when i set to 6M, FFT got halted, not in Auto Mem Length. and "Memory" mode FFT performs poorly now, just as before, if not a bit slower. no worry i have my VisaDSO if i need full memory length FFT. for now FFT is not my game.

[bitseeker]

OK. Guess I'll check out VisaDSO at some point. The only FFT use I'm considering in the short term is to adjust my analog function generator. There's a pot to set minimum distortion on the sine output. I can't see buying a spectrum analyzer just for that.

[Karel]

Unfortunately, the time-difference bug as described here:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

and which was reported to and confirmed by Rigol on March 1th, has not been solved with the latest fw 00.04.04

So, downloaded deep waveform data is still defect...

[RoGeorge]

I guess I should post this here....

5 Bugs at once:

Software Version: 00.04.04.SP1 (== 00.04.04.01.01), Board Version: 0.1.1

[Supported Model]    All the MSO/DS1000Z Series Digital Oscilloscopes
[Latest Revision Date]  2016/09/14

[Updated Contents]
--------------------
v00.04.04.01.01  2016/09/14
     - Supported the multi-inteface of LXI
     - Fixed bugs about Measure

Generator was set at 1.5MHz square, 9Vpp, 4.5Vdc offset.

Seems to be working good enough. Could not reproduce any of the five bugs.
 

LATER EDIT:
Well, except the Pluses instead of Pulses, of course

[RoGeorge]

If CH3 is on DC or AC instead of GND, then the Rms=130..140mV.
Rms=334mV could be debatable, but could also be just noise and op amp offset (+/- 1 ADC count at 10V/div).

[2N3055]

If CH3 is on DC or AC instead of GND, then the Rms=130..140mV.
Rms=334mV could be debatable, but could also be just noise and op amp offset (+/- 1 ADC count at 10V/div).

It is noise and offset... 10V/DIV is 80V full scale, divided by 0.334 is something about 240.... that is 8 Bit ADC  basically running at ENOB 7.9 .. Not bad actually.. and because of DC offset, it is different between DC and AC coupling..

[RoGeorge]

Unfortunately, the time-difference bug as described here:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

and which was reported to and confirmed by Rigol on March 1th, has not been solved with the latest fw 00.04.04

So, downloaded deep waveform data is still defect...

I was looking at the data points within the screen, and I could not reproduce this bug with FW 00.04.04.01.01 (SP1)

Could somebody please help me with some details, in order to reproduce the bug?
- What scope settings must be used(other then the ones that can be seen in the pic)?
- How many data points were extracted?
- At what point(s) can be seen the time difference?
- The data points were retrieved in ASC or Byte mode?
- What SCPI commands were sent in order to retrieve the data points?

[2N3055]

That bug was reported by someone and it was not something you can see on the scope.. It was related to data downloaded to PC..
As far as I know, nobody reproduced it, it was specific set of doing something to scope together with his own software that he wrote...

[RoGeorge]

Indeed, in the PC extracted points I couldn't reproduce any time shift between channels bug.

Since the first scope screen capture from the bug description shows a "T'D" in the upper left corner, I guess the data was extracted with the scope in the running mode. In running mode, only 1200 points can be saved to PC (the same as the ones from the display). So I saved first 1200 points from channel 1 and 2, then chart them in a spreadsheet. The points from the 2 channels are well aligned in time.

What I don't understand is why each data point value seems to be repeated?

I mean, for the same channel, let's say CHAN1, each second sample seems to have the same value with the previous one. It can be clearly seen from the chart that consecutive points always comes in pairs of the same value (same level). I will look into this one later. Just in case someone else want to reproduce the 'pairs', I did:

nc 192.168.1.3 5555

wav:form asc
wav:star 1
wav:stop 1200
wav:sour chan1
wav:data?

wav:sour chan2
wav:data?

then plot the CSV data.

[rstofer]

There are only 800 horizontal dots on the screen yet the data comes back as 1200 points.  I could see doubles if the dataset was twice the screen size but that doesn't appear to be the case.  Sooner or later it is going to come down to the resolution.

[RoGeorge]

Thanks for mentioning the 800 horizontal resolution.

So why 1200? I'm not sure yet. The only mention I found as a reason for the number 1200 is related with the MATH channel:

The source selected is equally divided into 1200 parts horizontally

One more thing to mention: If the Acquire -> Mem Depth is left on Auto, the scope will choose 500MSa/s and only 600 pts, which is very low and also is half of the number 1200 - that might be related with the pairs of values seen in the extracted data points.

I need to do more experiments before drawing any conclusions.

[rf-loop]

There are only 800 horizontal dots on the screen yet the data comes back as 1200 points.  I could see doubles if the dataset was twice the screen size but that doesn't appear to be the case.  Sooner or later it is going to come down to the resolution.

In this scope visible part of trace lenght is 600 points on the screen, not 800. 12 div 50 pts/div

[Karel]

Indeed, in the PC extracted points I couldn't reproduce any time shift between channels bug.

Since the first scope screen capture from the bug description shows a "T'D" in the upper left corner, I guess the data was extracted with the scope in the running mode. In running mode, only 1200 points can be saved to PC (the same as the ones from the display). So I saved first 1200 points from channel 1 and 2, then chart them in a spreadsheet. The points from the 2 channels are well aligned in time.

Use DSRemote to download the deep memory waveformdata (12 or 24 mpts) and you'll see clearly the bug.
At least, I can reproduce it here with sw version 00.04.04.SP1 and board version 0.1.1.
The bug is also confirmed by Rigol.

[Karel]

Unfortunately, the time-difference bug as described here:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

and which was reported to and confirmed by Rigol on March 1th, has not been solved with the latest fw 00.04.04

So, downloaded deep waveform data is still defect...

I was looking at the data points within the screen, and I could not reproduce this bug with FW 00.04.04.01.01 (SP1)

Could somebody please help me with some details, in order to reproduce the bug?
- What scope settings must be used(other then the ones that can be seen in the pic)?
- How many data points were extracted?
- At what point(s) can be seen the time difference?
- The data points were retrieved in ASC or Byte mode?
- What SCPI commands were sent in order to retrieve the data points?

Code: [Select]

tmc_lan write: :STOP
tmc_lan write: :WAV:MODE RAW
tmc_lan write: :WAV:YINC?
tmc_lan write: :WAV:YREF?
tmc_lan write: :WAV:YOR?
tmc_lan write: :WAV:STAR 1
tmc_lan write: :WAV:STOP 250000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 250000 bytes
tmc_lan write: :WAV:STAR 250001
tmc_lan write: :WAV:STOP 500000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 500000 bytes
tmc_lan write: :WAV:STAR 500001
tmc_lan write: :WAV:STOP 750000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 750000 bytes
tmc_lan write: :WAV:STAR 750001
tmc_lan write: :WAV:STOP 1000000
tmc_lan write: :WAV:DATA?
received 250000 bytes, total 1000000 bytes
tmc_lan write: :WAV:STAR 1000001
tmc_lan write: :WAV:STOP 1200000
tmc_lan write: :WAV:DATA?
received 200000 bytes, total 1200000 bytes


[rstofer]

There are only 800 horizontal dots on the screen yet the data comes back as 1200 points.  I could see doubles if the dataset was twice the screen size but that doesn't appear to be the case.  Sooner or later it is going to come down to the resolution.

In this scope visible part of trace lenght is 600 points on the screen, not 800. 12 div 50 pts/div

That's the problem with datasheets.  The datasheet for the family of scopes clearly states 800x480
http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0504/1/-/-/-/-/MSO1000Z_Datasheet.pdf
See page 8:

Display Resolution 800 horizontal × RGB × 480 vertical pixel

But if it is really 600, then 1200 points is exactly 600 pairs.

That this datasheet is applicable to the DS1054Z is shown on page 1

[ruffy91]

The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.

[bitseeker]

The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.

Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.

[rf-loop]

The resolution of the LCD is 800 horizontal, but the waveform doesn't span the whole width. There is the menu on the right side.

Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.

Also higher models do not give full screen width trace when menu is off.
Attached Rigol DS6000 menu off and menu on.
Display TFT resolution 800x480

Menu Off trace lenght is 700  ( 14 div) and menu On trace lenght looks like around 642 (bit under 13 div)
Example in Siglent (SDS1000X and 2000X) trace lenght is 700. (TFT800x480  and 14 div) (with menu, and it is always on)

This is normal in digital oscilloscopes, take R&S, Keysight, Siglent, LeCroy, Owon, Tektronix, GW or what ever. More or less under TFT horizontal resolution. With menu or without. Show me scope what give full TFT horizontal amount of pixels for trace
There is nothing wrong in this thing in DS1000Z. Just normal.
But, why 1200 data points looks like there is always 2 data points exactly same without exceptions. What "secret" is behind this.

But example if we go to Spectrum analyzers. Many times there data sheets told also trace lenght (data points).
Example Rigol DSA1000, full screen: displayed data points 751, normal 600   (TFT 800x480  8.5")
Example Siglent SSA3000X,  1024×600(waveform area 751×501), 10.1"
Example Keysight N9320B, Sweep point 461, fixed. (TFT 640x480  6.5")

Rigol DS6000

[bitseeker]

Exactly. Unlike the higher-end Rigol models, the onscreen menus can't be hidden, so you don't get the full screen width for trace data.

Also higher models do not give full screen width trace when menu is off.
Attached Rigol DS6000 menu off and menu on.
Display TFT resolution 800x480

Menu Off trace lenght is 700  ( 14 div) and menu On trace lenght looks like around 642 (bit under 13 div)
Example in Siglent (SDS1000X and 2000X) trace lenght is 700. (TFT800x480  and 14 div) (with menu, and it is always on)

Sorry, didn't mean literally "full screen" as in all 800 pixels, just more than with the menus showing.

[BEM]

Hi,

This is my first post.

I have a 1054z. The history graph is such a cool feature, that I wished the scope had before I discovered it, BUT I dearly wish it could go full-screen just like the FFT function can, with a grid.

[I am writing a sinusidal smooth stepper program, and I am going to use it to plot the actual step frequency/period over a course of steps. Also for speaker testing it would be useful, though it's currently small with limited resolution.]

Thanks for your consideration,
BEM

[BEM]

I found a change I would like to make: It's interesting that the user adds measurements on the left menu, and attempts to delete them on the right menu, but it should be changed.

What would be so wrong with selecting the same item you added again, to delete them?

[BEM]

Saddly, I just tried the 1054z history function. Apparently, it only works from the screen buffer. It appears useless for my application. 

That's all I wanted to do is get a period graph over time of sampled pulses and waits, for a stepper driver, but it can't do it 

[JPortici]

I found a change I would like to make: It's interesting that the user adds measurements on the left menu, and attempts to delete them on the right menu, but it should be changed.

What would be so wrong with selecting the same item you added again, to delete them?

if in the meantime you change the channel and you press onthe measurement button you won't delete the one you want but rather add a new one.
the real bug/feature miss is that they are still. not. deleted. at. all. only "hidden"

[garnix]

if in the meantime you change the channel and you press onthe measurement button you won't delete the one you want but rather add a new one.
the real bug/feature miss is that they are still. not. deleted. at. all. only "hidden"

Sure, but then you just tap it again and it would be gone - then switch channel and tap on the correct one... much much easier than always change to Measure tab on the right side and hang through the menus... They could even indicate on the left-side buttons if measurement is active e.g. by displaying the button in a highlighted state - or even better: display the actual value inside the button.

And agree, this "hidding" feature is crazy.

But what I use most: Long-Press the Measure button - then all measurements are gone. Then add new ones from the left.

[TheoB]

I reported a bug for the DS1054z at Rigol. At least I think it is a bug. The math-filter functions seems to not work at the entered frequencies (lowpass/highpass/bandpass/notch). As an example I want to filter 1kHz and set the lower limit to 750Hz and the higher limit to 1250Hz. I then get a bandpass filter around 500Hz . Same with low pass. If I specify 20kHz then I find the low pass edge (-3dB) roughly around 8.9kHz.
I don't run the latest version of the firmware (00.04.03.SP2) but I have also not found anyone reporting this. So I prefer not to update (yet).
To repeat (with a 1kHz sine at the input):

Code: [Select]

$ cat filter_bandpass.scpi
:TIMebase:MAIN:SCALe 0.002
:MATH:OPERATOR FILTER
:MATH:FILTer:TYPE BPASS
:MATH:FILTer:W1 750
:MATH:FILTer:W2 1250
:MATH:DISPlay ON
cat filter_bandpass.scpi > /dev/usbtmc


[MrWolf]

Some stuff I discovered about my new measurement instrument from Rigol:

Feature:

If you have both LAN and USB cable connected and set USB Device to "PictBridge" you do not have to disconnect USB to use LAN.

Bug:

Frequency Counter

Attached page from manual: "DS1000Z_UserGuide_EN__page_145.pdf"

Quote: "The hardware frequency counter supplied with this oscilloscope can make
more precise measurement of the input signal frequency."

Bug: It was enabled on CH1, CH2 was active (500MS/s). Turned on CH3, CH4. Sample rate dropped to 250MS/s. Counter failed to display correct freq. Some investigation showed thresold at >=30MHz. But later I failed to reproduce this. Instead reproduced similar problem, look "DS1104Z_100MHz_5ns_250MS.png". Counter was enabled on CH2, CH1 was active (500MS/s). Turned on CH3, CH4. Sample rate dropped to 250MS/s. Counter failed to display correct freq.

Software counter managed to do a better job overall but still fails, despite average mode being enabled and waveform being steady.

"DS1104Z_100MHz_5ns_500MS.png" shows exact same situation at 500MS/s. All counters work ok.

Conclusion: Counter(s) should considered non-functional when scope is in 250MS/s mode.

Edit: On some days it's in the mood and works. Currently cannot find a pattern.
Found the pattern: It is function(vertical scale, signal level, signal frequency, sampling rate)

Tests conducted using 10x probe connected directly to Siglent SDG2000X gen output
via probe adapter. Output in HiZ mode.

Test 1:

Test signal: 1MHz sine
Signal applied: CH1
Counter enabled: CH1
Vertical scale = 500mV/d
Timebase = 500ns/d

Counter failure mode 1-1:
CH1=ON, CH2-4=OFF, 1GS/s
Signal amplitude: <=250mVpp

Counter failure mode 1-2:
CH1-2=ON, CH3-4=OFF, 500MS/s
Signal amplitude: <=250mVpp

Counter failure mode 1-3:
CH1-3=ON, CH4=OFF, 250MS/s
Signal amplitude: <=400350mVpp

Test 2:

Test signal: 100MHz sine
Applied: CH1
Counter enabled: CH1
Vertical scale = 500mV/d
Timebase = 5ns/d

Counter failure mode 2-1:
CH1=ON, CH2-4=OFF, 1GS/s
Signal amplitude: <=1.21Vpp

Counter failure mode 2-2:
CH1-2=ON, CH3-4=OFF, 500MS/s
Signal amplitude: <=1.31.4Vpp

Counter failure mode 2-3:
CH1-3=ON, CH4=OFF, 250MS/s
Signal amplitude: <=1.81.2Vpp

Possible solution: counter value display disabled  based on
function(vertical scale, signal level, signal frequency, sampling rate)

[MrWolf]

In the second post let's discover territory that is seemingly beyond measure for Rigol DS1000Z:

Phase and Delay

Let's look at user guide page 141 (6-63) "DS1000Z_UserGuide_EN__page_141.pdf"
Seems to be straight forward stuff...
So I did this:

10MHz sines, 180 degrees phase, 500MS/s.

Hardware counter: ok
Software counter: ok
Period: ok
Graph: ok (checked by cursors)

Delay: insane
Phase: ludicrous

As manual says it first does period (and gets it right!), then it does delay and gets it insanely wrong. Based on that it does some ludicrous phase calc. Also the more waves are on the screen at the same time the more awkward it goes. On the normal scope it is the other way around - more data - more precision.

It cant be that bad and I must doing something wrong?   

Edit: Found sort of workaround. If you go [Measure] => Range,  Change "Region" from Screen to Cursor and fiddle around with cursors there may appear some more-less valid data. BUT as soon as you leave cursors alone they disappear and there is no indication what range is used for data. They must stay on screen in some form or the feature is basically unusable. Screenshot attached from brief moment where cursors are still visible. They are not visible even if you just go to the menu. Only way they appear if you actually move them. Mysterious position number seems to be pixels Someone has been hacking like there is no tomorrow... It reminds me time when I was a kid and programmed well working Tetris game that used actual screen memory on PC XT computer and no separate array Se when little block did fall it actually asked screen memory: Hello, is there anyting on my way...  And it worked!

[MrWolf]

As a possible hint to developers I'll show how phase data done on another scope that is up to 4x cheaper than cheapest DS1000Z, but gets proper software:

Tests:
25MHz, 100ns timebase, 100MS/s - to show how proper sin(x)/x OFF should look like
25MHz, 5ns timebase, 4GS/s (ETS) - to show how proper averaging works
2.5MHz, 1us timebase, 100MS/s - interesting to see how phase math function settles down

What can be seen on these test:

- if it does not know, it does not show! In ETS mode math is OFF because
ETS graph can be uncertain (line gets "thick" - not seen in provided example)

- it does not have built in phase function (probably because it's sort of complex
subject and depends on many variables). Instead one can do math that fits the situation,
for example I have this set as Phase(A,B) measurement:

acos(integral(A*B)/(sqrt(integral(A*A))*sqrt(integral(B*B))))/Pi*180

- it does have special "phase cursors" in addition to regular ones, find these
very helpful

- it does have actual zoom feature that makes placing the cursors very easy,
in DS1000Z you basically need magnifying glass to work with cursors
on smallest timebase & 100MHz

- using ETS and cursors one can get very precise phase data for steady wfm

- Phase(A,B) math works well in non-ETS mode

- sin(x)/x honestly turns off

[Ducttape]

My vote/wish item is for the ability to connect a USB keyboard that could duplicate the functionality of the multifunction knob and, of course, input characters without having to use that carnival game otherwise known as the on-screen keyboard.

Auto fan speed control would be nice to reduce noise.

[metrologist]

Phase and Delay

Anyone else looked into this? Does averaging affect this measurement, and is it possibly this region of phase shift? If I understand correctly, I should be able to duplicate the test with an ~1.3m coaxial delay line and 100 MHz source.

[MrWolf]

Anyone else looked into this? Does averaging affect this measurement, and is it possibly this region of phase shift? If I understand correctly, I should be able to duplicate the test with an ~1.3m coaxial delay line and 100 MHz source.

Actually you do not need 100MHz, it does not matter at all what the frequency is.
All you need is 2 waves on the screen.
This is because some ultimate HaXX0r has done it basically this way:
- let's first print the wave on the screen (and have some matrix representing screen pixels)
- now we have some set of data-pixels that is 602 pixels wide
- lets haxx0nalyze these pixels until    and rising/falling edges are "found"
- then lets apply some kickass low bit integer math (its fast!) and spit the out

In original example signal is 10MHz.
On "solution" picture with cursors it is 100MHz.
And now I did additional pic at only 10kHz (attached).

As you can see precision sort of improves regaring
"Cur" values but signs are all over the place and "Avg" values
are as mad as ever.

Turning Averaging, Sin(x)/x, Mem depth to various values
does not change anything. Also 500MS/s vs 250MS/s do
not matter.

So currently I stick to my theory it's done 12yo HaXX0r style
on some pixel matrix basically off the screen...
Processing power savings are huge compared to analyzing
actual data points 

Edit: Again attached pic how it's done on another scope with 100€ starting price,
but with software from actual engineers. Signal generated also by
properly engineered gen. Note the deviations are in ns and mHz range!
Phase by cursors has absolute accuracy since I can zoom into picoseconds if needed.
Calculated phase is by 2 degrees off but it's just a dumb math function
that cannot account for boundary effects. Would be easy to avoid in
actual software.
Actually I'm dumb, not math... My terminators suck. There is very small phase
difference. Both scopes pick it up from noise floor in A + B. Images
attached.

Dunno maybe in bashing poor Rigol to much but this is how I'm gonna get
even with my 400EUR. Could take it back to shop no prob. But not gonna
do it. I'm gonna hope that this will be fixed instead and someone is gonna learn
how to do stuff properly.

[metrologist]

I notice the Rigol counter does not seem to have having a problem measuring 10 kHz with 250 MS/s in your follow-up screen shot.

What happens if you shift your second source offset so it is out of the phase noise differential? I'm just wondering how the algorithm would determine if a signal is +180+ or -180- degrees.

What I mean, is it correct +180.01 degrees or -179.99 degrees?

[MrWolf]

I notice the Rigol counter does not seem to have having a problem measuring 10 kHz with 250 MS/s in your follow-up screen shot.

Indeed. Today its in the mood... 
Pattern found. Look original post.

What I mean, is it correct +180.01 degrees or -179.99 degrees?

Very metrological remark  180' phase shift is indeed bad case to test against.
But this does not get  Z off the hook. New findings:

- you do not have to own 1+n channel generator to test this stuff! Just feed same signal to all channels you want and make phase shifts using Delay-Cal in channel menu. It cross-checked against real signal and it seems to match. Sadly Delay-Cal is enabled only on 5us or faster timebase.

- workaround to using magnifying glass with cursors is to use [Cursor]=>Mode=>Track and set Cursors A and B to different channels. Then is easy to search for zero crossings. BUT there are only 2 cursors to work with and it is a 4 channel scope... Also it seems that Delay and Phase are also available on 2 channels only.

- look attached image. Here is no 180' excuse for erroneous reading this time.

Overall I think that this  box will not get AI anytime soon. Maybe these haxx0magical measurements should be just disabled... And instead there should be possibility add multiple cross-channel Tracking cursor pairs. For example if there would be up to 4 pairs of cursors... Cursor A-1 is  locked to channel A and gets according color. Cursor A-2 can be locked to any channel, but has same color as A-1. Cursor B-1 is locked to channel B and so on...
Exact identification scheme may vary. Anyway with 4x2 cursors lots of stuff could get done 

[MrWolf]

Tracking cursors idea illustrated.

[Karel]

Another bug:

Code: [Select]

usb 1-2: new high-speed USB device number 4 using ehci-pci
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
usb 1-2: New USB device found, idVendor=1ab1, idProduct=04ce
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: DS1000Z Series
usb 1-2: Manufacturer: Rigol Technologies.
usb 1-2: SerialNumber: DS1ZA17040xxxx
usbcore: registered new interface driver usbtmc

A bulk endpoint in a high-speed device MUST have a max packet size of 512.

[metrologist]

MrWolf, I could not duplicate any of the issues you reported here. I used a 100 MHz osc and split the signal via BNC T, with various coax lengths to each of 3 channel inputs - 4th channel On without input, and observed proper delay and phase measurements. The frequency counter worked fine for me too.

Karel, where do you see this bug?

[Karel]

Karel, where do you see this bug?

On my computer after connecting the scope to an usb port.
I open a console and type "dmesg".

[Dwaine]

MrWolf, I could not duplicate any of the issues you reported here. I used a 100 MHz osc and split the signal via BNC T, with various coax lengths to each of 3 channel inputs - 4th channel On without input, and observed proper delay and phase measurements. The frequency counter worked fine for me too.

Karel, where do you see this bug?

Karel is seeing that problem under Linux computer.  The scope USB commutations is wrong.   Firmware problem.

[BEM]

It would be cool if there was an open source OS for this scope...but I guess it's too much a challenge for the hacker community to tackle. 

[MrWolf]

MrWolf, I could not duplicate any of the issues you reported here. I used a 100 MHz osc and split the signal via BNC T, with various coax lengths to each of 3 channel inputs - 4th channel On without input, and observed proper delay and phase measurements. The frequency counter worked fine for me too.

I updated test procedure description for counter problem in original post:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg1072742/#msg1072742
Counter test was done with 10x probes at 10x setting, not 50ohm coax! Did re-run the test with different probes. Some numbers changed a bit (updated) but general situation is same. When pushing sensitivity limits counters fails much earlier while trigger and wfm graph still work properly.

As for phase/delay stuff - I ordered some high quality cables, terminators etc. Will re-run 50ohm test when I get them.

[metrologist]

Thanks! I'm surprised your posts have gotten such little attention. I tried a number of configurations and could not get phase shift measurements to fail.

[MrWolf]

Thanks! I'm surprised your posts have gotten such little attention.

Well I guess not many people really max out this box or try to use it for RF purposes...
Anyway I did final test on the subject, using 10X probe + BNC adaptor. Probe was
correctly configured as 10X probe. Probe was only 60MHz (I do not have BNC adaptor
for Rigol probes), but this does not matter much because I did graph based on
Rx values, and signal was basic sine.

Conclusions:
- counter sensitivity drops about 6...9dB from 25MHz to 100MHz.
- 100, 200mV/div ranges have funny stuff going on switching 1GS/s => 500MS/s => 250MS/s
- 10mV/div range is fake from counter's viewpoint and is really 20mV/div range
- do not ever assume counter as working ok based on clean visual signal and trigger working correctly

Attached Excel file and PDF with report.

Edit: Tx/Rx are mVpp, not mV in report. Reports fixed.

[MrWolf]

It's bashing time again. Now I got 100% solid proof that this  box is doing its "measurements" basically off the screen (pixels!?), not the datapoints. But while I'm putting screenshots together - heres a little warmup. It's this error I found earlier:

- look attached image. Here is no 180' excuse for erroneous reading this time.

Error is too big even for "pixel math". Luckily it has cursor mode called "Auto", if you apply this mode to specific measurement item it will readily reveal what is going on - and it's insane. Screenshot attached.

[ruffy91]

Where is the problem? It takes the middle of your signals. How should it take the middle of a sine which is not complete? You only have 60 Points depth!

[metrologist]

Is it bad that those on-screen measurements are performed on screen data? What is the trade-off, no automatic on-screen measurements and manual on-screen measurement?

I am still just a bit perplexed as to the play you're getting on this issue. It took me a sec to realize what was going on in your pic and I think I need to look more to be convinced that is not just a fleeting, opportunistic grab. I could not get the measurement to give me erroneous results, but I am limited in my inputs.

What is the funny icon next to the speaker icon?

[MrWolf]

Ok, now down the proof that Haxx0magical "pixel math" takes place instead of measurements...

Test setup:
25MHz sine signal, 90' phase diff.
Cursor=Auto, Auto item=Quick4

DUT: Rigol DS1000Z

Test 1-1: 5ns timebase, 500MS/s sampling. 
"DS1104Z_25MHz_5ns_500MS__phase_error_.png"
Note that that it should be heavily averaging (over 128wfms), but both delay and phase are jumping around quite happily and wfm twitches by couple of pixels. Values are not that off... but it's just tip of the iceberg.

Test 1-2: 50ns timebase, 500MS/s sampling. 
"DS1104Z_25MHz_50ns_500MS__phase_error_.png"
Note that sampling rate is same, but more datapoints due to 10x bigger timebase. On normal scope this would yield much better precision. But on this thing we have total fail because it operates far beyond measure - in the fantasy land of colorful pixels  But hey, at least wfm is rock solid this time and almost fools you into thinking that averaging is actually applied to measurement and it might be correct...   

Test 1-3: 20us timebase, 500MS/s sampling
"DS1104Z_25MHz_20us_500MS__phase_error_.png"
Now in this case user should get to use full power of modern DSO with deep memory and zoom. But  something has gone horribly wrong  All the little pixels are molten into a yellow goo and powerful "phase shift" has taken place.

Very important: after that test I pressed [STOP] button and next test was just zooming in on saved signal.

Test 1-4:
"DS1104Z_25MHz_20us_500MS__phase_error__zoom_.png"
When zooming in on stopped signal "measurements" wonderfully transform and auto cursors jump around like kangaroos until at max zoom somewhat correct values are displayed. Now I felt true power of modern DSO 

[MrWolf]

Where is the problem? It takes the middle of your signals. How should it take the middle of a sine which is not complete? You only have 60 Points depth!

My signals are two perfect sines. Nowhere in manual it says it will take middle of the "stuff on the screen". What if signals are more complex and cut by screen window in funny places?
What if many users wont ever discover magic cursors and just rely on the measurement number?
It's the simple case if you do no know - do not show.
If you gonna do automagic - do it properly. It must first make sure it has full cycle on waveform, and only then show something.

[MrWolf]

What is the funny icon next to the speaker icon?

USB PictBridge.

[metrologist]

You could probably also figure out the discrete pixel steps and correlate measurement data that way.

What does it mean exactly when the screen says 30.0pts? Is that 30 data points to make up the entire waveform of both channels, 30 data points per waveform per channel?

[MrWolf]

To put things into perspective I did same stuff on heavily outgunned old soapbox called Pico 2205 MSO. Guess could have done it on any Tek, Agilent etc also and gotten pretty much the same. It is what you expect from properly programmed DSO:

Test setup:
25MHz sine signal, 90' phase diff.

Test 2-1: 50ns timebase, 100MS/s sampling
"2205MSO_25MHz_50ns_100MS_.png"
Take note that poor soapbox is totally outgunned (5x worse sampling rate, operating at max analog freq) but manges display value with same abs error. Avg value is rock solid as it should be with 128 count avg.

Test 2-2: 20us timebase, 100MS/s sampling.
"2205MSO_25MHz_20us_100MS_zoom_.png"
Nothing changes about measurements when I zoom in/out since it's all calculated from actual data. Zoom is just UI feature as it should be. This pic is 500x zoom, with honest datapoint display.
Measurement values are exactly same as they are on other timebases with same sampling rate. And another time: Measurements do not (should not, cannot) depend on timebase, do not depend on zoom. They only depend on sampling rate and datapoints (more points - better averaging).

Edit:
Test 2-3: 20us timebase, 100MS/s sampling.
"2205MSO_25MHz_20us_100MS_.png"
Forgot no-zoom pic from 20us timebase. All measurements same as any other 100MS/s case.

So what's the bottom line. Why bashing the  Z-box? Because it wastes human resources. Maybe "pixel math off the screen" seems normal to someone coming from CRO. It's not normal for someone buying his fifth scope after using properly programmed DSOs for years. You wont be expecting s*it like that. It will waste your time and ruin your day.
Also as former pro programmer (now exec) I can ensure you that problem is not hardware here, it's just GUI/core logic is made a** inside out. I know the programmer type that does this. I have personally fired about 5 like this and another 5 in outsourced company f*cked a project worth millions. Worst case is when Haxx0r-aces manage it to senior programmer stage by luck or coincidence, more collateral when you fire these.

[BravoV]

So what's the bottom line. Why bashing the  Z-box? Because it wastes human resources. Maybe "pixel math off the screen" seems normal to someone coming from CRO. It's not normal for someone buying his fifth scope after using properly programmed DSOs for years. You wont be expecting s*it like that. It will waste your time and ruin your day.

Also as former pro programmer (now exec) I can ensure you that problem is not hardware here, it's just GUI/core logic is made a** inside out. I know the programmer type that does this. I have personally fired about 5 like this and another 5 in outsourced company f*cked a project worth millions. Worst case is when Haxx0r-aces manage it to senior programmer stage by luck or coincidence, more collateral when you fire these.

Is there any chance you sell it ? Anyway, you've played with so many scopes before, its not like your "precious" 1st scope like teenage hobbyist which is stuck with the 1st scope for quite a while.

Feel sorry for you that this crap & cheap ass scope is ruining your day/time or even life.

As you're an "executive" level now, money wise, again, just don't believe this cheap ass < $500 scope is still bugging and annoying you for so long, its been months isn't it ?

C'mon, just sell it, or donate it maybe to one of your fav programmer or employees, or young hobbyist or etc.

Cause once you're free from it, just take a deep breath and it will be a huge relieve for you, trust me.

[MrWolf]

Well I did know it will be talk like that. From consumer level yes, bad wolf bashes "poor mans" scope, woooo... negative feeback, omg 
But I look to it from another perspective: programmers like this should not be in the industry - because they force proper ones to deal with s*it they leave behind... if the company did not collapse.
Also when some yuongsters learn their stuff on scope with software like this he will take it as a norm and produce similar afterwards. What if he gets to program avionics eventually? What if the self driving car that he did program kills whole bus-station?

Cause once you're free from it, just take a deep breath and it will be a huge relieve for you, trust me.

What I'm gonna bash then? Those hand picked programmers I work now with? Nooo... Gotta have some can of worms to poke in... 

[Karel]

programmers like this should not be in the industry - because they force proper ones to deal with s*it they leave behind... if the company did not collapse.

You should tell to that same industry that they should hire better programmers and, because of that, they should be willing to pay higher wages...
At the end of the story, it's always the problem of the boss that wants to have the "best" employee for the lowest wage.
I don't see this change soon, if ever.

[Fungus]

You should tell to that same industry that they should hire better programmers and, because of that, they should be willing to pay higher wages...

It's not just about the wages. The head programmer might be the Boss's nephew and won't let anybody else touch the code or something.

The Daily WTF has endless stories about ways 'good intentions' can go wrong or be thwarted by idiots.  I'm sure it's even worse in China.

[MrWolf]

You should tell to that same industry that they should hire better programmers and, because of that, they should be willing to pay higher wages...

Dunno how is it in China... But in my experience all the dudes had ok wages and really nothing to complain about. Kickass ski tours paid for gods sake... Problem is cultural. Somehow it sneaks in to their brain that only result matters, not how they do it... If in all use cases (they can think of) "black box" gives out right readings it's ok they think. What they do not think: what if I did not think of something and my fast formula that makes 2*2=4 by 2+2 is not gonna cut it? What if someone else has to do some changes to my spagetti code that only doped raccoon can understand? What if the system I work on has to still work after 10 years and will have 100x the load??? What if "bad boss" actually tries talk some sense to me for my own good?

I'll give you an example: High load database GUI had to display some data that had ~100 fields in it. In spec it said: fields may change at any time, internal I/O must be configurable and array-based. After going live system still had some minor bugs. Fixing each bug caused chain reaction of 10 new bugs. After doing expertise on the code it became evident that dudes had programmed I/O with functions that had ~100 hardcoded parameters... (specific hardcoded order, no config possibility!) Eventually system was scrapped despite looking very modern and professional...

So now there is possibility that I have to deal IoT stuff and actually dissecting some badly programmed product is very interesting - what are ways of Haxx0rs at the GUI-hardware interface...

EEVblog #818 - Embedded Electronics With Jack Ganssle 
https://youtu.be/1apCAzCTZdQ?t=12m25s

[BravoV]

Also when some yuongsters learn their stuff on scope with software like this he will take it as a norm and produce similar afterwards. What if he gets to program avionics eventually? What if the self driving car that he did program kills whole bus-station?

Its called certification and compliance to certain safety standard.

Your cheap ass scope don't need that, otherwise it will be so expensive that probably you can't afford it, hence no more whining.

What I'm gonna bash then? Those hand picked programmers I work now with? Nooo... Gotta have some can of worms to poke in... 

I knew it, its never about the scope, g'luck on the whining and venting out your frustration thru this scope , I'm out.

[Fungus]

What I'm gonna bash then? Those hand picked programmers I work now with? Nooo... Gotta have some can of worms to poke in... 

I knew it, its never about the scope, g'luck on the whining and venting out your frustration thru this scope , I'm out.

I saw it a few posts ago and kept quiet.

If he can't see that $400 is unbelievable value for so much 'scope, warts and all, then it's his own problem. It's like buying a Ford Fiesta then complaining it won't fit a piano in the back and go 200mph.

PS: All cars have annoying 'bugs', too. Not just niggles, even the expensive ones often have recalls for critical failures.

My friend's new Ford Fiesta is totally clueless at calculating remaining kilometers even after a firmware update that was supposed to fix it. This isn't something that somebody at Ford might have overlooked in testing, they just don't seem capable of writing that code.

[MrWolf]

Your cheap ass scope don't need that, otherwise it will be so expensive that probably you can't afford it, hence no more whining.

Looks we have a winner here - why do something properly when you are not forced by framework of expensive-to-implement ruleset? Ever heard of agile software development?

Picos 2205 is 2x cheaper at 200€, yet it works like professional tool.
If Tek would do 200€ scope it would also work the same, just have very low specs.
I'm suspect Digilents AD2 is also executed 5+.
It's a cultural thing...

[Fungus]

Picos 2205 is 2x cheaper at 200€, yet it works like professional tool.

Are you claiming that Pico software is bug free? 

[MrWolf]

Are you claiming that Pico software is bug free? 

There's massive difference between a bug and whole logic built using a** inside out methods. Latter is not fixable without scrap-it-someone-does-it-properly process.

[Fungus]

Are you claiming that Pico software is bug free? 

There's massive difference between a bug and whole logic built using a** inside out methods. Latter is not fixable without scrap-it-someone-does-it-properly process.

I'll take that as a "no"....

[Ducttape]

A feature I'd like on my Rigol would be the ability to easily (e.g. a long button press, simultaneous button presses, etc.) put zero volts at the bottom of the display and the trigger time to the left. Come to think of it, might as well be able to specify any corner while we're at it.

In case it's not obvious, this is for times where my signal is only positive and I don't care about pre-trigger data. Doesn't waste screen space.

[MrWolf]

I'll take that as a "no"....

Probably there is something. If it interests you maybe you should test it and report if find anything.

But what if... Rigols firmware IS a bug?

[Fungus]

I'll take that as a "no"....

Probably there is something. If it interests you maybe you should test it and report if find anything.

Oh, sure! I'll spend $400 on a Picoscope just for that.

[metrologist]

Mr. Wolf,

Other than you complaining about the meas value "jumping around" what is the problem with the first measurement you posted just above? Compared to pico with 50 samples, the phase offset seems within reason.

This is a measuring tool and I understand the class of tool that it is, so it is important to me to distinguish the difference between a poor methodology and an actual bug within the context of this class of tool. I use measuring calipers all the time and have an inexpensive plastic set that are no where near as precise as my hardened and ground Starrett that actually did cost almost two orders of magnitude more. So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

[Fungus]

So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

And let's remember that the Pico are far more expensive then the Rigols (for far less hardware!)

[metrologist]

If Pico could wirelessly connect to my phone or tablet, then I would not need to buy another computer or laptop. That would be cool

[JPortici]

So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

And let's remember that the Pico are far more expensive then the Rigols (for far less hardware!)

without forgetting that most if not all of the money goes into a better version of the important part of the hardware... you know, the front end, acquisition and memory. and the crappiest of the picos is still better in the software, can't say that for the rigol with its load of hardware

[Fungus]

without forgetting that most if not all of the money goes into a better version of the important part of the hardware... you know, the front end, acquisition and memory. and the crappiest of the picos is still better in the software, can't say that for the rigol with its load of hardware

Yet weirdly enough Picos are despised around here.

Hands up who owns one...?

[MrWolf]

Other than you complaining about the meas value "jumping around" what is the problem with the first measurement you posted just above? Compared to pico with 50 samples, the phase offset seems within reason.

Jumping around is the problem. It just got lucky I pressed stop at the right moment.

Did new test with improved logic:

Signal gen puts out 2x10MHz, with nasty little 3.6 degree phase shift.
Measurements done 2x per DUT, swapping cables to look for possible issues.
For both units I tried to get best possible result.
If something could be done better in case of Rigol - please specify.

Pico: 100MS/s, 20k points, 1000x averaging: 3.15 +- 0.08014 & -3.266 +- 0.07538

Rigol: 500MS/s, 12M points, 1024x averaging: 0.1133 & -3.487
(Current values seem to be identical but actually they are jumping all the time in discrete manner and not centered around 2.880, it's reflected in average values)
Edit: proof attached (DS1104Z_10MHz_jumping_proof.png).

Screenshots attached.

So you have this range of 400 dollar scope, 4,000 dollar scope, 40,000 dollar scope and I have no illusions this Rigol is going to compete with the latter.

Hm, but currently I'm comparing it with my very old scopes that are out of production by now and were in same price range once... meaning 2x cheaper than DS1052E when it did come out...

[MrWolf]

Yet weirdly enough Picos are despised around here.

How's that weird? It's s*it for room decoration

[David Hess]

It's bashing time again. Now I got 100% solid proof that this  box is doing its "measurements" basically off the screen (pixels!?), not the datapoints. But while I'm putting screenshots together - heres a little warmup. It's this error I found earlier:

I thought that the Rigol operates this way was pretty well established.  It also leads to odd behavior where changing the trace positioning, volt/div, and time/div alters the automatic measurements in bizarre ways.

Is it bad that those on-screen measurements are performed on screen data? What is the trade-off, no automatic on-screen measurements and manual on-screen measurement?

It means that the processing used to generate the display and especially the index graded high acquisition rate display alters or completely corrupts the automatic measurements.  For example RMS measurements of anything except a clean waveform do not work correctly at all.

If he can't see that $400 is unbelievable value for so much 'scope, warts and all, then it's his own problem. It's like buying a Ford Fiesta then complaining it won't fit a piano in the back and go 200mph.

I might have accepted this argument if Rigol was not simultaneously deceptive about the capabilities of the instrument.  In case this is misunderstood let me make it plainer; they lie several times in the documentation and they do the same thing for the DS1000E series.  This company cannot be trusted.

[MrWolf]

I thought that the Rigol operates this way was pretty well established.

Doing calc only from data on the screen does not automatically mean that calc will be so wrong. It could take X actual datapoints related to screen, average long enough and get results no worse than ETS.
But even doing it from pixels does not explain some stuff...

Look screenshot:
"DS1104Z_10kHz_phase_error.png"
Two perfect 10kHz sines out of 1.2GS/s gen, no phase diff. Waveforms are drawn no problem. 1024x averaging does its job. However auto-cursors are jumping around like rabbits even to places where are no wfm pixels! Delay/Pha1 Min/Max get impossible values.

I might have accepted this argument if Rigol was not simultaneously deceptive about the capabilities of the instrument.

Actually instrument itself also lies like theres no tomorrow...
Now it's 2x10kHz square wave, no phase. Gen specs:
Rise/fall times 9 ns 10% ~ 90%, 1 Vpp, 50?Load

"DS1104Z_10kHz_5ns_500MS.png"
At 5ns timebase Z shows that gen is operating better than spec. For cross check theres same thing with Pico running at 4GS/s ETS:
"2205MSO_10kHz_5ns_4GS.png"

Now lets look at same wfm at the stage where duty cycle could be calculated:
"DS1104Z_10kHz_10us_500MS__lies.png"
Slight WTF moment. It's says running at 500MS/s. User would assume this is perfectly adequate for rise time measurements ant trust BS it puts out. It's wrong by 50 times! 
For comparison here's same from Pico:
"2205MSO_10kHz_20us_50MS.png"
Little old soapbox honestly says it's running only at 50MS/s and cannot calculate rise time for specific waveform.

Probably most correct way of using this Z "instrument" for analog stuff is screen+cursors unless they fix it. After all FFT has "memory" source option which makes it somewhat useful compared to screensaver function on "screen" source.
Maybe some measurements could also grow "memory" source and start actually mean something.
Overall it's not that bad - design is good. Great body with many knobs poking out. UI is generally ok. Hardware is adequate since it CAN display correct wfm. Just that specific dude(s) doing complex measurements part f*cked up a little....

[NorthGuy]

Pico runs on PC with computing power many times more than Rigol's. Even with all this power, it might have problems with 12M points, but you don't give it that much. Would it be reasonable to expect the Rigol to do the math on all 12M points and display the results reasonably fast. Of course not. Engineering is always a compromise. So, they decided to take a sample (what you see on the screen) and calculate on it. This gives them reasonable responsiveness.

And this is not really that bad if you take into account how it's working. For example, you could zoom in to get more accurate rise times. Or you could spend 15 seconds to load all the 24M data from Rigol onto PC and then perform the calculations you need.

[tautech]

I'll take that as a "no"....

Probably there is something. If it interests you maybe you should test it and report if find anything.

But what if... Rigols firmware IS a bug?

rf-loop did some study on similar problems 2 years ago:
https://www.eevblog.com/forum/testgear/rigol-ds1074z-weird-signal-level-problem/

[Fungus]

Or you could spend 15 seconds to load all the 24M data from Rigol onto PC and then perform the calculations you need.

Yep. Rigols have a connector on the back that lets you use them much like a Picoscope.

But they cost less, and they have a screen and knobs if you want to use them.

[Howardlong]

While I understand your concerns, to me this sounds much more about understanding how your instrument works, and being aware of its limitations.

I ran your tests on three scopes, an Tek MDO3054, Keysight MSOX3054A and a Rigol MSO1074Z-S, taking care to closely reproduce your tests including memory depth and averaging etc where specified. Not only did they all behave significantly differently in terms of results, but I came to the conclusion that the tests themselves were built to highlight particular characteristics using rather specific edge cases. I am sure we could equally well come up with similarly specifically designed cases putting the Pico in the same court.

Putting in two identical sine waves and asking for the phase difference is quite computationally demanding, it's essentially attempting to do multiple correlations between the two signals to find the best one and using that to give phase difference. I'm not surprised it's done off a subsample.

Regarding the rise time thing, I agree though that it would be better if the screen said something like "<400ns" like the Keysight scopes do in similar situations. In fact, out of Statistics mode, the Rigol does present it as "<200ns", so I assume it's simply run out of screen real estate. The Tek, though, is already known to be terrible at this. The Pico doesn't tell you anything at all.

I don't think the sample rate is a lie though. When the scope is stopped, you can zoom in and your measurements will be recalculated on the same data but at a higher sampling rate. It's a like using a ruler to get a quick coarse measurement and then use your micrometer for a finer resolution.

So in short I'd say it's as much about understanding and learning how your instruments work as anything else. This includes knowing both their limitations and how to use them. Although we all want to trust our instruments, part of being an good engineer is knowing when something doesn't look right, and being able to question, understand and explain it: i.e., a good workman doesn't blame his tools and all that (well, not most of the time anyway).

[Fungus]

So in short I'd say it's as much about understanding and learning how your instruments work as anything else.

Agree 100%. MrWolf is making mountains out of molehills and pointing the finger at the DS1054Z when most other low-end scopes will probably do similar things of you take them to the limits. If you want that sort of perfection then buy a $40,000 'scope.

[Howardlong]

So in short I'd say it's as much about understanding and learning how your instruments work as anything else.

Agree 100%. MrWolf is making mountains out of molehills and pointing the finger at the DS1054Z when most other low-end scopes will probably do similar things of you take them to the limits. If you want that sort of perfection then buy a $40,000 'scope.

I'm pretty sure even then you'll need to know how to drive it and interpret the results properly.

[MrWolf]

Regarding the rise time thing, I agree though that it would be better if the screen said something like "<400ns" like the Keysight scopes do in similar situations. In fact, out of Statistics mode, the Rigol does present it as "<200ns", so I assume it's simply run out of screen real estate. The Tek, though, is already known to be terrible at this. The Pico doesn't tell you anything at all.

Well... not "better", "correct"! Also "realestate" excuse do not work with "Dly1" and "Pha1". Here it clearly states "-" sign. So it means to display what it displays.
Its funny how engineers (I presume) are defending plain erroneous readings with various "humanitarian" excuses. Engineering is not for humanitarians with soft underbellys. It exact business.

All talks (by some) about how cheap it is and therefore cannot programmed correctly is plain incompetent. I have tens of years software experience and I can state that s*it programming costs more
for everyone involved. So you either find good workers or fold your stuff eventually... unless youre monopoly or govt of course ...or your sales strategy is endless steam of noobs who just need pro looking deco item 

I don't think the sample rate is a lie though. When the scope is stopped, you can zoom in and your measurements will be recalculated on the same data but at a higher sampling rate.

Excellent info. Then I apologize - was mislead by erroneous readings.
Moreover - then it can be fixed and indeed hardware dudes were doing good job 

So in short I'd say it's as much about understanding and learning how your instruments work as anything else.

Up to a point... In this case there are blatant UI and programming errors. Some of them are trivial to fix. "Cheapness" is not excuse. Even 10$ multimeters are to expected to display "out of range" where appropriate, not some BS values.

Would be interesting if some of the "humanitarian" engineers here were so kind also when their own dev team produced stuff like this 

[Karel]

Just some general info about the Rigol DS100Z series. As far as I know/experienced, most calculations & decoding are done
with the data that's actually visible on the screen, not with the raw captured data which can be as big as 24Mpts.
So, what's the difference between the raw waveform data (with sample rates up to 1GHz and and a size up to 24Mpts)
and the display data?

The difference is that the display data is always downsampled to 1200pts (100pts per horizontal division).

Those 1200pts are used for serial decoding, FFT and (I haven't tried my self yet) probably also for all other measurements.

How is this downsampling done? Only Rigol knows. They claim it's a special (patented/secret?) algorithm.

This is a big limitation but understandable because of the priceclass of the instrument. Zooming in (horizontally) improves
things but doesn't let you be able to see, for example, a long serial transmission.

So, if you want to do analysis with higher resolution, the only solution (with Rigol) is to download all 24Mpts to
a pc and do the analysis offline.

And here's the sad thing, there's a "time difference" bug in the Rigol firmware that causes a random time difference
of +/- 100nS between different channels:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

It has been reported to, and confirmed by, Rigol a long time ago (Februari 2016) but in the
subsequent firmware updates, they didn't solve it.

[MrWolf]

The difference is that the display data is always downsampled to 1200pts (100pts per horizontal division).

Actually they now offer "memory" source option for FFT. It becomes slow as diseased opossum but actually manages to show something meaningful. Same could be done with other measurements. Maybe time for T-shirts "memory based measurements for masses!"

This is a big limitation but understandable because of the priceclass of the instrument.

Well if it would really be 1200pts - not so bad. Better than one could do with cursors. So step up from CRO from example. But let's if that has anything to do with reality... Analyze some screenshots from my post:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg1088384/#msg1088384

1200pts reso presumed
601px wide screen area => 600px wfm measured (graticule is 1px too wide)
10us/div * 12div = 120000ns wide data
120000ns/1200 = 100ns/pt
120000ns/600 = 200ns/px

"DS1104Z_10kHz_phase_error.png"

3px max wfm width => 600ns => +-300ns "play" on data,
but ok lets write that down to graph aliasing... but:

Dly1-2:
Max: 400ns
Min: -800ns
=> +-600ns "play" in data => +- 6pt (+- 3px)

"DS1104Z_10kHz_10us_500MS__lies.png"

Rise:
400ns => 4pt => 2px

measured 1px max wfm width 10%-90% => 200ns (from pix) & 100ns (presumed from pts) & <1ns (actual signal)

So here it is seen that practical resolution for measurements is actually just about 300pt(px) horizontal,
actually 2x worse that could be done with cursors.

So heres a formula:

practical resolution = timebase div / 25

Probably worse if calculated in scientific manner.

[Fungus]

Just some general info about the Rigol DS100Z series. As far as I know/experienced, most calculations & decoding are done
with the data that's actually visible on the screen, not with the raw captured data which can be as big as 24Mpts.
So, what's the difference between the raw waveform data (with sample rates up to 1GHz and and a size up to 24Mpts)
and the display data?

The difference is that the display data is always downsampled to 1200pts (100pts per horizontal division).

Those 1200pts are used for serial decoding, FFT and (I haven't tried my self yet) probably also for all other measurements.

We don't know that with 100% certainty but that's what we observe and it makes sense to do it that way.

How is this downsampling done? Only Rigol knows. They claim it's a special (patented/secret?) algorithm.

That would be the main job of the FPGA in these oscilloscopes - to whizz through the sample memory and crunch the 24Mb of data down to screen size. The waveform update rate, etc., will depend purely on the processing power of the FPGA. I doubt there's any big industrial secrets in the process.

The main CPU can then work on those screen pixels to display them, make measurements, etc. It probably doesn't have direct access to the sample memory, it will all go through the FPGA.

Actually they now offer "memory" source option for FFT. It becomes slow as diseased opossum but actually manages to show something meaningful.

I assume they're shuffling the data into main CPU memory via the FPGA and doing the FFT there. Some enterprising programmer managed to slip that code into the firmware, we should thank him instead of complaining!

Same could be done with other measurements.

Then you could spend all your time complaining it was too slow, right? 

[kwass]

Same could be done with other measurements.

Then you could spend all your time complaining it was too slow, right? 

I think that the delay would be perfectly acceptable if the decode worked this way.   

[MrWolf]

Then you could spend all your time complaining it was too slow, right? 

Well I'm just learning about my new DSO. Seems indeed it's some new kind of DSO, I will name it SCREEN SAMPLING DSO, yeah    Sadly in the manual does not teach how to account for differences compared to normal DSO operation. You see I've used only normal ones so far and when buying this one was looking only at analog bw, memory sample rate and channel count. But there's another and unique param - "screen sampling rate" - very important for risetime auto-calc!

So now I must create helper formulas and tables to navigate around it's limitations. Would much prefer for it just to be slow. Slow computes well with measurement instrument. Readings off by 4 orders of magnitude do not (in the situation where normal DSO wouldnt be even stretched).

We don't know that with 100% certainty but that's what we observe and it makes sense to do it that way.

Let's observe some raw data then. I adore raw data, it makes s*it float
Reports attached below.

Short summary:
Fed 10Vpp, 32768Hz 50% duty square signal into Rigol DS1000Z and my old PicoScope 2205 MSO (25MHz, 2ch+16ch, 2013 out of prod model).
In case of normal DSO it can be seen readings reflect the nature of signal rather well. Lowest sampling rate observed at the 5ms timebase was 0.9804MS/s.
However in the case of "screen sampling" DSO it can be seen that despite hardware superiority it's readings are up to 4 orders of magnitude off. Despite running at massive 125MS/s at 5ms timebase in reality it's "screen sampling rate" for risetime calculation is only 0.005MS/s. Does a bit better with period calculation, only by about order of magnitude off.
So clearly it cannot be used anything like normal DSO. But then manual should reflect it. Customer is not to be expected reading forums for weeks when buying equipment.

[David Hess]

This discussion clears up a mystery for me; why does Rigol include a delay feature and misleadingly refer to it as delayed sweep when it is not.  It can only delay within the admittedly ample acquisition record and it does not produce a new acquisition; instead it decimates an old acquisition to produce a new display record from the acquisition record.  My ancient 2230 can do that (1) and the Tektronix 2230 is the oldest digital storage oscilloscope I would consider a real DSO! (2) Other DSOs including ones that have real delayed acquisition or sweep call this horizontal magnification and it works independent of a delayed sweep.

I am increasingly convinced that the Rigol is even worse than I originally thought.  All of my ancient CRT DSOs have a higher resolution vector CRT screen, make measurements on the 16 bit acquisition record without ambiguities so averaging actually improves resolution, support real delayed acquisitions or sweep, and if you count the Rigol's display record as its true record length which seems reasonable since *that* is what its measurements and decoding use, they have tiny record lengths which are still several times that of the Rigol.

If Rigol is doing the display processing in the processor instead of the FPGA unlike other DPO type DSOs, then this also explains its high acquisition rate; its record length is effectively only 1200 points!  That is a clever engineering trade off but it should not come at the expense of other functions.

(1) The Tektronix 2230 and 2232 inexplicably have a function to compress a 4k acquisition record into a 1k display record in real time.  When used, the time/div is multiplied by 4.  I have no idea why this function was included but I have occasionally used it to good effect.

(2) My criteria for a "real" DSO includes peak detection and the Tektronix 2230 has the earliest implementation that I know of.  This is why I never considered Rigol's earlier DSOs like the DS1000E series to be more than toys.

[Fungus]

So clearly it cannot be used anything like normal DSO. But then manual should reflect it. Customer is not to be expected reading forums for weeks when buying equipment.

It's honestly never occurred to me to try to accurately measure a rise time (or anything else) without being zoomed in on the area of interest.

I also don't try to measure 0.2V signals with my multimeter set to the 200V range, so... 

[Howardlong]

This discussion clears up a mystery for me; why does Rigol include a delay feature and misleadingly refer to it as delayed sweep when it is not. .

I belive this is a nomenclature problem. On Agilent DSOs, for example, until about six years ago, the zoom mode was referred to as delayed sweep mode, a throwback to the days of CROs. Rigol's heritage is from making low end scopes for Agilent, explaining the apparent anomaly.

[MrWolf]

It's honestly never occurred to me to try to accurately measure a rise time (or anything else) without being zoomed in on the area of interest.

Maybe you moved directly from CRO to "screen sampling" DSO. I barely used CRO and learned most stuff on normal DSO. On normal DSO you always look at the sampling rate and decide the actual precision of your auto-measurements based on that. For example at 1GS/s you would have high confidence that phases are spot on down to at least +-1ns (single shot), and transients to analog bw. This gives you massive edge over classical CRO - having "big picture" and precise measurements on a single screen w/o zooming in/out all the time.
This is a big trap for young players or when someone moves from normal DSO to "screen sampling" DSO.
So first step for fixing it for Z would be stop shooting at the moon and just disable auto-readings based on very simple formula I gave:
IF Signal.Transient <= (Timebase / 25) THEN Reading.disable()
...or at very least display <= in front of reading.
Of course real fix would be enabling memory-source measurements...

BTW - can it be assumed that info on this thread gets to Rigol or must report directly?

Edit: One more way to make it work. RUN mode - do as before, just display < or <= before readings or disable entirely. STOP mode - switch to signal analysis based on actual sample memory. No hit on realtime performance & valid data with single button press.

[Karel]

BTW - can it be assumed that info on this thread gets to Rigol or must report directly?

You can safely assume that they don't read anything on any threads on this forum...

Report it directly. If you don't receive any confirmation within a week, call them and ask for the status.
In my experience that is the only way to get your Rigol representative (Rigol North America or Rigol Europe) to really check and confirm a bug
and report it internally to the Rigol engineers in China. Also, do a follow-up check after 3 months. And after 6 months. And after...

[MrWolf]

Report it directly.

On reporter might be not enough. If anyone feels it is time for actual
sample memory based measurements for masses!
then act NOW.

https://www.rigolna.com/contact-us/

http://www.rigol.eu/contact-us/

EU exec is Wolfgang Bartels.
Look article:
http://www.elektroniknet.de/markt-technik/messen-testen/deutschland-ist-ein-wichtiger-potentieller-markt-fuer-rigol-87737.html
Google-translated:
https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.elektroniknet.de%2Fmarkt-technik%2Fmessen-testen%2Fdeutschland-ist-ein-wichtiger-potentieller-markt-fuer-rigol-87737.html
Quote:
"We place much emphasis on reliability, quality, service and sustainability."

Time to deliver.

[Karel]

I already have a dedicated line with the red telephone directly to Rigol...

[MT]

I got a bit annoyed by Mr Bartelemo when he said:

Customers - whether private, in research, development or training - who already have a device from us know that the quality is very good and the error rate is low.

[David Hess]

It's honestly never occurred to me to try to accurately measure a rise time (or anything else) without being zoomed in on the area of interest.

I also don't try to measure 0.2V signals with my multimeter set to the 200V range, so... 

There is merit to this but on the DSOs I have used including my ancient Tektronix 2440, accurate measurements are made even with voltage and time resolution significantly below optimum for the measurement.  The number of significant digits is also reduced to match the measurement accuracy and a warning is given if the sample rate or amplitude is too low.  If anybody is interested, the measurement algorithms used in older Tektronix DSOs are documented in detail.

Tektronix also went to considerable design effort and cost (1) to ensure that measurements and processing never truncated or degraded the sampled data.  For instance all of their old DSOs which use 8 to 10 bit digitizers, use 16 bit acquisition memories for processing and *then* a separate display memory.  So for instance averaging or high resolution modes result in a higher bit resolution waveform stored in the acquisition memory which the measurement routines then act on unlike the Rigiol DSOs.

(1) Back in the 1980s when they did this, memory was not cheap.  When you see those tiny record lengths (not so tiny when you have delayed sweep) on the first Tektronix DSOs, they all use 16 bit words so their 1k or 4k records are actually 2k or 8k bytes and as far as I know they have always done this.

This discussion clears up a mystery for me; why does Rigol include a delay feature and misleadingly refer to it as delayed sweep when it is not. .

I belive this is a nomenclature problem. On Agilent DSOs, for example, until about six years ago, the zoom mode was referred to as delayed sweep mode, a throwback to the days of CROs. Rigol's heritage is from making low end scopes for Agilent, explaining the apparent anomaly.

I am not so sanguine because Rigol has repeatedly done this going back to their early DSOs where they confused envelope mode and peak detection.  To my mind, Rigol premeditatively lies in their marketing and documentation.  And I notice that they never make a "mistake" in the opposite direction which Tektronix has done occasionally in the past.

On normal DSO you always look at the sampling rate and decide the actual precision of your auto-measurements based on that. For example at 1GS/s you would have high confidence that phases are spot on down to at least +-1ns (single shot), and transients to analog bw.

So first step for fixing it for Z would be stop shooting at the moon and just disable auto-readings based on very simple formula I gave:
IF Signal.Transient <= (Timebase / 25) THEN Reading.disable()
...or at very least display <= in front of reading.
Of course real fix would be enabling memory-source measurements...

But that would make the apparent and fictional performance of the instrument match reality!  Rigol cannot do that!

Tektronix actually did something like this with one of their early DSO designs.  If you have an analog trigger and compare it to the sampling frequency, then it is possible to detect when aliasing is likely.  The problem was while everybody's DSO suffered from the same aliasing problems, having an indicator on the DSO which alerts the user that aliasing is likely to be present makes the DSO look worse compared to the competition so this useful feature was dropped.

BTW - can it be assumed that info on this thread gets to Rigol or must report directly?

Rigol did not care years ago when I pointed out mistakes (lies) in their DS1000E specificaitons and documentation.  Why would they care now?

[Fungus]

On reporter might be not enough. If anyone feels it is time for actual
sample memory based measurements for masses!
then act NOW.

Isn't it better to understand that this is the way DSOs work.

That way you won't be confused when using strange DSOs (nb. It's not just Rigol that does this....)

Fixing it would require making all those low-end DSOs more expensive. You say you wouldn't mind if it all went slower in the name of accuracy but secretly you would. You'd be in here complaining about speed, and how your old 1990s Tek was faster.

[MrWolf]

Isn't it better to understand that this is the way DSOs work.
Fixing it would require making all those low-end DSOs more expensive. You say you wouldn't mind if it all went slower in the name of accuracy but secretly you would. You'd be in here complaining about speed, and how your old 1990s Tek was faster.

Fungus, I'm starting to get seriously worried... You are a fungus, not a mushroom. Who keeps you in the dark and feeds ...? Rise up, break from the chains. You can do it, fight for your freedom  You remind me of beautiful russian women who are ok with drunk husbands beating them. It's not ok! There is a better life out there  Don't suffer just because of having knobs!

Current Pico 2204A, costing just 109€ works just like my old 2205MSO and would wipe the floor with Z on low freq - because despite it has tiny 8kS memory, it actually uses all of it, not some 1.2kS interpolated down to a 300S(!!!) garbage!
What if we compare to actual counterpart 2408B, 100MHz, 4ch, 128MS. It's 128,000,000S vs 300S that scope can actually use for calculations...

But I know one other scope that you have to use just like Z - take measurements with cursors and scroll screen back and forth.
It's.... Velleman HPS140 

Now about fixing part. Did adding "memory" source option to FFT make Z more expensive? Did you receive 39600$ bill?
Or what is cost of "<" adding sign before measurement value?
Also there's this option:
RUN mode - do as before, just display < or <= before readings or disable entirely.
STOP mode - switch to signal analysis based on actual sample memory.
No hit on realtime performance & valid data with single button press.
And not only measurements, it would make decoding work!

So it's all about choices and not treating your customers like a mushrooms... Not so much about cost...
Yes there would be some programming involved but they already managed FFT so it's a broken in path...

And do not worry for me so much. I bought this box for very specific task at VHF freq.
According to Screen sampling rate = 1 / (Timebase / 25)  formula there is small window of timebases where Z can be used as more-less normal instrument: 5,10,20ns. So I'm very well covered with old Picos doing precision stuff below 25MHz and Z-box at VHF.

... but due to my pro line of work I feel that making society aware of s*it programming and it's implications is important so why not to have little cockfight now and then... 

[Fungus]

Isn't it better to understand that this is the way DSOs work.

Fungus, I'm starting to get seriously worried...

I know this is going to scare the absolute crap out of you, Wolfie, but I'm going to say it anyway:

Every voltage reading you've ever seen on your DS1054Z screen is probably wrong.

It's wrong because you didn't take the trouble to maximize the waveform on screen first. The DS1054Z only has an 8-bit ADC and it works in screen space. Think about all the implications of that! All those newbies out there who don't understand it.

Let's demand that Rigol switch to 16-bit ADCs right now to avoid any more confusion.

[MrWolf]

Let's demand that Rigol switch to 16-bit ADCs right now to avoid any more confusion.

Well yea since Rigol does not have DC offset like normal DSOs in this same price range:
https://www.picotech.com/library/application-note/using-analog-offset-to-maximize-oscilloscope-resolution
Not to mention much better basic DC accuracy in the first place for 2xxx series: ±3% of full scale ±200uV

But when you do not have proper tools it's worth having a brain. I actually got interested in the problem yesterday and if there has not been blonde force majeure forcing me off the lab corner...
Will report later in this thread:
https://www.eevblog.com/forum/testgear/help-please-understanding-rigol1054z-dc-rms-measurement/

[BravoV]

... but due to my pro line of work I feel that making society aware of s*it programming and it's implications is important so why not to have little cockfight now and then... 

Hmmm ... pro line of work ? ... programming ? ... just because your claim and self declaration ?

Just don't believe it until there is a proof, isn't that fair ?

[JPortici]

Fungus, I'm starting to get seriously worried

i see you're still new around here

[Fungus]

Let's demand that Rigol switch to 16-bit ADCs right now to avoid any more confusion.

Well yea since Rigol does not have DC offset like normal DSOs in this same price range:

How is the "price range" the same if you need to add a PC/laptop just to get a display and some horizontal/vertical/trigger controls?

PC: Remind us again the price of a 4-channel, 100Mhz Picoscope. I forgot.

[MrWolf]

Just don't believe it until there is a proof, isn't that fair ?

Is my formula Screen sampling rate = 1 / (Timebase / 25) not correct according to actual tests done?
Does it not characterize device and have practical value when estimating actual accuracy of readings?

Would this solution not work on specific hardware?
RUN mode - do as before, just display < or <= before readings or disable entirely.
STOP mode - switch to signal analysis based on actual sample memory.
No hit on realtime performance & valid data with single button press.
And not only measurements, it would make decoding work!

How is the "price range" the same if you need to add a PC/laptop just to get a display and some horizontal/vertical/trigger controls?

Well you really have to be a mushroom not to find some out of fashion PC essentially for free to tuck under the desk.

PC: Remind us again the price of a 4-channel, 100Mhz Picoscope. I forgot.

If we talk non-hacked, diff is not that big. If we talk hacked, low-end VHF and only analog work, maybe yea (that's by I bought Z-box). If we talk lower freq then Picos just wipe the floor with Z for lower price. It seems to me often people go for high freq just for "prestige" and do not actually need it. Especially amazing are audio people buying Z if there is Analog Discovery 2 with 14bit ADC for less.

[JPortici]

If we talk non-hacked, diff is not that big. If we talk hacked, low-end VHF and only analog work, maybe yea (that's by I bought Z-box). If we talk lower freq then Picos just wipe the floor with Z for lower price. It seems to me often people go for high freq just for "prestige" and do not actually need it. Especially amazing are audio people buying Z if there is Analog Discovery 2 with 14bit ADC for less.

only a fool would pay for the option you can hack for free

[MrWolf]

only a fool would pay for the option you can hack for free

Had any really free lunch lately? It reminds one occasion with my good friend. He's sort of "financial life hacker" and tries to get stuff for free always when possible. One time he bought large good looking set of kitchen utensils from presentable dude with BMW X5... in a dark poorly lit parking lot... Dirt cheap, much cheaper than in a store  Well you can guess what he discovered at home... All it was basically a moulage
So what can be learned from that - if someone gives you some hackable stuff (knowingly!) for cheap price - it's high probability that it's actual value of this stuff + margin for manufacturer + margin for ...

[ebastler]

PC: Remind us again the price of a 4-channel, 100Mhz Picoscope. I forgot.

If we talk non-hacked, diff is not that big. If we talk hacked, low-end VHF and only analog work, maybe yea (that's by I bought Z-box). If we talk lower freq then Picos just wipe the floor with Z for lower price.

https://www.picotech.com/oscilloscope/2000/picoscope-2000-overview
100 MHz, 4 channels - $1235
50 MHz, 4 channels - $659

Is that the pricing we are talking about? Then I don't get your "wipe the floor for lower price" comment, even looking at a stock DS1000Z in comparison. And if I compare a hacked DS1054Z to a $1235 Picoscope then - "maybe yea", as you put it, there might be just a tiny price advantage indeed...

[MrWolf]

Then I don't get your "wipe the floor for lower price" comment, even looking at a stock DS1000Z in comparison.

Yolo, I'm really glad I sort of play simulated poker here, it would be nightmare otherwise...

Did you failed to notice that 32768Hz signal produced correct auto-risetime-measurement (accounting analog bw, it's 25MHz scope) from 2ns to 2us timebase, and spot-on period from 5us to 5ms. On Pico that is. Did you register, it did show garbage only 1 time: never.

On Z it produced auto-risetime from 5ns to 50ns, and almost correct period only on 5us timebase. Correct period accounting for analog bw is never produced. For mere 32768Hz signal! So there is "bandgap" filled with garbage 100ns to 5ms risetime-wise and all settings besides 5us are garbage period-wise for specific signal auto-measurement. Only workaround is cursors and zoom, like Velleman HPS140. But o boy it has some sexy knobs eg "lots of hardware"  These knobs will be polished to the bone while "fools" who "cannot count their money" just sit and watch correct readings on their extremely boring instrument 

[David Hess]

Isn't it better to understand that this is the way DSOs work.

That way you won't be confused when using strange DSOs (nb. It's not just Rigol that does this....)

Only cheap toy DSOs do this.

Fixing it would require making all those low-end DSOs more expensive. You say you wouldn't mind if it all went slower in the name of accuracy but secretly you would. You'd be in here complaining about speed, and how your old 1990s Tek was faster.

It is not entirely clear how Rigol is producing their high update rate.  If the digitizer is producing a display sized histogram, then it really has a 1200 point record length or whatever the graticule width is most of the time and Rigol are cheap lying bastards.  If the graded indexed display is created by the processor (this seems more likely to me now), then Rigol are still cheap lying bastards.

Either issue is do to the programming and not the hardware; there is no conflict between accurate automatic measurements and high acquisition rate.

Also there's this option:
RUN mode - do as before, just display < or <= before readings or disable entirely.
STOP mode - switch to signal analysis based on actual sample memory.
No hit on realtime performance & valid data with single button press.
And not only measurements, it would make decoding work!

So it's all about choices and not treating your customers like a mushrooms... Not so much about cost...
Yes there would be some programming involved but they already managed FFT so it's a broken in path...

I do not think this is feasible for marketing reasons.  Having two different measurement modes would reveal that display base measurements are broken.

Well yea since Rigol does not have DC offset like normal DSOs in this same price range:
https://www.picotech.com/library/application-note/using-analog-offset-to-maximize-oscilloscope-resolution

Doesn't the Rigol position control shift the ground level?  Position controls usually operate as offset controls with the position signal added before the digitizer.  The difference is whether the signal is added before or after the attenuators.

[Fungus]

Isn't it better to understand that this is the way DSOs work.

That way you won't be confused when using strange DSOs (nb. It's not just Rigol that does this....)

Only cheap toy DSOs do this.

I mentioned several times that people are free to pay more money and get this problem "fixed". Going on an on about it is like complaining that Ford Fiestas can't do 200mph. Technically true, but not going to make headline news or scandalize anybody.

So really this discussion is a bit of a yawn.

As I said, it honestly never occurred to me to look at a rise time without zooming in on the wave. Isn't it 100% natural to zoom in and look at the rising edge when you measure it? Make sure there's nothing weird there? 

If Picoscope owners aren't doing that then it says a lot about their user interface.

[Fungus]

https://www.picotech.com/oscilloscope/2000/picoscope-2000-overview
100 MHz, 4 channels - $1235
50 MHz, 4 channels - $659

Is that the pricing we are talking about?

I suspect Wolfie's not being entirely honest, not even with himself.

Well you really have to be a mushroom not to find some out of fashion PC essentially for free to tuck under the desk.

Sure. I might even be able to find a matching CRT monitor to complete the setup (and get a real analog 'scope heat output to make it feel like the old days).

OTOH I might be able to put something useful in that space.

Had any really free lunch lately? It reminds one occasion with my good friend. He's sort of "financial life hacker" and tries to get stuff for free always when possible. One time he bought large good looking set of kitchen utensils from presentable dude with BMW X5... in a dark poorly lit parking lot... (snip stupid story)

The DS1054Z can be made into exactly the same device as the DS1104Z with serial decoders, advanced triggers, 24Mb memory, etc.

The DS1104Z with all those options costs $1100.

No, the DS1104Z isn't worth $1100. If I was spending $1100 I might get a GW-Instek or something like that.

The DS1104Z is definitely a bargain for $400 though.

[MrWolf]

Doesn't the Rigol position control shift the ground level?  Position controls usually operate as offset controls with the position signal added before the digitizer.  The difference is whether the signal is added before or after the attenuators.

Screenshot attached how it works on Rigol.

[nctnico]

Well you really have to be a mushroom not to find some out of fashion PC essentially for free to tuck under the desk.

Those things aren't free at all. I used to have 4 PCs running under my desk. Now only one and my electricity bill is considerably lower. Not to mention noise and replacing fans every few years.

[Fungus]

Doesn't the Rigol position control shift the ground level?  Position controls usually operate as offset controls with the position signal added before the digitizer.  The difference is whether the signal is added before or after the attenuators.

Screenshot attached how it works on Rigol.

So... it's well within specification? 

[JPortici]

As I said, it honestly never occurred to me to look at a rise time without zooming in on the wave. Isn't it 100% natural to zoom in and look at the rising edge when you measure it? Make sure there's nothing weird there? 

If Picoscope owners aren't doing that then it says a lot about their user interface.

i understand that you either don't get it or you need to be fed like a good troll

if you have acquired at the correct sample rate AND your math is calculated from memory, not from display, zooming doesn't do shit to make the measurement more precise/true. you can zoom in to check if the waveform is nice and clean but beside that there is no need for correct calculation

(as for your beloved fiesta, it's like it advertised/it's written that it does 0-100 in 10 seconds and if you're alone it's fine, but if you are in two it takes 15 seconds because the engine can't keep up with a bit more load)

[Fungus]

i understand that you either don't get it or you need to be fed like a good troll

if you have acquired at the correct sample rate AND your math is calculated from memory, not from display, zooming doesn't do shit to make the measurement more precise/true. you can zoom in to check if the waveform is nice and clean but beside that there is no need for correct calculation

I understand it perfectly, I just don't see it as a big deal.

(the fact that nobody has ever complained about it here makes me suspect I'm not alone, either...)

The only way this "debate" would be interesting is if we examined a whole load of other oscilloscopes to see which ones do this and which ones don't. At what price range do they start to do it 'properly'? etc.

[JPortici]

PC: Remind us again the price of a 4-channel, 100Mhz Picoscope. I forgot.

If we talk non-hacked, diff is not that big. If we talk hacked, low-end VHF and only analog work, maybe yea (that's by I bought Z-box). If we talk lower freq then Picos just wipe the floor with Z for lower price.

https://www.picotech.com/oscilloscope/2000/picoscope-2000-overview
100 MHz, 4 channels - $1235
50 MHz, 4 channels - $659

Is that the pricing we are talking about? Then I don't get your "wipe the floor for lower price" comment, even looking at a stock DS1000Z in comparison. And if I compare a hacked DS1054Z to a $1235 Picoscope then - "maybe yea", as you put it, there might be just a tiny price advantage indeed...

if i wanted to be picky i'd say that you also have a signal generator w/ AWG (albeit a bit crappy). add that to the cost
also more protocols decoding that any rigol combined, ets, eye diagram, reference waveform, segmented memory, advanced math. And if you're a programmer and you have the need, you can add other stuff via the SDK.

[Fungus]

if i wanted to be picky i'd say that you also have a signal generator w/ AWG (albeit a bit crappy). add that to the cost
also more protocols decoding that any rigol combined, ets, eye diagram, reference waveform, segmented memory, advanced math.

Sure! At two to three times the price you should demand more from your equipment.

And if you're a programmer and you have the need, you can add other stuff via the SDK.

You can also connect your DS1054Z up to Matlab (or whatever).

[nctnico]

As I said, it honestly never occurred to me to look at a rise time without zooming in on the wave. Isn't it 100% natural to zoom in and look at the rising edge when you measure it? Make sure there's nothing weird there? 

if you have acquired at the correct sample rate AND your math is calculated from memory, not from display, zooming doesn't do shit to make the measurement more precise/true. you can zoom in to check if the waveform is nice and clean but beside that there is no need for correct calculation

This varies from brand to brand. Tektronix for example uses the memory for math but Keysight uses the screen data. On a Keysight scope you'll get different results at various zoom levels. Whether this is good or bad is debatable and depends much on the kind of measurement. When it comes to risetime you may want to select a specific edge, when it comes to RMS or some average you may want to calculate it over as many cycles as possible.

[metrologist]

This varies from brand to brand. Tektronix for example uses the memory for math but Keysight uses the screen data. On a Keysight scope you'll get different results at various zoom levels. Whether this is good or bad is debatable and depends much on the kind of measurement.

So this statement basically nullifies all of MrWolf's arguments? Whether it is wrong or not?

I appreciate the discussion and opportunity to learn more about how to use my instrument to get the most out of it. 

[Fungus]

This varies from brand to brand. Tektronix for example uses the memory for math but Keysight uses the screen data. On a Keysight scope you'll get different results at various zoom levels.

So this statement basically nullifies all of MrWolf's arguments? Whether it is wrong or not?

Basically, yes.

People like to point the finger at the DS1054Z but if you take a sample size greater than 'one' you usually find that the DS1054Z isn't as black as they're trying to paint it.

That's why I said above: "The only way this 'debate' would be interesting is if we examined a whole load of other oscilloscopes to see which ones do this and which ones don't. At what price range do they start to do it 'properly'? etc."

[metrologist]

Yeah, but if that's the way Keysight does it...is it really wrong or worth concern? I'm sure they know more about it than I do.

I'd be happy comparing the top (or bottom?) 3 or 4.

[David Hess]

I mentioned several times that people are free to pay more money and get this problem "fixed". Going on an on about it is like complaining that Ford Fiestas can't do 200mph. Technically true, but not going to make headline news or scandalize anybody.

But I expect the Ford Fiesta to operate as a car doing car things within its specifications.  I do not expect the manufacturer of my car or DSO to lie or mislead about its capabilities.  (1) Incidently, some cars like the Fiat Chrysler Jeep Grand Cherokee which killed Anton Yelchin fail this test because of poor human factors engineering; they are defective by design.

To give a single example (I could have picked from several), the Rigol does not support RMS measurements and it apparently never did even when it was working.  I do not know what the automatic RMS measurement is measuring, but it is not the RMS value of the signal.  To verify this, apply some Gaussian noise and measure the RMS value; it will be wrong.  Now I know *why* the RMS measurement is broken but I only recently discovered it after becoming increasingly suspicious; the processing necessary to produce the display record corrupts the RMS value and measurements are made on the display record.

And it is not like digital RMS measurements are difficult; they are trivial.  Calculate the standard deviation and you get the RMS value.  The icing on the cake is that an *analog* oscilloscope can make this measurement to high accuracy.  I expect my Ford Fiesta to carry my ESI 250DA impedance bridge as cargo just as well as other much older vehicles that I have used.

As I said, it honestly never occurred to me to look at a rise time without zooming in on the wave. Isn't it 100% natural to zoom in and look at the rising edge when you measure it? Make sure there's nothing weird there? 

It is natural to do this for the very reason you identify; to know exactly what is being measured gives confidence in the measurement.  Oscilloscopes are particularly useful tools in this respect.

On the other hand if the measurement changes when it should not, that undermines confidence.  The DSOs I have used made accurate transition time and other measurements over a broad range of time/div and volt/div settings; if a weird result was produced, it was always because the signal was weird and not because of the instrument.  They even tailored the number of significant digits reported to reflect the measurement precision.

Doesn't the Rigol position control shift the ground level?  Position controls usually operate as offset controls with the position signal added before the digitizer.  The difference is whether the signal is added before or after the attenuators.

Screenshot attached how it works on Rigol.

That does not really show me how the Rigol position controls work.

Position controls work over a specified number of graticule divisions.  When the volt/div setting changes, the range of the position control in volts/div changes so the trace does not shift.  If the position control operates by injecting a signal directly before the digitizer instead of only adjusting the display, then it serves as a very coarse offset control increasing the input range of the DSO.

Offset controls inject a signal earlier in the signal chain before some or all of the attenuation and gain stages.  This increases the input range of the digitizer enormously which is important in some applications.  In an extreme case like the Tektronix 7A13 differential comparator, the offset control can operate over a range of 20,000 divisions (it really operates like the display is 20,000 divisions tall) while the position control still operates only over 12 divisions of an 8 division display.

I think people would be complaining if the Rigol's position control did not inject an analog signal before the digitizer and only operated through the display because the limited input range would be a major problem.  With a x10 probe yielding 50V/div, measuring the DC output of the input filter of an off-line switching power supply (340 volts DC) requires 7 divisions which is just within range of an 8 division oscilloscope (2) *if* the position control works as a fixed offset control.  If the position control only changes how the signal is displayed, then the DSO would require 14 vertical divisions.
 
(1) Of course car manufactures do this all the time.  That is why I hope to have nothing to do with GMC ever again.

(2) I am well acquainted with this measurement because with 1 or 2 very old exceptions, all of my analog and digital oscilloscopes have 8 vertical divisions and just barely make this measurement using only their position controls.  I would be surprised if any DSO trying to stay out of the toy catagory cannot do this.  Some of my oscilloscopes can make this measurement to very high precision and accuracy using their offset controls; a 7A13 can make a 340 volt DC measurement at 100mV/div.

[Fungus]

Offset controls inject a signal earlier in the signal chain before some or all of the attenuation and gain stages.

You can see the Rigol doing this when you run the calibration. The traces move up and down the screen looking for 'zero'.

[tautech]

Then you could spend all your time complaining it was too slow, right? 

Well I'm just learning about my new DSO. Seems indeed it's some new kind of DSO, I will name it SCREEN SAMPLING DSO, yeah    Sadly in the manual does not teach how to account for differences compared to normal DSO operation. You see I've used only normal ones so far and when buying this one was looking only at analog bw, memory sample rate and channel count. But there's another and unique param - "screen sampling rate" - very important for risetime auto-calc!

So now I must create helper formulas and tables to navigate around it's limitations. Would much prefer for it just to be slow. Slow computes well with measurement instrument. Readings off by 4 orders of magnitude do not (in the situation where normal DSO wouldnt be even stretched).

We don't know that with 100% certainty but that's what we observe and it makes sense to do it that way.

Let's observe some raw data then. I adore raw data, it makes s*it float
Reports attached below.

Short summary:
Fed 10Vpp, 32768Hz 50% duty square signal into Rigol DS1000Z and my old PicoScope 2205 MSO (25MHz, 2ch+16ch, 2013 out of prod model).
In case of normal DSO it can be seen readings reflect the nature of signal rather well. Lowest sampling rate observed at the 5ms timebase was 0.9804MS/s.
However in the case of "screen sampling" DSO it can be seen that despite hardware superiority it's readings are up to 4 orders of magnitude off. Despite running at massive 125MS/s at 5ms timebase in reality it's "screen sampling rate" for risetime calculation is only 0.005MS/s. Does a bit better with period calculation, only by about order of magnitude off.
So clearly it cannot be used anything like normal DSO. But then manual should reflect it. Customer is not to be expected reading forums for weeks when buying equipment.

rf-loop has duplicated your risetime tests with a X series Siglent for comparison here:
https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg1091032/#msg1091032

[Fungus]

rf-loop has duplicated your risetime tests with a X series Siglent for comparison here:
https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg1091032/#msg1091032

So... Rigol does it, Siglent does it, Keysight does it. It seems that this is the way DSOs work. 

(ntnico's sig is correct when it says, "There are small lies, big lies and then there is what is on the screen of your oscilloscope.")

PS: Other 'scope owners are still invited to participate in this. Just connect the probe to the test signal and zoom in/out. Does the displayed "rise time" change?

Anybody here own an R&S? Where are the a GW-Instek owners when you need them...?

[rf-loop]

So... Rigol does it, Siglent does it,...

Yes, and difference is only small "nitpick" class difference.  1 vs 100

[Fungus]

So... Rigol does it, Siglent does it,...

Yes, and difference is only small "nitpick" class difference.  1 vs 100

Is the number correct? No.

(and honestly, if it's going to be incorrect then less correct is better - it stands out more...)

[rf-loop]

and honestly, if it's going to be incorrect then less correct is better - it stands out more...

 

Best of day. But it is good: old peoples say that "laughing makes you live longer".

[MrWolf]

OMG, then I've been using technology of the gods thinking it's normal human tech! It's like seeing forest miles away and having capability to count all the needles in an instant... 
Originally I bought Picos for doing work on experimental electric motor. There it proved extremely useful to monitor both slow (mechanical) and fast (electrical) processes at the same time to a high accuracy. I had no idea that this capability is beyond state of the art in DSOs... But yolo, enuff cockfighting 

Since "Wolfs test" seems to characterize scope capabilities rather well (in fact much better than datasheets) and there is some public interest. What if I do separate thread with clear instructions how to do test and ready-to-download unfilled tables?

[Fungus]

and honestly, if it's going to be incorrect then less correct is better - it stands out more...

Best of day. But it is good: old peoples say that "laughing makes you live longer".

I'm perfectly serious.

(and one day you'll realize I'm right....)

[Fungus]

Since "Wolfs test" seems to characterize scope capabilities rather well

Not really.

It should be somewhere very close to the bottom of the list if you're making a purchasing decision.

[MrWolf]

The only way this "debate" would be interesting is if we examined a whole load of other oscilloscopes to see which ones do this and which ones don't. At what price range do they start to do it 'properly'? etc.

  ...but next thing you say...

It should be somewhere very close to the bottom of the list if you're making a purchasing decision.

Purchasing decision? Are you a salesman or something? 
What if you already purchased something and just want to know it's real specs regarding auto-measurements?
I'll be damn interested what is actual precision of my instruments since in scope business it seems
to be norm to forget "<" sign before measurement value where acutely needed...
Multimeters etc do it in even more logical way. Usually they just start lowering reading precision (count) and
finally display "out of range".

[Fungus]

It should be somewhere very close to the bottom of the list if you're making a purchasing decision.

Purchasing decision? Are you a salesman or something? 

I forgot, you're new here.

The way it works here is:
a) A newbie comes in and asks what 'scope to buy for $400
b) A few people reply "The DS1054Z"
c) All the DS1054Z haters say "Oh suuuure, so long as you don't want to measure rise times (snigger)".
d) I say "Ignore the haters, they're not telling the truth!"
e) I get accused of being a crazy DS1054Z fanboi.
f) Signal to noise ratio tends towards zero.

[ebastler]

Hey all,

This thread originally started as a pretty concise collection of bug reports and improvement suggestions for the DS1000Z scope family.  I think we had hopes that Rigol actually reads it, and takes some cues from it. (And they may actually have done so!)

Yet, this has increasingly morphed into yet another "Rigol is fine" vs. "Rigol sucks" thread. Three full pages so far on the question whether or not it is critical that measurements are derived from on-screen data only... 

Can't we move this type of discussion to separate threads, or to the general DS1054Z rant/question monster thread? Please?

Regards,
Juergen

[Fungus]

What if you already purchased something and just want to know it's real specs regarding auto-measurements?

Objectively characterizing things is good.

Listing only the bad things? Going on endlessly about things with only 0.001% real importance? Not so much.

I'll be damn interested what is actual precision of my instruments since in scope business it seems
to be norm to forget "<" sign before measurement value where acutely needed...

I agree that it could probably display "?zoom" or something.

I've never said the DS1054Z is perfect, just that it's the best all-round value for money under ~$1200.

That's quite something when you only paid $400 for it, IMHO.

[nctnico]

rf-loop has duplicated your risetime tests with a X series Siglent for comparison here:
https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg1091032/#msg1091032

So... Rigol does it, Siglent does it, Keysight does it. It seems that this is the way DSOs work. 

(ntnico's sig is correct when it says, "There are small lies, big lies and then there is what is on the screen of your oscilloscope.")

PS: Other 'scope owners are still invited to participate in this. Just connect the probe to the test signal and zoom in/out. Does the displayed "rise time" change?

Anybody here own an R&S? Where are the a GW-Instek owners when you need them...?

On my GDS2204E the risetime measurement is pretty much constant unless the timebase gets to >200us/div with 10Mpts record length and a 5MHz square wave (approx. 7ns risetime). At that point the samplerate is still 1Gs/s so it shouldn't matter but it does.

[Fungus]

Anybody here own an R&S? Where are the a GW-Instek owners when you need them...?

On my GDS2204E the risetime measurement is pretty much constant unless the timebase gets to >200us/div with 10Mpts record length and a 5MHz square wave (approx. 7ns risetime).

So.... it isn't constant. Is that what you're saying?

At that point the samplerate is still 1Gs/s so it shouldn't matter but it does.

Yes, that's the point of this test.

[MrWolf]

This thread originally started as a pretty concise collection of bug reports and improvement suggestions for the DS1000Z scope family.

Good point. So heres a bug:

Signal:
32768Hz square wave, 1Vpp, <10ns rise, low jitter.
Timebase: 5us
Acquire mode: Average
Averages: 1024
Mem depth: Auto
Enable "Rise" auto-measurement with stats.
Reset stats, take note of Min, Max, Avg.
Enable zoom.
Zoom to 5ns timebase.

Due to specific inner workings of device Max value stays on "unzoomed" 200ns, Min gets precise "zoomed" value of 8.9 and Avg gets spot in the middle...

[Howardlong]

Did you try resetting your stats after zooming?

This is an artefact of the previous problem you described, although I agree it would make sense for the stats to auto-reset after any change in measurement sampling rate. Whether averaging is on or not makes no difference.

Keysight x3000 series won't even collect stats if a measurement is undersampled or out of range. The Tek MDO3000 still collects stats but displays "Low Resolution". It resets stats on a change of sample rate.

Interestingly, on the vertical, the Rigol does reset stats automatically when it clips.

[Fungus]

This thread originally started as a pretty concise collection of bug reports and improvement suggestions for the DS1000Z scope family.

Good point. So heres a bug:

Due to specific inner workings of device Max value stays on "unzoomed" 200ns, Min gets precise "zoomed" value of 8.9 and Avg gets spot in the middle...

'Minimum' and 'maximum' are supposed to remember the minimum and maximum values they've seen. It would be a bug if they reset when you zoom in, not the other way around.

This is an artefact of the previous problem you described, although I agree it would make sense for the stats to auto-reset after any change in measurement sampling rate.

I think the opposite - it makes more sense not to reset them.

Resetting them potentially destroys information. Pressing 'reset stats' to manually restart them is the way to go.

[Howardlong]

This thread originally started as a pretty concise collection of bug reports and improvement suggestions for the DS1000Z scope family.

Good point. So heres a bug:

Due to specific inner workings of device Max value stays on "unzoomed" 200ns, Min gets precise "zoomed" value of 8.9 and Avg gets spot in the middle...

'Minimum' and 'maximum' are supposed to remember the minimum and maximum values they've seen. It would be a bug if they reset when you zoom in, not the other way around.

This is an artefact of the previous problem you described, although I agree it would make sense for the stats to auto-reset after any change in measurement sampling rate.

I think the opposite - it makes more sense not to reset them.

Resetting them potentially destroys information. Pressing 'reset stats' to manually restart them is the way to go.

The problem to my mind is that it's contaminating two differently extracted sets of data, so it's throwing apples and oranges into the same basket, making the result even more nonsensical.

Irrespective, whether it's a bug or a feature, it's never been something that has been of any particularly conscious concern for me. If I see, say, a nice round number like 200.0ns in a measurement, I am naturally and automatically going to be suspicious, and know it's time to question that number and make sure I understand why.

Once you've experienced, learned and understood how the instrument works and its limitations, something like this is not really a problem in practical terms, or even something to get irritated about. Whether it's a $400 or a $400,000 machine, you always need to be able to know when something doesn't look right, if you don't question your results and measurements then you're almost certainly not doing it right!

I'd say that at some point, say beyond the $50,000 price point, you are _more_ likely to find bugs because the gene pool of users and experience is so much smaller, and those units will not have been characterised to anywhere near the same extent as a $1,000 instrument.

[Fungus]

If I see, say, a nice round number like 200.0ns in a measurement, I am naturally and automatically going to be suspicious, and know it's time to question that number and make sure I understand why.

Yep.

Once you've experienced, learned and understood how the instrument works and its limitations, something like this is not really a problem in practical terms, or even something to get irritated about.

Hence my earlier comment (which was mocked by some people), "If it's going to be wrong, I prefer it to be very wrong."

50% wrong is far more dangerous than 5000% wrong.

Whether it's a $400 or a $400,000 machine, you always need to be able to know when something doesn't look right

With experience you learn to look at what's on screen as well as what the number says.

You should only think "OK" when they both match (and the number makes sense).

Maybe this is a benefit of learning with analog 'scopes. With analog 'scopes you learn to look at the screen and count the squares.

[MrWolf]

Irrespective, whether it's a bug or a feature, it's never been something that has been of any particularly conscious concern for me. If I see, say, a nice round number like 200.0ns in a measurement, I am naturally and automatically going to be suspicious, and know it's time to question that number and make sure I understand why.

Well depending on your background. Z box price is clearly in "complete noob" class. When I bought my first (very cheap and "nooby"!) DSO I had interest only in project on my desk and could not care less about inner workings of DSO. I had multimeters costing more than that DSO, but 25MHz was plenty enough for the task so why pay more? It took maybe a year before I paid any attention to "sampling rate" concept and many other "DSO specific" things. My project was highly experimental and it would have failed totally if my DSO wouldnt be programmed in extremely honest way and displayed "no reading" on wrong settings for the task etc.
Bottom line: In its current state DS1000Z requires very skilled operator to deliver. It can be considered more a "poor pro DSO" than "noob DSO". I thinks thats a problem for young players. What if someone is also doing something totally insane but very interesting and will think concept failed, while actually DSO played some little tricks on him like some gypsy on the flea market?
Noobs need DSOs programmed in extremely dry and "metrological" manner. I suspect Digilents Analog Discovery 2 might be fine example. I cannot see why theres such acute reaction by some against getting DS1000Z into same "dry and metrological" condition. Cannot see any limitation hardware-wise 

[David Hess]

Offset controls inject a signal earlier in the signal chain before some or all of the attenuation and gain stages.

You can see the Rigol doing this when you run the calibration. The traces move up and down the screen looking for 'zero'.

Dave's reversed engineered schematics of the Rigol DS1000Z input circuits do not extend to the integrated switched gain amplifier and digitizer.  What he shows as a vertical position control may actually be for balancing the offset into the switched gain amplifier.

It is possible that they used that circuit also for the position control but we cannot know without seeing more of the schematic.  That would mean that part of the calibration is to allow an offset adjustment to operate as a position control because gain changes would change the position control gain and hence range.

[Fungus]

Bottom line: In its current state DS1000Z requires very skilled operator to deliver.

Complete and utter rubbish.

All it takes somebody who does the perfectly natural thing of setting the timebase to actually look at the rising edge they're measuring. The 'scope has been on the market for two years and nobody else has even noticed this. That's how anti-intuitive you're being.


b) You're judging the whole 'scope based on one particular thing?? 

c) You're still pointing your finger squarely at the DS1054Z even though we've seen that most other 'scopes do it, too. 

[David Hess]

b) You're judging the whole 'scope based on one particular thing?? 

I have a whole list of complaints.  The thing I like about finding problems with the Rigol DS1000Z series is that it trains me for what to look for in modern DSO.  I used to just check for peak detection capability and transient response.  Now I include RMS measurements of noise and weird display record measurement problems.

c) You're still pointing your finger squarely at the DS1054Z even though we've seen that most other 'scopes do it, too. 

I do not care if other DSOs do it or not; if they do, then they are broken as well.  Them being broken does not fix the Rigol and my criteria for working properly does not include everybody else's product is broken also.

If I had to pick two things wrong with the Rigol right now, they would be the broken RMS measurement capability which would require making measurements on the acquisition record to fix and the transient response.  The later seems to indicate that the oscilloscope does not support a 100 MHz bandwidth do to slew rate limiting or something; maybe a stage is saturating or going into cutoff.  This issue might not be present in the 50 and 70 MHz models because of their more limited bandwidth.

[metrologist]

If I had to pick two things wrong with the Rigol right now, they would be the broken RMS measurement capability which would require making measurements on the acquisition record to fix and the transient response.  The later seems to indicate that the oscilloscope does not support a 100 MHz bandwidth do to slew rate limiting or something; maybe a stage is saturating or going into cutoff.  This issue might not be present in the 50 and 70 MHz models because of their more limited bandwidth.

I thought the RMS measurement issue was fixed in last (pulled) FW. Also, transient response, I thought you made the comment about an MSO1074Z measurement we saw on youtube. I did not see a problem when trying to test mine.

[nctnico]

Irrespective, whether it's a bug or a feature, it's never been something that has been of any particularly conscious concern for me. If I see, say, a nice round number like 200.0ns in a measurement, I am naturally and automatically going to be suspicious, and know it's time to question that number and make sure I understand why.

Well depending on your background. Z box price is clearly in "complete noob" class. When I bought my first (very cheap and "nooby"!) DSO I had interest only in project on my desk and could not care less about inner workings of DSO. I had multimeters costing more than that DSO, but 25MHz was plenty enough for the task so why pay more? It took maybe a year before I paid any attention to "sampling rate" concept and many other "DSO specific" things. My project was highly experimental and it would have failed totally if my DSO wouldnt be programmed in extremely honest way and displayed "no reading" on wrong settings for the task etc.
Bottom line: In its current state DS1000Z requires very skilled operator to deliver. It can be considered more a "poor pro DSO" than "noob DSO". I thinks thats a problem for young players. What if someone is also doing something totally insane but very interesting and will think concept failed, while actually DSO played some little tricks on him like some gypsy on the flea market?

You are totally over reacting here! My $25k Agilent DSO7104A also measures using screen data and if you dig even deeper into an oscilloscope you'll find it can show the weirdest signals. For example: when I evaluated my GW Instek GDS2204E I could make it to show very weird signals using some setting and a certain input signal. When I told GW Instek how I produced the result they send me a screendump of their Tektronix scope (IIRC 3000 or 4000 series so not low end) which showed a similar effect. I then tested on my DSO7104A and I was able to reproduce the effect on that scope as well. My test was stretching the limits too far.

The bottom line is: You have to know what the outcome is before you make the measurement. Otherwise you have no idea whether the result is correct or not. You can't go around sticking probes into a circuit and take what is being displayed at face value.

[Fungus]

I do not care if other DSOs do it or not; if they do, then they are broken as well.  Them being broken does not fix the Rigol and my criteria for working properly does not include everybody else's product is broken also.

That's like saying that a Ford Fiesta is broken if it can't do 200mph and the fact that none of its competitors can do 200mph either isn't an excuse.

If I had to pick two things wrong with the Rigol right now,

Out of curiosity, how many things can you pick that are right with it?

[David Hess]

I thought the RMS measurement issue was fixed in last (pulled) FW. Also, transient response, I thought you made the comment about an MSO1074Z measurement we saw on youtube. I did not see a problem when trying to test mine.

The RMS thing is a different problem we ran across in a recent discussion where we tried to test the analog versus DSO noise difference.  I think what is going on is that the processing to produce the display record alters the standard deviation of the signal, which is not surprising, but it was a confirmation to me that measurements are made on the display record which I did not want to believe before.  If you use RMS to measure noise on this DSO, it returns the wrong value; it is not even close.

For the transient response, I said the test was ambiguous in the Youtube video because we do not know the state of the feedthrough termination which was not used on any other oscilloscope.  Later I was doing some transient response measurements and it occurred to me that transient response anomalies are limited by the vertical bandwidth; you cannot create nonlinearities which would add high frequency content with transient response misadjustments.  Ok, that makes sense.  But the results from the video do not seem to show that.  If the feedthrough attenuator was bad, it should not produce that weird slant in the signal edge.  What that waveform *does* look like is nonlinear distortion caused by an amplifier driven into cutoff or saturation or distortion during overload recovery.

Now Dave identified the transistors in the first differential stage of the DS1000Z as MMBT3904s and Rigol had to use emitter networks to boost the high frequency gain.  That makes sense in comparison to much older 100 MHz oscilloscope vertical amplifier designs which had the 2N3904 available but did not use them.  They either used faster transistors or they graded the 2N3904s for low base transit time (how is this done?) which suggests to me that those transistors are just not fast enough.  That weird cross coupled differential cascode looks suspicious to me but maybe the differential tail current is low.  Why is the differential tail current even adjustable?

So why didn't this show up in your test?  Maybe Rigol grades these oscilloscopes like 2N3904s were graded in vertical amplifiers; if this is the case, the behavior would not show up in stock 100 MHz units.  Or maybe your test signal was not fast enough to produce the behavior.

So the transient response thing might not be a flaw, but it sure looks like one based on the performance and the design unless it only shows up in Rigol's hacked for higher bandwidth.

I do not care if other DSOs do it or not; if they do, then they are broken as well.  Them being broken does not fix the Rigol and my criteria for working properly does not include everybody else's product is broken also.

That's like saying that a Ford Fiesta is broken if it can't do 200mph and the fact that none of its competitors can do 200mph either isn't an excuse.

I do not *expect* automobiles to do 200mph unless I specifically bought them for that application.  200mph automobiles are rare.

I also do not expect the Rigol or any analog oscilloscope or DSO to have the fast overload recovery of a digital storage sampling oscilloscope or any sampling oscilloscope so that fact that its overload recovery is horrible is irrelevant.  Analog and digital sampling oscilloscopes are rare.

If I had to pick two things wrong with the Rigol right now,

Out of curiosity, how many things can you pick that are right with it?

I can simplify the answer to it is better than an even worse DSO.  I do not see it as a general purpose DSO because of its limitations.  I came to the same conclusion about Rigol's earlier DSOs.

I have got a question though.  Does making measurements on the display record mean that the Rigol actually has a record length of (checks manual, 600x800 display) 12 horizontal divisions * 50 points/division (estimated) = 600?  Is the long record length only available when acquisitions are stopped?  Wouldn't that make it like the early Tektronix DPOs?

[Karel]

Does making measurements on the display record mean that the Rigol actually has a record length of (checks manual, 600x800 display) 12 horizontal divisions * 50 points/division (estimated) = 600?  Is the long record length only available when acquisitions are stopped? 

The display memory contains 12 div. x 100 = 1200 pts. These 1200 pts can be aquired via usb or lan at any moment without
stopping the acquisition.
Stopping the acquisition is only necessary for downloading the deep memory waveform data e.g 24Mpts.

[Fungus]

I have got a question though.  Does making measurements on the display record mean that the Rigol actually has a record length of (checks manual, 600x800 display) 12 horizontal divisions * 50 points/division (estimated) = 600?  Is the long record length only available when acquisitions are stopped?  Wouldn't that make it like the early Tektronix DPOs?

The programming guide uses numbers in the range 0 to 1199 for setting start/end points. This suggests it works with 2 samples per pixel (600x2 = 1200 points).

[MrWolf]

The bottom line is: You have to know what the outcome is before you make the measurement.

Would that make you... god? Or policmean that spotted red 3-series BMW with big wing that just must to be speeding, and if not now then in future for sure, so better to ticket now 

c) You're still pointing your finger squarely at the DS1054Z even though we've seen that most other 'scopes do it, too. 

Yes but they seem to either indicate reduced accuracy or at least use some reasonable sized secondary buffer. Siglent SDS1102X+ seems to have 10kpts horizontal resolution for end-user. If to be compared to Rigol, around 40kpts buffer then instead of 1.2kpts? Edit: In fact buffer is even bigger according to rf-loop here  :
https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg1092595/#msg1092595

And since you seem to suggest that I have sort of "attitude problem"... Did you failed to notice that I filed bug reports also on Siglent SDG2000X? After short and very constructive discussion it was all settled.
If we would have similar 5+ reps here from Rigol it would be all fine and civilized, but instead we have who... you? And you seem not to be a rep because they know that customer is always upwind when you try to take a piss on him.
In fact I personally always highly regarded customers who give feedback (even negative) on my product/system. Can hire fewer testers then 

The programming guide uses numbers in the range 0 to 1199 for setting start/end points. This suggests it works with 2 samples per pixel (600x2 = 1200 points).

Yes but actual data suggests 300pts end-user resolution. Aliasing effect on further processing on these points?

[nctnico]

The bottom line is: You have to know what the outcome is before you make the measurement.

Would that make you... god?

No, a good engineer! A good police officer usually knows from experience if a car is speeding or not (and a ball park figure on the speed) in order to pick the ones he/she measures with the lidar. In this case the measurement is also a confirmation of something which is already known.

[tautech]

Siglent SDS1102X+ seems to have 10kpts horizontal resolution for end-user. If to be compared to Rigol, around 40kpts buffer then instead of 1.2kpts? Edit: In fact buffer is even bigger according to rf-loop here  :
https://www.eevblog.com/forum/testgear/siglent-sds1000x-series-oscilloscopes/msg1092595/#msg1092595

Just to be sure you're clear that there's 3 different models from 3 series of Siglents in risetime measurement tests ATM.
SDS1102CML+, SDS1202X and SDS2304X, all with significantly different specs.
Just be sure you're quoting the right one. 

[rf-loop]

Just to be sure you're clear that there's 3 different models from 3 series of Siglents in risetime measurement tests ATM.
SDS1102CML+, SDS1202X and SDS2304X, all with significantly different specs.
Just be sure you're quoting the right one. 

We know what is this test but I want here note for some  random readers.
These some tests shown are  not at all for evaluate Siglent scope risetimes.




Generally:

These particular tests are for get bit more knowledge about automatic measurements system technical "features" and this is generally important and interesting thing, independent of scope manufacturer and brand and model. 

And for example this purpose I have used externally controlled rise and fall times what are far slower than oscilloscope limits because I need data for estimate amount of data used for automatic measurements and for also proof that even with deep memory, every sample is mapped to display (I can count sample points when I look edges when I use  slow wfm/s acquisition mode where every displayed TFT refresh have only single shot wfm, so I can proof all samples are mapped to display but not all is used for measurements).  And some of these features can not read from data sheet. Example about automatic measurements resolution with different memory and timebase settings. There is  nothing in data sheets. So, user need evaluate these (if want do also more serious things than just looking strange and fun images about electrical phenomenons.)    Just for "know your equipments" -- for better confidence and better understanding results and for avoid mistakes.
This is why this kind of tests are important and useful.

[David Hess]

I have got a question though.  Does making measurements on the display record mean that the Rigol actually has a record length of (checks manual, 600x800 display) 12 horizontal divisions * 50 points/division (estimated) = 600?  Is the long record length only available when acquisitions are stopped?  Wouldn't that make it like the early Tektronix DPOs?

The programming guide uses numbers in the range 0 to 1199 for setting start/end points. This suggests it works with 2 samples per pixel (600x2 = 1200 points).

Is it returning 16 bit values?

Alternatively it could be setup to return minimum and maximum values when peak detection is used.  On my DSOs, the record length is halved when peak detection is used which is annoying but acceptable since they have such high resolution anyway.

Otherwise it seems odd that the display would be 600 wide while the returned data is 1200 wide.

[Karel]

Is it returning 16 bit values?

No, 8 bit.

[Fungus]

Otherwise it seems odd that the display would be 600 wide while the returned data is 1200 wide.

Why? They might have done it to get a teeny bit more accuracy in the on screen calculations (rise times, etc). It makes perfect sense to do that if you've got a bit of CPU time left over.

[David Hess]

Is it returning 16 bit values?

No, 8 bit.

Otherwise it seems odd that the display would be 600 wide while the returned data is 1200 wide.

Why? They might have done it to get a teeny bit more accuracy in the on screen calculations (rise times, etc). It makes perfect sense to do that if you've got a bit of CPU time left over.

My guess then is that it either has something to do with peak detection which to make full use of the 600 horizontal point display would require a 1200 point record or something do to with rendering the index graded display like antialiasing.

If it has to do with peak detection which I think is the most likely option, then it will be easy to determine; check to see if the number of horizontal display points is halved when peak detection is used.  In order for that to work with a 600 point display without halving the horizontal resolution, the digitizer has to return 1200 point records and it probably always does that.  The design is just simpler that way.

[Karel]

If it has to do with peak detection which I think is the most likely option, then it will be easy to determine; check to see if the number of horizontal display points is halved when peak detection is used.

It always returns 1200 pts, also in peak det. mode.

Offtopic, what I personally find strange is, why it uses a vertical resolution of only 25 lsb's per division.
For comparison, the DS6000 uses 32 lsb's per vertical division and thus uses the full dynamic range of the ADC for the display.

Edit: Found some info here:

https://rigol.desk.com/customer/en/portal/articles/2282294-why-does-my-data-not-appear-to-have-8-bits-of-resolution-

[ebastler]

Offtopic, what I personally find strange is, why it uses a vertical resolution of only 25 lsb's per division.
For comparison, the DS6000 uses 32 lsb's per vertical division and thus uses the full dynamic range of the ADC for the display.

Not further off topic than the last 3 pages of this thread... 

I think the DS1000Z's vertical resolution has been discussed on this forum before. Rigol seems to have mapped 200 ADC counts to 400 pixels vertically. The integer conversion factor probably helps in driving the display with limited FPGA resources.

[David Hess]

If it has to do with peak detection which I think is the most likely option, then it will be easy to determine; check to see if the number of horizontal display points is halved when peak detection is used.

It always returns 1200 pts, also in peak det. mode.

But it cannot return a 1200 point peak detected record in 1200 8-bit words; it would take 2400 words.  I assume the FPGA always returns a 1200 word record but in peak detect mode, the record is composed to 600 pairs and in normal mode, it is 1200 separate points.  At least that is how other DSOs handle it.  By returning a record which is twice as long as necessary in normal mode, peak detection mode does not visibly halve the horizontal resolution.

There is no reason the FPGA could not return different record lengths for different modes but it is an added complication which is not needed for a questionable increase in performance.

Offtopic, what I personally find strange is, why it uses a vertical resolution of only 25 lsb's per division.
For comparison, the DS6000 uses 32 lsb's per vertical division and thus uses the full dynamic range of the ADC for the display.

Lots of DSOs work this way.  An integer mapping of LSBs to display pixels prevents unneeded processing and aliasing.  Further having the digitizer range exceed the displayable screen size prevents clipping during some types of processing although I am unclear if the Rigol can take advantage of this.

I have seen and mostly used DSOs which use 25, 40, 50, 100, and 102.4 points per vertical division.  Resolution in excess of that necessary to display 8-bit data operates on 16 bit data when averaging, high resolution, or DPO modes are used

[MrWolf]

I did  the weird thing... switched on Diff math function:

For square there was flat line initially but cranking up scale did show something:


Switched to 100MHz sine. Again cranking up scale produced some pixellated stuff. Took auto-measurement off it: 32MVpp/s


Further down the menu discovered "Smooth" with minimum setting of 3:


Cranked "Smooth" setting up to 21 and got new auto-measurement value off 85.9MVpp/s (original signal still the same!):


Switching Auto Scale ON/OFF did not help.

So dunno, isnt the diff for 100MHz, 1Vpp sine supposed to be in the 1.2GVpp/s vicinity?
Or the "Smooth" is working other way around - smaller value means more "Smooth"  but why "pixels" then...

[Karel]

But it cannot return a 1200 point peak detected record in 1200 8-bit words; it would take 2400 words.

The peak detect acquisition mode is used to help discover if any “interesting” sample points would be lost in the
aforementioned sample mode. Here, the highest and lowest peaks from adjacent pairs of sample intervals are
saved and put into memory. Thus, any abnormal high or low values, glitches, etc. will be clearly captured in the waveform
memory so that further investigation of these anomalies is possible. In this mode, there isn’t any data loss, but the
precise waveform shape will be somewhat obscured by the high/low value envelope.

source: http://www.tek.com/blog/sample-processing-digital-oscilloscope

So, 1200 samples in peak detect mode is correct.

[TurboTom]

@MrWolf
It's been discussed in detail already, have a look here: https://www.eevblog.com/forum/testgear/rigol-ds1054z-how-to-get-_maximum_-positive-slew-rate/

The Diff function on all the recent rigol oscilloscopes is unusable where the "baseline" model (DS1000Z) still offers the best performance while the "advanced"  models are even worse -- same as the FFT.

It seems Rigol makes most of their revenue with their basline models so no need to take care of improvements for the the DS2000 and DS4000 series...

Cheers,
Thomas

[David Hess]

But it cannot return a 1200 point peak detected record in 1200 8-bit words; it would take 2400 words.

The peak detect acquisition mode is used to help discover if any “interesting” sample points would be lost in the
aforementioned sample mode. Here, the highest and lowest peaks from adjacent pairs of sample intervals are
saved and put into memory. Thus, any abnormal high or low values, glitches, etc. will be clearly captured in the waveform
memory so that further investigation of these anomalies is possible. In this mode, there isn’t any data loss, but the
precise waveform shape will be somewhat obscured by the high/low value envelope.

source: http://www.tek.com/blog/sample-processing-digital-oscilloscope

So, 1200 samples in peak detect mode is correct.

I know how peak detection works in detail.  The question was exactly how Rigol implements it.

Earlier Fungus posted:

The programming guide uses numbers in the range 0 to 1199 for setting start/end points. This suggests it works with 2 samples per pixel (600x2 = 1200 points).

The mystery is why 1200 samples are used for a 600 point wide display instead of 600.  My hypothesis is that 1200 samples are used so that peak detection is supported without halving the displayed horizontal resolution.  It may have been easier to always have the FPGA return 1200 samples for every acquisition than 600 or 1200 samples depending on the mode.

[Karel]

Just posting this so maybe Rigol wakes up...

Apply the same test signal to inputchannels 1 & 2 (e.g. a squarewave of 1MHz).
Set the timebase to 50 nanoSec.
Set the memory depth to 600 Kpts.
acquire the waveform and set the scope to STOP mode.

At this point, everything is still ok.

Now download the waveforms of both channels
(in this example I use DSRemote/Wave Inspector but there's plenty of other software that can do the same).

Compare the downloaded waveform with the screen waveform... big fail.

This has been reported to, and confirmed by, Rigol in February 2016. So far, they didn't fix it.

[David Hess]

Going by the graticule and sample rate, the horizontal displacement is about 60 points which unfortunately does not seem to match up with anything.

Is there a vertical displacement as well or was the signal offset changed?

[MrWolf]

Going by the graticule and sample rate, the horizontal displacement is about 60 points which unfortunately does not seem to match up with anything.

How not match? 600,000 samples, 60 sample error. 10,000x ratio. Must run out of precise mem address bits doing port from mahjong 

[TheoB]

Mr kwass is not updating the index of this thread to keep track of reported/found bugs.
You may wonder why the community should want to do that at all (just for fun I guess?). Rigol should mention the issues that are known but not fixed. It would give me somewhat more confidence in the supplier.

I also have reported a bug which was confirmed. I hope this new firmware solves it.

I reported a bug for the DS1054z at Rigol. At least I think it is a bug. The math-filter functions seems to not work at the entered frequencies (lowpass/highpass/bandpass/notch). As an example I want to filter 1kHz and set the lower limit to 750Hz and the higher limit to 1250Hz. I then get a bandpass filter around 500Hz . Same with low pass. If I specify 20kHz then I find the low pass edge (-3dB) roughly around 8.9kHz.
I don't run the latest version of the firmware (00.04.03.SP2) but I have also not found anyone reporting this. So I prefer not to update (yet).
To repeat (with a 1kHz sine at the input):

Code: [Select]

$ cat filter_bandpass.scpi
:TIMebase:MAIN:SCALe 0.002
:MATH:OPERATOR FILTER
:MATH:FILTer:TYPE BPASS
:MATH:FILTer:W1 750
:MATH:FILTer:W2 1250
:MATH:DISPlay ON
cat filter_bandpass.scpi > /dev/usbtmc


The Rigol engineer promised me that I would receive an update when this would be solved:

I saw this behavior also on my unit. I reported it to our R&D department
and asked them to correct it for next firmware update.

When I get a feedback I will communicate with you the date when the next
firmware update will be available.

[Karel]

Is there a vertical displacement as well or was the signal offset changed?

Yes but that was caused by me, I made some error during experimenting.
Didn't influence the problem though.
I fixed & replaced the screenshots.

[David Hess]

Is there a vertical displacement as well or was the signal offset changed?

Yes but that was caused by me, I made some error during experimenting.
Didn't influence the problem though.
I fixed & replaced the screenshots.

Now you can tell that the trigger position got displaced as well so there are two bugs shown.

[kazam]

This bug can be confirmed by me. Infuriating when you're trying to measure IQ output signals and compute complex ffts. The offset changed with timebase also.

I ended up getting a R&S RTE1024 and that works fine of course although I realize that is certainly not an option for everybody.

In my opinion rigol should just open source the firmware. It's not likely anyone can manufacture the hardware cheaper anyway. Also most people wouldn't risk running the firmware on unsupported hardware.

I'm not holding my breath though!

[Karel]

I ended up getting a R&S RTE1024 and that works fine of course although I realize that is certainly not an option for everybody.

For the price of an RTE1024 you can buy 20x DS1054Z ...

[RoGeorge]

Just posting this so maybe Rigol wakes up...

Apply the same test signal to inputchannels 1 & 2 (e.g. a squarewave of 1MHz).
Set the timebase to 50 nanoSec.
Set the memory depth to 600 Kpts.
acquire the waveform and set the scope to STOP mode.

At this point, everything is still ok.

Now download the waveforms of both channels
(in this example I use DSRemote/Wave Inspector but there's plenty of other software that can do the same).

Compare the downloaded waveform with the screen waveform... big fail.

This has been reported to, and confirmed by, Rigol in February 2016. So far, they didn't fix it.

1. This seems to affect only the downloaded data. On the oscilloscope screen, all the traces are synchronous.
2. Only data for channel 1 seems to be shifted in time relative to the other 3 channels. The other 3 channel appears to be all synchronous when downloading their waveform.
3. The time shift varies with the memory depth setting (somewhere between 20-70 data points, depending on Mem Depth)

Tested with FW 04.04.SP1

Does anybody else have synchronous downloaded waveforms for channels 2, 3 and 4, or is it just for this particular oscilloscope unit?

[Karel]

It's not just a matter of not beeing synchronous.
They must be all at the trigger point as well.

[Karel]

Another bug is the blatant USB spec violation:

Output of dmsg after connecting th scope to a pc:

Code: [Select]

usb 1-2: new high-speed USB device number 4 using ehci-pci
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
usb 1-2: config 1 interface 0 altsetting 0 bulk endpoint 0x3 has invalid maxpacket 64
usb 1-2: New USB device found, idVendor=1ab1, idProduct=04ce
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: DS1000Z Series
usb 1-2: Manufacturer: Rigol Technologies.
usb 1-2: SerialNumber: DS1ZA17040xxxx
usbcore: registered new interface driver usbtmc

A bulk endpoint in a high-speed device must have a max packet size of 512.

Depending on the combination of software (OS) and hardware (USB host controller on motherboard)
this causes connection problems.

[RoGeorge]

It's not just a matter of not beeing synchronous.
They must be all at the trigger point as well.

Yes indeed, they are all shifted in relation with the trigger point, and the saved waveform for channel 1 is also shifted in relation with the channels 2, 3, 4, but the saved waveforms for channels 2, 3 and 4 are not shifted between each other for my oscilloscope.

For what I am trying to do now, I don't need the exact location of the trigger point, but I need at least two channels that can save their waveforms well aligned in time relative to each other.

Can anybody please confirm if the saved waveforms for channels 2, 3 and 4 are aligned or shifted between each other?

[Karel]

Can anybody please confirm if the saved waveforms for channels 2, 3 and 4 are aligned or shifted between each other?

Will do that when I have some spare time. Holidays are over

[Karel]

Here are the results with all channels switched on and connected to the same signal:

[duracell]

I need an advice.

As I could read here, there were some bugs with DS1054Z.
Are they fixed now ?

I need a scope for 400 $.
Should I buy DS1052E or DS1054Z or something else.

Thank you very much for your opinion.

[ebastler]

As I could read here, there were some bugs with DS1054Z.
Are they fixed now ?

I need a scope for 400 $.
Should I buy DS1052E or DS1054Z or something else.

There may be a couple of bugs remaining, but none of them should stop you from buying a DS1054Z. It is not a perfect scope, but its limitations are by design, not due to bugs:

• The user interface can react a bit slowly when many curves are displayed and you e.g. move a trace around on the screen.
• All measurements (measuring e.g. rise time, frequencies etc. from the trace) and decoding of serial data streams are done on the screen data only and do not use the deeper sample memory. That makes the precision of timing measurements and the decoding dependent on the time resolution you have currently set on the screen, which can make handling a bit awkward (when using those functions).
• Build quality is very good, but some users get annoyed by the fan noise. Some (incl. me) also end up replacing the encoder for menu selection with one which has detents, to make it easier to select a desired menu item.
  

Whether or not these stop you from buying a DS1054Z is your personal choice. At the $400 price level (in Europe) you will not find a better scope in my opinion. Please don't buy the old D1052E, it is much more limited! 

BTW, please don't double-post on this forum. I just notice that you have posted the same question on the general DS1054Z thread.

[duracell]

Sorry for the double post and thank you very much for your response.

You (and the the kind guy from other thread (double post  ) gave me the all important infos I need to know.
So i made my final decision and will purchase tomorrow a DS1054Z.
Will come with impressions, as soon as it arrives.
 

[duracell]

I found this video on Youtube,



showing  DS1054Z freezing.

I gave the owner the advice to upgrade to firmware 00.04.04.01.01  2016/09/14
but it didn't help.

Because I today purchased the same scope, am little bit worried now.
Can this freezing showed in the video be fixed ?

[alsetalokin4017]

There is something seriously wrong with that scope. I've had 3 different DS1054z units in my lab thus far and none of them have been anywhere near that noisy. People have complained about the fan noise from the very beginning, and on the strength of those complaints I bought one of the quieter fans recommended when I ordered the scope in the first place-- but I never bothered to install it since the noise is negligible in my scope. But I think the noise from that scope is much greater even than what people complained about.

And I've identified and posted about a Freeze Bug that sometimes can make the scope start up in a "frozen" condition, but as far as I know only scopes with Boot Version 0.0.1.2 were affected, and the bug was fixed several firmware revisions ago.

It would have been helpful if the owner of the scope in that video showed the full system information screen.

You should not experience this problem, and if you buy your scope from a reputable vendor if you do you can return it for replacement with a good unit.

[duracell]

You should not experience this problem, and if you buy your scope from a reputable vendor if you do you can return it for replacement with a good unit.

 
thank you.

[Fungus]

showing  DS1054Z freezing.

That's a very old video - look at the date!

There was a freeze bug but it only affected a particular batch of 'scopes and it's been fixed now. You'll never see it.

PS: Would we really be recommending a scope that constantly froze? 

[technogeeky]

I don't know if Rigol does anything about suggestions or wishes, but I noticed that some consistency could be gained with a simple rule:

Every one of the six MENU buttons should cycle/toggle something.

Right now, the only button which works this way is Cursor.

• Measure should cycle through the Source selections. (CH1 -> CH2 -> CH3 -> CH4 -> MATH).
• Acquire should cycle through Acquire Mode settings. (Normal -> Peak -> Average -> High Res).
• Storage should cycle through Storage Type settings. (Picture -> Traces -> Waves -> Setups -> CSV -> Param).
• Cursor already cycles through Cursor Type settings. (Manual ->  Track -> Auto).
• Display should cycle through Persistence Time settings. (Min -> 100ms -> 200ms -> 500ms -> 1s -> 5s -> 10s -> Inf).

The only one I don't have a clear answer for is for Utility. I think the best choice would be to cycle through Auto Options (I didn't even know this existed...), but that menu would probably have to be re-worked.

Similarly, the Trigger MENU button could cycle through the SOURCE settings. *This may be a bad idea because it has to switch the relays in and out.


Agreement? Objections?

[bitseeker]

Being able to cycle through items instead of requiring the hand to be repositioned in order to operate the rotary encoder would be convenient. However, if consistency was a concern, Rigol might just remove the cycling behavior from the Cursor function, if it's the only outlier. 

[JPortici]

[i stand corrected. filter bug is solved]

(can we update the bug list at some point?)

[Karel]

The "multi-channel waveform data download bug" as described here:

https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg862373/#msg862373

has been resolved with fw 00.04.04.SP3.

The "USB packetsize bug" is still present.

[Fungus]

apparently there was a new update some days ago. in the changelog it is mentioned "fixed bug about filter". it was not

see my post: https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1178713/#msg1178713

And see everybody else's posts pointing out that it is:

https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg1179107/#msg1179107

[kwass]

Is anyone reading this list thread interested in taking over the maintenance of it?  I have not been using my ds1054z much and don't have the time to test and describe the bugs reported.

[BravoV]

For adopters , does the latest firmware affect the responsiveness ?

Or at least you can "feel" that its more sluggish at certain operation that you spotted by accident or frequent operations that you used to do.

[JPortici]

not really, if anything it seemes that it takes less time to capture screenshots

[BravoV]

Ok , thanks ! 

[Fungus]

For adopters , does the latest firmware affect the responsiveness ?

There's no concrete evidence that any of the firmwares have affected the responsiveness.

Suggestion:

If anybody here still has very old firmware it would be good to make some videos of it in operation and compare them with similar videos of the latest firmware (which I could make).

Connect up the test signal, enable one channel, move the trace up and down. Enable two channels, move the trace up/down. Enable four channels, move the trace up/down.

Even then it's quite subjective because a lot of the perceived response depends on how you use the controls. It's much better to 'twiddle' it, ie. make lots of small turns (which I've always done naturally which is maybe why I've never seen the response as a deal breaker).

If you do long continuous turns with no pauses then it's possible to get no response at all until you release the knob. If you're that sort of person who naturally does that then it probably feels much worse than it is.

I made a blurry video to show this:

[frozenfrogz]

I started a new thread for everything related to the latest firmware (from 00.04.04.03.02 onward), because this thread can no longer be maintained by the OP.
Please continue there and I will try to keep up with covering whatever issues will come along.

@Mods: Can we lock this thread to prevent forked replies?

[ebastler]

I started a new thread for everything related to the latest firmware (from 00.04.04.03.02 onward), because this thread can no longer be maintained by the OP.
Please continue there and I will try to keep up with covering whatever issues will come along.

@Mods: Can we lock this thread to prevent forked replies?

Thanks, frozenfrog! Maybe you could ask Katie to also put a link referring to the new thread in the original post here?

[Fungus]

Maybe a separate new thread for "wish list".

(Not that I believe Rigol reads this, can anybody yell Rigol to take a look?)

[kwass]

I started a new thread for everything related to the latest firmware (from 00.04.04.03.02 onward), because this thread can no longer be maintained by the OP.
Please continue there and I will try to keep up with covering whatever issues will come along.

@Mods: Can we lock this thread to prevent forked replies?

Thanks, frozenfrog! Maybe you could ask Katie to also put a link referring to the new thread in the original post here?

Done.