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

[Karel]

I want to add another bug. The DS1000Z series does not display the full vertical resolution, it clips it at 80%.

I think you are mistaken (or I do not fully understand).

The latter, you do not fully understand. I will try to explain better.

The scope and DSRemote use the same settings.
The waveform you see with DSRemote is downloaded from the scope at the very moment that scope was displaying
the clipped sinewave.

And yes, DSRemote shows more divisions in vertical direction because it can utilize the full 8-bit or 256 steps.
The scope's display instead, is using only 200 steps of the same waveform data.

Ofcourse, you can adjust the vertical scale of the scope to make the sinewave fit, but that's not my point.
My point is that the scope is not using the full dynamic range of the adc.

[frozenfrogz]

So basically you are saying, that there is a mismatch between displayed divisions and actual ADC gain setting / range?

Namely:

8 div@2V: 16V/256 = 0.06V expected resolution
10 div@2V: 20V/256 = 0.08V true resolution *

*where true gain setting might have to be determined via experiments

[Karel]

Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

[bitseeker]

Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

[Fungus]

Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

Probably because "200" maps to a 400 pixel display very easily in hardware but "256" doesn't.

I would be interesting to know if any other 'scopes do this. It wouldn't be the first time somebody points a finger at the DS1054Z only to find out that many other 'scopes do it as well.

[bitseeker]

Yeah, ease of implementation.

[Karel]

Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

Probably because "200" maps to a 400 pixel display very easily in hardware but "256" doesn't.

Then why didn't they do it with the 4000 series which uses the same resolution?

[bitseeker]

Good question. I dunno.

- Product differentiation? Pay more, get more/better.
- Processing limitation?
- Not sharing code between models?
- Implemented by different team?
- Something else?

I wouldn't think it's to avoid quantization error from fitting 256 values across 400 pixels. Scopes aren't so accurate for that to matter so much anyway.

[Fungus]

Then why didn't they do it with the 4000 series which uses the same resolution?

Bigger FPGA, more free gates?

Who knows...?

[technogeeky]

Karel, this is interesting. I normally use the built-in screen and so never noticed the discrepancy. I wonder what they gained or saved by truncating the screen rather than scaling it to fit. Just a case of ease of implementation?

There is a kind of hidden feature in this somewhat-bug. One of the annoying limitations of the 1054z is that you can't hide a waveform that you are using as a source of data like you can on other scopes. For instance, if you are doing some MATH function (say, FFT) on a trace you can't turn it off to hide it, and just see the result.

But this way, as long as your trace is small, you can hide it just off screen!

[bitseeker]

LOL, nice side effect, technogeeky. The down side, though, is that you sacrifice the resolution of your input to that math function by allowing the "hidden" signal to be small enough to fit within that small space up (or down) there.

[frozenfrogz]

Since I was quite busy the last couple of days I added the ADC gain <-> display mismatch bug to the OP just today.

In case you have a better description in mind, please let me know

The OP needs some work to become untangled and more approachable in my opinion and I am thinking about sorting the bug list by matter of importance // urgency. Maybe I can do it this weekend, but I can not make any promises.

Regards,
Frederik

[metrologist]

Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

[RoGeorge]

The vertical resolution is 8 bits. It doesn't says all 256 values must fit on one screen.
As a parallel situation, it would be unfair to consider the time zoom feature as a bug, just because it doesn't fit all the samples in the same screen without scrolling, right?

I see this 8 divisions instead of 10 as a display limitation, not as a bug. Yes, it could have been better, with 10 divisions drawn on the screen, but it's not.

One more thing, only 8 horizontal divisions instead of 10 is nothing when compared with only half resolution on some voltage ranges (as in 7 bits instead of 8 bits). I remember there were certain voltage ranges where the values were all odd when read by SCPI, which led me to the conclusion that some voltage ranges were just simulated in software by a x2 multiplication, instead of using a real voltage divider in the analog path of the measured signal.

[metrologist]

But how do you qualify the vertical resolution as being 8 bits? It seems there is only one way to get the full 8 bits out of the device, via SCPI in RAW mode, which presents other limitations.

[Karel]

Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

