[PATCH] Parse erroneous sample time for MK6

[Miika Turkia]

On Sat, Aug 15, 2015 at 2:57 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Wed, Aug 12, 2015 at 06:33:02PM +0300, Miika Turkia wrote:
>> Sometimes MKVI records sample time erroneously and we have to "fix" the
>> time. The 2 samples (from single DC) I have seen suffering this issue
>> can be corrected by subtracting 65528 from the sample time.
>>
>> Fixes #916
>>
>> Signed-off-by: Miika Turkia <miika.turkia at gmail.com>
>> ---
>>  file.c | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/file.c b/file.c
>> index 8522b2e..5afc91c 100644
>> --- a/file.c
>> +++ b/file.c
>> @@ -651,7 +651,14 @@ int parse_txt_file(const char *filename, const char *csv)
>>                       has_setpoint = false;
>>                       has_ndl = false;
>>                       sample = prepare_sample(dc);
>> -                     sample->time.seconds = cur_sampletime;
>> +
>> +                     /*
>> +                      * Sometimes MKVI records sample time erroneously and we have to "fix" the
>> +                      * time. The 2 samples (from single DC) I have seen suffering this issue can
>> +                      * be corrected by subtracting 65528 from the sample time.
>> +                      */
>> +
>> +                     sample->time.seconds = cur_sampletime > 65000 ? cur_sampletime - 65528 : cur_sampletime;
>
> This looks so totally random to me... what happens when you consider these
> as signed numbers. Do they make any sense then? So is the the MKVI somehow
> recording a negative delta to signify "something"?

I cannot really do any real conclusions on this, but it seems that
only the last 3 bits are significant on this case. The two cases I
have seen, first was 1 second into the dive the other was 4 seconds.
So cur_sampletime & 0x7 would give us correct results. I am more
inclined to believing this to be a bug than to indicate some special
circumstance, especially since the MKVI records multiple lines for
each second, each for different data. And they could easily record one
more line with proper type to signify something. I just sent a
question to Poseiden, if they could clarify what is going on...

miika