BTW, both versions of RUU use the same routine to get the image from the DSO (it expects 480 vertical pixels), so it shouldn't make a difference in terms of losing the bottom.

It did it on RUU1.51 it chewed the bottom space that hosts up to 5 selected measurements. I try again now to post you a screen and it does OK. Has to do with rebooting maybe?

Also no white top tag space appears on any version RUU screen save now. Not in a screen print to USB .bmp either. All I did was to self cal and turn off. 

---

It did it on RUU1.51 it chewed the bottom space that hosts up to 5 selected measurements. I try again now to post you a screen and it does OK. Has to do with rebooting maybe?

I grabbed my first image using RUU 2.0 and it also took off the bottom. But I don't know why the DSO stops putting on the border - could probably figure it out by downgrading then upgrading again, but it doesn't seem worth the effort since it wasn't a serious issue.

Hi All - I am away from a DS2000 until Tuesday but have reported this to Rigol and hopefully should have a fix soon.

Thanks for your patience

John

The white band on the picture has vanished here too. All measurements have the same value of +Width, which was set last. Rebooting gives correct values of measurements!

---

After playing around more with the new firmware, I have more information:

It appears that the measurement bug is simply invoked by re-selecting more than one item from the left-side menu. If any measurements are already selected when booting up (showing at the bottom of the screen), they work perfectly fine.

