Help needed decoding data

[Jef Driesen]

On 2014-06-30 04:37, John Van Ostrand wrote:
> Each sample is in 3 byte structure and the composition of that 
> structure
> changes every second between two types. The odd seconds (if it starts 
> at 1
> sec) have a structure that seems to have a pressure change in mbar, the
> even seconds have a structure that seems to store temperature samples. 
> Both
> types of structures seem to hold tissue compartment estimates.
> 
> Two seconds of samples looks like this (hex and binary for each sample
> shown):
> 
> Odd Seconds (bytes 1 to 3)
> 0x02 00000010  Bit 7, when 0, indicates that a sample follows. Bits 6 
> is a
> flag, maybe + or - indicator or data, bits 5-3 are always 0, bits 2-0 
> vary
> often.
> 0x14 00010100  Bit 7 indicates a negative value in this byte, bits 6-0 
> seem
> to be mbar increments from the last sample.
> 0x03 00000011  Byte indicates tissue compartment loading for one
> compartment.
> 
> Even Seconds (bytes 4 to 6)
> 0x01 00000001 Bit 7, when 0, indicates that a sample follows. Bits 6 is 
> a
> flag, maybe + or - indicator or data, bits 5-3 are always 0, bits 2-0 
> vary
> often.
> 0x30 00110000 Bits 6-0 change very slow, like a temperature sample but 
> the
> value is off and may need to be adjusted, maybe to a calibration.
> 0x02 00000010 Byte indicates tissue compartment loading for one 
> compartment.
> 
> It's clear from using the dive software that samples for depth and temp 
> are
> displayed for each second yet it appears that depth and temp are only
> recorded every other second.

Based on the above description (I haven't looked at your code), I think 
there is only one 6 byte large sample, rather than two different but 
alternating samples. In that case the sample rate is of course two 
seconds instead of one. The application may still interpolate (or copy) 
samples to give the impression of a one second sample rate.

With fixed size samples, I suggest you make a hexdump with one sample 
per line. Because bytes in the same column usually always represent the 
same type of data in a fixed size sample, you'll more easily notice 
certain patterns in the data. It certainly helped me to figure out the 
data structure in a several cases.

> I've extracted what appears to be the mbar
> increment data bits and graphed them. They closely, but not exactly, 
> follow
> a dive profile from the vendor software. There is detail missing and 
> the
> computed depths are a few feet off. I may not have mbar to feet 
> conversion
> right or there is a calibration I need to consider.

They might take into account atmospheric pressure and/or salinity. If 
there is a fixed absolute different, then there is a different 
atmospheric correction. If it's a fixed scale factor, then that's likely 
a different salinity factor.

Another reason could be rounding errors and scaling factors. If there 
are for example unit conversions necessary, and the application only 
shows a limited number (or no) digits than the values may appear to be 
slightly off. But in the end that's just a rounding issue. Scaling 
factors are also very common. If data is for example stored in units of 
1/16 feet, the magnitude values will be off by a factor 16 until you 
figure out this scaling factor.

Jef