[PATCH] Parse erroneous sample time for MK6

[Miika Turkia]

I got a confirmation that this is a bug in an old version of their
download tool. Should be fixed by a firmware update and updated PC
tool. I am still verifying some details before sending a new patch
according to the vendors suggestion. (A bit less accurate than my
current one, but probably more robust with bug variants I have not yet
seen.)

miika

On Sat, Aug 15, 2015 at 9:42 PM, Willem Ferguson
<willemferguson at zoology.up.ac.za> wrote:
> On 15/08/2015 13:57, Dirk Hohndel 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"?
>>
>> /D
>
> Miika,
> We need to consider the possibility that this not a bug, but a feature we
> have not come across yet. I say this because there are also now data codes
> 42 and 43 in the log, not seen before during code development. I will see if
> I can make contact with Søren Reinke who did most of the decoding of
> Poseidon. I suspect this is a software upgrade to also make provision for
> the Poseidon Se7en. It would be very helpful if Subsurface writes to stdout
> to indicate totally invalid time data in the file, possibly with line
> numbers in the log file.
> Kind regards,
> willem
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface