Rigol DS1000Z series buglist continued (latest: 00.04.04.04.03, 2019-05-30)

[TinkeringSteve]

Oh starting does work, the firmware apparently doesn't get to store that setting, it's back to "trace" when I start again.

No problems using FFT in memory mode.
Does your scope freeze every time / is it reproducible?
If it is persistent: Please try re-uploading the firmware as you already mentioned and if the error still remains, please share the extended system info for reference.

As to "does it always" - no - apparently not on CH1, but with at least CH2, when it's the only active channel, and I'm feeding in a sine @ 20 Hz, 3V with offset so that it's DC. And then set Mode to Memory.

[frozenfrogz]

My scope does not freeze - regardless of which channels are activated etc. I fiddled around with the active channels selection, input selection of FFT function, window mode, trace/memory both in auto and record/stop mode and single shot triggering. My scope does not lock up.

[TinkeringSteve]

My scope does not freeze - regardless of which channels are activated etc. I fiddled around with the active channels selection, input selection of FFT function, window mode, trace/memory both in auto and record/stop mode and single shot triggering. My scope does not lock up.

Funny. I can't reproduce it anymore either. I did a couple times before, only using Ch2 and restariting and going straight to "math" and changing the setting.
Now that I fiddled around a bit more, even restarting with only Ch2 active, going to math/fft and oing the memory setting, nah.
Weird.

[frozenfrogz]

Good news everyone!

I recently bought another DS1054Z (and a DP832) and since the re-seller asked me to give some feedback I wrote a lengthy email regarding my user experience and also pointed towards this thread for more detailed information.
The re-seller forwarded my mail to the European Rigol service (had one or two phone calls with them in the past) and they again forwarded it to Rigol R&D, also stating they will have a closer look at our bug-list.
If and how this might affect the next firmware releases I can not tell, but after all it is another chance for communication.

This is just a heads up and while Rigol might be reading this: Thanks for taking us seriously and you are very welcome to chime in and get a part of this forum!
Lots of Rigol users to get in contact with around here!

[bitseeker]

Excellent. Thanks for doing that. Hopefully, one day Rigol will pay attention to what goes on here. So far, they seem not to notice.

[frozenfrogz]

Since the last firmware release some water has gone under the bridge and I am interested to see if some of you did check out what bugs still remain. I would like to keep the opening post up to date and as comprehensive as possible

Please let me know if you are missing information there.
I downgraded the »freeze on update/calibrate issue« since there has not been word about further issues or permanent bricking.

Also, I might start working on the wish list that has remained untouched until today - if there is demand.

Kind regards,
Frederik

[Fungus]

Since the last firmware release some water has gone under the bridge and I am interested to see if some of you did check out what bugs still remain. I would like to keep the opening post up to date and as comprehensive as possible

There's not much left. A typo in a menu, and... I can't remember any more.

[frozenfrogz]

There's not much left. A typo in a menu, and... I can't remember any more.

That is my experience as well - the scope does what I expect it to do. I am no scope specialist though and most likely need just the basic functions anyway.
Personally, I hope Rigol does not fix the pluses spelling! I am feeling kind of attached to it by now

[Roeland_R]

For the wish list: Alternate triggering perhaps?

[frozenfrogz]

Re. alternate triggering: There is this thread.

I’ll add it as a wish list item when going through the post

[Karel]

The USB protocol violation that causes a failing connection dipending on motherboard USB-controller chipset and operating system, is still present and Rigol has no plan to fix it.

[Fungus]

The USB protocol violation that causes a failing connection dipending on motherboard USB-controller chipset and operating system, is still present and Rigol has no plan to fix it.

Bummer!

