On 2015-02-02 19:37, Henrik Brautaset Aronsen wrote:
I have been looking into the estimation of the dive length based on
the dive time in the manifest. The results I get are off by 160 to 320
bytes (or 5-10 samples). I wonder if this is the same on other units
or not. Can you give the attached patch a try, and send back the
logfile from the universal app? (Make sure to run with the -vv option
because I'm interested in the debug lines.)
Sorry for the slow reply.
No need to apologize. (I'm also not always as responsive as I would like
to be.)
I ran universal with «./examples/universal
-l petrel.log -d petrel.xml -vv -n "Shearwater Petrel"
/dev/tty.Petrel-SerialPort»
Get the results from:
https://www.dropbox.com/s/1b8pihvn7vrt0c3/petrel.xml?dl=0
https://www.dropbox.com/s/i10d9okw3bgz5mn/petrel.log?dl=0
I ctrl-c'ed after about 110 dives, hope that's ok.
It seems the estimated size is off by 64 to 832 bytes (or 2-26 samples).
That's a bit worse than the numbers I got. I wonder where those extra
samples come from. One possibility is that the divetime does not include
shallow samples. If that's true, then it might be impossible to find an
upper bound.
Ideally, we want an upper bound for the estimated size. If the actual
size is larger than our estimated size (underestimation), the progress
will exceed 100%. That's certainly not good. We can always force the
current progress to stay below our estimated value to avoid this
problem. But the downside is that doing that will "freeze" the progress
at 100% although there is still data being transferred. With an
overestimation, the progress may not reach 100%, but that's fine.
Jef
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
