Anomalies and/or Bugs in/between the Rigol MSO/DS1000Z, MSO/DS2000A, MSO/DS4000

[marmad]

I'm starting this thread to discuss any and all anomalies and/or bugs in or between the Rigol UltraVision DSOs (MSO/DS1000Z, MSO/DS2000A, MSO/DS4000).

I'm currently working on a video examining the differences between High Res mode on the DS1000Z and DS2000, but meanwhile I'm discovering other anomalies as well so I wanted a place to post them. I figured this might be a handy way to highlight some differences between the models that is not readily apparent from the specs.

Personally, I'm mostly interested in comparisons between 2 or more of the series, but feel free to discuss any bugs or problems you've discovered in any of the UltraVision models - anything is open for discussion - if you want to be an off-topic policeman, find another thread 

I noticed when I was setting up some tests today that the MSO1000Z displays a Ground-coupled channel input in an unexpected way (to me anyway). It looks more or less identical to the DC-coupled setting when there is no input to the channel (i.e. with some noise), while the DS2000 'simulates' a perfectly noise-free grounded input. So I figured this weird little anomaly was a point with which to begin this thread:

[motocoder]

Here's a link to my thread, in which we are discussing a lock-up triggered by certain events on the network interface.

https://www.eevblog.com/forum/testgear/rigol-ds2072-rma-ed-to-rigol-for-repair/

[marmad]

Here's a link to my thread, in which we are discussing a lock-up triggered by certain events on the network interface.

https://www.eevblog.com/forum/testgear/rigol-ds2072-rma-ed-to-rigol-for-repair/

Hey motocoder - welcome!    I've been following your thread with interest.

One quick question for you: there were some seemingly drastic changes with the LAN code in the DS2000 FW, beginning with, I believe, v.3 (although maybe it was v.2). Have you downgraded to FW 02.01.00.03 or FW 01.01.00.02 to see if the lock-ups persist?

[i4004]

