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

[frozenfrogz]

That "inverse brightness coagulation" (as per my second post above and resembling what PP is referring to) behavior is interesting. I would count that as an unexpected rendering issue that does not actually spawn from the ADC.

[metrologist]

I can report a more potentially benign bug. I enabled FFT and was setting the Center, Hz/Div, and Offset. I adjusted the Offset and then went to adjust the Center or Hz/Div. With either of those values outlined with the blue box (indicating that was my current parameter selection), the twiddle knob was still adjusting the Offset value 

I could recover this by selecting different parameters and the scope would release the Offset setting, but it came back again after changing something in the second menu and returning to the first. I reset (Default) the scope and set it up again without an issue, so I did not test the issue further.

I have the latest FW and probably one dot down from the latest hardware.

[Porcine Porcupine]

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

When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?

It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.

[Porcine Porcupine]

@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

I haven't been able to find satisfactory documentation about how Rigol's peak detect mode works, but I assumed it does what you described plus a second stage of downsampling. The second stage is needed because there are still too many points to show on the screen.

My thinking is it first stores the result of the downsampling you described in the acquisition memory. Then it downsamples again just like the first time: it divides points stored in the acquisition memory into the same number of time bins as points shown on the screen, and then alternately selects a maximum or minimum point from each bin. I could be be wrong about this, but this is the most sensible way I can think of to do it.

If it does do it in two stages, then peak detect mode would still be different than normal mode because the second downsampling stage still happens even though there's no first-stage downsampling to do. It seems to me it has to do a second stage of downsampling this way to ensure the peak points make it to the screen trace.

I don't think this problem is caused by ADC offsets, because I didn't see any obvious sign of that in the raw data before or after downsampling.

The effect I see on my oscilloscope is easily seen at 500 V/div. It's possible your oscilloscope isn't affected by the same problem as mine, and you're seeing a different effect at those low V/div ranges. Maybe what you see is the ADC offset you mentioned.

Edit: It just occurred to me that there is likely a third peak detect mode downsampling stage to go from the screen trace buffer to what is actually shown on the screen. If the screen trace buffer has 1,200 points stored in it, it would have to be downsampled again with the peak detect downsampling algorithm to preserve the peaks on the displayed trace, which doesn't even cover the full 800-pixel width of the screen.

[Porcine Porcupine]

I played with my oscilloscope some more and got a couple more results I think are interesting.

I fed it train of 5-V, 70-ns-wide pulses spaced at 1-ms intervals and set the time base and memory depth appropriately to test peak detect mode. I changed from dots to vectors for this so the pulses are lines instead of hard-to-see dots.

First in normal mode:



As expected the pulses were captured erratically and unreliably in normal mode. Each sweep showed a different number of pulses in different spots.

Then in peak detect mode:



Peak detect mode worked beautifully and did exactly what it's supposed to do. So now I know turning on peak detect mode does something, and the unit isn't simply stuck in peak detect mode.

I'm wondering now if that second stage of peak detect mode I speculated about in my last post might be stuck on, meaning that turning peak detect mode on and off is only controlling that first stage of downsampling. I know that scenario might sound a little farfetched, especially since I'm guessing about how peak detect mode works exactly. However, I think that scenario would be consistent with what I'm seeing. The double line with nothing in the middle and the points all displayed at the extremes of the noise amplitude looks so consistent with what I would expect out of peak detect mode that I'm still not satisfied a peak detect bug isn't somehow behind this.

I also fed a 4-Vpp, 1-MHz sine wave into the oscilloscope while in normal mode. With the time base set very slow compared to the signal's period, this is what I got with dots:



It looks like the envelope of the signal, which is what I would expect to see under these conditions with peak detect mode enabled. Nothing changed on the screen when I varied the frequency around 1-MHz, so I don't think this effect is caused by aliasing. As in the other examples of double lines, it looks like the fog you'd expect to see if displaying vectors because of the lines connecting the two lines of points.

Could this be a more extreme example of this double line issue?

[Porcine Porcupine]

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.

In your screenshot with the point cloud, I believe it is displaying 600 points (50 ns * 12 divisions * 1 GSa/s = 600 samples) of raw data directly from the acquisition memory with no downsampling or other processing. The traces in all the other images you posted were downsampled, and I think something Rigol didn't intend is happening during that downsampling at some time base settings to create that gap in the trace. It looks like peak detect mode finding the minimum and maximum noise points to me, but it shouldn't be happening whatever it is.

