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 would also appreciate more details about the Rice Code than RTSA-File-Format-3.pdf gives.
In particular, when the leading nibble is zero does the Rice scheme keep consuming further nibbles (allowing encoding of an arbitrary input range), or maybe just use the next three nibbles again (giving a range of -4387...+4387), or perhaps just saturate at the -2339...+2339 range?
Hi Christian
Hi Steve3943
We are using uncompressed rtsa files for further signal analytics in python.
(DSPStreamFileChunkSamples.mCompression is 0)
But this does not work when you want to get them online via tcp-stream - there you can't set the compression to 0, it's always compressed 🙁
Sorry but information concerning the compressiont is internal and will not be published.
Then you should really adjust your RTSA-File-Format-3.pdf to reflect those changes.
And your RTSA HTTP Stream Server Endpoints capability through e.g. http://localhost:54664/stream?format=int16&scale=1000000 is basically useless because
a) json is to slow for high-speed data
b) the binary data is always send compressed and therefore unreadable for anyone except yourself.
This means we can't do a live evaluation of your collected data in our system.
