Petrel progress bar problem [was: Re: testing of download from divecomputer needed]

Jef Driesen jef at libdivecomputer.org
Tue Feb 10 01:50:16 PST 2015


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


More information about the subsurface mailing list