DS1024C are not parsed correctly #1

mabl · 2013-07-21T06:38:50Z

As reported by Vincent here the file format of the DS1024C seems to be incompatible with the current parser.

The error is

./wfmutil.py info Bouton0.wfm
Format does not follow the known file format. Try the –forgiving option.
If you’d like to help development, please report this error:

Field smpRate >= 0 not met, got -1.03636966193e-21

Probably the fields are shifted in this version.

The text was updated successfully, but these errors were encountered:

mabl · 2013-07-21T06:41:09Z

@vincent:
Could you please provide the wfm file? I'd really like to fix this.

Veence · 2013-07-23T09:54:01Z

Of course! I am trying to figure out how to add a file and I send it right away after ;)

mabl · 2013-07-23T09:59:56Z

I think you can easily upload the file to https://gist.github.com/. It looks like GitHub does not support uploading files in issues...

Veence · 2013-07-23T10:01:23Z

Ok. I’ve uploaded the file here:

http://dl.free.fr/hZrwEArai

Thanks for looking into this issue!
Vincent

Veence · 2013-07-23T10:05:05Z

Tell me if you got it. I just figured out that Free requires you to watch an ad before you can access the file…

mabl · 2013-07-23T10:06:06Z

I got it - I'll look into it and will get back to you if i require more info.

Veence · 2013-07-23T10:10:43Z

Great! However, I’ll be on holidays starting tomorrow till August, 20th circa. I’ve an Internet access but, needless to say, I don’t take my 'scope with me! ;)

mabl · 2013-07-23T10:49:33Z

Ok, I have some update on this issue.

I've loaded the file with my DS1052E and it loaded flawlessly:

So there must be intelligence in it to handle this file format. After it was loaded, I reexported the trace as a WFM file. This newly exported file works with pyRigolWFM ot of the box.

There is no difference between those two WFM files, except these:

--- Bouton0.wfm.hex 2013-07-23 12:20:35.000000000 +0200
+++ NewFile0.wfm.hex    2013-07-23 12:20:15.000000000 +0200
@@ -11,7 +11,7 @@
 00000a0 0001 0000 0000 0000 0000 0000 0000 0000
 00000b0 0000 0000 0000 0000 0000 0000 0000 0000
 *
-0000110 9c9c 9c9c 9c9c 9c9d 9e9c 9d9d 9d9c 9d9c
+0000110 2400 4874 9c9c 9c9d 9e9c 9d9d 9d9c 9d9c
 0000120 9c9d 9c9d 9d9e 9d9d 9b9c 9c9b 9d9d 9c9d
 0000130 9c9d 9c9d 9d9d 9d9c 9c9d 9d9c 9d9e 9c9c
 0000140 9b9d 9c9b 9d9c 9c9d 9c9b 9d9c 9c9c 9c9d
@@ -32778,4 +32778,5 @@
 00800e0 8383 8282 8182 8383 8183 8382 8083 8383
 00800f0 8382 8383 8382 8382 8283 8283 8283 8382
 0080100 8382 8382 8282 8383 8382 8282 8281 8382
-0080110
+0080110 0000 0100                              
+0080114

(NewFile0.wfm.hex is the freshly exported file from my scope running the most recent 00.04.00 firmware.)

Note, that there are only two differences:

At 0x0110 the working WFM file has the additional bytes 2400 4874. the 9c9c etc. is the channel data.
The working WFM file has a trailing 0000 0100 after the channel data.

Point 1. is the one causing your problem. It encodes the sampling rate. Interestingly, the sampling rate is also encoded into channel timing information and hence totally redundant. Deleting the line 164 in wfm.py

    ("smpRate",  "f",  ("require", ">=", 0))

should work around this problem and make the script parse your WFM files.

Point 2. is also interesting. It's actually the first time I've scrolled to the end of the channel data section! I've never noticed those bytes - and all WFM parsers I know also do not care for them. I assume, these encode the WFM version information and were later added to the file format.

How old is your scope? Which firmware version do you use?

I'll add a proper version detection once I'm more sure about those trailing bytes.

mabl · 2013-07-23T11:33:34Z