perhaps "grievances" would be a best choice of words?   
(as this is not a bug or anomaly, it's just way to make more money....lol!)

like mentioned here
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg555785/#msg555785
1054z has 700x200 resolution, so nobody should scratch their heads when they see jaggy screenshots.... 
and i think that goes for whole z series...all models have 8bit adcs?

if i read the specs pdf, even 4k series mentions 12bit in "only if" terms, simillar to 1000z's "12bits max".

so it's 8bit everywhere.
so it's low vertical res everywhere. out of curiosity, is this the norm today, are "more vertical bits" reserved for much more expensive scopes?

as for this reply from marmad

Well, forgetting Hi Res for a moment, the true resolution of the ADC is 256 bits - so the question becomes: how do you map 256 voltage levels to 400 vertical pixels? You have to so some upsampling. I haven't examined the DS1000Z closely, but on the DS2000, Rigol maps each level to 2 pixels, so the full ADC = ~10.2 vertical divs.

on "old" thread,
i would say they just "crop" those extra 56 levels (i would like it if they were to put "256 bits" adc like you've mistaken above!), because how do you decide which pixel will be "2 pixel height" and which "just one", and if "just one" doesn't even exist (in any screenshot), then you surely have only 200 pixels.

edit/ they can also map 256 levels to 200 pixels by making each "double" pixel have more than one color tone, which they probably do, but did anybody check the vertical resolution by providing input signal with 256 (and more) voltage levels?

in my screenshot from that thread, i just see "2 pixel height".



offcourse resampler you use to blow the image counts, must be "point resize" or so...irfan view should do it if you just hit the "+" (zoom in) button...see the image..any vertical samples of just 1 pixel height?
inspect the irfan-view blown image below.

[David Hess]

I noticed when I was setting up some tests today that the DS1000Z displays a Ground-coupled channel input in, to me anyway, an unexpected way. It looks more or less identical to the DC-coupled setting when there is no input to the channel (i.e. with some noise), while the DS2000 'simulates' a perfectly noise-free grounded input.

The old Tektronix 2232 series of DSOs have a settable "smooth" function which zeros out noise below a threshold in the same way that an audio noise gate operates.  The later 2440 series as "smoothing" which is completely different.

Smooth

Uses a digital process to smooth the waveform display, yet retain the glitch catching capabilities of Peak Detect or Accumulate Peak acquisition modes.  (Smooth applies only to the Peak Detect or Accumulate Peak modes.)

The result is that peak detection which would normally show peak-to-peak noise from the digitizer instead produces a clean trace.  I find it annoying because the extra processing slows down the acquisition rate so I usually leave it disabled but it does produce a nice looking display.

Maybe the DS2000A series is doing something similar.  Peak detect or envelope mode might change this behavior.

[marmad]

perhaps "grievances" would be a best choice of words?   
(as this is not a bug or anomaly, it's just way to make more money....lol!)

   Perhaps - but one man's grievance might be another man's expected behavior 

so it's low vertical res everywhere. out of curiosity, is this the norm today, are "more vertical bits" reserved for much more expensive scopes?

Yep - pretty much. Attached is a zoomed and cropped image from Agilent 3000 X-Series, showing the same upscaling for their 400 pixel vertical display.

[marmad]

The result is that peak detection which would normally show peak-to-peak noise from the digitizer instead produces a clean trace.  I find it annoying because the extra processing slows down the acquisition rate so I usually leave it disabled but it does produce a nice looking display.

Maybe the DS2000A series is doing something similar.  Peak detect or envelope mode might change this behavior.

Interesting. Peak detect made no difference (and there is no Envelope mode on the DS2000), but High Res (at >=5us/div) changed the results slightly.

EDIT: Although I'm now wondering if that slight change is just due to the drop in waveform captures from 104 to 17 wfrm/s (when High Res is switched on while in AUTO-trigger mode @200us/div).

[i4004]

your agilent screenshot shows both 1 and 2pixels vertical samples, you saw same thing on any rigol screenshot?
(or is it 2 and 4 vertical pixels i'm seeing there on agilent?)

ie 1 discrete 'vertical' pixel?

as we already saw 2pixels samples in abundance on rigol.

although they're both 8bit scopes, it's just that they use different means to display it...i would prefer the agilent way because it's closer to the voltage waveform....


(for me it's just silly i bumped to 8bit adc so quickly in 2014, i mean it's 90s technology..and in the scope....!!??  )

[marmad]

your agilent screenshot shows both 1 and 2pixels vertical samples, you saw same thing on any rigol screenshot?
(or is it 2 and 4 vertical pixels i'm seeing there on agilent?)

No, it's 2 and 4 vertical pixels - look at Photoshop ruler.

although they're both 8bit scopes, it's just that they use different means to display it...i would prefer the agilent way because it's closer to the voltage waveform....

The Agilent image just happens to be a stopped DSO - in other words, not an intensity-graded image. The Rigol looks exactly the same when stopped.

[David Hess]

The result is that peak detection which would normally show peak-to-peak noise from the digitizer instead produces a clean trace.  I find it annoying because the extra processing slows down the acquisition rate so I usually leave it disabled but it does produce a nice looking display.

Maybe the DS2000A series is doing something similar.  Peak detect or envelope mode might change this behavior.

Interesting. Peak detect made no difference (and there is no Envelope mode on the DS2000), but High Res (at >=5us/div) changed the results slightly.

EDIT: Although I'm now wondering if that slight change is just due to the drop in waveform captures from 104 to 17 wfrm/s (when High Res is switched on while in AUTO-trigger mode @200us/div).

The displayed level of noise in the original DS2000A image does not look consistent with what I would expect from a buffer with a 15 picofarad input capacitance and excluding quantization noise.  What is the input bandwidth?  At 200 MHz with a shorted input, I would expect a lot more than even 1 millivolt of peak-to-peak noise.

High resolution or averaging will reduce the displayed noise considerably of course.

[i4004]

here is 1054z's

1-gnd-ed input
2-gnd-ed on probe
(while grounding the probe to the 'calibrator' ground produces more noise than it can fit the screen on 10mV/div)

i compared this scope without a connected probe to that what connor wolf mentions on his ds4k test yt video, and i actually got a bit lower front-end noise than he, but not that much lower...
(even though my 240v mains are not grounded...it's just L and N in the wall socket..connecting ground brings this lower yet...by some 80uV (0.08mV) to about 1.36mV front-end noise...)

i dunno why would 2k be perfectly still in that situation, some noise must exist there....

[marmad]

The displayed level of noise in the original DS2000A image does not look consistent with what I would expect from a buffer with a 15 picofarad input capacitance and excluding quantization noise.  What is the input bandwidth?  At 200 MHz with a shorted input, I would expect a lot more than even 1 millivolt of peak-to-peak noise.

The display does not change based on the vertical scale - it seems as if the input to the ADC is shorted (or something similar). I've seen this same method used on other DSOs.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

BTW, continuing our previous conversation from the other thread (Hi Res mode and Tektronix - deemed OT by OCs), I found some specifications from Tektronix as to how they map waveform values to the display (at least on the TDS XXXA series):

According to the specs, Normal mode maps 6.8 bits to 460px (i.e. ~4.128 pixels per value - some rather serious upscaling) - while Hi Res mode maps 9.7 bits to 460px (i.e. ~0.55px per value). From these numbers it appears as if you would only see a 1:1 mapping when Hi Res was equivalent to 8.85 bits of resolution, otherwise it would almost always be downscaling (unless I'm completely missing some salient point - which is totally possible  ).

Other than that, I have found no indication that the added resolution in the waveform record would be usable in real time. It would only be useful when the DSO was stopped - or for viewing/processing on an external device (which, granted, would still be a nice feature to have).

[marmad]

here is 1054z's

1-gnd-ed input

@i4004: Would you mind checking your GND-coupled input @ the lowest timebase and vertical scale? Here is the MSO1074Z that I have @ 5ns/1mv/div:

[i4004]

No, it's 2 and 4 vertical pixels - look at Photoshop ruler.

so both agilent and rigol have a usefull vertical display resolution of 200pixels...


yep, lo-res it is!

but not as low as 1052.

and dave just made a new thread on hires mode...heh...hold on, can't find it now(probaby saw this one and erased it), so it's ok...i'll say it here:
this scope doesn't have 12bits and doesn't have any hires mode, and neither does tek with such low display resolutions! 
12bit adc would be 4096 levels which would be best translated to 4096 pixels of vertical resolution on the display. in that case horizontal res. should be notched up a bit, to do true 8k display for the scope.....yiiiihhhhaaaaa! 


no, i wouldn't mind that at all, it's running anyway....fastest timebase and least v/div here for you
(default and max sample memory)
0v trigger.

and turn on that vpp counter if you're interested in noise... 

[eV1Te]

In order to really see the 12 bit of information when using a Hires mode one would need to export the data or stop the scope and "zoom" into a portion of the captured signal (vertically). Also the FFT of the signal would get a much lower noise level.

I took these screenshots on my DS1104z-S after stopping the scope at 100 mV/div vertical, and then changed the vertical scale 10 times to 10 mV. It is obvious that the data is displayed in 8 bits no matter which timebase or setting you use (at least I have not succeeded).

Both the high res and the averaging 256 times should be able to generate 12 bit effective resolution.

First picture  is in Normal mode:


This is in Hires mode (no difference in resolution still 8 bits):


This is Averaging 256 times (still 8 bits):

[marmad]

In order to really see the 12 bit of information when using a Hires mode one would need to export the data or stop the scope and "zoom" into a portion of the captured signal (vertically). Also the FFT of the signal would get a much lower noise level.

I took these screenshots on my DS1104z-S after stopping the scope at 100 mV/div vertical, and then changed the vertical scale 10 times to 10 mV. It is obvious that the data is displayed in 8 bits no matter which timebase or setting you use (at least I have not succeeded).

Yes, as I've mentioned before, the Rigols (although I'm not sure about the DS4000) don't save the High Res averaged data in sample memory - meaning they only work on the displayed image, which is downscaled while running. If it wasn't, then when you, for example, switched on High Res using the full 12-bits (at least on the DS2000), the scale of the display would immediately change by a factor of 10.

The problem is, when you STOP the DS1000Z and then increase the vertical scale, you're only changing the scale of the display memory - which has already been downscaled from the averaged data. On the DS2000, when STOPPED, it recalculates the averaging from the original samples every time you change the horizontal or vertical scale.

[marmad]

Here are two series of images demonstrating the High Res recalculations being done by the Rigol DS2000 while stopped.

Both series of images are of the exact same zoomed-in portion (vertical scale) of a sawtooth waveform (a ramped edge) - and are the same series of horizontal timebases, which start at the timebase when High Res first becomes active (500ns) and continue to the first timebase when it averages to a full 12-bits.

The first series is done with the DSO in Normal mode - and the second series is done with High Res active.

[marmad]

Here are two more images that perhaps show the High Res recalculations more succinctly.

DS2000 stopped while in Normal mode, then vertical scale decreased from 200mv/div to 20mv/div:




Then High Res mode turned on:

[rf-loop]

I noticed when I was setting up some tests today that the MSO1000Z displays a Ground-coupled channel input in an unexpected way (to me anyway). It looks more or less identical to the DC-coupled setting when there is no input to the channel (i.e. with some noise), while the DS2000 'simulates' a perfectly noise-free grounded input. So I figured this weird little anomaly was a point with which to begin this thread:

My opinion is that finally they have hit how it need do.  If GND is just as writing straigh line to display what information it give. Nothing, exactly nothing. But well done GND + front end to display, it tell something about front end working example in case of fault.  Why "simulate" GND coupling, it is better to do real GND coupling as have done last 50 years.

(it is even perfect if there is also real GND switch before first stage in analog front end what means that front end input is connected to GND and BNC input pin is leaved very Hi-Z floating with minimal capacitance)

When set input GND, if you change input V/Div do this noise change. How about if change horizontal t/div.
I like  if it works so that real input is tied to GND and INput BNC center is floating. If it is done so that input amplifiers and ADC is still producing normal noise and input is like "no signal" it is still acceptaable and well better than "simulating" GND writing constant zero to display. (what hell this straigh constant line in display memory tells to user  = do not simulate if you can do it real)

[rf-loop]

Yes, as I've mentioned before, the Rigols (although I'm not sure about the DS4000) don't save the High Res averaged data in sample memory.

Do it mean that you can not get out 12-bit  waveform data from scope if it is captured in Hi-Res mode?  Do measurements/cursors  use this 12bit data or 8bit data?

[i4004]

Here are two more images that perhaps show the High Res recalculations more succinctly.

it's just calculating how to make that thick line thinner, but nothing is really gained with regard to sampling, you could also make that line thinner in your head with same results, you didn't really gain any more adc vertical resolution.

so it's really cheating, and the waveform shown is just a guess....

if you had a scope with more bits in adc, it would show something else, something more genuine...this is a play with 8bit data....

[rf-loop]

if you had a scope with more bits in adc, it would show something else, something more genuine...this is a play with 8bit data....

With 8bit ADC we can get more than 8 bit.  But it need averaging with noise. Noise can be input stage normal noise or if this noise is very small then there need do noise injection.
But, price is speed.  It really reduce speed lot of.
It can do with waveform averaging if average enough long time. But this make whole waveform all changes slow.
With low horizontal speed we can use other method.
Example if scope have 1GSa/s speed.  When you turn horizontal so that you see scope have now example 1MSa/s. What is ADC itself speed, it is still 1GSa/s.  System only take every 1000's  sample.  999 samples are flushed out.
But if we use these 1000 samples for averaging and then produce this one bit we get more accurate sample. (if there is enough noise and noise quality is good for this). 
What we loose. We do not know in horizontal axis what is right time position for this averaged result. We can do it even better if take all these 1000 pixels and note every pixel time and then some more math but no reason to do it in normal lab oscilloscope.

What is real gain of absolute accuracy perhaps not need even tell but rised relative accuracy and resolution  inside some captured waveform may be "lot of".

[TMM]

Here are two more images that perhaps show the High Res recalculations more succinctly.

DS2000 stopped while in Normal mode, then vertical scale decreased from 200mv/div to 20mv/div:

https://www.eevblog.com/forum/testgear/anomalies-andor-bugs-inbetween-the-rigol-msods1000z-msods2000a-msods4000/?action=dlattach;attach=120108


Then High Res mode turned on:

https://www.eevblog.com/forum/testgear/anomalies-andor-bugs-inbetween-the-rigol-msods1000z-msods2000a-msods4000/?action=dlattach;attach=120110

I'm trying to replicate this on the DS1000Z, let me know if i'm doing anything wrong.

Using 1Vp-p 1.5KHz ramp from DG4062,
200mV/10uS per div, normal acquisition:


Then adjusted to 20mV/div after stopping the above:


Same thing again, but high-res acquisition instead of normal:

[TMM]

And again with shorter memory depth (i set the memory depth to auto).

Normal:


High Res:

[TMM]

And slowed down by 1 and 2 orders of magnitude:





Last test run again with forced short memory.

[rf-loop]

Here are two more images that perhaps show the High Res recalculations more succinctly.

I'm now confused totally.

What you mean with these (and there is also more images in other message).

You have used normal mode and high-res mode.
I can see these images sample rate is 2GSa/s.
It is maximum speed of this scope ADC.

How it can do any High-Res type averaging with this speed?
Stupid question: What exatly is Rigol High-Res mode? Do it real High-Res mode at all or is it some kind of diplay cosmetic  make-up?

[David Hess]

BTW, continuing our previous conversation from the other thread (Hi Res mode and Tektronix - deemed OT by OCs), I found some specifications from Tektronix as to how they map waveform values to the display (at least on the TDS XXXA series):

According to the specs, Normal mode maps 6.8 bits to 460px (i.e. ~4.128 pixels per value - some rather serious upscaling) - while Hi Res mode maps 9.7 bits to 460px (i.e. ~0.55px per value). From these numbers it appears as if you would only see a 1:1 mapping when Hi Res was equivalent to 8.85 bits of resolution, otherwise it would almost always be downscaling (unless I'm completely missing some salient point - which is totally possible  ).

I am not sure what you found but I suspect the numbers, 6.8 bits and 9.7 bits, came from the ENOB (effective number of bits) specifications that Tektronix often includes or used to include.  They represent the dynamic range of the digitizer and have nothing to do with mapping ADC levels to the display.

You can find the same type of ENOB specifications in the datasheets for the ADCs Rigol is using but they represent ideal values; the real numbers are lower do to outside factors like clocking and noise.

Tektronix was pretty paranoid about using integer mappings between the ADC levels and the display.  This is why the 7854 uses 102.4 points per division so its 10 bit ADC maps evenly to 8 and 10 divisions exactly (Its 8 x 10 cm display is 1024 x 1024 points or 325 x 260 dpi so Apple must have invented it.  The extra 2 vertical divisions are overscanned.) and their later vector graphics DSOs with 25 or 50 points per division used overscan for the extra points if a power of 2 display record was used if they were displayed at all.  25 points per division and 8 divisions yields 200 points so the extra 56 level from the 8 bit display record are overscanned.  The same thing happens horizontally with power of 2 record lengths.

The TDS460A series specifications (the TDS500 series are the same) are very specific about using 50 pixels per division with a 8 x 10 graticule producing a 401 x 501 pixel graticule on a 480 x 640 display and mapping 25 8-bit levels per vertical division so 2 pixels per 8-bit level.  8 vertical divisions only yields 200 8-bit levels but Tektronix liked to keep clipping outside of the visible display.  The raster display and graticule provide no overscan like their earlier vector CRT displays.

Other than that, I have found no indication that the added resolution in the waveform record would be usable in real time. It would only be useful when the DSO was stopped - or for viewing/processing on an external device (which, granted, would still be a nice feature to have).

I am not sure why the documentation would discuss it.

I have used the added resolution supported by the waveform record in real time on the 2440 series and old TDS series DSOs.  That is how these oscilloscopes either scale vertically without changing the input sensitivity or provide volt per division settings higher than the highest input sensitivity.  Averaging or high resolution mode is needed to provide a better than 8 bit waveform record because if only 8 bit resolution is available, the quantization levels become evident.  I do not remember exactly what the TDS series does (I think it forces averaging or high resolution mode depending on the sample rate if you try to set a higher vertical sensitivity than the hardware supports on a live waveform) but the 2440 disallows vertical scaling in real time if averaging is not used.  When stopped it allows it on any saved waveform which is how the 8-bit quantization can be displayed like many of the Rigol photos in this discussion.

The automatic measurements make use of the high resolution waveform record as well while the Rigols apparently make measurements on the display record yielding some odd behavior and limitations.

I do not have a TDS series DSO to play with anymore but what I remember is that high resolution mode did the same thing and works as expected.  If the waveform is scaled in real time without adjusting the vertical sensitivity or when saved, then the full >8 bit waveform record was used to generate the display.

[electronic_eel]

Here is another issue I found on my MSO4000 (firmware 00.02.02.SP1, hw 1.3):

Once the probe ratio is set higher (e.g. 100x), the measure functions on the math channel return totally bogus values. I found this while measuring on mains with my 100x probe.

This is the most easy way I found to reproduce this:

- Connect the scope to a function generator outputting a sine signal with e.g. 2Vpp @ 1KHz, use e.g. BNC and not a probe with automatic ratio detection (like the probes supplied with the scope)
- Go into the channel menu, probe and select a 100x ratio
- Activate the math channel with an advanced expression and enter CH1*CH1
- Go to the measure menu and select Math as source
- Add some measure values, e.g. Vmin and Vmax
- Go back to the math menu and scale the math channel to 5.00KU
- Move the position of the math channel on the screen up and down
- Watch the Vmin and Vmax measures for the math channel reporting totally bogus values (e.g. negative), depending on where on the screen the math channel is positioned.

I attached some examples from my scope, just compare the purple Max, Min and Avg values.

I can only observe this with a high probe ratio setting so I guess this is some kind of overflow.

Could somebody check if this problem is also occuring on the 2000A and 1000Z series?

Thanks.

[marmad]

it's just calculating how to make that thick line thinner, but nothing is really gained with regard to sampling, you could also make that line thinner in your head with same results, you didn't really gain any more adc vertical resolution.

so it's really cheating, and the waveform shown is just a guess....

if you had a scope with more bits in adc, it would show something else, something more genuine...this is a play with 8bit data....

This is just successive sample averaging producing more effective bits - the formula and method for doing it is well-documented. I'm not sure what you expect to happen when you press Hi Res - would the display grow more pixels? Even with a bigger ADC and higher resolution display, when you zoom in far enough, you see jagged edges.

[marmad]

I'm trying to replicate this on the DS1000Z, let me know if i'm doing anything wrong.

As I mentioned in a previous message, this is impossible on a DS1000Z. It doesn't recalculate the data, so you're just enlarging the 8-bit record.

[eV1Te]

I'm trying to replicate this on the DS1000Z, let me know if i'm doing anything wrong.

As I mentioned in a previous message, this is impossible on a DS1000Z. It doesn't recalculate the data, so you're just enlarging the 8-bit record.

I liked your demonstration of how the DS2000 recalculates the data. I completely understand that the DS1000z does not do this.

However what I am trying to say is that the DS1000z never displays anything above 8 bits, even while running. For example in the 1 mV and 500 uV range, the scope amplifies the signal in software hence it is possible to see bit steps clearly while running or stopping.

The hires mode or the averaging mode does not change the bit steps at all, and there is no difference when changing vertical after stopping either.

Hence the conclusion I can draw is that the Hires mode on the DS1000z is broken, or it never existed in the first place, and should thus be removed from Rigols advertisement and the specification for the instrument.

If this is incorrect and there is some settings that enables more than 8 bits, please correct me as I have spend hours trying to find such a condition (I would find it useful for low noise measurements).

I now have to resort to exporting the entire 24 MB of data in order to convert it to 140 kB of 12 bit data on my computer (post dithering), which takes significant amount of time to write to a USB stick.

[marmad]

I am not sure what you found but I suspect the numbers, 6.8 bits and 9.7 bits, came from the ENOB (effective number of bits) specifications that Tektronix often includes or used to include.  They represent the dynamic range of the digitizer and have nothing to do with mapping ADC levels to the display

It certainly has to do with mapping - the specification is very specific about the divisions - but it's true I had forgotten to take into account that it was effective bits, which makes much more sense in the calculations (with more tidy numbers). So, yes, that means it's 2px per level in 8-bit mode, 9-bits would map 1:1, and bit values above that are downscaled (un-zoomed).

The TDS460A series specifications (the TDS500 series are the same) are very specific about using 50 pixels per division with a 8 x 10 graticule producing a 401 x 501 pixel graticule on a 480 x 640 display and mapping 25 8-bit levels per vertical division so 2 pixels per 8-bit level.  8 vertical divisions only yields 200 8-bit levels but Tektronix liked to keep clipping outside of the visible display.

The DS2000 uses the same mapping.

I am not sure why the documentation would discuss it.

Well, ok then - I'll leave it there... and just assume those expensive DSOs can do it.

...while the Rigols apparently make measurements on the display record...

You keep mentioning this as if it's an anomaly in low-cost scopes. Instead, could you perhaps come up with some other low-cost brands which don't do this?    Agilent X-series? Nope, they do it too.

You have to keep in mind - Agilent was Rigol's mentor. Much of the behavior and feature set of Rigol's DSOs, for good or ill, is learned or copied from Agilent.

[i4004]

The hires mode or the averaging mode does not change the bit steps at all, and there is no difference when changing vertical after stopping either.

Hence the conclusion I can draw is that the Hires mode on the DS1000z is broken, or it never existed in the first place, and should thus be removed from Rigols advertisement and the specification for the instrument.

even 2k's "hires" mode is nothing usefull really, while on 1000z it doesn't even exist.
how to test it?
do you see any meaningful change when you turn it on? if not, then it doesn't exist.

but again, even on 2k this is just a gimmick....just like the perfectly still line on grounded input...that doesn't exist, why would you do it? for whom?
this thread should be called "rigol gimmicks/tricks".

edit/ok, it does something on 2k, not totally useless, looking at lastest pix from marmad.

This is just successive sample averaging producing more effective bits - the formula and method for doing it is well-documented. I'm not sure what you expect to happen when you press Hi Res - would the display grow more pixels? Even with a bigger ADC and higher resolution display, when you zoom in far enough, you see jagged edges.

well i would expect that in 21st century we've moved away from number of bits we first saw in 1972. for starters.
http://en.wikipedia.org/wiki/8-bit#Notable_8-bit_CPUs

8bit adcs are even older
http://www.analog.com/library/analogdialogue/archives/39-06/chapter%201%20data%20converter%20history%20f.pdf
page 23 onwards.

offcourse more bits have their limits too (12bits requires 8k display, i didn't kid much..heh), but they do exponentially grow, as you know...1024 levels of 10bit would be good enough.
that is 5x  more zoom. oh yeah, what is "ultra zoom" on rigol?
hehe...why do i even ask? 
is it by any chance just the horizontal zoom? 
did you ever hear anybody call "zoom" enlarging just one axis of the image?
meh....it's more advertising than technology....simillar to the way new flat tvs are marketed, with whole lots of interesting tech terms that in the end bring nothing or next to nothing.
there were 200hz panels, now 400hz....   

btw. is anybody making 10bit adcs that output whole 1k resolution if not via its display then via pc interface?

but...hehm..now i know why these things are relatively cheap...

i'm familiar with these concepts from video processing....your pdf mentions both sample and capture averaging...i would call first spatial averaging, and latter temporal averaging....
i presume rigol2k has the former, and i know the latter would be more usefull to average the noise out...i'm also familiar with dithering of images...

but either way it's just a trick to make a waveform look a bit better in a similar way that adding noise to video makes lores video easier on the eyes, but that still has nothing to do with hires video... no extra data was introduced....you just played a bit with existing data to reduce noise....
and video nr filters are always a compromise, you lose some and gain some...it's same here...
talking about video again: i would prefer to not use noise reduction at all because when you do it poorly it's worse than not doing it at all...and you can't really do it properly.
and i see same goes for 'hires' concept in scopes: why don't they just call it noise reduction?
or "virtual resolution improvement"....or both....there really is no need to lie about it.....
it's not hires.

the bottom point is that you can play with software on small amount of bits, OR do it properly and don't play at all and just improve adc ie employ 10bit adcs. map every level to every pixel, at least via pc interface...for scope's own display just do a bicubic resize of hires image...it'll be allright.
waaaaay better than 200 freakin vertical pixels/levels.

to that extent what's the price difference between 10 and 8bit adcs that we're discussing here?

btw. i don't thin it makes any sense to calculate effective number of bits the way you do it, to end up with, for example, "6.8 bits and 9.7 bits" numbers, because bits are bits, they don't have decimal point. because the whole thing is kinda like those "ghetto blaster" "boom boxes" which would state ridiculous 'pmpo' power outputs: it's  just a gimick in attempt to sell something.
it's not really there and it won't really help the measuring.

dave said it well:
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg554787/?topicseen#msg554787
although i don't agree that these days 8bit adc is all we should expect, even for such a low price!

[marmad]

However what I am trying to say is that the DS1000z never displays anything above 8 bits, even while running. For example in the 1 mV and 500 uV range, the scope amplifies the signal in software hence it is possible to see bit steps clearly while running or stopping.

The hires mode or the averaging mode does not change the bit steps at all, and there is no difference when changing vertical after stopping either.

Hence the conclusion I can draw is that the Hires mode on the DS1000z is broken, or it never existed in the first place, and should thus be removed from Rigols advertisement and the specification for the instrument.

If this is incorrect and there is some settings that enables more than 8 bits, please correct me as I have spend hours trying to find such a condition (I would find it useful for low noise measurements).

I've written and posted a lot of information about this in other threads, but I thought I would try to gather together some of it here for clarity:

There at least three big operational differences that I've noticed in the implementation of High Res on the DS1000Z as compared to the DS2000:

1) High Res can not be applied to a captured waveform (stopped DSO) on the DS1000Z; you can only use it when running.

2) High Res on the DS1000Z is destructive - i.e. the original samples are unavailable. On the DS2000, you can turn High Res back OFF after capturing a waveform; on the DS1000Z, once the DSO is stopped, you can't recover the original waveform to the display - although I haven't tested saving sample memory to USB or PC, so perhaps the original samples ave available that way.

3) Most importantly: on the DS1000Z, High Res mode appears as if it might be implemented after display decimation - or at least, in some kind of strange combination with it - resulting in some aliasing and other artifacts. The DS2000 follows the mathematical model of successive sample averaging quite well, while the DS1000Z seems to be doing things poorly in comparison.

The DS1000Z is doing some averaging (as shown in the images below), but it's not clear to me exactly when/how well it works for each possible memory depth setting (I haven't had time for in-depth tests yet). The 12k and 120k setting seem to do some averaging in the us/div range, while the 1.2M and higher settings seem to do almost nothing unless in the ms/div and slower ranges (perhaps higher memory depths overwhelm the ability of the engine to keep up unless at slower sample rates). There also seems to be a problem with higher frequencies leaking past the stopband sometimes, as shown in the image of the sweep roll-off @ 12k below.

The simplest way to get a picture of what the DSO is doing while in High Res is to test the bandwidth. As I've mentioned many time, successive sample averaging (boxcar filtering) is a low pass filter with a sharp roll-off to a null, then subsequent peaks and nulls through the stopband (as shown in this image):




To illustrate the effects of this, I used a repeated sine-sweep pattern - first to my DS2000 in Normal mode:




When I turn on High Res (@ 1.4M), you see the sweep BW roll-off, just as you should:




When I switch the memory depth to 14k, the roll-off gets sharper because of the lower sample rate (thus lower bandwidth):




Here is the same signal to the MSO1000Z:




When I turn on High Res (@ 12M), there is very little change:




When I switch the memory depth to 120k, there is a roll-off, but fairly gentle (perhaps every 4 samples averaged):




When I switch the memory depth to 12k, there is a sharper roll-off, but then a rise again - almost like a notch filter (clearly incorrect behavior):





And here is a sine wave FFT - in Normal, then High Res (DS2000, then DS1000Z):

[marmad]

but again, even on 2k this is just a gimmick....just like the perfectly still line on grounded input...that doesn't exist, why would you do it? for whom?
this thread should be called "rigol gimmicks/tricks".

Yes, you've stated your opinion quite clearly a number of times now - regardless of the fact that Rigol didn't invent any of these "gimmicks/tricks".

But I'm not quite clear what your dog in this race is: did you buy one of these scopes without reading the specs and expect a 12-bit ADC? Or just here to rant? 

[i4004]

but if they copied the tricks did they at least pay copyright fees? 

But I'm not quite clear what your dog in this race is

nah, just slightly surprised we're still in 8bit time....
i still like my 256 level(maybe) 200 line ( ) scope!   

and my dog is that rigol should come clear about the stuff it does...i mean "up to 12bits"?
come on...and you have simillar specs for both 1 and 2k z scopes....

1k spec sheet says

High Resolution 12 bit (max)

and 2k

High Resolution 12 bits of resolution when ?5 ?s/div @ 1 GSa/s (or ?10 ?s/div @ 500 MSa/s).

[marmad]

Here is another issue I found on my MSO4000 (firmware 00.02.02.SP1, hw 1.3):

Could somebody check if this problem is also occuring on the 2000A and 1000Z series?

Thanks.

@electronic_eel: Hi! I confirmed that the bug DOES exist in the DS2000A, but it DOES NOT exist on the MSO1000Z (you can actually see the code recalculate and replace the incorrect values after moving the offset). So they've fixed it in their latest model - now we've just got to get them to port the fix to the DS2000A/DS4000.

[electronic_eel]

@electronic_eel: Hi! I confirmed that the bug DOES exist in the DS2000A, but it DOES NOT exist on the MSO1000Z

Thanks for checking this, I thought nobody's gonna read / check this after all this bit resolution / high res talk   

(you can actually see the code recalculate and replace the incorrect values after moving the offset). So they've fixed it in their latest model - now we've just got to get them to port the fix to the DS2000A/DS4000.

So on the 1000Z the scope displays the bogus values first and after a second or similar the values get overwritten with correct ones?

If that is the case I'm not sure if it is really an intentional fix or they just restructured the measure code a bit and this is just a byproduct. I guess the statistics still get completely garbled up once the bogus values show up for a short time? If yes then I'd still count this a bug...

[eV1Te]

I've written and posted a lot of information about this in other threads, but I thought I would try to gather together some of it here for clarity:

There at least three big operational differences that I've noticed in the implementation of High Res on the DS1000Z as compared to the DS2000:

1) High Res can not be applied to a captured waveform (stopped DSO) on the DS1000Z; you can only use it when running.

2) High Res on the DS1000Z is destructive - i.e. the original samples are unavailable. On the DS2000, you can turn High Res back OFF after capturing a waveform; on the DS1000Z, once the DSO is stopped, you can't recover the original waveform to the display - although I haven't tested saving sample memory to USB or PC, so perhaps the original samples ave available that way.

3) Most importantly: on the DS1000Z, High Res mode appears as if it might be implemented after display decimation - or at least, in some kind of strange combination with it - resulting in some aliasing and other artifacts. The DS2000 follows the mathematical model of successive sample averaging quite well, while the DS1000Z seems to be doing things poorly in comparison.

That is a nice selection of measurements, the BW definitely shows that it does some boxcar averaging.

So am I right in assuming that the reason why we both see a reduction in BW and also no additional bits of resolution, is probably due to the fact that the DS1000z boxcar averaging is done all with 8bit integer math? That could explain all the observations we have made, and it also sounds reasonable since it has less processing power than the DS2000.

[marmad]

Thanks for checking this, I thought nobody's gonna read / check this after all this bit resolution / high res talk   

No problem at all. I'd read your post, but just didn't get around to running the tests until I responded to some other posts 

So on the 1000Z the scope displays the bogus values first and after a second or similar the values get overwritten with correct ones?

More like a fraction (0.25) of a second.

If that is the case I'm not sure if it is really an intentional fix or they just restructured the measure code a bit and this is just a byproduct. I guess the statistics still get completely garbled up once the bogus values show up for a short time? If yes then I'd still count this a bug...

I would say that someone at Rigol noticed that changing the offset screwed up the Math measurements, and they tacked on a routine to update them correctly.

[marmad]

So am I right in assuming that the reason why we both see a reduction in BW and also no additional bits of resolution, is probably due to the fact that the DS1000z boxcar averaging is done all with 8bit integer math?

That's possible - although the more tests I do, the more I start to become convinced that the High Res feature is really not implemented correctly on the DS1000Z - either by fault or design. Often the effect is almost exactly the same as normal Average, when it really shouldn't be.

