GPS positions with companion app

[Miika Turkia]

On Fri, Jun 26, 2015 at 5:09 PM, Miika Turkia <miika.turkia at gmail.com> wrote:
> On Thu, Jun 25, 2015 at 1:50 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>> On Wed, Jun 24, 2015 at 09:12:46PM -0700, Dirk Hohndel wrote:
>>> On Thu, Jun 25, 2015 at 07:21:53AM +0800, Miika Turkia wrote:
>>> > I have tested out the GPS coordinates a bit with companion app. As I
>>> > am lazy, I rather set it to automatic tracking in the morning and
>>> > forget about it. However, this ends up getting me wrong coordinates.
>>>
>>> That's how I always use it. But I haven't been on a boat dive since all
>>> the changes to the dive site handling, so it's entirely possible that this
>>> is currently broken in creative ways :-(
>>>
>>> > Currently we drive to a buyu line and tie the boat there for the
>>> > duration of the dive. Thus an option to grab the position after the
>>> > dive starts would be perfect for these dives. (Now I usually get the
>>> > position while still on the way to the dive site.) Of course this mode
>>> > does not work for drift diving, but that is why I suggest this kind of
>>> > an option for the new and shiny GPS import Linus envisioned.
>>>
>>> The way it SHOULD work is that if it has a fix during the dive, it takes
>>> the first such fix. If not, it tries to find a fix before or after.
>>>
>>> I can stare at the code a bit to see if I see a problem, or I can add some
>>> verbose debugging option that allows us to see which fixes it picks and
>>> why.
>>
>> I did stare at the code and the more I did so the less the code made
>> sense. So I did the obvious thing and rewrote it :-) ... and added a TON
>> of debugging statements. This was pushed to master and daily builds have
>> been triggered.
>
> Well, I just got a segmentation fault, but when running under gdb, all
> went fine.
>
> ---8<---
> processing gpsfix @ "Fri Jun 26, 2015 2:05 PM" which is withing six
> hours of dive from "Fri Jun 26, 2015 2:14 PM" until "Fri Jun 26, 2015
> 3:31 PM"
> look at the next gps fix @ "Fri Jun 26, 2015 2:08 PM"
> which is closer to the start of the dive, do continue with that
> processing gpsfix @ "Fri Jun 26, 2015 2:08 PM" which is withing six
> hours of dive from "Fri Jun 26, 2015 2:14 PM" until "Fri Jun 26, 2015
> 3:31 PM"
> look at the next gps fix @ "Fri Jun 26, 2015 3:38 PM"
> pick the one before as it's closer to the start
> Segmentation fault
> ---8<---
>
>> Miika, I would love it if you could try this (but I understand if you
>> don't have the time or network bandwidth to do so). I think the debug
>> messages are verbose enough to make it easy to track down what happened
>> and why the fixes are chosen.
>
> I think I got correct locations today. I'll try to test this a bit
> more, purely for the benefit of all :D

I think this is related to downloading new dives from DC and getting
the GPS positions. It occurred again after I had just downloaded the
day's dives, while syncing GPS coordinates. I hope I can catch this on
gdb tomorrow, otherwise I might have to start backtracking the log
file and downloading again from DC...

>> Now I need to add another piece of UI that allows us to import GPX files
>> in the desktop app... we can do so in the Android app but if someone has a
>> GPX file from some device we should just offer to read those and use the
>> same synch algorithm...
>
> poor you :D
>
> It feels like Subsurface is quite slow to start up nowadays. I wonder
> if this is related to my lightening fast (read incredibly slow)
> Internet connection.
>
> Also the IOS companion app is very slow to realize there is no
> Internet connectivity when I am attempting to start logging.
> (Workaround: quit and open up the app to trick it to notice syncing is
> not going to happen.)

Do you have a pointer where to report this one? If you do not have
that handy, I can always dig it out myself later.

miika