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

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