On Sat, Aug 15, 2015 at 2:57 PM, Dirk Hohndel <[email protected]> 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 <[email protected]> >> --- >> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
