An other way to check the resolution, per division,
Put scale to 1 volt/dev, with nothing connected just noise ( picture 1)
Press stop, and set scale to 20 mV (picture 2).
On 1 volt div, with 8 div and 200 levels, one level is 40 mV
On picture 2 you cansee that a sample was indeed 40 mV
Strange anomely, on picture 2 there are spikes above the trigger level,
but when switches to dots, there are no dots above the trigger level ( picture 3)
So it looks like that the DSO is calculating more noise then there is..?
@ Marmad, nice software developed. But i think more explanation is needed.
Strange anomely, on picture 2 there are spikes above the trigger level,
but when switches to dots, there are no dots above the trigger level ( picture 3)
So it looks like that the DSO is calculating more noise then there is..?
It has to do with the sin(x)x interpolation - the theoretical travel of the waveform in order to fit the given sample points. Of course, I think the interpolation begins to get 'fuzzy' at a very low level.
@ Marmad, nice software developed. But i think more explanation is needed.
Well, I hope to have it posted a little later today, so you can play around with it yourself
My first compiled 3D-plot: using the same set of frames showing the voltage-increasing sine wave in the images in my previous post.
Unfortunately, because of bandwidth restrictions on uploads here, I had to reduce the resolution for this post. There is a more detailed version
here. Once it loads. it plays smoothly.
It has to do with the sin(x)x interpolation - the theoretical travel of the waveform in order to fit the given sample points. Of course, I think the interpolation begins to get 'fuzzy' at a very low level.
And the DS2000 series has sin(x)/x interpolation?
Yes, definitely. sin(x)/x interpolation is the "mathematically correct" way to reconstruct a signal, so there isn't really a reasonable alternative. Plus, it's very powerful: If you guarantee that the highest frequency in the input signal is below the nyquist frequency (1 GHz for this scope), then it guarantees that the signal is reconstructed completely with perfect accuracy (minus bandwidth attenuation, of course -- it reconstructs the signal which arrives at the ADC, not what arrives at the input port).
Yes, definitely. sin(x)/x interpolation is the "mathematically correct" way to reconstruct a signal, so there isn't really a reasonable alternative. Plus, it's very powerful: If you guarantee that the highest frequency in the input signal is below the nyquist frequency (1 GHz for this scope), then it guarantees that the signal is reconstructed completely with perfect accuracy (minus bandwidth attenuation, of course -- it reconstructs the signal which arrives at the ADC, not what arrives at the input port).
Well, it
is might be notable that sin(x)/x interpolation is not mentioned anywhere in the documentation for the 2000 series (and perhaps not in that of the entire UltraVision line) - they only mention 'dots' or 'vectors'. As mentioned previously in this thread (and first pointed out by Rf-loop in his original thread), Rigol appears to have not done sin(x)/x correctly in the DS1000 series (even though it's called that in the DS1052E manual) - with the reconstructed waveform failing to sometimes pass through the sample points.
What that means in terms of the 2000 series I don't know - but I can report that as far as we currently know, the reconstructed waveform DOES correctly pass through the sample points as it should.
Weird, I tought I had read it somewhere. But looking for it, I can't find it.
Anyways, I did quite a few tests already and the waveform always passes through the points. Also, my own sin(x)/x implementation creates curves which look very similar to those on the scope.
So I'd say it's all fine.
Here are the same 700 Rigol frames (of the sine wave with a rising voltage) made into a compiled 2D plot (using a 2-color gradient and transparency) - with each frame of the animated GIF equaling 175 plotted Rigol frames - stepping 15 frames forward on each GIF frame.
As mentioned before in this thread, one thing that confuses some people is that the frame (segment) recording is based on a trigger occurring - not on time passing - as with other recording devices (video, sound, etc). This means that unless you have a perfectly regularly recurring trigger, the time between frames will vary. One of the weaknesses in the Rigol firmware is that there is no way to visualize this - playing back frames happens at a fixed rate - unrelated to the actual time tag of the frame.
The new version of RUU solves this problem in a number of different ways. As an example, take a look at a 3D plot (and the animated GIFs in the next post) of a series of frames recorded of a sine wave changing (with a glitch) into a lower frequency square wave. In the first set, the plot (and playback) of the frames happens just like on the Rigol - with an equidistant setting based on frame count:
In the second set, RUU plots the 3D graph (and plays back the recorded frames) with a changing scale set by the frame
time - not count. You can see clearly that the frames are not evenly spaced - and that the sine wave portion (of time) is much smaller than the slower-triggering square wave section:
Here are the same frames again - playing back in RUU - first, with an equidistant time scale based on frame count (like the Rigol):
And here, with a time scale based on the frame time:
Is RUU able to see if trigger was Auto or Normal?
Trigger data is not saved with frames - so no way for RUU to get that info from Rigol.
Like the display interval time, with RUU will traces displayed on frame time bases have a realtime slow motion feature.
"Frame Time" slower, or faster clocking would be nice but still be relative timing,
Slowing the faster ones, and speeding up the slow triggers but still able to see the skipped beats
I'm not 100% sure I understand you, but I think it does what you're asking for. The "@ XXXms" box in RUU sets the playback speed for frame arrays - the fastest possible setting is 15ms - or about 65 FPS. When you use the "Z Scale: Frame Time" setting in the Frame Array Plot/Play Settings Box, RUU will play all frames scaled from the "@ XXXms" setting as the minimum. So if you have "XXXms" set to 15ms - and a 40us frame is the fastest frame time in your frame array, then it will play at 15ms - but a 100us frame will play at 37.5ms (2.5 x 15ms).
Release Date???
Hopefully today - a little later
After reading through this thread and watching Dave's content, I couldn't help myself and ordered a DS2202. I'll let everyone know how it works out when it arrives.
Also, thank you to all whom have contributed to this thread - great read.
Am loving my new DS2072. Customs sat on it for 3 weeks because they had a question, and the courier company claimed they had posted me a letter to tell me! Ha ha - were the ponies busy?
Great scope, great screen, god it is nice to look at. Auto set is easily confused, annoying but not critical.
Been using it for a bit of video signal debugging, found it to be very functional, but slightly fiddly to use some of the menus (the selection wheel sensitivity & acceleration could be better). Compared to my Fluke Scopemeter 196c, I'd say I still prefer to Fluke for some stuff (because it's simpler), but overall I'd go for the Rigol as it has many more features (like holdoff - can't find that in my Fluke!).
Marmad - your software is awesome. I love, and appreciate your efforts. I'm volunteering some of my time if you want some VB coding done, let me know.
Marmad - your software is awesome. I love, and appreciate your efforts. I'm volunteering some of my time if you want some VB coding done, let me know.
Thanks, Chalky... I appreciate it
Perhaps I'll take you up on that offer later - right now my biggest problem is finding time to write documentation, but I think I'll just post the newest version with a bare-bones description and let people ask questions if they need to.
DS2072 Build Quality,
A member PMed me and asked me how well is the Rigol built
Below is a Pic of me standing (on 1leg) on my DS2072
I am 120kg = 260Lbs, note foot size,
Good test! Which standard?
So now Rigol makes an exercise step, in addition to the regular test equipment.
Does the Rigol DS2000 series have an alternate trigger function? It would be useful for stable display of two signals with a bit different frequency... According to the manual, it seems that there is no alternate trigger even in the DS4000 and DS6000 series.
Does the Rigol DS2000 series have an alternate trigger function? It would be useful for stable display of two signals with a bit different frequency... According to the manual, it seems that there is no alternate trigger even in the DS4000 and DS6000 series.
Definitely not in the DS2000. Not sure about the DS4000.
Well, I noticed it somewhere, but I don't know exactly where... If you look to the DS2000, DS4000 or DS6000 manual, you will see that these three manuals are very similar, especially in the trigger section.
Well, I expect that alternate trigger should be in any middle class oscilloscope, am I right?
Well, I expect that alternate trigger should be in any middle class oscilloscope, am I right?
Clearly Rigol looked at the market - and the way many people are using DSOs nowadays - and decided to offer Windows, Pattern, RS232/UART, I²C, and SPI as standard triggers in place of the usual Alternate - with another 7 types available as options. It's up to you to decide if that's what you need or not.
Yes, DS2000 might be good for people who work mainly with digital signals... They will never need the cursors in XY mode, for example.
Read this for the latest documentation - and please leave feedback if you download and try it.