I think this is a different problem.

My post was about the revised way SD changes to the next track. It now follows the same logic as Garmin and others.

Your info about MM vs SD GPS tracking relates to the accuracy thresholds set in SD  .. apparently GPS's output something called H DoP re their accuracy. If the level is above the max set by SD, then it stops logging your track and you see a message saying its trying to get a fix. MM just keeps logging.

SD are thinking about whether they should do the same. Since flight logs are quite interesting, I think SD shd do the same.

My experience is that you need to let your GPS run for a long time and it starts to learn which satellites are usually in view and where. The other alternative is to use an external antenna which can be cumbersome unless your GPS has bluetooth. I have a Navigon 8410 that does have BT but does not recognise my BT antenna (cd be unit specific). Also the signal did drop out regularly to start with but as I type, its indoors and has a fix on 5 satellites. Am pretty sure it will not drop out in flight from now on.

Cheers

David

I too have often seen SD Mobile stop tracking the aircraft in flight for periods of time whilst Memory Map, running on the same device at the same time, continues to track the aircraft position well.

Weather no go for flying. But put in a route which wd test new "leg choice" algorithm and it worked just as expected. Very much my preference. As soon as one leg was nearer than another, it changed.

Lets see what others say.

D

Will give it a go at the weekend.

Thanks for taking idea on board. Lets see waht others think.

David

We've switched, tentatively, to this method of determining which is your "current" leg ready for the next beta drop (later today). I would be grateful if people could try it, and let us know what they think. We may keep it if it proves to be better and doesn't inconvenience anyone used to the previous behaviour.

If at the beginning of your trip you're closer to your final return leg, SkyDemon will indeed assume that is the current leg and guide you to your destination rather than first enroute waypoint, but it won't reverse your route.

Thanks for following this up. I like the logic behind it, and it's something we'll play with in a future version of SkyDemon. Interesting idea, automatically reversing your trip, too.

Spoke to tech suppt at garmin who were very helpful. They confirm that the Garmin algorithm re  "current leg" looks for the leg from which you are "least offtrack" and presumes this to be the leg you are flying. AS I said you can therefore fool it by flying close to the anticpated final return leg when you depart (it then inverts the whole plan!).

Similarly they said if you finish somehwere fairly close to your departure point (but not the same point), then this can fool it too. Trick is to invert or reactivate the plan once you are on proper course.

In my view this is a far better logic than that currently used by SD.

Cheers

D

Well sure, couldn't hurt

Glad u r intrigued by Garmin's approach. As I say this is not definitive but my interpretation re what happens in practice.

Wd u like me to contact Garmin support and ask how they do in fact decide?

D

I am intrigued by the Garmin's apparently way of determining which leg of your route you are "trying" to navigate. We'll definitely be giving this some more thought.

jsnr, you're quite right that we do apply some broad filtering to GPS input before passing the values to the navigation instruments. That's not to say that we have any input in signal acquisition or processing, but I can see how it would appear that way. We filter data because unless the chipset has a reasonable confidence that the values are correct, we don't think they are appropriate for aviation navigation.

Here's a rough breakdown of horizontal DoP values, which is what we use:

1-2: Excellent
2-5: Good
5-10: Moderate
10-20: Fair (low confidence level, very rough data)
Over 20: Poor (inaccurate, should be discarded)

At the moment we require a horizontal DoP of better than 15 for GPS data to be passed through to the instruments. We have considered (and are still considering) an option called "Require Precise Data" which could be turned OFF for all data to be passed through. This would result in "quicker" fixes but would always be opt-in.