Take a look at the following 3 images; I've sent a 1MHz sine wave to both scopes (BTW, it doesn't matter that the DS2000 and DS1000Z are using different timebases - what matters is that the sample rates are as similar as possible):

Given a sample rate of 20MSa/s on the DS2000 with 256-sample averaging, the -3db bandwidth should be 34kHz - so a 1MHz signal should be virtually invisible (which it is). Compare that to the DS1000Z with a similar sample rate (25MSa/s) and 1MHz input signal. The resulting High Res display is almost exactly the same as you get using Average - which is exhibiting aliasing.

[TMM]

That's possible - although the more tests I do, the more I start to become convinced that the High Res feature is really not implemented correctly on the DS1000Z - either by fault or design. Often the effect is almost exactly the same as normal Average, when it really shouldn't be.

You've finally seen the light eh?

[marmad]

That's possible - although the more tests I do, the more I start to become convinced that the High Res feature is really not implemented correctly on the DS1000Z - either by fault or design. Often the effect is almost exactly the same as normal Average, when it really shouldn't be.

You've finally seen the light eh?

I've been posting there was a problem with High Res on the DS1000Z series for about a month now.

But as I showed with the sweep images above, the DSO is clearly doing some boxcar averaging (which I believe you asked me post actual documentation to prove before - so there you go ). I actually think the problem might be that it's doing some display decimation before the averaging (at least with large sample sizes) - which would be a terrible idea, but would save time and processing power. But in any case, the only results I've been able to see so far were either correct - but with very small averaging sizes (perhaps 4 - 16 samples) or else large averaging sizes with bad artifacts (like aliasing).

