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