Edit (Copied from Post #1):
Current workarounds:
Only select 1 measurement for screen bottom.
Use 'Display All' (with 0 or 1 measurement at screen bottom).
Make sure System -> Startup is set to 'Last', then select the measurements you want at screen bottom and reboot.

I have just verified that self-calibration still erases the trial options in FW version 01.00.00.03.

Strange, I would have thought that was one bug that Rigol would really want to eliminate (to avoid complaints and requests for new codes from new owners).

Post #1 and #2 re-edited to show current state/list of known firmware bugs/version numbers and to allow easier linking for firmware instructions.

I have just verified that self-calibration still erases the trial options in FW version 01.00.00.03.

Strange, I would have thought that was one bug that Rigol would really want to eliminate (to avoid complaints and requests for new codes from new owners).

I can confirm, that FW 00.00.01.00.05 also still has this issue!

Now I can't test the nice serial decode feature today :-(

Is there any running hours or power-up times counter on Rigol scopes?

I've been running some tests to try to determine what type/when different interpolation methods are used by the Rigol DS2000 (for another thread), and I thought I'd re-post my findings here.

It seems (although I might be incorrect about this) that the Rigol does not use the timebase setting to determine the interpolation method - but instead uses the sample rate. From what I've discovered so far, it appears that:

If the sample rate <= 500MSa/s it uses linear interpolation.
If the sample rate >= 1GSa/s it uses sin(x)/x interpolation

Images here.

It appears that Rigol is being cautious by making sure only to use sin(x)/x interpolation when the signal is being band-limited above the Nyquist rate (for 1GS/s this is 500MHz and above; so should be well attenuated by the 200MHz bandwidth limit of the DS2000 series). * Thanks to jpb for this observation 

I've been running some tests to try to determine what type/when different interpolation methods are used by the Rigol DS2000 (for another thread), and I thought I'd re-post my findings here.

It seems (although I might be incorrect about this) that the Rigol does not use the timebase setting to determine the interpolation method - but instead uses the sample rate. From what I've discovered so far, it appears that:

If the sample rate <= 500MSa/s it uses linear interpolation.
If the sample rate >= 1GSa/s it uses sin(x)/x interpolation

Based on the math (in theory, using sin(x)/x can accurately reconstruct the waveform assuming a sample rate at least 2.5 times the highest frequency component - as opposed to linear interpolation, which requires a sample rate at least 10 times higher), it seems like it would make more sense the other way around - although I guess the fact that it uses linear interpolation at lower sample rates means that (if you don't pay attention) you're more likely to quickly realize you're undersampling.

I responded on the other thread - but I thought I'd make the same point here for the benefit of those who only read the one thread.

My understanding is that sinc(x) attenuation will give you aliasing if the original signal contains components above the Nyquist frequency (the higher components will fold back into the pass band). Given the scope bandwidth is around 200MHz or perhaps nearer 230MHz at 500MS/s the Nyquist frequency is only 250MHz so will only be attenuated by a bit more than 3dB hence using sinc(x) interpolation risks giving wrong answers. At 1GS/s the Nyquist frequency is 500MHz and for a 200MHz BW(3dB), 500MHz will be attenuated by around 9dB (that is power not amplitude) so the assumption that the higher components are not there is a better approximation.

Linear interpolation is cruder but will be less wrong in that it won't introduce false peaks though it will introduce discontinuities in the gradient.

It appears that the measurement bug is simply invoked by re-selecting more than one item from the left-side menu. If any measurements are already selected when booting up (showing at the bottom of the screen), they work perfectly fine.

It is possible to do one measurement correctly without booting. Clear all measurements and select only one measurement from the side menu.

---

It is possible to do one measurement correctly without booting. Clear all measurements and select only one measurement from the side menu.

Um... that could be why I wrote, "...re-selecting more than one item..." 

BTW, as long as you clear the measurements displayed at the bottom of the screen (if you have more than one), you can also use 'Display All', which will show the correct measurements.

Hi All - Rigol are looking at another firmware release in about 2 weeks. This will fix the measurement ,and hopefully other , bugs.

Hi All - Rigol are looking at another firmware release in about 2 weeks. This will fix the measurement ,and hopefully other , bugs.

Thanks for the update, John.

John can you pass user requests to Rigol for adding cool stuff in the future? If yes, I would propose amber, green, b&w color schemes & digital filter sub menu please. 

Hi jpb

I responded on the other thread - but I thought I'd make the same point here for the benefit of those who only read the one thread.

My understanding is that sinc(x) attenuation will give you aliasing if the original signal contains components above the Nyquist frequency (the higher components will fold back into the pass band). Given the scope bandwidth is around 200MHz or perhaps nearer 230MHz at 500MS/s the Nyquist frequency is only 250MHz so will only be attenuated by a bit more than 3dB hence using sinc(x) interpolation risks giving wrong answers. At 1GS/s the Nyquist frequency is 500MHz and for a 200MHz BW(3dB), 500MHz will be attenuated by around 9dB (that is power not amplitude) so the assumption that the higher components are not there is a better approximation.

Linear interpolation is cruder but will be less wrong in that it won't introduce false peaks though it will introduce discontinuities in the gradient.

In my opinion the amount of aliasing will depend only of the sampling frequency and the analog bandwidth of the scope.
I am wondering if they actually do up-sampling and post digital filtering of the data before showing on screen?
If they do real interpolation then sinc is more short band interpolation (brick wall ideal filtering at Nyquist)
than linear which is sinc^2 like filtering with node at the sampling frequency. 

Regards
Dimitar

Hi jpb

Quote

I responded on the other thread - but I thought I'd make the same point here for the benefit of those who only read the one thread.

My understanding is that sinc(x) attenuation will give you aliasing if the original signal contains components above the Nyquist frequency (the higher components will fold back into the pass band). Given the scope bandwidth is around 200MHz or perhaps nearer 230MHz at 500MS/s the Nyquist frequency is only 250MHz so will only be attenuated by a bit more than 3dB hence using sinc(x) interpolation risks giving wrong answers. At 1GS/s the Nyquist frequency is 500MHz and for a 200MHz BW(3dB), 500MHz will be attenuated by around 9dB (that is power not amplitude) so the assumption that the higher components are not there is a better approximation.

Linear interpolation is cruder but will be less wrong in that it won't introduce false peaks though it will introduce discontinuities in the gradient.

In my opinion the amount of aliasing will depend only of the sampling frequency and the analog bandwidth of the scope.
I am wondering if they actually do up-sampling and post digital filtering of the data before showing on screen?
If they do real interpolation then sinc is more short band interpolation (brick wall ideal filtering at Nyquist)
than linear which is sinc^2 like filtering with node at the sampling frequency. 

Regards
Dimitar

Perhaps I misused the term aliasing - I was using it as short hand for the erroneous results arising from sinc(x) interpolation when the signal is not band limited to below the Nyquist frequency.

This (rather old) LeCroy app note gives some experimental results.

http://cdn.teledynelecroy.com/files/whitepapers/wp_interpolation_102203.pdf

Presumably upsampling and then digital filtering would be equivalent to linear interpolation followed by a low pass digital filter.

As an aside, I've been looking at arbitrary waveform generators recently and Agilent with their latest low end ones use up sampling followed by a low pass filter to reduce the jitter inherent with using a fixed sampling clock rate but that is at much lower frequencies (40MHz or less), the sampling rate is upped from 250MS/s to something over 1GS/s but in a scope they are already at rates above 1GS/s and also are trying to maximise the waveforms per second so I wouldn't think that they do it.

Following up on my post from yesterday about interpolation on the DS2000 - here are two images of a 100MHz sine wave:

This is the sine wave sampled at 500MSa/s - and the Rigol automatically uses linear interpolation:




This is the same sine wave sampled at 1GSa/s - and the Rigol automatically uses sin(x)/x interpolation:

---

Are you sure that second image is non-linear? To my eye, it could easily be linear with twice as many points, and it looks a bit funny for a perfect sin.

Are you sure that second image is non-linear? To my eye, it could easily be linear with twice as many points.

Seriously? You think that's how the image would look if connected with straight line segments? With 5 sample points per division?    Well, here it is for you  - un-interpolated. Print it out, get out a ruler and pencil, and give it a go 

...and it looks a bit funny for a perfect sin.

There is no such animal.

---

As I see it the Rigol collects the data points and then a display process occurs to create the vector display
But only the data points are saved in the save Waveform files.

There is acquire memory and there is display memory.

The acquire memory contains the sampled points - and it can be anything from 28 bytes (with 2 channels) to 56MB (or up to at least 114MB when segmented). That is what is saved in WFM and (if "Maximum" selected) CSV files.

The display memory contains an intensity map built-up from many waveform captures - this is what is saved in TRC files.

Also in another portion of (acquire or display) memory, an interpolation of the last/current waveform capture is stored; it is always 1400 bytes (unless the DSO is stopped and the timebase is increased past the sample length). It consists of endpoints of vectors, and is what is saved in CSV files (if "Displayed" selected), and also what RUU uses to display the waveform.

Hi Guys,

Few comments I have in mind please correct me if you don't agree with something

Perhaps I misused the term aliasing - I was using it as short hand for the erroneous results arising from sinc(x) interpolation when the signal is not band limited to below the Nyquist frequency.

Well aliasing in my opinion is not a result of an interpolation. It is actually result of a sampling of the analog signal with bandwidth more than Nayquist rate (half of sampling rate). In this case we have 'folding' of the high frequency components in the signal main frequency band and this is unrecoverable by any means.(We have to increase the scope sampling frequency (reduce time base) to fix). If however the Nyquist rule is met then we can use interpolation to recover (show on screen) the exact 'analog' signal (this is done by interpolation) 
Interpolation is a way to reconstruct the analog signal from the sampled data and this is what the DSO tries to do - after all we want to see picture on screen as close as possible to the original analog signal. 

-If we know that our analog signal has no energy above current scope Nayquist rate (fs/2) we should use sinc interpolation.
For example if I have 100Mhz scope and I think I have analog signal covering roughly those 100Mhz and if i sample with 500Msamples/s (to get bigger time frame for example) It is very important to turn sinc interpolation on, as in this case for the fast frequency components the scope got only 5 points per period and interpolation will greatly provide the 'true' analog behavior in between sampled points.     

-If we know we sample much faster then the signal band width (20 times for example) then we know we have captured all signal details with enough sample points so interpolation is not that important anymore in my opinion.

- If we sample with rate below signal bandwidth*2 we know we have aliasing for sure. This is more subtle and my thinking are as follows:
In this case sinc interpolation will show on screen picture less accurate then if we use linear interpolation. This is because sinc interpolation means filtering with ideal brick wall with cut at fs/2. Linear interpolation is equivalent with filtering with sinc^2 filter with nod at fs - bigger bandwidth of interest, so in this case we get more true signal energy shown on screen. 
Probably this is why Roigol switches the interpolations (linear sinc) as it was mentioned before?

- If we have analog signal 1Ghz band but my scope is only 100Mhz and I have set fs=1Gsamples/s then we don't have much aliasing because the scope analog channel filter will probably drop down a lot at the Nyquist rate 500MHz and we will see on scope the 'true' part of the signal with energy in the band below 100MHz. (in this case we have no clue about the part above 200MHz let say but important is that this doesn't affect the accuracy of what scope shows)   

This (rather old) LeCroy app note gives some experimental results.
http://cdn.teledynelecroy.com/files/whitepapers/wp_interpolation_102203.pdf

Thank you jpb it is very useful readings!
Probably someone can try with Rigol DS2000 to experiment with the edge and sine wave test
they described in this document?

Presumably upsampling and then digital filtering would be equivalent to linear interpolation followed by a low pass digital filter.

Well I think this is the way Rigol actually do the interpolation I think. Yes this is a complex thing if you need to do on the whole sampled data real time but note that they probably do this only on the sampled data currently fit on the screen (1400 byte as Marmad noted).
So what they do I think for sinc interpolation is check how many original data points fit in the current screen.
Calculate how much they need to up sample so have enough points on screen - n. Insert n-1 zeros in between each original sample points and then filter with sinc filter (approximation of it )(ideal brick wall fs/2 in frequency domain) and the result is 1400 bytes shown on screen. 
Of course if we have sampled data on the current screen more then 1400 bytes no need to sinc interpolate.     

Regards
Dimitar