Ok, so it now looks like the trailing 0000 0100 was added due to a bug in the scope. It actually appended a sample of data which was not in the data. Notice how it is also displayed as a spike at the end in the oscilloscope screenshot. I think the my Rigol also just ignores the sampling rate field, but since then the channel data is actually to short - it just invents some random data at the end. Not what I call professional from RIGOL...

I can work around this though. I'll update the repo soon.

As reported by issue #1, there are wfm files which miss the smpRate field. Since the information is redundant, we can simply ignore the field for such files. Detection of the protocol version is done via the file length.

mabl · 2013-07-23T11:53:42Z

@Vinsang: You should now be able to open the files generated by your scope. (At least it works for me.) I'd still be interested in the age and firmware version of your scope, though.

mabl · 2013-07-24T10:36:30Z

It looks like the field missing in your file is the sampling rate of the integrated logic analyzer. For the DS1000 series, which do not include a logic analyzer, this field looks to be equal to the primary sampling rate.

So it seems that the Rigol guys added some of the logic analyzer features later to their product and modified the struct holding the sampling data. Unfortunately this also resulted in this new field in the wfm header. I doubt they even noticed that their internal change broke WFM compatibility....

Veence · 2013-07-27T19:07:44Z

Hi Matthias,
erst und vor allem, vielen Dank für deine Anstrengungen!
I have a logic analyser bundled with my scope. So the issue remains pretty odd.
As soon as I am back home, I’ll mail you the other infos you requested.
Thanks so much again for the time you spent on this issue.
Guter Sommerurlaub!
Vincent

mabl · 2013-07-28T14:34:20Z

Hi Vincent,
you are very welcome.

Interesting, that your scope supports digital channels. I'd like to point you to issue #3 for this. I have yet to get WFM captures with digital channels.

mabl · 2013-08-26T07:48:30Z

Hi Vincent,

I hope you had a nice vacation! Did you have time to look into this issue again? Is it resolved for you? Maybe you could also provide WFM files with digital channels?

Best,
Matthias

Veence · 2013-08-26T19:35:00Z

Hallo Matthias,
wie geht’s Dir?

I hope you had a nice vacation! Did you have time to look into this issue again? Is it resolved for you? Maybe you could also provide WFM files with digital channels?

Nicht jetzt (bin nur gestern Abend zurückgekommen), aber ich verspreche Dir, ich werde es Morgen versuchen.

Noch einmal vielen Dank für deine Anstrengungen!

Bis Morgen! Gute Nacht inzwischen!
Vincent

beribboned · 2014-05-26T21:32:30Z

I have a DA1052E . I also get "Field smpRate >= 0 not met, got " followed by a Á Capital A, acute accent. Using od -c the first few bytes are

0000000 ¥ ¥ \0 \0 Á \n \0 \0 005 022 \0 \0 \0 \0 \0 \0
0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000040 002 \0 \0 \0 206 001 \0 ü ÿ \0 \0 \0 \0 200 ?
( if the above gets messed up) od -x gives

0000000 a5a5 0000 0ac1 0000 1205 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 2000 0000
0000040 0002 0000 86a0 0001 fffc 0000 0000 3f80

mabl · 2014-05-27T05:00:05Z

Hi @beribboned,

could you provide me with the wfm file?

Best,
Matthias

beribboned · 2014-05-27T12:45:48Z

http://people.trentu.ca/benbauer/WFM/aaaaaaaa.wfm

