Thanks for the review! It was great to see it in action and a few of the features like the graphing and more complex waveform test that really stand out. The testing of its waveform capture rate was also really interesting, to find its "sweet spot" and see how it scaled so linearly with memory depth. Overall a very useful review.
Jacob
The 2 features I'd miss (unless I hack it) are battery backup and VGA op, which I depend on.
Great review, thanks! ;)
I am still thinking of a Rigol 2000 or higher as a second scope (have the OWON SDS7102), mainly for the wfs/sHave you looked at the 4000 series? They have VGA output on the back.
The 2 features I'd miss (unless I hack it) are battery backup and VGA op, which I depend on.
The 2 features I'd miss (unless I hack it) are battery backup...
Owon SDS7000/8000 series: | <24W |
Hantek DSO5000 series: | <30W |
Rigol DS1000 series: | <50W |
Rigol DS2000 series: | <50W |
Agilent DSOX2000 series: | <100W |
Did you mean double the current price of the DS1052E?no i mean double the price of the ds2202 200MHz scope. i know this color grading, spi serial capable dso, big screen etc is a different game compared to the 1052e. i was wondering what are the differences other than price between 2072 and 2202? is there hardware difference? they are all 2GSps.
no more :KEY:LOCK nonsense.yeah i'll keep working around on that nonsense limit :P but not so frequently. i can see your work more seriously on arbitrary waves. with that nice color grading high wf/s rate, i wonder if it can do some freq domain like plot? like this tektroniks tds2024?
arbitrary waves. with that nice color grading high wf/s rate, i wonder if it can do some freq domain like plot? like this tektroniks tds2024?
no i mean double the price of the ds2202 200MHz scope.Yes, the price does seem to go up rather dramatically. I can think of three possible reasons:
i wonder if it can do some freq domain like plot? like this tektroniks tds2024?I'll try to look into that tomorrow.
He just matched the sweep generator sweep time to the scope full screen sweep time. and used external trigger from the sweep gen to trigger the scope.I'm not sure which part you're talking about: the Measurement part (using a logarithmic sweep) - or - the SCPI part (using a noise signal)?
Have you looked at the 4000 series? They have VGA output on the back.Actually I did, AND they also have a Battery option !! Definitely Interesting. Prices get a bit high at this end.
I use the VGA port on my Tek all the time - I have a 17" LCD on my bench which is much bigger and clearer than the scope's own built-in display.
For me, better than VGA-out would be good software which extracts the waveform data and displays it in a window on a high-res screen. I haven't tried this yet, but the DS2000 seems much faster at transferring data off-scope, so I'm hoping to write efficient software which will do just this.Never had good experience with data ports, for speed. If you get to try it, can you post your findings?
Quotei wonder if it can do some freq domain like plot? like this tektroniks tds2024?I'll try to look into that tomorrow.He just matched the sweep generator sweep time to the scope full screen sweep time. and used external trigger from the sweep gen to trigger the scope.I'm not sure which part you're talking about: the Measurement part (using a logarithmic sweep) - or - the SCPI part (using a noise signal)?
is it the usual "synch out" signal or a pulse at each frequency sweep, gotta figure that one later out my self ;)
but as i said, i doubt 1052e can do the nice color grade like that.
He does mention in the video that they just set persistence to 5 seconds; it looks like you might be able to do it on almost any scope.persistence to 5 seconds? not with 1052e ;) it only none or infinite. we'll get color "flat" not color "grade" i can do it in software though but slow. ok enough for today's lesson thanks, back to topic everybody :P
It's a nice scope but Dave’s last video showed the main problem with the DS2072 and that is no upgrade path for Bandwidth.1) Most scopes don't have upgradeable BW.
I also really dislike all those trial features disappearing just as you get use to them.You would prefer that they didn't give you any free time with the trial options? Even without buying the option package for additional triggers, this scope has 9 built-in triggers compared to 4 on the Agilent 2000X or Owon SDS. Even without paying for the 56M of memory, this scope already has 14M.
What no Zoom at all? Am I missing something here? I can Zoom with my cheap scope I would expect this one to do that easily.In fact, the scope has a very nice zoom - much better then the one on the Owon.
1) Most scopes don't have upgradeable BW.unfortunately DS1052E has. from 50Mhz to 100MHz. so it is a hope the 2000X also has. if rigol want this model to go boom, they should leakout some informations ;)
2) Bandwidth is just one feature in the assortment of features which make a scope useful for someone.bandwidth is the main feature. others are mostly bells and whistles that follow. YMMV.
unfortunately DS1052E has. from 50Mhz to 100MHz.Sorry, Mecha - but the DS1052E is no competitor to this scope at all. I've used that scope - and this one is at least 200% better - not just the 60% more that it costs. The closest competition is the Agilent DSO-X 2002a - which costs 25% more but has way smaller memory, way fewer triggers, etc, etc.
bandwidth is the main feature. others are mostly bells and whistles that follow. YMMV.I guess for you - certainly not for me (and others, I'm sure). I do the majority of my work at <=50MHz - and having 'bells and whistles' like 9 triggers, 14MPt, 50k wfrm/s, etc, are going to save me time in design and debugging. But if amount of $ per MHz of BW is your bottom line, then, yes, this scope is not for you.
if rigol want this model to go boom, they should leakout some informationsWell, it is interesting that all three scopes in the DS2000 line are 2GSa/s ;)
It's a nice scope but Dave’s last video showed the main problem with the DS2072 and that is no upgrade path for Bandwidth. 70MHz is just too low for most people! I have uses on a monthly basis that push my needs up to the 150Mhz region and I suspect that many other eevblogers also have need of BW higher than 70Mhz.
I also really dislike all those trial features disappearing just as you get use to them.
Very nicely done, Mark! Thank you for the review!Thanks, George - and thanks for the info on the DS4000 glitch - I hadn't heard about that!
How is that any different to any other software trial license before?Maybe it's not. But having these features enabled by license keys disturbs the notion that what you're paying for is quality components and construction. That's why so many EEVBlog readers are fascinated by teardown videos--they want to see what's inside.
Just because they pre-install them for you?
Dave.
Imagine if one of the licensed features was a lower noise floor. If I thought the manufacturer used better components in the higher spec model, I might pay up and buy it. But if I knew they were simply adding pseudorandom noise to the unlicensed instruments, then I'd probably stay way entirely.
14kPts | 140kPts | 1.4MPts | 14MPts | 56MPts | |
5ns | 15,000 | 13,150 | 1,412 | 142 | 36 |
10ns | 9,400 | 9,400 | 1,412 | 142 | 36 |
20ns | 50,012 | 13,515 | 1,416 | 142 | 36 |
50ns | 25,003 | 13,515 | 1,416 | 142 | 36 |
100ns | 17,859 | 13,159 | 1,412 | 142 | 36 |
200ns | 11,365 | 11,360 | 1,408 | 142 | 36 |
500ns | 5,434 | 5,435 | 1,336 | 142 | 36 |
1us | 5,263 | 2,890 | 1,126 | 139 | 35 |
2us | 5,054 | 1,506 | 846 | 133 | 35 |
5us | 4,425 | 1,176 | 733 | 130 | 35 |
10us | 3,789 | 1,157 | 720 | 130 | 35 |
20us | 2,945 | 992 | 442 | 117 | 34 |
50us | 1,326 | 639 | 414 | 114 | 34 |
100us | 683 | 421 | 306 | 94 | 32 |
200us | 347 | 245 | 200 | 69 | 28 |
500us | 140 | 109 | 97 | 39 | 21 |
1ms | 70 | 56 | 52 | 29 | 15 |
2ms | 35 | 29 | 27 | 19 | 10 |
5ms | ~14 | ~13 | ~11 | ~9 | ~6 |
10ms | ~7 | ~6 | ~6 | ~5 | ~3 |
20ms | ~4 | ~4 | ~3 | ~3 | ~2 |
50ms | ~2 | ~1 | ~1 | ~1 | ~1 |
100ms | ~1 | ~1 | ~1 | ~1 | ~1 |
Also: I can confirm a good 'bug' in the current firmware - it seems the trial options have come back from the dead on my scope - counting down again from the initial trial minutes. Whether this is behavior which will continue indefinitely is - as you might imagine - intensely interesting. :)
I also got them back, but next day they ware gone and the list was totally empty.
Here are the results of a quick test I did measuring the Rigol DS2072 waveform update rates at all timebase settings and memory depths (also attached in Excel format)How did you measure this, or was is displayed on the screen?
How did you measure this, or was is displayed on the screen?Single channel - 1MHz square wave to Channel 1 - Trigger Out to frequency counter. And I'll add this to the above post.
Interesting. You mean they just jumped from some higher number (e.g. 1800) to zero all of a sudden?
No, the option list was totally empty. There was also no option list when starting the scope.
No, the option list was totally empty. There was also no option list when starting the scope.
And how did you resolve it? Firmware update?
With money! I have bought the options.
With money! I have bought the options.
Yes, you mentioned that before - but that doesn't change the fact that there was a bug in the firmware which was making the scope options act strangely. I'm not sure I would pay for options until I knew that they would operate correctly continuously.
Edit: Or is that the default behavior when the trial options are gone?
Where can I get a new firmware, which is tested works ok? I don't want this which Dave installed.I don't think there is any official new version yet. I have the same as yours - with two bugs that I know of: the XY reversal - and the cancelling of trial options during self-calibration. You can get a second free trial license from Rigol if you lose the first through self-cal - but I doubt they'll give you a third, then fourth, etc, etc :)
I have not found any problems with these official options until now.Have you tried running a self-calibration since installing the official options?
Have you tried running a self-calibration since installing the official options?
Also: I can confirm a good 'bug' in the current firmware - it seems the trial options have come back from the dead on my scope - counting down again from the initial trial minutes. Whether this is behavior which will continue indefinitely is - as you might imagine - intensely interesting. :)
No, but it is not a big problem. The options can be reinstalled, if they are lost.
Single channel - 1MHz square wave to Channel 1 - Trigger Out to frequency counter. I took best-case rate when it was fluctuating:
The 1Mhz square wave, is that from the test signal of the scope itself or an external signal from an AWG?
But I won't try anything until the options are expired again, ;)
If you have time could you add the sample rate in your excel file.How did you measure this, or was is displayed on the screen?Single channel - 1MHz square wave to Channel 1 - Trigger Out to frequency counter. And I'll add this to the above post.
Thanks for your awesome video review marmad! You have provided a very nice introduction to several features and analysis capabilities of this scope. It's surprising there is not really that much out there on the Rigol DS2000 series.You're welcome, Sparky - and I hope to add more to the knowledge base as I learn more about the scope. But I think it's only been available since June - so it's not too surprising there isn't much yet.
If I'm not mistaken, Rigol hasn't publicly distributed any official firmware upgrades for the DS2000 series yet. I hope firmware updates from Rigol become transparent --- e.g. listed on a website for easy download, with clear indication of bugs fixed, features added, etc.As far as I know, there are no updates yet, but the current firmware is very stable (Dave unfortunately got a slightly buggy not-for-general-release version) - with only the 2 bugs mentioned before that I know about. But, as much as I love this scope - and admire Rigol's ingenuity and professional products - the downside of owning a Chinese scope is slow (and sometimes bad) communication and secrecy. Some Chinese companies are better than others - but they all seem to suffer from it to some degree.
Where can I get a new firmware, which is tested works ok? I don't want this which Dave installed.
Here is a test of the first in a group of utilities I'm writing for the Rigol DS2000: software which grabs the recorded frames to the PC for compilation into videos. This is a small first test - only 126 frames - but I'll try to upload a larger one tomorrow.
<snip>
Edit: And I'll start posting the software as soon as it gets a bit closer to release-ready.
Edit: And I'll start posting the software as soon as it gets a bit closer to release-ready.
Marmad or EV, have you guys tried the i2c serial decode features? How good is that software on this dso for that?
I used the I2C decode in the video review - it worked just as expected.Marmad or EV, have you guys tried the i2c serial decode features? How good is that software on this dso for that?
I have used only Rs-232 encoder and it works well.
What programming language and dev. environment are you using for your software development? What is the communications protocol to talk with the DS2000? Very exciting!I'm using Visual Studio and the National Instruments VISA DLLs - talking to the device with SCPI.
Do it still counts down or is it a bogus number for the remaining time of the options?Yes, counting down.
It's a 15MB movie, so it can take a few moments (depending on your connection speed) to start playing:
http://turbidmedia.com/ds2000.html (http://turbidmedia.com/ds2000.html)
Great review, justing adding my kudos.Thanks, saturation. I appreciate it.
What programming language and dev. environment are you using for your software development? What is the communications protocol to talk with the DS2000? Very exciting!I'm using Visual Studio and the National Instruments VISA DLLs - talking to the device with SCPI.
Since this thread is the latest and currently most active on the DS2000 series, it might make sense to keep general discussion here (least we end up with 20 threads!)
just ordered 2072 largely based on the reviews here. The 200 MHz sleeping beast inside looks promising.
I went with tequipment - they were on a generator yesterday and today finally got the commercial power restored... with another noreaster brewing off the coast. Not sure when I will actually get mine. But I figured they really need orders; probably lost so much because of Sandy. Make sure you request a quote from them before ordering via the web site.Thanks for the info on that - glad to hear they have power back. Any particular reason you suggest requesting a quote? Is that just good practice or are they maybe backlogged and that would be a chance to let a buyer know? It's possible I'll want to order one myself from somewhere at some point soon-ish.
Hi guys
just ordered 2072 largely based on the reviews here. The 200 MHz sleeping beast inside looks promising.
I went with tequipment - they were on a generator yesterday and today finally got the commercial power restored... with another noreaster brewing off the coast. Not sure when I will actually get mine. But I figured they really need orders; probably lost so much because of Sandy. Make sure you request a quote from them before ordering via the web site.
Since this thread is the latest and currently most active on the DS2000 series, it might make sense to keep general discussion here (least we end up with 20 threads!)Not to be a wet blanket or anything, but in fact, the whole point of threads stems from the name: that they should be specific. Of course, everybody here (including myself) breaks this rule regularly. But the result of this, unfortunately, is often threads that are 50-100 pages long, filled with reviews, hacks, product information, technical support, etc, etc, and are an absolute bitch to wade through for just one piece of information.
Any particular reason you suggest requesting a quote? Is that just good practice
Since this thread is the latest and currently most active on the DS2000 series, it might make sense to keep general discussion here (least we end up with 20 threads!)Not to be a wet blanket or anything, but in fact, the whole point of threads stems from the name: that they should be specific. Of course, everybody here (including myself) breaks this rule regularly. But the result of this, unfortunately, is often threads that are 50-100 pages long, filled with reviews, hacks, product information, technical support, etc, etc, and are an absolute bitch to wade through for just one piece of information.
<snip>
This is also my experience. I actually called and made a change to my order and they still applied a 5% discount.Any particular reason you suggest requesting a quote? Is that just good practiceYes they will verify stock and send a formal quote. also got a small discount from the web price and I didn't even ask for it :)
This is also my experience. I actually called and made a change to my order and they still applied a 5% discount.Any particular reason you suggest requesting a quote? Is that just good practiceYes they will verify stock and send a formal quote. also got a small discount from the web price and I didn't even ask for it :)
Any particular reason you suggest requesting a quote? Is that just good practice
Yes they will verify stock and send a formal quote. also got a small discount from the web price and I didn't even ask for it :)
I may call them to see if I could get that to my order but I'm already charged for the unit. Did they say why they gave you the discount eventhough you did not asked for it?
Wow that is terrific. How much of a discount did you get? Now, I may call them to see if I could get that to my order but I'm already charged for the unit. Did they say why they gave you the discount eventhough you did not asked for it? Was this purchase at tequipment?
- here is a current list of known firmware annoyances/problems/bugs (leaving out unimplemented features - or physical design issues):
Good list, I have not found anything to add to it, but when pressing AUTO button the scope does not find signals for both channels.
Real time 9.995 seconds gives exactly 10 seconds on the horisontal scale.
QuoteReal time 9.995 seconds gives exactly 10 seconds on the horisontal scale.
I'm not sure what you mean by this - can you be more specific?
Sorry about my bad language. Look at the pictures:
Are you sure your sweep time is accurate?
Then I checked this accuracy with 0.1 mHz pulse and there is no error on the time scale. So the problem is not cause of the oscilloscope.
Just out of curiosity, what persistency setting do you have the scope on for normal use?
This might have came up before but I did notice the waveforms blinks in and out of the screen when moving it either in the horizontal or vertical position. I vaguely remembered someone mentioned this issue before.
I found selecting an option with the push in multi-function knob kind of iffy as it can slip and you will end up with the previous or next setting. I found a workaround which requires only to select the option you want with the mult-function knob and if you are set with that option, just press the menu button rather than push the knob in. This guarantees your selection sticks and I'm using it constantly rather than the push in feature for selecting.
I use the standard Min setting - which gives you the normal analog scope feel; I would only use something higher if I was looking for anomalies.
Are the options still functioning on your dso? Is the count down still happening?
Nope, my trial options are currently expired - although I did get a mysterious full extra 35 hours after the initial period was expired (it reset itself). Also, I still have a spare trial license code from Rigol (courtesy of my distributor) to use - but I will save it until I really need it.
Can the firmware be backed up just in case some mysterious power outage takes out the scope for no apparent reason????
That was just an inquiry, my dso is still perfectly fine. Just curious as to if it is even possible to back up the firmware as a safety precaution. Just wondering.... ;D
Since firmware does not fail because of power outages (unless, perhaps, one happens at the exact moment you're upgrading the firmware) - and since many manufacturers generally don't want people fiddling with their firmware - and since one of the reasons manufacturers supply warranties is as a safety precaution against device failure - I'd guess that, no, there is no method (or at least no publicly available method) to copy the firmware from the DSO to a PC.
I noticed on channel 2 of my dso I'm getting 10mV of ripple noise as opposed to channel 1 which is about half that. Is this normal or maybe there is grounding issue for channel 2? This is done with the respected channel in question and nothing hooked up to the probe.
A probe can act like an antenna. To check actual noise levels of the DSO, unhook the probes. Also, posting a screen cap here (try to use .png format to save Dave's BW) would help in identifying problems.
Attached are pngs of noise levels of my scope at the 500uV vertical setting:
No BW limit: ~640 uVpp average
20M BW limit: ~176 uVpp average
It looks that the noise value depends on the horisontal scale value possition.
It looks that the noise value depends on the horisontal scale value possition.
It's not the noise level - it's the measurements themselves. Most lower cost scopes (including the Agilent X series) take measurements from the displayed data - not the full-resolution captured data. Like analog scopes, measurement is most accurate when the waveform fills the screen without overshoot, and you have at least 3-4 cycles on screen. If you play with the vertical or horizontal scale while keeping auto measurement on, you can watch the measurements change dynamically, starting with the LSD of the values.
I got so excited when receiving and playing around with the scope to check its labeled spec that I've did a self cal and lost the trial options.... :-[. I'm mad at myself as I really wanted to try out the i2c decoding on a small project. I'm kind of bummed for doing that... |O
Taking overshoot into account, the measurement reported from the dso is the average of the all the captured display data? How does it do the calculation for the reported Vpp, does it take a fixed sample size from the displayed data and average that?
DS2000 has a bootloader (unlike DS1000E), so in case of e.g. power failure during firmware update, the unit may not start again, but you are still able to re-initiate FW update by pressing HELP button during boot process (https://www.eevblog.com/forum/blog-specific/eevblog-369-rigol-ds2000-oscilloscope-playing-around/msg153700/#msg153700).Since firmware does not fail because of power outages (unless, perhaps, one happens at the exact moment you're upgrading the firmware) - and since many manufacturers generally don't want people fiddling with their firmware - and since one of the reasons manufacturers supply warranties is as a safety precaution against device failure - I'd guess that, no, there is no method (or at least no publicly available method) to copy the firmware from the DSO to a PC....Anyhow, the previous inquiry was like you said, what if power went down during a firmware update and your warranty is expired? It would be nice at that point to have something to load back onto the dso.
I'm not sure what you're asking. The measurements are made on the displayed data, which is limited to 700 x 400 points - not the entire sample data.
You can see this effect clearly by setting your sample depth to 14Mpts, then feeding a fixed waveform into the scope and adjusting the vertical and horizontal scales until 2 or 3 cycles fill the screen. Then turn on the Vpp measurement. Then change to the smallest timebase scale (i.e. flattening the waveform) and you will see the Vpp measurement flatten correspondingly. Then STOP the scope and increase the horizontal scale - you will see the entire captured waveform reappear (from stored sample memory) and the Vpp measurements will again increase as the waveform fills the screen.
DS2000 has a bootloader (unlike DS1000E), so in case of e.g. power failure during firmware update, the unit may not start again, but you are still able to initiate another FW update by pressing HELP button during boot process.
In addition to that, importand unit specific data is backed up in another part of memory, so in case they gets corrupted or overwritten, they are restored automatically. I'd say there is enough protection implemented. Anyway, in case anybody get into trouble and need my help, feel free to contact me.
As I already mentioned in another post here, I suggest anybody with FW version 00.00.01.00.02 to upgrade first to 00.00.01.00.05 or later.
... take measurements from the displayed data - not the full-resolution captured data.
...I received mine at the weekend. My first scope, and initially thought - oh dear, I've overbought, should have bought something cheaper/lower end as a starter. But I'm getting much more comfortable with it now.Check that you have the latest firmware version 01.00.05 (using the instructions provided above and in other threads).
The screen is also nice. TBF it's still a far cry from other more general tech. When we're seeing 'retina' displays etc becoming common on sub $500 consumer devices, this is an area where scope manufacturers (one and all) seem to be a few years behind where it's at. But, relative to other scopes at this price, it's pretty good I think, and doesn't have that horrible Owon 'margin' space that chops off a whole load of usable area.You have to realize that every extra pixel displayed horizontally (and to a lesser extent, vertically) is a major challenge for DSO manufacturers - it's always a tradeoff between resolution, waveform update rate, and blind time - that's why the screen resolutions lag behind other digital devices that cost similar amounts of money. This article gives you an introduction to the idea: http://www.eetimes.com/ContentEETimes/Documents/Schweber/C0906/C0906edited.pdf (http://www.eetimes.com/ContentEETimes/Documents/Schweber/C0906/C0906edited.pdf)
I suggest anybody with FW version 00.00.01.00.02 to upgrade first to 00.00.01.00.05 or later.
After many attempts, I think may be the only option is to select OK soft-button option from the GUI...so eventually I did.
The update started, and proceeded to 60%, but now it has stopped there. :(
I'm not sure what to do...I'm quite worried :'(
Any suggestions?
So, software version is updated, and hardware version has decreased! (hardware version was 1.1.0.0 before the update).
So, software version is updated, and hardware version has decreased! (hardware version was 1.1.0.0 before the update).
Perhaps you misread this when you looked the first time? Everyone on the board who has posted their version numbers (and that was mostly people with 01.00.02 firmware) ALL had 1.0.1.0 hardware version.
Also, I'm worried what other system information (calibration, etc.) might have been lost from the failed system update. Does anyone know what are consequences of failed update on system info?
The update started, and proceeded to 60%, but now it has stopped there. :(
It has stopped at 60% for at least 15 mins now.
Also, I'm worried what other system information (calibration, etc.) might have been lost from the failed system update. Does anyone know what are consequences of failed update on system info?
This test might give you some info about the integrity of your calibration data:
Let the scope warm up for +30 minutes.
Run a test signal to the scope and measure the voltage (it can be anything as long as it's a stable voltage).
Then disconnect all probes and run the self-cal.
Then reconnect the test signal and check that your measurements match.
Then repeat one more time:
Disconnect all probes and run the self-cal.
Reconnect the test signal and check that your measurements match.
My simple tests following marmad's instructions seems consistent with factory calibration being okay.
1) Is Rigol responsive in answering requests for firmware updates? Despite others on the forum receiving scopes before me, it seems I have the original firmware: 00.00.01. I was surprised about this, but so be it. Rigol's website does not appear to point to any f/w downloads.
To escape from this "special" mode, do again F7-F6-F7-Utility while in the trigger menu.
My simple tests following marmad's instructions seems consistent with factory calibration being okay.
Very nice sparky, glad your scope is Ok. What a day!
Hi Sparky,
I also spoke with Rigol NA. They also informed me that there engineers are working on a new release but were unsure of when that will occur. They may have not provided you with the firmware because they provided me with it and are now familiar with the fact that loading it through the menus is unsuccessful. I would also agree that they are probably waiting for a newer release.
They did ship me out a new unit overnight (which was great), but I am finding that the new unit does have a more stiff power button which is concerning (almost thought it was sticky and not popping back out). I also noticed that the calibration is a little off Measuring an average DC voltage of 3.43V on the new guy. My Fluke meter says 3.30V and I ended up doing the flash reload during startup and got the old unit up again (with no trails) and its reading 3.39V Source is 3.3V (maybe I am just being picky.
I ma shipping the old unit out first thing in the AM back to Rigol NA. I was impressed that they got me a unit so quickly (with the updated firmware already installed.
That's a good point; Rigol probably wont send out revised firmware if it is likely to cause them headaches if the update is not correctly applied...which can be a little tricky for the newcomer to get right (despite all the warnings/comments advising how to do it properly!)
Today I received an email reply from Chris Armstrong of Rigol confirming that an updated f/w is pending (but with no predicted timeframe for release).
Likewise, there is not a current fix to safely return the option trials which I wiped out when doing the self-cal. I guess it's time to practice some patience!
So, the larger your volts/div, the larger the quantization error. Depending on the setting you used --- and especially if you used different settings on each of your tests --- it might explain the difference in your measurements. This is why, in my second test, I used the smallest volts/div setting possible (500 uV/div) to reduce quantization error; naturally I had to use a similarly small input (2 mV).
I would expect the Fluke to have a way higher resolution DAC, but I haven't researched that.
. They were conceived of more as a way to visualize what was happening in an invisible realm - and not so much for getting precise measurement data - as anyone who's tried to count grid lines on a tiny CRT quickly realized.
I'm very impressed by the boat load of waveform measurements when you push 'Show all'. And an old 465 tek is as well ;)
The bug with updating the firmware is in the OLDER version - i.e. the one that's already installed on most people's scope (01.00.02) - not the newer version. So even if people don't upgrade to version 01.00.05 (or Rigol doesn't send out that version) the problem (of having to update via BOOT instead of the menus) will remain for everyone with 01.00.02 with the next publicly released version they try to install.
I - and at least a few other DS2000 owners on this forum - have gotten replacement trial licenses from Rigol (or their dealers) because ours were expired prematurely by the self-cal bug. You should get this as well - in fact, getting 36 hours (2160 minutes) of free trial licenses is part of the package you paid for - and I would threaten to return the scope if you don't receive it. It's ridiculously easy and virtually cost-free for Rigol to give you this (they just generate a key based on your serial number) - and negligent if they don't replace a feature you paid for but lost due to their error (the bug).
Unfortunately I would assume that they wont be giving the "Trail" code out any longer to try to bypass people trying to abuse the systemI'm not exactly sure how this could help people abuse the system - unless there is a bug in restarting the trial options (which is a possibility). If you mean 'abuse the system' in the sense of trying to crack their options code; in order to create a key generator, you have to get inside the scope's firmware and see exactly what math it's performing on the code in order to reverse engineer it. If you were dead set on trying to do this, you could just buy one of the option packages and use that key.
Marmad did you get your code from Rigol NA? have you expired it yet? If so have you tried the code a second time, and did it work?I got my replacement trial license from my dealer - who requested it from Rigol for me (BTW, it took a little time to finally get it). It seems to me that this is a better approach to getting it - since the dealer has more pull with Rigol than an individual buyer - and of course, you have more pull with your dealer than you would with Rigol - since they are the ones who will have to deal initially with an exchange or a return. I'm in the middle of house renovations, so I've had no time for the scope lately - so I haven't used my replacement license yet (I would want to have as much time as possible with the options). But my dealer tells me that it will reset the options to the 2160 minutes - and will only work once. But maybe there is an as-yet-unreported bug which allows the replacement trial license code to be reused over and over - but I've heard privately from at least one member that it didn't work a second time.
I got my replacement trial license from my dealer - who requested it from Rigol for me (BTW, it took a little time to finally get it). It seems to me that this is a better approach to getting it - since the dealer has more pull with Rigol than an individual buyer - and of course, you have more pull with your dealer than you would with Rigol - since they are the ones who will have to deal initially with an exchange or a return.True, better to ask your dealer, they should be able to apply for a new trial code for you.
... I haven't used my replacement license yet (I would want to have as much time as possible with the options). But my dealer tells me that it will reset the options to the 2160 minutes - and will only work once....Actually it will add 2160 minutes to the current count ;)
But as I, and other members here, have pointed out - there are bugs (aside from the self-cal one) in the firmware (both 01.00.02 and 01.00.05) that appear to effect the appearance and disappearance of the trial options. I'm afraid, unfortunately, that Rigol is putting more energy into trying to squash these in their next official firmware release than into fixing what I consider to be the real problems or adding new features. But we'll see what happens.As for the new firmware, Rigol says:
As for the new firmware, Rigol says:
"R&D still haven't release the new version and we have made effort to promote this progress. I believe it will be released in this month."
At any normal horizontal scale setting >= 20ms (i.e. 20ms/50ms/100ms/200ms/500ms/1s/2s/5s/10s/20s/50s/100s/200s/500s/1ks) the maximum/minimum horizontal trigger position (the orange D number in the upper right corner of the screen which reads 0.00000000ps when zeroed) is +10x/-14x the current
You are right, but at the 20 ms scale position only the right side is limited. In my pictures with the scale value 71.5 ms, it was possble to move the trigger mark to the left or right side.
Yes, this is absolutely a bug and should be corrected in the future firmware. Who tells it to Rigol?
@drieg - Do you know if version 01.00.05 was released for North America (was it only in EU and Australia)? It seems as if most of the NA people here are getting units with 01.00.02 installed - and being told to wait for the next release.I don't think Rigol makes any difference between EU and NA, even here in EU, you still get new units with 01.00.02 installed.
I don't think Rigol makes any difference between EU and NA, even here in EU, you still get new units with 01.00.02 installed.
The "Measure" box does appear to only work with the screen trace data, but the 6-digit frequency "Counter" works directly from the signal (with the trip point defined by the trigger level).
On my scope the "Measure" box can get hung requiring a reboot. If I input a 1 MHz signal and resolve the cycles the "Measure" box gives correct data. If I slow down the time/div, say to see modulation of the RF carrier, the "Measure" box will get confused and quotes, say, freq > something. If I speed up the time/div to see the 1 MHz cycles again the "Measure" box will remain hung with bad data and nothing I tried gets it working again except a power down.
I was unable to get the scope to save screen captures to the USB stick from the "Storage" menu; it just saves a blank screen with no trace.
OK, I caught it, before I was only recording 1 group . this time I recorded 2 groups , frames 1- 450 , and 451-2449, and have space for 8127.
and yes playback plays and loops only in the 1-450 group , but if I move into the second group with the Wavefunder 'big' knob then go to run from pause.It will play to 2449 then jump into the 1-450 group and loop there.
At times the Run/Stop on top was different from the '||>' run/pause button, one would cause the playback right to 8127 before looping back to 1, never tried 3 or more groups.
What is the best use of Run/stop and '||>' buttons???
I certainly don't have this problem on my DS2072 - I've saved many captures to sticks. Have you tried various sizes and makes of sticks?
Would you mind reporting what versions of the firmware/hardware,etc you are running? You can get detailed version info by following these instructions: go to the Trigger menu and set Edge trigger, then press F7-F6-F7-Utility buttons one after another quickly. Then check additional info under Utility > System > System Info. To escape from this "special" mode, do again F7-F6-F7-Utility while inside the Trigger menu.
I tried it on a different USB stick and it worked this time. Then I tried it on the original USB stick and it also worked. Bizarre, as it failed repeatedly before.
Which are the F7 & F6 "Utility" buttons? You mean switch to the Utility menu and hit the Self Cal - System - Self Cal or stay in the "Trigger" Menu and hit the bottom -second from bottom- bottom button in that menu (both blank)? Actually, that second one didn't work. FW just reports 00.00.01.
On my scope the "Measure" box can get hung requiring a reboot. If I input a 1 MHz signal and resolve the cycles the "Measure" box gives correct data. If I slow down the time/div, say to see modulation of the RF carrier, the "Measure" box will get confused and quotes, say, freq > something. If I speed up the time/div to see the 1 MHz cycles again the "Measure" box will remain hung with bad data and nothing I tried gets it working again except a power down.
Anyway the bug which I've reported in the earlier post (and is still unconfirmed by someone else with 01.00.05 firmware) involves playing back repeatedly all frames captured in Record Open mode. It's VERY easy to test this with the software I posted in the other thread - 3 mouse clicks. Could someone please give it a try? When playing back on repeat, keep your eye on Rigol's menu which lists end frame and current frame. If your scope has the bug mine does, you will see the current frame jump to 1 before it reaches the end frame.
Hi marmad, as your RUU software is working via USB for me (though I would still like LAN to work), I just checked this out on my scope (same 01.00.05 firmware).
I can confirm the bug: when on normal play (without repeat) all frames play back (same as when using the navigation knobs on the unit). When I enable "repeat" (or press the Pause|Play button on the unit) the current frame jumps to 1 before it reaches the end. When I press Stop button (either RUU software or on the unit) it jumps to the last frame.
Definitely a bug, and would be great to have this forwarded to our friend drieg for Rigol's attention!
I can confirm the bug: when on normal play (without repeat) all frames play back (same as when using the navigation knobs on the unit). When I enable "repeat" (or press the Pause|Play button on the unit) the current frame jumps to 1 before it reaches the end. When I press Stop button (either RUU software or on the unit) it jumps to the last frame.
Record open, playback in loop mode Interval 500mS , I get Frames 1,2, 6 allways like Marmad
On my scope the "Measure" box can get hung requiring a reboot. If I input a 1 MHz signal and resolve the cycles the "Measure" box gives correct data. If I slow down the time/div, say to see modulation of the RF carrier, the "Measure" box will get confused and quotes, say, freq > something. If I speed up the time/div to see the 1 MHz cycles again the "Measure" box will remain hung with bad data and nothing I tried gets it working again except a power down.
@TP: I was unable to replicate this error on my scope, either using the individual Frequency measurement or the 'Measure All' box. I have to conclude that it's either a firmware version 01.00.02 bug - or that there was an added variable in your setup/scope settings that I don't know about that provoked the bug.
OK, I caught it, before I was only recording 1 group . this time I recorded 2 groups , frames 1- 450 , and 451-2449, and have space for 8127.
and yes playback plays and loops only in the 1-450 group , but if I move into the second group with the Wavefunder 'big' knob then go to run from pause.It will play to 2449 then jump into the 1-450 group and loop there.
Well, I can't replicate it now either. That first day the scope was definitely acting weird.. maybe first day jitters :). Anyway, it works perfectly now.
A simple test to check for the 'looping' bug on the DS2000 - <cut>
. I've just ordered a DS2022 thanks to this information. ...
. I've just ordered a DS2022 thanks to this information. ...Maybe you mean DS2202?
I have a question about RMS voltage measurement. I'm checking out my brand new DS2072, which I chose based on all of the good info on the forum. Either I'm doing something wrong or the RMS measurement function doesn't work very well. Here's the setup: Channel 1 connected to the scope's calibration square wave, probe on x10, vertical 100 mV/division, horizontal 100 uSec/division, DC coupling. V min reads -4.0 mV and V max is 308 mV. These are ok. V rms reads 211 mV, which is bogus. I think it should be 156 mV. Am I maybe doing something incorrectly? With AC coupling the RMS value is closer but still quite a bit off. I just got the scope from Tequipment, software version is 00.00.01.00.02 .As far as I can tell, it's reasonably accurate (which is about the best you can say about most measurements on an oscilloscope): The calibration signal is a 3V 1kHz positive square wave with a 500us duration = 2.121Vrms.
As far as I can tell, it's reasonably accurate (which is about the best you can say about most measurements on an oscilloscope): The calibration signal is a 3V 1kHz positive square wave with a 500us duration = 2.121Vrms.Thanks. I feel like I'm at an AA meeting having to say "I'm an electrical engineer and I don't know how RMS works". It has always seemed intuitive to me that a square wave with its minimum voltage at zero has the same RMS value as a square wave symmetric about zero. Now I see that the math says otherwise, and I even found a couple of web sites that incorrectly agreed with me. I think it has to do with the DC component, it's just hard to suddenly break with decades of wrong thinking. So it's correct that the RMS value of the calibration signal is different with AC coupling vs. DC coupling. The scope's calculation isn't stellar accuracy, but close enough for my purposes.
Thanks. I feel like I'm at an AA meeting having to say "I'm an electrical engineer and I don't know how RMS works". It has always seemed intuitive to me that a square wave with its minimum voltage at zero has the same RMS value as a square wave symmetric about zero. Now I see that the math says otherwise, and I even found a couple of web sites that incorrectly agreed with me. I think it has to do with the DC component, it's just hard to suddenly break with decades of wrong thinking. So it's correct that the RMS value of the calibration signal is different with AC coupling vs. DC coupling. The scope's calculation isn't stellar accuracy, but close enough for my purposes.
I put an Marconi signal generator(2019a) on my ds 2072, ( 70 mhz to the book ) and these were the results,
112 mhz -3 db at 100 milliVolts, the rms on the scoop 70 mV
175 mhz -6 db
232 mhz -9 db
292 mhz -12 db
349 mhz -15 db still triggering and rms still working.
403 mhz -18db
437 mhz -20 db still good trigger and stable
497 mhz game over
Anyone who can verify ??
The scope's calculation isn't stellar accuracy, but close enough for my purposes.
...and between the 2202 is the 2 nsec timebase.
...and between the 2202 is the 2 nsec timebase.
And the 100MHz BW limit setting - which you would think would be set "ON" all the time on the 2072/2102.
...and between the 2202 is the 2 nsec timebase.
And the 100MHz BW limit setting - which you would think would be set "ON" all the time on the 2072/2102.
don't give rigol any ideas ;)
I do know FFT function on 2072 works way way beyond 70 Mhz (posted a picture somewhere above)
I do know FFT function on 2072 works way way beyond 70 Mhz (posted a picture somewhere above)
The FFT is just calculated from the samples, and goes uo to 3.5 Ghz. Depends on the selected timebase.
And Rigol knows what it is shipping, if you are selling test equipment, you can count on it that they will
check the specs..search for the limits.
These hacks or rumours of such on Rigol must have a fantastic marketing effect. Surely they sell more scopes this way, and get a lot of PR. I bought a DS2022, because so many people in this forum said the brand was good. I would guess it would have been less well known without the earlier 50 to 100 mhz hacks on the older scope.It's not just because people say so - look at Dave's video (https://www.eevblog.com/forum/blog/eevblog-360-rigol-ds2000-oscilloscope-teardown/) tearing down one of the DS2000s. Beautifully made inside - and it's the same with their latest series of AWGs and SAs.
It's not just because people say so - look at Dave's video (https://www.eevblog.com/forum/blog/eevblog-360-rigol-ds2000-oscilloscope-teardown/) tearing down one of the DS2000s. Beautifully made inside - and it's the same with their latest series of AWGs and SAs.
I do know FFT function on 2072 works way way beyond 70 Mhz (posted a picture somewhere above)
The FFT is just calculated from the samples, and goes uo to 3.5 Ghz. Depends on the selected timebase.
And Rigol knows what it is shipping, if you are selling test equipment, you can count on it that they will
check the specs..search for the limits.
I do think that the FFT is perhaps the one area that's a little feeble on the DS2000 series. It doesn't matter to me all that much - since it's relatively feeble on most low cost DSOs - and there are so many other great features (50k wfrm/s capture, segmented memory with histogram analysis, 500uV scale, hi-res mode, measurement history graphs, 2GSa/s sampling, etc) to offset that :)
I have a question about 8 vs 12 bit. I bought ds2022 thinking it was 12 bit, because many sites say this. Now, I am confused. Is it only 8 bit, but has some sort of averaging that supposedly makes it more accurate by considering many 8 bit samples?Yes, it's 8-bit - and HiRes mode is averaging - but a different kind than the standard type used on all DSOs as an Acquire type. There's a good explanation of it in this post (https://www.eevblog.com/forum/reviews/rigol-ds2072-review/msg138785/#msg138785) (and throughout that thread).
I have a question about 8 vs 12 bit. I bought ds2022 thinking it was 12 bit, because many sites say this. Now, I am confused. Is it only 8 bit, but has some sort of averaging that supposedly makes it more accurate by considering many 8 bit samples?
I have a question about 8 vs 12 bit. I bought ds2022 thinking it was 12 bit, because many sites say this. Now, I am confused. Is it only 8 bit, but has some sort of averaging that supposedly makes it more accurate by considering many 8 bit samples?
I think there are some DSP tricks (i.e. I don't understand the math ;) ) during down sampling that can increase the effective bit depth of the ADC. the sampling rate has to be set to lower than 2 GSa/s in order to get the extra bits of resolution.
note, The probes which come with the scoop are useless above 30 Mhz.
I'm curious if they're rated 1x/35MHz - 10x/350MHz (or something like that)
Bandwidths are 1X/8MHz and 10X/350MHz. Rise times are 1X/40ns and 10X/900ps.
Bandwidths are 1X/8MHz and 10X/350MHz. Rise times are 1X/40ns and 10X/900ps.
@EV: are these the written specifications - or tested by you?
They are from specs. I made some tests with Rigol DG4162 generator:
Sweep is from 1Hz to 160 MHz (there is no bigger value) with sweep time 1.4 sec.
Sw ver: 00.00.01.00.02
@ EV,
Clearly some SWR on the Rigol. not completly 50 ohm
as on the Tek
I bought some Tektronix 011-0049-01 feed Thru 50 Ohm Terminators from eBay. When I get them, I test again this sweep with DS2202.
Edit: Rigol seem to have also these feed thru 50 ohm terminators.
Hallo,
Made two pictures, of FFT screen dump, with 300 Mhz on a Rigol 2072 ( 70 Mhz)
The first picture, with High resolution on, and the second on normal...
se the difference, two peaks suddenly disappears...
Hallo,
Made two pictures, of FFT screen dump, with 300 Mhz on a Rigol 2072 ( 70 Mhz)
The first picture, with High resolution on, and the second on normal...
se the difference, two peaks suddenly disappears...
2 peaks more in normal mode? Also RMS is much bigger there. I am not familiar with FFT.
In high resolution , one should expect more detail then in normal....
In high resolution , one should expect more detail then in normal....
Yes I thought so also. Does that bigger RMS in normal mode mean something?
You can clearly see the signals from 88 -108 Mhz in the air.
Sw ver: 00.00.01.00.02I suggest an upgrade to 01.00.05 - but upgrade during bootup - NOT FROM GUI (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg167752/#msg167752) or you will lose the trial options. Also, don't forget: NO SELF-CALIBRATION for the moment - or you will also lose the trial options.
Edit: I managed to get the secret handshake now. Stupidly didn't realize I should go to system info afterwards. Thought it'd be a popup, but then I reread the forum, which I should have done anyway. So, it's not confirmed upgraded to 00.00.01.00.05.
Is it Valid to test at 160MHz Freg. when the DS2000 Scope is set at 100mS/div and ONLY 20Msa/s ??
Are you just showing aliasing?
Why it is not valid? What is aliasing (it is not in my dictionary)?
Why it is not valid? What is aliasing (it is not in my dictionary)?
Turn sampling (acquire) mode to "peak" (it is used in this Owon test)
But if you do this 4 button sequence, F7-F6-F7-Utility, under the trigger menu,
you get also the service menu, where you can do screen test, keyboard test,
and gaintest, and some other things i dont dare to touch.
Is there anybody , who already did some experience with this menu..??
Here is a new picture "peak detect" turned on.
I've had a couple of people PM me asking for a copy of the 01.00.05 firmware - but my DS2072 came with it installed, so I don't have one. Would someone who does be willing to post it - either here or in the software thread (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/)?Someone has posted it in the software thread.
I don't know about this error, but sometimes when I have stored pictures (as bmp and maybe others), in stored picture has not been any waveform only pure graticule and frames. When stored second time also waveform is there.
This is something different - as noted below. But perhaps you can test this on your DSO?
Further research on this bug:
I tried again with a sine wave - and this time it worked correctly. So I compared the 'good' and 'bad' sine wave WFM files, and they are identical. This means two things:
This bug/problem is intermittent - which is the worst kind of bug/problem.
This bug/problem is in the loading of the DSO memory - not the saving.
So far, with testing, it failed to correctly load a stored 14MPt waveform into memory [4 of 5 times]. (Edited - and growing).
Help question,It might help if you read the previous messages in the thread you're posting in ;) Seriously though, I pointed this out before in this post (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg160404/#msg160404) - and IMO it's the biggest failure (I don't mean bugs) of the current firmware: it would be a much more powerful feature if you could save and reload frames for comparison later - since you can do everything to saved frames (measurement, bus decode, zoom, math, etc) that you can do to single waveforms. Rigol have been notified that there are owners who would like this capability.
when i do a record, with the record button, i can play around
with the info, but if i want to save it to a file as wfm, it blanks
out. It only allow me to make a new directory..?
i press storage, select waveforms, and then press save,
in the next menu, i get only new folder and delete.?
I can only save waveforms in realtime mode, when i then
press storage, and do the same then i can save it to the usb stick
what do i wrong.?
Now I got it. It was also at the end of 1.4Mpts file, but I did not take picture from it.Thanks for confirming that EV! I was starting to worry I might be having memory problems with my DSO. I will pass it along to drieg.
@ Marmad, thanks for your info.., sorry, but i read everything on these posts...
but what happens, you read all kinds of things, but i had not tried all these items
so the most items you read here does not always mean anything to the reader...unitl..
you are a a point were you try things you did not had any clue before...
So i did not study all the software yet, i am not so far yet. I am using here a GPIB bus fot the HP stuff with a Prologix convertor to the PC. So i have to find a way to get the Rigol under control.
I did a search on the Firmware 1.005.., find that is has a header for a 2202
and was written for two fans inside, with temperature control ..
The firmware is not encrypted. You can upgrade with former version, or the same.
so you have not to enter option keys by hand..., thats gives a try for a brute force..
There are 28 items in the key, and 32 letters/numbers that gives... too many
I put an Marconi signal generator(2019a) on my ds 2072, ( 70 mhz to the book ) and these were the results,
112 mhz -3 db at 100 milliVolts, the rms on the scoop 70 mV
175 mhz -6 db
232 mhz -9 db
292 mhz -12 db
349 mhz -15 db still triggering and rms still working.
403 mhz -18db
437 mhz -20 db still good trigger and stable
497 mhz game over
RIGOL 2000 Service Menu
I did not found any info on this yes on the forum, maybe somewhere else..?
But if you do this 4 button sequence, F7-F6-F7-Utility, under the trigger menu,
you get also the service menu, where you can do screen test, keyboard test,
and gaintest, and some other things i dont dare to touch.
Is there anybody , who already did some experience with this menu..??
Well, I've found either another bug with the scope - or it's related to the previous bug of not being able to read deep sample lengths from scope.
Could someone else please try this and see what results you get?
< snip >
Then save the file to WFM format on a USB stick. Then make sure you clear the memory (capture a different type of waveform or AUTO no input), then load the saved WFM file back into memory. Again Zoom in and go to the end of the waveform and save the image:
Well, I've found either another bug with the scope - or it's related to the previous bug of not being able to read deep sample lengths from scope.
Could someone else please try this and see what results you get?
< snip >
Then save the file to WFM format on a USB stick. Then make sure you clear the memory (capture a different type of waveform or AUTO no input), then load the saved WFM file back into memory. Again Zoom in and go to the end of the waveform and save the image:
I tried to confirm this also, but I am unable to save Waveforms or CSV from the scope. Specifically what happens is that when I set "Storage" to "Waveforms" or "CSV" and then select "Save" button, the "New File" option is grayed out (unselectable). If I go back and set "Storage" to any other option (Traces, Setups, or Picture), I am able to select "New File" and saving proceeds.
Is there something I'm missing about not being able to save Waveforms or CSV?
I excited from dual time-base mode and that didn't help. I then pressed "Stop Record" button to exit Record mode (it is already STOPped...but square STOP button is RED color), and then the "New File" menu button becomes active when "Waveforms" is selected for the "Storage" option...however after exiting Record mode, the waveform is lost :(
So, I'm not sure the correct procedure to save the current waveform in memory to the USB drive.
Any pointers what I am doing wrong?
This thread has grown a lot in the last couple of days --- difficult keeping up!
Well, I've found either another bug with the scope - or it's related to the previous bug of not being able to read deep sample lengths from scope.
Could someone else please try this and see what results you get?
That was the main reason I started writing my software = so that you could save all of the data from the frames (but, of course, I can't force the Rigol to reload it). As of now, my software can save frames as images, animated GIFs, CSVs (and WFM is coming soon) - but because of another serious bug I posted about a couple of days ago (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg174895/#msg174895) (which no one else has yet confirmed), you can only read display memory from the scope - not the entire sample length - so the CSV and WFM files are currently limited to 1.4kPts each.
I noticed that the "Anti-Aliasing" does not work if I close the scope and turn on the power again even if "Anti-Aliasing" is on. If I put it off and on again, it works again.
Marmad or EV, have you guys tried the i2c serial decode features? How good is that software on this dso for that?
Does anyone have (or has anyone seen) any copy of the RIGOL Programming Guide - DS2000 Series Digital Oscilloscope besides ...
It's a little odd that the only copy I can find online (I see no copy at any of the Rigol websites) is clearly written for FW 01.00.02 (evidenced by the outdated "Keep" command - instead of "Open" - for Record Open).
Then all we need to do is hear from Rigol what the new method is.
Waiting.... ::)
I could not find the DS2000 Series Programming Guide on the Rigol NA website, however it is currently available on the Rigol website (http://www.rigol.com/prodserv/DS2000/document/?act=view&itemid=547 (http://www.rigol.com/prodserv/DS2000/document/?act=view&itemid=547)).
But not sure of this.., can anyone who has not filled in a new trail option key from Rigol,
confirm that he has also restored the trail options..?, before or after it expired.
Looking inside the firmware-file, you can see the web responses in clear-text. Would be cool to change some of the text. I wonder if the file is signed to prevent going in and changing characters... it can't be that easy I guess :)
I have software version 1.005, seems that all 2072 have .5 and the 2202 have .2
if a read back the posts
In ASCII mode, if its not a bug it looks like it:
ASCII-ANSI Standard, it comprise characters and controls,
it only decodes characters.
In the attached examples, my old Yokogawa decodes:
decode-1: (CR),(LF)
decode-2: (ENQ),F,F,9,1,(CR)
me and older technicians prefer this mode not "*"
And cant get 2 Gsa/s on channel 1 with external trigger,
only on channel 2. Is this normal, or do i somthing wrong.?
Also, if you bootup with CH1 and EXT trigger selected - you get 2G Sa/s.DS2072 FW 1.00.02
BTW, Wim, what FW version are you using? I'd like to find one more person with FW 01.00.02 to verify that the memory reading bug is not present in that version.I can confirm, FW 01.00.02 has also problems reloading saved WFM files.
EDIT: Also, I'd like to discover if the WFM-loading corruption bug (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg175767/#msg175767) is also present in FW 01.00.02.
I have this bug on Loading of WFM files EXCEPT on loading a 54MPts See att
DS2000 series owners check your heat sink clips!
In the drawings, the probes that come with the scope have two adjustment screws, for LF / HF or so, one on the plug and one on the probe itself. Mine only have a screw on the plug and the hole on the probe is filled with plastic stuff (but the hole can be seen clearly). Is that normal?
Push the tip harder. It will click to its place.
Also about the probes, the hooktip accessoires don't stick to the probes well, they very easily slip off a bit and then you're confused why you don't measure anything. Am I just too stupid to mount them (you just need to push them over the probe front, right?) or is this really a problem?
About the trigger, can I somehow trigger Ch1 and Ch2 seperately? Isn't that a sort of common feature? My old 1970 scope could do that, anyways ;)
It's not a big problem because the memory depth is so huge, but it would still be nice in some situations.
Then, why did Rigol decide not to have a 50 Ohm input on the scope? I found that many of the scopes on the market don't have it. Is it because it's a bit easy to destroy with high-power input?
Anyways, if I plug a BNC T piece directly into the scope input, and terminate one end with a 50 ohm load, and plug my 50 ohm signal into the other, that will basically be a 50 ohm input with still accurate voltage measurements; correct?
There is a plug on the hole. You can take it off.Ah, okay. I tought so at first, but when it wasn't reasonably easy to remove, I just gave up on that.
Haha, yeah, it really does -- stupid me. Thanks.Also about the probes, the hooktip accessoires don't stick to the probes well, they very easily slip off a bit and then you're confused why you don't measure anything. Am I just too stupid to mount them (you just need to push them over the probe front, right?) or is this really a problem?Push the tip harder. It will click to its place.
Ok, then I guess it's just not there.About the trigger, can I somehow trigger Ch1 and Ch2 seperately? Isn't that a sort of common feature? My old 1970 scope could do that, anyways ;)I have not found alt trigger either.
It's not a big problem because the memory depth is so huge, but it would still be nice in some situations.
I'll probably buy one then, they're not very expensive.Then, why did Rigol decide not to have a 50 Ohm input on the scope? I found that many of the scopes on the market don't have it. Is it because it's a bit easy to destroy with high-power input?Yes, 50 ohm feed through adapter should be better.
Anyways, if I plug a BNC T piece directly into the scope input, and terminate one end with a 50 ohm load, and plug my 50 ohm signal into the other, that will basically be a 50 ohm input with still accurate voltage measurements; correct?
About the trigger, can I somehow trigger Ch1 and Ch2 seperately? Isn't that a sort of common feature? My old 1970 scope could do that, anyways ;)
It's not a big problem because the memory depth is so huge, but it would still be nice in some situations.
From the above, I would conclude that dead times only happen after trigger events. So, if there's a one-time event you set the edge trigger up for, and if (sic) you set the trigger to Normal mode (not Auto), you'll capture it for sure. Is that correct?
Oh also, the DS2202 seems to display more than one captured waveform per screen update, even with Min persistence time set. "Min" apparently means "all waveforms captured since the last screen refresh"... which is just fine. It implies, however, that pressing STOP while the scope is in T'D or AUTO state will not have the same result as pressing SINGLE, then FORCE (or waiting for a trigger event), since the former might display more than one waveform on the screen.
Hi!
Since recently I also own a DS2000 series scope (the 200MHz version) and I have some questions and comments too.
Then, some things that confuse me.
In the drawings, the probes that come with the scope have two adjustment screws, for LF / HF or so, one on the plug and one on the probe itself. Mine only have a screw on the plug and the hole on the probe is filled with plastic stuff (but the hole can be seen clearly). Is that normal?
Also about the probes, the hooktip accessoires don't stick to the probes well, they very easily slip off a bit and then you're confused why you don't measure anything. Am I just too stupid to mount them (you just need to push them over the probe front, right?) or is this really a problem?
About the trigger, can I somehow trigger Ch1 and Ch2 seperately? Isn't that a sort of common feature? My old 1970 scope could do that, anyways ;)
It's not a big problem because the memory depth is so huge, but it would still be nice in some situations.
Then, why did Rigol decide not to have a 50 Ohm input on the scope? I found that many of the scopes on the market don't have it. Is it because it's a bit easy to destroy with high-power input?
Anyways, if I plug a BNC T piece directly into the scope input, and terminate one end with a 50 ohm load, and plug my 50 ohm signal into the other, that will basically be a 50 ohm input with still accurate voltage measurements; correct?
Greetings,
Sven
And the probes are oke for frequencies to 30 Mhz, and for pulse signals. For hihger frequencies you have to
use terminated cables. See also former posts.
That is correct, thats why you have also special probes and active probes. If you want to do lab measurements
then you have to think about all these things. these cable reflections has so many influences.
I have worked for a cerfication calibration company, and before you were allowed to do any measuremts, you had
to follow several courses for several months. Anyone can read a display, but only a few knows what they measure.
Okay, I guess this is to have a consistent amounts of samples available for the user to scroll through before the trigger ... triggers.QuoteFrom the above, I would conclude that dead times only happen after trigger events. So, if there's a one-time event you set the edge trigger up for, and if (sic) you set the trigger to Normal mode (not Auto), you'll capture it for sure. Is that correct?
Yes, in principle, the 'dead time' extends from the trigger moment. But for fast signals, you might have to consider the hold-off as well. The trigger system is not activated until a specified amount of samples are measured after starting the measurement (the trigger hold-off). When the input signal meets the trigger requirements during the trigger hold-off period, this will not generate a trigger and the system will remain sampling pre-samples. After the trigger hold-off has passed, at the first occasion that the trigger conditions are met, the system will start measuring post samples.
Aah, alright, interesting. So they probably just use a screen buffer and draw all captured waveforms into it, and then 30 times per second (or whatever the screen refresh rate is), they swap the buffer to the screen and clear it? That sounds logical. Thanks for explaining!QuoteOh also, the DS2202 seems to display more than one captured waveform per screen update, even with Min persistence time set. "Min" apparently means "all waveforms captured since the last screen refresh"... which is just fine. It implies, however, that pressing STOP while the scope is in T'D or AUTO state will not have the same result as pressing SINGLE, then FORCE (or waiting for a trigger event), since the former might display more than one waveform on the screen.
Yes, but there can actually be only ONE final waveform in the sample memory eventually, so even though you see the contents of the waveform buffer (> 1 waveform) when you STOP the DSO - as soon as you change the horizontal or vertical scale, you see the display 'snap' to the last waveform captured.
And yes about the 50 ohms it is not correct..., the BNC connector has not a high impedance for higher frequencies,Alright, so altough it should in theory be correct it is not because the plug screws things up... which likely won't be the case in a professionally made 50 ohm adaptor. Fine.
so the voltage on the BNC connector is not wath it is. Mine has 1 Mohm and 18 pf input, and also some inductance.
Even if you have a 50 ohm terminator on the input, the BNC connector has a complex impedance, which gives
wrong readings and also standing waves, as you can see on your plot.
Active probe Rigol RP7150 Fits for Rigol Series 4000, 6000 costs 3268 Eur. There is no for DS2000.Given that's more than twice the price of the scope that is not very surprising ;)
Okay, I guess this is to have a consistent amounts of samples available for the user to scroll through before the trigger ... triggers.
Once the system is running, this will basically just add to the dead time tough, won't it? *
Aah, alright, interesting. So they probably just use a screen buffer and draw all captured waveforms into it, and then 30 times per second (or whatever the screen refresh rate is), they swap the buffer to the screen and clear it? That sounds logical. Thanks for explaining!
* That "iff" you corrected to "if" was not a typo, it was borrowed from formal logic
Haha now that's funny. Maybe some software corrected it, somewhere?Quote* That "iff" you corrected to "if" was not a typo, it was borrowed from formal logic
Yes, of course - I knew this - but the weird thing is that I don't remember processing it OR correcting the writing :) I must have done that without even thinking about it.
But then looking back to your original statement as logic:Right. ;)
"So, if there's a one-time event you set the edge trigger up for, and iff (sic) you set the trigger to Normal mode (not Auto), you'll capture it for sure."
is NOT true - because you can also set the trigger to Single mode with the same outcome ;)
This is problematic, because it does not appear always on every saving and loading.Is there a difference if you immediately reload after saving, or if you perform some additional measurements in between? From the descriptions, it sounds like the scope draws whatever is in the sample memory instead of the missing data, and if you just do a save and reload, chances are the original data is still there.
@scummos
BTW, I don't know how much of this exponentially-growing thread you've managed to cover, but in case you missed this post regarding the wfrm/s rate of the scope (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg160064/#msg160064) - it might be of interest to you. It shows that the 20ns timebase scale is the optimal one to use (if possible) when glitch-hunting (i.e. smallest amount of dead time).
Is there a difference if you immediately reload after saving, or if you perform some additional measurements in between? From the descriptions, it sounds like the scope draws whatever is in the sample memory instead of the missing data, and if you just do a save and reload, chances are the original data is still there.
Since you (marmad) are the main contributor to this thread (and several other DS2000 related threads on EEV forums), perhaps you might consider starting a webpage (or wiki) containing the collected wisdom on this subject. Perhaps Dave might help out with space and a reasonably well known domain name.
@scummos
BTW, I don't know how much of this exponentially-growing thread you've managed to cover, but in case you missed this post regarding the wfrm/s rate of the scope (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg160064/#msg160064) - it might be of interest to you. It shows that the 20ns timebase scale is the optimal one to use (if possible) when glitch-hunting (i.e. smallest amount of dead time).
but when push to full scale it drops to 38100 , so the vertical scale has also influence.
BTW, I don't know how much of this exponentially-growing thread you've managed to cover, but in case you missed this post regarding the wfrm/s rate of the scope (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg160064/#msg160064) - it might be of interest to you. It shows that the 20ns timebase scale is the optimal one to use (if possible) when glitch-hunting (i.e. smallest amount of dead time).Yeah, I had seen that post, thanks for pointing it out. (I haven't read all of the thread(s) tough, it's *really* large)
BTW, in the interest of pushing the software I'm writing on more owners ;) it takes the Rigol 15 seconds to write a PNG file to a USB stick - and then, of course, there's the time needed to transfer the stick to a computer and read the file. It takes the Rigol UltraVision Utilities 2.3 seconds (using USB) to transfer the data to the PC and save it :)
BTW, in the interest of pushing the software I'm writing on more owners ;) it takes the Rigol 15 seconds to write a PNG file to a USB stick - and then, of course, there's the time needed to transfer the stick to a computer and read the file. It takes the Rigol UltraVision Utilities 2.3 seconds (using USB) to transfer the data to the PC and save it :)
DS2000 series owners check your heat sink clips!
Thanks for reporting this Martin. Unfortunately there's no easy way to check them without taking off that pesky sticker - aside from shaking the device - which might cause the problem.
I've never been a big fan of this method of spring retention - it's always seemed a little dubious to me. I've had them come off on three different motherboards over the years.
Not tested yet - the parameters of this bug are still unknown - and I haven't had the time to do a thorough investigation. Perhaps you'd like to discover them? ;)Send me a scope and I'd be happy to.
Are using the Lan or the USB interface.., ?
I have only the IVI drivers loaded yet, could not download the Ultra Sigma software, the Rigol site is so slow.
Does your software run without the Rigol Ultra Sigma..?
I just used a flashlight and looked through the vents as shown in one of the pics. You can see all the clips and retainers this way, though it does take some work to get the viewing angle and flashlight angles... I didn't remove my Void sticker. The shaking I did was mostly just rolilng the parts around near the vents. No where near what a real product verification vibration test would do:)
Is that software of yours cross-platform, so it could be ported to another OS by implementing a different backend for device communication? What language is it written in? Did you consider putting it on e.g. github? ;)
Wow... you guys sure hit the thread hard in the last 24h... took me a little to catch up.
Thanks for all the thoughts and info everyone.
So just to confirm... I know on pg 22 or 23 people were talking about scope probes and someone pointed out that there are currently no alternate probes that can be used with the Rigol DS2000 models. This is due to how the probes are powered?
So overall its essentially confirmed that there are currently no Tek, Agilent or other scope probes that are not cross compatible?
The way to determine this is in your serial number for instance:
DS2A143500123
the 14 represents rigols 14th year of operation
and the 35 represents the 35th week in that year.
Maybe this is a batch issue?
Hi, DS2072 FW1.00.02 DSA1421xxxxx
when the stick was inserted/left-in before start-up .
Is this to prevent boot from Stick?
Is this only on 1.00.02?
When loading Waveforms from a USB Stick I have to remove the stick and re-insert after I have selected Storage, Load, when the stick was inserted/left-in before start-up .
Is this only on 1.00.02?
I do give Praise to Marmad, and Recommend Rigol reward him with a Bonus, "Free Upgrade to Options"Thanks for the kind words, Teneyes. I did actually get one free license code for my Rigol - for the extra triggers - but that was more through the kindness and generosity of my dealer, drieg (http://www.silcon.cz/index.php?route=common/home) - than through Rigol. He was offered some compensation from Rigol because of the problems and service needed surrounding the early firmware of the DS4000 - and one thing he got from them was one of the option codes for me - to thank me for making the review and promoting the DS2000 series. Quite unexpected and generous of him. I still highly recommend him as the place to buy a Rigol for Europeans - with the same price / free delivery as Batronix - but much more personal and knowledgeable after-service.
If it's anything like my DG4062, it'll be horribly picky - and the faults that show up vary between memory sticks. I had one not recognised at all, one became unreadable in the PC after being used in the Rigol, and one would work OK in both Rigol and PC, but they were clearly accessing different memory areas in the Flash because neither could see the other's files (and would clearly end up corrupting and overwriting them).When loading Waveforms from a USB Stick I have to remove the stick and re-insert after I have selected Storage, Load, when the stick was inserted/left-in before start-up .
Is this only on 1.00.02?
This isn't a problem for me using 01.00.05. Have you tried alternate sticks? Some devices are notoriously picky about the brand.
...because of the problems and service needed surrounding the early firmware of the DS4000...I know the DS4000 series is more expensive and there aren't quite so many around, but: am I to assume that the DS4000 series runs similar firmware and suffers from similar bugs to the DS2000 series? If I were looking at ordering one soon, should I hold off or at least insist on it being supplied with a particular firmware version?
I know the DS4000 series is more expensive and there aren't quite so many around, but: am I to assume that the DS4000 series runs similar firmware and suffers from similar bugs to the DS2000 series? If I were looking at ordering one soon, should I hold off or at least insist on it being supplied with a particular firmware version?
Is there a list of known bugs in the DS4000 series anywhere?
Also, since I have the animated GIF option as a kind of compiled version of the screen images - I'd like to do the same for the CSV output. Does anyone know if you can make a database file that is in CSV format? So it could be opened in Access or another DB program?To what purpose? A relational database isn't really appropriate for this sort of data I don't think. Though most database engines I'm familiar with can import CSV fairly easily (Postgres, MySQL and Oracle all can).
Well, I'm not sure - maybe we can discover a purpose later. But originally the idea was just as a possible solution to an organizational problem - if you want a voltage record of each waveform stored in a 100 different frames, the DS2000 doesn't allow you to save any files when in Record mode. But my software can pull out that voltage record from each frame and save it as a CSV file, but then you have a 100 (or whatever) separate CSV files. I thought it might be handier to have it stored in a single file, as a database of frames connected via their relationship to time. Anyway, just trying to think of more efficient ways to save recorded data for possible analysis or processing later.I see what you mean, maybe something a little more elegant than a bunch of timestamped text files is required... Maybe a simple XML format? Unless you're planning on writing a 'waveform management system' as well though (and I'm sure many would be happy if you were!), this might be one to leave as an exercise to the reader. :)
BTW, in the interest of pushing the software I'm writing on more owners ;) it takes the Rigol 15 seconds to write a PNG file to a USB stick - and then, of course, there's the time needed to transfer the stick to a computer and read the file. It takes the Rigol UltraVision Utilities 2.3 seconds (using USB) to transfer the data to the PC and save it :)
I find that if Counter is On ,
AUTO does not work
Does this happen on FW=1.00.05?
I find that if Counter is On ,
AUTO does not work
Does this happen on FW=1.00.05?
It seems to work for me with FW 01.00.05:
DS2072 FW=1.00.02
Update on Bug 7.) AUTO routine sometimes fails
I find that if Counter is On, one channel Only ,
AUTO does not work
changes trigger and scan rate
and only displays a blank Menu
See Displays att.
Strange hat,
On small signals of about 1 mV i get a strange hat on
the trigger point, see att. picture, that little peak on the middle
of the screen on the top of the sinus.
It is only at the trigger point, perhaps to do with noise
trigger or something..?
Note the generator reads 536 uV, so very good rms on the scoop.
Strange hat,
On small signals of about 1 mV i get a strange hat on
the trigger point, see att. picture, that little peak on the middle
of the screen on the top of the sinus.
It is only at the trigger point, perhaps to do with noise
trigger or something..?
Note the generator reads 536 uV, so very good rms on the scoop.
You've set the trigger level just below the "hat" level, so naturally that is what the scope is triggering on. Set the trigger to mid level of the sine instead, and see if you can see the hat then. If not, set to inifinite persistence.
//C
Why doesn't the DSO show "T'D" ? ,Triggered , with the peak of wave well above trigger level
Strange hat,
On small signals of about 1 mV i get a strange hat on
the trigger point, see att. picture, that little peak on the middle
of the screen on the top of the sinus.
It is only at the trigger point, perhaps to do with noise
trigger or something..?
Note the generator reads 536 uV, so very good rms on the scoop.
Strange hat,DS2072 Fw1.00.02 for clarity, I suggest prefix with Model and FW
On small signals of about 1 mV i get a strange hat on
the trigger point,
What does the '*' mean on the "700 pts*"?
Why doesn't the DSO show "T'D" ? ,Triggered , with the peak of wave well above trigger level
I never see "RUN", on top left of my DSO
I only see AUTO, |AUTO| reversed, and T'D when in Auto
Maybe changed in your later FW?
Strange hat,
My scope does the same thing and I think martinv's explanation is correct. The scope is triggering on noise on top of the peak of the sine wave (there's apparently an offset for these tiny voltages). This noise shows as a peak at the trigger point because it survives the averaging, as it is correlated because it's triggering on that. But away from the trigger time, the noise is not correlated so it gets averaged out. So I think it's just an artifact of the trigger/averaging process and not a bug.
I also do not think it is a bug, but search for an explanation.
The trigger has no connection with the avarage, and the trigger is always in this case in the middle,
so for the trigger it is a almost a fix point, for the avarage not.
But you also see it with avarage off, only more difficult to see
Strange hat,
On small signals of about 1 mV i get a strange hat on
the trigger point, see att. picture, that little peak on the middle
of the screen on the top of the sinus.
It is only at the trigger point, perhaps to do with noise
trigger or something..?
Note the generator reads 536 uV, so very good rms on the scoop.
Strange hat,
Note the generator reads 536 uV, so very good rms on the scoop.
Another observation is that the 10 MHz sine wave is not at a sufficient level to have its frequency counted: "< 15 Hz".
Strange hat, and now a DitchI'm DS2072 FW=1.00.02 Trial options
It is only at the trigger point, perhaps to do with noise
trigger or something..?
Strange hat,
So it looks that the bandwidth at the BNC connector is 200 Mhz at -3 db,
if you ingnore the impedance changes at the BNC input.
Keep in mind that it is a 1 Mohm 18 pf input. The scoops >200 Mhz
have also 50 ohms inputs.
Anyone who can verify ??
And the 700* is only in auto mode for memory, cant find any explanation.
I figured this would be a great use for the record and playback, but I discovered large gaps of lost data between each recorded frame/(screen). I'm assuming this is normal?
Instead of scrolling with the tiny horizontal knob, WHY can't this nice big jog wheel be used to scroll quickly forward and back instead of using the little horizontal knob. Wouldn't this be a huge improvement?
And the 700* is only in auto mode for memory, cant find any explanation.
It means <= 700 bytes. Depending on the timebase setting, frame recording, and other settings, the sample size can continue to drop in AUTO mode - following the defined scale: 560 -> 140 -> (70) -> 56 bytes - which appears to be the smallest size used - which equals 4 points per division.
So it looks that the bandwidth at the BNC connector is 200 Mhz at -3 db,
if you ingnore the impedance changes at the BNC input.
Keep in mind that it is a 1 Mohm 18 pf input. The scoops >200 Mhz
have also 50 ohms inputs.
Anyone who can verify ??
I have tested the BW of my DS2102
with some nice results, summarizing:
BW in BNC= 190Mhz.
BW in 1/10 probe = 244Mhz.
Trigger OK just 375Mhz.
Counter just 410Mhz - accuracy -0,+2 last digit.
Hi Marmad, and everybody else
Based on your great review on the DS2072 and the posts to the EEVblog forum here, I decided to order the DS2072 for myself. Thank you all!
- snip -
I'll update you as soon as the scope arrives. :D
After two fun hours with the DSO, I can make two conclusions:
a) the scope is really fun to work with and
b) for some reason my Basic Micro ARC32 controller seems to always set the first bit to high in each byte read from I2C - I have absolutely no clue why.
ps. I added a screenshot to show an example of I2C decoding :D
If anyone knows a good source for decent BNC 50R thrus that aren't $50 I'd appreciate it.
SeeThanks Teneyes, I did read talk about this special menu but I thought it was only for upgrading for some reason. Weird that they'd obscure this... anyway I have the same version 1.00.02 that everyone else has.
https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg172218/#msg172218 (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg172218/#msg172218)
for acess to real firmware version number
I'm planning to buy a new scope and been thinking whether to get the Owon SDS7102V or Rigol DS2072. The higher bandwidth of Owon is a big plus (-3dB point somewhere near 150MHz), but hunting some random glitches seems to be better in DS2072.Mine is around 100MHz. It looks like it's probably the same hardware as the higher bandwidth models though, so there may be a software or hardware hack.
Has anybody measured the actual bandwidth of DS2072? At what frequency might this -3dB point be?
Overall I'm pretty impressed with the 'scope from the past couple of hours exploring. My biggest disappointment is probably the image capture features. Capturing a PNG file to the USB stick takes like 45 seconds! BMP is faster but still quite a few seconds. I was expecting the 'print' button to be pretty much instant. Copying over the network using RUU (this is great! thanks!) isn't much faster, but I do like the idea of having a network connected 'scope ;).
What might be the best place to purchase DS2072 in Europe (I live in Finland) ? I've checked the Batronix, but are there some other sellers with better price?Well, as I mentioned in the video and a couple of times since (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg177291/#msg177291), I recommend people buying in the EU use EEVBlog member drieg. Same price/free shipping as Batronix (I think the price is fixed in the EU - same as in NA)- but much better before/after sales support. Drieg is the one testing and reporting all of the bugs we discover here on the blog to Rigol - and I gather he is perhaps the biggest expert here on all things Rigol.
How could BMPs be faster than PNGs? They are often ~100x bigger - and writing to an external device usually requires more time than processing - although I can't say I've actually timed saving BMPs on the DS2000. Also, I don't know if the brand of USB stick you're using (or FW 01.00.02) affects save/transfer rates - but my timed speeds are:PNG is quite often slower even on a fast PC depending on how you set the compression. The CPU in these is not fast. It wouldn't surprise me that much.
However I've done some more poking around and it seems that the problem only happens if you set Storage>Storage to Picture instead of Traces. I'm not sure what the difference is since it seems to produce identical image files, but Traces doesn't allow filetype selection and takes from 2-5s to write to the USB and makes a BMP file.
Well, as I mentioned in the video and a couple of times since (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg177291/#msg177291), I recommend people buying in the EU use EEVBlog member drieg. Same price/free shipping as Batronix (I think the price is fixed in the EU - same as in NA)- but much better before/after sales support. Drieg is the one testing and reporting all of the bugs we discover here on the blog to Rigol - and I gather he is perhaps the biggest expert here on all things Rigol.Thanks for this information.
It seems that the DS2072 is lacking the alt trigger mode and dual timebase, or have I missed something?No alternate trigger - but many other standard included triggers (plus even more via one of the option packages). Yes dual timebase - called Delayed Sweep - which is very easy to enter and exit (via a simple push of the Horizontal Scale knob).
Marmad, can you briefly summarize, what were the main reasons for replacing the Owon with DS2072? Can these reasons justify the price difference...?Well, actually, the Owon was replaced with a Hantek - which was later returned. I then continued using my analog Tek scope until I read about the Rigol DS2000 series. But I've spoken/written about this quite a lot already (short synopsis here (https://www.eevblog.com/forum/reviews/review-of-owon-sds7102/msg58541/#msg58541)) so suffice it to say that all of your instincts (and the stuff you wrote in your previous post) are correct.
Btw, there seems to be slight difference in end user prices (with VAT included) when comparing Batronix to Silicon electronics...(maybe due to different VAT amount).I bought my DS2072 through my company (so minus VAT), but if you send drieg a PM or email about the difference, he might be able to help you out.
I'm happy you figured out a method to make it quicker for yourself (although saved traces [the channel data itself] is not the same as a saved bitmap of the entire screen) - but it doesn't really resolve the issue or shed light on the problem behind it - which might be helpful for other 01.00.02 users here.Okay I did some more testing on this issue. Saving PNGs definitely takes > 30s, whether from the Storage menu or from the Print button after choosing PNG in storage. BMPs do seem to be quick though, around 2s. I think my confusion was in using the Storage menu to change the Print format, I think I must have not confirmed the setting back to BMP before pressing Print.
It takes you 45 seconds to save a PNG picture - but it takes me 15 seconds. Is this a question of firmware - or different USB sticks?Could easily be either :)
Also, would you please mind posting the time (and connection method) it takes to transfer & save a PNG using RUU? This might help resolve things.6 seconds over Ethernet, from clicking Save on the file picker dialog. BMP is about the same. I don't have a long enough USB cable (or any free ports for that matter...) to test using USB. Thanks for your help :)
Okay I did some more testing on this issue. Saving PNGs definitely takes > 30s, whether from the Storage menu or from the Print button after choosing PNG in storage. BMPs do seem to be quick though, around 2s.
6 seconds over Ethernet, from clicking Save on the file picker dialog. BMP is about the same.
On my DS2072 01.00.02 FW I get the following for saving screen shots to USB sticks:
San Disk 1GB, "Print" 56 sec, "Save" PNG from Storage menu 59 sec
Kingston 2GB, "Print" 57 sec, "Save" 60.5 sec
DS2202, FW 01.00.05
PNG: Save 20 sec, Print 16 sec
BMP: Save 11 sec, Print 8 sec
How slow is the image save speed of the DS2000-series compared to other scopes (Owon, Hantek..)? I was surprised how slow these are compared to other (like Tektronix). If I recall correctly, on those more expensive models it won't take many seconds...On my DS2072 01.00.02 FW I get the following for saving screen shots to USB sticks:
San Disk 1GB, "Print" 56 sec, "Save" PNG from Storage menu 59 sec
Kingston 2GB, "Print" 57 sec, "Save" 60.5 secDS2202, FW 01.00.05
PNG: Save 20 sec, Print 16 sec
BMP: Save 11 sec, Print 8 sec
Wow, so it does appear as if Rigol either optimized their code in FW 05 - or more likely, fixed a bug - since you'd have to write REALLY BAD code to produce something that would take almost 60 seconds to convert an 800x480x24 bitmap to PNG format and save it.
How slow is the image save speed of the DS2000-series compared to other scopes (Owon, Hantek..)? I was surprised how slow these are compared to other (like Tektronix). If I recall correctly, on those more expensive models it won't take many seconds...
We're talking about a bitmap image - not the voltage levels of the waveform (which is way faster) - so the speed is linked to the size and depth of the display, which is 800x480x24 bits on the DS2000 series. That's 9.2Mb or 1.1MB, The Owon is 800x600x8; which is 3.8Mb or 480kB.
You make mistakes quite often when you talk about Owon. Selectively forget the truth?
But I'm very lazy to correct all becouse - who cares.
Go ahead and create some original content of your own on EEVBlog instead of sponging off of mine - I mean, damn, you didn't even have the idea of buying your first SDS7102 on your own - you got that from my review.
"
22 February 2010 08:33 PM
Pitäisikö valmistautua siihen ajatukseen että laadukkaat huippumerkit tulevatkin joskus Kiinasta?
Tekway, Rigol, Owon (1) , Atten, Uni-T (lempinimi Uni-Toy).
.
.
.
(Image)
20 August 2011 02:50 PM
Ai mikä tämä on?
No se on Owonin uusi SDS malli. Owon on itse kehittynyt muutamassa vuodessa kapisesta moskan tuottajasta varteenotettavaksi ja nyt viimeisimpänä iskivät markkinoille aikamoisella uutuudella. (2)
(ei siis todellakaan ole se wanha parjattu Owonin DSTN sekoilu...jossain muutenkin kapisessa mallissa)"Quote(3)"
Attached image is authentic OWON -> USB -> PC Transferred bitmap image. Is it 800x600x8?Quick image analysis suggests the Owon is using 9-bit RGB and the Rigol 16-bit RGB. Both seem to be using less than 256 colours on screen, so it's possible they're using indexed colour modes.
Attached image is authentic OWON -> USB -> PC Transferred bitmap image. Is it 800x600x8?Quick image analysis suggests the Owon is using 9-bit RGB and the Rigol 16-bit RGB. Both seem to be using less than 256 colours on screen, so it's possible they're using indexed colour modes.
Can not correct your mistakes or lies? Then you come angry. Grow up.
Do you overall mainly think that things what occurs around same time have causality?
20 August 2011 02:50 PM
I have a question about the Record/Play back functions. I tried using the serial decode function and found about the maximum I could fit on 1 screen is as shown in the attached picture.
Now I can zoom much further out in the horizontal scale and capture a huge chuck of data then zoom back in to read/decode it.
I figured this would be a great use for the record and playback, but I discovered large gaps of lost data between each recorded frame/(screen). I'm assuming this is normal?
So i'm back to the zoom way out, grab a screen with max data points, then zoom back in to read/decode.
Instead of scrolling with the tiny horizontal knob, WHY can't this nice big jog wheel be used to scroll quickly forward and back instead of using the little horizontal knob. Wouldn't this be a huge improvement? Perhaps this could included in a future update. I feel like hooking up my cordless drill to the Horizontal knob sometimes:)
I don't have much experience in capturing/decoding data, so please let me know your thoughts and preffered methods of doing this.
What are some of the other uses for the record/playback feature?
I'm still wondering if the lost data between each screen record using the Record/Playback feature is normal to this scope, all scopes, or a bug?Martin, I'm not quite sure why you're re-posting this old message when I answered it here (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg178869/#msg178869) - unless you missed my previous response.
Sorry, I did miss your previous reply somehow, yet I recall reading the post before and after, but I also sometimes plug red into black and black into red by mistake. Then again my job sometimes requires it to be done intentionally!No problem - the mad unspooling of threads here sometimes means you miss responses ;) And I'm sorry if I was somewhat short-tempered - it's been a tiring couple of days.
...So for long continuous streams of data, it's not going to work well - you're better off using the entire 56MPts of memory in a single shot.
I was missing the 'Delayed' ON in the horizontal menu which allows use of the 'Navigation Knob'. This is great as my last scope force me to turn the little horizontal position knob 100s of turns to do the same thing.
Well, does the DS2072 have anything similar to Tek Wave Inspector? It is nice to have 14Mpts acquisition memory length, but is there any possibility to search for events or place marks? It seems to me, that not. I have read the DS2072 user manual. Anyway, Owon SDS7102 also has no tools to manage the nice 2×10Mpts memory.
10M record length for each channel;Anyway, you mentioned it here, that Owon has 10MB per channel. But if it had only 5MB per channel, it would also be enough.
Well, it is not much important, but it seems that Owon has really 2×10MB memory.
when I set the screen saver to any given time, It doesn't activate at all. Thank youDS2072 FW1.00.02
Yep, I don't get a screen saver time-out to Rigol Screen,, tried 1min, 2 min
But then again with Trial Options, I shut it Off when not in use
I just got my DS2072 last week but only today noticed that when I set the screen saver to any given time, It doesn't activate at all. Its supposed to show the Rigol screen is it not?
I've updated the FW from 1.00.01 to 1.00.00.05 (which I can only tell from plugging a USB with the latest version on it, in) however still no go as regards the screen saver issue.
I'm not quite sure what you mean by this? Do you mean writing the scope variables to a file? You can get detailed version info by following these instructions:
Go to the Trigger menu and set Edge trigger
Then press the [Menu7][Menu6][Menu7][Utility] buttons one after another quickly.
Then check additional info under System -> System Info.
To escape from this mode, press again [Menu7][Menu6][Menu7][Utility] while inside Trigger menu
- or reboot the scope.
Perhaps it's a bug in 01.00.02 - and you haven't properly upgraded yet? BTW, as far as I know, there haven't been any scopes delivered with 01.00.01 - so I think you started (or still have) 01.00.02.
Your right marmad.. I must not have completed the upgrad to the FW.. However when I insert the USB stick with FW v01.00.05 on it, it says 'A same firmware detected, Upgrade'?
Your right marmad.. I must not have completed the upgrad to the FW.. However when I insert the USB stick with FW v01.00.05 on it, it says 'A same firmware detected, Upgrade'?
@orbiter: I'm not sure you're actually entering the 'special' mode to get to the detailed system info. After going through the steps in the previous post, are you seeing a screen like this?
Software version: 00.00.01.00.05
Hardware version: 1.0.1.0
FPGA version:
SPU 03.01.02
WPU 00.06.00
CCU 12.29.00
MCU 00.05
Is the External Trigger also digital , with separate ADIC, back to the teardown???
How can we test ?
I have no additional info come up marmad, only the same info that is shown in my second picture.
EDIT:... Do I need to upgrade to 00.00.02 first or something?
Well here is display of 138Mhz on Chan 1 , with External Trigger and looks like 10 Dots in 5ns for 1 sample every 0.5 ns, and 2GSa/s ,
However now I still have the initial problem.. No screensaver :(
Can someone else reading this with 01.00.05 run a quick test of the screen-saver on their Rigol?
I can do it, but not before tomorrow.
For the need of an External trigger and 2GSa/s ,
It is best to use Chan 2 and External, this is a Work around to avoid having to power-off and on for uses of Chan 1 and external Trigger .
Yes no offset if using Chan 1 and/or Chan 2 as trigger, (1GSa)
Go back to old msg for Dots at display of 2GSa/s and set to External
Does someone have 2 output function gen with phase offset to test
mmm I'm thinking of DG3062
BTW, I'm just about to upload a bug-fix for RUU (version 1.51) for you. I found one line of code with a TypeConversion mistake. When you get a chance, please download the new version, switch your Windows settings back to ',' for decimal point and try to enter 'Zoom Markers'. I think it should work fine for you now.
OK to more complete here are #1 Chan1 with EXT , dots, and Chan 2 with Ext and Dots
Yes, it works now.
Thanks!
No worries, there's no rush. Thanks for the assistance guys.
Screen saver works! FW 1.00.05 DS2202
However now I still have the initial problem.. No screensaver :(
Is it possible we could get one other owner with a DS2072 and FW 01.00.05 to check their screen saver? Sparky?
I can try testing the 2G Sa/s on both Ch 1 and Ch 2 with ext. trigger, as there are still questions on that issue... I have a DG4062 near by if we need two signals with phase offset.
I can try testing the 2G Sa/s on both Ch 1 and Ch 2 with ext. trigger, as there are still questions on that issue... I have a DG4062 near by if we need two signals with phase offset.
Great! There is clearly a misunderstanding about our bug report vs. what Rigol thinks the problem is/isn't.
If you could just check (using dots) what the real sample rate is when the DSO displays 1 GSa/s after choosing CH1 & Ext. Trigger - then reboot and check it again after it displays 2 GSa/s - we would know for sure if it was an actual sample rate setting bug - or a display of sample rate bug.
Test done! Seems the 2G Sa/s is the real deal when using Ext trigger (after reboot)! So, display on the scope is correct, and it is indeed bug in the firmware which requires reboot of the scope to get this 2G S/s.
Let's forward this clarified bug report to Rigol via our friend drieg!
Here are the same pictures from my scope DS2202, which Sparky sent :
From the discussions here, it appears that I should upgrade to firmware 1.00.05 when the unit arrives (assuming it is not already at that level). Can someone please let me know how I would go about getting the firmware?
Excellent! So now we have confirmed this bug for both DS2072 and DS2202! I guess single firmware fix will resolve the problem for all DS2000 series.
Be sure to read the warnings and follow instructions upgrading the firmware --- only do upgrade during BOOT! Search this thread and the above thread for details on the procedure.
It is good that there is no trigger level line on the trace as the trigger level is unrelated to the displayed signal, but it this test by connectting to the same point , we know they are the same and can realize the offset.
From the discussions here, it appears that I should upgrade to firmware 1.00.05 when the unit arrives (assuming it is not already at that level).@sanka (and other prospective new owners): First off - welcome to the party ;D Us early adopters gotta stick together!
DS2072 FW 1.00.02
Can someone please verify .
Hi EV, I only have DS2072 (until someone can tell me how to unlock it >:D) without 2ns timebase, but I think the results are useful anyway. I'm not seeing the same effect on DS2072 FW 1.00.02. See the pics. These captures are with AA on, normal acq mode, I've tried other settings and it doesn't seem to make a difference.
Hi EV, I only have DS2072 (until someone can tell me how to unlock it >:D) without 2ns timebase, but I think the results are useful anyway. I'm not seeing the same effect on DS2072 FW 1.00.02. See the pics. These captures are with AA on, normal acq mode, I've tried other settings and it doesn't seem to make a difference.
Your tests are with CH1 as the (internal) trigger, so this is not a direct comparison. I think everyone is getting normal results like you show for internal trigger. The test proposed by Teneyes is to use external trigger, which is how EV has done the test.Ugh, of course you're right. Serves me right for not re-reading the thread I was trying to follow at work...
I have re-done the test can confirm I'm seeing a relatively similar effect, but my delays seem longer at 20MHz. The test is not valid though, as I don't have two matched length BNC cables to do the ext. trig. test and it is few ns per foot.
I've been playing with the waveform file and getting pretty much nowhere.
One bug I found (or re-found actually) on my scope (FW 00.00.01.00.02): if I try to save waveforms to a USB stick without first saving a screen capture using the print button, my scope
hangs and must be powered down. If I save a screen capture first, after each powerup, then saving waveforms and CSV work fine. Tested two USB sticks.
Do you think normal triggering would change anything?
Do you think vector interpolation is doing anything ( use DOts maybe)
any at higher 100Mhz
DS2072 FW 1.00.02Put the rise time measurement on from left of the window, so we can see what it is.
Here is a nice rise time with a fast clean Pulse ;D ;D ;D
I've been playing with the waveform file and getting pretty much nowhere. I saved a waveform that says it has 1400 pts (50ns/div, 2GSa/s). The file is 22,376 bytes long and has a bunch of stuff that makes no sense to me. But if I read the data in as 8-bit bytes I find the trace stuck on the very end as two interlaced 728 point traces (yes it's 728, not 700). By interlaced I mean one trace followed by 4 bytes then a second trace. When I stick the two traces together (i.e. deinterlace them) it almost exactly matches the screen capture of the waveform. I have no clue what this means, but the data I was able to find was straight 8-bit bytes. (That doesn't mean that other versions of the data aren't hiding elsewhere in the long file.)
DS2072 FW 1.00.02
Here is a nice rise time with a fast clean Pulse ;D ;D ;D
Wow! :) The rise-time is about 1ns! How did you generate this pulse? Rise times on my signal generator are about 10-12ns.
Wow! :) The rise-time is about 1ns! How did you generate this pulse? Rise times on my signal generator are about 10-12ns.I'm guessing he modified the saved file and re-loaded it :)
It's A JOKE
The lines are way tooo Perfect
Here is the best rise time I think given that the dots are interpolated by the DSO with Sin(X)maybe 1 dot at middle is better and rounding above 90% .
Also see the dots to make the vector display
I Learnt a lot and it was fun, . just a geek at heart
[...]
See this post in marmad's software tips and tricks thread:
https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg175707/#msg175707 (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg175707/#msg175707)
Be sure to read the warnings and follow instructions upgrading the firmware --- only do upgrade during BOOT! Search this thread and the above thread for details on the procedure.
I guess the upgrade completed when the CH 1 button stopped blinking and all the front panel lights came on steady. I waited a long time to see if some screen update might happen. After staring at the steady lights and the blank screen for some 20 minutes, I lost patience, turned off the power, took out the USB stick, powered it back on, and found that everything was fine!
[...] since the discovery of the Memory Read bug in FW 05 (Software can't read sample memory from scope: #9 in our compiled list of bugs in the first post of this thread) (https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158659/#msg158659), I would just urge you to think a moment before upgrading if you use (or want to use fairly soon) MATLAB, LabVIEW, or any other third party software which needs to read the sample memory for processing.Thanks for the warning, Marmad. I did the 01.00.05 upgrade as I don't plan on using third party software any time soon.
[...]
I guess the upgrade completed when the CH 1 button stopped blinking and all the front panel lights came on steady. I waited a long time to see if some screen update might happen. After staring at the steady lights and the blank screen for some 20 minutes, I lost patience, turned off the power, took out the USB stick, powered it back on, and found that everything was fine!
Hmm...not completely sure it worked correctly. Do you still have your trial options? If not, it went wrong - if so, things are fine.
...shows 2122Minute for all rows. Is that a happy scope?
btw, I read in another post here that Self Calibration takes away the trial options. Is that true with 1.0.5 too? Should I refrain from calibrating until after I have played with the trial options?
@EV: Thanks for checking. Is it possible we could get one other owner with a DS2072 and FW 01.00.05 to check their screen saver? Sparky? I can't imagine that it has anything to do with model number, but it might be good to be sure.However now I still have the initial problem.. No screensaver :(
@Orbiter: Since two others with the same firmware as you have it working, time to try various settings on the scope to see which one might affect it. I'd start with a 'reset' to default settings (I can't remember in which menu that is located on the DSO - but I know it's there) - then try the screen saver again first before altering anything. Then - with screen saver set to time out in 1 minute, I'd try changing some of the more obvious settings/options and give it a minute to timeout.
BTW, do you have any trial or permanent options running? Both EV and I have at least one permanent option - which, theoretically, might make a difference. That's another reason it would be good to hear from another DS2072/FW 01.00.05 user.
EDIT:.. OK an update..
Just forwarded the clock on the scope and re-calibrated it afterwards.. Guess what? I now have a screen screen saver :) However now I've lost my trials :(
Screen saver doesn't activate.
I tried under two conditions - 1. With the clock set to Beijing time (or so it seemed) as it came from the factory, and 2. With the clock set back to my local time (Pacific Standard Time).
[...]For what it is worth, I filed a report at http://www.rigolna.com/tech-support/. (http://www.rigolna.com/tech-support/.) I want to see how responsive they are.
Well, clearly there is some kind of screen saver bug,
[...]
[...]I should have some time next week to play with and learn the scope a little bit. I'll tweak some settings and report back if screensaver starts to work.
but since at least two of us with 01.00.05 report them working - it must be caused by some combination (or lack of) settings, options, etc. Not really sure how we can figure out the parameters of it.
[...]
@ Sparky
It's interesting to see the DSOs interpolation of the individual data points.
It's interesting to see the DSOs interpolation of the individual data points.@ Sparky
Here are displays showing how the DS2072 interpolates 1 Sample off line ,vectors and dots
Then displays of 2 Samples in a row off line, vectors and dots
Note how 2 samples will make the trace going more offline
These are very unlike to occur unless a weird event happens, IE a Neutrino hits the ADC
It is more to show the interpolation function
Where do i find the Firmware updates ?
For Sin(x)x See these discussions:
https://www.eevblog.com/forum/chat/sin(x)x-interpolation-and-digital-filters-in-oscilloscopes/#top (https://www.eevblog.com/forum/chat/sin(x)x-interpolation-and-digital-filters-in-oscilloscopes/#top)
https://www.eevblog.com/forum/chat/rigol-ds1000e-series-possible-errorfail-in-sin(x)x-interpolation/ (https://www.eevblog.com/forum/chat/rigol-ds1000e-series-possible-errorfail-in-sin(x)x-interpolation/)
I've found a bug. Very minor, but a bug nontheless. I'm using firmware 00.00.01.00.05:DS2072 FW1.00.02
When using the menu timeout feature (menus retract after a set amount of seconds of inactivity), pressing any of the menu buttons or flipping to a next page resets the timer.
I've found a bug. Very minor, but a bug nontheless. I'm using firmware 00.00.01.00.05:
When using the menu timeout feature (menus retract after a set amount of seconds of inactivity), pressing any of the menu buttons or flipping to a next page resets the timer. It doens't do this for the left-side menus. No matter what button you press, the left menu always retracts after the set time from initial activation. The only way to 'keep it open' is to press a button the instant it retracts.
I can confirm the X-Y swap is fixed in 00.00.01.00.05 (still in the list in the first post).
You are not reporting the full Firmware revisionAaah thats right,
Storage->DiskManagerI totally missed that, think i checked the second page, but noo i had not :)
Yes that is annoying but the return is there on the second page of the menu,
So i did got back the trail options, and for test i did an auto cal to get rid of the trail options. ( version ..005 )
That worked, all the trail options are gone after the self calibration.
I will test now to see if i can get it back again, i want to discover a solid reset.
I've found a bug. Very minor, but a bug nontheless. I'm using firmware 00.00.01.00.05:
When using the menu timeout feature (menus retract after a set amount of seconds of inactivity), pressing any of the menu buttons or flipping to a next page resets the timer. It doens't do this for the left-side menus. No matter what button you press, the left menu always retracts after the set time from initial activation. The only way to 'keep it open' is to press a button the instant it retracts.
I can confirm the X-Y swap is fixed in 00.00.01.00.05 (still in the list in the first post).
And my trail options are back againOoo how did you do that ?
Your absolutely right. It was a long day, late at night :=\. My logic thinking out the window it seems. X-Y is still swappedI can confirm the X-Y swap is fixed in 00.00.01.00.05 (still in the list in the first post).
As far as I know, the X-Y swap bug has not been fixed in any version of firmware - except the engineering version which Dave had briefly. It's not fixed in my FW 01.00.05.
What is wrong with that.., on my anloge scoop it is also this way
ch1 give the vertical and channel 2 the horizontal.
@Teneyes and Sparky:
As you can see, it is perfectly correct.
Perhaps we need to make more checks like this at higher frequencies (approaching BW limit) to see if the DS2000 series suffers the same problems pointed out in the old thread (https://www.eevblog.com/forum/chat/rigol-ds1000e-series-possible-errorfail-in-sin(x)x-interpolation/https://www.eevblog.com/forum/chat/rigol-ds1000e-series-possible-errorfail-in-sin(x)x-interpolation/) (in which rf-loop pointed out that in the Rigol DS1052E/DS1102E, Rigol's implementation of SIN(X)/X was terribly wrong at frequencies approaching the rated BW)?
BTW, do you know where then name "Vectors" has come from?
so they just use 'vectors' as a kind of vague term for some kind of interpolation that they don't want to fully explain.
Can anyone provide a Dots display of a real 400MHz signal into a DS2202 with 2 chans (1GSa/s)?
Hey look at this Noisy Waveform, ;D
Well, clearly there is some kind of screen saver bug,For what it is worth, I filed a report at http://www.rigolna.com/tech-support/. (http://www.rigolna.com/tech-support/.) I want to see how responsive they are.
[...]
I should have some time next week to play with and learn the scope a little bit. I'll tweak some settings and report back if screensaver starts to work.
I called Rigol NA in Ohio. A very helpful gentleman helped me debug it on the phone and concluded that a new unit will have to be sent out. He is arranging for the RMA and an Advance Exchange (i.e., he will send out a new unit before my unit reaches him).
Although the unit I received was defective, I got a chance to check out Rigol NA Support and they appear helpful and prompt.
Has anyone done much with the I2C trigger. I can get it to trigger on a Start condition however I don't seem to be able to get it to trigger on a Missing Ack or Address.
I am reporting a bug on 500uv only, where the display of the trace trigger point on the Center vertical graticule ( orange T arrow down) is offset higher that then trigger level. This offset higher , is bigger at larger trigger Levels. See the Pics
My options are EXPIRED, but still there..
FW 1.00.02
@marmad ,
This is a repeat report, I connectted a low level signal to Channel 1 , & set 8 point averaging for cleaner trace. The vertical scale was set to 500uV.
I am reporting a bug on 500uv only, where the display of the trace trigger point on the Center vertical graticule ( orange T arrow down) is offset higher that then trigger level. This offset higher , is bigger at larger trigger Levels. See the Pics
Can anyone confirm my testing???
This is a small bug.
This may only occur on FW 1.00.02
There is No Offset on any other vertical scale.
There is No Offset when trigger level is 0.0. @ 500uV
The Trace does not offset, just the indication of the trigger point, IE the trace shifts to the left
Yes Noise affects the trigger point ,
I am saying the bug is how the trigger point is displayed
At 1 mv , all is OK
At least at 1mv/div the Center and trigger line intersect on the Trace.
I think the offst you are seeing is your 100KHS is modulated on a slower signal, like Mains power,
If you set Scan rate much slower , I think you'll see the higher Freq. on a low Freq.
Is this the norm on the DS2072?
Is this the norm on the DS2072?
Yes, look at the bug 7 on the first post. There is no alt trigger, so AUTO is useful only for a signal on one channel and if there is an easy signal. I have not used it at all for a long time.
Has anyone done much with the I2C trigger. I can get it to trigger on a Start condition however I don't seem to be able to get it to trigger on a Missing Ack or Address.
Has anyone else experienced this? It may well be user error or some sort of Software issue on the board that I'm using to test.
Thanks Mike
I couldn't get it to do the initial Probe Compensation Function Inspection, per Page 7 of the manual. I keep getting "Auto Failed" error messages.For future reference , the "Auto Failed" message usually means No signal attached or it is too small for the DSO to detect and Auto Lock.
Will we ever know the cause of Failure? Loose heat sink Clips??
welcome to the forum;
Has anyone done much with the I2C trigger. I can get it to trigger on a Start condition however I don't seem to be able to get it to trigger on a Missing Ack or Address.
Thanks Mike
Assuming you have looked at signal to be right levels and generally OK
SDA , SCL assigned correctly
Do you know that there Is a missing Ack(s)?
I assume you know the Address, and maybe you can Scan slowly thru all addresses 1-127
Can you Att a screen shot with Menu open , like shown below
I find using Marmad's RUU 1.5.1 very easy & fast
See: https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg171575/#msg171575 (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg171575/#msg171575)
By the way, I had to use a second scope to get the width of the trigger output pulse measured. It seems to correlate with the time/div setting and the memory depth in use.Wellcome to the forum!
DS2202, FW 1.00.05
The signal from trigger out is very fast rising and falling. I measured it with my TDS3032 (BW 300 MHz) scope and got rise and fall time both to be 1.05 ns. It can be faster but my scope can not measure it. Rise time 1.05 ns gives bandwidth 350 / 1.05 = 333 MHz (> 300 MHz).
Sorry, stupid me, where is the 350 come from?By the way, I had to use a second scope to get the width of the trigger output pulse measured. It seems to correlate with the time/div setting and the memory depth in use.Wellcome to the forum!
DS2202, FW 1.00.05
The signal from trigger out is very fast rising and falling. I measured it with my TDS3032 (BW 300 MHz) scope and got rise and fall time both to be 1.05 ns. It can be faster but my scope can not measure it. Rise time 1.05 ns gives bandwidth 350 / 1.05 = 333 MHz (> 300 MHz).
Sorry, stupid me, where is the 350 come from?
DS2202, FW 1.00.05
The signal from trigger out is very fast rising and falling. I measured it with my TDS3032 (BW 300 MHz) scope and got rise and fall time both to be 1.05 ns. It can be faster but my scope can not measure it. Rise time 1.05 ns gives bandwidth 350 / 1.05 = 333 MHz (> 300 MHz).
Here is picture of Rigols trigger out signals rise time. It is measured with Fet probe. When using direct BNC cable, rise time is measured to 1.09 ns.
Here at the Jersey Shore when we are not wind swept with a Hurricane like Sandy, I like to roll a portion of my lab out onto the back patio and enjoy the great wx while prototyping and designing RF and control projects.
Any of you have experience with the DS2072 screen in sun light? Will the unit need a hood?
Also any hams that might comment on how well the instrument handles itself in high RF environments. HT, 2 to 5 watts VHF/UHF 440 operation close by and HF kilowatt operation in shack... Excellent grounding of all equipment close by and used...
Tek & HP equipment here have no issues - I don't have any hands on experience with Rigol products.
TIA 73
PeterV
I have a problem that when I use DS2102 to test a audio BTL driver, Math function A+B is use for checking any differential signal during rise/fall time, the signal on screen show a lot of noise and apparently should not be that great and have been verify by using TEKWAY DSO, anyone can give me a hand? May be I was operate the scope wrongly.
I got it, it's cause by the ADC resolution and I better end up using external circuit to do similar job. My gone TELWAY 100MHz DSO which cost only 1/3 th the price can do the job beautifully.
Ha Ha, it seen technology is gone backward.
I have not purchased from RigolNA direct, but good support from RigolNA when I lost my Trial options. I purchased from Tequipement as same price for DS but free Shipping.
Even with Back order I received in 11 days. UPS took 6 Days. I also like Tequipement and bought another order and got 5% discount (web coupon) under Rigol's price.
I have a problem that when I use DS2102 to test a audio BTL driver, Math function A+B is use for checking any differential signal during rise/fall time, the signal on screen show a lot of noise and apparently should not be that great and have been verify by using TEKWAY DSO, anyone can give me a hand? May be I was operate the scope wrongly.
Is this a meaningful display for this topic ?
FW 1.00.02
Hi All
This may be only on my version, but watch out for this quirk (bug)
While saving DSO setups to a file on USB stick, look at the funny date stamps on the files I save between 06:55 to 07:00 ,
2 files were stamped with year 2043 and 2014-9-6.
Anyone else see this.!!!
ui marmad .. the thread is running high :)I have the equipment and can run these tests, but I think my BNC cables are garbage (they were cheap) as it's far too sensitive to movement. I'll try to get a stable setup to make some measurements tonight, if nobody else gets there first.
I'm looking for Rigol DS2k series user, with signal gen, to run some frequency response testes
https://www.eevblog.com/forum/reviews/frequency-response-of-your-dso/ (https://www.eevblog.com/forum/reviews/frequency-response-of-your-dso/)
I'll try to get a stable setup to make some measurements tonight, if nobody else gets there first.
ui marmad .. the thread is running high :)
I'm looking for Rigol DS2k series user, with signal gen, to run some frequency response testes
https://www.eevblog.com/forum/reviews/frequency-response-of-your-dso/ (https://www.eevblog.com/forum/reviews/frequency-response-of-your-dso/)
I've somehow got my 2072 into a mode I can't get it out of. The vertical sensitivity display for channel 1 has a tilde instead of an equal sign. For example, it says "~ 1.00v" instead of "= 1.00v". What did I do, and how do I get the equal sign back? Channel 2 is ok, displays the equal sign.
It is on user manual page 2-3. You have AC coupling. Change it to DC coupling.Thanks. Now that I know what this symbol is, it's not only obvious, it's a nice feature. And I realize now what I thought was an equal sign isn't, but a symbol for DC. The book shows only the DC symbol explaining why I never found a "~". I'm coming from an analog scope. Thinking the DC symbol was an equal sign, I interpreted the tilde as meaning "approximately" instead of "ac coupling". This seemed pretty analogous to "uncal" on the analog scope, and my thinking continued downhill from there. Some parts of the transition from analog to DSO are obvious, and others are pretty different.
I'm coming from an analog scope. Thinking the DC symbol was an equal sign, I interpreted the tilde as meaning "approximately" instead of "ac coupling". This seemed pretty analogous to "uncal" on the analog scope, and my thinking continued downhill from there.I don't really think there's an UNCAL for these scopes... since they can tell you the exact width of a div on the display, even if you're using a fractional one (you can do that by pressing the scale knob, then rotating). Sure, it might be more difficult to read, but it's still accurate. :)
This seemed pretty analogous to "uncal" on the analog scope, .I don't really think there's an UNCAL for these scopes... Sure, it might be more difficult to read, but it's still accurate. :)
I'm trying to figure out the following. Coming from an analog scope, I'm still getting my head around al these extra features! But can't figure out how to do (if even possible) what I want the scope to do: I'm trying to determine the absolute maximum pp voltage my bass guitar puts out. Ideally, I want the scope to hold on to the max measured value and capture the next highest if one occurs, either a value, or the waveform itself. Is this possible with the DS2072?? Or do I have to record a bit and track back the recorded waveform?
Thanks guys for the input :-+Ideally, I want the scope to hold on to the max measured value and capture the next highest if one occurs, either a value, or the waveform itself.
@FunK (brother?)
Select which channel , CH1 or Ch2
select left top menu for "Vertical" menu
on left buttons
Select Vpp
Select "Measure"
on right
Select "Statistics" ON
see table for Max Vpp
You may also Like:
select time base 100ms or faster
select "Display" menu (group of 6 menus)
select "Persis.Time"
select "20s"
I guess the levels may change a bit under the load...I second this. I did a similar test with my pedal steel guitar and believe it made a sigificant difference with vs without load. However, the bass under test (BUT?) volume control on is likely providing loading.
Hahahaha Bass-Under-Test! That's a keeper.I guess the levels may change a bit under the load...I second this. I did a similar test with my pedal steel guitar and believe it made a sigificant difference with vs without load. However, the bass under test (BUT?) volume control on is likely providing loading.
I was surprised to see ~12V P-P (with a normal load) especially considering a lot of players run these into 9V powered pedals. On the other hand it took some extreme picking to get that 12V.
There is a serious issue though. The hook sheath slips off too easily.
The scope sees its 3VPP 1kHz cal signal as unipolar, displays it above mid-line and measures it x0.71 for RMS when the channel is DC coupled. ...... F87 is a true RMS reading DMM. Are both the DS2000 and the F87 doing everything right?@Salas:
Put a HP 3478 multimeter on the probe test points of the Rigol 2072,
got 1.48 V on DC
got 1.48 V on AC
On the Rigol 2072,
got rms 1.48 on AC
got rms 2.08 on DC which is not correct
rms gives same Power in the same R, as a DC voltage of that value.
Be aware that Gating Area, means the trace on the display, so you can see when I moved the trigger point to the left and adjust the time base to show mostly just the +300mv of the Cal-signal the DS2000 will Calculate the RMS to be 283mv ,
See display, I hope that helps understand this scope
Note: I used the Fine Adjust of the timebase to get 39.00us/div
A nice description:
http://masteringelectronicsdesign.com/how-to-derive-the-rms-value-of-pulse-and-square-waveforms/ (http://masteringelectronicsdesign.com/how-to-derive-the-rms-value-of-pulse-and-square-waveforms/)
Put a HP 3478 multimeter on the probe test points of the Rigol 2072,
got 1.48 V on DC
got 1.48 V on AC
On the Rigol 2072,
got rms 1.48 on AC
got rms 2.08 on DC which is not correct
rms gives same Power in the same R, as a DC voltage of that value.
I'm specifically interested in having the math function display Channel 1 plus Channel 2, but with different delays between the channels. I guess it's just not possible...
Thanks neverthereless ;)
NOTE: This DS2072 display data was Manually Created to test the DSO measuring system.
so I can better understand .my first DSO.
NOTE that the system knows only 2GSa/s is used , so cannot measure under 0.5ns thus rise time is measured as "rise<500ps"
NOTE the difference among Max, Top, and Amp measurements.
This maybe helpful to others to understand this DSO
One interesting thing I've learned while programming RUU is that the Rigol only displays 200 of the 256 possible ADC levels at any given time (mapped to the 8 vertical grid divisions) - even though the entire range is available via SCPI. My newest version of RUU (hopefully will post it tomorrow) has a 'Full ADC' switch - to allow seeing the full range.
The Rigol DS2000 will still measure and display the measurements if >top+25% and < bot-25% , and what Marmad is proposing is only in his RUU. data utility program that the Display be extended to show the complete waveform , Great Idea :) :) :)One interesting thing I've learned while programming RUU is that the Rigol only displays 200 of the 256 possible ADC levels at any given time (mapped to the 8 vertical grid divisions) - even though the entire range is available via SCPI. My newest version of RUU (hopefully will post it tomorrow) has a 'Full ADC' switch - to allow seeing the full range.I own a Agilent DSO1024A scope which is made by Rigol. One frustrating thing when viewing a signal with a large dynamic range (amplitude) was that as soon as a peak jutted out of the viewing window (either the top or bottom) then all the measurements that were impacted suddenly became "*****". So a little "headroom" above and below the displayed window in which measurements could still be taken is a good thing IMO.
I own a Agilent DSO1024A scope which is made by Rigol. One frustrating thing when viewing a signal with a large dynamic range (amplitude) was that as soon as a peak jutted out of the viewing window (either the top or bottom) then all the measurements that were impacted suddenly became "*****". So a little "headroom" above and below the displayed window in which measurements could still be taken is a good thing IMO.
Here is a 3D-plot of a frame array (RUU does this now ;) ) ]
Man what a great idea to present frames on a 3d plot!Thanks :) - it's what I've been planning with RUU all along. But since the memory read bug, I had to devise a different scheme to get to my goal. Now the software can save, load, plot, and play 'frame arrays':
Wow, great functionality and displays Marmad. :-+ :-+ :-+ :-+ :-+
Does that mean that the 3-D display function of RUU can also display the extended data values up to FF hex, (+113.5%) and still detect and show the white streaks if value is = FF (hex) at the max?
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.
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.
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).
Is RUU able to see if trigger was Auto or Normal?
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
Release Date??? ;)
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.
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 expect that alternate trigger should be in any middle class oscilloscope, am I right?
Yes, DS2000 might be good for people who work mainly with digital signals... They will never need the cursors in XY mode, for example.
I asked John South at Emona and he chased the latest firmware, and still no official date for the next update.Is it Rigol's choice to postpone your review until you'll get final firmware version?
Is it Rigol's choice to postpone your review until you'll get final firmware version?
I asked John South at Emona and he chased the latest firmware, and still no official date for the next update.
Dave.
Very nice review, thanks! :-+Thanks Uffe! And on another subject - I had a very nice unexpected surprise last week: all of my options are now official versions :)
- I had a very nice unexpected surprise last week: all of my options are now official versions :)
Congratulations! It is a nice prize about your development work!
Now I'm definitely buying one of their 4000 scopes.
If you end up with one be sure and post all about!Well I'm slightly ahead of you. A colleague bought a DS4034 a couple months ago on my recommendation, and I loaned it for a
The only new fly in the ointment is the GW Instek, which has suddenly become interesting (due to their recent IMPROVEMENT in
their communication skills). In all the years I bought their stuff, I never had a decent reply from sales / support, so I had given up
on them. Now the baskits seem to be a bit more friendly. I may wait to see how that pans out as well.
Guess May isn't that far away.
Anyway, is Rigol ever going to release the new DS2000 firmware, as they promised in november 2012, or so?
@Marmad ,Congrats on your options,
You have helped many owners and supported Rigol's DS2000 & more.
You well deserve it :-+ :-+ :-+. and maybe 200 MHz , later.
Good to see your good work rewarded. 10 Tulip rating ;)
Maybe because Dave will do a review when the new firmware is released. I am looking forward to it.Anyway, is Rigol ever going to release the new DS2000 firmware, as they promised in november 2012, or so?and why you keep posting this question over and over?
Nice work marmad on acquiring those Offcial option codes ;).
They got off cheap, they should send you a 4000 series with all the options on for all the work you have done :-+
I have no wish to offend, but must humbly disagree, linear interpolation is a very suitable alternative, either that or LeCroy got it all wrong. (I've owned a 9310M for over 10 years - they got it right!)Hi Colin,
Take the following with a grain of Rigol salt ;) but supposedly the new DS2000 firmware is due out by the end of this week.
I've heard that every week since before xmas :-DD
One of the cute things my LeCroy does (amongst many) is whenever the number of data samples per centimetre drops below 10 or so points, each individual data point is highlighted, so you can see what data points the linear interpolation is making its way through. Without having to press buttons, or interpret numbers, or switch modes, the scope immediately and visually alerts you to the fact that it is close to undersampling.That's a great idea - and I think it would be fairly easy to implement in a DSO with intensity grading. Maybe I'll try to put it into a future version of the control software I'm writing.
The lack of solid information in manuals seems to be a common problem with Chinese scopes. I get the feeling that the Chinese manufacturers are completely paranoid about competition and the theft of their ideas. They act like they are so fearful of copying that they won't even let their purchaser know how the scope works.Perhaps this is part of the problem, but I get the sense that it also has to do with providing 'extras' (more $ outlay for them) above and beyond what is strictly required to manufacture and sell the item. The same reason that most (all?) PC software for Chinese-made test equipment is crap.
The one area where it might be nice is when zooming given that the WaveJet has "only" 500K of memory and not multi megabytes - I've not used the scope enough to know if this is a practical issue or not.I think the other thread (https://www.eevblog.com/forum/testgear/does-agilent-x3000-series-use-linear-or-sin-xx-interpolation/msg213843/#msg213843) discussing this shows that it's definitely a good feature to have when zooming at slower sample rates.
File with the SCPI variables and commands (
Not in the File :SYSTEM:BRICk=on
But it happens ;D |O
Hi All - I have received the new official release firmware from Rigol today. It seems to fix some bugs and make general operation smoother. I don't currently have a list of changes but will try to find out. I'll be sending Dave a copy today. If you do update you have to follow the below method - Thanks Marmad hope you don't mind me doing a copy and paste.
I don't currently have a list of changes but will try to find out. I'll be sending Dave a copy today. If you do update you have to follow the below method
Here is the list again from FW v.00.01.00.05 - and what appears to be fixed in FW v.01.00.00.03:
Nice work! :-+
But what the heck are Rigol doing with their serial number system, can it get any more confusing?
* NEW FIRMWARE FOR DS2000: FW v.01.00.00.03 *
Where are the firmware updates located at the Rigol website? :-//
I've never looked for FW updates at their website (always got it from my dealer or other users), ...
I've never looked for FW updates at their website (always got it from my dealer or other users), but from what I understand, this is one area where Rigol could stand improvement (as well as in documentation, communication, etc. - the typical weak points of Chinese companies).
What dealers provide the firmware?
How do other users get it?
They are certainly aware of how the lack of downloadable firmware is a not a good look for them, and are working on on it.
Come-on Rigol... It only takes 10 minutes to put a few files on a server with a brick warning next to it :D
Rigol have remarked to me (not to be taken as an official reason I suppose) that they didn't think their firmware update process is robust enough yet to encourage every man and his dog to attempt it. i.e. they don't want a flood of bricked scopes or support calls coming through.
They are certainly aware of how the lack of downloadable firmware is a not a good look for them, and are working on on it.
Can someone with 2072 and new software test this setup file..
This setup file gives a DS2072 a 2 nSec timebase..
Can someone with 2072 and new software test this setup file..
This setup file gives a DS2072 a 2 nSec timebase..
What's the matter, Wim - afraid you won't be able to downgrade? ;) That's the main question - and I haven't tried it yet; still hoping Drieg will answer the question before I take the risk ;D I suspect, because of the problems with the update procedure - that it's still possible to downgrade back to 05.
Just spoke with Rick @ Tequipment who are located no more than five miles from me here on the Jersey Shore.
Rick contacted Rigol N/A and the word is: Not released to the US yet 'It's coming around the World' and it may take up to 30 days before we see it.
Registered owners will receive an email blast when it's released for your geolocation.
Regards,
PeterV [REN] WB3FSR
Ha! It goes around the world in about 5 minutes. ;D
I am looking for a new scope and thanks to this topic I am considering the DS2000 series.
I have not yet decided if the higher prices for the DS2102/2202 models are worth to closer look at them.
Besides the obvious higher bandwidth and the better probes, are there any helpful advantages/things to take in consideration?
Dear firmware fairy, please visit. :-/O
Can someone with 2072 and new software test this setup file..
This setup file gives a DS2072 a 2 nSec timebase..
What's the matter, Wim - afraid you won't be able to downgrade? ;) That's the main question - and I haven't tried it yet; still hoping Drieg will answer the question before I take the risk ;D I suspect, because of the problems with the update procedure - that it's still possible to downgrade back to 05.
Maybe they disabled their RTC... :palm:
Oh, they have a different calendar.
Updated (per marmad): :scared: :scared:
Can someone with 2072 and new software test this setup file..
This setup file gives a DS2072 a 2 nSec timebase..
Rick contacted Rigol N/A and the word is: Not released to the US yet 'It's coming around the World' and it may take up to 30 days before we see it.
Can someone with 2072 and new software test this setup file..
This setup file gives a DS2072 a 2 nSec timebase..
It doesn't work on the new firmware. "File version doesn't support!".
the dance worked, thanksCan someone with 2072 and new software test this setup file..
This setup file gives a DS2072 a 2 nSec timebase..
It doesn't work on the new firmware. "File version doesn't support!".
I guess kind of like "All your bases are belong to us!" >:D
So then also your former setups, if ever used wont work anymore.
They changed the layout.
Did you use any setup files before, or other saved files, that wont work..??
So then also your former setups, if ever used wont work anymore.
They changed the layout.
Did you use any setup files before, or other saved files, that wont work..??
Saved picture looks like this now:
Why would I want my serial number attached to an image I'm going to presumably show others? Stupid.
Well, what's the problem with the rise time bug? I don't understand it...
also it stopped printing S/N and time on top of the pictures
I intalled back the new firmware. In the picture is antisymmetric ramp wave. Rise time and fall time are both 160 ns! |O |O :-//
I intalled back the new firmware. In the picture is antisymmetric ramp wave. Rise time and fall time are both 160 ns! |O |O :-//
What caused it to stop - or - how many saves did you do before it stopped?
I closed the scope and started it again and now it works correctly!!!! :-+ :-+ :-+
very strange, the only difference is that yours is 2202. I've tried again and it shows different raise/fall. Where does it place the markers if you switch to fall mode?
Yes, I confirmed the bug. I think the Rise time is actually just the Fall time repeated. In fact, if you chose either Rising Edge or Falling Edge with Auto cursor - it goes to the same edge.
It seems like it might be an easy bug to fix (pointer problem, etc) - I wonder if we can get Rigol to do it quickly?
It seems that it helps, if the scope is started again with same setup!!??? :-// :-//
BTW, can you please post your 2ns setup file, I'll see if it works here with raise/fall times ;) ;)
No, I don't think so - I've had the new firmware for 12 hours - turned it off and on several times.
And I think I just found another measurement bug.... :(
Look at the displayed measurements of these two images - the only difference between the two is that I deleted the Width measurement on the 2nd image. Should the DSO not measure Rise and Fall just because it can't do Width?
I see that it was a good idea to buy a DSO-X 2002A instead.
But somebody might need the 7Mpoints per channel of DS2000. :-//
OK, I have used this new firmware only two short times. These are anyway new bugs.
Nice scope! Cursor Dx has 7 digit precision!
I see that it was a good idea to buy a DSO-X 2002A instead.
also it stopped printing S/N and time on top of the pictures
I've only seen one new bug.
No same rise & fall bug. I hate the white top with the Model# S/N and date-time on a saved screen. It should have been optional and only for user description/comment. On the older non 3D RUU it chews the bottom space even. On newer RUU it saves as a whole. Here is a screenshot (I cropped out the white top tag).
We need to give something back to Rigol for the money they saved us. So we are doing a volunteer Beta testing program for them. Fair enough... I guess.
@Marmad
Have you raported the bug to Drieg or Rigol? I can not use the scope today. No new bugs has appeared? :-+
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?
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'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.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.
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.
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.
Hi All - Rigol are looking at another firmware release in about 2 weeks. This will fix the measurement ,and hopefully other , bugs.
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.
Hi jpbQuoteI 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
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? ;D 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.
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.Thank you jpb it is very useful readings!
http://cdn.teledynelecroy.com/files/whitepapers/wp_interpolation_102203.pdf (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.
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.
Here is firmware upgrade procedure from Rigol:Yes - the same one as here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684).
To update your oscilloscope's firmware, do one of the following:There is even no talk about the uninterruptible power supply. No instrument damage warning. Probably Agilent uses an advanced firmware protection or something.
Place the file on a USB flash drive, connect it to the oscilloscope, press [Utility] > File Explorer, select the file; then, press Load File.
If your oscilloscope is on the network: you can place the file on your computer, access the oscilloscope's Web Interface (see the User's Guide for details), click Instrument Utilities, select Firmware Version, browse to select the file; then, click Install.
After your oscilloscope's firmware is updated, check the calibration status: press [Utility] > Service > User Cal Status. If "Results: OK" is displayed, you do not need to recalibrate. If calibration is required, press the Start User Cal softkey.
Firmware upgrade of Agilent DSOX2000 series is much more simple... http://www.home.agilent.com/agilent/software.jspx?ckey=2014479&lc=eng&cc=CZ&nid=-33575.970747&id=2014479 (http://www.home.agilent.com/agilent/software.jspx?ckey=2014479&lc=eng&cc=CZ&nid=-33575.970747&id=2014479)QuoteTo update your oscilloscope's firmware, do one of the following:There is even no talk about the uninterruptible power supply. No instrument damage warning. Probably Agilent uses an advanced firmware protection or something.
Place the file on a USB flash drive, connect it to the oscilloscope, press [Utility] > File Explorer, select the file; then, press Load File.
If your oscilloscope is on the network: you can place the file on your computer, access the oscilloscope's Web Interface (see the User's Guide for details), click Instrument Utilities, select Firmware Version, browse to select the file; then, click Install.
After your oscilloscope's firmware is updated, check the calibration status: press [Utility] > Service > User Cal Status. If "Results: OK" is displayed, you do not need to recalibrate. If calibration is required, press the Start User Cal softkey.
Firmware upgrade of Agilent DSOX2000 series is much more simple...
Same on the Instek. :P So there. epeen! epeen!
Ok, I'm convinced! The huge 'difficulty' of upgrading firmware is the last straw. ;D I'm selling my Rigol DS2000 and buying a less powerful Agilent DSOX2000!
There is even no talk about the uninterruptible power supply. No instrument damage warning. Probably Agilent uses an advanced firmware protection or something.
*** The trail options DO NOT disappear anymore after a self-cal, they where there again
before and after i had my 1703 minutes left...
The header on the top of a print screen can be changed a little by changing some setup
see attached file, where now the date is left out. It seems they put the para.txt in the file.
Other people dont get it back, but on my machine...it is strange it did not happen on my DSO ?????
RS233 Options
Does anyone know it there is any differences in the functions of
the RS232 Decode function:
on the DS2000 at $222
on the DS4000 at $500
on the DS6000 at $750
Are the functions just crippled by menu items???
EDIT: I think the header is there for factory use, after some time it disappear, normally in the factory
they make a print screen for admin. After shipping it is gone by time.
UPDATE, a second self -cal and the options are gone... |O
Totally, even the option box is grade out.... |O
What's DS2000-S series?Looks like a 25MHz signal generator added internally to the DS2000: http://cn.rigol.com/download/China/DS/Datasheet/DS2000_DataSheet_CN.pdf (http://cn.rigol.com/download/China/DS/Datasheet/DS2000_DataSheet_CN.pdf)
Anyway, I like the DS2000's easy replaceable fuse. Most scopes have the fuse inside, often even solderer (Tek DPO2000, DSOX2000...)
Number of Channels 2
Sampling rate 200MSa / s
Vertical resolution of 14bits
Maximum frequency of 25MHz
Standard waveforms sine, square wave, pulse, triangle wave, noise, DC
Arbitrary Waveform Sinc, the index rose, the index fell, ECG, Gauss, haversine
The sinusoidal frequency range from 0.1Hz to 25MHz
Flatness of ± 0.5dB (relative 1kHz)
Harmonic distortion of-40dBc
Spurious (non-harmonic)-40dBc
1% total harmonic distortion
Signal-to-noise ratio 40dB (TBD)
Square / pulse frequency range of 0.1Hz to 15MHz
Rise and fall time <15ns
Overshoot <5%
Duty cycle of 10-90%
Duty cycle resolution of 1% or 10ns (whichever is the greater value)
The minimum pulse width of 20ns
Pulse width resolution of 10ns or 5 (whichever is the larger value)
Jitter 500ps
Triangle wave frequency range of 0.1Hz to 100kHz
Linearity 1%
Symmetry 0-100%
Noise bandwidth of 25MHz (typ)
Arbitrary wave frequency range of 0.1Hz to 10MHz
Waveform length 2 ~ 16k points
Internal storage of 4
Frequency accuracy of 100ppm (less than 10kHz) 50ppm (greater than 10kHz)
Resolution of 0.1Hz or 4, whichever is greater
The amplitude output range 20mVpp ~ 5Vpp, high impedance 10mVpp ~ 2.5Vpp, 50ohm
The resolution 100uV or 3, whichever is the greater value
Accuracy of 2% (1kHz)
DC offset range ± 2.5V, high impedance ± 1.25V, 50ohm
The resolution 100uV or 3, whichever is the greater value
Accuracy of 2% (1kHz)
Looks like a 25MHz signal generator added internally to the DS2000:
Seriously? You think that's how the image would look if connected with straight line segments? With 5 sample points per division? ;D Well, here it is for you - un-interpolated. Print it out, get out a ruler and pencil, and give it a go ;)What? Of course seriously! Did you think I was trolling you or something?
I guess that's what it boils down to! I was expecting that the interpolation's synthetic sine would be pretty faithful, but I guess there's some rounding or error accumulation or whatever that causes it to flatten up at that aspect ratio. Interestingly, Teneyes' 6pt has just a couple pixels more per period, but the sine looks much better.Quote...and it looks a bit funny for a perfect sin.There is no such animal.
The peaks obviously aren't pointy enough, but If those lines just continued straight for a few more pixels then the whole thing would basically be straight line segments.I just took the sample points image into Photoshop and connected the first few segments. I don't really think you could mistake the difference between this and sin(x)/x interpolation - although granted, it would perhaps be more obvious if the sine wave cycles were bigger (shorter timebase).
I'm not sure if the DS6000 Demo Board has been mentioned before on EEVBlog or not (a quick search didn't turn up anything), but I found it at Batronix while searching for any possible new UltraVision products - and I hadn't seen it before and thought it was kind of interesting. It lists at €163 / $225 (excl.), and I've attached the user guide below.
Rigol are supposed to be getting me one of those, looks interesting.
They should most certainly get you one too!
I'm not sure if the DS6000 Demo Board has been mentioned before on EEVBlog or not (a quick search didn't turn up anything), but I found it at Batronix while searching for any possible new UltraVision products - and I hadn't seen it before and thought it was kind of interesting. It lists at €163 / $225 (excl.), and I've attached the user guide below.
"This Demo board is used to illustrate the basic functions of the oscilloscope. It is powered through USB port and can output 25 kinds of signals for the illustration of oscilloscope functions, i.e. sine, video (PAL/NTSC), AM Modulation, Sweeps, many digital signals and lots more. Delivery including Demo Board, USB Cable, CD with manual."
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=44584)
I just took the sample points image into Photoshop and connected the first few segments. I don't really think you could mistake the differenceObviously not those sample points. I didn't have access to them at first, and even now I have no reason to think they match exactly with the vector capture. The trigger setting is different, and dots/vectors trigger a little differently.
Obviously not those sample points. I didn't have access to them at first, and even now I have no reason to think they match exactly with the vector capture. The trigger setting is different, and dots/vectors trigger a little differently.The trigger setting didn't really matter - here's another image I just captured of the same 100MHz uninterpolated sine wave (sorry - slightly less amplitude due to a loose 50 Ohm terminator) with the trigger set to the previous 180mV level. It's almost the same image as before - with the dots just shifted horizontally.
Compare the peak from your interpolated capture with one that has plenty of data and see how much rounder the correct curve is!DSOs are imperfect devices - and besides doing the sin(x)/x interpolation, the scope is doing other transformations to the sample data to get it to the display (e.g. the Rigol is mapping 200 bits of vertical ADC resolution to 400 pixels of vertical screen resolution). Perfectly correct curves may or may not be precisely what you see on the display - although with a small number of sample points, the difference between linear and sin(x)/x interpolation is pretty noticeable.
If I then chop off the pointy bit, I get something very similar to your capture (effectively adding just one more sample per peak.)Well sure, adding sample points in convenient locations can definitely help linear interpolation look more like sin(x)/x. ;) But in any case, to me, the difference between your linear interpolation and the 'bad' curve is still noticeable - one looks like straight vectors and the other looks like less-than-perfect curve fitting.
But either way, sorry to ask and I won't take any more of this long thread with what's way off topic.It wasn't any problem to ask, and I don't think it's off topic since it's about the Rigol's interpolation (and I brought it up in the first place). I was just surprised at the question - and I thought I answered good-naturedly with a bit of ribbing - while trying to point out that, IMO, it would have been clear if linear interpolation had been used on that waveform with 5 points per div. - even though, as I mentioned in my later post, I understood your point and conceded that it would have been more clear if I had used a lower frequency sine wave in the example. :)
The procedure is still the same.
Hello
my DS2072 saved screens on the flash as .trc files. Searching all inet I have no idea how to work with it.
Does anybody know what it is? Example in attachment.
Thanks in advance,
Vladimir
On arrival users want to do a self-cal, but the next time you do a self call is much much later,
then your options are long ago expired..., so it is a real solution..., good thinking from Rigol.
On arrival users want to do a self-cal, but the next time you do a self call is much much later,
then your options are long ago expired..., so it is a real solution..., good thinking from Rigol.
1) This is not a solution - it's a bug that hasn't been fixed. Self-calibration should not affect trial minutes not matter how many you do.
2) As mentioned before, I installed a brand new trial license key - did one self calibration - and the trial minutes were erased. So this does not work in every situation.
3) Until more is known about the parameters, self-calibration is still not something I would recommend new users do - unless they have a spare trial license key or until their trial minutes are gone.
A bug is when you made a mistake in your software. But i am not sure it is a mistake.
Also they did not tell anything about it in the release note, which is very strange.
Why is it all in chinees..,Image is from Chinese document - Rigol always releases new products first in China (more 'beta' testing ;D ) before Western markets.
Maybe we have to solder in two BNC plugs on the back side.., have to look on DavesI was looking over Dave's photos last night; I couldn't see any obvious DDS circuitry, but there is certainly space for a daughterboard. One bad thing though - the new DS2000-S series has a button on the front panel that isn't on the normal DS2000 series.
teardown, to see if there is already something on the circuitboard..to connect to
I was looking over Dave's photos last night; I couldn't see any obvious DDS circuitry, but there is certainly space for a daughterboard.
In the service menu, key test, there are two keys i can find on the front,Interesting. It shows the button as being here on the front panel:
one is called LA and the other is indeed Source
In the firmware all the commands are there for the AWG.I mentioned in a previous post that I think all commands necessary for an LA are also already in the firmware.
Put Logic Analyzer features roughly the equivalent of the external units we have been discussing (with triggering, protocols, etc.) in the $300-$400 range into the 2072 and you get a very popular configuration. Just saying.
Why is there only one conductive rubber dot at the Clear and Auto button? It's not good!
So we need to get two extra buttons somewhere! :)
So we need to get two extra buttons somewhere! :)
With the new firmware, this has gotten me curious as to whether shorting the 'Source' button position will pop-out the AWG side menu... perhaps it's time to finally open my DSO. ;D
And the Metal case is Ready for BNC outputs,
But does Not look like an Add-on board :(
Not only are there holes in the front panel for the two buttons, the keypad PCB is already laid out for the two additional (illuminated) buttons:I like the metal encoder spindles. :-+
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=45117)
Are you able to obtain waveform data that is 2GS/sec ? Everything Ive tried results in a file containing 1GS/Sec data. Ive set horizontal to max, memory depth to 56Mpoints, 14, 1.4, aliasing on and off - scope says 2GS/Sec on the display but always outputs 1GS/sec to the wavefile. Acquire mode is normal.
To check the scope. It "seems" to be sampling at 2GS/sec. I generated a 10 - 950 Mhz sine wave sweep at -20dBm and it displayed it on the FFT. Its a bit iffy above 200 Mhz.
BTW. Does anybody succeed with Rigol support. I sent numerous mails to support@rigol.com and from the feedback form from Customer Center. It seems they are in permanent meditation or dead.
Are you able to obtain waveform data that is 2GS/sec ? Everything Ive tried results in a file containing 1GS/Sec data. Ive set horizontal to max, memory depth to 56Mpoints, 14, 1.4, aliasing on and off - scope says 2GS/Sec on the display but always outputs 1GS/sec to the wavefile. Acquire mode is normal.
To check the scope. It "seems" to be sampling at 2GS/sec. I generated a 10 - 950 Mhz sine wave sweep at -20dBm and it displayed it on the FFT. Its a bit iffy above 200 Mhz.
To check the sampling rate, all you have to do is STOP acquiring when it displays '2GSs/s', then change the timebase to the smallest possible (e.g. 5ns), switch 'Display' -> 'Vectors' to 'Dots', then count the actual sample points. 2GSa/s means a 500ps acquire time for the ADC, so at 5ns/div, you should see 10 dots per div. If you don't, then I would imagine you have a technical problem.
Theres two possibilities, 1. the scope does decimate and saves 1GS/sec waves, or 2. the tool Im using to view the waveform is parsing the binary data incorrectly. I noticed the wfm file for the DS2072 isnt the same as the DS1052E. It contains preamble. Either case Ill check with the baudline author.I'm guessing it's almost certainly #2 - there wouldn't be any logical reason for #1 (except a bug). And yes, the WFM format has been drastically changed - and there is no published documentation about it - typical Rigol/Chinese behavior which pisses me off. And they appear to have changed it even some more in the latest firmware version (01.00.00.03)!
Thanks for answer, marmad.BTW. Does anybody succeed with Rigol support. I sent numerous mails to support@rigol.com and from the feedback form from Customer Center. It seems they are in permanent meditation or dead.
From what I've read, people have had varying levels of success. In some areas, it seems Rigol is quick and responsive to their customers - in other areas, not so much. I've had success communicating to Rigol through my dealer - which is sometimes the better path to take than directly.
So, if I am a registered customer, why I could not get the support from the only place where I registered?
BTW. They suggest me to visit their Munich office :)
I do agree, Mark. But if so, why not to make a separate topic for FW updates to put there FW files. Because now everybody here need each time to ask his dealer for help.
Well, that's one reason the Rigol (and Hantek and Owon and Siglent) threads are so numerous (and often large) in this forum - because we (the owners/users of the equipment) are offering support to each other to make up for a deficiency from the manufacturers. If the Chinese companies provided better documentation and software for their devices - as well as a speedy, reasonable level of after-sales support, many of us would probably spend a lot less time here :)
Theres two possibilities, 1. the scope does decimate and saves 1GS/sec waves, or 2. the tool Im using to view the waveform is parsing the binary data incorrectly. I noticed the wfm file for the DS2072 isnt the same as the DS1052E. It contains preamble. Either case Ill check with the baudline author.I'm guessing it's almost certainly #2 - there wouldn't be any logical reason for #1 (except a bug). And yes, the WFM format has been drastically changed - and there is no published documentation about it - typical Rigol/Chinese behavior which pisses me off. And they appear to have changed it even some more in the latest firmware version (01.00.00.03)!
We are currently working on documenting the format - so that conversion routines can be written.
BTW, if you want to know what version of firmware you're running, you need to use a specific sequence of buttons. Read the instructions at the bottom of this post (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684).
Are you saying the DS2072 is same hardware as DS2200 and only needs sofware to get 200MHz bandwidth
The insides should be the same.
Evan Cirelli,, sales team, VP and co-founder of TEquipment.NET
Hi Evan ,
Are you saying the DS2072 is same hardware as DS2200 and only needs software to get 200MHz bandwidth? ??? ;D
Heres a plot of the DS2072, captured via usbtmc piped into baudline, Hz = Mhz in this case. Waveform averaging is enabled vertical at 2mV/div. 2GS/Sec sampling.
All total nonsense.
@MikeR
What was your time base set at? (100ns/div?)
Probably :)
Was the frequency generator sweeping?
No manual stepping at 10Mhz
Does Baudline use multiple display waveforms or just just one?
It supports multiple inputs and channels. From STDIN, the channel data needs to be interleaved
chan1,chan2, etc
The Averaging by the Ds2072 during a sweep must have an affect.
It will, the longer dwell per step increases the snr due to the averaging, the steps here were
roughly timed to be similar - but not perfect hence my last comment.
The time base setting will affect the number of Samples and thus your data used by baudline
I now realize this thanks to your help.
-Cheers,
-Anyhow the .wfm file format is rather odd, baudline is able to parse unsigned bytes easily - it will display the spectrum showing e.g radio channels in the right places but only for sample rates set to 1GS/Sec, the file was captured at 2GS/sec, if I load that setting the sample rate accordingly they are in the wrong "spot" suggesting the original data isnt 2GS/sec.
-Anyhow the .wfm file format is rather odd, baudline is able to parse unsigned bytes easily - it will display the spectrum showing e.g radio channels in the right places but only for sample rates set to 1GS/Sec, the file was captured at 2GS/sec, if I load that setting the sample rate accordingly they are in the wrong "spot" suggesting the original data isnt 2GS/sec.
Why would this be your conclusion? That equipment programmed to write it's own invented file format isn't doing it correctly? But that the third party software IS reading the file correctly?
As I mentioned already, the format described in wfm_view and other online sources for the DS1000 series is not valid anymore. The locations in the header of pertinent information (sample rate, sample size, etc) - and the manner in which the DSO stores sample data has been altered quite substantially. It's likely that with 2GSa/s the Rigol is storing the data in a different fashion than with 1GSa/s - since the 2GSa/s setting was not available in the DS1000 series. No one has published specs on the new format yet - or written any readers. My Rigol doesn't have any problems writing - and then later reading - a 2GSa/s WFM file - so clearly the fault is in the software. So, instead of claiming, as you did first, that the Rigol wasn't sampling at 2GSa/s - or secondly, that the Rigol isn't writing the 2GSa/s to the file (both of which are easy to prove otherwise) - you should be studying the new format and discovering the changes so that you can get Baudline to work correctly.
I haven't "claimed" anything here just stated my ongoing observations.
It "seems" to be sampling at 2GS/sec.and
...suggesting the original data isnt 2GS/sec.
Which stands currently that the 2GS/s wfm file when loaded into baudline only seems to be at 1GS/Sec
I haven't "claimed" anything here just stated my ongoing observations.
You wrote:QuoteIt "seems" to be sampling at 2GS/sec.andQuote...suggesting the original data isnt 2GS/sec.
Both of those 'observation' were implying that the Rigol was doing something wrong - when it was ridiculously easy to prove that it was doing those things correctly with simple experiments - and thus Baudline was at fault .QuoteWhich stands currently that the 2GS/s wfm file when loaded into baudline only seems to be at 1GS/Sec
Yes, because Baudline is obviously reading the file incorrectly.
Well not really, my understanding was incorrect. Baudline was reading the file correctly it was just in the wrong order / format.
I do agree, Mark. But if so, why not to make a separate topic for FW updates to put there FW files. Because now everybody here need each time to ask his dealer for help.
Does anyone know why these DS2072 scopes are completely unavailable from any US sellers? It seems they have been out for more than a year, and although I can find dozens and dozens of shops selling the DS1052, I can't find a single one who has any DS2072's.I got mine from Tequipment with no difficulty in January and I believe many others have ordered and received since then. Where are you trying to order from, and have you contacted them and asked why it's unavailable?
Does anyone know why these DS2072 scopes are completely unavailable from any US sellers? It seems they have been out for more than a year, and although I can find dozens and dozens of shops selling the DS1052, I can't find a single one who has any DS2072's.
Is there a problem with them? Is it being discontinued or replaced? Can't figure how they could be as scarce as hens teeth after more than a year on the market.
Many of the owners here bought it from Tequipment or other places in the US until very recently. So I would imagine there's just a backlog at the moment.
Tequipement had a 6 week wait but not any more. and often w/discount.
PM Tequipment on EEVBLOG, he is VP.
https://www.eevblog.com/forum/chat/special-price-for-eevblog-members/msg212809/#msg212809 (https://www.eevblog.com/forum/chat/special-price-for-eevblog-members/msg212809/#msg212809)
I just got off the phone with TEquipment and they have none and have a waiting list of people - their website says 4-6 weeks, as does Rigol's website.I'm guessing that this backlog of orders probably started suspiciously shortly after Mr. Dave Jones published "EEVblog #451 – Rigol DS1052E vs DS2072 Oscilloscope" (https://www.eevblog.com/forum/blog/eevblog-451-rigol-ds1052e-vs-ds2072-oscilloscope/) ;D
There are also none for sale on any US site, or even on eBay. There are 2 on eBay, all being shipped from China suppliers, and being sold for 40% above MSRP.
I ordered mine from tequipment in early March, and at the time was told the 2072 was on a 2 month back order. I opted for the 2102 because I could.
Now that we know a SigGen option is in the works, I wonder if production hasn't been paused for awhile waiting for the new boards?
What is a "sig gen option"? I haven't heard about that... is there going to be a waveform generator option for a newer revision of these scopes? :oIt's not clear if it's going to be an option - or just another set of models (DS2000-S series). There is info in this thread. (https://www.eevblog.com/forum/testgear/new-rigol-ds2000-s-series-with-built-in-dual-channel-25-mhz-awg/)
From Tequipment catalog:
Model
DS2072(70MHz,2-Ch Scope)
DS2072-S(70MHz,2-Ch Scope + 2-Ch 25MHz Waveform generator)
DS2102(100MHz,2-Ch Scope)
DS2102-S(100MHz,2-Ch Scope + 2-Ch 25MHz Waveform generator)
DS2202(200MHz,2-Ch Scope)
DS2202-S(200MHz,2-Ch Scope + 2-Ch 25MHz Waveform generator)
It's not clear if it's going to be an option - or just another set of models (DS2000-S series). There is info in this thread. (https://www.eevblog.com/forum/testgear/new-rigol-ds2000-s-series-with-built-in-dual-channel-25-mhz-awg/)I am afraid that it will not be a option that can be added to an older DS2000 series scope.
Nobody knows anything for sure. And there are already plans made by some people to look into a retrofit if it's not something offered by Rigol.It's not clear if it's going to be an option - or just another set of models (DS2000-S series). There is info in this thread. (https://www.eevblog.com/forum/testgear/new-rigol-ds2000-s-series-with-built-in-dual-channel-25-mhz-awg/)I am afraid that it will not be a option that can be added to an older DS2000 series scope.
Im happily reading 1400,14000,14K, and 14M Points via LAN and USB interfaces with firmware FW (01.00.00.03) not at the same time obviously. - Using Linux USBTMC and via the LAN.
Or does turning on the 2nd channel cause all hell to break loose? which was the point of the bug report...
My result
Please report back findings here for compilation and delivery to Rigol.
My resultThanks, Evi! Are you using USB or LAN connection?
Love this scope.Welcome to the forum as DS2000 owner. Yes, Drieg is a great person/dealer to do business/communicate with.
Glad that i stopped a Owen order and go for this DS2.
http://www.silcon.cz/ (http://www.silcon.cz/) is a Verry good place to buy from.
My resultThanks, Evi! Are you using USB or LAN connection?
What is the delay from External Trigger in to Trigger Out?
So External trigger has different processing (more direct route, faster software routine) to display and output (trigger)
Does that say the ASIC takes 60nsec to process?
Is it different at Higher Scan rates; less samples?
External trigger is most likely an Interrupt into the Main processor.
Would Triggering on Ext. change the update rate?
I suppose One could offset the Trigger position to the left of the Screen , and still see the Trigger output step (ie. 14 x 20ns=280 nS)
Measuring the Trigger Output delay of the Rigol. Here it is fed back into channel 2, and it appears the delay is ~220ns:Is 220ns a good result?
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=46005)
Did the traces always have the 250ps spacing? some sort of Discrete timing resolution
250ps corresponds to 4 Ghz , is that the CPU clock rate ? (different memory access delays)
Does that spacing change with different trigger input frequencies, I suspect NOT
With DPO intensities do some traces occur more often?
But I do not think the Stability of the 1 Mhz trigger input signal frequencyI had forgotten, but this 8ns jitter was already mentioned by member pena here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg185313/#msg185313) - so I don't think it's related to the trigger input stability. Also, EV tried already to measure the rise time, and found it was at least 1.05ns.
Maybe someone has a stable 10 MHz rubidium source (@EV) to do this same test :)
Since it's clear from EV's old posts (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg185397/#msg185397) that the slew rate is VERY fast on the Trigger Out, perhaps the jitter is due to that.
1) Horizontally the dots are spaced 200ps / 5GHz apart. That's significantly faster than my 1GHz sample rate. That suggests the ADCs might support timing much finer than the sample rate, which might mean the hardware is capable of equivalent time sampling.
Marmad, might you could give us a screen shot of the trigger pulses on dots mode at 2ns/div?
IF one was to record 32 frames , would there be a regular pattern or random positioning of the traces within the 8 ns ? I think a 3-D plot in ZT would be interesting.
Yes , I was thinking about that and think that if One feeds in Only a slow square wave = 1/2 the update rate and in NORMAL trigger.
Does minimum Hold-off have an effect? (the HOLD-Off clock resolution )
Also does this 8ns occur when triggering is from Ch1 or Ch2, not sure of EV's CH1 display.
Who was that on EEVBLOG that has a DS4000?
Who was that on EEVBLOG that has a DS4000? (Please forward)
I wonder if this variations on the Trigger output also happens on the DS4000 series?
QuoteWho was that on EEVBLOG that has a DS4000?
Not sure, if he visits Eevblog, but it should be this man called Connor Wolf:
www.youtube.com/watch?v=id9YcpP6My4 (https://www.youtube.com/watch?v=id9YcpP6My4#ws)
www.youtube.com/watch?v=_J1pVlqMIHM (https://www.youtube.com/watch?v=_J1pVlqMIHM#ws)
I wonder if firmware would be able to set a fix delay, say 230ns for CHs and 175ns for EXT-IN. or is it just a race
(nops , in firmware to pad timing)
So, in order to build a MSO based on this DS2000, it sure is going to be Problematic for sync-ing.
The Chump seems to have it and maybe AndyC_772.I have a DS4054 at work, which I could probably have a play with if you like.
I have a DS4054 at work, which I could probably have a play with if you like.
My own scope is an Agilent MSO-X3054A, and I couldn't resist comparing it... trigger event to trig out delay is 27.6ns, and the jitter on the trig out pulse is about 200ps peak-to-peak, though the scope isn't really able to measure such small amounts with any degree of accuracy.
It was about 1.2 ns when trigged to CH1.
Thanks Andy if you could test the DS4000, off company time :)
The Agilent does it faster
Was there any difference in the delay between channel triggered and External triggered,
memory depths?
Auto and Normal triggering?
Two quick questions: is the delay you measured from triggering on a channel input or external trigger in?See above; channel trigger looks to be a fraction faster. (Interestingly, I've just measured it again and it's come out at 30.2ns - maybe I have a little channel-to-channel skew to calibrate out, or I'm just tired at the end of a busy day and my experimental technique isn't at its sharpest. Apologies).
Also, I've been reading a lot about the X- Series recently - trying to figure out Agilent's specifications for the memory usage (which ain't easy). From what I understand from their specs (assuming you don't have the 2MB Mem upgrade), if you're running all 4-channels simultaneously in Auto/Normal mode - you have 250kB per channel. Is that correct? Or does the halving of memory during Normal mode affect just a channel 'pair' (i.e. 500kB)?
Have you verified actual memory amounts when stopped (since Agilent is obviously fairly cagey in this regard; i.e. no tables anywhere in all of their literature)?
It was about 1.2 ns when trigged to CH1.
Isn't that when you had it triggering itself?
I see the same 8ns when triggered from Ch2 with 1MHz sine.
Yes, it was triggered to itself, but it is also same, if it is auto triggred and the trigger level is outside the trace. I get 8 ns only with external trigger.
I have the 4M memory upgrade. With just ch1 enabled, I can capture 500us worth of data @ 4Gsa/s before the sample rate starts dropping (2M points), and with ch1 and 3 enabled I can capture the same (ie. total of 4M points split across the two channels).
I get 8ns in Normal mode with either channel or external trigger - which is the way I generally use the DSO.
I can see that If Trigger out is connected to Ch 1, and in Normal trigger there would NOT be a trace, But what if you pressed the "Force" button to get the feedback going??
Hi All - Rigol are looking at another firmware release in about 2 weeks. This will fix the measurement ,and hopefully other , bugs.
Any news about the fix yet?
This suggests to me that a software upgrade is definitely feasible for Rigol to offer. I'd expect to see one coming.
Did anybody who open the case mark down the type and brand of the cooling fan?
The fan is quite small.
Compared to DSOX2000, Tek DPO2000 or even Rigol DS4000. Well not a big issue.
DS2072 and DS2102 are presumably identical except for the 2ns timebase, given the tested -3dB response of the DS2072 and the fact that only the 100MHz PGA filter is engaged for bandwidth limiting?? I thought, the DS2102 does not have the 2ns timebase - or am I wrong?
?? I thought, the DS2102 does not have the 2ns timebase - or am I wrong?
Peter
I have a DS2072 and am finding I may have a need to do CAN decoding. It appears this is not available on the DS2000 Series, but is available on the DS4000 series.It can be done in software with exported data of course. Maybe Marmad one day includes it in his, maybe somebody else writes some piece of software which analyzes the Rigol export data.
I'm wondering what the chances are that CAN decoding will become available on the DS2000 series?
The price is a little scary. At least it's not as scary as Flexray!
http://www.tequipment.net/RigolSD-CAN-DS4.html (http://www.tequipment.net/RigolSD-CAN-DS4.html)
The self-cal bug is mentioned several times in this blog, you can ask your dealer for a replacement code.
or read the blog again. :)
Note: If you do this wrong you will lose your trial options - so be patient and take the time to do it right!
Do the upgrade ONLY during bootup - not from the GUI/Menus/OS asking for file/etc. or you will lock up the scope - losing any trial options you have remaining - and requiring you to do the upgrade again anyway using the method listed below:
You do this by using two hands when booting up - one thumb on the 'Power On' switch - one thumb on the 'Help' button. When you press 'Power On', all of the scope LEDs will light for ONE SECOND - during that brief period, you must PRESS AND LET GO of the 'Help' button. It can be a little tricky, but if it works, bootup will stop before the Rigol logo with the 'SINGLE' button lit (if it doesn't, turn off power and try again until you get it). Then insert the USB stick with the file on it. The CH1 LED will flash as the DSO loads the file.
Once updating is finished, several of the LEDs will light up - and all flashing, etc. will stop. That's it! Remove the USB stick and reboot, and check your firmware version using the method listed above.
I would NOT expect new firmware for quite a while.
am I to understand that if you hose up your trial options, flashing firmware with this method will restore them?
I like the hires modus. But the 400 pixels are not enough to display all the 12 bits. Is there a vertical zoom? How can one get full benefit from the hires modus?
Thanks in advance
egonotto
Have you tried feeding back the "Trigger out" fast pulse to test?
Here are rise times of my DS2202 measured from trig out and risemime tester MK2 signal.
@TP
I went back and re- read your post on Hi Res and other problems
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg172191/#msg172191 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg172191/#msg172191)
And I wonder if you agree that the DS2072 has more Bandwidth than 70MHzInputting a pulse that should have a rise time of 5 ns (according to the specs for the chip I used) gives a rise time of 7.1 ns on the scope. That means the scope rise time is 5 ns which matches the 70 MHz spec.
Have you tried feeding back the "Trigger out" fast pulse to test?
So what exactly is the point of the DS2102?
Hi,
@TP: Thanks for the hint. But you can not go below 500uV. I think here is yet a improvement in the firmware possible. I will try this with the sample data on PC.
Unfortunately when I checked the data saved on a USB stick (CSV format) it was 8 bit quantized even when it had been taken in HiRes mode. I don't know about data transfered directly to the PC via USB or Ethernet (say using Marmad's program).
Hi
I think one has to do the hires in PC. Perhaps one can find a better algorithm as boxcar.
In PC you have more processing power and more time.
Hires is a kind of low-pass filter. Perhaps I have soon time to introduce me in digital filter.
Best Regards
egonotto
Ha, ha ;D When I just sent my DS2000 a SCPI command to make the DSO enter Logic Analyzer (LA) mode, it responded with the following message:
I had so far with the new software two hang ups, when i used the horizontal trigger
knob. To scroll left and right on 5 nSec timebase.
Could not reproduce it yet, turn it off and on again, everything was oke again.
Anyone who has same ...??
I think you need to be a button sniper or something to be able to select the *.trc :)
I don't understand what you mean by playing the mp3. I didn't realize it even had a speaker??
Play it and you'll understand.
Rigol might be a top class brand in year 2023 or so.
'*.trc' is not an 'Easter Egg'-like symbol.
It's not selectable.
The DSO can't play mp3 files.
Rigol wouldn't use well-known, copyrighted music.
Joke, guys - joke. Sheesh.... although I have to say, I had a good laugh yesterday thinking of some of you frantically trying to select the unselectable. ;D
Rigol is already a top-brand - since the DS2000 is a much better DSO.Well, OK. ^-^ If you need a long memory + segmented memory with about 65000 frames or so, you must choose Rigol. And 0,5mV/div might be also useful.
Geez... And to think I trusted you. You little tinker :D
Geez... And to think I trusted you. You little tinker :D
Yes, I didn't realize that other users might just try to replicate the results on their DSO - instead of just playing the file (which was so obviously stupid that I was sure it would be recognized as phony). I felt guilty for awhile... but did imagine withe some amusement the various attempts to select '*.trc'. :)
hehee ;)
hehee ;)
If Rigol gives me a SCPI command to control the frequency (and length) of the beep, I will make it play that tune when you start RUU! ;)
DS2000-S will be definitely better (hardware) than DSOX2000. But when will it appear at www.silcon.cz (http://www.silcon.cz) ??October/November this year is my rough guess.
Back on topic. I received my DS2072 today. If I have understood it right, I shouldn't calibrate it if I want to keep the "trial options", meaning SPI/I2C decoding and so on?
is there a danger that one do the regeneration to late?
so what's the consensus on the most stable version for a noob to upgrade from 00.00.01To get your correct FW version, read the bottom portion of this post (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684).
I don't know how Farnell are still in business. Terrible prices, pathetic range, slow website with a useless search function, parametric searching which usually doesn't include the most important parameters... And apparently lots of old stock too.
Oh, the price was not bad. It was cheaper than my local dealer www.htest.cz (http://www.htest.cz)
No - you can do it anytime.is there a danger that one do the regeneration to late?Back on topic. I received my DS2072 today. If I have understood it right, I shouldn't calibrate it if I want to keep the "trial options", meaning SPI/I2C decoding and so on?Yes - better to wait. Don't worry - there will be opportunities to calibrate a bit later when 'regenerating' trial options. ;)
...we're not posting about the technique publicly...so far, it seems to have kept Rigol from taking steps to prevent it.Understood, "nothing to see". :)
I'm not Marmad, but I'll answer anyway...pardon me Marmad. The max number I read in this thread is 5 measurements, which is one more than the Agilent DSOX2000 series.Yes, you can have up to 5 measurements at the bottom of the screen at once, optionally with statistics (min, max, avg).
Have to agree Element14 (FARNELL) 2 years ago wanted $58 plus cents for 1 ATMEGA48V and I found a firm who supplied 100 including freight for less. The other thing that bugs me are SMD resistors 0402 pkg & 603s after searching for half an hour finding prices as low as 2 cents you finally find the higher wattage one and the price is $1 to $2 each min order 10 place it in the cart and there's a minimum of 2000 s__t you say and start the circus again :-- RS is nearly as bad but they put available in 5 to 6 wotking days and after ordering it's on back order 3months, :-- wish they would the length of time before placing the order Who gets their ass kicked for the order spread all over the place yeah! the person ordering not the supplier.LOL I'm not the only one that thinks so.
It really annoys me because I use Atmel micros a lot and until recently my company only seemed to be able to order stuff from them and RS (who are possibly even worse, but at least tend to deliver in the morning instead of at 4:30 - "next day" my arse). Their range is pathetic and they used to want £7 for a single part that Mouser were doing for £1.50. Even now Atmel will sell you a debugger for $99 while Farnell want £175 for it.
Hello group,Welcome Jean! Yes, it's a fun DSO to play with - especially the segment record and record open (history) feature. :) I don't mind the fan because my lab has other fans making more noise than the Rigol - but if you plan to open it to change (or alter) the fan, be sure to watch Mike's video on how to remove the warranty sticker without breaking it (https://www.youtube.com/watch?v=KGcNS5g9ygg).
I just received my DS2072 yesterday and I am very pleased so far. Since I am currently working on a project involving a shared SPI bus (ADC + TFT screen driven by an Arduino), I have tried the SPI triggering capabilities plus the decoding function, which are very useful, in addition to look very nice. In any case it works quite well.
I was hesitating between this model and a Hameg HMO 1xxx or 2xxx (I have been using Hameg for many years, my old 203-5 is still working well, moreover there is a special offer running up to October 2013, giving the decode option for free when buying a new scope), and I finally went for the Rigol, helped in my choice by the videos (EEV among others) and all the helpful comments on this forums, so thxs guys :)
If I had to find a flaw, I would say the fan is too noisy for my taste, I will probably have a look inside later to check if I can make things quieter. Except this, it is a very nice device that I am discovering with pleasure, I only wish the trial options time were not decreasing so fast :/
Returning to the scope now, I think I am getting addicted! ++
Welcome Jean! Yes, it's a fun DSO to play with - especially the segment record and record open (history) feature. :) I don't mind the fan because my lab has other fans making more noise than the Rigol - but if you plan to open it to change (or alter) the fan, be sure to watch Mike's video on how to remove the warranty sticker without breaking it (https://www.youtube.com/watch?v=KGcNS5g9ygg).
Also, be sure to download my software for the DS2000 here (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/).
And don't worry about the trial options - we owners have figured out a simple method to reset them - just send me or another regular user here a PM when your time is close to ending ;)
Apart from Ebay, is there any other options to avoid rip-off-britain prices.......possibly one of Dave's sponsor sites.
I don't mind having top-notch support, I just want a fair deal.
UPDATE: Have bought the DS2072.
Apart from Ebay, is there any other options to avoid rip-off-britain prices.......possibly one of Dave's sponsor sites.
I don't mind having top-notch support, I just want a fair deal.
UPDATE: Have bought the DS2072.
Well, Ian - if you had waited a little bit before buying (I just now saw your message), I might have been able to steer you to a much better deal/price.
I never bought the 2102 as I had priced up, I bought the 2072.......a helluva lot cheaper.
Hi all,Be aware, this can be a trap: I do not know how it works in the UK, but I am pretty sure, you will have to pay import VAT when the package arrives in the UK (this is the fact in all European countries). As it will be held at customs (pretty large and heavy box) you will then pay 849 Pounds to China plus import VAT (same as regular VAT) plus customs (3% or so) to the UK. Thus: China is not cheaper than UK.
Have made my mind up and am going to buy the Rigol DS2102......I'm in the UK and can only really see the Rigol UK site as an option to buy..........but I also notice that I can buy via Ebay.
Rigol-uk.co.uk = £835 + vat = £1002 total
Ebay (shipped from China) = £849 total
UPDATE: Have bought the DS2072.
you will then pay 849 Pounds to China plus import VAT (same as regular VAT) plus customs (3% or so) to the UK.
Edit: At the very least, there is always Batronix in Germany: DS2072 = €710 + VAT (or NO VAT if you have a number) + free shipping in EU + 30 days trial period. But I know of an even better deal that's often possible ;)
Where has a better deal? I'm looking at getting one and getting it from Batronix seems like the best so far. I have a VAT number.
Where has a better deal? I'm looking at getting one and getting it from Batronix seems like the best so far. I have a VAT number.
Check your PMs.
Marmad can you inform me about this too? I also have a VAT number if that would matter. Thanks :)
I never bought the 2102 as I had priced up, I bought the 2072.......a helluva lot cheaper.
Still, there were better deals to be had - you didn't wait long enough after your original post. Something is screwy with the Forum notification system today; I'm not getting notified of posts for a LONG time.
The online chat girl said they expected stock in 2 weeks.I've generally had a good impression of their customer service and attitude, but bad luck with delivery timing.
I'm also curious about the deal you're talking about. Could you PM me?I never bought the 2102 as I had priced up, I bought the 2072.......a helluva lot cheaper.
Still, there were better deals to be had - you didn't wait long enough after your original post. Something is screwy with the Forum notification system today; I'm not getting notified of posts for a LONG time.
The difference between Men and Boys
is the price of their Toys
The one with the most Toys , Wins :-DD
The online chat girl said they expected stock in 2 weeks.I've generally had a good impression of their customer service and attitude, but bad luck with delivery timing.
My most recent order had a lead time of 5 wks, which I found out on the "order status" page a few days after placing the order. You could say it's my fault for not asking for a quote to get stock status ahead of time, but with such a long lead time a note on the product page or at checkout would have been nice. On top of that, I requested a quote for the same item about a week after the sale just for the heck of it, to see what timing estimate I'd get that way. The quote said "Notes: Lead time is 2 weeks." I called in to get to the bottom of it and found out the quote was mistaken - the leadtime was still 5 weeks (so 6 weeks from the time of my sale).
According to UPS the order left their dock just shy of 4 weeks after the sale. That's 4 weeks late, 2 weeks early, or 1 week late depending on what version of info the customer got and depending on whether one believes month+ backordered status should be identified on the product page or at checkout (or only mentioned when the customer asks for it).
I wrote them about this in response to a "let us show you why we're better" email back on April 5th and haven't heard back, but then I viewed it more as a comment slip and wasn't necessarily expecting a response.
Everyone - even the best of companies - has issues sometimes where a series of improbable coincidences can't be avoided. Also, I've only ordered from them twice so that's a pretty small sample size. Many other people have had good things to say so I'd like to believe my experiences have been the exception to the rule. When my orders did arrive, both were packaged well and the contents were in great shape and working order (and were the correct contents). That's most important to me, so I would order from them again and give them a 3rd chance.
Even so, if it's really important your scope ships in 2 weeks I'd double-check, possibly by email or requesting a quote. Then I'd check again :P
It's either a clever marketing strategy or Rigol severely underestimated the demand.
Anybody tried to buy a Wee console when it first came out? ;)
According to above experience.
In future, I will order from the Rigol's official site ,
if Tequipment.NET has no stock.
Neil
All my Rigol orders with Tequipment came from Rigol in Ohio .
I did check with Rigol and it was more expensive
and I needed to pay the shipping and same delivery time.
At this time the world supply is Low,
Why?
For the relative expensive product, they will just start to buy required parts after receiving your order, and then they have to assemble those parts......which doesn't necessarely have to be a negative thing for us too, beside you have to wait for your new toy (I know waiting isn't funny, I was able to pick mine up 6h after I placed my order 15km from my home). But this way there are few out-of-date units in stock. This way they can react fast on hardware problems and apply fixes in the production process, alongside with shipping the units with the most recent firmwares. So besides all negative effects of this policity there are also benefits for us customers.
I did experience what I thought was a problem with the 2202. After powering it up cold with channel 1 & 2 set at max sensitivity of 500uV/div, the DC balance takes about 10 minutes of warm-up to settle. (see attached screen shots) Performing a self cal did not correct the issue. I returned it to Rigol NA and they shipped another one again, with no questions asked. Sadly it exhibits the same behavior so I can only assume they all have this issue. :(
I haven't seen any posts about it so has anyone else noticed this?
Rigol will give their Agents some discounts. This is why Tequipment.net could offer free shipping. The discounts to the Agents could even be 40% of the list price I think.
TENEYES
Thanks for the tips. For this test there was nothing connected to the inputs. I tried terminating the inputs with 50 ohms and there was no difference but I think the noise @ this 200MHz bandwidth is quite good and I am satisfied with the 2202. It was the 4022 that bothered me a bit with 3.5mV noise. The 3 division thermal drift on channel 1 is annoying but If I need to use the 500uV range I just let it warm up for 10 minutes. The trigger level doesn't seem to have any effect on the thermal drift.
I may have missed this from all the discussion about how self calibration clears the trial counters: So, how does one calibrate a new scope yet preserve the counters?
--Van
@ marmad
I just wonder if the "better" brands i.e. Tek and HP exhibit thermal drift at max sensitivity settings? Maybe Dave can attest to this since he has reviewed them.
Hi guys!
A quick question, I hope I didn't miss it being already covered in the last 78 (!!! :-+) pages. Having used my scope several times now, I still can't get how to enable or disable measurements from the left-side meu. I find it very hard to see the logic of that. Sometimes new measurements appear on the right side, sometimes it shifts the older measurements and appears somewhere between the already activated ones. Is there any way that Rigol will change that very annoiing behaviour any time soon?Thank god they listened to us about the inverted X-Y mode...
XaS
Having used my scope several times now, I still can't get how to enable or disable measurements from the left-side meu. I find it very hard to see the logic of that. Sometimes new measurements appear on the right side, sometimes it shifts the older measurements and appears somewhere between the already activated ones.
- Select Period Measurement on CH1. I would like it to appear on the right of Period Measurement CH2, like this:
| Period CH2 | Period CH1 | empty | empty | empty |
Instead I get the same as after the first step. I see no way to sort the measurements the way I like besides fill all measurement slots with garbage, delete them and then fill them in the right order.
- Select Period Measurement on CH1. I would like it to appear on the right of Period Measurement CH2, like this:
| Period CH2 | Period CH1 | empty | empty | empty |
Instead I get the same as after the first step. I see no way to sort the measurements the way I like besides fill all measurement slots with garbage, delete them and then fill them in the right order.
Hmm... I get exactly what you would like to get (as shown above) - I don't get the same as after the first step ???
For me, the Recover options don't seem to have any effect if I've used 'All Items' -> 'Delete'.
I start following this topic after I watched Marmad's review of the Rigol 2072 oscilloscope. ...And here is another new owner of the Rigol 2072. I'm a beginner in electronics, with some ties in the past, but I'm very excited to have just bought a tool I can use to see what's going on inside my or others' electronic circuits. And what a tool it is! Also, it's good to see experienced users exploring the features and sharing information about this oscilloscope. For us, beginners, it's priceless. Thanks.
OK, too much excitement here. I'm going back to work now, but I can't wait to use the oscilloscope again.
marmad and orbiter, thanks for checking with your units. I still run v00.00.01.00.05, maybe this is fixed in the most recent software version?
XaS
marmad and orbiter, thanks for checking with your units. I still run v00.00.01.00.05, maybe this is fixed in the most recent software version?
XaS
@XaS.. The latest FW does indeed sort out a few issues on the scope, as shown on page one of this thread via marmads excellent compilation of info. https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)Although the latest firmware also adds one NEW measurement bug (#13) which you will have to workaround until the next release.
Thank you all for checking, it seems to be solved in 01.00.00.03 indeed. I couldn't find this particular problem in the first post, that's why I asked here. It seems like this wasn't discovered so far.Yes, you can downgrade - and I've sent you email ;) But make sure you do upgrading/downgrading via the bootloader, as described in that same post (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684).
@marmad: Yes, #13 is a bummer. But as far as I know it is also possible to downgrade if it gets too annoying, right? Also, if you could check your email if you've got a minute to spare... ;)
XaS
By the way, I just wanted to install a new, more silent fan. Lifting the sticker was no problem at all, but inside, on the screws holdung the metal case, there is a nasty, thin red film of colour. Any scratches will be obvious. Now I've got to wait for 33 months untill I get a silent DSO... :'(
It could easily be Loctite. But it's not on the thread to secure the screw but only on the head itself. To me it looks like its only purpose is to reveal when someone has tampered with the screws. That's why I don't know if it is wise to remove, let alone possible to remove it completely. Finally I got a device with 36 months warranty and now I can't wait until its over.... ;D
Thank you all for checking, it seems to be solved in 01.00.00.03 indeed. I couldn't find this particular problem in the first post, that's why I asked here. It seems like this wasn't discovered so far.I noticed it, but didn't think it was a bug. Since turning measurements on/off is so unergonomic I just thought it was expected behaviour. Nice to see they fixed it, I hadn't noticed yet.
I’ve encountered a problem with my DS4024 which is similar to problems people have had with their DS2000 series. After reading through this thread (79 pages!) I found out why my trial options disappeared overnight (I did a self calibration :palm:). Anyhow, I ‘understand’ the situation on the DS2000 series but I was wondering if there was something similar for the DS4000 series? I have looked around but can't find it anywhere.I don't know about this - I haven't heard anything one way or the other.
Also, I found a minor bug with the DS4024 and was wondering if that bug was present on the DS2000 series as well, since they appear to share a similar platform. Paul Price started a thread in the General Chat section and I detailed the bug in that thread, so rather than repeating it here you can read it there.I just tested at 200ms/div, trigger position at 1.414s (see attached image) - no problem.
https://www.eevblog.com/forum/chat/rigol-ds4024-sweep-behavior/15/ (https://www.eevblog.com/forum/chat/rigol-ds4024-sweep-behavior/15/)
There is also an odd display characteristic on the DS4024, which is detailed in that thread. Does the DS2000 series also behave like that?Yes, the DS2000 does the same, but it's clear to me what Rigol are doing. It has to do with intensity grading/persistence: extend the 'Display' menu, and watch the 'PersistTime' selection when you switch from 100ms -> 200ms - it grays out - meaning it's no longer active above 100ms. At <= 100ms/div, the Rigol is capturing full screens of data so that they can be combined into the intensity/persistence map (impossible to do when 'rolling'). Whether you like this behavior or not is a question of preference, but that appears to be why they're doing it.
Prompted by another thread,
There is the selection of Anti-Alias on or off, but Does the DS2000 only allow 'AA' under a rnage of specific settings? (X sec/div - Y sec/div)
Honestly, I wonder if the AA actually works (or works well) on the DS2000. Can anyone post 'before' and 'after' screen shots of the AA making a noticeable difference?Actually, I saw the effect of AA yesterday by accident. I had an 1kHz sine wave on both channels, both with some serious noise on them (it was an audio signal from a laptop). Edge trigger had some problems on catching the sine waves steadily and the curves jittered left and right. Due to false manipulation I switched on AA accidentially and I got the sine waves as if they were amplitude modulated with about 0.5Hz. They slowly went from a flat signal to the full sine waves and the back again to zero. Since I wasn't interested in this, I have no evidence on it happening. And right now I can't reach the DSO...
Is there any reason to switch off the Anti-Alias function?
Honestly, I wonder if the AA actually works (or works well) on the DS2000. Can anyone post 'before' and 'after' screen shots of the AA making a noticeable difference?Actually, I saw the effect of AA yesterday by accident. I had an 1kHz sine wave on both channels, both with some serious noise on them (it was an audio signal from a laptop). Edge trigger had some problems on catching the sine waves steadily and the curves jittered left and right. Due to false manipulation I switched on AA accidentially and I got the sine waves as if they were amplitude modulated with about 0.5Hz. They slowly went from a flat signal to the full sine waves and the back again to zero. Since I wasn't interested in this, I have no evidence on it happening. And right now I can't reach the DSO...
XaS
Oh, That's weird. At DSOX2002A there is no such feature, or it's probably still ON. :palm: Dave could not produce any aliasing with this scope. Well, the scope is Apple-like, we know. :palm:Is there any reason to switch off the Anti-Alias function?
https://www.eevblog.com/forum/blog/eevblog-474-gw-instek-gds-2000a-series-oscilloscope-unboxing-fi/msg242748/#msg242748 (https://www.eevblog.com/forum/blog/eevblog-474-gw-instek-gds-2000a-series-oscilloscope-unboxing-fi/msg242748/#msg242748)
First, with 1kHz sine and 500us time base, there is an effect. Without AA, the sine wave jitters arround like hell. With AA on, the display rate is MUCH slower (I'd say about 4fps compared to >20fps before) and the sine wave is more or less shown stable.
Edit: Of course, selecting more than 7kPoints solves the problem for 20ms and some more above.
@EV: I think you were the one that originally posted about the Anti-Alias bug. Can you please confirm that Anti-Aliasing is working in the current FW with a 'before' and 'after' screen shot?
OK, I got these pictures from home. There is clearly some efect, if antialiasing is on or off.
In previous posts some of us have confirmed that it is not doing anything to stop aliasing.To be fair, Rigol doesn't claim it will stop aliasing:
At slower sweep speed, the sample rate is reduced and a dedicated display algorithm is used to minimize the possibility of aliasing.
The displayed waveforms will be more susceptible to aliasing when this function is disabled.
To be fair, Rigol doesn't claim it will stop aliasing:But it's not doing anything visible (except perhaps changing gradation), while mathematical techniques for anti-aliasing (http://www.home.agilent.com/upload/cmc_upload/All/exp66.pdf) have been around for awhile. I think it's a bug (or an unimplemented feature - which they 'forgot' to remove from the manual).Quote from: User ManualAt slower sweep speed, the sample rate is reduced and a dedicated display algorithm is used to minimize the possibility of aliasing.
The displayed waveforms will be more susceptible to aliasing when this function is disabled.
Notice the 100MHz and 200MHz bandwidth options at the bottom of the trial list.
Notice the 100MHz and 200MHz bandwidth options at the bottom of the trial list.
Yes, this has been commented on quite a few times throughout this thread. Haven't you read all [000081] pages? ;D
Ah. I noticed it was just posted to YouTube four days ago. When I did a search on the thread and forum nothing came up so I posted it.That's EEVBlog member studio25's video - and the thread where the video is posted (and which is investigating hacking the Rigol) is here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/). But thanks for posting here - I know it's sometimes impossible to find stuff on EEVBlog - hell, I often can't find posts I made myself. ;D
Ah. I noticed it was just posted to YouTube four days ago. When I did a search on the thread and forum nothing came up so I posted it.That's EEVBlog member studio25's video - and the thread where the video is posted (and which is investigating hacking the Rigol) is here (https://www.eevblog.com/forum/testgear/sniffing-the-rigol's-internal-i2c-bus/). But thanks for posting here - I know it's sometimes impossible to find stuff on EEVBlog - hell, I often can't find posts I made myself. ;D
Hello,
I try the rs232 decode on my DS2072. So far it works pretty good.
But it knows only little ascii symbols.
.,:;-_!"§$%&/()=? is unknown.
The DS2072 is a little analphabet
i generate the signal with Scanalogic-2 a little logic analyser. Therefore the pegel is no true RS232.
Hello marmad,
now the rs232_csv_max file
Best Regards
Hello marmad,
now the rs232_csv_max file
Best Regards
I try the rs232 decode on my DS2072. So far it works pretty good.Added to the bugs/issues list (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) - and passed along to Drieg/Rigol.
But it knows only little ascii symbols.
.,:;-_!"§$%&/()=? is unknown.
Hi guys,
I did a little about measuring EMI using DS2202, details can be found at https://www.eevblog.com/forum/projects/idea-about-measure-emi-using-oscilloscope/ (https://www.eevblog.com/forum/projects/idea-about-measure-emi-using-oscilloscope/)
I have a little question about the bandwidth of the FFT, it seems the BW of the DS2202 is far higher than 200Mhz?
And I do not have ground (earth) in most of the rooms in the house.Are you from Russia??
No, i am from Denmark. First in ca 1995 the installation off ground in all room in a house started.And I do not have ground (earth) in most of the rooms in the house.Are you from Russia??
Your scope is probably OK, but provide it a proper ground.
I have had a Rigol DS2072 and I Got An Electric Shock from it.Other oscilloscopes are the same (except for specially-built ones with isolation - I have a Tektronix battery-operated analog scope that is double-insulated). What you were doing is dangerous - and there is lots of information about it online (http://www.cbtricks.com/miscellaneous/tech_publications/scope/floating.pdf); the DSO MUST be grounded.
I was using a 2 wire extension cord without ground (earth).
I found out when Rigol DS2072 is not grounded, there is 115 volt on Chassis ground,
and independently of the switch are On or Off.
Is it only my Rigol DS2072 that is defective ?
How are other digital oscilloscopes ?
Do I have to change the house's electrical installation with ground (earth) ?
So guys, I'm thinking about possibly getting a DS2072 someday - my question is what is the deal with the demo features? It comes with all of them enabled for a period of time? How long?
Same as on my DSOX2002A and my father's DSOX3000 at his company. It's probably not a bug.Thank you for testing. But it just tell that all Rigol oscilloscopes, is real bad isolated from main power(230V).
Dave's video is about measurement and connection to other electrical appliances, and what can happen.I have had a Rigol DS2072 and I Got An Electric Shock from it.Other oscilloscopes are the same (except for specially-built ones with isolation - I have a Tektronix battery-operated analog scope that is double-insulated). What you were doing is dangerous - and there is lots of information about it online (http://www.cbtricks.com/miscellaneous/tech_publications/scope/floating.pdf); the DSO MUST be grounded.
I was using a 2 wire extension cord without ground (earth).
I found out when Rigol DS2072 is not grounded, there is 115 volt on Chassis ground,
and independently of the switch are On or Off.
Is it only my Rigol DS2072 that is defective ?
How are other digital oscilloscopes ?
Do I have to change the house's electrical installation with ground (earth) ?
Dave even made a video (http://www.eevblog.com/2012/05/18/eevblog-279-how-not-to-blow-up-your-oscilloscope/) which talks about the fact that the DSO chassis (and all BNC connectors) are shorted to Earth ground (and how to avoid accidents when probing).
Dave's video is about measurement and connection to other electrical appliances, and what can happen.
When Rigol DS2072 is not grounded, it have 115 Volt (or 230 Volt) on chassis and also on probe tip.
Completely without being connected to other equipment.
All my old analog oscilloscopes I have had, do not have 230 V out on Chassis ground, and also on probe tip. And all other electrical instruments I have do not have it.
Rigol DS2072 must be bad isolated from main power(230V).
Are other digital oscilloscope brands also poorly insulated ?
Of course, it is best to ground.
Dave's video is about measurement and connection to other electrical appliances, and what can happen.
When Rigol DS2072 is not grounded, it have 115 Volt (or 230 Volt) on chassis and also on probe tip.
Completely without being connected to other equipment.
All my old analog oscilloscopes I have had, do not have 230 V out on Chassis ground, and also on probe tip. And all other electrical instruments I have do not have it.
Rigol DS2072 must be bad isolated from main power(230V).
Are other digital oscilloscope brands also poorly insulated ?
Of course, it is best to ground.
So I just did a few checks. From measureing the mains input socket with an LCR meter, there's a common mode filter with 4.7nf caps between N-G and A-G. There's no blead resistance across the caps and ground (I am not saying there should be.)
So under controlled conditions I removed a ground, powered it up, and got what you described. This is as to be expected, the 4.7nf caps are forming a voltage divider to earth at the input CM filter, and so earth is now half way between neutral and active potentials. In Oz, with a 240V active and neutral at close enough to ground, this gives ~ 120VACrms on the jacks.
Shorting this to ground gives a current of 338uArms, which if you work out 1/(2*pi*f*C) on 4.7nf, and divide 240Vrms by it, you’ll get exactly that.
It’s got nothing at all to do with insulation, it’s designed that way to remove mains line noise (and vice versa.) So just operate it with a ground and you’ll be fine.
When Rigol DS2072 is not grounded, it have 115 Volt (or 230 Volt) on chassis and also on probe tip.
Completely without being connected to other equipment.
All my old analog oscilloscopes I have had, do not have 230 V out on Chassis ground, and also on probe tip. And all other electrical instruments I have do not have it.
I returned the Rigol DS2072, maybe I should buy it again.:palm: I hope it didn't cost you anything to return it!
When Rigol DS2072 is not grounded, it have 115 Volt (or 230 Volt) on chassis and also on probe tip.
Completely without being connected to other equipment.
All my old analog oscilloscopes I have had, do not have 230 V out on Chassis ground, and also on probe tip. And all other electrical instruments I have do not have it.
Do the other instruments have:
"WARNING: MAINTAIN GROUND TO AVOID ELECTRIC SHOCK"
engraved in large letters on them?
Grounding was in the past for extra protection.
Now, it is obviously necessary.
As I have said before, in Denmark we were first grounding in new houses about 1995 (in wet room before). I would have been happy for a digital oscilloscope, who absolutely not have to be grounded.
I returned the Rigol DS2072, maybe I should buy it again.:palm: I hope it didn't cost you anything to return it!
Grounding was in the past for extra protection.
Now, it is obviously necessary.
As I have said before, in Denmark we were first grounding in new houses about 1995 (in wet room before). I would have been happy for a digital oscilloscope, who absolutely not have to be grounded.
Regardless of wiring in Danish houses, any electronics operated from switching power supplies need to be grounded - and always have. I noticed back in 1988 when I ran my PC without a ground connection that there was 110-120V potential on the metal case.
I thought the display is cleared after each trace in normal mode ? ???
they will appear simultaneously on the display with a minimum decay time (or longer - if you have persistence set higher) - and WAITING for a trigger freezes the 'decay'. You were set to AUTO MemDepth @ 100ns - which means up to 16,790 waveforms per second. This is actually advantageous - and helps spot multiple triggers and glitches.aaaaah Yes, Thanks Marmad,
When on 20 nSec timebase:
and input of a signal of 10 Mhz i get 41.000 WFM/sec
but when change input to 60 Mhz it drops to 22.000 WFM/sec
On 1uS timbase:
and input of 1 Mhz, i get 2.900 WFM/s
but with 10 Mhz it drops to 1.900 WFM/s
On 20 nSec timebase:
and 1 Mhz i get 46.000 WFM/s but change timebase to fine and 20.05 nSec it drops to 5.000 WFM/s
How does that fit in your explanation video about WFM/s, i dont get it.
Or if someone could post just ONE 'before/after' example of it actually 'minimizing' aliasing, I would be happy :)This seemed like it might be interesting to play with, so I fed the DSO various frequencies and looked for an example where AA looked better.
I've only seen AA produce an improvement in cases where the scope was displaying low intensity. So if you have dim traces, or a dim swath, turning on AA may add detail. In the first normal acquisition images, you see that the vertical portions of the traces got more intense and easier to follow with the eye. But this isn't a typical aliasing case of undersampling the waveform. I don't know why the trace was so dim to start with. Even at 185us with exactly 4 periods displayed, the wave (in dots) was still pretty dim and wide. At 100us, it looks correct, and with AA turned on in 185us, it looks correct. Is this another kind of aliasing?
The last two images were the only ones I came up with where it looked like AA actually reduced acquisition aliasing. That's a 15.555555MHz signal.
I'm not sure if the DS6000 Demo Board has been mentioned before on EEVBlog or not (a quick search didn't turn up anything), but I found it at Batronix while searching for any possible new UltraVision products - and I hadn't seen it before and thought it was kind of interesting. It lists at €163 / $225 (excl.), and I've attached the user guide below.
"This Demo board is used to illustrate the basic functions of the oscilloscope. It is powered through USB port and can output 25 kinds of signals for the illustration of oscilloscope functions, i.e. sine, video (PAL/NTSC), AM Modulation, Sweeps, many digital signals and lots more. Delivery including Demo Board, USB Cable, CD with manual."
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=44584)
It's got the Instek one beat - Instek demo board only does 10 analog and 5 digital/LA functions for $205 list (so probably about $185 discounted).
I might have to get me one of these to play around with.
Those test point "hoops" on that demo board look neat. Has anyone seen those for sale?Well, in the original post I made (which you can see in the quoted area above), I mentioned I found the device (and images) at Batronix(.com) in Germany.
Those test point "hoops" on that demo board look neat. Has anyone seen those for sale?Well, in the original post I made (which you can see in the quoted area above), I mentioned I found the device (and images) at Batronix(.com) in Germany.
Here's the data sheet. (http://www.batronix.com/pdf/Rigol/UserGuide/DS6000DemoBoard_UserGuide_EN.pdf)
Seriously though, if you want to do any more playing around, I would strongly suggest that you don't use 14M or 56M sample lengths - since traditionally, one of the tools to battle against aliasing is to increase sample length (since that automatically increases sample rates and/or samples being decimated for the display). If anti-aliasing works at all on the Rigol, it should first and foremost be working when you have small sample lengths - so that switching it on might (in the background) automatically force the DSO to capture more samples for random decimation (or change sample speeds) in order to prevent the occurrence of the aliased waveform.I didn't post pictures of the smaller memory depths because AA never did anything for them, not because I didn't try it. But going back at it, I am able to get a very subtle change at 140k in some situations. I experimented with what happens to the sample dots themselves and could find no difference at any memory depth.
http://www.batronix.com/shop/oscilloscopes/Rigol-DS2202.html (http://www.batronix.com/shop/oscilloscopes/Rigol-DS2202.html)
Click accessories!
http://www.batronix.com/shop/oscilloscopes/Rigol-DS4022.html (http://www.batronix.com/shop/oscilloscopes/Rigol-DS4022.html)
Click accessories!
Thanks to everyone for the plethora of good information, bugs, comparisons, quirks... It makes purchasing one of these a much more transparent process. Especially to a noob like me considering a first scope.
I've run into a few bugs, and have contacted Rigol who says they are known but that there is no firmware update released yet. You can see in the attached image, a bug where all the test data is wrongly shown as identical.This bug was just introduced in the last version of the FW - and has already been fixed in the upcoming version. It is in our bug list on the opening page (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684):
Though maybe not a bug, I noted that when I download a waveform onto a USB drive, the resolution is reduced below that displayed on the scope. For example, at 2 V/div, the resolution in the downloaded file is 0.080V. For a full screen deflection of 16V (= 8 x 2V/div ), the # of steps is 200 ( =16V / 0.080V). I'll have to explore more to see if it is possible to download at higher resolutions.I'm not sure exactly what you mean? What file format are you talking about? WFM? CSV? TRC?
Those Rigols are feature rich, they have good hardware, but because of those bugs
:palm: :palm: I would never trust this scope. :-- Anyway, when they finally make a good firmware without bugs, it will be a good scope.
I hope to use the decoding functions for our CAN bus, and I am pleased to see some great demos of this capability already posted.
I hope to use the decoding functions for our CAN bus, and I am pleased to see some great demos of this capability already posted.How do you plan on doing that? As far as I know the CAN bus decoder is only available for the DS6000 scopes (and costs almost as much as a DS2072!)
This bug was just introduced in the last version of the FW - and has already been fixed in the upcoming version. It is in our bug list on the opening page (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684):Marmed,
Though maybe not a bug, I noted that when I download a waveform onto a USB drive, the resolution is reduced below that displayed on the scope. For example, at 2 V/div, the resolution in the downloaded file is 0.080V. For a full screen deflection of 16V (= 8 x 2V/div ), the # of steps is 200 ( =16V / 0.080V). I'll have to explore more to see if it is possible to download at higher resolutions.I'm not sure exactly what you mean? What file format are you talking about? WFM? CSV? TRC?
Maybe Rigol will offer CAN decoding on the DS2000 later?I don't think so. Probably the main firmware set is the same through all DS 2xxx/4xxx/6xxx series and they just enable/disable features (and changes regarding different hardware). By this the firmware development costs are shared through all scope lines and maintaining is much easier.
OK, I do not know what happend, the page 85 was hanging for a few hours after my last post there. I did nothing special, just writing some text.
I now had the idea to add a few blank postings to move the thread to a new page. It seems this worked and the thread it is back to normal again - just one real entry from me is missing and this one was not important. So, end of page 85 is missing and hanging.
Peter
Still appears broken to me - I can only see posts after the attached when I'm in the reply editor, where the new posts appear below the edit box.
In case it helps, right now in normal view I can see through "Reply #1270" (attached). In edit view I can see though the following post:
I think page 85 broke when I as posting a response to Marmad. I had trouble uploading a 1.5MB .BMP file, attached to my response, where the page (#85) would timeout when I posted. I tried 2 or three times, and succeeded with the post only after I removed my attachment. I then went back to modify the post to re-add the attachment, and that's when page 85 started behaving badly. My post exists, attached to my username devitrify, but it doesn't appear on page 85.
The Rigol does another trick (I'm not sure why, but I think partially for speed - and partially because of the 500uV/div setting) in which it only maps 200 (of the 255 possible bits) to the 400 pixel height of the display, effectively causing ~10% of the possible vertical resolution to fall offscreen, top and bottom. If you want to get as much vertical resolution as possible in your saved waveforms, you should adjust the display so the it overlaps the top and bottom by ~10% (one division).
@devitrify: I just read your 'vanished' post (and your original post again). Obviously the Rigol, like all other low-cost DSOs, uses an 8-bit ADC, meaning that you would never get more than 256 discrete levels maximum.Marmad, Rigol claims 12 bits of resolution for the DS2000 series in their posted specs at: http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ (http://www.rigolna.com/products/digital-oscilloscopes/ds2000/)
Marmad, Rigol claims 12 bits of resolution for the DS2000 series in their posted specs at: http://www.rigolna.com/products/digital-oscilloscopes/ds2000/ (http://www.rigolna.com/products/digital-oscilloscopes/ds2000/)
but I understand you to say that these additional 4 bits are interpolated from the actual 8-bit measurement.
I am disappointed. I wish that manufacturers would simply state the resolution of their ADCs and separately indicate the means with which they achieve any additional resolution, much like optical vs digital zoom on cameras.
High ResolutionAverage is over frames
Again, this is something being done ON sample memory in it's transformation to display memory (and the screen). You won't be able to save this except as the 1400 bytes of display memory.
EDIT: Actually, perhaps I'm wrong about this and the results of the averaging end up in sample memory - I haven't tested saving High-Res mode so I'm not sure. But in any case, it will be as 8-bit data, not 12-bit.
Average is over frames
(Again, this is something being done ON sample memory in it's transformation to display memory (and the screen). You won't be able to save this except as the 1400 bytes of display memory.) = I'm not sure about this, as explained by my edit below.It matches my experiences outlined earlier in this thread. The scope retains the original 8-bit values in sample memory and can switch between high-res and normal without acquiring a new waveform. Anti-Alias also seems to be done during transformation from sample to display.
It matches my experiences outlined earlier in this thread. The scope retains the original 8-bit values in sample memory and can switch between high-res and normal without acquiring a new waveform. Anti-Alias also seems to be done during transformation from sample to display.
Hello all... going to take the plunge on a DS2072. Looks like the only place in the US to get a good deal is Tequipment but they are out of stock. Did anyone recently place an order and how quickly did they get the scope?
Hi-res works best when the scan rate is such that there are Extra samples. (20 Sa/s ;D)
Hello all... going to take the plunge on a DS2072. Looks like the only place in the US to get a good deal is Tequipment but they are out of stock. Did anyone recently place an order and how quickly did they get the scope? New to electronics.. but it seems this is a good starting scope to play around with. I have a Tek 465b but I guess I won't use that much when I get my hands on the Rigol. Seems a great group of people here!
Dave
The manufacturer discontinued the free trial option?said who?
Aidetek (a ebay dealer), told me so. Could it be true? :oThe manufacturer discontinued the free trial option?said who?
I have no idea, I'll have to ask him.Aidetek (a ebay dealer), told me so. Could it be true? :oDoes Aidetek do the self-Cal ? OOPS ;)
Aidetek (a ebay dealer), told me so. Could it be true? :o
Aidetek (a ebay dealer), told me so. Could it be true? :o
I haven't heard this directly - but I notice that it isn't advertised anymore at Batronix (and I'm fairly sure it was listed on the pages before). Also it wouldn't surprise me, since members here are posting openly on how to reset the trial minutes (and I know Rigol follows the forum).
It makes sense in a way - the new models (-S) are coming out, so there is a depleted stock everywhere with an increase in demand - a perfect time to do it if they were planning it.
Poll, What will the price point be for the DS2072-S ?
$999 ?, $1199? ........
Hello all... going to take the plunge on a DS2072. Looks like the only place in the US to get a good deal is Tequipment but they are out of stock. Did anyone recently place an order and how quickly did they get the scope? New to electronics.. but it seems this is a good starting scope to play around with. I have a Tek 465b but I guess I won't use that much when I get my hands on the Rigol. Seems a great group of people here!
Dave
Hi Dave,
I placed an order with TEquipment back on June 4. It hasn't shipped yet, but I knew going in that they were on back order. The last update I got said that my order would ship June 21. If that is true, then this might be a good time for you to order, assuming they'll receive enough stock to go around.
Good luck,
--Van
I spoke to TE about the DS2072 on April 25th, and at time they told me 4-6 weeks. Rigol's website also said 4-6 weeks until it ships. Well, that was over 7 weeks ago and neither have gotten stock - I've been periodically checking in with each.Judging from the other comments on this thread of people ordering (and receiving) theirs, it seems like the units that get to RigolNA immediately fulfill backorders, so there's never any standing stock.
I received my DS2072 from Batronix 2 days ago, it has got trial options. :)
I will NOT buy anything from aidetek again !
Asked 3 times about firmware version and upgrade without any answer.
They still dident pay back my promised 80$ .
Aidetek are going total oposit way then other dealers, removing things instead of adding.
Lucky that i dident buy my DS2072 over there.
Its written many times where to buy DS2000.
Thanks Van,
I get an estimate date of 6/21 too on the order. I guess we will have to see how accurate it is.
I'm not too happy though if they are removing the trial options, it would be nice to try those out. :--
I'll contact them Monday and see what I can find out.
Dave
Then, the current does not have these trial options?
Then, the current does not have these trial options?
Perhaps Rigol is moving towards no trial minutes in upcoming versions, but for the moment, whether they are or not is completely irrelevant. Not only is the firmware currently being hacked by members here, but as we've posted many times already: it's easy to 're-start' the trial - and there is nothing preventing downgrading to earlier FW versions with the trial. So I'm not sure what difference it makes for prospective buyers. A lot of things would need to be changed in order to 'plug' this particular leak.
Does anyone have inside information about when the next firmware revision may be released? I'm looking forward to bug #13 at the beginning of this thread being resolved. The workaround is a pain.
Does anyone have inside information about when the next firmware revision may be released? I'm looking forward to bug #13 at the beginning of this thread being resolved. The workaround is a pain.
It was supposed to be quickly - unfortunately, I'm afraid the other Rigol thread that started here in the last month may have played a role in delaying it. Hard to know for sure since Rigol has always been tight-lipped about it.
Another DS2072 owner reporting here - or actually the scope is still on its way. I ordered mine from Batronix yesterday and it was shipped the same day, so swift service there.
This is actually my first personal scope ever. Many times I've thought buying one but it wasn't until now when I pulled trigger. In the end I was having two choices: Rigol DS2000 series and Agilent DSOX2000 series. I was close to buying a four channel Agilent, but then it just looked liked that Rigol really is the best bang for the buck. The price wasn't a factor here. I could have spent 2000...3000euros for the Agilent, but eventually spent a little over 800e for the Rigol.
and another newbie DS2072 owner reporting here .. hi 8)
Someone ever decided to use 50 ohm, but why...??The common wire impedance of 50 Ohm is a compromise between good power handling (30 Ohm) and low cable loss (77 Ohm).
Hello Wim13,
can you please explain what a measuring head does.
Is it that it measure the signal at the input of scope and adjust the signal at generator, so that the amplitude of the signal at input from scope is always the same?
Best Regards
egonotto
Turning on anti aliasing does not change anything, only the brightness.
I don't know what's going on with the flow of shipments to the U.S., but it seems to have tricked down to nothing. The supposed ship date of my DS2072 came and went last Friday, so I called TEquipment today to find out if it had shipped yet. They said that, according to Rigol, it will be another 10 to 12 days before any more ship. Last week, after waiting three weeks since ordering, I was told that units would be shipping in just a few days directly to customers from Rigol in Ohio. But, now, apparently that's all off.
So, considering these continual shipping delays, unfixed FW bugs and rumors of possible new anti-hacking measures, I decided to cancel my order and to re-direct my attention to a used analog scope to satisfy near-term needs. Later, when it's more clear where this product is headed, perhaps I'll try again to get my hands on one.
--Van
I really cannot understand what is going on over at Rigol - and I don't understand why they wouldn't know last Tuesday when I ordered that there were no DS2072's coming on Friday. I import tons of stuff from China and I always know what is coming and when. There seems to be something strange going on @ Rigol here. Either they are not communicating with their distributors, or they are inept at handling orders/status/promises, or there is some kind of manufacturing problem we don't know about.
But although I can understand backlogs, I begin to see a red flag when a manufacturer repeatedly fails to meet already-promised distributor commitments within a reasonable time span.
...and serious, unfixed bugs
...and we see a very unclear picture of where Rigol is taking this product.
But although I can understand backlogs, I begin to see a red flag when a manufacturer repeatedly fails to meet already-promised distributor commitments within a reasonable time span.
I think you're being a little paranoid. Everyone knows the -S version is coming out shortly (if not already on sale in China) - so it's quite possible that backlogs/delays are connected to that. BTW, Batronix here in the EU (as well as other companies) seems to continue to have stock so it seems to be an NA problem - not a manufacturing or FW problem.Quote...and serious, unfixed bugs
What might those be? There are no serious bugs - and just one rather annoying one.Quote...and we see a very unclear picture of where Rigol is taking this product.
I'm not sure I follow. The DS2000 is very successful - so Rigol is coming out with an enhanced version with built-in AWG (the -S model) to broaden the line.
But although I can understand backlogs, I begin to see a red flag when a manufacturer repeatedly fails to meet already-promised distributor commitments within a reasonable time span.
I think you're being a little paranoid. Everyone knows the -S version is coming out shortly (if not already on sale in China) - so it's quite possible that backlogs/delays are connected to that.Quote...and serious, unfixed bugs
What might those be? There are no serious bugs - and just one rather annoying one.Quote...and we see a very unclear picture of where Rigol is taking this product.
I'm not sure I follow. The DS2000 is very successful - so Rigol is coming out with an enhanced version with built-in AWG (the -S model) to broaden the line.
I consider the very security flaws that have been successfully exploited to be serious.
The anti-aliasing bug-- okay, you consider it an annoyance but others might consider it a serious bug.
Or maybe it's the bug that wipes out the trial options when the scope is calibrated that is the annoyance.
I am concerned about how well this model will be supported by the manufacturer going forward: the timeliness of customer support, bug fixes, product updates, response to customer feedback, etc.
I wish they did a 4 channel version of the DS2000. The 4000 series is rather expensive so there is nothing to compete with Agilent's 4 channel 2000X scopes.
...No function generators in stock except for a few models of the DG5000 (no 1000's, or 4000's)...I ordered a DG4162 on June 17th from Tequipment and much to my surprise the tentative shipping date is August 7th :(. I also planned on purchasing a DS2202 but still haven't gotten a reply to my PM here to Tequipment regarding the EEVblog discount >:(. In addition, I e-mailed Rick @ Tequipment directly on June 19th when I found out they were out of stock until August about the possibility of changing the order from the generator to a scope and haven't gotten a reply from him either >:(. I expect poor customer service from Rigol, but certainly not from Tequipment :--.
If one of the members here would be kind enough to PM me the EEV discount code I would be very grateful.
...No function generators in stock except for a few models of the DG5000 (no 1000's, or 4000's)...I ordered a DG4162 on June 17th from Tequipment and much to my surprise the tentative shipping date is August 7th :(. I also planned on purchasing a DS2202 but still haven't gotten a reply to my PM here to Tequipment regarding the EEVblog discount >:(. In addition, I e-mailed Rick @ Tequipment directly on June 19th when I found out they were out of stock until August about the possibility of changing the order from the generator to a scope and haven't gotten a reply from him either >:(. I expect poor customer service from Rigol, but certainly not from Tequipment :--.
If one of the members here would be kind enough to PM me the EEV discount code I would be very grateful.
And finally, a special thank you goes out to Marmad and the other ingenious folks who have put so much time and effort into exploring the full potential of these scopes :-+ :-+ :-+. All your efforts are greatly appreciated by countless members here and elsewhere.
Marc -
It was Rick I just talked to @ TE. I had asked if he was the guy who is on EEVBlog and he said generally no, so if you PM'ed him then I don't think he comes to the site too much... I wouldn't hold it against them, I don't think the EEVBlog is an official support channel for them...
I will set up a coupon code today to give a flat discount. Its a bit complicated as some manufactures have a min sale price that we cannot go below that applies to certain items and with our current back end its not as sophisticated we would like.
Its also possible we can do better than this flat discount.. sometimes there is margin and sometimes there is not. It depends on the brand or item. Sometimes a quote is better but I think the flat discount would work for most items.
PM me for the code. It was set up as I typed this. This would also work on all clearance. We are moving a bunch of items out below cost right now.
Thanks for the business,
Evan Cirelli
Co-owner of TEquipment.NET
Turning on anti aliasing does not change anything, only the brightness.As part of How Thick is Your Baselne on Your Digital Oscilloscope? (https://www.eevblog.com/forum/testgear/basline-noise-in-your-digital-oscilloscope/msg248817/#msg248817), I learned more about what anti-alias is doing. We already knew it was a sample->display thing, but here's an example where it actually fixes up waveform aliasing. These are all the same part of the same capture. 500uV/div, displaying dots, peak acquire (though it happens with Normal as well). You can see the first makes it look like the noise is restricted to two horizontal bands, but switching to a shorter time base makes that effect disapper--it was an aliasing artifact! The third returns to the original timebase but enables Anti-Alias.
The anti-aliasing bug-- okay, you consider it an annoyance but others might consider it a serious bug.It's almost certainly working as intended. I wouldn't call it a bug, but it is deceptive.
We already knew it was a sample->display thing, but here's an example where it actually fixes up waveform aliasing.
I found Hi Res to be even worse: Putting "High Resolution" in the sample section of the datasheet (and the acquire menu of the scope) is pretty much a lie, especially if other scopes actually implement it at signal->sample time.
I found Hi Res to be even worse: Putting "High Resolution" in the sample section of the datasheet (and the acquire menu of the scope) is pretty much a lie, especially if other scopes actually implement it at signal->sample time.
The digitizing oscilloscope supports five acquisition modes.
Sample
Peak Detect
Hi Res
Envelope
Average
HighRes is acquisition mode - exactly.
Tell to Tektronix they have done it wrong. It is more like they have defined world of oscilloscpes (in history) and others have then followed....
Btw, it is also good to understand what is High Res mode, how it works.
It's almost certainly working as intended. I wouldn't call it a bug, but it is deceptive.
Just to elaborate: the way that the DSO SHOULD be implementing anti-aliasing is with oversampling which is then randomly decimated before display to avoid the appearance of a false low frequency component - or if the sample length is already deep, just random decimation when displayed.Right, we're agreeing with each other. I'm saying the DS2000 seems to do the second part; it does sample->display randomization or something similar. But it doesn't do the much more important signal->sample randomization.
Tell to Tektronix they have done it wrong. It is more like they have defined world of oscilloscpes (in history) and others have then followed....All I've found from Tek so far is "In hi-res mode, the data is significantly oversampled, and then a boxcar average is performed in acquisition hardware to real-time average". This implies to me that the averaging happens before data is written to sample memory, but it's still a little vague.
I know the meaning of AC and DC coupling for the Signal input
But is the function of AC and DC coupling on the Trigger settings independent of the Channel signal coupling on the DS2000?
What happens with the Signal DC coupled, and Trigger AC coupled?
What happens with the Signal AC coupled, and Trigger DC coupled?
With the Trigger set to AC coupling;
the Trigger level (edge) varies with the trigger level knob, (orange voltage value)
but there is No orange Line --------------------.
Is that because the triggering subsystem cannot know the absolute DC level to put the line on the Display? :-//
Am I explaining that OK.
Right, we're agreeing with each other. I'm saying the DS2000 seems to do the second part; it does sample->display randomization or something similar. But it doesn't do the much more important signal->sample randomization.
This is not what the Rigol does. I don't think the DS2000 can oversample; that if the Rigol ADC is making 2G readings/s, then it's writing 2Gsa/s to sample memory. Rigol's High Resolution averaging happens when displaying the sample memory. This is how Rigol achieves 2GSa/s, by moving everything to sample memory post-processing.
Rigol is approximating features of the big boy scopes, so they named them the same and put them in the same place... but they're not the same! And their approximation of Anti-Alias is nearly useless since their "vectors" algorithm already does a decent job preventing sample->display waveform aliasing. Calling them the same thing is definitely deceptive.
What happens with the Signal AC coupled, and Trigger DC coupled?So in AC mode the trigger signal is not the same level anymore as the displayed signal.
What happens with the Signal AC coupled, and Trigger AC coupled?
The DSO of course does not know the difference of the AC + DC componont of the signal, so
the trigger in AC mode does not know where the desired trigger level is on the screen. And the orange line is meaningless.
Well I tried modes with and input signal = a 1 Vpp Sin with 0.5 Vdc offset
when the DS2072 is Chan 1 AC coupled
and Trigger Setting is set to DC coupled
ACTs the Same as
Chan 1 AC coupled
and Trigger Setting is set to AC coupled
So why not show the orange line!!
I'll try the RFQ process and hopefully, they'll be a little more responsive thru that channel.I submitted the RFQ this morning and they responded about 4 hours later, including the EEV discount and free shipping :D. When I tried to pay via PayPal, I was charged shipping. I did an online chat w/ Dawn and she refunded the shipping back thru PayPal. In addition, she was able to apply the discount to the DG4162 I purchased earlier in the month prior to learning about Evan's very generous offer. So while their customer service is lacking thru indirect channels, it's outstanding thru the Quote and Live Chat channels :-+ :-+. FWIW, they're estimating the lead time to be 2-3 weeks. Sounds a bit optimistic but time will tell.
Does this go back to old Scope devices,when the DS2072 is Chan 1 AC coupled and Trigger Setting is set to DC coupledBecause it is not the same.....
ACTs the Same as Chan 1 AC coupled and Trigger Setting is set to AC coupled
So why not show the orange line!!
If trigger mode is in DC, there is a relation with the showed grid on the display ( not the displayed signal )so the DSO can display a orange line.
If trigger on DC and is on 1 volt, there is a relation with 1 volt on the screen.
But in AC mode there is NO relation the the value next to the displayed grid
and the DSO does not now where to display the line, so it does not.
In AC trigger mode 1 volt can be anywhere on the screen.
because I would think this DS2000 can determine the trigger value that is used to set the position on the display ,
thus show the trigger level line
Below are 4 displays , (note trigger level in low left corner)
1. Input DC coupled with trigger DC coupled
2. Input DC coupled with trigger AC coupled (no trigger line)
3. Input AC coupled with trigger DC coupled
4. Input AC coupled with trigger AC coupled (no trigger line)
What is the Difference between 3 & 4?
Just my small preference :)
Can anyone help me a little with getting 01.00.05 firmware? I have 01.00.02 FW and 1.1.0.0 HW. I assume it is one GEL file applicable for all world regions, isn't it?Rigol support has sent me recent 01.00.00.03 which I do not want use (for some obvious reason with "trial" keyword in it).
I was just finished it to-date, after 2 loong nights and what can I say...who can give me a good European source for a Rigol DS2XXX series one? :). Probably only a DS2072, depending on final price + VAT + shipping, etc. Batronix is out of stock now. Anyone around who is selling them?
I just unboxed my DS2072, which I ordered from Batronix. And yes, there's a warranty sticker on these scopes now.
I'm pretty sure there's always been one on there - I have one on mine bought in October 2012. Put if you want to open the DSO, there are ways around it without breaking it - look for mikeselectricstuff's video.Ok, I was under impression that older models didn't have anything similar on them and this was added later/recenly.
I got my DS2072 today too!
Very nice. Very nice indeed!
I got my DS2072 today too!
Very nice. Very nice indeed!
So it sounds as if the tap has opened up again finally in NA. Good to hear it.
I made a 'swivel shelf'.
When I spoke to Dawn @ TE (who is awesomely helpful!) she said their shipment of DS2072's had just arrived that day and were being readied for shipment.
Big question is..... Do you still have trial options?
Just wanted to throw a link out to this thread quick in case anyone is still looking for the Tequipment.net code:If one of the members here would be kind enough to PM me the EEV discount code I would be very grateful.I don't believe there is a code, it's done on a case by case basis. The stuff I've bought via EEV was a hard quote each time with no discount code.
If someone can tell a lazy SOB like me what to do in order to see any full firmware version or if there's anything anyone wants to know about my 'scope, let me know and I will do it and post up.It's all listed in the third post of this thread (down near the bottom). (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
If someone can tell a lazy SOB like me what to do in order to see any full firmware version or if there's anything anyone wants to know about my 'scope, let me know and I will do it and post up.It's all listed in the third post of this thread (down near the bottom). (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
If the DSO came from back inventory, I'm guessing you'll have FW 01.00.02 or 01.00.05.
If someone can tell a lazy SOB like me what to do in order to see any full firmware version or if there's anything anyone wants to know about my 'scope, let me know and I will do it and post up.It's all listed in the third post of this thread (down near the bottom). (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
If the DSO came from back inventory, I'm guessing you'll have FW 01.00.02 or 01.00.05.
I can't get that to work. I am in the trigger menu w/Edge selected and I'm hitting 7/6/7/Utility quickly (tried to do it all within 1/2 second - also tried to do it slower and more deliberately), and I have key beep turned on, so I know I am getting the key presses. It beeps on 7/6/7 and on Utility it brings up the Utility menu.
Anything else that needs to be set - like channels off, in single/run/stop or something?
If someone can tell a lazy SOB like me what to do in order to see any full firmware version or if there's anything anyone wants to know about my 'scope, let me know and I will do it and post up.It's all listed in the third post of this thread (down near the bottom). (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
If the DSO came from back inventory, I'm guessing you'll have FW 01.00.02 or 01.00.05.
I can't get that to work. I am in the trigger menu w/Edge selected and I'm hitting 7/6/7/Utility quickly (tried to do it all within 1/2 second - also tried to do it slower and more deliberately), and I have key beep turned on, so I know I am getting the key presses. It beeps on 7/6/7 and on Utility it brings up the Utility menu.
Anything else that needs to be set - like channels off, in single/run/stop or something?
this confused me. are you using the buttons on the right side of the screen ? - they are what worked for me
I can't get that to work. I am in the trigger menu w/Edge selected and I'm hitting 7/6/7/Utility quickly (tried to do it all within 1/2 second - also tried to do it slower and more deliberately), and I have key beep turned on, so I know I am getting the key presses. It beeps on 7/6/7 and on Utility it brings up the Utility menu.
Is it possible I have a later firmware and this keypress method to get the full version info has been removed?
Is it possible I have a later firmware and this keypress method to get the full version info has been removed?
Is it possible I have a later firmware and this keypress method to get the full version info has been removed?
If you still can't get the button method to work, install NI VISA runtime (you need it for RUU anyway) and Rigol Ultra Sigma software.
Connect DSO via USB; boot the DSO; start Ultra Sigma; open SCPI Control Panel; type (or copy and paste) the following:
:SYSTem:SETup?
You will see the full FW version number in the top line of the return data.
It's strange, I turned key beep off and still could not see the firmware screen. I must have tried it over 100 times being very deliberate and careful with button presses.
Well, I installed NI-Visa and RUU (great software, BTW!) and typed the command into the SCPI control panel. Result: 00.01.00.00.03.
It's strange, I turned key beep off and still could not see the firmware screen. I must have tried it over 100 times being very deliberate and careful with button presses.
Well, I installed NI-Visa and RUU (great software, BTW!) and typed the command into the SCPI control panel. Result: 00.01.00.00.03.
You were checking System -> System Info after each of those times, right? If so, it's very strange... I just did it with FW 01.00.00.03 first time without a problem.
Made a complete graph for the Bandwidth of the 2072, 2102 and 2202.
They have all different bandwidth
As far i could find has to do with this IC,
The LMH6518
• Oscilloscope Programmable Gain Amplifier
of 20, 100, 200, 350, 650, 750 MHz or full bandwidth.
As far i could find has to do with this IC,
The LMH6518
• Oscilloscope Programmable Gain Amplifier
of 20, 100, 200, 350, 650, 750 MHz or full bandwidth.
Instrument Introduction
DS2000 Series is a new generation oscilloscope. It has 2 channels. It has a sibling version with logic analyser DS2000D. The maximum bandwidth is 200M, and the peak sampling rate is up to 1G.
I hooked my scope up to Ethernet just now, and was a little surprised by the instrument introduction:QuoteInstrument Introduction
DS2000 Series is a new generation oscilloscope. It has 2 channels. It has a sibling version with logic analyser DS2000D. The maximum bandwidth is 200M, and the peak sampling rate is up to 1G.
Doesn't exactly inspire confidence. You could buy a scope and then find out later that Rigol can't be bothered to release firmware fixes for that revision of the hardware.
I'm not sure what you mean about trials and 01.00.00.03 - they work fine with it. I personally think 01.00.00.03 is better - almost all bugs fixed (with one addition).
I was just curious if trial options counter that is about to expire still can be restarted on 01.00.00.03...
Vectors on the Rigol don't do a damn thing towards preventing aliasing - as evidenced by many images already posted here. If you think they do, post an image which demonstrates this. Their Anti-Aliasing does NOT work - and is either a bug, unimplemented feature, or mistake.
This input stage is a Hantek / TEKWAY ...
As you can see there are slight differences.
This input stage is a Hantek / TEKWAY ...
As you can see there are slight differences.
The Rigol has a differnt chip on the entry, that can be programmed for the bandwidth, and can
be changed by software, so very different from the Hantek
From the TI datsheet of this chip:
The LMH6518 gain is programmed via a SPI-1
compatible serial bus. A signal path combined gain
resolution of 8.5 mdB can be achieved when the
LMH6518's gain and the Gsps ADC's FS input are
both manipulated. Inputs and outputs are DC-
coupled. The outputs are differential with individual
Common Mode (CM) voltage control (for Main and
Auxiliary outputs) and have a selectable bandwidth
limiting circuitry (common to both Main and Auxiliary)
• Oscilloscope Programmable Gain Amplifier
of 20, 100, 200, 350, 650, 750 MHz or full bandwidth.
sorry I may be late to the party..
The anti-aliasing function may not do what you expect but it does work. Here is an example same signal with and without anti-aliasing. I should have tried to zoom in to see what the actual waveforms look like. But there is some difference
CH1 is ~700Hz and CH2 is @ 7 MHz envelopes. The second picture - Antialiasing ON
It is likely that there are differences in the input stages of the DS2000 series.
It is likely that there are differences in the input stages of the DS2000 series.
Wim's chart of the different BW's of the different models was all made on the same DSO - he just changed the BW via software codes.
I know the Rigol is doing SOMETHING when you turn on anti-aliasing, but it's definitely NOT doing anti-aliasing as defined for DSOs - thus it DOES NOT WORK.
Imagine sending the command to 750MHz BW :scared:
I understand that a member, tried setting higher BW modes with the Hardware hack and the the DS2000 is NOT capable of more BW
My DS2072 has arrived :clap: Can't even open the box until my wife gets home :(
Another curious thing, look at the pictures.
Where is the difference?
I think this function changes how captured samples are mapped to pixels on the screen to minimize aliasing. It doesn't change the way the signal is sampled. It works when scan rate is much slower than the sampling rate. What did you expect this button to do?Anti-aliasing never changes how the waveform is sampled. But you seem to be thinking about IMAGE anti-aliasing - I'm speaking about WAVEFORM anti-aliasing; which is what a DSO is supposed to do if it has an anti-aliasing feature (it has nothing to do with jagged edges, pixels, etc).
Another curious thing, look at the pictures.
Where is the difference?
i dont get it, please more ext
Another curious thing, look at the pictures.
Where is the difference?
i dont get it, please more ext
IMHO, the BW is lower in the DS2202, but little more I can say. :)
I have a SDS8102V (real BW ~206MHz), when I have a DS2072 I will do more comparisons (DS2072 as DS2202).
What do you think?
Another curious thing, look at the pictures.
Where is the difference?
i dont get it, please more ext
IMHO, the BW is lower in the DS2202, but little more I can say. :)
I have a SDS8102V (real BW ~206MHz), when I have a DS2072 I will do more comparisons (DS2072 as DS2202).
What do you think?
I can not see on Agilent what the settings are...to compare
But what is lower then the 2202, to your opinion ?
See picture with a rise time of 1.5 nSec that is 350/1.5 is 233 Mhz,
what is also measured with a signal generator
Another curious thing, look at the pictures.Yes , I see a picture of 500Mhz Agilent Scope
Where is the difference?
with a Label of OWON , what is your point??
You like bullshit!!
See picture with a rise time of 1.5 nSec that is 350/1.5 is 233 Mhz,
what is also measured with a signal generator
See picture with a rise time of 1.5 nSec that is 350/1.5 is 233 Mhz,
what is also measured with a signal generator
It is even better. Look at the picture, there rise time is 1.32 ns which gives BW = 350 / 1.32 = 265 MHz.
I think this function changes how captured samples are mapped to pixels on the screen to minimize aliasing. It doesn't change the way the signal is sampled. It works when scan rate is much slower than the sampling rate. What did you expect this button to do?Anti-aliasing never changes how the waveform is sampled. But you seem to be thinking about IMAGE anti-aliasing - I'm speaking about WAVEFORM anti-aliasing; which is what a DSO is supposed to do if it has an anti-aliasing feature (it has nothing to do with jagged edges, pixels, etc).
This post and the following one (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg252801/#msg252801) provide more information.
Marmad, I understand what aliasing is. I don't believe it's a bug or even annoyance if this option does not let you to measure a 1 MHz signal with 200 kSa/s ;)zibadun: Man, we've been talking about this for ages already here - it's not about measurement; it's about incorrect display. The point is - you shouldn't see a waveform of a lower frequency - you should see (what looks like) noise (see what the 1MHz waveform SHOULD look like at that time base).
You need to use a high enough sampling rate for the signal being measured and also make sure that any higher frequency components are cut off with a low pass filter. There is no way around it.Of course there is - Agilent does it. It's actually fairly easy - there are papers written about it (linked in earlier posts in this thread). You just do random decimation from sampled data to display data (e.g. instead of displaying every Nth sample, you vary the decimation). So instead of seeing a FALSE lower frequency, you see NOISE.
I bet one cycle of free trial options that IMAGE anti-aliasing is what Rigol had in mind and it's working as designed. :)No - that's not what they had in mind - look at the manual excerpts. It's perhaps what the guy who coded it had in mind, but he FUCKED UP! It's a bug, mistake, or unimplemented feature - there is no way around that fact.
Oh no please do not misunderstand me. Respect please. I'm just saying what I think. Owon is not the best, but recognize that in the image above is nothing short, regarding BW.@ Carrington
Please understand that my native language is not English, so may that I am not express properly.
Yes sorry , and I apologize
To be complete you could say you are comparing :
A Rigol DS2072(hacked) with 2.0 GSa/s at $800 200 Mhz
A Owon SDS9302 with 3.2 Gsa/s at $1500 300 Mhz
An Agilent DSO-X-3502A with 4.0 GSa/s at $8000 500 MHz
zibadun: Man, we've been talking about this for ages already here - it's not about measurement; it's about incorrect display. The point is - you shouldn't see a waveform of a lower frequency - you should see noise (see what the 1MHz waveform SHOULD look like at that time base).
...
Of course there is - Agilent does it. It's actually fairly easy - there are papers written about it (linked in earlier posts in this thread). You just do random decimation from sampled data to display data (e.g. instead of displaying every Nth sample, you vary the decimation). So instead of seeing a FALSE lower frequency, you see NOISE.
I saw the "random decimation" note. You can prevent aliasing from appearing on the lower resolution image but you can't remove aliases from the sampled waveform if you selected too low sampling rate for your signal. There is simply no data about what was happening in between the samples. You can't look back and apply some algorithm that will turn aliases into noise and will leave "real" frequencies untouched.
Here is what I can get this function to do. Note false paterns removed by the Antialiasing feature. Sometimes it has the opposite effect and makes the picture worse. You just have to toggle on and off and use the one that looks better.
Hello
There is a new firmware to Rigol DS2000:
DS2000(DSP)update_00.01.01.00.02.
See picture with a rise time of 1.5 nSec that is 350/1.5 is 233 Mhz,
what is also measured with a signal generator
It is even better. Look at the picture, there rise time is 1.32 ns which gives BW = 350 / 1.32 = 265 MHz.
That's hardly 10% to 90% rise time, more like 15% to 85% which will show a much shorter time and thus calculated bandwidth.
--
Darryl
The bug fixes/changes from new FW#01.01.00.02 are listed as folllows:
Is it just me or is the "Project" tab a new one? I can't remember that being there before, and it's got some weird stuff in it!
@marmad have you found any changes to security with the new FW, ie have rigol closed the door on down grading FW, DSA9 keys etc with the all the recent revelations lately its got me curious.
Is it just me or is the "Project" tab a new one? I can't remember that being there before, and it's got some weird stuff in it!
Project tab was always there when you entered F7-F6-F7-Utility key sequence for full version info.
I to have the project tab, but have no idea what it's for :-//
@marmad have you found any changes to security with the new FW, ie have rigol closed the door on down grading FW, DSA9 keys etc with the all the recent revelations lately its got me curious.
That's hardly 10% to 90% rise time, more like 15% to 85% which will show a much shorter time and thus calculated bandwidth.
--
Darryl
Are you telling that Rigol calculates the rise time in wrong way?
That's hardly 10% to 90% rise time, more like 15% to 85% which will show a much shorter time and thus calculated bandwidth.
--
Darryl
Are you telling that Rigol calculates the rise time in wrong way?
Well if those cursors are auto placed, then I would say that's very poor placing.
Anyone else think the same ?
Darryl
Reporting a Bug
At higher Frequencies
When in AC coupled Trigger mode the Counter does not display the Correct Frequency but the measurement displays correct.
When in DC coupled Trigger, the Counter is correct
Mine seems ok mate, I tried it at a few frequencies inc the 20MHz.. Both WITH and without the options mod. Can't go any higher than 20MHz at the moment though :(
And 20MHz.......
I think AUTO mode has packed-in again too in latest FW (02) :--
Reporting a Bug
At higher Frequencies
When in AC coupled Trigger mode the Counter does not display the Correct Frequency but the measurement displays correct.
When in DC coupled Trigger, the Counter is correct
Is this bug with the new FW?
Big thanks to marmad :-+.
Wellcome to the forum! Have you already found this thread?
https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/ (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/)
It is in TRIGGER mode, you tested the AC-DC input, Teneyes mentioned the TRIGGER mode AC/DC
About the AC and DC trigger...
The input signal on both pictures is the same, that did not change.
See also the change in the freq. counter..
Strange effect, on AC the trigger output become more stable, picture 1
and on DC the source signal is more stable, picture 2
This is very strange behavior...
I hope it is not Hardware,
so it seems not to be a real problem...
Shortly after buying my SDS8102V was discovered the noise problem (HW).
And now that I've bought a DS2072 if it appears that also has a hardware fault then ... :o :rant: |O
If you're right, "I hardly think it's the end of the world."
Only I wish it was not a hardware failure.
If it is, do not want to jinx myself, but lately everything goes wrong.
Let us trust in the experience Rigol.
I’m interested to know how to reset option min counters (boy they seem to drop fast) if anyone would like to PM me but I’m happy to post more first if that makes folks more comfortable sharing this information.I have a tool that you can run on Windows, it'll auto-scan both USB and LAN, and automatically push any licence keys you may have into the scopes that it finds. I have no idea which licence keys you might own, or which ones out in the wild are legitimate trials etc. so I've left that part to you. You'll need to add your licence keys into the config file.
then maybe we could get without much difficulty A BW of 300/400MHz by SPI commandsWhatfor? The scope has not been calibrated for this. Maybe a 70Mhz scope was only calibrated for 70 Mhz so even 100 or 200Mhz measurements are not valid.
Anyone have an image of the input stage of a DS2072?I don't think I took any photos, but I did compare my DS2072 to Dave's photos and couldn't find any differences by eye.
To compare with this (DS2202):
http://www.flickr.com/photos/eevblog/8022205124/#in/photostream/lightbox/ (http://www.flickr.com/photos/eevblog/8022205124/#in/photostream/lightbox/)
Thank you very much ve7xen, then only to be confirmed the value of unmarked smd resistors and capacitors, to claim that they are identical.
Unfortunately these resistors may be the key.
The fact that the models are physically identical was already confirmed in this forum 9 months ago. This is old news.
Obviously I did not know it.
Also was confirmed that the unmarked smd resistors and capacitors are identical?
Thanks
Great :)
Marmad, you know if someone has tried to establish a BW of 300MHz by SPI command?
And this BW was verified?
Thanks
Perhaps, and -3dB @ 233MHz is due to the combination of LMH6518 @ 350MHz and the response of the stages before the LMH6518.
In such case would interesting change the MMBFJ309, N-Chanel RF Amplifier, by another similar with better frequency response.
We only need sniff the SPI of the LMH6518 to check it. Has anyone done that yet?
Hi all,
Is this a bug.....or is it just me intepreting the scope wrongly.?
DS2072 (FW v.01.00.00.03)
- Turn on both channels, probe a couple of different DC voltages.
- Whilst Ch.1 selected go to Vertical menu and select Vavg (yellow). Ch.1 Vavg is now displayed at bottom of screen in yellow.
- Select Ch.2 and go to Vertical menu and select Vavg (blue). Ch.2 is now displayed at bottom of screen in blue.......however, Ch.1 which is still yellow now reads same voltage as Ch.2.
I was looking to have Ch.1 & Ch.2 Vavg at bottom of screen. Whatever I do both the Vavg's at the bottom of the screen always read the same voltage.
PS. If use the DISPLAY ALL function under MEASURE both the V.avg's are displayed correctly in the pop-up.
Ian.
Read the first post of this thread, all the bugs are listed....
And yes it was a bug, solved in the latest FW, you can download on the first page.
I think there are similarities with this:
...
See Q01_1 at page 2, and other small changes to get 200MHz of BW.
Nonsense! The hardware and firmware are identical between the 2072, 2102, and 2202 models. The only difference between models is the entry of a key(s). Many folks here have done exhaustive testing prior to and after applying these keys and have proven this to be fact. I just received my 2072 today and have done some basic tests for myself all of which have tracked the others work just about perfectly. If you go thru the couple of threads regarding the 2072, you can see some excellent plots done by Wim13 showing the vertical bandwidth past 400 MHz....we could get without much difficulty A BW of 300/400MHz...Whatfor? The scope has not been calibrated for this. Maybe a 70Mhz scope was only calibrated for 70 Mhz so even 100 or 200Mhz measurements are not valid...
Nonsense! The hardware and firmware are identical between the 2072, 2102, and 2202 models. The only difference between models is the entry of a key(s). Many folks here have done exhaustive testing prior to and after applying these keys and have proven this to be fact. I just received my 2072 today and have done some basic tests for myself all of which have tracked the others work just about perfectly. If you go thru the couple of threads regarding the 2072, you can see some excellent plots done by Wim13 showing the vertical bandwidth past 400 MHz....we could get without much difficulty A BW of 300/400MHz...Whatfor? The scope has not been calibrated for this. Maybe a 70Mhz scope was only calibrated for 70 Mhz so even 100 or 200Mhz measurements are not valid...
....
I think it's a bit too early to state that. We have no knowledge that Rigol has calibrated a 2072 for anything higher than 70 MHz (we don't know what their process is in production). Just because you can see stuff visually up to the -3db drop, doesn't mean it's accurate.If you're talking calibration constants, that's not a hardware difference...
re: anti-aliasing having no effect.
I beg to differ. Try the FFT function, with and without AA.
It seems to limit something or other.
Have noticed from videos of people ds2xx2 that all earlier shipments come with switchable x1 x10 probes. Some people mention 350MHz bandwidth. Well my scope came with x10 non selectable , rigol info sheet says 300MHz bandwidth. Now I've got other probes for accessing the 500uV setting, but who else has the x10 only probes ?
--
Darryl
Have noticed from videos of people ds2xx2 that all earlier shipments come with switchable x1 x10 probes. Some people mention 350MHz bandwidth. Well my scope came with x10 non selectable , rigol info sheet says 300MHz bandwidth. Now I've got other probes for accessing the 500uV setting, but who else has the x10 only probes ?
I tried several times, first just the DSA9 key, then the DSAR followed by DSA9 keys but it still stayed a 2072
Another thing I noticed - maybe already known and not a bug.
In 500uV/DIV mode, the scope is internally set to 1mV/DIV and the data scaled by a factor of 2. This can be noticed when reading out the waveform data. The LSB is always 0. This effectively reduces the ADC resolution by 1 bit / dynamic range.
Are you sure?
I can also clearly see on the screen, that the signal is scaled. The steps are clearly visible and larger as compared to e.g. 1mV/DIV.
Another thing I noticed - maybe already known and not a bug.@Xyphro
In 500uV/DIV mode, the scope is internally set to 1mV/DIV and the data scaled by a factor of 2. This can be noticed when reading out the waveform data. The LSB is always 0. This effectively reduces the ADC resolution by 1 bit / dynamic range.
If the spec says true 500uv/div support it is actually wrong due to this bug, because the main purpose should be in most cases to look at the trace on the screen.
I agree, it is not a serious issue :-)Just a specific setting on the Scope
Just a funny fact.
How to do it? It's not rocket science - over-sample, then randomly decimate for the 'required' sample speed = stochastic sampling. Done.
I found a new bug while programming this here: http://www.xyphro.de/blog/index.php?entry=entry130705-223439 (http://www.xyphro.de/blog/index.php?entry=entry130705-223439)Yeah also doesn't implement some of the LXI 1.3 stuff over TCP/IP, such as 10.2 rule get XML ID document via '<hostname>/lxi/identification'
The DS2072 does not accept an INITIATE_CLEAR class command over the USB interface. This command is a required command according to the USBTMC specification. The Scope does not react at all to it, and the USB transfer times out.
If it's so simple why don't you implement it in RUU marmad?
If it's so simple why don't you implement it in RUU marmad?
There's no way I could get sample data fast enough from the DSO to do it in real time. I could do it slowly - but what good would that be?
Anti-alias is ideally something you want to have while probing unknown signals at slower horizontal speeds - but once you figure out what you're looking at and adjust your settings accordingly - it becomes a bit irrelevant. But it's something that needs to take place between the sampling and the display of the data - and so even thought the basic implementation (in terms of math) is not complex - it DOES have it be done quickly.
Have noticed from videos of people ds2xx2 that all earlier shipments come with switchable x1 x10 probes. Some people mention 350MHz bandwidth. Well my scope came with x10 non selectable , rigol info sheet says 300MHz bandwidth. Now I've got other probes for accessing the 500uV setting, but who else has the x10 only probes ?
The RP3300 x1/x10 switchable probes have been the standard included probes for the DS2000 series since they first started selling them. Where did you buy your DSO?
This is from the DS2000 User Manual:
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=53792)
I'm away from my scope at the moment, but the sheet tucked into each probe matched the actual probe. Ie no mention of a x1 position or switch. I'm 99% sure they are listed as RP3300.
Will post the pic tonight / tomorrow. Its a new scope bought from rigol-uk. Otherwise known as telonic instruments.
--
Darryl
sig500uv = dlmread('Newfile1__500uv.csv', ',', 2, 0);
sig1000uv = dlmread('Newfile1__1000uv.csv', ',', 2, 0);
sig500uv = sig500uv(:,2);
sig1000uv = sig1000uv(:,2);
hist500uv = hist(sig500uv, 10000);
hist1000uv = hist(sig1000uv, 10000);
c500uv = find(hist500uv > 0);
c1000uv = find(hist1000uv > 0);
c500uv = length(c500uv)
c1000uv = length(c1000uv)
If RUU is fast enough to render 3d it should be fast enough to draw "anti-alias". You can do it on a stored waveform, as a proof of concept. A picture worth a thousand words in this case ;)
I'm very confident, that the 500uV mode is a scaled mode and the gain in the analog path is the same as for the 1mV/DIV setting.
Teneyes: i tried the same, but get to see discrete steps (blank lines) on my scope.
Which fw version do you use? Mine is listed in the previous posting.
Maybe this is a new "feature" of my version?
If RUU is fast enough to render 3d it should be fast enough to draw "anti-alias". You can do it on a stored waveform, as a proof of concept. A picture worth a thousand words in this case ;)
The math data on how to do it is readily available online - and used (at the very least) in the Agilent X-Series. Exactly what am I trying to prove and to whom? ???
Agilent does this by first estimating the highest frequency component in the measured signal and then selecting a sampling rate which is fast enough to prevent aliasing. The captured samples are displayed using a technique you describe to avoid moire patterns on the screen. Rigol does the same thing more or less. I uploaded an example of this which you simply dismissed ;)
If you override scope settings and force 200 ksps on a 1 Mhz signal no algorithm will be able display noise instead of the aliased signal. In fact sampling 1 MHz @200 ksps would give you a 0 Hz aliased signal, i.e. a DC offset :)
I think you are confusing two different issues, interference patterns on the screen and RF aliasing. The latter cannot be fixed by algorithms. If you believe otherwise write a function that shows you are correct.
I'm very confident, that the 500uV mode is a scaled mode and the gain in the analog path is the same as for the 1mV/DIV setting.
So send an email to Rigol and get their response.
I do, but do you really expect any response from them?
Have noticed from videos of people ds2xx2 that all earlier shipments come with switchable x1 x10 probes. Some people mention 350MHz bandwidth. Well my scope came with x10 non selectable , rigol info sheet says 300MHz bandwidth. Now I've got other probes for accessing the 500uV setting, but who else has the x10 only probes ?
The RP3300 x1/x10 switchable probes have been the standard included probes for the DS2000 series since they first started selling them. Where did you buy your DSO?
This is from the DS2000 User Manual:
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=53792)
I'm away from my scope at the moment, but the sheet tucked into each probe matched the actual probe. Ie no mention of a x1 position or switch. I'm 99% sure they are listed as RP3300.
Will post the pic tonight / tomorrow. Its a new scope bought from rigol-uk. Otherwise known as telonic instruments.
--
Darryl
Well they are listed as RP3300A.
Well they are listed as RP3300A.
I can't even find an RP3300A probe listed anywhere online - it's like a cheaper version of the RP3300 that they've produced specifically to include with the DSO. Kind of sucks for you, man. :(
Perhaps they had it planned from the beginning - but didn't start producing them until later - so had to include the more expensive RP3300; I've no idea. But the online datasheet (http://www.rigolna.com/download/501G00000001PJyIAM/)(from June 2012) lists the standard probe as RP3300 - and so does the User Manual (May 2012). So it might be you have a very early model.
Edit: What was your calibration date?
its a very new model.
dated 4th June 2013
the manual, has a satin feel to the outside cover... and I can only see my single set of finger prints on it... I'd bet the manual had never been opened before, the glued edge, hasn't had a crease to it yet.
and the english half of the manual, definitely says Mar 2012 .... of course cant read the other half ;-)
You can always demand the RP3300 probes - saying that you read the probe specs in the online material before you bought it. Those materials post-date the manual.
and the english half of the manual, definitely says Mar 2012 .... of course cant read the other half ;-)
the problem is that the Rigol has user-selectable sample lengths - the Agilent does not. And it seems Rigol didn't figure out an elegant way to deal with this (e.g. forcing the sample length to a specific size).
If you don't think it's possible, you should be getting an Agilent owner to prove me wrong. For example:
@Hydrawerk - can you please demonstrate? For example, send a 100kHz sine into the DSO - and adjust the horizontal scale until the sampling rate shows 100kSa/s - then grab a screen shot and post it here?
So the issue here is that Rigol gave you enough rope to hang yourself? While Agilent thought the user does not know any better and picked the "correct" sample rate for you :)
Ok . I'm curious what Agilent will show for 100 khz signal sampled at 100 ksps, at 10ms time base. but sounds like this picture will not be possible to obtain (since Agilent does not allow use override ).
Well they are listed as RP3300A.
I can't even find an RP3300A probe listed anywhere online - it's like a cheaper version of the RP3300 that they've produced specifically to include with the DSO. Kind of sucks for you, man. :(
Perhaps they had it planned from the beginning - but didn't start producing them until later - so had to include the more expensive RP3300; I've no idea. But the online datasheet (http://www.rigolna.com/download/501G00000001PJyIAM/)(from June 2012) lists the standard probe as RP3300 - and so does the User Manual (May 2012). So it might be you have a very early model.
Edit: What was your calibration date?
its a very new model.
dated 4th June 2013
the manual, has a satin feel to the outside cover... and I can only see my single set of finger prints on it... I'd bet the manual had never been opened before, the glued edge, hasn't had a crease to it yet.
and the english half of the manual, definitely says Mar 2012 .... of course cant read the other half ;-)
Well they are listed as RP3300A.
I can't even find an RP3300A probe listed anywhere online - it's like a cheaper version of the RP3300 that they've produced specifically to include with the DSO. Kind of sucks for you, man. :(
Perhaps they had it planned from the beginning - but didn't start producing them until later - so had to include the more expensive RP3300; I've no idea. But the online datasheet (http://www.rigolna.com/download/501G00000001PJyIAM/)(from June 2012) lists the standard probe as RP3300 - and so does the User Manual (May 2012). So it might be you have a very early model.
Edit: What was your calibration date?
its a very new model.
dated 4th June 2013
the manual, has a satin feel to the outside cover... and I can only see my single set of finger prints on it... I'd bet the manual had never been opened before, the glued edge, hasn't had a crease to it yet.
and the english half of the manual, definitely says Mar 2012 .... of course cant read the other half ;-)
With respect to Rigol manufacture dates, I have read this somewhere. In checking the 5 different Rigol instruments that have been in my hands this seems to hold true. For example: serial # DS2A1436xxxxx. The 14 represents 2012 ( the 14th year Rigol has been in existence). This agrees with their website stating they were established in 1998. http://us.rigol.com/html/about/history.shtml (http://us.rigol.com/html/about/history.shtml)
The 36 represents the 36th week of 2012.
RigolNA also told me that a while ago, some units were sent back to be reworked. I received a 4022 that had been reworked but still was supplied with the pre-rework cal certificate. At turn-on, the menus were set for Chinese. I'm not sure if any of the 2000 series were reworked.
Hope this helps,
But it is funny to see that this lead to the discovery that the 500uV mode is in fact no "true" 500uV mode and only a digitally scaled 1mV version.
They could also offer a 250uV or 125uV setting with this method.
@marmad:
It can still be a problem of the CSV data export within the scope, but if this would not be the case, I have no another explanation for the same amount of values in histogram.
It's also a question if not mentioning something is really lying :-)
What would be a proof for you?
The procedure which lies between sample data and display data reshapes the data (interpolation / Decimation / ...) and pixels might not translate back 1:1 to ADC values, so depending on the level of interpolation/decimation, in between values can be shown on the display.Yes , The DSO can interpolate extra data point between 7 Bit data samples to create data values for the Display.
I got a confirmation from Rigol, that the 500uV mode is a scaled mode.
I got a confirmation from Rigol, that the 500uV mode is a scaled mode.
What do you mean 'WE'.. ;D..,
I am glad , I have 500uV, with 200uV Noise @BW=20MHz
and 20 uV resolution, how ever it is derived.
I did not understand how the resolution in 500uV/Div normal mode can be 20uV?take a series of 40 uV points and interpolate
If it was scaled 1mV/Div I would expect a 40uV resolution.
this would be a kind of filtering and the BW should go down.
Maybe EV or Wim can do a Sweep with DS2000 set @ 500uV, I only did from 4-40 MHz
Or the 20Mhz bw limit is done in the digital domain with a 8 bit signal path? You said it was turned on if I remember correctly.
But I'm also still happy with my Rigol :-)
Is there a way to adjust the trigger to 50% of the signal? I don't see this button which was quite handy on my previous rigol...Presuming you still want the signal displayed with DC coupling, you can put the trigger in AC coupling and 0V and it will do that.
Is there a way to adjust the trigger to 50% of the signal? I don't see this button which was quite handy on my previous rigol...Presuming you still want the signal displayed with DC coupling, you can put the trigger in AC coupling and 0V and it will do that.
Maybe EV or Wim can do a Sweep with DS2000 set @ 500uV, I only did from 4-40 MHz
(...) Could you please send a 100kHz sine wave into your Agilent DSO - then adjust the horizontal scale until the sampling rate shows 100kSa/s - then grab a screen shot and post it (...)Here are my pictures. I added a 10MHz at 10MSa/s. There is some small product of aliasing, but it's OK. It is not a clear sine wave, that fools you.
Thanks,
Mark
Here are my pictures. I added a 10MHz at 10MSa/s. There is some small product of aliasing, but it's OK. It is not a clear sine wave, that fools you.
I think pix are close to Hydrawerk's conditions
Huh? ??? Totally aliasing - not close at all.I think you missed what Teneyes was replying to ;)
Thank you for the pictures. What happens if you turn on the Antialiasing feature?So how do similar pictures from DS2000 look like?I think pix are close to Hydrawerk's conditions
Thank you for the pictures. What happens if you turn on the Antialiasing feature?So how do similar pictures from DS2000 look like?I think pix are close to Hydrawerk's conditions
marmad and now Teneyes expect this feature to do something else in undersampling mode. But looks like they will get either noise with some aliasing (Agilent) or "classic" aliasing (Rigol). they don't get to see the real signal while undersampling. So guys pick your poison :-//Please add me to the above list ;). Both Marmad and Teneyes understand the theory behind proper anti-aliasing as applied to scopes and it is clear that Rigol does not perform it that way. With all the material that's been presented on how random decimation of the raw data helps to minimize the effects of aliasing, I'm at a bit of a loss why this is still being argued :-//.
hydrawerk, here is the antialiasing feature at work on Rigol https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg255344/#msg255344 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg255344/#msg255344). It attempts to minimize moire patterns on the display. I think it works fineWow, you just don't want to stop being wrong about this :)
marmad and now Teneyes expect this feature to do something else in undersampling mode. But looks like they will get either noise with some aliasing (Agilent) or "classic" aliasing (Rigol). they don't get to see the real signal while undersampling. So guys pick your poison :-//The Agilent's "noise", as you call it, is actually a solid block of pixels, which is what you should see given the frequency and sample rate - that is the REAL signal (or a close enough approximation). That would actually help me from being confused by incorrectly folded-down lower frequencies. Sorry, but it seems as if you still don't understand the concept of what it's doing ;)
I realize that normally the DSO triggers on a select trigger (condition) and that there is a need to record data before and after the event. I am finding it an annoyance to have to wait as the DSO records long data before I am able to force a trigger.
When I select , "Single" I want 1 event
When I select , a Long time base , 1 min/div ( anything greater than 2 seconds)
When I move trigger point to near left edge of the Display ( showing I wish to see data after the trigger)
and then I press a "Force" trigger, I wish to see data Now
I think the DSO should start the trace immediately and just show the data immediately at the trigger point and NOT make me wait a long time for the DOS to record a preample.
Nope not for me :
At 20s/div, 14 Mpts, 50KSa/s ,
After moving trigger point to 5 div left of center (on the screen), "Wait" takes 40 seconds to Arm
After moving trigger point to 5 div left of center (on the screen), "Wait" takes 40 seconds to Arm
Yes , got it now, to get immediate tracing on manual trigger set the trigger exacting at left edge of the display, Just an OLD dude like the scan, I'm a bit slow :),
before left edge, then you wait to see trace
after left edge then you wait to arm
yeah sure , STOP DEADBut you had just enough time before bed to push us up to 100 pages in this thread! We are the second longest thread here at EEVBlog - and bearing down on first place. >:D
3:18 AM , time for bed
This is basically what a 100kHz sine wave SHOULD look like at 500ms/div:
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54268)
This is what the Rigol displays @500ms/div using 200kSa/s:
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54270)
This is what the Agilent displays @500ms/div using 100kSa/s:
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54154)
Which is closer to the REAL signal?
"Anti-aliasing" should eliminate aliasing - period. If that means that the DSO needs to 'lock' the sample size while the feature is being used - that's what it should do.
Agilent is more real, but it's lying about the sampling rate. It's oversampling the signal and then performs DSP on it to down convert to 100ksps.
Rigol shows the real 200khz sampling rate. with only two samples per cycle it's not able to represent the amplitude correctly so it appears like the signal is amplitude modulated. Rigol shows what you asked, with no gimmicky "stochastic" sampling.
Congratulations, you have found it! :) :-+ I heard first time about aliasing about half year ago.
- the aliasing still happens when you zoom in on the waveform when the DSO is stopped. :(Did you Zoom in far enough??
OOOH Boy what a Scan and sample rate (5Sa/s) here
The Warming up of my DSO with terminated inputs.
about 25 minutes between Pix
Note the gradual drift of the trace to Zero over 35 minutes
yeah sure , STOP DEADBut you had just enough time before bed to push us up to 100 pages in this thread! We are the second longest thread here at EEVBlog - and bearing down on first place. >:D
3:18 AM , time for bed
It took "Hantek - Tekway - DSO hack - get 200MHz bw for free (https://www.eevblog.com/forum/testgear/hantek-tekway-dso-hack-get-200mhz-bw-for-free/)" (the longest thread) 2 years, 2 months, and 5 days to get to 100 pages - while it only took us 8 months and 10 days to get here - and we weren't even offering free bandwidth. ;D
474 postings are made by you, 1009 by others. In "my" Tekway thread 605 are made by me and 1230 by others.
It is however somehow unfair compare, the Tekway/Hantek/Voltcraft community is large, but ~ 5000 of these DSO owners don't speak or don't post english (lol) or post on mikrocontroller.net (2788 replies!). That makes 4623 total (of which i posted 1326 times) postings related to Tekway/Hantek/Voltcraft DSO/MSO in the 3 main threads only :P
Did you Zoom in far enough??
And, I'm sorry, but I don't know what mikrocontroller.net has to do with EEVBlog. If you combine the top #2 and #3 threads here (both of which were started by me), I totally kick your ass here at EEVBlog. ;D
it is not about you and me or our threads in generally, but about threads about these two specific topics (if i would count my posts on analforum.com i would kick half of the world forever :P )
On the other side, exacty as you said, "8 months and 10 days" to get 100 pages, and thats a lot!
Within same time i got only 50-55 pages :( So "free something" didn't means anything, heh.
To me, it seems pretty easy to implement - certainly no more difficult than HIGH-RES mode, or a number of other post-processing techniques they use.
I hope that RIGOL consider it.
They could also add decoders CAN and LIN.
But why doesn't Rigol write a new FW routine which has a different behavior for when both AUTO and ANTI-ALIASING are on?Do you have any picture evidence that the DS2000 is capable of oversampling? My first couple of attempts at this seemed to indicate otherwise (which is what I was complaining about a dozen pages ago) but I haven't spent the time yet to thoroughly convince myself of it. If the DS2000 can only process what makes it to sample memory, then the anti-aliasing you want is simply not possible.
To me, it seems pretty easy to implement - certainly no more difficult than HIGH-RES mode, or a number of other post-processing techniques they use.
Do you have any picture evidence that the DS2000 is capable of oversampling? My first couple of attempts at this seemed to indicate otherwise (which is what I was complaining about a dozen pages ago) but I haven't spent the time yet to thoroughly convince myself of it. If the DS2000 can only process what makes it to sample memory, then the anti-aliasing you want is simply not possible.
The technique doesn't require the DSO to ever sample faster than 2GSa/s - it just varies how it decimates those samples at slower time base settings.I've never suggested that the DSO sample faster than its max. I haven't seen evidence that the Rigol ever does any logic between ADC and sample memory, even if the current sample rate is 1MSa/s.
This could happen between the ADC and sample memory (which is how I think the Agilent does it) or it could happen between sample memory and display memory.I'm confused: I thought the anti-aliasing you've been talking about has to happen before writing to sample memory. How could a sample->display algorithm help the situation in the agilent vs rigol images posted earlier? The presence of a high frequency signal has already been lost.
I'm confused: I thought the anti-aliasing you've been talking about has to happen before writing to sample memory. How could a sample->display algorithm help the situation in the agilent vs rigol images posted earlier? The presence of a high frequency signal has already been lost.
. Anyone have any comments on my posts about the MATH functions back here?@VE7XEN eh!
Reporting A BUGAn Update, and very quick, I'm impressed :-+ :-+
on FFT the DSO must maintain the Center frequency selected at the center of the display as you change through span scales
The Rigol does NOT have to do this during sampling; it could sample at full speed (2GSa/s) into sample memory - then do random decimation (to simulate the current sampling rate) to display memory. Of course, this wouldn't work for ALL slower sample rates (at some point the memory wouldn't be large enough), but it could work for many slower rates.With you up to here. I thought "at some point the memory wouldn't be large enough" is every time sample rate is reduced. Going back and looking at one of the examples you posted (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg252823/#msg252823), the scope is sampling at 200kSa/s because the memory depth is set to 14kpt and the timebase is 5ms. There's no room to increase the sample rate there, so that couldn't be a fix to that particular aliasing. What's an example where it could still sample at 2GSa/s into sample memory that it isn't doing that already?
Is this clear now? :)
With you up to here. I thought "at some point the memory wouldn't be large enough" is every time sample rate is reduced. Going back and looking at one of the examples you posted (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg252823/#msg252823), the scope is sampling at 200kSa/s because the memory depth is set to 14kpt and the timebase is 5ms. There's no room to increase the sample rate there, so that couldn't be a fix to that particular aliasing.Huh? ??? No room to increase the sample rate? It's sampling at 200kSa/s because the memory depth is FIXED at 14k - that's the only reason. If the sample size wasn't fixed there (if it used all 56M), it could be sampling at 500MSa/s; plenty fast enough to fix that aliasing.
What's an example where it could still sample at 2GSa/s into sample memory that it isn't doing that already?ANYTIME up to 2ms/div it's not sampling at 2GSa/s, it could be - if it didn't use FIXED sample sizes.
A little Tip for Math function Intg()Nice work! It's useful after all!
When using an input from a Chan and the Scan rate is in mSec, then multiply the input by 1000, that way the Units calculated will be in U, see the display
For a square wave input of -1.0 to 1.0 Vdc at 4mSec period
So integrating (+1.0 *1000) for 2 mSec = +2 Units
So integrating (-1.0 *1000) for 2 mSec = -2 Units
ANYTIME up to 2ms/div it's not sampling at 2GSa/s, it could be - if it didn't use FIXED sample sizes.So by that reasoning, the DS2000 already does anti-aliasing: Select the maximum memory depth and turn on anti-aliasing. But you haven't been satisfied by that "anti-aliasing" in the rest of this thread.
So by that reasoning, the DS2000 already does anti-aliasing: Select the maximum memory depth and turn on anti-aliasing. But you haven't been satisfied by that "anti-aliasing" in the rest of this thread.
The Rigol does NOT have to do this during sampling; it could sample at full speed (2GSa/s) into sample memory - then do random decimation (to simulate the current sampling rate) to display memoryI translate that into:
...
ANYTIME up to 2ms/div it's not sampling at 2GSa/s, it could be - if it didn't use FIXED sample sizes. (with chart that can be recomputed with simple math.)
No, the Rigol doesn't do that now.QuoteThe Rigol does NOT have to do this during sampling; it could sample at full speed (2GSa/s) into sample memory - then do random decimation (to simulate the current sampling rate) to display memoryI translate that into:
1) Sample into sample buffer at the fastest rate memory depth + time base allows (up to 2GSa/s, ofc)
2) decimate to screen
The Rigol does that now. And we agree it doesn't fix acquisition aliasing. So that leaves me suspecting I'm missing something in your description of what you'd like the Rigol to do.
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54520)In that picture, normally the sine wave is the true signal, and the black vs red crosses are what's written to sample memory. That produces results like on the Agilent.
My confusion is with your claim that the Rigol could theoretically anti-alias without doing the random decimation before storing samples into the waveform. If it can sample fast enough to store that sine wave into sample memory, it already doesn't alias. (If that sine wave is in sample memory, the aliased low frequency sine wave will never be what's on the screen.)
No, the Rigol doesn't do that now.QuoteThe Rigol does NOT have to do this during sampling; it could sample at full speed (2GSa/s) into sample memory - then do random decimation (to simulate the current sampling rate) to display memoryI translate that into:
1) Sample into sample buffer at the fastest rate memory depth + time base allows (up to 2GSa/s, ofc)
2) decimate to screen
The Rigol does that now. And we agree it doesn't fix acquisition aliasing. So that leaves me suspecting I'm missing something in your description of what you'd like the Rigol to do.
It certainly doesn't do RANDOM decimation, and I don't think it does decimation to simulate lower sampling frequencies either.
I've written this all before:
Random decimation (stochastic sampling) is the key to anti-aliasing. Beat frequencies (aliases) are formed by regular time interval sampling.
In the image, the black crosses and dotted line show regular decimation forming an alias frequency of the true frequency. The red crosses and line show irregular (random) decimation NOT forming an alias.
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54520)
rigol would have to re-architect the entire signal processing chain to do what you show. They would need make sure that the real signals are not affected by your special method and verify that interpolation still works correctly. The cure would be worse than the disease. It's far easier to just use the correct sampling rate (i.e. 2.5x highest frequency component).
I use SDRs daily and haven't heard anyone doing the stochastic sampling. This is not a common technique.
There is a better way to down sample using CIC and FIR decimating filters which take care of aliasing.
What you propose is a gimmick. There is one Agilent paper about it and that's it...
.. and it doesn't even mean they use this for anything but translating sample to display memory...
I use SDRs daily and haven't heard anyone doing the stochastic sampling. This is not a common technique. There is a better way to down sample using CIC and FIR decimating filters which take care of aliasing. What you propose is a gimmick. There is one Agilent paper about it and that's it, and it doesn't even mean they use this for anything but translating sample to display memory...I found Agilent's Patent for the (original) technique (http://www.google.com/patents/US5115189) - filed in 1991, and invented by Matthew S. Holcomb of the Hewlett-Packard Company. Pretty interesting... I've attached a few images from the Patent here.
I found Agilent's Patent for the (original) technique (http://www.google.com/patents/US5115189) - filed in 1991, and invented by Matthew S. Holcomb of the Hewlett-Packard Company. Pretty interesting... I've attached a few images from the Patent here.
Edit: Here is also another published paper about the technique. (http://www.hpl.hp.com/hpjournal/97apr/apr97a5.pdf)
From the paper:
"Instead of storing every Nth digitized point, the decimator can be designed to randomly select one out of every N points for storage. In the case of the 10.01-MHz input, the points placed in memory are points randomly selected from the ten cycles of the input that occur in every 1-s interval. This random sample selection technique effectively dithers the acquisition clock during the acquisition and prevents a beat frequency from developing.
This intra-acquisition dithering technique has been used throughout the HP546XX oscilloscope product line and again in the HP54645A/D products. The effect it has on aliasing is dramatic. Fig. 7a shows the aliased 10-kHz sine wave that is produced when a 10.01-MHz sine wave is sampled at 1 MSa/s. Fig. 7b shows the same display using the dithering process just described. The resulting display is a fuzzy band much like what would be seem on an analog oscilloscope, with all signs of an aliased waveform removed."
Edit2 @zibadun: So... still think 'my special method' is a gimmick? :) Apparently, it works quite well eliminating aliases, doesn't affect interpolation, and the reason there isn't lots of information about it in DSO literature is because HP patented it and Agilent doesn't seem to want to talk about it - instead using terminology like the following from the 5000/6000/7000 Series Oscilloscopes User’s Guide:
"At slower sweep speeds, the sample rate is reduced and a proprietary display algorithm is used to minimize the likelihood of aliasing."
Good research, marmad. So if Rigol does this they would need a license from hp/Agilent?
high performance FPGAs were not so common in 91 so may be this was the best hp could do. Time to move on? :)
( @Marmad, in RUU, if there is a space(s) behind the TCPIP srting, it wont connect )
( @Marmad, in RUU, if there is a space(s) behind the TCPIP srting, it wont connect )
There shouldn't be - the last that I heard about it was that it was working over LAN.
But with that extra space it cannot connect. maybe you can remove spaces.
@ Teneyes, dont use rectangle, use a window, as Hanning or Blackman@Wim Thanks Wim , that is Wonderful
So there seems to be an internal difference between the STANDARD 57600 baud decoding and the USERDEFINED 57600 baud decoding in the DS2072. So I tuned down the userdefined baudrate to approx. 56200 baud and at this baudrate the decoding showed exactely the same incorrect decoding like the STANDARD 57600 baudrate mode.Did you find what the higher limit of the UserDefined Baud rate also failed? 59,000?
To see what the tolerance band is.
Does it look like the program is sampling at 56,000 hz and not 57,600hz?
AS 14,400, 28,800, 57,600.... are called 14K 28K and 56K Baud
Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates jet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!
FFT
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54640;image)
Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates jet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!
Thanks, Markus. If you could figure out the full parameters of the bug (e.g. by testing the other rates so that we know the extent), we can add it to the FW bug list - and report it to Rigol.
[]The only one who decodes with the wrong baudrate timing is the 57600 one. This decodes with 56000 baud! [/b][/color]Hi Markus
the workaround for this kind of minor bug is quite easy: If you want to decode a 57600 baud serial string, just use the user defined baudrate and set this one to 57600 and everything is decoded fine!
SET THE RS232 TRIGGERING
wondering a bit about that picture, FFT center is 3kHz (so full span 6kHz) but FFT sample rate 10kSa/s ? That didn't make any sense. Or is that zoomed in and moved to left side?The display was 50Hz/div , span of the display =14 x 50 = 700Hz
therefore the display was from 2.65 - 3.35 KHz
"According to the Shannon Sampling Theorem"
The Rigol 'Center' is Not the Center frequency of the Scanned span as in a Spectrum Analyzer.
For Rigol DSOs (D2000,DS4000,DS6000),
The 'Center Freq.' is that Frequency that is set at the Center of the display.
Here is what My DS2072 shows at the left end of the FFT freq.spectrum , always 0 HZ
see display 2 (Rigol center =0kHz )
therefore the display was from 2.65 - 3.35 KHz
When the center of screen is marked as "center", then on left and right side there are exact the same amount of DIVs. As long the FFT is from one edge of the screen to the opposite edge, the center marking is center of full span, a typical center frequency. When you move the FFT to left or right direction then of course that "center" marking if showing the actual frequency on the center line location, so when you move to max. right it will be 0 (or whatever is set to start freq) and when you move to left the full span freq. So whatever you set as DIV, the center marking (again, when position not changed) is always the center frquency of the span. When you zoom in, still the same situation - as long the FFT has been not moved to right or left direction.
and the center is always a center of the screen, so when zero to full span the center marker is center frequency, and when range x to range y then it it still center frequency (of the specific range). Only when you move it's not center frequency anymore, which is exactly what it should be (but maybe you expecting something unexpected from Rigol? )
What DSO do you Have ? a Tekway??
FFT
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=54640;image)
wondering a bit about that picture, FFT center is 3kHz (so full span 6kHz) but FFT sample rate 10kSa/s ? That didn't make any sense. Or is that zoomed in and moved to left side?
This seems oddly reminiscent of trying to convince you that Rigol's High-Res mode produces the same results as everyone else.I'm probably just inviting more abuse onto myself, but the Rigol High-Res mode is so different from what I expected that I am curious to see comparisons.
I encountered a mysterious issue when serial decoding a well known 57600 baud serial datastream. The encoding showed me some wrong characters and so I thought maybe the oscillator of the selfmade sending µcontroller device is out of spec. and I tried the "user selectable" baudrate on the DS2072 and at first I used the same baudrate there too, that's 57600. And - I don't know why - when I switched to the user defined baudrate with exactely the same baudrate (57600) the decoding was perfect :)! So there seems to be an internal difference between the STANDARD 57600 baud decoding and the USERDEFINED 57600 baud decoding in the DS2072. Does anybody have any idea or could verify this issue on his Rigol DSO.
It's unfortunate that all of this discussion of the 2000 series scopes is contained in a single 104 page thread.
It's unfortunate that all of this discussion of the 2000 series scopes is contained in a single 104 page thread.
Why? I think this whole thread is quite constructive!
In other news, my 2072 just got past US-->Canada customs last night. I hope it comes soon!
[ if you are a new user, it's so hard to skim through the entire thread.For me, I went thru all pages and deleted 5 pages worth of Posts,
I wonder if there is an efficient way to process all this info. May be the most informative comments should be flagged somehow by readers to make them easier to find.
It's unfortunate that all of this discussion of the 2000 series scopes is contained in a single 104 page thread.
A wiki is a good solution for this kind of thing.
I don't have time to maintain one, which tends to be everyone's problem with this kind of thing, but if someone wants to step up and manage the content I am willing to host one.
A wiki is a good solution for this kind of thing.
I don't have time to maintain one, which tends to be everyone's problem with this kind of thing, but if someone wants to step up and manage the content I am willing to host one.
I think it is mainly due to hardware... Well, they have no custom ASIC.
A wiki is a good solution for this kind of thing.
I don't have time to maintain one, which tends to be everyone's problem with this kind of thing, but if someone wants to step up and manage the content I am willing to host one.
It could go on the EEVblgo wiki, but of course someone needs to maintain it and organise it which is a massive job to do it properly with different pages for all the issues and content that interest people.
Yes is possible, and therefore the gds-2000a series uses a [[500Ms ADC x2] x2] to reach about 100,000 wfm/s. But I do not understand why the Rigol DS2000 not keep the 50,000 wfm/s for time base < 20ns.
This could be improved via firmware?
You don't have your facts straight: the GDS-2000A only does it's 80k wfrm/s maximum with a 200MSa/s rate - 10 times lower than the 2GSa/s maximum - so 10 times lower the BW. In fact, at 2GSa/s, with it's small 1k sample size, the 2000A is not significantly faster than the Agilent or Rigol (slower at many settings) - and likely slower when using the 1M sample size (no one has done tests yet).
Also, the GDS-2000A series update rate drops dramatically < 50ns - much more than the Rigol.
I rely on this table:
Could you please explain to me why 50,000 wfs are only reached at 20 ns and it decrease to lower base time? It brings me head ^-^Something to do with the way that Rigol has tuned the system. If you look at wfrm/s rates of other DSOs (http://cp.literature.agilent.com/litweb/pdf/5989-7885EN.pdf), it's not uncommon for the speed to reach a peak at a certain time base, then drop off.
Could be the Wfrm/s improved via firmware?I doubt it (at least, not by much); I'm sure Rigol has already spent much time working to get as much speed as possible out of the design.
Just unpacked my 2072!
Looks like it's running Software Version 00.00.01, and Hardware Version 1.0.
Just unpacked my 2072!
Looks like it's running Software Version 00.00.01, and Hardware Version 1.0.
Mine:
Software version: 00.01.01
Hardware version: 1.0
Yours is fast and loud? :-DD
That upper table is nonsense - Kiriakos didn't use the correct measuring equipment for measuring < 50ns - he claims the DSO is much faster than even Instek claims it is. ;DGrego's video (See at ~ 12 min):
You can see the real wfrm/s @ <50ns in Grego's video when he uses a Picoscope to measure the frequency.
CodyShaw:
Nothing bad, I'm just kidding, my apologies. :)
In my DS2072 the fan is quite noisy (loud). But here the temperature is 30 ° C, perhaps the fan is regulated by temperature (fast).
"Let the future tell the truth ...
To UberSteve:
What model of probes was bringing?
To UberSteve:
What model of probes was bringing?
As in are they rp3300 or rp3300a ?
The "a" version are not switchable between x1 and x10
--
Darryl
Hi All!
New DS2072 owner here! Unit arrived today from Emona Aus. Unit is apparently new stock just arrived from China and reports the following info in the System Information screen:
Serial: DS2A15270XXXX
Software version: 00.01.01.00.02 (latest I believe?)
Hardware version: 1.0.1.0.0
FPGA version:
SPU 03.01.05
WPU 00.06.05
CCU 12.29.00
MCU 00.05
Huge step up from my Bitscope... :D
Thanks to all that have contributed to this thread, it's the main reason I decided on the DS2000. :-+
-Steve
How about if we create a topic about the new/future verison/model of the Rigol´s oscilloscopes? ^-^
Including: DS1000-Z, DS2000-S, DS2000-Z, etc.
With specifications, rumors and other.
What would be the suitable name for this topic?
How about if we create a topic about the new/future verison/model of the Rigol´s oscilloscopes? ^-^
Including: DS1000-Z, DS2000-S, DS2000-Z, etc.
With specifications, rumors and other.
What would be the suitable name for this topic?
Rigol DS-Z Specs, Rumors, and Other (Q&A)
To UberSteve:
What model of probes was bringing?
As in are they rp3300 or rp3300a ?
The "a" version are not switchable between x1 and x10
--
Darryl
My serial starts DS2A1521xxxxx so thats like may 2013, about right i'd say for a 4th june 2013 assembled and tested ready to go.
Darryl
Hi guys, mine came with the RP3300A, fixed 10x 300Mhz probes. I contacted Emona about it today, and they said that is what Rigol are shipping now.As mentioned earlier (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg258647/#msg258647) in this thread, all the materials online - at Rigol's main site and elsewhere (http://www.rigol.com/prodserv/DS2000/document/)- list the RP3300 as the probes that come with the DSO (they even have the RP3300 User's Guide posted!) - so you are well within your rights to demand an exchange if you want to - because the RP3300 is what is advertised as coming with the DSO.
Anyway, there were also only 1:10 150MHz probes with my 70MHz scope DSOX2002A.
Anyway, there were also only 1:10 150MHz probes with my 70MHz scope DSOX2002A.
Yes, but we all have 200MHz 70MHz scopes. :)
Thanks for the info gilbjd. By now the range is:
DS2A1520xxxxx (Week 20, 2013) -> RP3300
DS2A1527xxxxx (Week 27, 2013) -> RP3300A
Wow... I think we have now the exact moment in which the change was made.
New range is:
DS2A1520xxxxx (Week 20, 2013) -> RP3300
DS2A1521xxxxx (Week 21, 2013) -> RP3300A
Thanks for the info darrylp and gilbjd.
how do you analyze spi bus with this scope? 2 channel for clock data in and data out?
Wow... I think we have now the exact moment in which the change was made.
New range is:
DS2A1520xxxxx (Week 20, 2013) -> RP3300
DS2A1521xxxxx (Week 21, 2013) -> RP3300A
Thanks for the info darrylp and gilbjd.
That was one last ditch effort to bandwidth limit the scope ;)
the rp3300a probes are still 300MHz, just down from the rp3300 at 350MHz.
--
Darryl
this qestion is aimed for users who play with this scope for a relative long time and even have an agilent x2k or x3k series scope as comparison.
how do you analyze spi bus with this scope? 2 channel for clock data in and data out?
any quirks regarding the longevity of the scope. im seriously looking at these as the prices is damn good, even the lowest agilent model is twice the price
sorry for not reading trough a 107 page topic which i wasnt interested in before
Wow... I think we have now the exact moment in which the change was made.
New range is:
DS2A1520xxxxx (Week 20, 2013) -> RP3300
DS2A1521xxxxx (Week 21, 2013) -> RP3300A
Thanks for the info darrylp and gilbjd.
That was one last ditch effort to bandwidth limit the scope ;)
the rp3300a probes are still 300MHz, just down from the rp3300 at 350MHz.
--
Darryl
Wow... I think we have now the exact moment in which the change was made.
New range is:
DS2A1520xxxxx (Week 20, 2013) -> RP3300
DS2A1521xxxxx (Week 21, 2013) -> RP3300A
Thanks for the info darrylp and gilbjd.
That was one last ditch effort to bandwidth limit the scope ;)
the rp3300a probes are still 300MHz, just down from the rp3300 at 350MHz.
--
Darryl
Would it be possible to place a picture of the rp3300a probe?, I looked at the rigol site, but could not find any.
That looks like a nice probe, not so clumsy as the rp3300
Looking again through Dave's teardown photos of the DS2000, and I noticed a pad labelled 'VIDEO OUT' and some unpopulated footprints (http://www.flickr.com/photos/eevblog/8022112817/#in/set-72157631618295437/lightbox/) near the first FPGA (connected to the ADC and sample memory).
I'm really curious about this... has anyone done any probing there - or have an idea what it may be for?
Looking again through Dave's teardown photos of the DS2000, and I noticed a pad labelled 'VIDEO OUT' and some unpopulated footprints (http://www.flickr.com/photos/eevblog/8022112817/#in/set-72157631618295437/lightbox/) near the first FPGA (connected to the ADC and sample memory).
I'm really curious about this... has anyone done any probing there - or have an idea what it may be for?
is that 14 way header a known jtag for something ? or is it a VGA header ? which would have 5 pins ?
Yes, it's very strange,Also the video output seems to return to the fpga. No return, out fron the FPGA!
To the 10 pin IC reach from the right three tracks:Analog RGB? or Digital?Analog Sync!Very strange. ???
Anyone know if you can get a front dust cover for the DS2000? I've seen one for the DS4000...
Are you sure the firmware file is correctly named as it was originally?I just extracted it from the zip file, was that not right?
I had mine renamed (to help me know what firmware version it was) and forgot to rename it back and had the exact same behavior.Well, the problem is, that the scope locks up as soon as i plug in even en empty USB drive :-(
Are you sure the firmware file is correctly named as it was originally?I just extracted it from the zip file, was that not right?I had mine renamed (to help me know what firmware version it was) and forgot to rename it back and had the exact same behavior.Well, the problem is, that the scope locks up as soon as i plug in even en empty USB drive :-(
Does the scope need some crazy formatting? I just formatted with linux command line...i.e. FAT32, single partition on DOS compatible MBR
Try another USB drive.Yea, it was stupid of me to trust in the scopes ability to read my USB drives - I tried all of them after your suggestion (5 or so) and sure enough the crappiest half torn apart USB drive from china worked. The irony! Thank you very much!
Funny, last time i did a self-cal, on the end i got a message, not a reboot.
the message was, that is was ended, and asked please reboot.
that was nice and polite of the DSO.
First i thought i was because of the new FW, but today i did a self-cal,
and it di not show the message, but did the reboot as always..
Have somebody here seen this message also..?
Yes, it's very strange,Also the video output seems to return to the fpga. No return, out fron the FPGA!
To the 10 pin IC reach from the right three tracks:Analog RGB? or Digital?Analog Sync!Very strange. ???
http://www.ti.com/lit/ds/symlink/lmh1980.pdf (http://www.ti.com/lit/ds/symlink/lmh1980.pdf)
Is a analog video sync separator for NTSC, PAL: 480I/P, 576I/P, 720P, 1080I/P/PsF
So it does have some sense. But why is unpopulated? :box:
Thanks for the info gilbjd. By now the range is:
DS2A1520xxxxx (Week 20, 2013) -> RP3300
DS2A1527xxxxx (Week 27, 2013) -> RP3300A
Soon after, my DS2072 "gave off the magic smoke" :-BROKE No more playing 'till it gets replaced :'(
Serial: DS2A15270XXXX
Software version: 00.01.01.00.02 (latest I believe?)
Hardware version: 1.0.1.0.0
DS2A1527xxxxx (Week 27, 2013) -> RP3300A
Serial: DS2A1527XXXXX
Software version: 00.01.01
Hardware version: 2.0
DS2A1520xxxxx (Week 20, 2013) -> RP3300
QuoteI've noticed that with the series DS2A1527XXXXX RIGOL not only changed the probes.Hi All,
UberSteve: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg263616/#msg263616 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg263616/#msg263616)
Serial: DS2A15270XXXX
Software version: 00.01.01.00.02 (latest I believe?)
Hardware version: 1.0.1.0.0
Leonard Tatzig: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg269946/#msg269946 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg269946/#msg269946)
Serial: DS2A1527XXXXX
Software version: 00.01.01
Hardware version: 2.0
Carrington: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg264041/#msg264041 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg264041/#msg264041)
DS2A1520xxxxx (Week 20, 2013) -> RP3300
DS2A1527xxxxx (Week 27, 2013) -> RP3300A
My DS2072 I got yesterday came with the switchable RP3300 probes.
Serial: DS2A1509XXXXXX ( (Week 9, 2013 ?)
Software version: 00.00.01
Hardware version: 1.0
Probes -> RP3300
No information about FPGA version
Is the latest firmware?
Why version numbers are in short form?
Best regards,
up8051
Software version: 00.00.01.00.05
Just checking to see if you could feed a string such as 01000001 which represents “A” in ASCII (by simply turning on and off voltage at some level (maybe 3.3V or 5V) over periodically uniform time intervals and have the 2072 decode 1s and 0s into the letter A? Thanks!
Just checking to see if you could feed a string such as 01000001 which represents “A” in ASCII (by simply turning on and off voltage at some level (maybe 3.3V or 5V) over periodically uniform time intervals and have the 2072 decode 1s and 0s into the letter A? Thanks!
What?
I guess you can decode any signal into ASCII, but you need either to specify the baudrate (like in RS-232) or you need a data and a clock line.
It also has something called parallel decode, I'm still puzzled how that is going to work with just 2 channels...
- just curious to see if anyone wants to confirm this is possible by giving it a try
- just curious to see if anyone wants to confirm this is possible by giving it a try
Here you go:
Is there a link which gives software (WINDOWS) and instructions a neophyte hacker could follow?
DS2000 series owners check your heat sink clips!
After using my new DS2072 for several days. I noticed a rattling sound when I moved it. Having heard of this clip retainer issue, I decided to investigate, but didn't want to void the warranty. Luckily the heatsinks and clips can all be seen from the side ventilation holes. I found on clip and one retainer were missing. After lots of shaking, I was able to get both of the missing parts position by the ventilation holes and pulled them out with a tweezers.
It appears the retaining loop was soldered but not good enough for the heavy spring tension on it.
<snip>
After a long absence from posting in this favorite thread, I'm back! I wish I had more time to post here, but for now just a cautionary note...
I've just experienced the same issue as martinv describes above. I've been using my scope quite a bit recently, and aside from it warming up, there have been some very hot days in SoCal recently. I was working and all of a sudden heard a loud metallic clank sound. I had no idea where it came from, but today when I moved my scope I heard a rattle inside and recalled this heat sink clip issue.
I followed Mike's YouTube video to circumvent the warranty sticker, and opened up the unit. Sure enough the spring was not in place. I could not find the retaining clip; presumably it fell out when I was opening up the unit. I believe the metallic clunk I heard was the retention clip getting pulled out and hitting the power supply cover.
See attached pic (warning: very high res!).
Just wanted to post a reminder that this is something to be on the look out for if you hear rattling in your scope! Obviously not good to have metal pieces loose around in there...
Take care folks!
Just wanted to post a reminder that this is something to be on the look out for if you hear rattling in your scope! Obviously not good to have metal pieces loose around in there...Hi Sparky
Check the fan. On my scope one of the loose parts stuck to the fan motor and was held there by the motor magnets so shaking didn't dislodge it.
Very stupid to rely on the solder alone to hold it in the board. At the least I would make a new one out of a paper clip cut in half, pushed through the hole and bent over on the underside before soldering back in the hole.
Sh!t , a rattle in my DS2072, and one retaining clip fell out :--
and another one rattling, I got it near the vent and working on getting that clip out, :-- :--
Now where are the loops??
What will you do?
Fix it w/rebar-wire;D or an RMA??? I have already sent my DSO back Once.
DS2A1425xxxxx
I noticed a bug(?) when decoding RS232 communication with the DS2072:
Sh!t, a rattle in my DS2072, and one retaining clip fell out :--
and another one rattling, I got it near the vent and working on getting that clip out, :-- :--
I get the feeling this issue is more frequent than first thought! In your case, it is both retaining springs that have come loose? I could not get the spring out through the vent and had to take it apart.
Sh!t, a rattle in my DS2072, and one retaining clip fell out :--
and another one rattling, I got it near the vent and working on getting that clip out, :-- :--
I get the feeling this issue is more frequent than first thought! In your case, it is both retaining springs that have come loose? I could not get the spring out through the vent and had to take it apart.
Well, I got 2 springs and 2 hoops out
See pic for fishing tool.
Everyone watch-out
Do I dare turn it on and have the heat sinks fall off?
Has anyone opened a DS2000 and seen any improvement in the spring-clamp anchors?
I noticed a bug(?) when decoding RS232 communication with the DS2072:
@ Gecko
Use RS232 Triggering
So I made the screenshots for you. I think that it's OK. No aliasing at all.This seems oddly reminiscent of trying to convince you that Rigol's High-Res mode produces the same results as everyone else.I'm probably just inviting more abuse onto myself, but the Rigol High-Res mode is so different from what I expected that I am curious to see comparisons.
How do other scopes (especially the Agilent) handle a 40mVpp 100kHz sine wave at 1ms/div 10mV/div? Both max memory depth and 1MSa/s.
I thought I saw a response curve for a 2102 somewhere in the 111 pages of postings.
The reason I ask is that I want to compare it to what I'm seeing with a 1102E which I'm unhappy with.
The picture below was taken right at the output of an HP8657B terminated, measured with the supplied probe at 10x. The voltage level is 1 V. RMS. Shown for comparison is the same test setup with a Tektronix 2225 50MHz scope..
I had ordered a 2072 for hacking but I can't find anybody who can give me a firm shipping date in the US.
Has the "2102" got a flatter response curve like the TEK2225 . A 2+ db rise shown by the DS1102E is pretty unacceptable in my opinion.
I was trying to display oscillofun Oscillofun (https://www.youtube.com/watch?v=o4YyI6_y6kw#) on my Rigol DS2072 (aka DS2202) , hacked and running the latest firmware.
It seems it only displays normally with a sample rate of 1GSa/s and a memory depth of only 700 pts. If I try to increase the memory depth, the display gets very very slow at updates (basically unusable).
I had ordered a 2072 for hacking but I can't find anybody who can give me a firm shipping date in the US.
Not even ordered. I believe the freq response of the 2xxx series scopes is given here.Yes, I know, is just to have another reference.
...
Brian
Has this screen is a transparent EMI / RFI shielding foil? It seems a simple sheet of polycarbonate or something.I'm not the only one who thinks so.
http://www.flickr.com/photos/eevblog/8022302444/#sizes/o/in/photostream/ (http://www.flickr.com/photos/eevblog/8022302444/#sizes/o/in/photostream/)
It seems to me that the firmware bug
from page one of this massive thread
" 14) Bus decoding does not decode the full ASCII set. Missing characters:[ . , : ; - _ ! " § $ % & / ( ) = ? ] - everything between square brackets (except spaces).
[FW v.00.01.00.02? / FW v.00.01.00.05 / FW v.01.00.00.03 / FW v.01.01.00.02]"
has now been fixed in fw 00.01.01.00.02
At least in my testing at 9600 baud the DS2072 of mine shows nearly all characters from 32 (dec) to 47 (dec) inclusive in an accurate way.
See attached screen print.
(Test conditions: Arduino, softwareserial library using pin 4 for TX data. I toggled pin 10 to give a good trigger point for the DSO, this is shown in ch2 trace.)
So this is good news, eh?
This seems oddly reminiscent of trying to convince you that Rigol's High-Res mode produces the same results as everyone else.I'm probably just inviting more abuse onto myself, but the Rigol High-Res mode is so different from what I expected that I am curious to see comparisons.
How do other scopes (especially the Agilent) handle a 40mVpp 100kHz sine wave at 1ms/div 10mV/div? Both max memory depth and 1MSa/s.
Here's the Rigol images for comparison:
From what I can see, there is fw bug there. The 40mV of wave doesn't cover four divisions neither at high or low resolution.Those were both high res. The difference was the sample rate. When I used "Normal" instead of "High Res" Acquisiton, the waveform was fine. There's some kind of aliasing going on, taking the 40mV, 100kHz signal and displaying it (at 1GSa/s) as 2mV, 2.33kHz, or (at 1MSa/s) as 10mV, 12kHz. Stopping the scope and zooming in, the 100kHz, 40mV waveform will be there: I'm pretty sure the Ultravision "High Res" happens when converting the acquired samples to display and does not affect acquisition at all.
By "no input" do you mean grounded or floating?
Quiet Thread now, everyone gone to hacksville ;DJust wanted to post a reminder that this is something to be on the look out for if you hear rattling in your scope! Obviously not good to have metal pieces loose around in there...Hi Sparky
Sh!t , a rattle in my DS2072, and one retaining clip fell out :--
and another one rattling, I got it near the vent and working on getting that clip out, :--
Just an Update
Rigol issued an RMA to me
Rigol also sent me a prepaid shipping Label with tracking
I tracked the shipment to Rigol and 40 hours after it arrived at Rigol (NA) it was shipped back to me.
Fast service for me. .
kizzap, try pushing the knob you are rotating.
Set the coupling to AC mode.
Pushing the knob I am turning (the smaller knob for the channel) puts zero volts onto the centre of thehorizontalvertical division. Maybe I need to change a setting somewhere.
Pushing the knob I am turning (the smaller knob for the channel) puts zero volts onto the centre of thehorizontalvertical division. Maybe I need to change a setting somewhere.
For when DC coupling is important, (from memory) there is a setting in the Utility->System menu called "VerticalExp" which is "Ground" by default. I use "Center". With it set to Center, whatever is in the center of the screen stays there as I change the vertical resolution. So say I want to watch a 5V signal. I start at 2V/div, spin the little knob to get the 5V signal on the center graticule, then start turning the big knob to zoom in, making small adjustments to the little knob as needed. There is a limit to how far you can zoom in this way. You can zoom in more with a 10x probe than with a 1x probe (since the maximum offset doesn't get scaled.) Getting the signal centered this way takes hardly any time at all, though it's certainly not quite as easy as pressing a single button.
I've been doing this a lot lately, as I'm looking at small, low frequency stuff (which would be lost in the noise with ac coupling), putting the scope into roll mode at like 2s/div and watching the trace go by.
How could BMPs be faster than PNGs? They are often ~100x bigger - and writing to an external device usually requires more time than processing - although I can't say I've actually timed saving BMPs on the DS2000. Also, I don't know if the brand of USB stick you're using (or FW 01.00.02) affects save/transfer rates - but my timed speeds are:
My Rigol takes ~15 seconds to write a PNG file to a USB stick.
The Rigol UltraVision Utilities take ~2.3 seconds using USB to transfer, convert & save a BMP (all bitmap transfers from the DSO are BMP - conversion to other formats is handled by RUU).
I find using RUU just great , capture DSO data to files quickly on my PC then quicky forward to reports, E-mail.
Also RUU captures the Menu so the pictures explains the Setup
Those were both high res. The difference was the sample rate. When I used "Normal" instead of "High Res" Acquisiton, the waveform was fine. There's some kind of aliasing going on, taking the 40mV, 100kHz signal and displaying it (at 1GSa/s) as 2mV, 2.33kHz, or (at 1MSa/s) as 10mV, 12kHz. Stopping the scope and zooming in, the 100kHz, 40mV waveform will be there: I'm pretty sure the Ultravision "High Res" happens when converting the acquired samples to display and does not affect acquisition at all.Interesting, I see it's the same with the DS2000. I've come to a similar conclusion about High Res acquisition mode in my experiments with the DS1000Z - https://www.eevblog.com/forum/blog/eevblog-522-rigol-ds1000z-oscilloscope-quick-look/msg331537/#msg331537 (https://www.eevblog.com/forum/blog/eevblog-522-rigol-ds1000z-oscilloscope-quick-look/msg331537/#msg331537)
Interesting, I see it's the same with the DS2000. I've come to a similar conclusion about High Res acquisition mode in my experiments with the DS1000ZThis was already discussed in-depth in this thread back around this post (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg246407/#msg246407).
I feel Rigol are cheating somewhat. Instead of oversampling and filtering at acquisition time they are simply doing it as a math operation at display rendering time. This means it further low-pass filters the traces before displaying them. So, not actually an acquisition mode at all. :(Cheating compared to who? From the material I've read, at least both Agilent and Tektronix (and perhaps others) do it the same way. This just seems like another case of a feature not working the way that you expected (or prefer) that it worked.
So yes, just like other manufacturers' implementations of High Resolution mode, Rigol's implementation acts exactly the same way - and will filter the waveform (and cause anti-aliasing if the effective sample rate is reduced too far for the incoming signal).
The complaint isn't just that "high res" happens post acquisition, but that Rigol's "one pixel per column" algorithm aliases out components that are too high frequency for the current time base.
See that the sample rate is 1Gsa/s in my screenshot, which should leave plenty of effective sample rate for a 100kHz signal.
Agilent produces the results I expected, and with far less sample rate.
As far as I can see, the Rigol is not acting the same way as the Agilent.
What's the point of using high resolution mode for display of an envelope? If you use normal aquisition mode the Rigol display looks exactly the same as Agilent and accomplishes all you could wish for.That example was to demonstrate the difference between algorithms; to demonstrate that Rigol's display with High Res enabled can be very different than other scopes. If someone expects high res to act like normal but with a lower sample rate and "high res" samples, then they can be surprised on the Rigol.
"within the same acquisition" means oversampling. Oversampling is done at acquisition time before storing each high-res sample.
Yes there is a filtering effect, but this is firstly applied to the "oversampled" data rather than the final trace samples.
Naturally, now that I know more what it does, it can be a useful tool. One just has to be aware that at 1ms/div + high res, the effective bandwidth (on screen) is like 5kHz.
Rigol's method stores only 8 bit samples. There is never any oversampling. It's not an acquisition mode at all. Any "high-res'ing" is derived, at display time, from what is stored.Again, it makes NO DIFFERENCE whether you perform the math on already stored samples or samples as they're acquired. It's just math. I think you're hung up on believing 'acquisition mode' means that it has to happen between acquisition and sample memory - as opposed to acquisition and display.
It can only add low-pass filtering on top of what's stored, and what's more it doesn't even say how severe this filter is let alone have any parameters.As I mentioned in my previous post, I ran some tests on the Rigol to determine the LPF bandwidth of the successive sample averaging - and it's quite predictable.
Agilent's method... need not create any extra filtering beyond the stored sample rate ... and probably ensures it never does by adjusting the bit depth accordingly.It automatically creates filtering by virtue of doing successive sample averaging. This is a GIVEN of the technique. Says Agilent: "High Resolution mode limits the oscilloscope's real- time bandwidth because it effectively acts like a low-pass filter."
The maths is not the problem. It's the stored trace that's the problem. One method perform oversampling and filters only to the Nyquist point and stores those high-res samples as the trace. The other method just stores 8-bit samples straight from the ADC ... which is nyquist limited and still only 8 bits. Any further processing cuts-off even lower.
I bet Rigol's method could be, but it doesn't let you, flipped on and off - refreshing the display in either Normal or High Res without any new trace acquisitions.I think this is a clue to Evan's issue. As far as I know, the only time Rigol doesn't let you change the High Res setting on existing data is in record mode. It absolutely does let you change the setting when stopped normally.
As far as I know, the only time Rigol doesn't let you change the High Res setting on existing data is in record mode. It absolutely does let you change the setting when stopped normally.
There's a practical difference between the two approaches and it affects record mode: You get to store fewer waveforms if you want the high res averaging.
I'm not sure I understand you: on my DSO I haven't noticed any difference in the maximum frames I can record when using High Res mode.I admit I'm operating on some assumptions there; I'll do some experiments in the next day or two and get back to you.
I admit I'm operating on some assumptions there; I'll do some experiments in the next day or two and get back to you.
I wish there were owners of that Agilent DSO who did testing
I foresee Agilent dropping out of the lower end market.
See that the sample rate is 1Gsa/s in my screenshot, which should leave plenty of effective sample rate for a 100kHz signal.@Galaxyrise: Interestingly, the reason the 100kHz signal is so attenuated in the image you posted (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg331910/#msg331910) is that it falls almost directly in the first null point of the stopband @ 1ms/div (see image above which shows the null points of an averaging filter (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg332716/#msg332716)). Compare it to this image using the same settings as you, but with a 150kHz sine wave - which falls beyond the first null point (although still attenuated by -12dB):
Time base - | Bandwidth (-3db) - | First null in stopband |
10ms/div | ~4.3kHz | ~10kHz |
5ms/div | ~8.6kHz | ~20kHz |
2ms/div | ~21.6kHz | ~50kHz |
1ms/div | ~43.3kHz | ~100kHz |
500us/div | ~86.6kHz | ~200kHz |
200us/div | ~173.2kHz | ~400kHz |
100us/div | ~346.4kHz | ~800kHz |
50us/div | ~692.8kHz | ~1.6MHz |
20us/div | ~1.38MHz | ~3.2MHz |
10us/div | ~2.77MHz | ~6.4MHz |
5us/div | ~5.54MHz | ~12.8MHz |
Except, of course, a DSO is often storing the trace at no where near it's ADC's max sample rate. This is when oversampling kicks in. An oversample situation is with respect to the stored trace, not the ADC. When the trace is stored at, say, one sample per minute there is certainly some room for oversampling wouldn't you think?The maths is not the problem. It's the stored trace that's the problem. One method perform oversampling and filters only to the Nyquist point and stores those high-res samples as the trace. The other method just stores 8-bit samples straight from the ADC ... which is nyquist limited and still only 8 bits. Any further processing cuts-off even lower....
There is no such thing as oversampling when the DSO is already sampling at it's maximum rate. I can't speak about the DS1000Z, but the Rigol DS2000 series can sample at it's maximum 2GSa/s rate down to 2ms/div - it doesn't need to oversample because the sample memory already contains all possible samples that could be captured in a given time frame.
The setting is editable but it doesn't action until the next capture. I was only giving an example of what could happen because the stored trace is no different between Normal mode and High Res mode. Which is not the case on scopes that have a true high-res acquisition mode.I bet Rigol's method could be, but it doesn't let you, flipped on and off - refreshing the display in either Normal or High Res without any new trace acquisitions.I think this is a clue to Evan's issue. As far as I know, the only time Rigol doesn't let you change the High Res setting on existing data is in record mode. It absolutely does let you change the setting when stopped normally.
There is a distinct acquisition mode change here, it changes the content of the stored samples. The Rigol's don't attempt to perform this function and therefore are not implementing a high-res acquisition mode.
I was only giving an example of what could happen because the stored trace is no different between Normal mode and High Res mode. Which is not the case on scopes that have a true high-res acquisition mode.
I can assure you this is a big issue for everyone. Rigol's High Res mode should be avoided. It will create problems if used.
High-res acquisition mode operates in oversampling only
Rigol doesn't do this, so, although it is high-res, it's not an acquisition mode.
By limiting the BW seems to be designed for audio applications, or something like that. For now I never used this mode.See that the sample rate is 1Gsa/s in my screenshot, which should leave plenty of effective sample rate for a 100kHz signal.@Galaxyrise: Interestingly, the reason the 100kHz signal is so attenuated in the image you posted (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg331910/#msg331910) is that it falls almost directly in the first null point of the stopband @ 1ms/div (see image above which shows the null points of an averaging filter (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg332716/#msg332716)). Compare it to this image using the same settings as you, but with a 150kHz sine wave - which falls beyond the first null point (although still attenuated by -12dB):
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=67767)
Playing around with sending sweeps to the Rigol while in High Res mode reveal the nulls that exist in the stopband at each time base setting (while using 14MB/AUTO mem depth). These null points are at the averaging frequency (sample rate/number of samples averaged) and its harmonics.
Bandwidths @ different time base settings in High Res mode on DS2000
Time base Bandwidth (-3db) First null in stopband 10ms/div ~4.3kHz ~10kHz 5ms/div ~8.6kHz ~20kHz 2ms/div ~21.6kHz ~50kHz 1ms/div ~43.3kHz ~100kHz 500us/div ~86.6kHz ~200kHz 200us/div ~173.2kHz ~400kHz 100us/div ~346.4kHz ~800kHz 50us/div ~692.8kHz ~1.6MHz 20us/div ~1.38MHz ~3.2MHz 10us/div ~2.77MHz ~6.4MHz 5us/div ~5.54MHz ~12.8MHz
Bandwidths @ different time base settings in High Res mode on DS2000
Time base Bandwidth (-3db) First null in stopband 10ms/div ~4.3kHz ~10kHz 5ms/div ~8.6kHz ~20kHz 2ms/div ~21.6kHz ~50kHz 1ms/div ~43.3kHz ~100kHz 500us/div ~86.6kHz ~200kHz 200us/div ~173.2kHz ~400kHz 100us/div ~346.4kHz ~800kHz 50us/div ~692.8kHz ~1.6MHz 20us/div ~1.38MHz ~3.2MHz 10us/div ~2.77MHz ~6.4MHz 5us/div ~5.54MHz ~12.8MHz
Thanks for this table, BTW. That's very useful info to have, and not provided by any of the vendors, to my knowledge.
By limiting the BW seems to be designed for audio applications, or something like that. For now I never used this mode.Anti-aliasing is also done sample->display time, and it's almost useless since the "normal" sample->display decimation algorithm rarely introduces aliasing. And in high res, it actually tends to make aliasing worse! What most people expect anti-aliasing to do, ie minimize sample-rate induced aliasing, Rigol's anti-aliasing cannot do. It can make the display a little nicer looking sometimes, but I think it's generally a waste of update rate.
I am more interested in the ANTI-ALIASING option, I would like to know how RIGOL implemented it, what sampling method used etc...
Anti-aliasing is also done sample->display time, and it's almost useless since the "normal" sample->display decimation algorithm rarely introduces aliasing. And in high res, it actually tends to make aliasing worse! What most people expect anti-aliasing to do, ie minimize sample-rate induced aliasing, Rigol's anti-aliasing cannot do. It can make the display a little nicer looking sometimes, but I think it's generally a waste of update rate.
I am more interested in the ANTI-ALIASING option, I would like to know how RIGOL implemented it, what sampling method used etc...@Carrington
By limiting the BW seems to be designed for audio applications, or something like that.
I am more interested in the ANTI-ALIASING option, I would like to know how RIGOL implemented it, what sampling method used etc...
This makes perfect sense since the stored frames are the waveforms constructed from the already-averaged samples (with the original samples no longer available). OTOH, when the DSO is stopped (when not in Record), the last group of captured samples still sits in sample memory - so the DSO can apply (or not apply) the averaging to the display memory by turning High Res on or off.I had assumed that the raw samples were written to segmented memory, which would mean that the scope had to apply the high res algorithm to segmented memory in order for it to work at all in that mode, and thus there was no good reason not to enable changing between normal and high res on recorded data.
I don't mean that turning on high res changes the record length for a particular memory depth, I mean that you have to use a larger memory depth to give the algorithm enough samples to average. If I want to capture 14k points per waveform, and I want each of those points to be the result of averaging >8 samples, then I actually need to capture at 140k pts.QuoteThere's a practical difference between the two approaches and it affects record mode: You get to store fewer waveforms if you want the high res averaging.
I'm not sure I understand you: on my DSO I haven't noticed any difference in the maximum frames I can record when using High Res mode.
I'd be curious to know what the bandwidth of the High Res mode is at each time base setting between 50us/div - 10ms/div in the Agilent 2000 X-Series.I tested that last night on my 2000X, which has the optional 1M memory option.
I tested that last night on my 2000X, which has the optional 1M memory option.
I used the built-in waveform generator, which only goes to 20 MHz, so I couldn't get the last few measurements.
High-res acquisition mode operates in oversampling only
No, it CAN use oversampling - but it's not a prerequisite. Just look at the specs for the Agilent 2000 X-Series High Res mode at the following time base settings:
...
Successive sample averaging ("High Res") is purely a math operation on either incoming or stored samples - oversampling can be used, but it's not a necessity.
QuoteRigol doesn't do this, so, although it is high-res, it's not an acquisition mode.
Oh, so now you're admitting that the Rigol IS doing successive sample averaging? Just that it's not an "acquisition mode"? ;D
I can't get the table to align nicely. I hope it is readable anyway.
Time base Bandwidth (-3db) - First null in stopband
10ms/div ~34kHz ~77kHz
5ms/div 67.8kHz 153.6kHz
2ms/div 169.6kHz 384.0kHz
1ms/div 339.0kHz 768.0kHz
500us/div 676.7kHz 1.536MHz
200us/div 1.689MHz 3.840MHz
100us/div 3.364MHz 7.680MHz
50us/div 6.704MHz 15.36MHz
20us/div 16.87MHz ?
10us/div ? ?
5us/div ? ?
It is a prerequisite for high-res acquisition.
I've never said otherwise. The only comment I've made is that the maths is not the issue. The real issue is the lack of oversampling and the filtering cutting into the displayed trace.
....and what's more (Rigol) doesn't even say how severe this filter is let alone have any parameters.
...(Agilent) need not create any extra filtering beyond the stored sample rate ... and probably ensures it never does by adjusting the bit depth accordingly.
That's the difference (between Agilent and Rigol) and it's significant.
I don't believe there is anything called auto memory. At least I haven't found it yet.:) Ok.
I don't believe there is anything called auto memory. At least I haven't found it yet.See at min:2.29.
I don't believe there is anything called auto memory. At least I haven't found it yet.See at min:2.29.
You know if the DSOX2000 series gives their maximum waveforms per seconds with auto memory only, or with maximum memory too?
About Agilent High Resolution:
EEVblog #223 - Agilent Oscilloscope High Res Mode (https://www.youtube.com/watch?v=VtsE6xbwHcQ#ws)
As the commentator says right at the start...
Added the following table to the first post in this thread:Perfect, I keep a copy, for my personal collection.
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=67954)
I had assumed that the raw samples were written to segmented memory, which would mean that the scope had to apply the high res algorithm to segmented memory in order for it to work at all in that mode, and thus there was no good reason not to enable changing between normal and high res on recorded data.@Galaxyrise: Maybe the reason you can't switch between Normal and High Res with recorded frames is because the display frames are already "compiled" from the raw samples and stored separately in display memory. That's why the DSO can play them back so quickly. The raw samples are still in sample memory - and can be read out via SCPI - but the DSO doesn't want to alter or change the compiled frames once they're stored.
@Galaxyrise: I just discovered something else: you CAN switch your recorded frames from High Res to Normal mode - just enter Delayed Sweep (Zoom). The DSO will automatically switch to rendering the frames with High Res turned-off. But once High Res is off, exiting Delayed Sweep does not turn it back on again.Ha! At this point, I'm inclined to think the inability to switch high res and normal is just a firmware bug. They even left the menu enabled (unlike memory depth.)
1: Had anyone reported back with a positive confirmation , that the A can be "upgraded" like the Non A
1: Had anyone reported back with a positive confirmation , that the A can be "upgraded" like the Non A
As far as I've heard, Rigol has changed the key (or something) on the 'A' version, making it incompatible with the current hacking tools.
CAN-DS2000A
CAN trigger and decode for DS2000 and DS2000A.
Source: http://www.tequipment.net/RigolPricelist.html (http://www.tequipment.net/RigolPricelist.html)
Interesting. I wonder if it really works with all older model DS2000s (HW v.1)? If it does, it must require a firmware upgrade.I hope so, because mine is 1.0. :D
Today I power on my scope and I am being greeted with the boot message showing the trial options with over 2000 minutes left again, and yes all the menus that were greyed out before are now accessible again.
I am not complaining, but wondering, has this happened to anyone else?
we will soon be able to do our own ... >:DSoon!!!! 8)
FYI the DS1000Z has that jitter too.
Has all to do with phase differences..
If you synchro the clock rate off the DSO with signal generator it stands still.
Yes, it seems logical.
Has all to do with phase differences..
If you synchro the clock rate off the DSO with signal generator it stands still.
Has all to do with phase differences..
If you synchro the clock rate off the DSO with signal generator it stands still.
lol, Wim, what's that? of course there will be no phase variation (jitter) when measured signal is referenced to itself. But we not talking about that, but about the jitter added by trigger circuit, signal paths, FPGA design and potential firmware implementation.Yes, it seems logical.
lol, Wim, what's that? of course there will be no phase variation (jitter) when measured signal is referenced to itself. But we not talking about that, but about the jitter added by trigger circuit, signal paths, FPGA design and potential firmware implementation.
Sorry, man, I don't think you're correct. The jitter/offset (which, BTW, the new Siglent has as well as shown by Herman's GIF) has to do specifically with some interaction between the main time base sample rate and the delayed time base.Then are different and don't go on phase? :-//
There is no jitter/offset (in this circumstance) outside of using Delayed Sweep.It is true, good point.
But we not talking about that, but about the jitter added by trigger circuit, signal paths, FPGA design and potential firmware implementation.Then only, FPGA design and potential firmware implementation? :-//
It is the difference of the clock rate of the DSO, and ofcourse related to the sample rate,Clock rate of the DSO? Frequency at which the signal is digitally processed or something like that. :-//
and the input frequency.
It is the difference of the clock rate of the DSO, and ofcourse related to the sample rate,
and the input frequency.
It is the difference of the clock rate of the DSO, and ofcourse related to the sample rate,
and the input frequency.
Sorry, man, I don't think you're correct.
i can only recommend the R&S article to undertsand the difference between analog and digital trigger.
Compare your delayed trigger picture to the typical analog trigger jitter picture in the pdf, they look very similar.
But horizontal jitter is horizontal jitter - it all looks the same.
As I mentioned before, the Siglent has a clear offset in the single GIF that Herman posted - exactly like the offset (except bigger) as my image of the Rigol attached below - no jitter in the image: just offset.
we just don't know if the Siglent actually "jitters" at certain sample rates (or the extent of it's offset) because Herman didn't post any other info about it.
What I don't understand is this: on an analog scope, a delayed sweep involves ACTUALLY delaying the horizontal deflection amp for the B sweep - thus the reason for it's name (tradition). This involves a delay time comparator, gate, etc, - all of which could introduce jitter/error into the process.
On a DSO, correct me if I'm wrong, there is no actual delay of anything - the entire process is just done in firmware. The DSO just does it's normal capture of the main time base samples - and then extracts a subset of those samples for the "zoomed window". There is no extra comparator, gate, added circuitry, etc. - just software.
what difference would the trigger type matter?
When using zoom, there is maximal possible resolution, so depends on the implementation (calculated or hardcoded) there might be difference (and we should not forget as well rounding errors ... they very common)
For me looks like Siglent simply adjusted wrong, easy to fix thing (remember the DS2000 500uV/DIV bug).
.... The over shoot with Rigot is also quite big. It should be under 3 %. Maybe the adaption with 50 Ohm feed through terminator is not very good.
Probe calibration?His probe have HF compensation?
Can somebody explain why trace of channel 1 looks very different if channel 2 is on or off? Look at the pictures!@EV
@EV
Hi, Did you check the sample points?
here are the samples @2ns with Chan 1 only and Chan 1& 2
also see the interpolation shown in pix3 of an 'Ideal' step, note the Sinx/x Overshoot
A touch of humor: :)
@EV
Hi, Did you check the sample points?
It seems Rigol has definitely done some work on the intensity-grading in the Zoom window of Delayed Sweep in the latest FW release.Ooo, did they fix high res in roll mode? It had the same problem.
The intensity grading looks much better in the new DS1104 scope... The best intensity grading is won by the Agilent with the DS1104 a close second and the DS2000 last.
Ooo, did they fix high res in roll mode? It had the same problem.
I'm not sure if this helps sort anything out, but here are 2 images from the DS1000Z and 2 from the DS2000 showing an attempt at comparing intensity grading.
But honestly, I can't imagine often needing that combination of features.
Here are some intensity graded images DS1104Z and a DS2072, along with an image from a Tektronix analog scope
- not sure why the DSOs don't look a little better?
---
I added 1 more with the DS1104Z cranked up on the intensity to 71%; maybe better?
---
also added 1 more showing DS2000 being fed by function generator with signal slightly less modulated; there is a point at which as more modulation is added the waveform becomes visibly more "striated" (and less striated as modulate is decreased)
If you look at the DS1000 first rise of the modulated signal compare to the DS2000 you will notice that the higher sample rate of DS2000 is capture more information from the signal. Therefore the intensity grading of both waveforms can't be compare equally.
Maybe, I don't know. The over shoot with Rigot is also quite big. It should be under 3 %. Maybe the adaption with 50 Ohm feed through terminator is not very good.
Here are some intensity graded images DS1104Z and a DS2072, along with an image from a Tektronix analog scope
- not sure why the DSOs don't look a little better?
I just noticed that selecting "Inverted" in the storage menu doesn't have any effect on saved PNGs. Or BMPs or JPEGs as well. I expect the saved pictures to have inverted colours (or even better, leave the colours and just change black to white and vice-versa)...Well, I don't know for sure if it works with FW.01.01.00.02 (never tried it) - but it certainly works for FW 02.01.00.03. Did you see the image I posted on the previous page of this thread?
However, the settings in regular Save do have an effect on QuickPrint. The file type (PNG, BMP etc.) you set there is also used for QuickPrint.
2) When the RS-232 baud rate is set to AUTO 57600, it is incorrect. When set to USER 57600, it operates correctly.[/b]
OK Now,
first Pic shows Error , missing bytes 4 out of 13
second shows correct today on new firmware
Is it my imagination or did the latest firmware (00.02.01.00.03) change the behavior of the vertical gain and position controls so that, while adjusting them, new sample updates to the display are temporarily stopped? It seems to make changes to the trace visually smoother and less jerky during the adjustments. This can be demonstrated by using Auto trigger and changing the edge trigger level outside the range of the waveform (no trigger/free running).Well, it seems about the same to me - but I couldn't be sure without comparing. The behavior of the firmware of holding the last captured waveform while adjusting size or position has has been around now for the last 3 FW releases.
Maybe it has always been this way and I am not remembering correctly?
Well, it seems about the same to me - but I couldn't be sure without comparing. The behavior of the firmware of holding the last captured waveform while adjusting size or position has has been around now for the last 3 FW releases.
RS-232 Decode on 00.02.01.00.03
Looks like the § comes out as a * (not sure what character set that belongs to anyway) but the rest is there:
First image: The "Auto" indicates that it isn't triggered. Set it to normal triggering if you only want triggered waveforms. The stuff on the left doesn't look like it falls below -32mV, so it's not going to trigger there. The stuff on the right just barely does, so I would think you'd get triggering on that if you set it to normal.
I'm away from my DS2000 until Monday, but perhaps someone else can test using the Trigger Out with the new v.2 firmware?After of the above.
I'm not sure Rigol could have done anything about it in FW, since it might have been hardware related (on HW v.1 models), but I'm pretty sure our 'concerns' about it were reported to them via Drieg.
To sum up the previous findings:
Delay of Trigger Out when using CH1/CH2 as trigger: ~210ns +/- 4ns
Delay of Trigger Out when using External Trigger as trigger: ~163ns +/- 4ns
Anyone want to check if it's still the same?
I can confirm that the the trigger out delay is ~230ns, for the two last firmwares on my DS2072 HW v.1.
Mystery solved ...Yes the DSO's are sensitive, and be aware of RFI
Impressive because it was so powerful... reached up to 150mVpp
SDS8102V one meter away:
Mystery solved ...Yes the DSO's are sensitive, and be aware of RFI
Impressive because it was so powerful... reached up to 150mVpp
SDS8102V one meter away:
See the FM Station RFI in picked up from my Finger in first picture last year (70MHz)
see again with mod. today in 2nd Pic (counter almost locks on)
@CarringtonI don't know, the paint of the 200ml EMV35 pot was brown (cooper). There is also gray color (Nikel).
Does EMV35 come in light Green by the DecaLiter? :D
Is a changelog available for the latest DS2000 firmware (00.02.01.00.03)?
Would someone with HW v.2 / model A like to try it as well - to see if Rigol tightened the specs up in the newer hardware?
You just need to send a > 100k sine/square wave into CH1 (edge trigger) and Trigger Out to CH2 - then use a long persistence (e.g. 2s) to get an idea of jitter. The distance between the trigger point and the (averaged) rising edge of the Trigger Out signal is the delay (plus or minus the farthest distance of other edges).
Then just switch the sine wave input (and edge trigger) to External Trigger and check again.
This is from HW2 (non A), Firmware 00.02.01.00.03:
Thanks, JDubU. It looks more or less identical with HW v.1. I'm guessing, given their general design, they couldn't make it any better without some major changes. 160 - 230ns is certainly usable; if they would allow External Trigger to be a source to the other trigger types (for cross-triggering purposes), the slightly longer-than-normal delay would matter even less.
I installed BW 300M option to my DS2202. Here are rise time tests with Tek type 284 pulse generator.What HW version does your DS2202 have?
In pic 1 I have used BNC cable with 50 ohm feed through terminator. Rise time has changed from 1.4 ns to 1.2 ns and over shoot from 8 % to 10 %. It is not a big change.
In pic 2 I have used 10X probe with 50 ohm feed through terminator between probe tip and generator output connector. Rise time is about 1 ns and over shoot 17 %.
What HW version does your DS2202 have?
Hi Dschnell, welcome to this group
Anything special I should examine a used scope for ?
When you said 200M+300M do you mean you are able to set the bandwidth limit for this?
When you said 200M+300M do you mean you are able to set the bandwidth limit for this?
No, if you go from DS2072 to DS2202 the options screen shows the 200 Mhz bandwidth. If you then update to the newest fw and apply the DS2302 code you end up with both 200 Mhz and 300 Mhz in the options screen. I don't think it is a problem though.
and that's not a new bug?
dropping from 47k to 17k while nearly all other values got better?
and that's not a new bug?
dropping from 47k to 17k while nearly all other values got better?
and that's not a new bug?
dropping from 47k to 17k while nearly all other values got better?
It is quite likely that is a new bug. But they release a new Firmware again since a long time. After many new devices offers maybe they have more time to release new fixes.... ;)
and that's not a new bug?
dropping from 47k to 17k while nearly all other values got better?
It is quite likely that is a new bug. But they release a new Firmware again since a long time. After many new devices offers maybe they have more time to release new fixes.... ;)
Read my message above. It's not realistic to classify slower or faster wfrm/s rates as bugs. Is it a bug when you turn on High Res and the rate drops? Nope - not a bug.
sorry, but im new here and i dont know how to post a topic..can anyone help me?
ok, it just seemed a bit weird to me that only 1 value has such a difference :)
New chart: full comparison of v.1 and v.2 waveform update rates in AUTO mode / vectors:
Do these waveform update rates change if you change the frequency of the input signal (change the trigger rate)?
and that's not a new bug?I find it more likely that the old figure was caused by a bug (billed as a feature), since it was such a discontinuity. But like marmad says, it's hard for us to know what's an intended consequence of balancing features and what's an unintended drop in wfrm/s. Hopefully someone at Rigol knows :)
dropping from 47k to 17k while nearly all other values got better?
Following up on the bug discovered: problems in DOTS mode @ >= 5us/div.
This waveform chart shows how the update rates for DOTS mode are always better than VECTORS until 5us/div, at which point they get drastically worse. Something is definitely wrong here:
In regards to your previous post: Dots mode 100us --> 200us. The 200us setting does produce a display with unique dot artifacts at that one setting but, if I stop the sampling and zoom in, the sampling rate does match what is displayed at the top of the screen (by counting the dots per horizontal division).
Found a bug in the new firmware - incorrect setting of the sample rate in Dots mode at certain time bases (and maybe something else too).
Perhaps someone can confirm on their DSO? Also, if someone still has FW v.01.01.00.02 installed, could they please double-check to see if this bug is present in that FW or not?
To test:
Single channel on; Dot mode; test signal input (e.g. 1MHz sine) - the bug affects both AUTO/14M/56M memory settings (but not the others, I think).
Go from 100us/div to 200us/div - and watch the image change. The sample rate is clearly wrong; in the image it's supposed to be 2GSa/s:
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=72082)
I don't see what is wrong?Here is the EXACT same signal and settings - except with 2 channels ON - and a 1GSa/s rate (LOWER than the first image). Can you see what's wrong now?
I don't see what is wrong?Here is the EXACT same signal and settings - except with 2 channels ON - and a 1GSa/s rate (LOWER than the first image). Can you see what's wrong now?
I agree that it should look as good as that with one channel also, I just wanted to point out that when you have "too" many points in memory and an unfortunate frequency of the input signal you can get an apparent aliasing on the screen even though you have intensity graded display. But when the difference is that big it must be something else I would think as you pointed out.
@JDubU: Did you install the 300MHz option? It would be nice to know if this is connected to that option - or inherent in the firmware in general.
Same here with HW2 and old FW 00.01.01.00.02. (I could only test it with 16Mhz, but same at 200µs)
I am seeing the Dot mode artifacts at 200us/div using the latest firmware with no options installed.Thanks, Bugware and JDubU.
First Bug:I'm not sure I would classify this as a bug or not. When you turn on Statistics, the waveform display area is reduced from 700x400 to 700x360 by the display processor before overlaying measurement stats. Those small horizontal lines you see are artifacts from the reduction (exactly 5 lines per div.) from 50 vertical pixels per div. to 45. Perhaps Rigol could fix this, but I'm SURE it would mean slower update rates for a smoother algorithm (which, IMO, isn't worth it).
The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on:
Second BugAs noted in my post right above yours, this bug is already in the list: #17. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs:
First Bug:I'm not sure I would classify this as a bug or not. When you turn on Statistics, the waveform display area is reduced from 700x400 to 700x360 by the display processor before overlaying measurement stats. Those small horizontal lines you see are artifacts from the reduction (exactly 5 lines per div.) from 50 vertical pixels per div. to 45. Perhaps Rigol could fix this, but I'm SURE it would mean slower update rates for a smoother algorithm (which, IMO, isn't worth it).
The intensity graded waveform gets bright horizontal lines in the waveform when statistics is turned on:
Second BugAs noted in my post right above yours, this bug is already in the list: #17. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684)
When the trigger is change from DC Coupling to AC or HF Reject Coupling then the trigger point slips to the "left" about approx 2µs:
Sure that is a scaling problem. But I think all data in the display memory must be scaled?! So maybe there is no change in the update rate, so my thought...
I see. Sorry I have misunderstood the bug #17 in the list. So then this is only a confirmation of that. ;) BTW. the offset is not only with AC Coupling but also for LF and HF Reject Coupling... 8)
Was wondering if anyone could confirm this bug aswell:
Sure that is a scaling problem. But I think all data in the display memory must be scaled?! So maybe there is no change in the update rate, so my thought...
There is the normal scaling done between sample memory and display memory. The scaling for statistics is clearly done after this (since it's doubling lines), as part of the overlay (adding measurements, screen icons, etc).QuoteI see. Sorry I have misunderstood the bug #17 in the list. So then this is only a confirmation of that. ;) BTW. the offset is not only with AC Coupling but also for LF and HF Reject Coupling... 8)
Yes, I knew, but the bug clearly affects filtered triggers - so fixing it for one will likely fix it for all - but I added *filtered* to the bug description to make it clearer.
ofcourse, but there's more than 100 oscillations on the display.. no need for >1% error.
And if it's only depending on the display, how does changing the mem depth make such a big difference? the displayed signal is exactly the same.
edit: marmad, might you explain the background on the anti-aliasing problem? it would help me understand the problem :o
Now I'm in!Welcome! There is newer FW than the version installed on your DSO. You can download it from here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684).
I went to local distributor in Moscow in bought the DS2072A device.
alright, I'll look again :)Here is a link to a previous post (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg261236/#msg261236), which has the original patent papers for Agilent's (orignally Hewlett Packard's) technique for using stochastic (random) sampling to eliminate aliasing. This followed a long
though I don't remember reading anything that explains the anti-aliasing itself or how I would recognize this as a "problem" looking at the curves lol
alright, I'll look again :)Here is one more link (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg259965/#msg259965) - using images to clearly show the problems of aliases when a 100kHz sine wave is undersampled at 100-200kSa/s - and how the Agilent (but NOT the Rigol) deals with it perfectly.
though I don't remember reading anything that explains the anti-aliasing itself or how I would recognize this as a "problem" looking at the curves lol
So the probes that comes with it are 300mhz?, I thought they was supposed to be 350?, and they are fixed to 10x? not switchable?Manual for the probes says "DC~300MHz". They are not switchable, 10:1 only. Compensation trimmer is on box with BNC. And there is plastic srewdriver in the bag.
Hm, datasheet for the 2000A series states:There have been previous reports in this thread that sometimes the DSO comes with the RP-3300A probes (http://www.rigol.com/download/Oversea/DS/User_guide/RP3300A_UserGuide_EN.pdf) - instead of the RP-3300 probes (http://www.batronix.com/pdf/Rigol/RP3300.pdf), which most of us got.
2 Passive Probes (350 MHz)
And the manual, page 1-5 says so also, at least the one I downloaded.. strange..
Mine will arrive late January so I'll see what's packing by then..
Strangely, on some pages on the Rigol homepage, the A are rated at 350MHz, while on others they are rated at 300MHz.It's the same with the RP2200 probes that comes with DS1000E.
Thanks AndersAnd. I wonder if the materials they use now downgrade the capabilities?How old are your RP2200 probes? I bought my Rigol 1052E with the RP2200 probes in June 2009.
Are you probes older than that?
Or maybe they just forgot to put the stickers in your user's guide. Or maybe they later found out the probe couldn't live up to the 200 MHz BW they originally specified and just put stickers in the manual instead of improving the product to live up to the specs originally planned. I don't think these probes were ever sold with any scopes above 150 MHz BW anyway. Rigol 1152E-EDU with 150 MHz BW is sold on the Chinese market, with these RP2200 150/200 MHz probes too I think.
I just attached a scan of the spec sheet in my Rigol RP2200 User's Guide.
Notice the 150MHz and 2.3ns stickers on it. You can see some of the 200 below the 150MHz sticker and when I hold it up against the light I can see some of the 1.7ns too.
(https://www.eevblog.com/forum/reviews/cheap-oscope-probe-quality/?action=dlattach;attach=66787;image)
Thanks AndersAnd. I wonder if the materials they use now downgrade the capabilities?
From my probe datasheet, enclosed.
(https://www.eevblog.com/forum/reviews/cheap-oscope-probe-quality/?action=dlattach;attach=66760;image)
CAN decoder works!
CAN decoder works!Perfect! :-+
CAN decoder works!
Thanks, EV.
A couple requests. Could you zoom in on just one packet, so the contents of the ArbID and DLC fields can be seen? Also, I'd be interested in checking out the Event Table view, to see what it says in the Error field about the lack of an Ack (no other CAN controller on the bus, I assume).
I also got two RP3300A with my scope (DS2072 with hw1.0, but only 4 weeks old), while two RP3300 were advertised. Now I really wanted some 1x probes aswell, so I complained a bit (a lot) and finally got 2 extra RP3300 sent home for free. I didnt have to send my RP3300A back. Where I bought my scope, they're asking 45 euro's for a single RP3300 probe! Don't think they made any money from me, I got a 10% discount on my scope (765 euro) and two extra RP3300 (90 euro), so I only paid +- 675 euro for my scope.
Now, since I've got both, I can also compare them! :-)
The RP3300A have a much better feel than the RP3300. Build is better and they're also better isolated. With the RP3300 I get some glitches in the signals when I hold them in my hands the wrong way (finger close to the 1x/10x switch, probably picking up 50Hz in that case). The RP3300A are also a little bit smaller and thinner than the RP3300. The RP3300 have this yellow cap, to 'shield' the ground when probing on a PCB, but it falls off way too easily (for both probes, do others have this aswell?). I don't have a high frequency generator, so can't compare the bandwidth. Strangely, on some pages on the Rigol homepage, the A are rated at 350MHz, while on others they are rated at 300MHz.
If I'd have to chose between the RP3300 and RP3300A, then I'd go for the A! I'm not going to use the RP3300 in 10x mode, the RP3300A feel much better quality and is better isolated, so the RP3300 will be only used for low bandwidth 1x probing.
Btw, I doubt that either the RP3300 or the RP3300A are very good at 300MHz, but maybe someone already tested the bandwidth.
Just found another brand new feature added to the latest firmware (which, honestly, should have been there from the start):Oops. Been using this since I got my 2072A. Didn't realise it was missing from earlier versions or I would have said something.
CURSORS in X-Y Mode:
Here you have it! I hope it is what you wanted.A couple requests. Could you zoom in on just one packet, so the contents of the ArbID and DLC fields can be seen? Also, I'd be interested in checking out the Event Table view, to see what it says in the Error field about the lack of an Ack (no other CAN controller on the bus, I assume).
.
.
And what's that 2nd tab on the Event table, labeled Details? If that's been there already, I failed to notice it before now.
Here are details.And what's that 2nd tab on the Event table, labeled Details? If that's been there already, I failed to notice it before now.
but can anyone help me measuring low voltages without having the fat curve? because, for some reason, on my old HP DSO (with a CRT) the curve was thin ...
anyone else has troubles using the rotary encoder right to the menu button? it really is sensitive
everytime I just press it, it registers a rotation
it wouldn't be a bad idea if Rigol would make it possible to ALSO use the up/down buttons below to select something in the menu that's currently open (instead of the menu below it)
Fat curve? What does that mean? Do you mean the size of the trace? If that's what you mean, the method for reducing it is to limit the input signal - either with the 20MHz or 100MHz channel BW limiter or by averaging - either waveforms (Average) or samples (High Res).
For some menu items, they can be selected by just pushing the corresponding menu button.
yes, I meant the horizontal width of the curve ... on my old DSO I saw a thin line, here I see lotsa noise when I decrease the timebase :o
20 MHz didn't make it better, reduced it only a little bit ...
Thanks again. That is interesting, and I've definitely never seen it before.
btw, I saw animated gif screenshots earlier here on this forum.With the software I wrote: Rigol Ultravision Utilities (RUU) - available in this thread (download link at bottom of first post) (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/). It's especially handy for just getting screen captures from the DSO to the PC in a few seconds - but can also turn recorded frames into animated GIFs or waterfall plots (as well as a bunch of other stuff).
how were they created? with the rigol software or frame by frame by hand?
2nd channel only -> 1GS/sHi
Can somebody confirm following behavior with latest FW on DS2k devices:
1st channel only -> 2GS/s
2nd channel only -> 1GS/s
At least i can't remember reading anything about that.
I expected to have a drop of maximum sample rate from 2GS/s to 1GS/s only in case when both channels are active at once.
btw, I saw waterfall screenshots/pics of DS2xxx DSOs before, so they've been made with this software?Yes Dave Jones used it in the review of DS1052 vs DS2000,
CH1 and CH2 with no input signal has a very small pulse in the noise.Hi , welcome to the Forum
Anyone else has troubles using the rotary encoder right to the menu button? it really is sensitive
everytime I just press it, it registers a rotation
for example: I try to select a different probe ratio. turning is is kinda sluggishly jumping to the next value, sometimes it skips 2 or 3
and when you push it after it's successfully on the correct value it jumps to the next value and selects this before the menu closes
it wouldn't be a bad idea if Rigol would make it possible to ALSO use the up/down buttons below to select something in the menu that's currently open (instead of the menu below it)
I am suggesting the amount of rotation to jump to the next selection be a bit larger...
so I think it would make more sense to solve this in the software, like ignoring a turn when it happens less than 100ms before a push or something like that.Thats exactly the way I would program it.
I think that waveform playback knob must act as multifunction knob because it is hardly used at all. And it is bigger and has fixed angles, good for selecting something.It does. Note the menu symbol for Navigation Knob from the DS2000 User Manual:
Thanks Fagear and Teneyes. Exactly what I needed to know. I got tired of turning off Math to make the timebase changes then turning FFT back on. Sometimes need to see envelopes in the time domain at slower clockrates than the right rate for the FFT.But then press CH1 button and use horizontal scale knob. The FFT will scale with CH1 waveform as well and will shift to the side. Playing around with both horizontal knobs (rotating and pushing, while CH1 is selected) will force FFT graph to shift and jump around and sometimes to dissapear. To reposition FFT graph you need to press MATH, set required zoom and push POSITION to center the graph.@ Rory
Yes the CH1 and Math buttons change the function of the <Scale> Knob. But as Fagear states , ackward or bugging
@Marmad:
The % of blind time (between 200ns and 2ns) in the following table is it real or effective?
Then the real blind time (%) between 2ns and 200ns would be: 82.46, 88.65, 92.80, 63.06, 81.36, 86.70 and 91.46.@Marmad:
The % of blind time (between 200ns and 2ns) in the following table is it real or effective?
Effective blind time. You can see that the active acquisition time is listed as 14x the time base (i.e. the display window - not the 'real' acquisition time).
Then the real blind time (%) between 2ns and 200ns would be: 82.46, 88.65, 92.80, 63.06, 81.36, 86.70 and 91.46.
So we can say than for these time bases (2ns-200ns) is always better to use 14K?
It depends what you're doing. For most Normal uses, the effective blind time is, in a sense, the 'real' blind time - because YOU will be blind to it (i.e. it won't appear on the display) even if the DSO is not technically blind to it. So if a glitch happens in the part of acquisition memory that is off-screen, you'll never see it. But when capturing waveforms for later examination (whether just one - as in Single Shot mode - or many - as in Segments), then the 'real' vs 'effective' blind time actually makes a difference.I understand:
If you know how the disturbance Looks like you could trigger on that.It depends what you're doing. For most Normal uses, the effective blind time is, in a sense, the 'real' blind time - because YOU will be blind to it (i.e. it won't appear on the display) even if the DSO is not technically blind to it. So if a glitch happens in the part of acquisition memory that is off-screen, you'll never see it. But when capturing waveforms for later examination (whether just one - as in Single Shot mode - or many - as in Segments), then the 'real' vs 'effective' blind time actually makes a difference.I understand:
"So if a glitch happens in the part of acquisition memory that is off-screen, you'll never see it." But, can the oscilloscope automatically detect it?
Digital scopes have this kind of blind time. It's the Technologie... I heard a very nice statement some time ago: Measuring wiht a DSO is like driving a car with closed eyes and just open them from time to time for a very short moment.
Analog scopes also have a blind time (during beam retrace).
It does. Note the menu symbol for Navigation Knob from the DS2000 User Manual:Yes I know. For example it works for trigger holdoff setting.
I understand:The maskrange, work only for a screen/screen-region, would be great if in a post process, the oscilloscope could capture glitches off-screen (at memory).
"So if a glitch happens in the part of acquisition memory that is off-screen, you'll never see it." But, can the oscilloscope automatically detect it?
But there are many many times when Navigation Knob does nothing.
I am suggesting the amount of rotation to jump to the next selection be a bit larger...
No matter how large they make the amount of rotation it can always be just on the edge when you press the button, so I think it would make more sense to solve this in the software, like ignoring a turn when it happens less than 100ms before a push or something like that.
Since it has no way to see into the future (needs faster FPGAs for that :) ) to determine that a push is about to occur, that means it will delay all turn reactions for that same interval. Aka, "is this a real turn, or an accidental turn while clicking?"
The response from users will then be... "Why is this d@mn thing so laggy? The responsiveness to the knobs is poor."
No matter how large they make the amount of rotation it can always be just on the edge when you press the button, so I think it would make more sense to solve this in the software, like ignoring a turn when it happens less than 100ms before a push or something like that.
Since it has no way to see into the future (needs faster FPGAs for that :) ) to determine that a push is about to occur, that means it will delay all turn reactions for that same interval. Aka, "is this a real turn, or an accidental turn while clicking?"
The response from users will then be... "Why is this d@mn thing so laggy? The responsiveness to the knobs is poor."
Maybe I am missing something obvious. Is there some quick way to remove measurements from the bottom of the screen.
There are dedicated buttons for adding measurements but I cant find a quick way to clear them.
Maybe I am missing something obvious. Is there some quick way to remove measurements from the bottom of the screen.
There are dedicated buttons for adding measurements but I cant find a quick way to clear them.
Measure => clear all items
Did some testing with the new FW, and updated my Bandwidth chart.
.
.
Is there any chance that that the additional noise/fuzz or whatever artifact is evident in the display with 'channel 2 also active' (New2.png) is due to the that sample rate dropping from 2GHz down to 1GHz? Probably not, but I just wanted to ask before giving up on the 300MHz BW for the DS2000 (for the non A anyway).
Did some testing with the new FW, and updated my Bandwidth chart.
There is not much more bandwidth on a 2072 with option 300 Mhz, the entry
of the 2072 , the non A models, dont get 300 Mhz, mine goes to 280 Mhz.
The lack of a internal 50 ohm terminator...
Also got more noise, see picture with only 1 channel, and then enable channel 2,
the difference is clear, on 1 nS the sample rate is to low for two channels.
The performance is worse on 1 nS then on 2 nS.
I did the test with the DSGH key, see option picture.
So the advantage of the new bandwidth option is not big for the non A models.
You are better off with the 200 Mhz version. So use the DSEH key for better performance.
Is there any chance that that the additional noise/fuzz or whatever artifact is evident in the display with 'channel 2 also active' (New2.png) is due to the that sample rate dropping from 2GHz down to 1GHz? Probably not, but I just wanted to ask before giving up on the 300MHz BW for the DS2000 (for the non A anyway).
Also, I have been wondering for some time if going from 200MHz to 300MHz BW was detrimental, because it appeared to me that the increased Overshoot (with 300MHz BW) was likely due to the rising response around 115MHz of the 300MHz BW selection.
What condition is shown in picture 'New6' with the FFT?
Thank you for the very interesting and informative BW data you provided on the DS2000.
In conclusion, I understand that you believe now that 200MHz should be as high as we should go for the DS2000 'non A' version?
I edit my post, the FFT i added because of the improved function of it after the last FW
And yes i think 200 Mhz is the best performance for the non A model, 300 gives some unwanted behavior.
And the differences are to small, 230 versus 280 Mhz...
Storage->Traces.Press Clear on the TOP , Trace is just a graphic overlay of what was saved, good for comparing Old tests.
How I can delete a Trace after loading? (Without turning off the scope)
Also got more noise, see picture with only 1 channel, and then enable channel 2,
the difference is clear, on 1 nS the sample rate is to low for two channels.
The performance is worse on 1 nS then on 2 nS.
I'm still using cyberbet's fimware at 300 Mhz but with 200 MHz bandwidth limit available. No CAN but I have no use for it right now. Still undecided if I should update to the newest firmware....
IMO the improvements in the latest FW are way more valuable than the ~50MHz of extra BW you may be getting with that old FW version.Strongly agree.
IMO the improvements in the latest FW are way more valuable than the ~50MHz of extra BW you may be getting with that old FW version.Strongly agree.
I just want to add, it is not only the BW, and noise, a base time of 1ns is quite useful.
i dont agree, the 1 nSec, has only 4 samples ( one channel) or 2 samples ( 1 channel)
I just want to add, it is not only the BW, and noise, a base time of 1ns is quite useful.
I don't share your opinion, but I respect it. And with repetitive signals is not so usefool.IMO the improvements in the latest FW are way more valuable than the ~50MHz of extra BW you may be getting with that old FW version.Strongly agree.
I just want to add, it is not only the BW, and noise, a base time of 1ns is quite useful.
i dont agree, the 1 nSec, has only 2 samples ( one channel) or 1 samples ( two channel)
so be carefull what you measure... can be not so usefool
LOL... I found a bug?
How you call it then?LOL... I found a bug?
It can't really be classified as a bug: you're running an option that is not officially available for the DSO you're running it on. If a DS2302A does the same thing (or if Rigol EVER sells BW updates for other DS2000 models) then it could be called a bug.
How you call it then?
IMO the improvements in the latest FW are way more valuable than the ~50MHz of extra BW you may be getting with that old FW version.
Thanks, you're probably right. Is there a list of all the improvements in the new firmware?
Marmad already stated a few posts back, the non A models where not good enough for 300 Mhz.
they had to modify the entry in the A models.
maybe, but all tests so far were at HW 1.0, there were actually some noticeable board/ input stage changes in the non-A HW 2.0. So it is to early to say that for all the non-A models!
My old TEK TDS3032 has 2.5 GS/s and 5 samples per division with 1 ns time base. It is so regardlss whether both or only one channel is on.
I do not know about the math, but look at the picture.
Math is math; there is no getting around it. Drawing dots on a display is something else.Maybe it's magic...
Either one of the following HAS to be true:
1) Your DSO samples at a maximum of 2.5G and it gets a sample every 400ps - and then, for whatever reason, it's doubling the number of actual sample points it draws on the screen.
2) Your DSO, for whatever reason, has the 5GSa/s rate of the TDS3052, and it gets a sample every 200ps. Then the number of points on the screen equals the actual real sampling rate.
Well, I guess it's technically a bug - but in an unimplemented - and perhaps unfinished? - portion of firmware. So not very relevant.I agree is true, it is not relevant.
EDIT: BTW, does not happen when saving via RUU.
from Tek 3032B Manual
Separate Digitizers. Ensure accurate timing measurements with
separate digitizers for each channel. Each digitizer can sample at up
to the maximum sample rate (2.5GSa/s); acquisition on all channels is always
concurrent to provide full single-shot bandwidth on each channel.
So IMO, Tek is combining samples from 2 channels,
if so Let's deleted all this dicussion, Please
from Tek 3032B Manual
Separate Digitizers. Ensure accurate timing measurements with
separate digitizers for each channel. Each digitizer can sample at up
to the maximum sample rate (2.5GSa/s); acquisition on all channels is always
concurrent to provide full single-shot bandwidth on each channel.
So IMO, Tek is combining samples from 2 channels,
if so Let's deleted all this dicussion, Please
Traces when using type as dots or vectors look quite different. Why?It looks like a sinx/x interpolation, but it is weird.
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.
Traces when using type as dots or vectors look quite different. Why?It looks like a sinx/x interpolation, but it is weird.
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.
I noticed it already here:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/1785/ (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/1785/)
There time base is 2 ns.
Wim13 explained then:
"There is always something like cross talk between channels.
To the book Rigol claims cross talk between ch1 and 2 better then 40 dB"
I however now noticed that there is not this trasition in the Dots picture. The trace there looks same as if Ch2 is not on.Traces when using type as dots or vectors look quite different. Why?It looks like a sinx/x interpolation, but it is weird.
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.
There seems to be a problem with the sample-to-display interpolation algorithm (sin(x)/x) when the horizontal time base is faster than about 20ns/div.
The dots display looks reasonable but the vector display introduces interpolation artifacts when the distance between sample points spans a larger number of pixels on the display. This can be seen more easily in single sweep mode. The dots reliably form a smooth curve but the vectors tend to "zig zag" between adjacent sample points with multiple 2 or 3 pixel steps in opposite directions as the trace moves from one sample point to the next. On a free running sweep, these display artifacts appear as a noisier trace.
This also explains why enabling CH2 increases the apparent noise on CH1. The sampling rate is cut in half causing the distance between sample points to double (producing more display artifacts) for a given time base setting.
There seems to be a problem with the sample-to-display interpolation algorithm (sin(x)/x) when the horizontal time base is faster than about 20ns/div.
Note that the steps are multiple display pixels high....
...with several examples of inappropriate direction reversals between sample points.
Note that the steps are multiple display pixels high....
By multiple, do you mean a multiple of 2? The Rigol maps 200 possible ADC values to a 400 pixel high display - steps are ALWAYS a minimum of 2 pixels - it doesn't matter what time base or interpolation method you use.Quote...with several examples of inappropriate direction reversals between sample points.
What you're talking about here is noise fluctuation between 3-4 quantization levels (which is 1-2 bits); normal on digital oscilloscopes. This has nothing to do with sin(x)/x - and can be found at every time base if you STOP the DSO and 'zoom' in on the trace with vertical scale.
By multiple, I mean that the available vertical display resolution is not being used to its best advantage by the interpolation algorithm. The individual, lower resolution ADC values may map to locations that are separated by multiple display pixels, but the interpolated trace that connects them is not limited to the resolution of the ADC. The interpolation algorithm should produce smooth traces that fully utilize the available vertical resolution of the display.
By multiple, I mean that the available vertical display resolution is not being used to its best advantage by the interpolation algorithm. The individual, lower resolution ADC values may map to locations that are separated by multiple display pixels, but the interpolated trace that connects them is not limited to the resolution of the ADC. The interpolation algorithm should produce smooth traces that fully utilize the available vertical resolution of the display.
All of the interpolation is done on the original 8-bit values - with scaling for the display done as the last stage of the process (which I believe most lower-prices DSOs do - see attached image from Agilent X-3000 showing a minimum of 2 pixel steps - and even some quantization error at the top of the second sine wave). This method also guarantees that the display memory produces 8-bit values when read by another device.
In any case, what you've pointed out is not a 'problem with the sample-to-display interpolation algorithm' - it's the way it's normally done - and while your suggestion would lead to a nicer looking waveform when the DSO was stopped, it would definitely be slower.
The problem is that the interpolation algorithm is adding the appearance of higher frequency content than what the ADC is actually measuring. The ADC is only producing the "dots" display. Everything in between the dots in the vector display should be as close to an estimate of what the waveform looks like as possible. This is the role of the sin(x)/x convolution window which attempts to use Nyquist criteria to reasonably interpolate what the actual waveform is doing between measured sample points. Since these are simply mathematically derived estimates and not measured, there is no reason that there should be higher frequency content in the interpolation than there is in the dots display itself. It seems like what is happening (and what you describe) is that the interpolation is rounding off to the nearest of the 256 quantization levels of the ADC rather than to the 400 level vertical resolution of the display and then linearly scaling (with more roundoff error) to the vertical display resolution.
The problem is that the interpolation algorithm is adding the appearance of higher frequency content than what the ADC is actually measuring. The ADC is only producing the "dots" display. Everything in between the dots in the vector display should be as close to an estimate of what the waveform looks like as possible. This is the role of the sin(x)/x convolution window which attempts to use Nyquist criteria to reasonably interpolate what the actual waveform is doing between measured sample points. Since these are simply mathematically derived estimates and not measured, there is no reason that there should be higher frequency content in the interpolation than there is in the dots display itself. It seems like what is happening (and what you describe) is that the interpolation is rounding off to the nearest of the 256 quantization levels of the ADC rather than to the 400 level vertical resolution of the display and then linearly scaling (with more roundoff error) to the vertical display resolution.
I don't agree that there is higher frequency content added: there is quantization and rounding error - again, visible in the Agilent's screen capture as well - and within the error bounds of the DSO. But it seems to me you have a very simplified idea about how the captured samples end up as interpolated display. If vectors are ON, the display memory ALWAYS contains 1400 bytes (700 vectors) - it doesn't matter if the ADC captures 14M - or - 28 samples during the acquisition window. There are a WHOLE bunch of steps involved in arriving at those 1400 bytes - just one of which is the actual sin(x)/x or linear interpolation algorithm.
But anyway, it's late and I'm done here - if you want to believe there is a problem with the Rigol, fine by me. :)
Also got more noise, see picture with only 1 channel, and then enable channel 2,
the difference is clear, on 1 nS the sample rate is to low for two channels.
The performance is worse on 1 nS then on 2 nS.
@ EV note that with 2CH there are less samples so the Sin(x)/X interpolation will make the curve go off the linear path
.
.
Yes, Sin(x)/X interpolation is outside the linear path.Sin(x)/x is NOT a linear path - lots of information you can read about it online. ;)
Sin(x)/x is NOT a linear path - lots of information you can read about it online. ;)
"Unlike the narrow pointed triangle of linear interpolation, the window for SinX interpolation is a theoretically never ending damped sinewave. "
OK, maybe it works correctly, but there are too few sample points for this fast rising pulse. Thanks for the picture! I am very lazy to read manuals and any other information. ;) ;D
Here is for comparison the picture with same traces from my old TEK TDS3032. It is 300 MHz scope but the measured BW is over 400 MHz and it has 5 points per division as I told before.
Here are 2 pictures with BW limit 100 MHz. Deviation from dots path can still be seen.Can you please post the following image again - taken with the DSO running and Wave Intensity = 0%?
Can you please post the following image again - taken with the DSO running and Wave Intensity = 0%?
And BTW, EV, why are your Rigol screen colors different than everybody else that posts images?
I have added lightnig to the pictures. The attached picture is not manipulated.
BUG in latest f/w, 02.01
Delayed sweep malfunctions.
To reproduce:
Ch2 must be enabled, Ch1 optional
acquire: 7M samples, normal
trigger: ch1 or not important, Auto or Normal seems to have no effect
main timebase 500us/div, delayed t.b. 100 us/div or something
Then when you move the delayed t.b. towards 1 ns/div all seems well until you select 1 ns/div..
It locks up for about 10 seconds, no waveform update, no response to keys.
Then it comes good and lets you go back to 2ns/div
I suggest disabling 300MHz on non-A HW v.1 models. Not only is it buggy (I've had a couple of crashes from it), but it's not really perfectly implemented in the input stage.
How is it possible to uninstall only BW option?
Do ":SYSTem:OPTion:UNINSTall" and then generate new keys without 300 MHz option (with 200 MHz for example) and install them.
It can be two keys: DSAZ (200 MHz, MEM, DC, AT) then DSEA (CAN).
Or simply use DSEZ instead as the only key, to combine CAN with all the options included in DSAZ (200 MHz, MEM, DC, AT) into a single key.How is it possible to uninstall only BW option?Do ":SYSTem:OPTion:UNINSTall" and then generate new keys without 300 MHz option (with 200 MHz for example) and install them.
It can be two keys: DSAZ (200 MHz, MEM, DC, AT) then DSEA (CAN).
Just to let people know - I found still another bug in 300MHz option on my HW v.1 non-A DS2000:
.
.
Are you going to do a separate list of these bugs? So we could check if they are in the next FW uodate.
I don't think I would bother unless someone with a HW v.2 model (or A model) confirms each bug on their DSO.
I have a non-A version 2 hardware, can you point out one or more bugs that are easy reproduced? I can do some tests tomorrow.Well, I don't know what caused my various crashes and strange behavior (which is one reason I wanted to uninstall that option) - but here are two other bugs reported that could be reproduced:
But it seems to me you have a very simplified idea about how the captured samples end up as interpolated display. If vectors are ON, the display memory ALWAYS contains 1400 bytes (700 vectors) - it doesn't matter if the ADC captures 14M - or - 28 samples during the acquisition window. There are a WHOLE bunch of steps involved in arriving at those 1400 bytes - just one of which is the actual sin(x)/x or linear interpolation algorithm.
Could you please explain what the data in display memory actually is?
I've always wondered why there are 1400 bytes while the display is only 700 points wide, but wasn't able to come up with any verifiable scheme.
I have similar problems when using the multi function knob. Also, it sometimes skips several entries or in my case causes the cursors to jump over the desired loactions. All in all, the knob is very unprecise in my experience.
Even my DSOX2000 has a small multifunction knob. I wish it was bigger. At Owon and Tektronix they have big multi knobs.
This got me thinking about when Steve Jobs said people were holding it wrong when customers complained about poor iPhone antenna signal. >:D :-BROKEI have similar problems when using the multi function knob. Also, it sometimes skips several entries or in my case causes the cursors to jump over the desired loactions. All in all, the knob is very unprecise in my experience.I have very few problems with the multi-function knob skipping (and I have big hands) because of developing a specific way of using it when selecting things. Of course, when using it only for adjustment (like intensity), you can just rotate it normally - but if you want to experience very few skips when selecting, you need to develop a special method such as the following:
It has everything to do with the way you grip it (see image): my thumb is on the bottom edge of the knob front, while my index finger is on the top edge at the very back of the knob (snug against the case), with my hand supported by my 3 free fingers. The knob is turned precisely with opposing motions of the thumb and index finger (their positions don't change), and when the desired selection is reached, my grip tightens slightly with my index finger pushing slightly down and back against the case - while the thumb pushes slightly up and inward - essentially locking the knob from rotating during the click.
After uninstalling BW 300M option BW has changed from 300 MHz to 240 MHz. Rise time has changed from 1.15 ns to 1.38 ns and over shoot has changed from 11.0 % to 8.5 %.
Don't think so, the 300 MHz picture has faster rise time [1.148 ns] than the 200 MHz one [1.375 ns] as it should.After uninstalling BW 300M option BW has changed from 300 MHz to 240 MHz. Rise time has changed from 1.15 ns to 1.38 ns and over shoot has changed from 11.0 % to 8.5 %.You reversed the picture titles.
After having a coffee and looking again you are right, it's just that the preview of the 200 Mhz one looks faster and I went wrong from there. :palm:Don't think so, the 300 MHz picture has faster rise time [1.148 ns] than the 200 MHz one [1.375 ns] as it should.After uninstalling BW 300M option BW has changed from 300 MHz to 240 MHz. Rise time has changed from 1.15 ns to 1.38 ns and over shoot has changed from 11.0 % to 8.5 %.You reversed the picture titles.
Yeah that's the problem when one pic has a 1 ns timebase and the other pic has a 2 ns timebase.After having a coffee and looking again you are right, it's just that the preview of the 200 Mhz one looks faster and I went wrong from there. :palm:Don't think so, the 300 MHz picture has faster rise time [1.148 ns] than the 200 MHz one [1.375 ns] as it should.After uninstalling BW 300M option BW has changed from 300 MHz to 240 MHz. Rise time has changed from 1.15 ns to 1.38 ns and over shoot has changed from 11.0 % to 8.5 %.You reversed the picture titles.
Yeah that's the problem when one pic has a 1 ns timebase and the other pic has a 2 ns timebase.
Just a tiny video for fun - showing how fast and easy it is to use the multifunction knob when you use the right grip.
This a totally unrehearsed, first-take video in which I type out "rigol ds2000 oscilloscope" on the software keyboard without selection errors in 50 seconds...
EDIT: Just managed 38 seconds when I put some thought and concentration into it - so an average of 1.52 seconds for each of the 25 selections.
After uninstalling BW 300M ..... and over shoot has changed from 11.0 % to 8.5 %.
The next picture is from BATRONIX web site. There is told that with new measuring input stages the over shoot is below 5 %. The amplitude there is 5 mV when in my pictures it is 240 mV and the rise time of the pulse is < 70 ps.After uninstalling BW 300M ..... and over shoot has changed from 11.0 % to 8.5 %.
Here is rise time of scopes trigger out pulse. Its amplitude is 1.5 V and rise time about 1 ns probably. So the rise time of the pulse is much slower than the rise time of the pulse from TEK Type 284 generator. The measured rise time is 1.5 ns and over shoot only 3.5 % with old measuring input stage.
What exactly are you talking about or think Batronix/Rigol are talking about when referring to new and old measuring input stages respectively.Yeap, that seems. Although I'm not 100% sure.
I'm pretty sure when Batronix wrote "new measuring input stages", they were not referring to HW 2, but just referring to DS2000 in general and that it was written when the old HW 1 was all there was known. IIRC this has been on their website for a long time: http://www.batronix.com/shop/oscilloscopes/Rigol-DS2072.html (http://www.batronix.com/shop/oscilloscopes/Rigol-DS2072.html)
So when they wrote "new measuring input stages" they were not comparing HW 2 to HW 1, but just comparing DS2000 to older Rigol series scopes, maybe like DS1000E series which might have a bigger overshoot.
Batronix haven't even updated their website yet to mention anything a bout DS2000A series scopes.
Yeap, that seems. Although I'm not 100% sure.I just checked "The Way Back Machine" to make sure, and this info was on Batronix' website already on October 13, 2012, long before HW 2 came along. Source: http://web.archive.org/web/20121013114141/http://www.batronix.com/shop/oscilloscopes/Rigol-DS2072.html (http://web.archive.org/web/20121013114141/http://www.batronix.com/shop/oscilloscopes/Rigol-DS2072.html)
Batronix haven't even updated their website yet to mention anything a bout DS2000A series scopes.
You probably missed my post above which proves it was already on Batronix on October 13, 2012, long before HW 2 came along. So this screenshot was made on HW 1 and comparing to older scope series. It has nothing to do with HW 2 vs. HW 1.Batronix haven't even updated their website yet to mention anything a bout DS2000A series scopes.Maybe so, I don't know. Here is however the same picture with text "lower over shoot" under DS2000A web page:
http://www.rigol.com/prodserv/DS2000A/ (http://www.rigol.com/prodserv/DS2000A/)
This got me thinking about when Steve Jobs said people were holding it wrong when customers complained about poor iPhone antenna signal. >:D :-BROKE
You probably missed my post above which proves it was already on Batronix on October 13, 2012, long before HW 2 came along. So this screenshot was made on HW 1 and comparing to older scope series. It has nothing to do with HW 2 vs. HW 1.
Ok, so it is old picture and they advertise on web page http://www.rigol.com/prodserv/DS2000A/ (http://www.rigol.com/prodserv/DS2000A/) that over shoot of DS200A is lower but don't say lower of what. ;DYeah it's very easy to make random comparison claims when you don't tell what you're actually comparing against. Noone will ever be able to hold it against you.
Show off! ;D :clap:
it's really odd ...
I entered the test-serials using the DSO editor and the rotary enc.
no problems with that
but if I try to select let's say the probe correction, I might end up with the next or prev value (beside a laggy response during selection)
Happy New Year, everyone! :)Happy New Year. But that's not what Europe looked like. Kind of obvious when you think of it, otherwise why would some countries be red, others yellow and others again blue?
Here's what the festivities looked like in my neck of the woods when 2014 arrived:
Although this photo spread Internet expanses as "spectacular photos Europe at midnight 1 January 2013. Recorded by NASA," we'll have to disappoint you, though someone just played well in Photoshop.
Maybe one day New Year's footage from space really look like that - when NASA made ??an even better photo equipment, when the fireworks on the ground look like a nuclear war, and when all countries regardless of the time zone they decide to welcome the New Year at the same time.
Besides if it's supposed to look like fireworks at midnight, the UK would not be lit up at the same time as mainland Europe, as they celebrate New Year an hour later and Moscow i 3 hours ahead of CET.
I wish the Navigation Knob would also do high speed horizontal position in normal mode the same way it does in delayed sweep and record playback modes.
I also wish that the inner knob had a finger indent so that it could be spun continuously (like many professional video playback controllers). The way it is designed now, I find it to be almost useless and, instead, use the small horizontal position knob which has the same function but can be spun faster and with more control.
... You've got one knob (Navigation) which increments very fast - and then two knobs which increment very slowly at the same rate (although you can spin the h.pos. knob faster if you want). The inner knob should increment at a medium rate - making it much easier to hone in on the desired position.
Perhaps I'll pass these suggestions along in the hopes Rigol will implement them in the next firmware.
I think it slows down and makes FW complicated , now the FW has everytime
make decisions and have to think , ohh this is a A or a non A.
Traces when using type as dots or vectors look quite different. Why?Carrington asked me to test this on my non-A hardware version 2 scope, with latest software and all upgrades and I get the following. Not sure if I missed a setting but it looks ok:
Time base 1 ns, Ch1 and Ch2 both on, HW 1, BW 300 MHz.
Bandwidth DS2302 HW 2, signal generator on 1 volt, 10 Mhz steps:Awesome... :o
Bandwidth DS2302 HW 2, signal generator on 1 volt, 10 Mhz steps:
And 1nS :palm:
How are you getting a continuous trace of closely spaced dots? You should be seeing only one dot per horizontal division (1 ns/div, 1G samples/second).Looks like hi res acquisition
How are you getting a continuous trace of closely spaced dots? You should be seeing only one dot per horizontal division (1 ns/div, 1G samples/second).Looks like hi res acquisition
Does anyone have a good description for how the hi resolution mode works? The manual didn't really help me understand it.Please search on the forum, because it has already been discussed in detail.
Looks like hi res acquisition
Ah yes!
Yes it is in hi res because the original from EV was also in hi res.Please can you repeat the same test for 1ns/div, but not in stop mode and/or hi res.
Does anyone have a good description for how the hi resolution mode works? The manual didn't really help me understand it.
Yes it is in hi res because the original from EV was also in hi res.
Bandwidth DS2302 HW 2, signal generator on 1 volt, 10 Mhz steps:
Sorry, but I'm not sure I buy this BW chart.
Sorry, but I'm not sure I buy this BW chart.
Atttached Excel sheet with the measurements.
My old TEK TDS3032 has 2.5 GS/s and 5 samples per division with 1 ns time base. It is so regardlss whether both or only one channel is on.
But that doesn't make sense mathematically. If 2.5GSa/s is the maximum rate, 400ps is the smallest sample period. That would be 2.5 samples per div @ 1ns. 5 samples per div would require a 5GSa/s rate (200ps sample).
I just had hi res on for the other screenshots because I figured that EV had it on too (too many dots) in his original posting and I switched it off after taking the shots.Ok, sorry, my mistake. :)
"...and mathematically adds points depending upon the horizontal time/div setting. What you are seeing are the interpolated points, not actual samples."Which is basically what the Rigol is doing in HighRes mode below a certain time base.
I got explanation to this from TEK Forum:
"When at 400ns/div or faster horizontal time base, the sample rate is maxed at 2.5GS/s. To overcome the max sample rate, the instrument goes into real time interpolate mode and mathematically adds points depending upon the horizontal time/div setting. What you are seeing are the interpolated points, not actual samples."
A few days ago someone mention something about a Tek oscilloscope that in dots mode showed more samples than should be.https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg355318/#msg355318 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg355318/#msg355318)
It's not magic, are interpolated (maths).
But, IMO, if your measurements ARE correct, I'd say Rigol made a mistake in redesigning their filter - and it makes me feel better about owning a HW v.1 ;DDS2072, DS2072 (HW2.0) and DS2072A have all different input stages.
DS2072, DS2072 (HW2.0) and DS2072A have all different input stages.
And no idea why this happens: :-//
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=75292;image)
Yes, clearly I know that. But if PA0PBZ's chart is accurate, IMO it indicates a poorly designed filter for the sampling hardware.Well, who knows, it may be an error in the measurement.
And no idea why this happens: :-//I'm unable to infer from that screenshot what is surprising to you.
I'm unable to infer from that screenshot what is surprising to you.Why do you think that there is nothing unusual?
What does it look like when switched to "Dots" mode?
And no idea why this happens: :-//
I got my ds2202a-s today,Where did you buy a S2000A-S version? Didn't think they were released yet. Not listed at online distributors like http://rigolna.com (http://rigolna.com) and http://batronix.com (http://batronix.com)
4) my hardware version is 1.2.2.0.2, but other A models have 1.0.2.0.2?, is that also due to the Signalgen?Most likely.
Where did you buy a S2000A-S version? Didn't think they were released yet. Not listed at online distributorsIt's available in Russia: DS2072A-S (http://irit.ru/products/index.php?SECTION_ID=915&ELEMENT_ID=395821), DS2302A-S (http://irit.ru/products/index.php?SECTION_ID=915&ELEMENT_ID=395833).
What's the price difference between the S and non-S models?DS2072A ~ 766€
These are stopped displays, In run mode the varying trigger scanning causes the sampling to collect a series of sample along the sin display and if not a sin wave(step function) the DSO will create a sin wave overshoot.
Note : At 2.5 samples/ cycle the frequency will be accurate but Vpp is NOT.
AS EV says very few points
I think it is due to the overlap of many waveforms slightly different each time, and the wave intensity processing. Like the persistence effect.
Note: Test now with average acquisition mode and only 2 averages.
Ah, I managed to miss PA0PBZ's post that you were quoting, and didn't realize you were quoting something, so I was missing the context!I'm unable to infer from that screenshot what is surprising to you.Why do you think that there is nothing unusual?
I got my ds2202a-s today,Where did you buy a S2000A-S version? Didn't think they were released yet. Not listed at online distributors like http://rigolna.com (http://rigolna.com) and http://batronix.com (http://batronix.com)
Edit: they are listed at http://www.tequipment.net/rigol/series_ds2000a-series/ (http://www.tequipment.net/rigol/series_ds2000a-series/) but without prices.
What's the price difference between the S and non-S models?4) my hardware version is 1.2.2.0.2, but other A models have 1.0.2.0.2?, is that also due to the Signalgen?Most likely.
I can enter it in the formula line of course but the "Apply" button stays grayed out as long as "log(...)" appears in the formula. The status of the button usually changes from grey to white when a correct formular has been entered. Any idea?
not yet. Maybe one with v.01.01.00.02 on his system can try it out (Math -> Operate -> Advanced ->Expressions)?I can enter it in the formula line of course but the "Apply" button stays grayed out as long as "log(...)" appears in the formula. The status of the button usually changes from grey to white when a correct formular has been entered. Any idea?
Have you downgraded and tried the v.01.01.00.02 FW? It's likely a bug - and so would be good to know the extent of it.
not yet. Maybe one with v.01.01.00.02 on his system can try it out (Math -> Operate -> Advanced ->Expressions)?
Everything seems to work but not the logarithm function.Tested it on my DS2072A and yes, "Apply" grayed out while log() is in formula even if syntax is correct.
I am not able to use Log(CH1) or anything else using "log()" (even "log(10)" is not working).
I can enter it in the formula line of course but the "Apply" button stays grayed out as long as "log(...)" appears in the formula.
Everything seems to work but not the logarithm function.Tested it on my DS2072A and yes, "Apply" grayed out while log() is in formula even if syntax is correct.
I am not able to use Log(CH1) or anything else using "log()" (even "log(10)" is not working).
I can enter it in the formula line of course but the "Apply" button stays grayed out as long as "log(...)" appears in the formula.
Device: DS2072A converted to DS2202A, HW: 2.0 (1.0.2.0.2), SW: 00.02.01.00.03.
Thanks for your enthusiasm - but you're running the same FW as us, which has already been tested. :) We're looking to see if anyone with v.01 FW can test it.Have downgraded to 00.01.01.00.02 again.
Have downgraded to 00.01.01.00.02 again.
Bug with Log() dissapeared.
While you are reporting bugs, not that I can say this is a bug, when you first power on the unit all lights light up except the CH1 for some reason. If they are come on as a function test at power up, shouldn't CH1 also light too?It flashes for a second but then switches off. I agree - this is strange.
While you are reporting bugs, not that I can say this is a bug, when you first power on the unit all lights light up except the CH1 for some reason. If they are come on as a function test at power up, shouldn't CH1 also light too?On My DSO FW 02.01.00.03 HW 1.0.1.0.0
Please does DS2000 or DS2000A with latest firmware have cursors in XY mode?
That looks like tracking mode. I meant a feature like this. (https://www.eevblog.com/forum/reviews/my-new-toy-)-agilent-dsox2002a-sex-on-a-stick!/?action=dlattach;attach=44101;image)Once again, yes, the DS2000 has it (even though Teneyes misunderstood you). Please search the thread (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg349961/#msg349961) before posting questions that might be easy to find out on your own.
Have downgraded to 00.01.01.00.02 again.Thank you. I already passed this bug to Rigol and they verified it and said it will be passed to the engineers. However: Marmad you should still pass it over to Drieg as it will not be a mistake to report it through two different channels = chances for a correction are higher.
Bug with Log() dissapeared.
Have downgraded to 00.01.01.00.02 again.Thank you. I already passed this bug to Rigol and they verified it and said it will be passed to the engineers. However: Marmad you should still pass it over to Drieg as it will not be a mistake to report it through two different channels = chances for a correction are higher.
Bug with Log() dissapeared.
Which usb sticks are people finding that works on the scope? [...]I tried to use ~18 types of USB flash disks (Sandisk, Transcend, Kingston, Toshiba, card-readers and many others...), but only 2(!) types worked very well in bootloader mode with DG4000: Chinese noname 2GB (red) and 512MB (black)! :D
Protocal Version: USB 2.00
Current Speed: High Speed
Max Current: 100mA
USB Device ID: VID = 1221 PID = 3234
Serial Number: 2010042716480359
Device Vendor: USB2.0
Device Name: Flash Disk
Device Revision: 0000
Manufacturer: USB2.0
Product Model: Flash Disk
Product Revision: 3.00
Chip Vendor: Micov
Chip Part-Number: 3.00
Physical Disk Capacity: 1939865600 Bytes
Windows Disk Capacity: 1939603456 Bytes
Internal Tags: AA2E-QAHS
File System: FAT
ContMeas ID: 3CC6-01-00
Some one else mentioned this "bug" before, but just to elaborate (and it's been added to the bug list on page 1):
All SCPI commands related to CAN triggering and decoding appear to be missing in the latest FW. A bigger PITA is the fact that the mode is not correctly reported for TRIGGER, although it is for DECODE. That means if BUS1 is set to CAN, and you query:
:BUS1:MODE?
...you get:
CAN
...even though you can't change any of the parameters of the BUS.
But if TRIGGER is set to CAN, and you query:
:TRIG:MODE?
...the VISA connection times out, and any software (like RUU) will believe the DSO has been disconnected (since :TRIG:MODE? should ALWAYS return a value).
See my picture, it starts at going up, dotted line and exits on trigger position steady line ,The key is what's happening at the trigger position, not what happened before it.
( not on the steady line before trigger point, but on trigger point )
What was the position of your position button ?
See my picture, it starts at going up, dotted line and exits on trigger position steady line ,
( not on the steady line before trigger point, but on trigger point )
What was the position of your position button ?
All the information is in the bottom line of my image.QuoteSee my picture, it starts at going up, dotted line and exits on trigger position steady line ,
( not on the steady line before trigger point, but on trigger point )
Sorry, your image confirms the problem - it is NOT triggering on Exiting the Window - it's triggering on Entering. Rigol has definitely made a mistake, either with their English translations - or their understanding of what those terms mean.
It is easy to proof that you are wrong.., change the T1 cursor, and you will see that it changes the trigger point
and that is the exit.
I still dont agree, i still think it works correct.
But how to tell, it is in the definition of enter or exit the trigger level.
I try: the sine wave goes to the first T2, the the trigger knows it has to wait for the signal to exit
the window T1 level, the first hit of T1 is the enter mode, the second hit is the exit.
I still dont agree, i still think it works correct.
But how to tell, it is in the definition of enter or exit the trigger level.
It is called window, thats is correct but, it is not only in between, but also NOT inside is a window.
It is called window, thats is correct but, it is not only in between, but also NOT inside is a window.
I understand that - but then I think they choose the wrong name for the Trigger - at least as far as English is concerned. If I'm defining something with 4 sides (two screen edges and the two levels), I think of that as the Window. Perhaps the name Levels would be more appropriate - and a better description of what's happening.
About your post before: Using the same sine wave, gives the same outcome,
but try a complex signal, a dual tone or something with different hights in it,
then you see the advantage of windowing.
But how to tell, it is in the definition of enter or exit the trigger level.
Ah, so you're saying "high" + "enter" means "enter the region above the high threshold" not "enter the region between the thresholds." That explains why the manual calls it "Windows" (plural) trigger! Yeah, everything does make sense with that meaning (except the "rising edge of the input" part of the manual.) Thanks :)
Ah, so you're saying "high" + "enter" means "enter the region above the high threshold" not "enter the region between the thresholds." That explains why the manual calls it "Windows" (plural) trigger! Yeah, everything does make sense with that meaning (except the "rising edge of the input" part of the manual.) Thanks :)
It definitively makes more sense when you think of it as 2 Windows with a dead-band - but the definitions are still un-intuitive. When I set a Trigger to happen on a Falling edge - I expect the trigger to take place ON the Falling edge. This doesn't work that way - so the names/terms should be different because they aren't working like every other Falling/Rising edge trigger.
Rigol is also using the same edge icons that they use with triggers that actually trigger on an edge - so not good. They should be different - or the icons should automatically invert depending on ENTER/EXIT selection.
Actually, instead of RISING EDGE, FALLING EDGE, and EITHER EDGE, those terms/icons should be TOPWIN and BTMWIN and BOTH - and then everything works as it should.
I've been thinking about it a bit more, and I wonder why the Windows Trigger even has a WndType setting? With a TOPWIN or BTMWIN setting, it's just an edge trigger, isn't it? What's the use case where someone would rather set that up using a Windows Trigger?
The any-edge WndType and TIME trigger position follow similarly.
Does this make sense?
Hello freaks,
first of all, I know this board is discussing about sniffing on the I2C bus then rather of using the DSO. However so many people are there who are using the DSO. So I believe someone can answer my question very quick. I am adding a big sorry to write an off-topic question there.
My question is very simple: It is triggering problem
I am struggling with a measurement problem: I have a big power Generator who is generating 400Volts AC. The armature coil is driven by 15V DC.
Unfortunately sometimes the 400V is going to zero for 10 Seconds. After that, everything is OK for hours or days. I am trying to figure out the reason. For that I am monitoring on channel A the one 230V AC phase and on channel B the 15 DC. However how can I parametrize a trigger? I want to store the "event" of the two Voltages. At the moment I do not what the reason for the problem is. I do not know if the 15DC is going to zero or the 400V before.
My idea is to store the event of the power drop-out. The DSO should stop after that event the acquisition.
i can not sit hours or days on the DSO to wait for the drop-out event. The problem is the event is very short, only 10 Sec. It can happen in the middle of the night.
Thank you so much for our help. Any sorry again for the off-topic story.
MartyMC
If Rigol wants to reproduce the Window trigger as specified by most other sources (which is a single defined Window), then the Enter / Exit button names need to be reversed - and the Rise / Fall names should be changed to one of the suggestions previously mentioned.
If Rigol wants to reproduce the Window trigger as specified by most other sources (which is a single defined Window), then the Enter / Exit button names need to be reversed - and the Rise / Fall names should be changed to one of the suggestions previously mentioned.
i dont agree, read your post careful,
T2 is a window and T1 is a window,
So in my opinion Rigol is correct, in enter en exit..
on the ni site : Window Triggering: A window trigger occurs when a signal either enters or leaves a window you specify.
But i found this strange: see picture, i does not use T2 for trigger in this picture,
just using T1..., i think this is not correct..
Question on the usage of the DS2072. I've found one thing extremely annoying issue, but perhaps there's a course/fine setting for the position knob that I'm unaware of. When changing the vertical scale on the channel, I find it extremely annoying turning the position knob to find my signal again. When I want to look at a 5V dc signal, and have it set to 50mV, I find myself turning the vertical positioning knob for what seems like forever. Is there any way to do this faster? I know you can press the knob button to get to 0V, but even that can take forever going from 0V to 5V in such tiny increments. Thanks.
I've now officially changed the names in the new (currently beta) version of RUU so that the trigger actually makes sense ;D
Nice, but the point i wanted to make in my last post, T2 is totaly useless, is does nothing
also in your picture above, it makes no difference whatever you set T2 to, it will always trigger..
So the bug is that there is no T2 window, only a T1 window..
Nice, but the point i wanted to make in my last post, T2 is totaly useless, is does nothing
also in your picture above, it makes no difference whatever you set T2 to, it will always trigger..
So the bug is that there is no T2 window, only a T1 window..
Huh? ??? I don't understand what you mean. In my image, everything works exactly as it should with the name changes I've used.
Try to use level T2 for something you measure...., you will see that is does nothing..
it has no infuence on the measurement
test the following, in your top picture change the level of T2, see if something changes..
you can even turn it of the screen .. and nothing changes..
test the following, in your top picture change the level of T2, see if something changes..
you can even turn it of the screen .. and nothing changes..
Why would it? That wouldn't make any sense: it's not related to the Top Window - it's only related to the Bottom window. My first image has the DSO set to trigger when entering the *top* window.
Edit: if you select type down, then T1 is useless
if you selct type rise , then T2 is useless
So what is then the use of using two levels, if ONLY ONE is been used...???
Yes , i know the definition, but my point is that it is NOT WORKING, in the RIGOL
According to the definition, the signal has to cross T2 ( in rise) to trigger the first event,
and then crossing T2 triggers...
BUT in the RIGOL trun T2 down to the signal so, it does not cross T2, just T1, and it still works..., that is NO window......
Well oke, no problem, then we differ from opinion about that.......
Well oke, no problem, then we differ from opinion about that.......
It's not opinion, my friend - I don't think you understand how it's supposed to work. As mentioned in the text I copied and pasted, the trigger's purpose is to allow you to set two threshold voltages - creating a "window" in-between - and then have the DSO trigger if the signal enters OR exits (OR either) that "window". In the given example, monitoring a 5V power supply for positive and/or negative excursions outside the range of 4.5 and 5.5 volts.
This is exactly what the Rigol's Windows trigger can do - albeit hopefully with some changed names in a later FW ;)
As far i read all the info, it has to be T2 AND T1, but your interpretation is T1 OR T2, oke that makes this topic more simple
see if i can find more on it.
( rise and exit on. )
Why is there no trigger possible in picture 1.......
When changing the vertical scale on the channel, I find it extremely annoying turning the position knob to find my signal again. When I want to look at a 5V dc signal, and have it set to 50mV, I find myself turning the vertical positioning knob for what seems like forever.Try changing the VerticalExp setting: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg311883/#msg311883 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg311883/#msg311883)
Question on the usage of the DS2072. I've found one thing extremely annoying issue, but perhaps there's a course/fine setting for the position knob that I'm unaware of. When changing the vertical scale on the channel, I find it extremely annoying turning the position knob to find my signal again. When I want to look at a 5V dc signal, and have it set to 50mV, I find myself turning the vertical positioning knob for what seems like forever. Is there any way to do this faster? I know you can press the knob button to get to 0V, but even that can take forever going from 0V to 5V in such tiny increments. Thanks.
Sorry to steer off topic, but is there a link to your latest VISA software Marmad? I don't remember what thread I found it in, but the last time I downloaded it was roughly this summer.
Try changing the VerticalExp setting: https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg311883/#msg311883 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg311883/#msg311883)Damn!! I thought that was somewhere in the settings - but couldn't find it today when looking. It really should be in the Channel Menus! ;D
Why is there no trigger possible in picture 1.......The trigger is set to fire when the signal enters the top window, but the signal never enters the top window.
The trigger is set to fire when the signal enters the top window, but the signal never enters the top window. The legend for the trigger (upper left) is actually clearer than the text.
The icon you posted stays the same regardless of conditions. And the delta icon and level doesn't make sense if you think of the area as 2 windows. They only use it because they don't devote enough screen real estate for two distinct voltage levels.Aww, such a missed opportunity! Firmware update suggestion :) Ok, I'll redact my post.
Aww, such a missed opportunity! Firmware update suggestion :) Ok, I'll redact my post.
Question on the usage of the DS2072. I've found one thing extremely annoying issue, but perhaps there's a course/fine setting for the position knob that I'm unaware of. When changing the vertical scale on the channel, I find it extremely annoying turning the position knob to find my signal again. When I want to look at a 5V dc signal, and have it set to 50mV, I find myself turning the vertical positioning knob for what seems like forever. Is there any way to do this faster? I know you can press the knob button to get to 0V, but even that can take forever going from 0V to 5V in such tiny increments. Thanks.
@Pasky: While thinking back on your question, it dawned on me that I didn't think to ask you exactly what you're trying to do. Forgive me if the following is obvious to you, but if you're looking for disturbances in a 5V DC signal, using AC coupling will center the signal at 0V (screen center) but also pass glitches and other disturbances you can zoom in on. If you're trying to "zoom in" on the upper edge of a 0 to 5V waveform, it's not going to work because you're going to overdrive the input amp - and whatever edge you see will end up being distorted anyway.
Also thanks that VerticalEx setting did the trick
Hello,
can someone explain me how to use the self cal feature?
The manual says i should connect the trigger out on the back with CH1, CH2 and Extern trigger.
Does that mean, i have to connect all at once? What is the best way to connect one BNC to all 3 inputs?
Do i have to calibrate or is it calibrated on delivery?
Does the DS2000 Scope require external connections for self calibration?But I did not find new versions of UM, where this is has corrected :)
ANSWER: The DS2000 series self calibration routine specifies no connections to the inputs on the front panel. Early versions of the User's Manual are incorrect.
The manual says i should connect the trigger out on the back with CH1, CH2 and Extern trigger.
Does that mean, i have to connect all at once? What is the best way to connect one BNC to all 3 inputs?
Do i have to calibrate or is it calibrated on delivery?
From Rigol's site:Here you are, both the old DS2000 and the much newer DS2000A User's Guide say "Disconnect all the input channel connections".QuoteDoes the DS2000 Scope require external connections for self calibration?But I did not find new versions of UM, where this is has corrected :)
ANSWER: The DS2000 series self calibration routine specifies no connections to the inputs on the front panel. Early versions of the User's Manual are incorrect.
Self-calibration
The self-calibration program can quickly make the oscilloscope reach the best working state to get the most precise measurement values. You can perform self-calibration at any time especially when the change of the environment temperature is up to or more than 5 ?. Make sure that the oscilloscope has been warmed up or operated for more than 30 minutes before the self-calibration.
Disconnect all the input channel connections, and then press Utility -> Self-Cal and the self-calibration interface as shown in the figure below is displayed.
Press Start and the oscilloscope will start to execute the self-calibration program.
Press Exit to give up the self-calibration operation at any time and return to the previous menu.
Note: Most of the keys are disabled during the self-calibration.
Here you are, both the old DS2000 and the much newer DS2000A User's Guide say "Disconnect all the input channel connections".Wow, You found a last UM! Thanks. I saw on www.rigolna.com (http://www.rigolna.com), there is old versions.
Has it been confirmed already that the HW design is identical between DS2072A and DS2302A?
Hi guys.Rigol said only 2048 dots :(
Anyone know how much memory uses the DS2072 to estimate the FFT?
Thanks. ;)
Rigol said only 2048 dots :(Not so bad.
Not so bad.
Thank you very much.
Yes, using something like this:
@marmad: Is this your software? Because doesn't seems Matlab.
I get it. ;)
But why did not you use LabView or CVI to implement your software? Many advanced graphics functions are already made. :-//
http://www.ni.com/lwcvi (http://www.ni.com/lwcvi)
NO. ::)I get it. ;)
But why did not you use LabView or CVI to implement your software? Many advanced graphics functions are already made. :-//
http://www.ni.com/lwcvi (http://www.ni.com/lwcvi)
And labview is free software?
I'm waiting for the DS2000A with LA.
The Rigol MSO4000 has a sampling rate of 1GSPS for the LA. And I think that the DS1000D series LA has a sampling rate of 200MSPS.
I'm wondering if the DS2000A's LA will have a sampling rate of 500MSPS or 1GSPS.
Anyone know anything about it?
Neither is extra BW, trigger and decoder options etc. for Rigol products...NO. ::)I get it. ;)And labview is free software?
But why did not you use LabView or CVI to implement your software? Many advanced graphics functions are already made. :-//
http://www.ni.com/lwcvi (http://www.ni.com/lwcvi)
LOL...
Yes, using something like this:
Yes, using something like this:
what is the name of the software?
I'm waiting for the DS2000A with LA.
The Rigol MSO4000 has a sampling rate of 1GSPS for the LA. And I think that the DS1000D series LA has a sampling rate of 200MSPS.
I'm wondering if the DS2000A's LA will have a sampling rate of 500MSPS or 1GSPS.
Anyone know anything about it?
Thanks.
Are there any rumours or confirmations about upcoming DS2000 series with built-in LA?My speculations:
Will the LA have 8 channels or 16 channels? When is it expected? Details on launch date and model numbers? Pictures?
With no signal in, CH2 trace lines up perfectly with CH2 pointer and so the offset reading of the trace (if any) corresponds with the trace position. For CH1 the pointer and the trace are offset by several pixels so the offset reading and the trace position are different.
This is after the scope has calibrated itself after running about 6 hours. What's more, this offset of CH1 trace varies as you turn CH2 off and on.
Okay.Righteo, here it is, 273MB compressed to 13MB for the sake of upload.
I've taken a video and trying to compress it to a reasonable size to upload to youtube.
To check if there is an offset between the pointer and what the DSO perceives as ground, set the coupling to GND.When I set the coupling to ground there is ZERO offset between the pointer and the trace, both channels, and turning one channel on and off has no effect on the other channel. If I wind the sensitivity right up and set to X1 then CH1 has no offset and CH2 has +250uV offset. Using averaging to get good trace. If I short the BNC connector with a small screwdriver the CH2 offset goes down to 150uV, not zero like with GND coupling.
Not sure if anyone else has seen this yet - Each trace has a pointer at the edge of the screen identifying it as CH1 or CH2. With no signal in, CH2 trace lines up perfectly with CH2 pointer and so the offset reading of the trace (if any) corresponds with the trace position. For CH1 the pointer and the trace are offset by several pixels so the offset reading and the trace position are different. For example the pointer might be offset three divisions and the reading shows 3.00 volts offset but the trace is not directly over the graticule line. This is after the scope has calibrated itself after running about 6 hours. What's more, this offset of CH1 trace varies as you turn CH2 off and on.
Okay, so you can get a 1 pixel wide trace in some circumstances. See pic.High Res Acquisition, right?
Having a further look at this offset business - at about 1 or 2 pixels below halfway up the screen there is a point where the pointer and the trace line up perfectly. The further you go up or down the screen the greater the offset between the pointer and the trace, positive offset up the screen and negative offset down the screen. What's more, if you have the peak voltage reading turned on, at 1V/div it shows 40mV at 1 div, 80 mV at 2 div etc. So the scope is actually reading some kind of voltage.
The trace pointer can be moved in 1 pixel increments - 400 steps
The two pixel wide trace can only be moved in two pixel increments - 200 steps. (8 bit D/A?)
Discussed many many times in this thread: the DS2000 (and DS1000Z) map 200 ADC values to the 400 pixel high waveform display area.Okay, I'll try and find it. That's the trouble when threads get this long.
Okay, I'll try and find it. That's the trouble when threads get this long.Sorry if I came across as short - I know it can be difficult to locate things we've talked about in such a lengthy thread. It's not a very efficient system for locating information.
Here i uploaded two more samples, this time good waveforms.
- One sample SPI mode, 12Mbit. same settings as before.
- The other sample in RS232 mode, 2Mbit, 8bit, no parity, 1 stop, LSB.
When decode zoomed data in SPI mode, the bus status is shifted respect waveforms.Isn't this the same issue that was on the DS4k a couple of firmware versions ago. Ie, the decoded data "drifted" in relation to the trace when "zooming" and panning thru the captured data?
I'm triggering on external event with dedicated pin, I need to isolate especific data for debug.
Hello Mark_O.
Some more info:
- As i can see, decode is not related to trigger at all but wave forms, you can even decode in auto triggering mode in the midle of a string.
- The lines i draw are in the correct place, confirmed with LA1034 LOGICPORT tool that is decoding as expected.
- I dont know how the scope knows the start bit, anyway it is doing it in not zoomed strings any kind of trigger.
- In SPI i trigger with CS signal, sometimes with GPIO, edge or SPI trigger with same result in zoomed string.
- In current string I can not trigger In RS232 mode because the scope suport up to 900Kb for trigger, the string is 2Mb.
I don`t know if any parameter is wrong, but ... decoded data don´t match waveforms.
marmad:
- Where in the manual you can find this? "protocol decoding should be teamed with the corresponding trigger".
- After heavy use of decode function, i can asure that it is not dependant of trigger mode. Please see the new image, trigger SPI.
Is anyone here actually going to send them a list of bugs?As you can read earlier in this topic, e.g. here (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg364020/?topicseen#msg364020), the OP marmard (https://www.eevblog.com/forum/profile/?u=9091) send all bugs to Rigol via Drieg (https://www.eevblog.com/forum/profile/?u=343) (Petr Šmíd) who owns the official Rigol distributor Silicon Electronics (http://silcon.cz) in the Czech Republic.
I found, decoding is ok, the problem is the data display is shifted respect waveforms, more far from trigger event more shifted.
I think it is an cumulative error calculating the position of data to show.
Can this be a software thing or is it just the kinda washed out screen quality of the DS2000 series?
I was messing with the menu, actually looking for the FFT function and pressed a soft button to do with Math... ( It had options X Y Math with tick boxes) X was originally ticked but I was having problems clearing the menu ( It was saying something like 'must choose one') so I also ticked Math.AFAIK, I don't have any menu or sub-menu on my DS2000 similar to what you're mentioning:
The Math box duly checked ok, but at some point moments later the scope locked up.
I was messing with the menu, actually looking for the FFT function and pressed a soft button to do with Math... ( It had options X Y Math with tick boxes) X was originally ticked but I was having problems clearing the menu ( It was saying something like 'must choose one') so I also ticked Math.AFAIK, I don't have any menu or sub-menu on my DS2000 similar to what you're mentioning: in fact, I don't seem to have a single menu that even uses the word "Math". The Math Menu (when you press the MATH button) is just a subset of features including FFT, Logic, simple A/B formulas, and advanced formulas using variables. So without better info, there is no way to try to replicate your problem.
The Math box duly checked ok, but at some point moments later the scope locked up.
Anyway - yes .. something I did when that menu was showing has locked it up.
I will try a re-boot - unless there's a 'hold down at power up' button that resets everything?
UI of triggering is strange, for example I want to see RS232 data as ASCI chars, I see interesting place to me, and want to trigger on specific letter 'D' for example. For that purpose I need to find somewhere ASCI codes table and find the number of that letter. |O
Just because triggering UI works with numbers only, no letters, no HEX. :-//
I've found picture with another example, I2C decoding shows hex values, triggering works with dec values only.
Someone sent it to me (might be the same guy) by e-mail. I put it up on my website .... the file is:
http://www.gotroot.ca/rigol/DS2000-03_00_00_00.7z (http://www.gotroot.ca/rigol/DS2000-03_00_00_00.7z)
Someone sent it to me (might be the same guy) by e-mail. I put it up on my website, but I was just assuming it was actually the existing version from February, so the filename is wrong if it is in fact a new version. I won't be able to try it for a few days, but the file is:
http://www.gotroot.ca/rigol/DS2000-02_01_00_03.7z (http://www.gotroot.ca/rigol/DS2000-02_01_00_03.7z)
If anyone else wants to give it a stab. Let me know if I should rename it...
Thanks! The compressed filename is indeed wrong, but the .GEL binary file has ASCII numbers 00.03.00.00.00 at the beginning.
The file is much larger than previous .GEL files.
I renamed the file. New link:I've fixed the FW links in the second post (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) (moved all the files from rapidshare to my own server) and added the latest v.03 to the list. I haven't heard anything about this latest version, but I'm currently travelling and away from the DSO, so no chance to experiment with it for awhile.
http://www.gotroot.ca/rigol/DS2000-03_00_00_00.7z (http://www.gotroot.ca/rigol/DS2000-03_00_00_00.7z)
If anyone has the actual 00.02.01.00.03 files I'd appreciate a copy to put up. The rapidshare links upthread are all broken for me.
Sometimes the intensity stays tha same even if you try to adjust it. Probably someone has noticed it here. This issue appears at certain memory length settings, I think.Hi Hydrawerk
Sometimes the intensity stays tha same even if you try to adjust it. Probably someone has noticed it here. This issue appears at certain memory length settings, I think.
Rigol DS2000 Intensity odd behaviour (https://www.youtube.com/watch?v=vh0xJlMVExY#)
My Wave Intensity always goes to 50% no matter what I attempt to set it to. Is this the same issue as in the previous few posts? Brightness adjusts the grid intensity and works ok.
OK, I didn't know that. I did read the "waveform intensity" part of the book. So now, the intensity setting stays where I set it, but it doesn't change the brightness of the waveform. Am I interpreting what the "waveform" is? I think it's the yellow and blue channel 1/channel 2 traces. I upgraded to 00.02.01.00.03 this morning. I "think" the intensity used to work ok, but my memory is not to be trusted, either.
Pushing down on the intensity adjustment knob sets the intensity to 50% (it's a shortcut).
Don't push it down after adjusting the intensity. Just stop turning the knob and the intensity will lock to your setting after a second or so.
OK, I didn't know that. I did read the "waveform intensity" part of the book. So now, the intensity setting stays where I set it, but it doesn't change the brightness of the waveform. Am I interpreting what the "waveform" is? I think it's the yellow and blue channel 1/channel 2 traces. I upgraded to 00.02.01.00.03 this morning. I "think" the intensity used to work ok, but my memory is not to be trusted, either.
Pushing down on the intensity adjustment knob sets the intensity to 50% (it's a shortcut).
Don't push it down after adjusting the intensity. Just stop turning the knob and the intensity will lock to your setting after a second or so.
Very good news. :-+Are there any rumours or confirmations about upcoming DS2000 series with built-in LA?My speculations:
Will the LA have 8 channels or 16 channels? When is it expected? Details on launch date and model numbers? Pictures?
- Upcoming DS2000 series with built-in LA? Yes, no doubt!
- Model numbers: DS2072AD, DS2102AD, DS2202AD and DS2302AD.
- LA 8 Channels at 1GSPS.
- Launch in the EU, 6 months after it is launched in China.
https://www.eevblog.com/forum/testgear/rigol-ds2000-series-model-designation/ (https://www.eevblog.com/forum/testgear/rigol-ds2000-series-model-designation/)
https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270640/#msg270640 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270640/#msg270640)
Very good news. :-+Are there any rumours or confirmations about upcoming DS2000 series with built-in LA?My speculations:
Will the LA have 8 channels or 16 channels? When is it expected? Details on launch date and model numbers? Pictures?
- Upcoming DS2000 series with built-in LA? Yes, no doubt!
- Model numbers: DS2072AD, DS2102AD, DS2202AD and DS2302AD.
- LA 8 Channels at 1GSPS.
- Launch in the EU, 6 months after it is launched in China.
https://www.eevblog.com/forum/testgear/rigol-ds2000-series-model-designation/ (https://www.eevblog.com/forum/testgear/rigol-ds2000-series-model-designation/)
https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270640/#msg270640 (https://www.eevblog.com/forum/testgear/rigol-ds2000-hardware-version-2-0/msg270640/#msg270640)
Yes, the waveform intensity control is the brightness of the traces.You are 100% correct. When looking at the square wave, brightness has a good effect on the rise/fall lines, and does close to zilch for the horizontal lines. I finally found the button-push 50% brightness setting in the manual section for the multi-function knob. So if you read and remember the whole manual, the info is there. If you use it as a single-subject reference, you'll never find how the knob push sets the brightness. Thanks, from a part-time user who doesn't remember all the details.
The range of brightness is not very dramatic. Try looking at the rise/fall transitions of the calibration waveform as you adjust the intensity. You should see the brightness change in them.
May be this already mentioned somewhere, but I just noticed it: MSO version of DS2000A series is coming!
Maybe that's what the big v00.03 firmware update and version number jump is about?!
I dont think it will continuous fills the memory non stop, and never stop, there will be some dead time...?Hi Wim.
to do things i mentioned above. Maybe i am wrong, but i dont think the DSO is a real time non stop sampling device.
Teneyes,
Try adjusting the trigger Holdoff time to around 3 - 4 mS.
It looks like the trigger circuit has re-armed and is triggering on the next pulse that it sees.
Good Point.Teneyes,
Try adjusting the trigger Holdoff time to around 3 - 4 mS.
It looks like the trigger circuit has re-armed and is triggering on the next pulse that it sees.
i think the same, it triggers on the first on going pulse.
I did the same test, and indeed, it triggers on the fist pulse it finds, i think thats is correct
Played around with the delay, and that worked for me.., then it triggers oke
Can anyone Confirm that the DS2000 does NOT decode when recording frames?
Hi Len,HI Mark
It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.
It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.
Mark, did you miss this demonstration (https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/msg419795/#msg419795), where teneyes showed it working on a DS2000? (Post capture, not real-time.)I'm currently travelling so I haven't been following the threads closely, but I've tried decoding on segments before (using I2C) and it didn't work.
Hi Folks , I tried to re test the decoding of Frames in record mode referenced aboveIt does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.Mark, did you miss this demonstration (https://www.eevblog.com/forum/testgear/rigol-mso4000-and-ds4000-tests-bugs-firmware-questions-etc/msg419795/#msg419795), where teneyes showed it working on a DS2000? (Post capture, not real-time.)
This Feature is only in latest FW 00.03.00.00 :-+ , I think Rigol is smirking at me ;D
Here I am checking the recording & decoding of 2 Channels RS232
230byte bursts at 10sec on Ch1, Ch2 continuous
Note: The decoding of a new frame in playback takes about 2 seconds at this setup
A High Speed Test of RS232 Data Recording & decoding
I used:
...
475 Byte Block
...
Recorded 508 Frames
For a Total of 241300 Bytes recorded
Data Decoding Limit ( RS232 test)
it appears that to Decode without Errors, at least 28 Pts must be allocated for Each 'BIT' of data or else the Decode will miss a byte.
To test I used:
2ms/div
70Kpts/display
89.2Kb.s all OK = 28.027 Pts/bit
89.4Kb/s Errors occuring
See Pics
In your second test at 89.4Kb/s, if you had just zoomed out a bit from the 100us/div you were at, then it would have had more bits to work with, and started "working" again. Even though the sample Pts/dataBit hadn't changed at all.EDIT: This Bug is Fixed in Latest Firmware 00.03.00.01.03
I think. ;D
..the key point being that the same results would have been obtained if those 508 frames had gaps of seconds or minutes or hours between them, regardless of the inter-frame latencies. (Plus, you could turn on the ClockTag, and see the date/time stamp for each frame.)I agree and here is an example ( thanks for pointing out TimeTag)
That's the power of segmented captures.
Just to make it Clear to all;
Zooming has no effect if there are Decoding errors. The decoding is done on the full un-Zoomed data.
Below I show 3 displays where the errors still exists. Note you can see the error gaps
Also Note that if there are errors in non- Record mode there will be errors in the recorded frame ( same recorded points are used, Not the display data)
I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28, it fails, in fact it is still working, most of the time (82%). And look at the pattern... 2 correct, 1 skipped, 3 correct, 1 skipped. Repeat. This suggests that it's phasing in and out, or something similar. The ones it missed didn't have any fewer samples/bit than the ones it handled properly!I was wrong
Is anyone else seeing a screen flicker in their ds2072a? It is especially noticeable on grays, and is probably caused by backlight leds. I would estimate the frequency at 40-60 hz. I searched here and on Google and surprisingly didn't find any posts mention this. Did I get a bad unit, or are you all less picky than I am? The scope is not modified in any way.I noticed it a little when you are looking down toward the screen maybe 60 deg off axis but not when looking straight on. Mostly when the menus were showing and I *think* just after switch-on.
I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28,...I was wrong
I did more tests and I think I can show the limit for samples per bit for good decoding
...
My Conclusion, The requirement for good decoding is 4 samples per Bit (RS232)
Think about what '4 Sample points/Data Bit' implies for acquiring comms-type data in segments, in RecordMode! Properly adjusted, the duration and size can be quite amazing. At just 4 samples/bit, that's 7x(!) as long as you originally thought possible.Yes the recorded frame below of a 270 byte/frame and at 8128 frames shows that 2,194,560 Bytes of data were recorded.
so i tested version FW 00.03 but still the noise is there.
Test signal is 100 Mhz 0 dB, on other scoop it is a steady clean signal. ( also on FW 00.01.01, or on one channel ) )
so i tested version FW 00.03 but still the noise is there.EDIT: This is better in Latest Firmware 00.03.00.01.03
Test signal is 100 Mhz 0 dB, on other scoop it is a steady clean signal. ( also on FW 00.01.01, or on one channel ) )
i did a test on a DS1000z where you can turn off and on Sin(x)/x
that makes a lot...lot off difference. ( temp a DS1000z for test ).
But why was it then on FW version 01 of the DS2000 better, what did they change..?
i did a test on a DS1000z where you can turn off and on Sin(x)/x
that makes a lot...lot off difference. ( temp a DS1000z for test ).
Implementation of FFT, differenses between DS2000 and DS1000z, most@Wim
things works the same on these two DSO.
But on the DS1000z the FFT is more user friendly, even better as on the DS2000
Good to see Wim, I hope those features will go into the DS2000 Firmware someday
On the DS1000;
Can you please check what happens when you push the Multifunction knob when selecting the FFT vertical offset & Vertical Scale,
On the DS2000 with Vrms , pushing knob set 0 Vrms to the middle of the scale , Useless
What is a negative Volt on an FFT display???
Thanks
With more and more people stating and receiving the New FW 00.03.00.00, I thinking it would good to report new Bugs here. Marmad has kept a good list on the 3rd post of this Blog. Altough Marmad usually confirms all bugs himself , I think it would be helpful for a few others to confirm any reports. Also if any Fixs to an existing bug is a complete fixed.
These are Bugs I have found:
#03__01 The Clear Button does not work.
#03__02 The decode display does not clear when decode is turned off
#03__03 Once the lg(CH1) advance Math function is applied you can Edit the function;
If the Expression button is press the DSO hangs. and if in start Last System. the
attempt to change the expression , will hang the DSO!!! :-- :--
#03__04 The Set Counter Menu has display Error (unnecessary scrolling,small ) see Pics
This occurs when system 'System'-'Power On' - is set to 'Last' and the trigger is
NOT set to EDGE trigger.
Power cycle after PULSE trigger causes 3 items in Menu ,most others 2 items set in Menu
Auto Setup Button resets trigger to Edge and all 4 Menu Items??? (CH1,Ch2,Ext,Off)
If anyone ventures onto Fw 00.03.00.00, please help to confirm any of these.
Edit 1 Added more info on Bug #03__04
I have not found anything from the manufacturer that denotes the improvements found in the .03 version. I may have missed the valid reasons for doing so, and it would be nice if someone could point those features/improvements out to a newbie like me!HI Rick and welcome to this Forum,
So, should I install 00.03.00.00? Thanks in advance for any responses.
Rick
What does "it takes 171S to change from 00.03 to 00.02 and 237S to change from 00.02 to 00.03 bigger file" mean? Is that a file that is resident on the scope?
hello
I wanted to learn about the lithium battery (cr2032) in (ds2072)
it is only responsible for the RTC belt ?? or remove it if it does not affect the calibration data???
in some multimeter Rigol which battery is installed to preserve the memory of calibration constants....
important question of who can know?
Here's a weird bug in the average function :
-hook up channel one to the 1khz test signal
-hit auto button
-change timebase to 50ms
now your signal just looks like a wide band, like you'd expect on a graded display. OK.
-turn on averaging in the acquire menu, 2x will do nicely.
-> wtf! what happened to our signal? the wide band just turned into a small ribbon
-it gets even weirder when turning on anti-aliasing, now the ribbon is waving over the screen
What is happening here? The scope is fetching 14Mpts, so there shouldnt be any weird aliasing things happening, but still it's there.
It looks normal again when you go to 20ms timebase.
Did you try setting the trigger to normal instead of auto?
Here's a weird bug in the average function :Oh it's an Undocumented feature by Rigol. :)
-turn on averaging in the acquire menu, 2x will do nicely.
Note to Newbies: I used Marmad's RUU software to capture and post here in 30 sec/pix (no stick 4 me)
Here's a weird bug in the average function :Oh it's an Undocumented feature by Rigol. :)
-turn on averaging in the acquire menu, 2x will do nicely.
I think some sort of Beat freq. with the way Averaging is calculated, combined with Intensity grading and Bug #18 noted in the 3rd post of this blog
Here's some more disppays:
at slightly off frequencies (999.8, 999.9, 1000.05, 1000.1, 1000.2 Hz)
at off duty cycle 50.7%
and scanning at 49.80ms/div .
Note to Newbies: I used Marmad's RUU software to capture and post here in 30 sec/pix (no stick 4 me)
...
I just received new FW 00.03.00.01.03
New BUG, downloading a screen shot via ethernet is soooo slowwww ( 35 sec) , i was thinking RUU was not working anymore,reset several times, but it was the RIGOl, also tested with other PC and Ultra Sigma, same result.Yes I confirm Ethernet access to the DS2000 with FW 00.03.00.01.03 is much slower than FW 00.02.01.00.03
Don't know if it will be helpful... But while Dave still is waiting for stable FW to do his DS2000 review ;) I've shot my own video.
Why it can be not helpfull? Well, it is not on English. :blah:
Maybe I will do some captions on English later. Don't know yet.
I'm not sure what the "Interframe space consists of at least three consecutive recessive (1) bits" spec.
in 'CAN' protocol means. ??
#4 shows the minimum time before next Burst will be decoded = about 14 Bit periods
Well , Rigol knows of the SCPI and I got 3 messages from China, thanking me for my reports and stating that my info was referred to R&D then this response 2 hours later.
We will fix this in next version ,thank you .
I think we know that FW 00.03.00.01.02 was a release to support the new DS2000A-S models being so much bigger FW...
My DS2072A-S works happily on rev. 2.x firmware, signal generator and all. Whatever's been added in 3.x, I don't think A-S support is it.
May be this already mentioned somewhere, but I just noticed it: MSO version of DS2000A series is coming!There's also a MSO1000Z series at the Chinese site, which isn't listed at the international site yet. The links for the MSO1000Z and MSO2000A images both below both contain the upload date March 27 2014.
Maybe that's what the big v00.03 firmware update and version number jump is about?!
See http://www.rigol.com/ (http://www.rigol.com/) and select the Chinese localization.
(http://www.rigol.com/upload/page/1/slide_12091_1395971711_b8bda_c32b8.jpg)
Skipped the beta. No idea what was on it out-of-the-box (idiot boy forgot to check first!). Tried it on 2.x grab-the-key firmware and 00.03.00.01.03, both of which would allow feature unlocking keys but no bandwidth change keys, so it's on 2.x non-A-keys firmware for now, fully unlocked ;DMy DS2072A-S works happily on rev. 2.x firmware, signal generator and all. Whatever's been added in 3.x, I don't think A-S support is it.@AintaBigCleaver :D
Did you try FW 00.03.00.01.03 ?
or Beta FW=00.03.00.00.00 ?
Does anyone know how Agilent deals with displaying CAN data?? Hydrawerk??Hi Teneyes. :)
Obscure Bug in FW 00.03.00.01.02
In the Display below , See what is wrong with the Settings
Thanks Carrington
I could not download the second link
The videos and pdf file shows how a DSO decodes message and then shows the decoded data ,but does NOT show enough detail to show Stuffed Bits and the bit by bit comparison
Thanks CarringtonYou're welcome.
I could not download the second linkYes, it's the same video.
Could this be the Video, showing how Hardware decoding helps
Agilent video (http://www.home.agilent.com/agilent/redirector.jspx?action=ref&cname=AGILENT_EDITORIAL&ckey=826337&lc=eng&cc=CA&nfr=-11143.0.00)
It might be interesting to see a test of the speed of Protocol decoding between Rigol vs TekSure!
The videos and pdf file shows how a DSO decodes message and then shows the decoded data ,but does NOT show enough detail to show Stuffed Bits and the bit by bit comparisonNo, about that particular detail, I haven't found anything.
Oops! Me neither.Thanks Carrington
I could not download the second link
Me neither.
No idea, but probably you're right.QuoteThe videos and pdf file shows how a DSO decodes message and then shows the decoded data ,but does NOT show enough detail to show Stuffed Bits and the bit by bit comparison
I doubt any of them do. You're doing the bit-wise comparison to check if the Rigol is decoding properly. The rest assume they do decode properly, so there's no reason to check the device operation. I.e., the purpose is to test the bus, not the test instrument. For that purpose, no one cares which bits are stuff bits.
A self-criticism :):) There is nothing wrong, now we know more than before.
Here's a Test to see Frequency tolerance of the Rigol CAN bus Decoding;
The base Frequency was set to max. of 1.0Mb/s and the input message bit rate was raised until an Error and then lower until errors.
Displays;
1: Good decoding at a higher Bit rate (1.087Mb/s) just before Errors occured
2: No decoding at a higher Bit rate (1.111Mb/s) as Errors occur
3: Good decoding at a lower Bit rate (0.877Mb/s) just before Errors occured
4: Error decoding at a higher Bit rate (0.862Mb/s) as Errors occur
So I would say Tolerance is -12% to +8.7 % of Baud rate:
but I am not sure what the theoretical range is?
The timing could be from the the Tigger point, but with 70 bit times there might be re-syncing at the bit change edges
I was thinking more of the occasion where a process monitoring device, one is design/building, is not stuffing the bit in or is causing errors in the CAN msg.
Any time a device is showing voltage and decoded bits it is nice to see the Bit-to-Bit Matching clearly.
For Rigiol , maybe only when a Binary display of the message is selected.
@Electrofan3: Good decoding at a lower Bit rate (0.915Mb/s) just before Errors occuredNot sure if I'm measuring the same things you are measuring but I found on my 2072 that RS232 decodes reliably in the range of - 6% to 5%. It was at a slow rate and just one test. EF
4: Error decoding at a higher Bit rate (0.909Mb/s) as Errors occur
So I would say Tolerance is -8.5% to +8.7 % of Baud rate:
Well , maybe I opened a 'CAN' of worms
Let me start will this past discussion of how soon is the DS2000 able to decode the next 'CAN' bus message.?
Here I show you that it depends on the CRC!
If the CRC is correct the DS2000 will decode if there is a 3 Bit times of Idle
If the CRC is Not correct the DS2000 will decode if there is a 7 Bit times of Idle
Here are the Displays:
1: CAN message bursts with Ok CRC has good Decoding at a Interframe space of 6 bit times
2: CAN message bursts with Bad CRC has good Decoding at a Interframe space of 7 bit times, Should do better
3: CAN message bursts with Bad CRC Skips Decoding at a Interframe space of 6 bit times Should do better
4: CAN message bursts with Ok CRC has good Decoding at a Interframe space of 3 bit times
5: CAN message bursts with Ok CRC has NO Decoding at a Interframe space of 2 bit times Could do better
I think this is a BUG and I have reported it to Rigol
Now , although the InterFrame spacing Spec (http://en.wikipedia.org/wiki/CAN_bus#Interframe_spacing) for devices on a 'CAN' bus , is 'to leave the bus idle for 3 bit times , I see no reason for using a DSO as a diagnostic tool to decode Message faster than the devices. Yes, the DSO can scan for the End of Frame (1111111) flag , then open to decode any correct message that follows. Then the DSO should display a RED Bar showing faulty interframe space and the good message.
To do the testing I want to create a specific message,
but I did not have any 'CAN' bus devices to test and that would show a complete message to test with,
so I created my own messages that I can vary parameters (voltages, timing, data, and errors ) and be correct.
I needed to create the CRC for the complete message also.
I did research and tried different software , but no program generated the Correct 15 bit 'CAN' bus CRC.
So I went back to basics
and manually formed the CRC for the message I used in Testing
After 4 mistakes, and slow working here is my long division for the CAN bus CRC
I hope you are amused
In theory, that may be interesting. But in practice, I don't think it's either necessary or reasonable for a diagnostic test device to decode bus traffic that will never occur.Thanks Mark_O, for the feedback ,
I'd have to dig back into the Bosch defining specs for CAN 2.0 to find all the nitty-gritty details of the state-transitions that occur after a bus-error, but I can tell you for sure that recovery is never instantaneous, and no properly operating CAN transmitter will ever start sending the next frame as soon as you'd like the Rigol to be able to decode it.
As for "will never occur." but I would say "SHOULD never occur"
Has anyone had any problems with a Rigol DS1074Z(-S) scope not booting up from time to time?
I believe I am running the SP5 firmware (which it came with, not sure if there is a new version 3.0 out yet) , and from time to time the scope just sits there and doesn't boot up. No lights from the front panel light up, and the screen just says Rigol.
If I repower the scope it works fine.
It has happened with both installed and uninstalled options key (still on trial period for a few hours).
Very good news, Sigrok now supports the RIGOL DS2000, and runs on windows!
http://sigrok.org/wiki/Rigol_DS2000_series (http://sigrok.org/wiki/Rigol_DS2000_series)
http://sigrok.org/wiki/Downloads (http://sigrok.org/wiki/Downloads)
Very good news, Sigrok now supports the RIGOL DS2000, and runs on windows!Is CAN decoding after the data is transfered to the PC??
Thanks, didn't even know this existed and it does support my DMM as well, good because the software that came with it is not that great.
Is CAN decoding after the data is transfered to the PC??I suppose so.
Have you seen these new reviews?
Here's an Odd Occurance
Are the steps below the best steps for upgrading firmware, or are there better steps?
Also, where is the best place to get FW v.3 for the 2072 (2072, not 2072A in case there is any difference)?
Is the screen supposed to show anything when the upgrade is done? Or does the scope need to be powered off and back on when the all the front panel lights are lit continuously? Thx!
Ok, success! (I think). Thanks!No problem. You can use the technique described in post 2 (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684) to get the full firmware version info to check that the upgrade/downgrade occurred correctly.
I found another new feature in FW v.3 - something we've been asking them for over the last year - and although it's a baby step by Rigol, at least it's a baby step in the right direction:
The External Trigger input can now (finally) be used for a second trigger type: PULSE
- how would you wire this up to demonstrate this?
This would help explain Teneyes' earlier discovery that the Ext. Trigger can now be used as a source for the counter: it seems to go hand-in-hand with adding pulse measuring capabilities.
- how would you wire this up to demonstrate this?
An encouraging sign... let's hope they keep adding more triggers it can be used as a source for.
the Ext. Trigger can now be used as a source for the counter:Here is 1MHz on Ch1 , with a 250KHz ,phase locked to the 1Mhz and connect to the External Trigger.
- how would you wire this up to demonstrate this?
Teneyes, can you show us the same test using square waves, say from a synchronous binary counter chip? If there is a difference there, that would be serious.
It would mean something is way wrong. With a sinewave input maybe there is some phase shift in the external analog circuit, but inputting two square waves with known identical corresponding transitions every 4 cycles, only different in frequency, it is a very easy test to reproduce, and if an anomaly shows up, then yeah, theres problems alright.
Teneyes, can you show us the same test using square waves, say from a synchronous binary counter chip? If there is a difference there, that would be serious.@Circlotron & Others
I tested with Sin Wave 100mV RMS, and with Sq wave 1Vpp. I did not see any difference in the jitter.also I see jitter of 500nS if I trigger externally.
I see jitter on a weak signal. < 280mVpp
What was the amplitude of the signal in your test?
Symetrically at 0Volts, so -500..+500mvI tested with Sin Wave 100mV RMS, and with Sq wave 1Vpp. I did not see any difference in the jitter.was the Sq.wave above and below 0.0 Vdc ,
What version of FW??
Note that there appears to be about a 9ns offset between the "EDGE" External Trigger point and the CH1 trace.
I can confirm the delay of 9nS, also I see jitter of 500nS if I trigger externally.
Symetrically at 0Volts, so -500..+500mv
FW is 3.00.01.03
Note that there appears to be about a 9ns offset between the "EDGE" External Trigger point and the CH1 trace.
The offset I get with a 0V External Trigger level is ~5-6ns (see image #1 - it varies a bit based on input voltage level). But since the External Trigger is a different signal path from the channel inputs, I would expect some difference. Of course, the offset changes based on the trigger level set: note the 3 images with a 0, 500mv, and 750mV trigger level. At 500mv (with 2V pk-to-pk square wave input simultaneously to CH1 and EXT) there is zero offset.
It appears the optimal setting for an External Trigger (assuming you want as little offset as possible) is between ~1/4 to 2/3 (with 1/2 between the average) of the respective-going voltage (i.e. for falling/negative edges/pulses ~half of the negative voltage - for rising/positive edges/pulses ~half of the positive voltage).I can confirm the delay of 9nS, also I see jitter of 500nS if I trigger externally.
Symetrically at 0Volts, so -500..+500mv
FW is 3.00.01.03
+500mV/-500mV square wave - virtually zero jitter (and no offset with trigger level set to 250mV). Check animated GIF of captured segments.
Nice animated JPEG ! almost a real scope on your desktop :)
However I can see horizontal jitter, if you look closely, you can spot it. It is even better viewable with a fast risetime signal, and on 2nS/div....
We are talking about 500pSec. This dissapears if you change the trigger from ext to ch1 (at least on mine)
Has anyone determined the better of the two latest firmwares for the DS2000 series yet? FW v2.xxxx or v3.xxxxx?
I just bought a DS2202 non A version and have the desire to unlock all the options but want to make sure I have the better (less buggy) of the firmwares in place first.
marmad,
Thank you, I took the plunge and performed the v3 update.. guess we shall see.. :) .. Thank you.
so far, so good!
what a great piece of equipment for the money, very impressive!
JLM
If Rigol made a DS2074 version of this scope, it would be perfection.
If Rigol made a DS2074 version of this scope, it would be perfection.
I don't think it's a good idea.Even a higher level of perfection would be a DS2304 with room to grow!.. :)A few members here have 2 Rigols and connect trig out/in.
Maybe it's called the 'Combo DS1/2306'
I don't think it's a good idea.We had an in-depth discussion about the Trigger Out delay and jitter in this very thread over a year ago. (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg224637/#msg224637) But these things can be compensated for when using the Trigger Out.
As I wrote here, Trig Out signal from DS2072 has very bad jitter.
It seems, that Trig Out of 2072a is not hardware, but a kind of software (from FPGA logic) and it is suitable for low frequencies only, not higher than 1MHz I think.The Trigger Out reflects the actual waveform capture rate of the DSO; it doesn't pass through triggers it doesn't use. As such, it's frequency will NEVER be higher than ~52kHz maximum.
Indeed i have, thats why i was looking at the ds1000, connected to a ds2000..!!, 6 channel DSO with lots of different timebases.@Wim13 - Which reminds me - what is the situation with the Trigger Out on the DS1000Z series? Less delay and/or jitter?
@Wim13 - Which reminds me - what is the situation with the Trigger Out on the DS1000Z series? Less delay and/or jitter?Well I did some tests with a DS1072z trigger out to ext trigger in of the DS2072.
If you want both scopes together to act as a 6 channnel scope the delay can be corrected for, but the jitter means that for frequencies > say 1 MHz the jitter becomes annoying....
But I don't think the annoyance of the jitter would be related to the frequency of the input signal (or DUT).Yes of course, the jitter is always 8 ns, independent of the timebase and/or the observed waveform. What I meant to say is that (in my opinion) this method of locking both scopes is not very useful for displaying waveforms above (an arbitrary chosen frequency of say) 1 MHz as then 8 ns becomes a significant percentage of the analyzed and displayed frequency's period, resulting in a visible and annoying smear of the waveform.... For lower frequencies the jitter is just less or not at all visible.
Thanks for this interesting video. I was just struggling with an I2C problem, and learned a few things how to optimise use of the segmented memory (bummer it will not decode in analyze mode, maybe in the next FW update?). Maybe I should fire up the hex editor.
Looking forward to seeing this functionality in RUU.
Thanks Mark
That's a good trick to search recorded frames of data :-+
It is great that you will incorporate it in a future version of RUU.
Here is a tip to use with manual Hex editing; I think the hex editor will fill a selected data block with a given byte pattern. That is fill 240 bytes with x' 21 3C E1 FF' repeated to fill the block, for example. That is what I used to patch Rigol waveform files. I hope that will help until RUU.
Thanks again.
kinda annoying and I don't know why this happens all of the sudden: I power off my DS2072(2302) normally and pull the plug. Now, whenever I put it back in the next day, the DSO resets itself (like it does after self cal for example)Nikwing. , did you set power on to 'Last' and NOT. To 'Default'. In Util menu?
You may wish to set intensity higher
the 2nd problem is about measuring. I try to measure/calibrate an ECG circuit, setting it to 5 mV/DIV. If I don't use high res, it's really impossible to measure
I tried both, "default" and "last" in the settings, it happened with both (more than 1 try for both settings)
I'll give it another try :)
the 2nd problem is about measuring. I try to measure/calibrate an ECG circuit, setting it to 5 mV/DIV. If I don't use high res, it's really impossible to measure anything.You shouldn't have a "fat" trace at 5mV/div (it should be about 1/10 a division.) If you unplug everything from the scope, is the trace still fat? If not, then you're letting noise in from somewhere and should adjust your measurement setup. It's pretty easy to pick up 5mV of noise.
increasing the time base to something like 10 ... 100 ms/DIV makes the DSO totally slow, no matter what sample memory I select (the lesser the memory, the weaker the visibility of the curve on the screen)
I still remember my old HP DSO which was nothing compared to the Rigol and I was able to measure and display what I wanted to.
What do I have to do to get a nearly clear curve on screen?
I can't see an ECG curve on the Rigol because it refreshes so slowly :/
1) As others suggested, use roll mode. This is what I usually do for my slow measurements (and I've had it all the way to 1000s/div!) Hires is really good in roll mode.
2) Set the trigger point to exactly the left side of the screen.
In normal y-t mode, the scope needs to have captured enough data to fill in from the beginning of the waveform to the trigger before it can actually trigger. So if your trigger is in the center of the screen, and you're at 100ms/div, then the scope needs to have 700ms of data before it can arm the trigger. By moving the trigger point to the left of the screen, the trigger can arm "immediately" after the previous waveform is captured. When the time base is slow enough, the scope will even display the in-progress waveform, making it feel a lot more responsive.
I know this might be a bit off topic, since we're discussing the 2000 series scopes,
Has anyone noticed any vertical amplifier offset (no signal applied with 50 ohm termination on input AC or DC coupling selected) in the range of 100 - 200 uV when in the 500uV / div range. I also noticed that channel 1 has a bit more than channel 2. My particular model is a DS2202, are we splitting hairs with a Chinese scope playing in the grass?
In the attached screenshot, I have my trigger position set to screen left as you suggest - but it would still take 7 seconds before the buffer is filled (and I would start to see the trace). So you have to keep an eye on the location of your trigger position within the current sample memory depth - not just the screen memory.Good catch. To get the effect I was after, that means also choosing a memory depth so that the waveform is the entire screen. That's what I get for giving usage advice away from my unit! As another usability caution, you can actually set the trigger position to be far to the left of the waveform. You want the "T" chevron to still be pointed down, not to the left.
I think I may have found a bug. Since upgrading to 3.00.01.03, whenever I plug in the scope, it automatically powers up. Before it just used to fade the power button. The power mode in the settings is Default, not Open. I did try both. Going back to V2 did not fix the issue. When I turn the scope off and unplug it it takes a few seconds for the power led to completely turn off. If I then plug the unit in, it boots up on its own.I am pretty sure the newest firmware does not change the scope back to regular power on mode if it is changed to "open" mode. Has anyone tried this? Is there some way to report this to Rigol. The official 3.00 version doesn't have this setting so I am hesitate of simply writing to Rigol NA support.
I went back to FW 00.01.00.05 and main power connect still starts my DS2072
I use SCPI command to get to LAST
I went back to FW 00.01.00.05 and main power connect still starts my DS2072
I use SCPI command to get to LAST
That setting controls the setup information at startup; that's not what I'm talking about. In 3.01 there is a new setting called PowerStatus (you can see if if you scroll to the next page) The options are Open or Default. According the newest DS2000 manual on the Rigol website, Open mode powers up the scope when you plug it in, and Default just "energizes" the unit and you have to press the power button to power on the scope. I am stuck in Open mode after testing that setting and cannot get back to Default. I can change the setting and it appears to save the value, but the scope still powers up by itself.
We just had a power failure last night and the scope was on this morning because of this. I'll have to keep it unplugged to prevent it running if power is lost :(
That setting controls the setup information at startup; that's not what I'm talking about. In 3.01 there is a new setting called PowerStatus (you can see if if you scroll to the next page) The options are Open or Default. According the newest DS2000 manual on the Rigol website, Open mode powers up the scope when you plug it in, and Default just "energizes" the unit and you have to press the power button to power on the scope. I am stuck in Open mode after testing that setting and cannot get back to Default. I can change the setting and it appears to save the value, but the scope still powers up by itself.
We just had a power failure last night and the scope was on this morning because of this. I'll have to keep it unplugged to prevent it running if power is lost :(
Have you tried to reset stored settings (you know, left function keys column, F6 button while powering up).
Cheers.
Have you tried to reset stored settings (you know, left function keys column, F6 button while powering up).
Cheers.
Yep, I tried to reset using F6. That was actually my first attempt at a fix. I also tried to load the default values through the menu.
Also, Power On "last" and "Default" works as it's supposed to, but neither solves the automatic boot-up issue.
Are there any others who are having this same problem?
Yep, I tried to reset using F6. That was actually my first attempt at a fix. I also tried to load the default values through the menu.
Are you absolutely positive that you cleared the FRAM correctly with F6 during bootup? In other words, ALL of your settings (channels settings, image settings, etc) were gone? If not - make sure you're certain before going further - for example, set something specifically, then clear the FRAM at bootup.
There is also 'Security Clear'- it will clear both the FRAM and NOR FLASH - which contains 'Firmware, Bin, Internal saving' (according to Rigol doc). The problem is, I don't know if it clears the bootloader or other vital data (calibration settings, model and serial number, etc) - but I suspect it might - which could leave you with a bricked DSO. So I strongly advise you should check with a Rigol representative/dealer before attempting it. If you're still sure you want to try it - I can post or PM you the method.
The security clear sounds promising... and dangerous. I'm not sure I really want to risk a brick over this. I'm assuming that it is not just my unit doing this, so Rigol should fix it in a future firmware, hopefully.
Speaking of which - where is the best/cheapest place to buy Rigol scopes? I'm in the market for a 2072 as well.If you are in the US and maybe they supply to other countries (not sure), I'll recommend tequipment.net
The security clear sounds promising... and dangerous. I'm not sure I really want to risk a brick over this. I'm assuming that it is not just my unit doing this, so Rigol should fix it in a future firmware, hopefully.
Well, contact the person/company you bought your DSO from, tell them your problem, and ask them if using Security Clear might work for you.
I did the Security Clear, and still no change. I'm starting to think there may be something wrong with my scope. I'd love to hear if anyone else experiences the same behavior.
Also, if there are any smart hackers out there that can figure out how to change the setting back, I would greatly appreciate it.
Cheers.
I went back to FW 00.01.00.05 and main power connect still starts my DS2072
I use SCPI command to get to LAST
I did the Security Clear, and still no change. I'm starting to think there may be something wrong with my scope. I'd love to hear if anyone else experiences the same behavior.
Yeah, it's not a big deal, I agree, but along with not being able to unlock 300MHz, I'm just wondering if there is a hardware issue with my scope. Anyway, I'll drop it now ;)
There's probably a SCPI command for it - and if so, that might work. But even though Rigol has released a new user's manual for the newest v.3 firmware - there's still no new programming guide (as far as I can tell). You could try the following guesses from Ultra Sigma, since sending incorrect commands doesn't cause any harm - and the DSO will display on the screen whether it's accepted the command or not.
The :SYSTem:PON command is to set 'power on', so I'm guessing that POS or PST might be 'power status'. Try:
:SYSTem:POS DEF
and
:SYSTem:PST DEF
:SYSTem:PST DEF is correct, but it still does not change the behavior. I'll contact Rigol and if nothing comes of it, I'll just live with it. Now if we could just figure out what's going on with the 300MHz randomness.
I've been using my DS2000 heavily the last few weeks, and about a week and a half ago it just started to hang constantly - requiring reboot after reboot (some combination of settings - I think I was using Roll mode). It got so bad, I was starting to think that I'd had some kind of failure - but first I downgraded to FW v.2 and uninstalled 300MHz, and since then, it's been absolutely fine - not a single crash. I still haven't re-installed v.3 again to check if it was specifically that or the 300MHz option causing the problem, but I can certainly report that FW v.3 with the 300MHz option installed is definitely NOT stable.
But even though Rigol has released a new user's manual for the newest v.3 firmware - there's still no new programming guide (as far as I can tell).
Hi All,
In the past when I would insert a USB stick with a DS2000 '.GEL' file the DSO would display the version number and prompt "OK" to install ,but now It will only prompt if it is a new FW version. see Pix.
Has anyone else seen this?
When I go back to older version (boot/help), I do not get the update prompt just the 'USB device detected'.
Also
Has anyone ever seen all:
100M
200M
300M Bandwidth options displayed like in Pix
marmad:
I would appreciate hearing more from you on the issues you had. Have you learned anything else since your experiences with the DS2000, FR v.3, and the 300MHz BW Option?
Thank you for any information you can add since your post in Reply 2524, Ted552
If you install the 300MHz option on a DS2000, your scope's rise-time is indeed lowered, however you also gain a fair amount of overshoot on pulses. The overshoot measured with a TEK 284 (70 pico sec. step) was in the order of 15%. So I decided that this is not acceptable for me, and turned it off.
marmad:
I would appreciate hearing more from you on the issues you had. Have you learned anything else since your experiences with the DS2000, FR v.3, and the 300MHz BW Option?
Thank you for any information you can add since your post in Reply 2524, Ted552
[Additional]:
Now, in terms of the continual hanging problem - I haven't seen it happen again since I removed the 300MHz option and downgraded to v.2 - then upgraded back to v.3 later after my work was done. But I was working with Roll mode and some rather atypical settings - so it's possible that the same settings with v.3 but without 300MHz would also cause the hanging - I just haven't been able to reproduce it since. So at this point, it's unknown if it's just a bug that exists in v.3 with certain settings - or is linked to 300MHz option being installed. But I have to say, before I ever began using the 300MHz option, the DS2000 crashed or hung fairly infrequently - but it's happened many more times with it installed. But more info is definitely needed to pinpoint the source of this problem.
Not in this case; the Tek 284 has no overshoot and a rise time of 70 ps.If you install the 300MHz option on a DS2000, your scope's rise-time is indeed lowered, however you also gain a fair amount of overshoot on pulses. The overshoot measured with a TEK 284 (70 pico sec. step) was in the order of 15%. So I decided that this is not acceptable for me, and turned it off.
this 15% more overshoot is from the 200MHz set DS2000, but until you know what the rise signal should look like ( measured on a much higher bandwidth scope ) then maybe seeing an overshoot increase is actually right ? the lower bandwidth just wouldn't have the ability to capture it ?
this 15% more overshoot is from the 200MHz set DS2000, but until you know what the rise signal should look like ( measured on a much higher bandwidth scope ) then maybe seeing an overshoot increase is actually right ? the lower bandwidth just wouldn't have the ability to capture it ?Not in this case; the Tek 284 has no overshoot and a rise time of 70 ps.
"Which is Better??? ":-//
"Which is Better??? ":-//
As you can see by the flat traces that I manually created the data for the waveforms and re-loaded the sample data into the DSO and the DSO created the Traces, always with SinX/X interpolation.
1. In the first display the sample data is at one level and then jumps to the Higher level in one sample period (500ns).
NOTE how the SinX/X interpolation displays a pre and post step ringing.
To explain in more detail. I saved a waveform file from the DS2000 (at 140pts/disp)) to a USB Stick.
I then transfered this file to a PC. I then used a Hex Editor to put in the Sample data into the files that I wanted the DSO to Display. , There is NO real voltages measurement Data.
I set the first 70 data samples for 1 div above the bottom of the display
then
I set next 70 data samples for 1 div below the top of the display.
I then loaded the waveform file into the DSO (w/USB)
The ringing you see is the result of the DSO trying to make a sine wave with the SinX/X interpolation function.
2. In the second display the step change of level was created for a smoothly change to resrtiction the SinX/X effect.
See the Dot Samples in this Display.
You can see the Dots are a gradual curve at the bottom and top of the Step change in the Sample Data.
I think a lot of the overshoot when displaying a step change is the SinX/X function. A user has to look at where the sample dots are to determine if there was a real indication of overshoot.
The #1 display shows a 10% overshoot when there was absolutely Zero overshoot !
As for the Front end BW of the DS2000 we know that there is a Programmable BW Amplifier that has the selections of 20,100,200,350,650 and 750 MHz so I assume 300MHZ option opens up the BW to 350MHz
Well that's a good question. I would assume that Rigol has adapted the front-end of the new DS2000A to compensate for the excessive overshoot with the 300MHz model. But I don't know for sure, I don't own one.This is NOT due to Sin X/ X interpolation. Besides that, the sin interpolation is only done between sample points.....
The first picture in this post was done running the scope bandwidth at 200MHz. you can already see how much overshoot it has. Test done at 300MHz show even more overshoot. NOT due to sin interpolation.
.......
So as far I'm concerned this myth has been busted for the DS2000 series :)
Thanks Orange.
I think you tested on the DS2072 Non-A , with older Firmware
My displays indicate nothing about the Analog specifications of the DSO.
Yes the vector display follows thorough the sample points and (SinX/X is used between data points)
I may have missed the post, is there any difference in the front end of the DS2000A to improve the spec.? (higher BW) Although the latest FW allows the option for DS2302 (300MHz), was there any changes to the frontend in the DS2000A hardware for a faster response (with what overshoot??)
Besides Rigol sales , I doubt anyone has both DS2000 and DS2000A to do a test with same pulse.
and with only a few sample points/div I think it would be hard to determine any difference when testing at the limits of the DSO specifications.
Just thinking,why I like 1ns/div? I am old :( and slow to multiple by 2, for 2ns/div ;D
Well that's a good question. I would assume that Rigol has adapted the front-end of the new DS2000A to compensate for the excessive overshoot with the 300MHz model. But I don't know for sure, I don't own one.
@ Othello
You may wish to check the full firmware Version (see 3rd post here for - F7 F6 F7 Util)
if you are at 00.00.01.00.05 then Yes update FW
See bug list ( post #3). you can always go back.
On a lighter side
A Rigol tames a wild One yes wild
@Teneyes: I am guessing you live in the toronto area.
And about a kilometer higher in elevation too. Lovely place, wondering if we have time to visit next month.@Teneyes: I am guessing you live in the toronto area.
I think he's about 4000km west of Toronto.
On a lighter side
A Rigol tames a wild One yes wild
Video comparison of the Rigol DS2000 and the new Siglent SDS2000 series here:It would be interested to see if the fuzzy traces with 2 channel at fast scan rates shows on the Siglent like the latest DS2000 FW. With and without SinX/X?.
It would be interested to see if the fuzzy traces with 2 channel at fast scan rates shows on the Siglent like the latest DS2000 FW. With and without SinX/X?.
On the Rigol it seems to me to be related to SinX/X and intensity levels. That have changed on latest Rigol firmware releases.
Could this be SinX/X extrapolation??
It would nice to be able to turn off SinX/X .
Fuzzy Traces
It looks like Min. Presistence is set to an incorrect value!!!
and is about 200ms
to Clarify , the setup is :Could this be SinX/X extrapolation??I can't replicate this particular error on my Rigol, so I'm not sure what is causing it.
It would nice to be able to turn off SinX/X .
70 MHz input
It has to be a 70MHz input @5ns/div? That seems like a pretty specific bug ;DWell ;D, It shows on the peaks of 30-120 Mhz, and more at 5ns/div.
Here are Gifs. , of Vectors and Dots Recording with 50MHz input ON FW00.01
Note how the dots are follow on the sin curve but in VECTORS there is less ripple
Note how the dots are follow on the sin curve but in VECTORS ther is a rolling ripple of 1 GHz !!
The new Rigol 2014 DS2000 Performance Verification Guide:
http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-04ce/1/-/-/-/-/DS2000%20Performance%20Verification%20Guide.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-04ce/1/-/-/-/-/DS2000%20Performance%20Verification%20Guide.pdf)
The new Rigol 2014 DS2000 Performance Verification Guide:
http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-04ce/1/-/-/-/-/DS2000%20Performance%20Verification%20Guide.pdf (http://beyondmeasure.rigoltech.com/acton/attachment/1579/f-04ce/1/-/-/-/-/DS2000%20Performance%20Verification%20Guide.pdf)
My DS2072, did a single shot trace this morning at 2 sec/div. Waited till it said "WAIT" (confusing, means scope is waiting for trigger, not for you to wait...) then switched my cct on and this caused a trigger because it said "TRG" or suchlike, can't remember now, then eventually after maybe 20 seconds or so it said "STOP" in red. After about five minutes there was still nothing displaying on the screen so I moved the time/div kob back and forth one click and BYU there was my trace! Interestingly, it didn't start right on the trigger point but about 2.5mm to the right.
This display not showing up immediately only seems to happen at slower sweep speeds; high speed ones appear as soon as the scan is finished. Not sure what the borderline between high and low speed is yet though. Just that at 2 sec/div it acted up. Any ideas?
BTW, posting USB screen captures when you have problems would help us point out what mistake you're making.@Circlotron
Okay, the image names should tell the story.
Anyway, I tested your setup (High Res mode @ 2s/div w/14k) but it works fine on my DS2000 - the trace appears on the display as soon as it's triggered just like it's supposed to. Perhaps it has to do with my test signal, but since you're running an older version of the firmware (I'm using v.3 FW), it might also be related to that too.I forget my firmware version but I've had the scope exactly 12 months this week. Only had Riglol hack entered via the menu.
I forget my firmware version but I've had the scope exactly 12 months this week. Only had Riglol hack entered via the menu.
Did another test and in Hi Res mode is displays immediately on trigger down to IIRC 100mS/div. Slower than that and you can wait forever and still nothing
As already mentioned, High Res is, at best, marginally useful at those time bases, causing the BW of the DSO to be reduced to below 250 Hertz.I have used high res and slow time bases to watch thermistors and the like, but I'm usually doing that stuff in roll mode. I don't suppose Roll mode would work for you, Circlotron? If not, remember you can turn on high res after the capture is complete when in Y-T mode.
remember you can turn on high res after the capture is complete when in Y-T mode.I only just the other day discovered that. Game changer. ^-^
Is the FW#00.03.00.01.03 stable and solid? Better than the 00.02.01.00.03? Any tricks to upgrading? I've got two non-A DS2072's.
Is the FW#00.03.00.01.03 stable and solid? Better than the 00.02.01.00.03? Any tricks to upgrading? I've got two non-A DS2072's.
Anyone? I know you guys are on top of this!
UltraPower Analyzer software
Hello, did anybody met this SW in free access?
http://www.rigolna.com/products/accessories/ultrapower-analyzer/ (http://www.rigolna.com/products/accessories/ultrapower-analyzer/)
http://www.edn.com/electronics-products/electronic-product-reviews/other/4430108/Software-turns-oscilloscopes-into-power-analyzers (http://www.edn.com/electronics-products/electronic-product-reviews/other/4430108/Software-turns-oscilloscopes-into-power-analyzers)
Nice but unfortunately far from free.
Nice but unfortunately far from free.
I think he's asking if anyone has managed to locate a copy of it somewhere for free.
See seronday's Post where he found a Option for the DS4000 using Ultra Power Analyzer, so there will be/or is one for the DS2000 also: https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg523679/#msg523679 (https://www.eevblog.com/forum/testgear/sniffing-the-rigol%27s-internal-i2c-bus/msg523679/#msg523679)I played around with the spare bits on the DS2000 for a few minutes (DSBA, DSJA, DSSA), but couldn't get it to enable the PA option - either from SCPI or from the software itself. I'm using the very latest FW (3.1.0.4), so perhaps it makes a difference to downgrade first (no time to test it at the moment).
I played around with the spare bits on the DS2000 for a few minutes (DSBA, DSJA, DSSA), but couldn't get it to enable the PA option - either from SCPI or from the software itself.
First of all, you need proper private key, like this one: 0x1C5E1F52C1E3A8
And I believe that you don't enable PA option in the scope, but in the PA itself.
First of all, you need proper private key, like this one: 0x1C5E1F52C1E3A8
And I believe that you don't enable PA option in the scope, but in the PA itself.
Foe non-A models? Because it's enabled in the PA itself?
The software comes with a 15 day trial period, after that you have to enter a registration code in the software, not the oscilloscope, to continue using it. Purchase of a registration code requires the oscilloscope serial number so it might be generated in a similar way to the option codes, but unlikely to be closely related.
I believe that the power analyzer option found by seronday is a not-yet-implemented firmware feature.
There is new firmware for the MSO/DS2000(A-S) series that has apparently been out for a few weeks (although I was unaware of it): #00.03.01.00.04.
(https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/?action=dlattach;attach=111462)
I haven't had any time to test old bugs - or look for new ones (or new features) - and I'm swamped with other things at the moment. Perhaps someone else can test whether, when using the Decode bus with frames in Analyze mode, the Decode bus still sticks on the first packet of data (as demonstrated in this portion of my Mask video (https://www.youtube.com/watch?v=Id8dpWSvmAs&t=17m31s))? I recently reported that bug to Drieg and if it still exists in this FW version, he will report it to Rigol very soon.
The firmware is available in the usual place: post 3 of this thread (https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684).
I was using the serial decoding (rs232) yesterday and I'm happy to report that the new firmware doesn't seem to suffer from this problem anymore.
Yes!
There was a noticeable lag (maybe a second or so), but as I was moving between frames in analyze mode the decoding was eventually getting updated. :-)
Yes!
There was a noticeable lag (maybe a second or so), but as I was moving between frames in analyze mode the decoding was eventually getting updated. :-)
I can confirm that it also works with the CAN analyzer (DS2000A).Yes!
There was a noticeable lag (maybe a second or so), but as I was moving between frames in analyze mode the decoding was eventually getting updated. :-)
Great! Good to hear it - and thanks for posting the info (plus welcome to the forum :)).
Besides decode in analyze mode, have you discovered any new fixes/feature enhancements with the new firmware?To be honest: Due to lack of time I did not look deeply into all menus and submenus. I did not discover anything new by "just" working with the usual functions.
I took a look at the waveform update rates and here are my results. I used only 70kHz Sinwave to test because I don't have a SigGen... Sorry!
My DS1074 does not exhibit this behavior. So I switch to that instrument when looking hires at low-frequency stuff...
Yes I realize(d) the difference between the scopes. But it does not explain (at least not to me) why the wave intensity of the (signal) trace on the DS2072 drops of instantly and dramatically when the timebase is > 100 ms/div - becoming almost invisible.
Except, as I've already posted extensively about, the DS1000Z does NOT do correct 12-bit High Res at all. So you're basically just looking at a brighter waveform that is barely (if at all) being averaged. I just checked Roll mode on both scopes (@ 200ms/div), and the DS1000Z is definitely not averaging to 12-bits (i.e. no High Res) - while the DS2000 does it perfectly.
Yes I realize(d) the difference between the scopes.
But it does not explain (at least not to me) why the wave intensity of the (signal) trace on the DS2072 drops of instantly and dramatically when the timebase is > 100 ms/div - becoming almost invisible.
But then running the DS1000Z in High Res/Roll is almost equivalent to DS2000 Normal/Roll, so why bother swapping scopes? ;)Well I wanted to look at a low frequency signal with a lot of noise on top - including scope noise as I was at nearly maximum sensitivity. Hires gets rid of a lot of the noise. But then this signal becomes nearly invisible on the 2000.
I believe the dimness of the waveform in High Res mode at slower timebases comes from the interaction between the successive sample averaging and the decimation for the intensity buffer. I think that it's actually performing correctly - in terms of the intensity mathematics (every 256 successive samples are being reduced to 1) - but it's the kind of thing that, even though technically correct, does not lead to a good visual result. It would require a workaround exception in the code to bypass (or correct) the problem.Hmm but why the sudden change @ 100 ms/div. I would expect a more gradual dimming.
Hmm but why the sudden change @ 100 ms/div. I would expect a more gradual dimming.
The acquisition/display engine is working differently at the slower timebases. You can see that when you're at <=100ms/div, the entire waveform is captured before being displayed (i.e. all decimation is done), but when at >=200ms/div, it is displaying the waveform AS it's being captured (i.e. decimation done on the fly - thus not being affected by subsequent captures).Aha! Now it makes sense. From 100 -> 200 ms/div the display indeed changes from complete capture -> display to displaying "live" while capturing.
The Rigol's do intensity grading based on BOTH vertical and horizontal overlapping from sample to display memory. When displaying on the fly (anytime you're running at >=200ms/div), the overlapping (and thus, grading) will be different since it won't know beforehand the upcoming samples. This is true on the DS1000Z too, but because it's not really doing 12-bit averaging, you don't see the intensity difference caused by the missing (averaged) samples when displaying on the fly.
Aha! Now it makes sense. From 100 -> 200 ms/div the display indeed changes from complete capture -> display to displaying "live" while capturing.
Thanks, this helped me a lot. (Still would like Rigol to do something about it, but it is probably not on top of a list)
Try this: do a Single capture of a sine wave in High Res mode @ >=200ms/div with Intensity at 50%. You'll see the typical very dim waveform when the capture is done. Then just lightly turn (I don't mean PUSH - just very slightly rotate) the multifunction knob, and the intensity will snap back to an 'average' setting.Yes, I already noticed that (by twiddling the vertical position knob, even while capturing). That was (then) one of the reasons why I suspected a bug....
Yes, I already noticed that (by twiddling the vertical position knob, even while capturing). That was (then) one of the reasons why I suspected a bug....
Ok so if the displayed trace(brightness) reflects the actual density/intensity of the original signal at that level, then increasing the amount of noise on the input should result in an even dimmer average trace (as the signal density per tracewidth would become smaller). Might try that later...
No, I think that Rigol's thinking is that the dimness is actually the mathematically correct intensity after averaging (as mentioned above) - so it's giving you the 'truest' image of the averaged + decimated samples. But once the DSO is stopped, the 'true' image of the incoming and processed samples is not as important as normal brightness.
At least, I can imagine that some engineer might have thought this way ;D
Ok so if the displayed trace(brightness) reflects the actual density/intensity of the original signal at that level, then increasing the amount of noise on the input should result in an even dimmer average trace (as the signal density per tracewidth would become smaller). Might try that later...
No, the amount of noise won't make a difference: in High Res mode, it's already displaying the lowest intensity level possible.Yup confirmed. But if the algorithm is so simple what would be the problem (for Rigol) to just upshift the intensity to get better visibility? If I understand you correctly there already is only one (1) intensity level in this mode, so no intensity information will be lost :-//
<snip>
You can prove this by turning the intensity level to 0%, then running the DSO in High Res mode. It will always be a perfectly black trace.
Yup confirmed. But if the algorithm is so simple what would be the problem (for Rigol) to just upshift the intensity to get better visibility? If I understand you correctly there already is only one (1) intensity level in this mode, so no intensity information will be lost :-//
Since there is only one level at >=200ms/div High Res, you might as well set intensity to 100%. Do you still find it too dark if you do that?I'd like it a bit brighter, but I suppose it will do :)
There is a new issue with 'Rigol DS1000Z & DS2000 Oscilloscope Jitter' related to the Trigger mode/method. See -> https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964 (https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964) This is already up to 12 pages in only two days. I'm posting this alert here because I didn't see Rigol O'Scope experts here such as 'marmad', 'teneyes', etc there that could be valuable contributors to understanding the issue. And further we should all at least be advised that this issue is being discussed. I also believe that some DS4000 users are experiencing the trigger jitter issue (with the AC trigger mode).Thanks for the heads up. As I noted over in that thread, we've been talking about problems with AC-coupling the trigger for over 2 years now in this thread (check out the bug list or search the thread). Few of us original owners use that setting because of these problems - and I've never found a single instance in my use of the DSO in that time where I needed it. The other jitter being discussed is not present on the DS2000.
Thank you 'marmad':There is a new issue with 'Rigol DS1000Z & DS2000 Oscilloscope Jitter' related to the Trigger mode/method. See -> https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964 (https://www.eevblog.com/forum/blog/eevblog-683-rigol-ds1000z-ds2000-oscilloscope-jitter-problems/msg550964/#msg550964) This is already up to 12 pages in only two days. I'm posting this alert here because I didn't see Rigol O'Scope experts here such as 'marmad', 'teneyes', etc there that could be valuable contributors to understanding the issue. And further we should all at least be advised that this issue is being discussed. I also believe that some DS4000 users are experiencing the trigger jitter issue (with the AC trigger mode).Thanks for the heads up. As I noted over in that thread, we've been talking about problems with AC-coupling the trigger for over 2 years now in this thread (check out the bug list or search the thread). Few of us original owners use that setting because of these problems - and I've never found a single instance in my use of the DSO in that time where I needed it. The other jitter being discussed is not present on the DS2000.
I upgraded the ds1104z to version 00.04.01.SP2 (board version 0.1.1).
Triggering ac nothing has changed.
I find problems, attaching two pictures ... this's not normal!!!
You can use the Delay Trigger type (which takes two input sources) to get a stable image of two waveforms with unrelated and different frequencies.
I've got a question: how good is the math function of the DS2xxx?@Nikwing
I try to measure current, voltage and multiply both to see the power
on all 3 DSOs all channels and math are set to RMS.
But only the Rigol shows a 10-20W different calculated value
the math also changes with V/div resolution on the Rigol, that doesn't happen on the other 2 DSOs
The Yokogawa and Philips both show around 550WYokogawa 131 x 4.36 = 571.16
Looks like I can't set something like RMS(CH1) * RMS(CH2) in advanced math.
is it normal that my Rigol measures a higher value than my other DSOs? and is there a way to calibrate it to show the correct value instead of using corrections in math?I am not sure.
if I may ask that: saving s png screenshot with header, footer and (I currently don't remember the word) the text file enabled doesn't work here. the png looks the same all the time and no txt file is being created. Is that a bug?For screen captures I use Marmad's RUU utility ,Get it Here (https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/msg171575/#msg171575) . For quick and easy reports with 3-D and animated Gif
is it normal that my Rigol measures a higher value than my other DSOs? and is there a way to calibrate it to show the correct value instead of using corrections in math?I am not sure.
Have you preformed the Rigol 'Selfcal" recently
and I push the stop button, I see multiple lines on screen until I change the time base (and back to where it was)
is that a bug?
and I add another question about triggering:
I've attached a random picture. Usually I would trigger at A
is it possible to trigger at B although there's a higher peak in the signal? Is it possible to tell the scope to always trigger at a desirered point on the curve?
Would I set the trigger level to let's say B and then use delay/offset or nth recurrence, or is there another way?
And, would it be possible to analyze just the part I marked with C, as in pretending that this is the real signal (which kinda "repeats" between B and A)?
I don't know how to phrase that D:
I have found a bug related to switching between roll and YT mode in the newest firmware. Here is the description:NOT a Bug, but you found the Limits of the Specifications
the 1st two displays show no error at 18mv, Roll to YT ( noise)
As you can see there is No error in the Scale
Now read the Specification in next Pix
because you are using 10x your input is 1.8mV, which is below Spec.
Pix 5 & 6 confirm your displays with 10X
( I think I saw this and reported it to Rigol as the DSO is still triggering , but they responded that the input is out of Spec)
I hope that Helps
Teneyes: This also looks like a Bug to me. Please, why would Trigger level effect the vertical display/measurement when switching from 'ROLL' to 'Y-T' Mode?
I find the very osbcure small bug of 1/2 scaling occursUpdate More conditions
Teneyes: This also looks like a Bug to me. Please, why would Trigger level effect the vertical display/measurement when switching from 'ROLL' to 'Y-T' Mode?
CORRECTION , Yes a rare bug
Thanks Ted, I removed any Trigger level causes by using External Trigger (5 V sync pulse)
Also set the input Scaling to 1x
Used a 2 cycle burst to set roll and trigger time
I find the bug of 1/2 scaling occurs for this Setup
1. Lowest V/Div scale (500uV/div @ 1X, 5mV/div @ 10X..... )
2. After Switching from Roll to Y-T
The scale is corrected after:
1 The scale is clicked lower (still the Same 500uV/div)
2 The vertical position is changed
3. The vertical position is Zeroed
4. The trigger position is Changed or Zeroed
5. Chan 2 ( even Off) position is Zeroed
I hope that would help Rigol narrow the code that needs to be called when switching to Y-T mode
The 3 Displays with 3.6mV,
Roll mode
Y-T mode
Y-T mode after a knob click
Edit: I have reported this to Rigol , anyone with D2000A , wish to confirm This bug
Edit: Occurs when Chan 1 only is on
Frequency counter?Yes a Limit to the Maximum Frequency that can be Counted!
(Latest jitter fix firmware. Im not sure if it behaved the same way with the "older")
Thank you for the link, but that is a DS2072A scope. I know that Rigol added CAN decoding and 50 ohm termination to the A model, but the question is whether CAN decoder can be enabled on non-A models with current firmware (03.03.01).
korlatos: is the CAN decoder can be enabled on non-A models with current firmware (03.03.01).Yes it can!@EV , Do you have the Rigol CAN test PCB?
Here is My DS2072 test with FW 00.03.03.01.00,,
I did have problems with trigger setup at 1st but finally it worked ?????
If you have a Rigol DG4000 and wish to play with CAN decoding , I have Attached two ".RAF" files one can load into the DG4000.
Known Firmware Bugs/IssuesJust cleaning up old bug report
22) All SCPI commands related to CAN triggering appear to be missing in the latest FW.
[FW v.02.01.00.03 / FW v.03.00.01.03
Known Firmware Bugs/IssuesAs most of EEVBLOGers know, that after Dave Jones (#683) got on Rigol's case about AC-triggering , the Bugs were Fixed :D
17) There is a visible offset from center position when using AC-coupled Triggers (including filtered LF and HF) at lower time bases (<= 2us/div), as well as serious jitter with certain settings.
[FW v.01.01.00.02 / FW v.02.01.00.03 / FW v.03.00.01.03]
My scope is still at 00.02.01.00.03, and I added the hack to get some of the options (the scope is bought as 200mzh so I only added the other options), will I loose these if I upgrade to 00.03.03.01.00 now?
The release notes contained an long list of bugfixes so I guess an update is in order now.
Can this firmware be loaded somewhere?Yes, you can load it on your DS2000/DS2000A. Hi Hi
Any guinea pig installed it and confirmed if any installed options are affected?All installed options fine here [emoji1]
I installed the new firmware.The installation instructions "Step 9. Special Note for DS2000/DS2000A users:" covers this kind of thing. In fact you should routinly perform this solution after updating the Firmware in the DS2000/A to clear FRAM. This has been often mentioned here in the past.
On first boot, browsing the Utility menu with the down arrow caused the entire screen to "bounce" up vertically about 50 pixels, and then back down. It did this twice.
Options still active.
Note: When you look at System Info you should see Firmware '00.03.03 SP2'. For the Full Version Info you should see Firmware '00.03.03.02.06'.Reminder: To get the full firmware version info from the DS2000, follow these instructions:
I installed the new firmware.The installation instructions "Step 9. Special Note for DS2000/DS2000A users:" covers this kind of thing. In fact you should routinly perform this solution after updating the Firmware in the DS2000/A to clear FRAM. This has been often mentioned here in the past.
On first boot, browsing the Utility menu with the down arrow caused the entire screen to "bounce" up vertically about 50 pixels, and then back down. It did this twice.
Options still active.
I didn't mention that I successfully installed this Firmware update yesterday without issue, because I thought that it would be understood after my describing how to get the update and what it does.
Edit follows below:
Recommendation: After FW update -> 1) ''Clear FRAM (by pressing 6th grey button on left side in & out repeatedly during Reboot)*, 2) Restore DEFAULTS*, 3) Perform 'Self-Cal'. *Ref. Step 9.
Note: When you look at System Info you should see Firmware '00.03.03 SP2'. For the Full Version Info you should see Firmware '00.03.03.02.06'.
hey dadler? was it just a one time glitch? Is everything fine now? I am considering an upgrade as well.
00.03.03.02.06 HighRes on > 1ms qause long freezesits also freezes in dot mode.
with only 1 ch in use.
lr1234, arny or EV ; Did anybody roll back to previous FW version??
HighRes on > 1ms qause long freezes
with only 1 ch in use.
its also freezes in dot mode.
Default settings,test signal on ch1
Memory auto
Only 1Ch enabled (for 2Gs/s)
If HighRes or Dot Mode changing time base lover as 500us cause freeze.
2Gs/s memory arithmetic’s with bugs.
Temporary help- enabling second channel(2Gs/s/2)
I have reported the bug to Rigol Germany and in turn have these passed on to the R & D, as they were able to understand him. I have to say - that's really straightforward good. Another point of what I like about Rigol. Bearing in mind this can fault occur, the complexity of this instrument before. It is important to specify that the manufacturer this error takes to the chest. I know the other way.
I had been able to start producing this error without HighRes. The repeat of the flash process the same firmware completed the mistake, however - at least I no longer have to readjust him. With HighRes he can, however, very good and reliable reproduce.
What could have changed in this procedure, I can not judge.
My DS2202 is already a "Big Bang for a Buck" and in terms of price do you get a lot of power on offer. For an R & S HAMEG you really have to pay a lot more. The I2C Decoder option I bought it and was not disappointed. Unfortunately, the option CAN Decode is not available for my device - only for the "A" version. That's what I would have been interested. Currently, I'll solve it with a USB logic analyzer of this task also copes well.
Only the probes are in 1: 1 mode with 9MHz very narrow bandwidth. There are also native 1: 1 probes that create the 200Mhz or you just used a direct coaxial cable.
Well, let's see what the upcoming update for us keeps ready.
ILeider ist die Option CAN-Decode für mein Gerät nicht erhältlich - erst für die "A" Fassung.I have DS2000 Non -A and here is CAN
the option CAN Decode is not available for my device - only for the "A" version.
Load the option Key for CAN
Check what version of FW,
Ich habe DS2000 Non -A und hier ist CAN Laden Sie die Wahltaste für CAN Überprüfen Sie, welche Version von FW
Am I right in assuming that the first thing to go on these is the capacitors in the power supply?No, the caps are Ok
Are there any FW updates after ver 00.03.03.02.06?
I have downgraded back to ver 00.03.03.01 as I told some posts ago.
This page shows all of the current firmware versions:Thanks, so no new updates yet. The latest is that buggy one!
..
Was anyone successful in down grading from 03.03.02.06 to 03.03.01.00 firmware on a DS2000A?Just an update.
Now they're giving away all the advanced options (except bandwidth) on newly purchased scopes. To me, this removes all moral qualms about unlocking the bandwidth. Since memory and bandwidth are physically in the scope already it's not stealing to unlock them (few would think tearing the governor off of your car is stealing).. But getting the advanced decoding and triggers did seem like stealing, but now they're free!I never had any moral qualm as you call it. Companies don't have a moral, so why should I have this towards a company. To me its all in the game, RIGOL could have easily closed the loop hole, but they did not. In fact I suspect that RIGOL helped the guys that needed to unlock the scopes with hints and private keys, all too boost the sales. For example the DS1000Z license system was also suddenly unleashed with the help of an anonymous source. That's now almost 2 years ago.
Which leaves the question: are they doing this to get rid of stock so they can come out with a new model? If so, will they start dropping the upfront price too? Anyone heard any whispers?
To me its all in the game, RIGOL could have easily closed the loop hole, but they did not. In fact I suspect that RIGOL helped the guys that needed to unlock the scopes with hints and private keys, all too boost the sales. For example the DS1000Z license system was also suddenly unleashed with the help of an anonymous source. That's now almost 2 years ago.
I'm not sure when the DS2000 came outI think it was autumn 2012.
Bought mine in summer 2012, with S/N. 003xx, so I say spring time. FW 00.01.02, lots of bugs under the bridge.QuoteI'm not sure when the DS2000 came outI think it was autumn 2012.
Has anyone figured out how to downgrade firmware on the A series?
Another MSO2072A-S that experiencing issues with the latest 3.3.2.6 firmware.
The problem seems to be happening when only one channel is turned on and during changing the horizontal timebase (especially for slower timebase settings). The problem seems not to be happening when the Acquire->Anti-aliasing is off.
Has anyone figured out how to downgrade firmware on the A series?
The scope locks up . Details can be found if you go one page backAnother MSO2072A-S that experiencing issues with the latest 3.3.2.6 firmware.
The problem seems to be happening when only one channel is turned on and during changing the horizontal timebase (especially for slower timebase settings). The problem seems not to be happening when the Acquire->Anti-aliasing is off.
Has anyone figured out how to downgrade firmware on the A series?
What is the problem?
Does any of you own this bag, and what is your though about it?
So no one have an experience with the official Rigol bag for the DS2000? :(
Does any of you own this bag, and what is your though about it?So no one have an experience with the official Rigol bag for the DS2000? :(
I have uploaded some notes and comments on the Rigol BAG-G1 (https://www.eevblog.com/forum/testgear/dsomso-instrument-carry-case-rigol-vs-agilentkeysight/). Hope you find it helpful.
It looks like there is a new firmware version 3.4 SP1 available as its shown here: http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)
Hopefully, it solves the lock-ups introduced by 3.3 SP2
Anyone has access to it? :-)
It looks like there is a new firmware version 3.4 SP1 available as its shown here: http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm (http://beyondmeasure.rigoltech.com/acton/form/1579/0012:d-0001/1/index.htm)I did not install it yet, but you can find it here:
Hopefully, it solves the lock-ups introduced by 3.3 SP2
Anyone has access to it? :-)
I was just thinking, the battery for the RTC will eventually need replacing. Is this hard to do? I remember some early pc motherboards had the battery inside a clock module and it made life difficult. Hopefully it is just a CR2032 or similar, out in the open on the main board, and the scope doesn't lose any calibration data when the battery does quit.
Received an email from rigoltech.com email address today with a link to the new firmware and release notes for the DS2 Series. When I click the link for the release notes it downloads a file named "Release Notes DS2v3_3_2_6 6-17-15.pdf" which is the previous firmware and only contains the release notes for up to that revision. So no release notes for the new version. I downloaded the firmware linked in the email and get a zip file named DS2000Update.zip. When I unzip this file I get another zipped file named DS2000FWUpdate.zip. When I unzip this one it creates a directory/file named DS2000(DSP)Update_00.03.04.01.00/DS2000Update.GEL. At least it appears to contain the correct firmware, though not sure why its double zipped. I haven't bothered installing it yet because I haven't seen anyone else report that they have installed it and I am currently not having any problems with v00.03.03SP2.
Same here, received the same email with the "old" firmware.Received an email from rigoltech.com email address today with a link to the new firmware and release notes for the DS2 Series. When I click the link for the release notes it downloads a file named "Release Notes DS2v3_3_2_6 6-17-15.pdf" which is the previous firmware and only contains the release notes for up to that revision. So no release notes for the new version. I downloaded the firmware linked in the email and get a zip file named DS2000Update.zip. When I unzip this file I get another zipped file named DS2000FWUpdate.zip. When I unzip this one it creates a directory/file named DS2000(DSP)Update_00.03.04.01.00/DS2000Update.GEL. At least it appears to contain the correct firmware, though not sure why its double zipped. I haven't bothered installing it yet because I haven't seen anyone else report that they have installed it and I am currently not having any problems with v00.03.03SP2.
There firmware update system seems a little odd. Today, out of the blue, I got a firmware update email for the DP800 (DP832) power supply. I reviewed the release notes, and looked at the firmware, and if it's labeled correctly it's firmware version 00.01.14.00.03 released on 4/24/2015. Note sure why they decided to send that to me today. Of course, it's possible it's a different firmware, and the release notes weren't updated correctly. I didn't bother to compare the files, and quite frankly I'm not going to bother. Not looking to risk bricking my equipment without good reason.
I just received a 03.04.01.00 for my DS2000, haven't tried it yet.
http://rev.muxr.org/rigol/DS2000Update.zip (http://rev.muxr.org/rigol/DS2000Update.zip)
There are also release notes and upgrade procedure: http://rev.muxr.org/rigol/ (http://rev.muxr.org/rigol/)
Good to hear!I just received a 03.04.01.00 for my DS2000, haven't tried it yet.
http://rev.muxr.org/rigol/DS2000Update.zip (http://rev.muxr.org/rigol/DS2000Update.zip)
There are also release notes and upgrade procedure: http://rev.muxr.org/rigol/ (http://rev.muxr.org/rigol/)
I've just done a quick and dirt upgrade (+ FRAM, default settings, autocal). It looks like I can't lockup my scope anymore.
Cheers.
---
Daniel
Same here, received the same email with the "old" firmware.Received an email from rigoltech.com email address today with a link to the new firmware and release notes for the DS2 Series. When I click the link for the release notes it downloads a file named "Release Notes DS2v3_3_2_6 6-17-15.pdf" which is the previous firmware and only contains the release notes for up to that revision. So no release notes for the new version. I downloaded the firmware linked in the email and get a zip file named DS2000Update.zip. When I unzip this file I get another zipped file named DS2000FWUpdate.zip. When I unzip this one it creates a directory/file named DS2000(DSP)Update_00.03.04.01.00/DS2000Update.GEL. At least it appears to contain the correct firmware, though not sure why its double zipped. I haven't bothered installing it yet because I haven't seen anyone else report that they have installed it and I am currently not having any problems with v00.03.03SP2.
There firmware update system seems a little odd. Today, out of the blue, I got a firmware update email for the DP800 (DP832) power supply. I reviewed the release notes, and looked at the firmware, and if it's labeled correctly it's firmware version 00.01.14.00.03 released on 4/24/2015. Note sure why they decided to send that to me today. Of course, it's possible it's a different firmware, and the release notes weren't updated correctly. I didn't bother to compare the files, and quite frankly I'm not going to bother. Not looking to risk bricking my equipment without good reason.
EDIT: just done an md5sum of this one and the original 1.14 archives, they are identical.
Cheers.
---
Daniel
I just received a 03.04.01.00 for my DS2000, haven't tried it yet.
http://rev.muxr.org/rigol/DS2000Update.zip (http://rev.muxr.org/rigol/DS2000Update.zip)
Regarding that FW update...there's a way it can brick the scope.
https://www.eevblog.com/forum/testgear/ds2072a-full-300mhz-all-options-upgrade-plus-bricking-unbricking/ (https://www.eevblog.com/forum/testgear/ds2072a-full-300mhz-all-options-upgrade-plus-bricking-unbricking/)
As far as I know, not showing the trigger bar in trigger AC coupled is normal, as it would not mean anything.
Can't remember the vids, but Dave speak about that in one of his video.
For LFReject I don't know if this si normal, but as we remove the low frequency part it would make sense, as the DC component is "low frequency".
Here is the video:
I installed it witout problems to my DS2202. I don't know what is fixed!
with all options installed?
with all options installed?
Yes, I have official options exept one. All are still there.
Does DS2072A mount poor quality components on board (no brand capacitors and so on...) like the DS1054Z??http://www.eevblog.com/2012/09/26/eevblog-360-rigol-ds2000-oscilloscope-teardown/ (http://www.eevblog.com/2012/09/26/eevblog-360-rigol-ds2000-oscilloscope-teardown/)
Or does it have better components?
Rigol DS2000(A) Firmware 00.03.04.02.01 (15th Dec 2015) is now available on the http://int.rigol.com/Product/Index/3 (http://int.rigol.com/Product/Index/3) site.
Does anyone know what has changed/added/fixed in this latest release ? There doesn't seem to be a release note in the .rar !
I obtained the firmware from Rigol and I have loaded all missing versions onto my mirror at http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) . !Thanks K., seems like Rigol is letting the users alpha test :(
Hello,I don't remember having lockups with 00.03.03.SP1 (I did have frequent lockups with a version that came on my scope, forgot which version it was). I guess they may have introduced issues in SP2. Anyways I've been running 03.04.01.00 without lockups.
Ok, so I bought the DS2072A and I'm quite happy with it. It has firmware version 00.03.03.SP2 and I've managed to get it freeze two times already without even trying hard. I quess that was the problem of this version. Are those latter versions any better and do you recommend upgrading the version and if yes, what version is recommended?
As usual I have loaded all missing versions onto my mirror at http://gotroot.ca/rigol/ (http://gotroot.ca/rigol/) . Sorry for the hiatus!Thanks VE7XEN for all the versions of Firmware on your site.
just a quick question: are there any news about any new firmware versions? I run 00.03.01.00.04 but I read about a newer version here and I'm not sure about the actual stateSee the gotroot site in post above for 3 later versions of firmware.
After 3 years waitinf for a good update, i put my DS2202 in the oblivion room.
After 3 years waitinf for a good update, i put my DS2202 in the oblivion room.
Maybe luchog missed the latest update from 2015 but I have no idea what that update fixes. But if he really doesn't want to use the scope anymore he could axe it like that other guy did with his Owon scope and post a picture for our amusement >:D
There is new DS/MSO2000/A/-S Firmware available: 00.03.05.00.01 {July 25, 2016}.
And anybody that's amused by axes through test equipment really needs to get out in the real world a bit more.I feel the same way about people who smash really good name brand musical instruments on stage. 😡
It would be better to give the scope away to a fellow forum member from a poor country, similar like that great gentleman Dubbie did a few weeks ago with his fully spec:ed Rigol DS1104Z-S:Great idea (NOT!):
It seems noble to give away the sh*t you don't want anymore and think it will be usefull for the less fortunate but in the end of the day the less fortunate also need a proper tool just as he/she needs an iPhone and a PC capable of running Windows 10.
Why? Simple: read a few posts back and you'll notice someone disagrees with your opinion about how useful this scope is. Then people start whining about giving it away instead of putting it in storage until the end of time.It seems noble to give away the sh*t you don't want anymore and think it will be usefull for the less fortunate but in the end of the day the less fortunate also need a proper tool just as he/she needs an iPhone and a PC capable of running Windows 10.Why are you posting such idiotic crap in a thread about a DSO you've never owned, likely never used, and have no real experience with?
Why? Simple: read a few posts back and you'll notice someone disagrees with your opinion about how useful this scope is. Then people start whining about giving it away instead of putting it in storage until the end of time.
There is new DS/MSO2000/A/-S Firmware available: 00.03.05.00.01 {July 25, 2016}.
Edit: Request a download link for this from http://www.rigolna.com (http://www.rigolna.com) (Rigol U.S.A.), etc. You will find the new Firmware for the DS2K
series O'Scope here as of today.
There is new DS/MSO2000/A/-S Firmware available: 00.03.05.00.01 {July 25, 2016}.
Download link?
Sorry but you are starting to mix things here.
And who is going to watch a 75 minute video while the same information can be put into a short text you can read in under a minute?
It doesn't take hands-on experience to form an opinion; there are enough reviews and postings about it.
At the end of 2015 I looked into both the DS2000 and DS4000 very carefully when looking for an extra scope but decided not to buy either of those due to firmware bugs and price/performance.
I'm actually wondering what other scopes you have hands on experience with because your DS2000 seems to be like some sort of golden standard to you.
Rigol isn't a soccer club.
v00.03.04.01.00 2015/10/10
- Supporting the EDU models for education market
Also from the release notes. So, is this version 00.03.05.00.01 or 00.04.04.00.05? Also shows the date as 2016/05/31, so has this release really been ready that long?
They also included a text file of release notes/change log for each firmware version to date.
They also included a text file of release notes/change log for each firmware version to date.
FWIW, there are literally dozens of changes, extras, features, etc. that they've implemented in later firmware versions which are not documented in these release notes (just one that springs to mind: when they added EXT trigger as a source for the Pulse Trigger).
I've never understood why this is the case. Bad or lazy record-keeping? They don't want a paper-trail of when certain features are implemented? The public release notes differ from the private? Who knows?
Rigol support also included a web link to another release note in the email. I don't know if this is the public release note that you are referring to. It lists more changes/fixes for each release but does not include an entry for this latest firmware. It is attached below.
About my last post.I had issues with my DS2000 when I first got it due to firmware bugs.. mainly the hanging. But I had settled on the 03_03_02 which has worked well for me.. I have not gotten a single hang with it.
-After 3 years waitinf for a good update, i put my DS2202 in the oblivion room.
Because:
- Knobs are very imprecise and slow.
- Sometimes trigger doesnt work.
- When i turn it on most of the times show full screen noise and hangs, sometimes just hungs.
- Sometimes it just does not turn on.
After starting most of the time it is working ok, anyway i don´t feel confortable using it.
I like the idea to donate it, here in my country there are a lot of peopple that can need it.
Thanks for your comments.
Because:
- Knobs are very imprecise and slow.
- Sometimes trigger doesnt work.
- When i turn it on most of the times show full screen noise and hangs, sometimes just hungs.
- Sometimes it just does not turn on.
Thanks Marmad, I just saw there was a trick to show the detailed info... so here's that, i thought for some reason i had super old firmware version that possibly didn't show the detailed stuff. I'll carefully read over your great info. thanks for all your hard work, tried out your software really quick and it looks awesome so far.
(http://i43.tinypic.com/303b6g0.jpg)
Did I do something bad here? Was there conflict with these methods that casued me a problem? Below is the a screenshot I took back when I did the trial date hack, I never updated the firmware or anything since then. so it should have all been the same.
broke out into a cold sweat when this happened, but thought I'd jump on here and ask the experts, since I have a big gap of time missing on all the steps that happened from the trial hack to now the keygen....
The 1000Z also doesn't count pulses, it only counts pluses... :-DD
I couldn't find the maximum input voltage in 50ohm input impedance mode and the manual says CAT I 300 Vrms, CAT II 100 Vrms with Transient Overvoltage 1000 Vpk only in 1M ohm impedance mode.Are you sure it's not listed on the front panel alongside the BNC inputs ?
Does anyone know the proper input protection figures?
Ooops!! Yes, i looked everywhere but the writings next to the BNCs :palm:The manual supplied or their latest from their website ?
Well, i was trying to find a proper attenuator for measurement and I knew the common 5V limitation, however I had doubts about it and well... Thanks :)
Still, it's not been mentioned in the manual :blah:
Is there still a good buy 2072A and upgrade or it is better to buy 2102A and upgrade???
Could be my imagination, but it seems to improve waveform display quality (sharper, less fuzz in traces).
Just did the firmware update and Bingo!!What version of firmware?
new firmware on http://www.rigol.com/Support/SoftDownload/3 (http://www.rigol.com/Support/SoftDownload/3)
new firmware on http://www.rigol.com/Support/SoftDownload/3 (http://www.rigol.com/Support/SoftDownload/3)
The extended System Info shows update to Software Version 00.03.06.00.00 with date of Jan 17 2019 but hardware and FPGA version numbers did not change from last firmware version 00.03.05.04.00 (dated Mar 7 2018).
- When i turn it on most of the times show full screen noise and hangs, sometimes just hungs.
I might be able to buy a used DS2072A. Currently asking $600 for it, but has not been sold for a long time, so might be open to a lower offer.
Considering the age, what would be a fair price for a DS2072A these days? I doubt I'll ever need more than 100MHz, so a DS1054Z (hacked to 100MHz) would work equally well and have 4 channels. But, then again, I rarely need more than 2 channels, and in cases where a lot of digital signals are needed, a logic probe works usually as well. So my main alternative would be a DS1054Z or an even cheaper used 2 channels Rigol
I see that once hacked, the DS2072A maintains the features. Is there a version of the firmware that does not allow hacking anymore? I'm sure it's in the thread, but I haven't had time to read thru the 113 pages yet, sorry
I've had a few of the models in this range (1054Z, 1074Z, DS2072A, and MSO2072A).Thanks!
Given what you describe as your options (used and new) and your requirements/interests I'd say go for a new 1054Z (get a slight discount from tequipment.net and a warranty). It can't hurt to have the extra two channels (you might come up with some reasons to use more than 2). When I bought the 2000 series (and I'm still happy with the one I have) I was slightly smitten by the big Nav knob but I haven't used it nearly as much as I expected. It's still a great scope but it's hard to beat a new 1054Z in terms of price/features & performance. If you really want to spend more the next step up is probably a Siglent 1104X-E. Just depends on your budget and preferences. You could start with the 1054Z and sell it in 2-3 years for maybe half or more of what you paid for it and then look at what's the latest and greatest at that time, or your first scope might be all you need if you don't get TEA.