REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol

[MikeR]

-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.

It not my conclusion since its still being investigated. I haven't "claimed" anything here just stated my ongoing observations. Which stands currently that the 2GS/s wfm file when loaded into baudline only seems to be at 1GS/Sec, why is still to be determined and I am working with the baudline author to add support for the file format having supplied many example waveforms.

Update:
That observation is for the .wfm file *only*

- The CSV output mode does contain the full 2GS/Sec when configured to capture at that speed.
as shown in the attachments.

Same 50 Mhz signal.

Loading the .wfm with a samplerate (in baudline) set to 1GS/sec results in the 50Mhz signal being
at 50 Mhz, which triggered my original question.

-M

[marmad]

I haven't "claimed" anything here just stated my ongoing observations.

You wrote:

It "seems" to be sampling at 2GS/sec.

and

...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 .

Which 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.

[MikeR]

I haven't "claimed" anything here just stated my ongoing observations.

You wrote:

It "seems" to be sampling at 2GS/sec.

and

...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 .

Which 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. Now this has been solved and its showing a full 1 Ghz of spectrum from the 56M captured wfm.

Same is probably true for the 1400 :wav:data? points thats currently capturing at 30FPS or over 68K samples /sec over LAN so extending the same decoding to that code should be trivial.

-M



 

[marmad]

Well not really, my understanding was incorrect. Baudline was reading the file correctly it was just in the wrong order / format.

So you think Rigol was writing their own invented file format the wrong way?    I think it would probably be more accurate to say that Baudline was not reading Rigol's new version of it's .WFM format correctly.

[marmad]

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.

@Evi: Good idea. I will ask my dealer if he thinks it would be a problem for Rigol if we keep copies of the already-released FW versions available here. BTW, I sent you a PM about FW, too.

[marmad]

I've been doing stress testing on the two-channel memory sample reading bug of the Rigol (#13 in this list) in order to try to quantify things better, so that Rigol will fix it in the next release.

My results so far are as follows:

AUTO (single) / 14kB / 140kB / 1.4MB / 14MB / 56MB / AUTO (dual) = Reading is SUCCESSFUL (either BYTE or ASCII mode): 
7kB* / 70kB* / 700kB / 7MB / 28MB = Reading FAILS [*sometimes] (whether BYTE or ASCII mode): 

If anybody else is interested in testing their Rigol, I've written a new piece of software (Rigol_Sample_Memory_Read.zip) (also attached below) to automate the testing of all sample depths.

To use it, you don't need to do any setup or have any input signals to the DSO; it's irrelevant - the software will turn on and off the appropriate channels, set the memory depth, and try to read.

To run every memory depth, just select "ALL" for single and/or dual channel modes, and click "RUN".
NOTE: it takes time to read 7MB, 14MB, 28MB, and 56MB memory depths (the software inserts a 350ms pause after every packet from the DSO - and a 750ms pause between switching memory depths) - so use 'Break' if you want to exit ('Clr Text' to empty the message output box).
If the total received bytes don't match the acquire memory depth setting, the software will display the result in RED (FAIL).

For testing ASCII transfers, you have to use a different technique. Since the number of ASCII bytes is unknown for a given memory depth, select only ONE memory size to test, set 'Repeats' to 3 or 4, then 'RUN'.
If each repeated test gives exactly the same number of ASCII bytes returned, the result is SUCCESSFUL. If the tests return different numbers, the result is a FAIL.

You can also use the 'Repeats' setting to run multiple tests on one memory depth. For example, if I run the 7kB memory read test 10x, it seems to fail ~50% of the time.

Please report back findings here for compilation and delivery to Rigol.

The image shows the results of a test run on all possible acquire depths; 4 settings failed (70kB / 700kB / 7MB / 28MB):

[Corporate666]

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.

[ve7xen]

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?

[marmad]

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 of orders at the moment.

[Corporate666]

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

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.

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.

[marmad]

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.

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'm guessing that this backlog of orders probably started suspiciously shortly after Mr. Dave Jones published "EEVblog #451 – Rigol DS1052E vs DS2072 Oscilloscope" 