It uses the ":WAVeform:DATA?" command as described in Rigols programming guide.

[Karel]

I see this 8 divisions instead of 10 as a display limitation, not as a bug. Yes, it could have been better, with 10 divisions drawn on the screen, but it's not.

The problem is not the number of divisions on the screen. The problem is that the scope is not able to display the full dynamic range of the adc.
It shows max 200 steps instead of 256. In other words, the vertical steps (as displayed on the screen) become unnecessary course.

[metrologist]

Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

It uses the ":WAVeform:DATA?" command as described in Rigols programming guide.

But then must it issue :WAV:MODE RAW beforehand? Otherwise, YINC is /25.

[Karel]

Yes. Also, it's kind of a "documented bug". If you take a look at the programming guide 2 - 223 (page 239)
there's written that the "Yincrement" steps are verticalscale / 25.

For example, the 4000 and 6000 series don't suffer from this limitation.
In their respective programming guides they specify that "Yincrement" steps are verticalscale / 32.

Which is weird because the 4000 series uses a display with the same number of pixels.

The specifications state that the vertical resolution is 8 bits. How does DSRemote get all 8 bits? Is it using Raw mode?

It uses the ":WAVeform:DATA?" command as described in Rigols programming guide.

But then must it issue :WAV:MODE RAW beforehand? Otherwise, YINC is /25.

Normal mode. And indeed YINC is 25/division, which is actually the problem because, apparently, the scopes display uses also 25 steps per division. Not 32 steps per division like the 4000 series.

[metrologist]

So then, how did DSRemote get the info for the extra divisions? In normal mode, it would only receive the display data.

Edit:
page 2-218: "NORMal: read the waveform data displayed on the screen."
and reference the illustrations on page 2-216...

I was also just looking at some screen dumps and every displayed sample uses two vertical pixels. The graticule is 400 pixels tall, with the bottom division's 50 pixels encorporate both the bottom and it's top graticule lines; all other division's 50 pixels seem to start just above the graticule line and encorporate just the top graticule line. So, there is the ease of implementation for the display.

And, how do we qualify 8-bit vertical resolution? I seem to recall that the measurements use display data for the calculations, so we actually do not have 8 bit resolution. Who's to quibble over a few (56) bits?

[Karel]

So then, how did DSRemote get the info for the extra divisions? In normal mode, it would only receive the display data.

When requesting the display data in normal mode, the scope will send 1200 samples (200 for every horizontal division).
Every sample is transmitted as one byte (when format is set to byte). So every sample contains 2^8=256 vertical steps which is the full dynamic range of the adc.

[metrologist]

So then I don't understand the point of having a mode setting, at least not the RAW setting. Seems you could set the format to WORD and get the same information (range). Anyway, that's off topic now.

[Fungus]

Since I was quite busy the last couple of days I added the ADC gain <-> display mismatch bug to the OP just today.

Is it definitely a bug then? A "bug" implies it's something unintentional that needs fixing with a firmware update. If it's due to a hardware limitation then it's not really a bug (in my book). Even if it's done deliberately due to a marketing decision, then ... it's still not really a bug as such.

The vertical resolution is 8 bits. It doesn't says all 256 values must fit on one screen.

What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

If it does then it's not a bug, it's a feature. 

[Karel]

What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

Good question, I just tried. You can scroll into view.

But still, it makes no sense. Why not showing the whole waveform when it's running?
The 4000 series has the same display resolution and they do it correctly i.e. they show the whole waveform when running.

[Fungus]

What happens if you freeze the display and move it up/down. Does the extra signal scroll into view?

Good question, I just tried. You can scroll into view.

It's a feature! R&S charge extra for their "virtual screen" function (which basically does the same thing).

But still, it makes no sense. Why not showing the whole waveform when it's running?
The 4000 series has the same display resolution and they do it correctly i.e. they show the whole waveform when running.

Must be a hardware limitation. If 200 pixels are visible then they're obviously just dividing by two in the display logic instead of fully scaling the values. Maybe they ran out of gates in the FPGA or it would be much slower or something. Only Rigol knows for sure. The 4000 series will have a more powerful chipset.