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

[marmad]

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?

EDIT: As mentioned in a later post, I've discovered that the bug/problem is with loading waveforms into DSO memory.

Set sample length to 14MPts (you can also try 56MPts - but it will take longer to save the file). Sample any waveform (EDIT: I used noise - but I don't think it matters - see also post below) - STOP, enter Zoom mode, go to the end of the waveform and save the image:

BEFORE SAVING


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:

AFTER LOADING


EDIT: On my DSO, the waveform is not being recalled correctly from the file.

[andrewfernie]

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? 

Someone has posted it in the software thread.

[marmad]

As it turns out, it doesn't matter what kind of waveform you save. Here is another example - showing the end of a 14MPt capture, save, and load of a sine wave:



EDIT: The place where the file/memory gets corrupted:

[EV]

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.

[marmad]

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

[marmad]

Here is the sine wave file I showed in the previous post reloaded again into the DSO memory. It again has corruption at the end - but different than the first time of loading it:

[EV]

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

I could not repeat this bug, I did it only once. Look at the picture. Have you tried an other USB-stick?

Edit: I try again with 20 MHz sine wave.

[EV]

Now I got it. It was also at the end of 1.4Mpts file, but I did not take picture from it.

[marmad]

Help question,

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

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

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

[marmad]

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.

Now I'm just wondering if it's related to this other bug bug I posted about, or something different entirely.

[Wim13]

@ 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 ..
And there is a battery low indication, was there ever a battery in these Rigols..?
Or is this firmware written for more brands then only Rigol..?
The firmware is not encrypted. You can upgrade with former version, or the same.

[marmad]

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

No problem Wim - I was kidding. These threads get so long it's almost impossible to read the whole thing - and I know what you mean about the info not having significance unless you've used the feature, etc.

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.

It's easier to connect now - with USB or LAN. I recommend downloading Rigol's Ultra Sigma software and experimenting with sending SCPI commands to the DSO . It's very easy (ASCII based messages) and you can test many things (such as the memory read bug I described).

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.

Interesting. I hope it stays this way - and Rigol concentrates their efforts on getting rid of the bugs - instead of on hack-prevention.

[marmad]

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

Yes, way too many - I also thought of that the first day with the scope   But the only way to reverse engineer a key-generator is to 'watch' what math the firmware performs on the license code + serial number.

[marmad]

@Teneyes - I posted a small piece of test software for you in the other thread - to check if your 01.00.02 software uses the "Open" command (as mine does) - or the "Keep" command (as noted in the outdated programming guide). Please let me know which one works for you.

[martinv]

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

I ran this same test using my HP 8660D signal generator into my new DS2072.   My results were within 1dB for the most part.  I am very impressed with the scope so far.

[marmad]

I posted some utility software at the other thread to test if your Rigol DS2000 series scope can have it's sample memory read correctly by the PC. Mine is failing this test, as reported earlier here as a serious bug/problem.

Could someone please give it a try and let me know what happens?

Thanks.

[Sparky]

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

Thanks for this --- it's something I didn't notice previously.  I just had a look on my DS2072 and the new menu is called "PROJECT" --- just thought I'd mention it because I was looking for "SERVICE" option  

I did not play with anything on this menu yet.

[Sparky]

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?

[Sparky]

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?

Now I realize this is the same issue as posted by Wim13:
https://www.eevblog.com/forum/reviews/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg175819/#msg175819

This thread has grown a lot in the last couple of days --- difficult keeping up!

[marmad]

This thread has grown a lot in the last couple of days --- difficult keeping up!

True    But the bug I found when loading waveforms into memory has nothing to do with the Record mode - so that limitation doesn't matter.

[Sparky]

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?

This bug has already been confirmed by EV, but here I also post my result of this test.  In my case, each time I load the waveform from USB stick, the error appears to be the same.

See my "before" (waveform as originally recorded, before saving to USB drive) and "after" (after loading from USB drive) images attached.

Interesting that the error in recalled waveform always appears at the very end.

[Sparky]

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

Okay, I gave it a shot and I can confirm this doesn't work correctly.  I set the memory depth to 5.60k points (:ACQuire:MDEPth? returns 5600) and then acquire some data and then run each of the SCPI commands from Ultra Sigma.

When I send the :WAV:STATus? it returns IDLE, 1400 to say the read operation is idle and there are 1.4k points to read.  When running the next command (:WAV:DATA?) it returns #9000000000 which seems bogus (last 4 zeros indicate no data).  On a fifth execution of this command, it returned #9000001400xxxx.... which indicates it is sending 1400 points, and the xxxx's are the data.  Then I run :WAV:STATus? again and it indicates IDLE, 1400 so I try and read another 1.4k points with :WAV:DATA? but system returns #9000000000 again...and after a few attempts it succeeds and sends #90000014007xxxxx again.  So, even on second, third or forth attempts to read data, when it eventually does send data, it seems to be sending the exact same first segment of data as was returned from the beginning, rather than the next 1400 points of data. 

So, does not seem to be working correctly, even for small memory depth (5.6k points) when trying to read 1400 points at a time.


EXTRA INFO: I should add that even when doing the step :WAV:MODE RAW to set the waveform to RAW mode, :WAVeform:POINts? still returns 1400, which is the normal maximum number of points to read.  That is, the number of points to read doesn't automatically update to the maximum possible allowed in RAW mode.  Thus, in a second test, I subsequently send :WAVeform:POINts 5600 to set the number of read points to 5600, and WAV:STATus? now returns IDLE, 5600.  Then, after a bunch of failed :WAV:DATA? it eventually succeed and returns all 5600 data points.  So, this seemed to work fine (despite initial fails to read data).

I then did another test, with memory depth 280k points. :WAV:STATus? returns IDLE, 280000.  And, on second attempt at read, :WAV:DATA? succeeds and this time returns 126948 data points, and not the full 280k points asked for.


I then tried the MATLAB programming example in the DS2000 series programming guide, and that fails also.  The request for data ([data,len]= fread( ds2000, 2048 ) times out before the operation completes.  This happens even when the input buffer size is 1400 points.

This is possibly the worst bug so far --- no ability to read out the complete memory to PC for further analysis.  Really hoping this bug can be fixed!

Has this one been forwarded to our friend drieg?


Edit note: Since my original post, I read a bit more about setting the number of waveform points to read, and so I subsequently performed additional tests and included results above.

[EV]

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]

I've posted a revamped version of the Rigol Read Memory test in the software thread. It allows you to check if your scope has the bug which prevents correct reading of the sample memory.

There is definitely a bug in the IDLE -> READ response sequence - which is the final response for the final packet when reading memory. You can see how this works by setting your memory depth to 14MPts, then running my software and clicking "Rigol Full Sample Memory Read - MAX/RAW mode". The PC will read the entire memory - but fail on the final packet.  Unfortunately, for small memory depths (< 14MPts in non-ASCII mode), there is only one packet - so read attempts at 14kB and 140kB and 1.4MB fail using Rigol's technique. Using my "Wait Until Bytes Read >= Sample Memory Size" button will usually force my DSO into finally sending the final packet at smaller memory depths (<= 140k) - but it's a wonky workaround.

This bug appears to be confined to v.00.01.00.05. Once I hear Rigol's response to the problem, I will consider downgrading to v.00.01.00.02

[marmad]

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.

Thanks, EV. Confirmed this bug on my scope too. I'll add it to the bug list on Page 1 - which I'm updating now.