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.
Hi,
I have 00.00.01.00.05 Software, Hardware is 1.0.1.0.0, rest I guess isnt important? - The proceedure you give for obtaining the information is part of the calibration routines - I ended up in channel gain menu
/not related to the wfm parsing,
The 01.00.05 firmware locksup with RAW reads even in stop mode, currently Im resorting to reading the display data and processing that. Not ideal - Thats already on the forum and theres a test app, not good for me since I dont use windows at all, I used rigolterm and the scope crashed with manual / basic command entry.
The dealer sent me the latest firmware 00.01.00.00.03 together with the DS2000 programming guide dated July 2012. Fine for usb control (if raw worked, need to double check the commands while in the same room as the scope.)
Im also aware the firmware update proceedure is a little more involved, will check that.
Somewhat related:-
http://www.urlme.net/blog/?p=2031The dual channel example is from a TEK TDS1012B scope.
-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.
I will make a file with e.g 100 MHz marker (via sig gen) & capture it to investigate the file further.
Regarding other comments: We gain in hardware what we loose in documentation...
Batronix have been fast and friendly but ultimately must also resort to emailing Rigol...