[TMM]

Another thing to note is that on the 2K, when you enable high-res the intensity grading is disabled?

On the 1K the intensity grading runs even in high res. I wonder if that could explain why the data seems to still be 8bit (they round the high res data back to 8bit in order for the intensity grading to work?). It doesn't explain why the high freq rolloff is different to the 2K though.

[marmad]

Another thing to note is that on the 2K, when you enable high-res the intensity grading is disabled?

Rigol coded the intensity-grading on the DS2000 in a fairly strict, non-adaptive way - which can sometimes be good and sometimes bad. Since the grading is based on both complete waveform update hits and overlapping sample hits (e.g. 1.4M samples to 700 horizontal display px), when High Res is turned on, all of a sudden large groups of samples are averaged to single points - i.e. single hits - so the intensity grading is reduced immediately. You can get some grading (depending on the memory depth and timebase), but it's much reduced from Normal mode.

[David Hess]

nah, just slightly surprised we're still in 8bit time....

There is a good reason for this and it is also why analog oscilloscopes support a maximum sensitivity for a given bandwidth; the total noise from the vertical input amplifier over a wide bandwidth is considerable so in practice greater than about a 2mV/div or 5mV/div sensitivity on a 100 MHz oscilloscope is not useful.

If you want greater useful sensitivity, then the input bandwidth has to be limited and some analog oscilloscopes do this automatically.  DSOs can provide greater sensitivity and resolution through averaging or high resolution mode which both remove noise.  A higher resolution ADC is not needed and does nothing in this case.