(I guess I"ll have to use an Ethernet cable instead...)

[Porcine Porcupine]

Bug report: Some DS1000Z units display in peak detect acquisition mode while set to normal acquisition mode.

I posted a separate thread in December about seeing a double trace on my DS1054Z I had just bought. As mentioned in my other thread, I found a Reddit post by someone who encountered the same problem about a year before I did. The Reddit poster returned his unit and received a replacement with the same problem. He concluded that the problem is likely a firmware bug causing the oscilloscope to remain in peak detect acquisition mode when set to normal acquisition mode. After discussing the problem with the Reddit poster and comparing raw data to on-screen traces, I've become convinced the problem is in fact a firmware bug causing the unit to display in peak detect mode whether it is set to peak detect or normal mode.

My original thread about the problem: https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/

Reddit post by someone with the same problem: https://www.reddit.com/r/AskElectronics/comments/5mi24b/recently_purchased_a_rigol_ds1054z_oscilliscope_i/

The steps to reproduce the problem are listed in the Reddit post linked above.

The problem is present whether the oscilloscope is in dots or vectors display mode, but the separation between the peak detect points becomes obvious in dots mode.

My oscilloscope shipped with what is still the latest firmware; although, not all DS1054Z units running the latest firmware seem to be affected.

Here is my DS1054Z's information:

• Software Version: 00.04.04.03.02
• Board Version: 0.1.4
• Boot Version: 0.0.1.4
• Firmware Version: 0.2.3.11
• CPLD Version: 1.1

I recently captured some data from my DS1054Z with MATLAB using SCPI commands over Ethernet. By doing this I was able to plot raw data stored in the acquisition memory and compare it to the trace shown on the oscilloscope's screen.

Here's the trace shown on the screen (1-kHz internal source):



Here's the raw acquisition memory data plotted:



With a memory depth setting of 2.4 Mpts, the 1920x963 image above obviously only shows a fraction of the points. However, I did zoom in to take a closer look, and the data looks just like I would expect. This issue obviously occurs after the oscilloscope processes the data for display on its screen.

Here's the raw data downsampled to the same 1,200 points shown in the oscilloscope's on-screen trace plotted with the actual on-screen trace data in normal acquisition mode:



The downsampled raw data and on-screen trace data are represented by blue and red dots, respectively. I think these plots make it very clear that the oscilloscope is stuck in peak detect mode. In normal mode, the trace displayed on the oscilloscope should look like the downlsampled blue trace. Instead, we are stuck with a double trace when in dots mode and a fat trace in vectors mode that appear to show way more noise than is actually present.

I've tried to present this problem as clearly as I can with the hope someone at Rigol will see this and include a fix in the next firmware update.

Edit: I replaced the original plot I posted of the downsampled raw data and on-screen data together. The MATLAB function I used for the original plot to do the downsampling low-pass filtered the data, which removed a lot of noise. The new plot has the downsampling done without filtering. You might notice in that plot the on-screen data is slightly delayed compared to the raw data, but I believe that's normal for whatever reason, and it doesn't concern me.

[frozenfrogz]

Thank you for the detailed report! I will add it to the list and try to recreate the issue on my device.

Kind regards,
Frederik

[Porcine Porcupine]

Thank you for the detailed report! I will add it to the list and try to recreate the issue on my device.

Kind regards,
Frederik

You mentioned in the thread I posted in December that you weren't able to reproduce the problem on yours. It seems we have the same hardware and firmware too. It's interesting that this issue affects some units and not others.

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363199/#msg1363199

[frozenfrogz]

I could not reproduce it at that time, but maybe I did not try hard enough
Would be interesting to see if it can be tracked down to certain behavior / sequence of operation.

[Fungus]

This has had its own thread:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145

[Porcine Porcupine]

This has had its own thread:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145

That's the thread I started about it several months ago. I wasn't sure what the problem was then, but now I'm convinced it's a bona fide firmware bug that deserves Rigol's attention.

[Fungus]

This has had its own thread:

https://www.eevblog.com/forum/testgear/help-my-new-rigol-ds1054z-shows-a-weird-double-trace/msg1363145/#msg1363145

That's the thread I started about it several months ago. I wasn't sure what the problem was then, but now I'm convinced it's a bona fide firmware bug that deserves Rigol's attention.

I still think it's a hardware limitation in the circuit that copies raw sample data to the display.

It simply can't apply a wide-enough filter to display it correctly (which is understandable - it would need to filter an awful lot of data for each screen pixel). As such, it can't be fixed by firmware.

I'd be interested to how other oscilloscopes deal with this problem (in theory they should all do it to some extent!)

[Porcine Porcupine]

I still think it's a hardware limitation in the circuit that copies raw sample data to the display.

It simply can't apply a wide-enough filter to display it correctly (which is understandable - it would need to filter an awful lot of data for each screen pixel). As such, it can't be fixed by firmware.

I'd be interested to how other oscilloscopes deal with this problem (in theory they should all do it to some extent!)

One thing that convinced me it's stuck in peak detect mode is that I was able to produce a trace with MATLAB that looks exactly as it should by simply downsampling the raw data to the same number of points displayed on the screen. I assume Rigol's normal acquisition mode is supposed to do the same thing in software to go from acquisition memory sample points to the points displayed on the screen.

Another thing that makes me feel it really is stuck in peak detect mode is the traces in both normal and peak detect modes look the same.

Here's a trace captured in normal mode:



And here's one captured in peak detect mode:



Both traces look like classic peak detection to me. If it was actually switching modes when the setting was changed, I would expect the traces to look different (as they probably do on a DS1054Z that isn't affected by this problem). These two example plots don't line up point-for-point because I had to do a new sweep after changing modes to get it to draw a new trace.

[Fungus]

One thing that convinced me it's stuck in peak detect mode is that I was able to produce a trace with MATLAB that looks exactly as it should by simply downsampling the raw data to the same number of points displayed on the screen.

Correct.

The problem is simply in the number of points you need to sample in your downsampling filter.

In Matlab there isn't really a problem, you can sample 100 points, no problem. It's a powerful PC.

In the Rigol ASIC there may be a much more defined limit for this downsampling. It might only be able to sample (eg.) 4 points (I don't know the exact number but it will be quite small).

This means that at some ratios of imput->output frequencies you're going to get aliasing, ie. You'll see two lines instead of one line.

In my post in the other thread you can see this happening, The aliasing on the displayed changes with zoom level.

This isn't a firmware bug, it's a hardware limitation (number of input samples in the downsampling filter).

[2N3055]

@Porcine Porcupine,

With do all respect, you don't seem to really understand how peak detect mode works...

In normal mode running at let's say 100M/sec, A/D converter is discarding 9 samples and use only one out of ten..
In peak detect mode, it won't discard 9 samples, but will remember min/max value, and show those two points on screen.
That way, you can detect 10 nsec pulse on time base where one pixel would only mean 1 usec and normally you wouldn't know something happened in meantime..
So far, so good...

But if you go to time base where your scope already samples at 1GS/sec (max rate here),  Peak detect mode and Normal mode ARE THE SAME.... That is how it works... Usually, other scopes have warning in their manual that Peak detect works only on slower timebases....


And double line can also be caused by more likely reason: since A/D converter used actually works by interleaving 4x250MS/sec converters, if converters have offset relative to each other, consecutive samples wouldn't be vertically aligned..  Like what you see... If there is a bug, it is more likely it is in self cal procedure...

But it probably is not even that.. I can replicate this only on two lowest ranges, that are software zoom created. At 1mV/DIV (1X probe) vertical res of scope is about 40 pixel ... And any offset between A/D converters is multiplied by 5x, making it really visible...
Lowest real vertical range is 5mv/div...

Just something to think about...

Regards,

Sinisa

[frozenfrogz]

After some fiddling I could get to show the double tracing on my scope. It is very dependent on the time base and magnification setting though.
Looks like a quantization issue to me but that is just a wild guess.
It is gone in hi-res and average mode, thus my suspicion for quantization through the ADC.

[frozenfrogz]

Btw. if you are on the low end, say 10mV per unit, you are seeing all the noise.
If you zoom in per time base, the "double trace" resolves into a scattered point cloud, showing kind of a rendering issue.
The black area between the top and bottom "trace" should actually be all yellow in this case, but for some reason the individual dots add up to *null* when merged closely together.

[Fungus]

Looks like a quantization issue to me but that is just a wild guess.

I agree 100%.

It is gone in hi-res and average mode, thus my suspicion for quantization through the ADC.

ie. If you choose sensible display settings it vanishes. Not an issue.