here is a plot I made (partial data) after extracting channel 1 using rigol2dat.C
( http://nsweb.tn.tudelft.nl/~gsteele/rigol2dat/ )

http://people.trentu.ca/benbauer/WFM/rgl001.pdf

Note that I had to fudge the timebase because rigol2dat didn't seem to get it quite right. This should be close to 85.2 Hz.

mabl · 2014-05-27T12:58:55Z

Hmm this file does not work, but also does not throw the error you mentioned:

-> % python3 ./wfmutil.py info ~/Downloads/aaaaaaaa.wfm
Format does not follow the known file format. Try the --forgiving option.
If you'd like to help development, please report this error:

Field unused1 == b'\x00\x00\x00\x00' not met, got b'\xc1\n\x00\x00'

-> % python3 ./wfmutil.py --forgiving info ~/Downloads/aaaaaaaa.wfm
Traceback (most recent call last):
  File "./wfmutil.py", line 47, in <module>
    scopeData = wfm.parseRigolWFM(f, args.forgiving)
  File "/tmp/pyRigolWFM/wfm.py", line 311, in parseRigolWFM
    scopeData["triggers"] = parseTriggerHdr(fileHdr["trigHdr1"])
  File "/tmp/pyRigolWFM/wfm.py", line 300, in parseTriggerHdr
    trgDict["slope"] = (trgDict["level"] -  trgDict["slopeLowerLevel"]) / trgDict["slopeWidth"]       # V/s
ZeroDivisionError: float division by zero

This error is due to slopeWidth being equal to zero. Once this is removed, the file works:

General
=======
Cur. selected channel    : CH2
Alternate trigger        : False

Channel CH1
===========
Enabled                  : 1
Probe attenuation        : 1.0
Y grid scale             : 1.000e-01 V/div
Y shift                  : -1.600e-02 V
Y inverted               : 0
Time grid scale          : 5.000e-03 s/div
Samplerate               : 5.000e+04 Samples/s
Time delay               : 0.000e+00 s
No. of recorded samples  : 8192

Channel CH2
===========
Enabled                  : 1
Probe attenuation        : 1.0
Y grid scale             : 1.000e-02 V/div
Y shift                  : -1.720e-02 V
Y inverted               : 0
Time grid scale          : 5.000e-03 s/div
Samplerate               : 5.000e+04 Samples/s
Time delay               : 0.000e+00 s
No. of recorded samples  : 8192

Channel CHLA
============
Enabled                  : 0

Trigger
=======
Mode                     : Slope
Source                   : CH2
Coupling                 : DC
Sweep                    : Auto
Holdoff                  : 5.000e-07 s
Sensitivity              : 3.800e-01 div
Level                    : 1.200e-02 V
Slope type               : RISE >
Slope lower level        : -3.600e-03 V
Slope width              : 0.000e+00 s
Slope slope              : inf V/s

mabl · 2014-05-27T12:59:57Z

Should be fixed in master now. The --forgiving option is still required, I'll look into that.

mabl · 2014-05-27T13:02:44Z

The plot also looks right

beribboned · 2014-05-27T13:16:24Z

Thanks. Works with python 2.7. This is a CRT screen measured with a photodiode pulled from an optical mouse.

mabl closed this as completed Jul 23, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DS1024C are not parsed correctly #1

DS1024C are not parsed correctly #1

mabl commented Jul 21, 2013

mabl commented Jul 21, 2013

Veence commented Jul 23, 2013

mabl commented Jul 23, 2013

Veence commented Jul 23, 2013

Veence commented Jul 23, 2013

mabl commented Jul 23, 2013

Veence commented Jul 23, 2013

mabl commented Jul 23, 2013

mabl commented Jul 23, 2013

mabl commented Jul 23, 2013

mabl commented Jul 24, 2013

Veence commented Jul 27, 2013

mabl commented Jul 28, 2013

mabl commented Aug 26, 2013

Veence commented Aug 26, 2013

beribboned commented May 26, 2014

mabl commented May 27, 2014

beribboned commented May 27, 2014

mabl commented May 27, 2014

mabl commented May 27, 2014

mabl commented May 27, 2014

beribboned commented May 27, 2014

DS1024C are not parsed correctly #1

DS1024C are not parsed correctly #1

Comments

mabl commented Jul 21, 2013

mabl commented Jul 21, 2013

Veence commented Jul 23, 2013

mabl commented Jul 23, 2013

Veence commented Jul 23, 2013

Veence commented Jul 23, 2013

mabl commented Jul 23, 2013

Veence commented Jul 23, 2013

mabl commented Jul 23, 2013

mabl commented Jul 23, 2013

mabl commented Jul 23, 2013

mabl commented Jul 24, 2013

Veence commented Jul 27, 2013

mabl commented Jul 28, 2013

mabl commented Aug 26, 2013

Veence commented Aug 26, 2013

beribboned commented May 26, 2014

mabl commented May 27, 2014

beribboned commented May 27, 2014

mabl commented May 27, 2014

mabl commented May 27, 2014

mabl commented May 27, 2014

beribboned commented May 27, 2014