Another problem with higher resolution is that fast settling time to 8 bits is difficult enough to achieve.  If 12 bit resolution is used, it does not reveal anything new on fast signals because they will not settle any faster.  Improvements can be made in this area but they are difficult.

12 bit and higher resolution oscilloscopes do exist, even the Tektronix 7854 is 10 bits and has a 10 bit display to support that, but they are still limited by noise and settling time so the extra resolution is not useful in a general way.  Sampling oscilloscopes often have much higher than 8 bit resolution.

[David Hess]

EEVblog ate my original reply with a redirect so what is below is abbreviated.

The TDS460A series specifications (the TDS500 series are the same) are very specific about using 50 pixels per division with a 8 x 10 graticule producing a 401 x 501 pixel graticule on a 480 x 640 display and mapping 25 8-bit levels per vertical division so 2 pixels per 8-bit level.  8 vertical divisions only yields 200 8-bit levels but Tektronix liked to keep clipping outside of the visible display.

The DS2000 uses the same mapping.

An integer mapping prevents or minimizes aliasing from the display.  The TDS documentation discusses how those DSOs apply interpolation when this is not the case.  Many Tektronix models have a mode where the actual sample points are highlighted to distinguish them from interpolated points.

I am not sure why the documentation would discuss it.

Well, ok then - I'll leave it there... and just assume those expensive DSOs can do it.

The DSOs I have certainly do but they date from a time when all DSOs were expensive.

While testing I found something interesting on the Tektronix 2232; it reports the amount of memory each saved waveform takes.  1k record length waveforms take 1kbyte and 4k record length waveforms take 4kbytes which is consistent with 8 bit acquisition records and 8 bit waveform records.  When averaging is used, the waveform records double in size taking 2kbytes or 8kbytes.

...while the Rigols apparently make measurements on the display record...

You keep mentioning this as if it's an anomaly in low-cost scopes. Instead, could you perhaps come up with some other low-cost brands which don't do this?    Agilent X-series? Nope, they do it too.

The Rigols were the first oscilloscopes I considered when looking for a new DSO and I expected better.  Making measurements (and protocol decoding) directly from the display is something I would expect in a toy no matter who makes it.

There is a caveat with the above however.  If DPO type operation produces the display record during acquisition which is the case with older DPOs, then there is no choice if measurements are made because the display record is the only thing available.  That explains limitations on oscilloscopes where DPO operation is used and may explain some of the limitations on the Rigol Ultravision oscilloscopes where DPO operation is fixed.

You have to keep in mind - Agilent was Rigol's mentor. Much of the behavior and feature set of Rigol's DSOs, for good or ill, is learned or copied from Agilent.

Current DSOs from Agilent appear to be better than the ones from Tektronix but I would carefully evaluate either for this type of problem.

[Teneyes]

I started new thread just for "Rigol DSO Trigger position Offset w/ AC coupled trggering , DS2000, MSO1000"
and I will collect confirmations of which models have this bug and return results to this thread later.
New Thread Here

[i4004]

btw. anybody compared rigol's 'video' tigger to other dso's simillar triggering items?
on pal or ntsc...
would you expect perfectly still waveform even wothout stopping the scope?

[marmad]

The Rigols were the first oscilloscopes I considered when looking for a new DSO and I expected better.  Making measurements (and protocol decoding) directly from the display is something I would expect in a toy no matter who makes it.

It's SOP below a certain price point, so I guess it's just a market full of toys. Too bad for you; you'll likely never be able to buy a low-cost DSO.

Personally, I wouldn't count on an oscilloscope for making precise measurements (a habit I learned from trying to count graticule tick marks on analog scopes) - just as I wouldn't count on an MSO for complex logic analyzing - feels rather like using a screwdriver to hammer a nail.

[i4004]

taken from here
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-font-size/msg559800/#msg559800


aaa..there's the marmad i know, getting all feisty  over nothing.
again. 

Well, no - sorry, I have not learned anything new from your posts - which continue to be filled with loads of incorrect speculation and bad information. 

damn, i see simillar posts from teenagers when they first appear on the web! 
ego-trips.
adults just correct the wrong info.
you learned your camera is crap. i bet recent smartphones have better quality.

There is no "virtual 12bit stuff". It seems you still don't understand how the DSOs are working. I suggest you go back and re-read the posts in the other thread.

nope, i think you didn't understand the terminology i used, in a simillar fashion that you calculate bits of vertical resolution to end up with a decimal point numbers. 9.8bits i think you calculated somewhere. 
if the adc is 8bit (and it is on both 1k and 2k scopes) than any way to achieve higher res will be virtual because it's not real, it's achieved by tricks.
(as rf loop explains shorter and simpler than your pdf paper, not that pdf is bad)
it's just that 2k is devoting more cpu to doing it, ie z is not really doing it, like we saw from the screenshots.
i understand exactly how they get virtual "12bits" from real 8bits. i mentioned it in the thread, if it's wrong, correct it.

No, you're wrong again on multiple points. Either your eyes are bad, you don't use a color-corrected monitor, or you don't understand what you're looking at.

my god man, my god! come here and we'll test our eyes, we'll see their color performance, we'll see of color (on monitor) affects this (at all) and we'll also talk about pixelization by lower resoltuion, which seems not really quite your field of expertise.....
if you can't see a drastic resolution decrease in z portion of the screen i posted above, then you'0
re quite unfamiliar with the way images are scaled.....
see this, both images originated from same lores source, one is jaggy, one is less jaggy but more blurred...the only difference is resizer.....





now, it is not really important for us to go into details of how and why (although we already did, and can do some more) but the fact is z has consideratly less vert. res. with same number of bits of adc. and same display resolution!

There is no lower resolution - they are exactly the same -

meh, make a 320x240 paint image of diagonal thin line(or sine form), and then make the same thing (same line, slanted in a same angle) on 1920x1080, and you'll probably get what i'm talking about.
probably!

and the only thing that the DS1000Z has going for it is slightly more contrast (due to a brighter backlight). But it's "washed-out" and less "sharp" (this is NOT the same thing as contrast) because of it's worse sub-pixel anti-aliasing. This is apparent - even to those with poor vision - when you examine the images close-up (using pa3bca's photos) :

you're going on too far in a wrong direction. you talk about small nuances that less will notice(i would, and better than you, i wear no glasses and can read z display just fine, font is not small for me) and skip the "elephant in the room" ie the jagginess of the z sine forms.

First, here is the rendering of "black" on both DSO screens - normal and inverted to "white". If it's not obvious which one is closer to true black, then you need a new computer monitor (or you need to calibrate the one you've got):

