Products > Test Equipment

Rigol DG1000Z RAF file format

<< < (3/4) > >>

Ben321:

--- Quote from: nfb on October 14, 2021, 09:44:55 pm ---Here you are.

https://rigol.force.com/support/s/article/what-is-the-file-format-used-with-dg-arbitrary-waveforms2

--- End quote ---

Thanks.

mike47203:
Sorry Ben321. I never saw the notification about your post or I would have helped. Hoped you found what you needed.

Ben321:

--- Quote from: mike47203 on July 14, 2019, 04:52:50 pm ---The waveform CRC input data starts at byte 57 and runs to the end of the file
The header waveform is bytes 1 to 50. You have to calculate the waveform CRC first and place it in the header before you calculate the header CRC.

--- End quote ---

Bytes 1 through 50? Don't you actually mean bytes 0 through 49? In computer stuff like what the byte offset in a file is, those numbers usually start at 0, not at 1. Unless of course you literally do mean byte 1 (the second byte of the file) is where it starts. Also, in the previous sentence you mention byte 57 with no reference to what you consider the first byte, so can I assume that in that sentence you also assume that you consider 1 to be the first byte? Or in that sentence do you consider 0 to be the first byte of the file?

In general, can you please be more clear on where you are starting your numbering of the bytes? I always start my numbering of bytes at 0 whenever I'm describing the structure of a file. I need to know exactly what terminology you are using in your description, if I am to actually write software that implements what you are describing.


--- Quote from: mike47203 on July 14, 2019, 04:52:50 pm ---Interesting thing about the CRC is that the function generator doesn't tell you there is a bad CRC, but I get some strange results if it is. Maybe the sample rate is off or there can be a bad sample point. Seems to be fine with a good CRC. There could be something else going on, I haven't experimented with this too much. Maybe a firmware issue.

--- End quote ---

What it's doing is that if the CRC is bad, it assumes that it's a headerless waveform data file. All the remaining bytes of the header it assumes are actually part of the waveform. Yes, my DG1022Z does in fact correctly load headerless waveform files, as samples for it to output, but what it doesn't do is set the configuration for the scope (such as voltage amplitude and frequency settings) and thus it needs to be manually configured in such a case, or it needs to load a separate settings file (which can be made initially simply by manually configuring it correctly and then saving the configuration to a file).

Ben321:
You can ignore the first part of my above post, I re-found this document https://beyondmeasure.rigoltech.com/acton/attachment/1579/f-0595/1/-/-/-/-/DG%20file%20format%20and%20arbitrary%20waveform%20examples.pdf that explains the header. And by the way, I have discovered that all the multi-byte values used in the header (as well as each 2-byte sample) are little endian. This post https://www.eevblog.com/forum/testgear/rigol-dsxxxx-gel-firmware-file-format/msg1415612/#msg1415612 shows the different CRC specs for the different Rigol devices, and I discovered experimentally that the one I needed for my Rigol DG1022Z (which was not in the list of CRC specs in that post) was the same as the one that list refers to as "CRC-16/RIGOL 2". And the opening post in this thread showed where to calculate the CRCs. The waveform CRC is calculated first, and placed after the LowLevel field in the header. Then another CRC is calculated over the header from its first byte up through the last byte of the waveform CRC just calculated. This is the header CRC, and it's appended to the header right after the waveform CRC. After that, there's 4 bytes all with a value of zero. Then all the remaining bytes are the waveform.

I discovered that if at least one of the CRCs doesn't match, then the entire file is treated as a headerless waveform file. This means there's no settings stored in the RAF file for the funcgen to use, so things like sample-rate or frequency, and the voltage levels, will need to be manually set with the controls, or loaded from a previously saved settings file. This is fine if you wrote software to generate a waveform without a header, but it also means that if a header is present but just has a bad CRC, then the funcgen will mistakenly think that there is no header (it will assume it's a headerless waveform file), so it will treat every byte-pair in the header as a waveform sample. Suffice to say, its actual output analog signal will be incorrect in such a case.

Ben321:
I also discovered the format for the other signal specification values in the header. They aren't meant to be read and used straight away. They are actually scaled by various constants. When the output mode is PERIOD, the 64bit period/samplerate value represents the period * 10billion. When reading from the file, you need to take the number and divide it by 10billion to get the actual period as measured in seconds. When the output mode is SAMPLE RATE, the 64bit period/samplerate value represents the samplerate * 1million. To get the actual sample rate, as measured in smp/sec you need to take this value and divide it by 1million. As for the 32bit voltage level values, those represent the actual voltage * 10million.  To get the actual voltage levels, you need to take these values and divide by 10million.

I can't find ANY of that documented anywhere. I discovered it experimentally by using Rigol Ultra Station to generate several test files, and then writing my own loader software in Visual Basic, and trying different scale constants for the various values, until I found the ones that produced the correct results. Keep in mind, that these constants are correct when working with RAF files for the DG1022Z (the funcgen I have), but there's no guaranty that they will also be correct when working with RAF files for other Rigol funcgens. Also, the headers for these files don't contain any fields for storing the model number of the funcgen they are for, so for the software to interpret the values in the header correctly when loading an RAF, the software actually needs external input to tell it what device the RAF file had been created for. Even Ultra Station gives you a dropdown menu when you load an RAF file, asking which model number that the file is for, so it can know how to load it properly. That's not very good software engineering practice in my opinion, making a file format that requires user input to even tell the software what kind of file it's supposed to be, but that seems to be the way it is with the Rigol RAF files.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod