Signature Data Format (.AD2CP files) AltRaw definition?

Up to System integration and telemetry

Signature Data Format (.AD2CP files) AltRaw definition?

Posted by Levi Kilcher at December 30. 2017

Hi-

I'm working on a Python reader for binary ad2cp files. I'm wondering if there is a discrepancy between the data format, and the description in the System Integrator's Manual (SIM). Based on the SIM, 0x1A records (Burst Altimeter Raw record) should have a length of about 112 bytes (depending on which bits are set in the burst's Configuration bit-mask). However, the header block for the 0x1A record says the block is 3090 bytes. Can you explain the difference?

My guess is that the Altimeter Raw Data sub-block is incorrectly defined. For example, the 'format' column of the 'Altimeter Raw Data - Samples' row says 'signed fract' what does that mean? is there supposed to be a '16 bits * (Altimeter Raw Data - number of samples)' here somewhere?

Thanks,

Levi

Re: Signature Data Format (.AD2CP files) AltRaw definition?

Posted by Levi Kilcher at December 30. 2017

Here are a couple more questions about the ad2cp data format:

  1. The 'ensemble counter' seems to wrap (max) at 4096 (i.e., 2^12). However, this is a 32-bit field in the data file. Why doesn't it go all the way to 2^32?
  2. I recorded data for 106 days on a 500 kHz Signature at a sample rate of 2Hz. This created a >23GB file. The strange thing is that the last few days of the file seem to have been inserted near the beginning of the file: after the string header block (0xA0), but before the data from the beginning of the sample-period. At first I'd assumed that the write-operation had 'wrapped' over the beginning of the data, but all of the data from the beginning of the measurement period is there! Thus, the data from the end actually got inserted. This seems like very strange behavior. Happy to share the data file privately if necessary.
 
Thanks,
Levi
Powered by Ploneboard
Log in


Forgot your password?
New user?