what a nitpicking parade!
it's probably true, it's probably correct, but i just can't bring myself to the fact that you see the 1000(z?) trees and yet not see the forest! 

I repeat: there is no higher res - they are both in Normal acquisition mode on displays of equivalent resolution.

this tells me 2k has much better resizer, the thing that converts less adc levels to more pixels the display has.
when both displays are 480 pixels high.

again, could you, please, make a png screenshots from both scopes on that AM signal?
i' m really interested in this, ie why it's happening.

[marmad]

damn, i see simillar posts from teenagers when they first appear on the web! 
ego-trips.

No, this is what adults say to children who continually interject nonsense that is incorrect, off-topic, rude, or irrelevant.   

nope, i think you didn't understand the terminology i used, in a simillar fashion that you calculate bits of vertical resolution to end up with a decimal point numbers. 9.8bits i think you calculated somewhere. 

If you bothered to actually read or comprehend anything that was posted here, you would know I was quoting those numbers from a Tektronix document. This just proves, once again, that you have no interest in understanding anything that doesn't fit within your own narrow concerns or opinions.

if the adc is 8bit (and it is on both 1k and 2k scopes) than any way to achieve higher res will be virtual because it's not real, it's achieved by tricks.

It's math - plain and simple. Is all math just a trick? Is the fact that we turn real-world analog signals into digital number-streams via electrons and math a trick? I suppose all those things would seem like tricks to, for example, a monkey.

...and we'll also talk about pixelization by lower resoltuion, which seems not really quite your field of expertise.....

   Much more than yours, I'm quite sure.
 

you're going on too far in a wrong direction. you talk about small nuances that less will notice(i would, and better than you, i wear no glasses and can read z display just fine, font is not small for me) and skip the "elephant in the room" ie the jagginess of the z sine forms.

I was responding to and writing about exactly the things that people in the other thread were interested in and asking about: the legibility of the fonts and the overall display quality (the thread is called "Ridiculously small Rigol DS1000z series font size"). You, otoh, were driving off-topic.

this tells me 2k has much better resizer, the thing that converts less adc levels to more pixels the display has.
when both displays are 480 pixels high.

again, could you, please, make a png screenshots from both scopes on that AM signal?
i' m really interested in this, ie why it's happening.

This has all been discussed in-depth in another thread; I suggest you read it there. Oh, wait - you're the guy that doesn't know how to use Google to do forum seaches, right?    Ok, I suggest you FIRST learn how to do forum searches, then find where we were discussing the mapping of the ADC of the DS1000Z, then read it there. 

[i4004]

If you bothered to actually read or comprehend anything that was posted here, you would know I was quoting those numbers from a Tektronix document.

i know that.

but do tell: how many levels is that bit number, and in what circumstances?
bleh
i like hess' response better:

I am not sure what you found but I suspect the numbers, 6.8 bits and 9.7 bits, came from the ENOB (effective number of bits) specifications that Tektronix often includes or used to include.  They represent the dynamic range of the digitizer and have nothing to do with mapping ADC levels to the display.

You can find the same type of ENOB specifications in the datasheets for the ADCs Rigol is using but they represent ideal values; the real numbers are lower do to outside factors like clocking and noise.

It's math - plain and simple. Is all math just a trick?

marmad, i'm pretty sure you would pick 'true' 10bit or 12bit adc (without extra processing) versus 8 bit with virtual 12bits, am i not correct?
so all this writing of yours flops right there.

math can be used in all sorts of ways. i would prefer 1:1 mapping with more bits in adc, and so would you.

Much more than yours, I'm quite sure.

for you, these 2 segments

are the same?
and you talk about my vision and reasoning? 

You, otoh, were driving off-topic.

kinda, sorta, but because i saw great difference in the image (of both scopes) you posted there, and that image shows fonts in some way? 

but i agree with you, some offtopic is good!
you said it quite well in other thread!
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg556083/#msg556083

 

Oh, wait - you're the guy that doesn't know how to use Google to do forum seaches, right?

that's quite mean, as i already explained
https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg530392/?topicseen#msg530392

".just like i wrote in added edit "it's over, google found us just now, now everybody knows!" which was written prior to your post.
so yeah, now you can, but then? no."

you also have this
https://www.eevblog.com/forum/testgear/new-rigol-ds1054z-oscilloscope/msg521251/#msg521251


so don't use that garbage anymore, it's doesn't become truth if you repeat it.
it wasn't easy to find then. now?
much easier....there's a yt video on first page of results, just like i wished for! 

Ok, I suggest you FIRST learn how to do forum searches, then find where we were discussing the mapping of the ADC of the DS1000Z, then read it there.

what, this stuff between me and you
https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg555796/#msg555796
?

what about if i tell you how would i do it, and then you tell me how would you do it?

ok, presuming we can't have 10 or 12bit adcs (and we obviosuly can't) i would resize those 256 voltage levels to desired display resolution by using something like lanczos resize (in hardware in real time) or alike.
now you. how would you do it?
256 levels to 400 pixels. would you use 'double pixels' and why on earth would you do that?
hehe....

[marmad]

Following up on Teneyes' post on the Trigger Output jitter change (normally ~8ns on both DS1000Z and DS2000), I did a little more experimentation.

In the first set of images from the DS2000 running FW 03.01.00.04, switching the trigger coupling from DC -to- AC -to- LFR/HFR has the effect of changing the jitter from 8ns -to- 1.2ns -to- 4 alternating bands of 1.2ns preceded by gaps of 800ps.

In the second set of images from the MSO1000Z using FW BETA 04.01.03.00, switching the trigger coupling from DC -to- AC/LFR has the (non)effect that Teneyes noticed - i.e. the output jitter doesn't get smaller (although the delay out changes - notice the trigger delay settings used to center the waveform). But the interesting thing that I noticed was that using the HFR trigger coupling produced a rock-solid Trigger Output (absolutely no jitter - last image) - although the input frequency of the triggering signal probably can't be too fast since the HFR is a ~75k low-pass filter (I tested it working to  500kHz).

[XFDDesign]

It's math - plain and simple. Is all math just a trick? Is the fact that we turn real-world analog signals into digital number-streams via electrons and math a trick? I suppose all those things would seem like tricks to, for example, a monkey.

If you follow his claim (as it wasn't an argument; it wasn't backed up by anything), then all existence is "virtual" as it's merely "tricks" of physics and chemistry. The transistor's function is "virtual" by nature of it's use of "tricks" in applied physics and the use of math. The resulting voltage tolerance of two capacitors in series is a "virtual" capacitor, by mere function of the use of physics (and the application of math). Etc.

In an attempt to return the subject at hand, does anyone have a list of bugs with the DS4000 series scopes? I'm particularly interested as my TDS5034B died, and as a result am no longer buying Tektronix anything (same series model now costs 2x, and is make just the same in China. If the decision is "a $5k scope that is made in China and lasts 3 years" versus "a $15k scope that is made in China and lasts 3 years" well the Tek amount of money will last me 9 years, which is almost as long as the TDS5034B lasted me. But, the concern is the bug list. People on the forums have said that the 4k series has a lot of bugs, yet all my googling has only unearthed a SPI Decode bug and that is it. 

[marmad]

In an attempt to return the subject at hand, does anyone have a list of bugs with the DS4000 series scopes? I'm particularly interested as my TDS5034B died, and as a result am no longer buying Tektronix anything (same series model now costs 2x, and is make just the same in China. If the decision is "a $5k scope that is made in China and lasts 3 years" versus "a $15k scope that is made in China and lasts 3 years" well the Tek amount of money will last me 9 years, which is almost as long as the TDS5034B lasted me. But, the concern is the bug list. People on the forums have said that the 4k series has a lot of bugs, yet all my googling has only unearthed a SPI Decode bug and that is it. 