[Fungus]

It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.

So, you need to learn more about aliasing.

Look at texture mapping in 3D graphics where the same problem occurs. When an object is far away then one pixel on screen might cover hundreds (or even thousands!) of pixels in the texture map. There's no way to downsample/filter it in real time.

nb. In 3D graphics they solve it by using precomputed mipmaps for the textures but an oscilloscope can't do that.

When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?

Nope.

What you see depends on the ratio of the high frequency components of the signal to the samples you kept.

In the post I linked to there's 4 different views of the same data, all views are completely different. The difference you see on screen comes purely from the selection of which points were thrown away and which were kept.

It's nothing to do with peak mode or anything else, that's a complete red herring. It's 100% due to the limits of the downsampling filter and it can't be fixed by a firmware update.

(more correctly: it can't be fixed without reducing the screen update rate to something unacceptable).

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

[Porcine Porcupine]

It also seems strange to me that noise or anything else in this signal could alias into two lines like that without any points between them.

So, you need to learn more about aliasing.

Look at texture mapping in 3D graphics where the same problem occurs. When an object is far away then one pixel on screen might cover hundreds (or even thousands!) of pixels in the texture map. There's no way to downsample/filter it in real time.

nb. In 3D graphics they solve it by using precomputed mipmaps for the textures but an oscilloscope can't do that.

When I downsampled with Matlab, I did it in about the crudest way possible by just throwing samples away without any low-pass filtering. If downsampling were going to cause such aliasing with this signal, don't you think it would have happened then?

Nope.

What you see depends on the ratio of the high frequency components of the signal to the samples you kept.

In the post I linked to there's 4 different views of the same data, all views are completely different. The difference you see on screen comes purely from the selection of which points were thrown away and which were kept.

It's nothing to do with peak mode or anything else, that's a complete red herring. It's 100% due to the limits of the downsampling filter and it can't be fixed by a firmware update.

(more correctly: it can't be fixed without reducing the screen update rate to something unacceptable).

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

Thanks for the explanation, but I'm still a little confused about how such aliasing is happening. I'm interested in replicating the aliasing in Matlab from the raw data to understand it better. Do you have any suggestion on how I might do that?

I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?

[Fungus]

I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?

You just described the problem perfectly: How do you reduce 2000 points of data to a single point on screen?

I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise. 

(nb. The DS1054Z only displays 600 points on screen so there's a secondary 2:1 reduction somewhere...)

[ebastler]

How do you reduce 2000 points of data to a single point on screen?
I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise.

Obviously we don't know how it is implemented by Rigol. But I can't see a good reason for always showing the extreme data points, and hardly ever showing one with medium amplitude. That does hint towards an unintended peak-detect like algorithm, as postulated by porcupine.

And, not to forget: At just slightly faster time base settings, where the scope still has to do massive down-sampling, the effect disappears and the curves or point clouds look reasonable. Something must go "wrong" at those slow time bases. Maybe some histogram counter overflowing or whatever?

Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

[Porcine Porcupine]

I downsampled by a factor of 2,000 to go from 2.4 million raw sample points to 1,200 like the oscilloscope presumably did to get the trace data but didn't get the aliasing. Would I perhaps see similar aliasing if I tried other downsampling ratios or different sampling phases?

You just described the problem perfectly: How do you reduce 2000 points of data to a single point on screen?

I don't know what method the DS1054Z uses, sorry. I'm sure it's done in hardware though so expect it to be a compromise. 

(nb. The DS1054Z only displays 600 points on screen so there's a secondary 2:1 reduction somewhere...)

In the image below, taken from one of my previous posts, I plotted the points stored in the oscilloscope's 1,200-point trace buffer in red and the raw data I downsampled from 2.4 million raw points to 1,200 points in blue. So the effect happens before that final 2:1 reduction.

This is making me want an oscilloscope with open source hardware and software so I can peer inside the black box. But guessing what the black box is doing is sort of fun too in its own way.

[Fungus]

Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

Just don't use dot mode, problem solved!   

(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!

[ebastler]

Just don't use dot mode, problem solved!   
(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!

Well, it's most obvious in dot mode -- but the line mode suffers from an inflated noise (trace width) if it plots only the outliers and connects them with lines.

Averaging is fine if you want to look at a stationary signal, but pretty useless when looking for fluctuations or spurious events. So you will have to live with the inflated noise when you are after that. (And at the same time have to measure at the slower time bases, to be fair.)

I'm still happy with my DS1054Z; but it would be a pity if Rigol make the noise performance look worse than it is, just by careless digital processing.

[2N3055]

Sorry but i have a question:

I would like to know what you guys think an analog CRT scope would show in these circumstances...

Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....

Tadaaaa...

You would get solid block, from left to right, vertically sized to P-P amplitude of signal....
Depending of waveform, parts of that "band" would be darker or brighter, depending on statistical distribution of signal amplitude over time ....
It works only in what a DSO crowd would call "Peak mode"....

I don't know who started dot mode fetish, but it is not optimal mode that shows signal best... Vector mode is your friend. Dot mode is used only sometimes, for specific reasons.

Also, unless you want to specifically filter out higher frequencies (by using BW limit, average or HiRes mode), you want a Peek mode pretty much always...
You don't want to miss super short interference bursts because you are looking at slow timebase..

I don't know what are you measuring but from my practice...

Regards,

Sinisa

[ebastler]

I would like to know what you guys think an analog CRT scope would show in these circumstances...
Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....
Tadaaaa...

Read again, please, and go one page further back. The real discussion of the artefacts starts around post #237 or so. The demo signal is simply the 1 kHz square wave from the calibration output. And the problem is that the parts of the trace where the signal is stable appear either split in two (dot mode) or artificially widened, with inflated apparent noise (line mode).

The short pulses at large intervals, shown further down in the thread, only serve to show that peak mode actually works (and only works when enabled).

[Porcine Porcupine]

Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

Just don't use dot mode, problem solved!   

(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!

I just think it would be desirable for Rigol to include a fix in their next firmware update if this issue is fixable in firmware without any compromises. That might not be possible, as you've pointed out, but I don't think any of us knows for sure what's causing this effect. It would be nice to at least hear something from Rigol since they know exactly how the oscilloscope processes data.

Either way, I'm still satisfied overall with my DS1054Z. It's a fantastic oscilloscope for the price.

[2N3055]

I would like to know what you guys think an analog CRT scope would show in these circumstances...
Namely, a slow time sweep and fast pulses... For instance, 10 ms/div and feed it 1 MHz signal....
Tadaaaa...

Read again, please, and go one page further back. The real discussion of the artefacts starts around post #237 or so. The demo signal is simply the 1 kHz square wave from the calibration output. And the problem is that the parts of the trace where the signal is stable appear either split in two (dot mode) or artificially widened, with inflated apparent noise (line mode).

The short pulses at large intervals, shown further down in the thread, only serve to show that peak mode actually works (and only works when enabled).

I am specifically commenting Reply #254.....

As for what you are saying, I made my comment on that before... 
He needs to self cal scope first, and than not use software magnified input ranges..
Also, DS1000Z IS sensitive to external RF fields... It might as well be that he REALLY HAS high frequency interference injected... In that case noise is not artificially inflated....
Or his scope might really have some issue....

[2N3055]

Anyway, this is just guessing. But I think it likely that, within the limitations of the existing DS1000Z hardware, there would be a better way to down-sample and display the signals at slow time bases.

Just don't use dot mode, problem solved!   

(why would you use dots to look at a signal like that?)

Or ... use dots but turn on averaging - also solved!

I just think it would be desirable for Rigol to include a fix in their next firmware update if this issue is fixable in firmware without any compromises. That might not be possible, as you've pointed out, but I don't think any of us knows for sure what's causing this effect. It would be nice to at least hear something from Rigol since they know exactly how the oscilloscope processes data.

Either way, I'm still satisfied overall with my DS1054Z. It's a fantastic oscilloscope for the price.

Put it in vector mode and it looks exactly as it should....

On the other hand I do agree that I would like for Rigol (and everybody else) would exactly explain how they massage data before handing it to us...
I'm all for it...

Regards,
 Sinisa

[Fungus]

As for what you are saying, I made my comment on that before... 
He needs to self cal scope first, and than not use software magnified input ranges..
Also, DS1000Z IS sensitive to external RF fields... It might as well be that he REALLY HAS high frequency interference injected... In that case noise is not artificially inflated....
Or his scope might really have some issue....

Nah, they all do it (I think).

It's not noise, it's a high frequency sine wave. See my post in the other thread, the signal is very clear at maximum zoom:

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

[ebastler]

I am specifically commenting Reply #254.....

Me too, and specifically on the first two screenshots in that post. 

As to the third image in #254, I agree that it is not a meaningful measurement setting. But it can serve as another test case for the assumed "unwanted peak detection": I would indeed expect to see the occasional dot inbetween those two extreme lines. (While the sine signal spends most of its time near the extrema, the transition time between them is certainly not negligible, and hence the probability to "catch" a sample inbetween should not be negligible either.)

[ebastler]

Put it in vector mode and it looks exactly as it should....

Well, it's most obvious in dot mode -- but the line mode suffers from an inflated noise (trace width) if it plots only the outliers and connects them with lines.

Averaging is fine if you want to look at a stationary signal, but pretty useless when looking for fluctuations or spurious events. So you will have to live with the inflated noise when you are after that. (And at the same time have to measure at the slower time bases, to be fair.)

I'm still happy with my DS1054Z; but it would be a pity if Rigol make the noise performance look worse than it is, just by careless digital processing.

[2N3055]

I am specifically commenting Reply #254.....

Me too, and specifically on the first two screenshots in that post. 

As to the third image in #254, I agree that it is not a meaningful measurement setting. But it can serve as another test case for the assumed "unwanted peak detection": I would indeed expect to see the occasional dot inbetween those two extreme lines. (While the sine signal spends most of its time near the extrema, the transition time between them is certainly not negligible, and hence the probability to "catch" a sample inbetween should not be negligible either.)

@ebastler,  I apologize, I meant specifically to that last third image...

In non peak detect mode at slow timebase and dot mode, with decimation,  signal would get very VERY few dots vertically in between...  At that sampling ratio, it does spend negligible time going up and down...
That is why you have to use vector interpolation....

Regards,

Sinisa

[Porcine Porcupine]

Nah, they all do it (I think).

It's not noise, it's a high frequency sine wave. See my post in the other thread, the signal is very clear at maximum zoom:

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

Ah, I think I see now why you were saying it's aliasing and I had a hard time understanding how it could be aliasing. I was assuming the noise is a spectrum of high frequencies, and I think you had that single-frequency sine wave in mind.

The time segment you zoomed into isn't indicative of the noise over a full cycle of the square wave on my oscilloscope. When I zoom all the way into the trace on my oscilloscope, I can find time segments that look like a single sine wave as in your example. But I can move around and find other segments that look very different and obviously have other frequency components. This is why I didn't think it was aliasing.

[konnor]

I publish my attempt to correct some errors on DS1000Z firmware (2017).
The archive in this message contains the modified firmware.
In the next post is attached an archive with a library and tools for
make&load plugins. Two simple examples are included.

changes on firmware:
1) Ext port 6000 funcs - read/write/call (see rigolif programm)
2) pluses -> pulses
3) rnage -> range (decoder:conf:range)
4) Changed USB Buffer Size (40->200) - test, please. I don't use USB IF
5) Disabled set bandwidth to license maximum on start (BW20 fix)

directory in plugin archive:
rigolif           sample programm for 6000/UDP
add_info          mixed info
libb              plugin library       
patch             port 6000/UDP patch sources
plugin_simple     sample of simple plugin (single LED cycle and exit)
plugin_thread     plugin with thread (permanent LED cycle)

!!!WARNING!!!
This is Beta version. Tested only in my Rigol
AS IS, AS IS, AS IS.....


Update: Archive with color-bug firmware removed, see update in new topic: https://www.eevblog.com/forum/testgear/rigol-ds1000z-firmware-patch-plugins/

[ebastler]

I publish my attempt to correct some errors on DS1000Z firmware (2017).

Wow, that is quite amazing! But I am reluctant to try it...

What version number did you give the new firmware? If I want to go back to a standard firmware, can I do that? (To which version?) I seem to recall that Rigol does not allow "downgrades" of the verion number, so can one ever go back?