RTSA-Suite PRO File Format (IQ and SPECTRA) Documentation & Sample Files
Features and Purpose
The RTSA-Suite PRO file format for IQ and SPECTRA records is used to store files generated by the RTSA-Suite PRO.
The file format is binary and chunk based, similar to e.g. the PNG file format.
The file format offers the following distinguishing features:
• Binary, compact and optionally compressed storage of measurement data
• Meta data storage (location, time, format etc.)
• Multi streams
• Interleaving of streams
• Sequential stream read and write
• Random access of complete files
• Preview storage of power spectra and power histogram
• Extension of existing streams
Doc-PDF and a sample IQ and SPECTRA recording (CW signal at 2410MHz with 1MHz sample rate / 1024FFT) is attached
Uploaded files:Updated the documentation to V3 (thanks Aaron for noting the typo within the Rice bit packing table).
Hello,
we're trying to parse a rtsa file by our self but facing some issues:
- DSPStreamFileChunkSamples.mPacketFlags is not documented (can't find Packet flags DSPPF_*somewhere in the documentation)
- After DSPStreamFileChunkSamples.numSamples there are 8 bytes of undocumented data before the samples start (most time it's 0x00000001)
- When we assume that after those 8 bytes the rice encoded data starts (DSPStreamFileChunkSamples.mCompression is 1) we get decoding errors because we encounter 0x00 as a first nibble which is not allowed so I assume we're doing something wrong but can't find out from the documentation what exactly.
- The padding before a 64bit value should be documented (can only be seen in the example)
It would be nice if you can clarify this so we can properly decode the data.
Thx,
Christian
There was a new value added to the struct after numSamples:
quint32 mSampleLayers; // Number of sample blocks in one measurement (third dimension in volumetric data)
That you're seeing 8 bytes is probably due to 64 bit padding of the structure.
Regarding the packet flags, these are defined as follows:
Uploaded files:
Thx for the fast response. Can you help me to decode the samples data?
As you can see the data is compressed (mCompression is 1) so the samples should be rice-encoded. But it does not decode properly:
0x2 --> 3 Bytes --> value = 0x22b = 0010 0010 1011 = -39
0x5 --> 2 Bytes --> value = 0x51 = 0101 0001 = -10
0xb --> 1 Byte --> value = 0xb = 1011 = -1
0x0 --> ???
Thx,
Christian
I've forwarded the issue internally, not really my area of expertise.
@mm_dev: Any news on this? It would be nice when we could decode also the compressed packets as they are much smaller than the uncompressed ones or the json representation.
Sorry, unfortunately there hasn't been any feedback yet regarding this topic.