Have you seen the one created by Altemir? It's fairly comprehensive, but I notice that he doesn't have the latest FW listed (02.02.01.01) and that he hasn't been on the forum for 2 months - so it hasn't been updated (e.g. I know the latest version allows decoding of recorded frames). But you can probably ask over in that thread for more details about other bugs that might have been fixed in the latest FW.

[motocoder]

But the interesting thing that I noticed was that using the HFR trigger coupling produced a rock-solid Trigger Output (absolutely no jitter - last image) - although the input frequency of the triggering signal probably can't be too fast since the HFR is a ~75k low-pass filter (I tested it working to  500kHz).

Yes, Very interesting.
I have a suspicion that the trigger out in the HFR mode uses a fix hardware timer ,
possible made for Mixed mode.
I will ask Motocoder to test hs DS2000 with his leak beta version on the HFR mode.to see how that looks.

Screenshot attached.

[XFDDesign]

Have you seen the one created by Altemir? It's fairly comprehensive, but I notice that he doesn't have the latest FW listed (02.02.01.01) and that he hasn't been on the forum for 2 months - so it hasn't been updated (e.g. I know the latest version allows decoding of recorded frames). But you can probably ask over in that thread for more details about other bugs that might have been fixed in the latest FW.

I hadn't, and my SearchFu is apparently weak. Thank you very much for the pointer!

[Mark_O]

Following up on Teneyes' post on the Trigger Output jitter change (normally ~8ns on both DS1000Z and DS2000), I did a little more experimentation.

In the first set of images from the DS2000 running FW 03.01.00.04, switching the trigger coupling from DC -to- AC -to- LFR/HFR has the effect of changing the jitter from 8ns -to- 600ps -to- 4 alternating bands of 600ps preceded by gaps of 400ps.

I'll buy the 8ns, but your '600ps' looks more like 1.2ns to me.  I think you may have forgotten one factor of 2x when you multiplied?  (0.6 div, yes, but 2ns per.)

Same for the 600ps+400ps.  That winds up 1.2 + 0.8ns, and the 4 bands combined span the same 8ns as the original, just segmented.

[marmad]

I'll buy the 8ns, but your '600ps' looks more like 1.2ns to me.  I think you may have forgotten one factor of 2x when you multiplied?  (0.6 div, yes, but 2ns per.)

Same for the 600ps+400ps.  That winds up 1.2 + 0.8ns, and the 4 bands combined span the same 8ns as the original, just segmented.

Yep - good catch - somehow I used 1ns/div when counting tick marks. Fixed.

[marmad]

Another strange anomaly in the DS1000Z - first spotted by rf-loop in this thread.

As pointed out by rf-loop (and confirmed by me) the Sin(x)/x ON/OFF switch on the DS1000Z does absolutely nothing to change the interpolation - if the DSO is using Sin(x)/x, it stays Sin(x)/x - and if it's using Linear, it stays Linear - regardless of the switch setting.

But I think Rigol has completely screwed-up the labeling of the function of this switch. I think, instead of interpolation, it's doing some kind of BW-limiting (maybe 50MHz?) on all of the input channels simultaneously - perhaps to try to prevent aliasing when 3/4 channels are active with the reduced 250MSa/s rate. But it only seems to be active between 100 - 5ns/div.

Image #1 shows 100MHz sine to CH 1 & 4: "Sin(x)/x ON"
Image #2 shows 100MHz sine to CH 1 & 4: 20MHz BW limit on CH1 - "Sin(x)/x ON"
Image #3 shows 100MHz sine to CH 1 & 4: 20MHz BW limit on CH1 - "Sin(x)/x OFF"

[leppie]

perhaps to try to prevent aliasing

So many useless buttons/features on this scope

Is there a summary post for all known DS1000Z issues yet?

[David Hess]

The Rigols were the first oscilloscopes I considered when looking for a new DSO and I expected better.  Making measurements (and protocol decoding) directly from the display is something I would expect in a toy no matter who makes it.

It's SOP below a certain price point, so I guess it's just a market full of toys. Too bad for you; you'll likely never be able to buy a low-cost DSO.

I bought several low cost DSOs at that time including a Tektronix 2440 but they are all old enough to vote and drink which is not an avenue I would suggest to a neophyte.  None of them were newer than 21 years old which is a measure of how little I thought of Rigol's instruments at that time.

Personally, I wouldn't count on an oscilloscope for making precise measurements (a habit I learned from trying to count graticule tick marks on analog scopes) - just as I wouldn't count on an MSO for complex logic analyzing - feels rather like using a screwdriver to hammer a nail.

Using the display record to make automatic measurement is a hack; its like making measurements from a screenshot instead of the actual data and just adds another layer of processing and aliasing.  I would like to know why they did it this way.  I would suspect it was for performance reasons except that their slow DSOs work this way also.

One of the annoying results is that measurements made of a saved waveform change depending on how it is displayed.  As discussed in another EEVblog thread, there is more than a loss of precision if the automatic measurements are jumping by 50% on a saved waveform.  That is just broken.

[marmad]

Using the display record to make automatic measurement is a hack; its like making measurements from a screenshot instead of the actual data and just adds another layer of processing and aliasing.  I would like to know why they did it this way.

As mentioned multiple times already, Agilent does it - and likely did it before any of the Chinese manufacturers did it - so I would guess that's where the idea comes from. So you continually bringing it up solely in terms of Rigol is both silly and a moot point.

[David Hess]

Using the display record to make automatic measurement is a hack; its like making measurements from a screenshot instead of the actual data and just adds another layer of processing and aliasing.  I would like to know why they did it this way.

As mentioned multiple times already, Agilent does it - and likely did it before any of the Chinese manufacturers did it - so I would guess that's where the idea comes from. So you continually bringing it up solely in terms of Rigol is both silly and a moot point.

Agilent doing it does not make Rigol's implementation any better.

Which models of Agilent DSO operate this way?  Didn't they outsource design and production of their low end DSOs to China?

[Teneyes]

As mentioned multiple times already, Agilent does it - and likely did it before any of the Chinese manufacturers did it -

Old connection of Aligent to Rigol is noted in this article back in 2009
And I am sure there was some exchange of technology (spying,agreements)

[marmad]

Agilent doing it does not make Rigol's implementation any better.

I wrote nothing about "better". What I did write, repeatedly already, was that you bringing it up in multiple threads as if it's some strange anomaly of Rigol scopes is just nonsense. Agilent, Siglent, Hantek, and who knows how many others, do it. We've already been discussing this issue on this forum for years before you joined.

[i4004]

any of the listed bugs/anomalies fixed in recent firmware(s)?

is rigol reading this, or is it just fixing the "peaks", ie bugs that are most obvious?

as someone else mentioned in another thread, such threads would be more usefull if the findings and fixes were updated in the first post.

[rowifi]

Not been following this thread, so this may already be known.
Our DS2202A shows a strange behavior when triggering.
It does not trigger with the vertical gain set low, even though the signal is visible on the screen

Using edge trigger and using Normal mode, use the built in scope probe test pin. The square wave is 3V peak to peak. Set Vertical gain to 1V/div and set trigger to say midway ( 1.5v). The Trigger works and the waveform is shown.
.
Reducing the Vertical gain in steps, the waveform will reduce and the trigger level indicator also reduces accordingly, but when the vertical gain is 10V/div  or lower  the trigger fails and a WAIT message is shown.

The scope does record the waveform for one sweep when the vertical gain is changed, and it therefore 'appears' to be triggering, but the WAIT message is displayed and the scope is not updating the waveform.
 
Forcing a trigger or using auto mode shows that the signal is still present and measurable by eye.