Rigol ds1054z WFM data converter

[Pat Pending]

I just received a new Rigol DS1054Z and hit a snag almost immediately.

What utility converts the WFM files stored to flash into CSV format?
I've tried 5 different utilities from several varieties of python script to utilities that required labview.
I tried Rigols' own UltraScope as well as a ancient Tek WFM converter tool.
None has worked.

Storing as native CSV format on the flash simply takes too long

Any ideas what works.
Thanks

[Mechatrommer]

try VisaDSO

[Pat Pending]

I was looking for a script to perform the conversion due to the number of files but I'm in a pinch and this worked perfectly.

Thanks Mechatrommer

[Mechatrommer]

i'll just leave the VB code chunk where it reads the WFM format here in case anybody want to continue the work... fwiw..

[Fungus]

Next question: Are the numbers you get the same as the CSV files or are they the raw sample data?
 

[Mechatrommer]

who you are asking? what numbers?

[Fungus]

who you are asking?

The people who've tried it.

what numbers?

The sample values inside the file, after decoding.

[Mechatrommer]

The sample values inside the file, after decoding.

there is no need to decode, everything is plain raw (8 bit) value. but i cant remember if they are the same as csv or not because if we closely deal with this we will encounter some form of weirdness (bug?) ie sometime the data we downloaded whether directly to PC through USB, or in wfm/csv files is not tally with whats shown on the dso screen, so we need to double check what we get in files/pc compared to dso screen. but sometime they are the same. VisaDSO provides manual data offset (Settings -> Data Trans. Method) and (Settings -> Manual Trans Setting) and scaling in case we encountered this bug. by default, we assume no bug (data discrepancey) going on (Settings -> Data Trans. Method -> Default (Rigol Formula)).

my advice in case capture process (wfm export from dso) cant be made the same time and place as PC post processing or data analysis, we should make screenshot capture to the USB stick used to save the wfm file, so later in pc we can verify the data captured from DSO (screen) was the same (offset and scaling) as whats saved in the wfm file. fwiw...

[Fungus]

The sample values inside the file, after decoding.

there is no need to decode, everything is plain raw (8 bit) value.

They will need to be offset/scaled to whatever the vertical settings were when it was captured.

but i cant remember if they are the same as csv or not because if we closely deal with this we will encounter some form of weirdness (bug?) ie sometime the data we downloaded whether directly to PC through USB, or in wfm/csv files is not tally with whats shown on the dso screen

On screen and CSV have sin(x)/x applied to it (maybe, after last week I'm not so sure).

[Fungus]

I just had a play and the short answer is: No.

Here's the data grabbed over LAN:

0000000  21 22 21 21 20 21 20 21 20 21 21 21 20 22 20 21 !"!! ! ! !!! " !
0000010  21 21 21 21 20 22 21 21 21 22 21 22 21 22 21 20 !!!! "!!!"!"!"!
0000020  20 2A 3C 54 6C 83 95 A1 A7 A7 A3 9A 91 87 80 7D  *<Tl..........}
0000030  7D 80 84 87 89 89 88 87 85 84 83 82             }...........


And here's the corresponding data inside the wfm file (shown in hex editor):


It's identical.

[Mechatrommer]

...
It's identical.

yes. istr that the problem is discrepancy between whats shown on the dso screen and all the downloaded/saved data. the downloaded and saved data are (should be) the same, except csv is precalculated (rigol 8bit to volt value formula) from the dso. but sometime, they are all tally with the screen, you'll need luck to observe and experience the bug, istr it has something to do with triggering state when the data is loaded into memory (when capture is stopped) and then transmitted to usb/lan/file. ymmv.