[Galaxyrise]

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?

[Corporate666]

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?

Funny, I was this -> <- close to splurging and getting the 2102 because they have it in stock... but it's over a third more and the only difference appears to be 70Mhz vs 100 Mhz.  I'm usually working with stuff under 1Mhz, so the extra money is a lot to spend for instant gratification

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? 

[marmad]

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? 

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.

[marmad]

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)

[Jason]

I bought one from rigolna.com a couple weeks ago when I saw they were back in stock; it shipped out the next day.  I suspect "4 to 6 weeks" is their general lead time and it's not really tracking their incoming shipments.

Yeah, I also considered the DS2102 to avoid the wait but the price jump was a bit too much.  The DS2072 was already more than I wanted to spend (this is just for hobby use).

[Corporate666]

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)

Very interesting!  Thanks for the info and link in the previous post.  That actually seals the deal for me.  One of the reasons I didn't want to splurge on the DS2102 was because I had planned to get the Rigol function generator as well... don't really need it, just like it   and it would replace my aging fluke and give me a few more features I don't use too much.  But if the -S model will have function generation capability built in, I will stick with my old Owon for the time being.

[Hydrawerk]

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.

I am afraid that it will not be a option that can be added to an older DS2000 series scope.

[marmad]

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.

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.

[marmad]

I worked again on testing the Rigol FW sample-memory reading bug - and I've finally figured out the exact parameters of the bug - which should help Rigol engineers track it down. This bug has persisted through all of the last 3 official firmware versions, so I'm really happy to finally nail it down. 

A detailed bug report and a special version of the sample-read software has been sent to Drieg - which will be passed on to Rigol Monday for processing into the next official release. From what I know, the 'measurement bug' first spotted by EV in the latest FW (01.00.00.03) has been fixed - so if they can just get rid of these (plus Teneye's 500uV trigger offset and any lingering Cursor issues) we might be approaching the mythical 'zero bug' territory.

Anyway, for those of you with any interest, the precise specifications are as follows:

When both channels are on, any memory read that requires more than one packet of data will ALWAYS fail. The maximum packet size is around 2MB - so any memory depth >2MB for byte mode or >~200kB for ASCII mode can not be read correctly.

I was mistaken about this - more info here.

[marmad]

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.

Yes, none of those memory depths are available with both channels turned on - except indirectly via AUTO at certain timebase settings - so they work fine.

Or does turning on the 2nd channel cause all hell to break loose? which was the point of the bug report...

Yes, both channels turned on invokes the bug listed above.

[marmad]

@MikeR:  I think you're being a little optimistic with those transfer speeds you mentioned; the bottleneck isn't really the interface - it's the Rigol.

When you send the command :WAV:BEG - the Rigol starts filling a buffer in the DSO (~2MB large). If you ask for the data before the buffer is filled, you'll get it - and the DSO will continue filling the buffer (if necessary). If you don't empty it before it's filled, the DSO will wait.

But it's possible to time exactly how long it takes the scope to fill the buffer. In the case of 1.4MB, it's ~5.95s (if I remember correctly, it takes ~8.6s to fill it entirely). This is not taking transfer speeds into account - this is purely the time it takes for the DSO to move 1.4MB of sample memory to the output buffer. Rigol have clearly written the firmware so that external events like reading memory won't have any impact on the DSO's real time performance.

In terms of transfer speeds over USB, it takes my computer about 1.275s to move 1.4MB from the Rigol.

[Evi]

Please report back findings here for compilation and delivery to Rigol.

My result

[mrubbert]

Love this scope.
Glad that i stopped a Owen order and go for this DS2.
http://www.silcon.cz/ is a Verry good place to buy from.
Quick delivery, good package, comunication ...........
Thanks to Drieg, marmad, eevblog and all others.

[marmad]

My result

Thanks, Evi!  Are you using USB or LAN connection?

Love this scope.
Glad that i stopped a Owen order and go for this DS2.
http://www.silcon.cz/ is a Verry good place to buy from.

Welcome to the forum as DS2000 owner. Yes, Drieg is a great person/dealer to do business/communicate with.