Mini 2 Tracking Issues

Not sure about this. If the device was going to do this, it would have to be sure to stamp the derived "sent point" with the time from the detail activity point that it used as the source. And this could not be used at all when trying to get the location for a message. The message MUST be stamped with the location at which it was generated. Point being that SAR has to be able to depend on these locations and their timestamps.

twolpert  - Thanks again for all the thoughts and discussion. It's very helpful and I appreciate you taking the time to respond.

All points, activity and trackpoint, are timestamped with the actual time the GPS reading was taken.  I assume they are based on the same clock so that shouldn't be an issue. You can actually see the activity point timestamps when you convert to track. The timestamps on both tracks correspond perfectly.  The only other issue would be if the lat/long are synthesized in some way using compass, accelerometer (if there is one), and interpolation between actual GPS readings.  All signs seem to indicate they are true GPS readings as they appear to be far too accurate (including say a lane change in car), to be anything else.  But even if it was a simple curve fit between known points/readings, it would still be highly accurate, and the device could still use a threshold (within some time/distance range of LKG GPS reading) to adhere to any SAR requirements. 

The issue is if an Activity Point is truly a trusted point.  I think it is. In all cases it seems to be equal if not more accurate, because the it's easier to see anomalies/outliers with more points that could be uploaded.  There are plenty of outliers with trackpoints only, so the more data gaps that are filled, the better.

JimSa said:

At the risk of sounding like I am ranting, here is another braindead thing about the M2...  If it can't acquire GPS at the moment the tracking interval expires and the Iridium stack wakes up, it just skips that tracking point.

While I *can* confirm the issue you've described in your OP (activity "track" ending up to 10 minutes earlier than the tracking point track), I've used both M1 and M2 and found that the M2 was significantly better and quicker in acquiring a GNSS fix. As in: the M1 could take more than 10 minutes sometimes, especially when moving, but the M2 would always report my position accurately in (a lot) less than 30 seconds.

Are you sure the EPO file is present on the device and  that it's not expired?

I don't recall if M1 uses EPO or not. If it does not, and if the onboard almanac is outdated, longer acquisition times are to be expected. Whether the device uses EPO or not, it will acquire a full almanac eventually. However, it takes longer to DO this when moving.

I checked my EPO and it shows as current.  However, the M2 has received two updates over the past several days.  So I suppose it's possible the EPO was out of date. 

I'll run another test today.  If I get the same result, I'm giving up and returning the M2.  I was really hopeful for this device, but in IMHO it is a step backwards in terms of customer value.  The only positives are the easy to use UI and the size/weight reduction, but the loss in functionality and reliability is simply not worth it.  It really seems like Garmin went with form over function on the M2, focusing on migration to common a OS/stack for future engineering efficiency.  That might be good for Garmin, but in my opinion they have failed to provide any incremental customer value, with some significant regressions.

BTW - It's only been a day, but I got crickets from the Garmin support Contact Us form submission.  Does anyone have a support link that will generate an actual ticket number and viewable ticket activity log?  I am worried my existing contact went into a black hole and I'm just waiting on an email response that may never come...

Adding on for anyone that reads this thread in future that might be curious. Today's M2 test was successful. On a 7.3 mile loop, the two tracks (high detail activity and mapshare trackpoints) started and terminated where I expected. I did the test in optimal conditions with clear lines of sight and I gave the device a couple minutes at the start and end of the route. I'm not sure if the recent update helped or if it was just because of optimal conditions. The resultant high detail track had 523 points, which again seemed very excessive.  Battery utilization was about 5% per hour with High Activity Detail, Tracking Interval of 10 mins, Backlight 0%, and GPS Only mode (not GNSS), and no messages being sent.

As I expected, the 523 point Activity Track cannot be converted to an editable route on explore.garmin.com in the map view.  This is part of the problem of not allowing the user to set the M2 logging interval. While the the conversion to route does seem to shape the route to the 200 point limit, which *should* make it editable, that limit is really just an estimate.  I have had routes with 210 points that are editable, and I have sent Garmin examples of routes with 174 points that aren't editable on explore.garmin.com.  Garmin has done nothing to address the 200 point limit or the website bug where it isn't always 200. So if you convert tracks to routes and edit them on the website, this is case where the M2 limitation of not being able to control the logging interval is running you headlong into another garmin bug.  You will need to go through the extra steps of exporting and editing in something like basecamp to create routes.

No such function for opening a ticket. If given the option, use chat or phone - NOT email. Based on forum feedback, email is something of a black hole.

Nobody (except maybe the Garmin engineers) understands the reason for the 200 point limit for a route. Nobody.

I followed up on ticket that I submitted well over a year ago about the 200 point limit, and how their own software doesn't size to an editable route that is 200 points.  I mean it will size to 200 points, but it's often still not editable. I even narrowed it down to two test cases with a single point difference, where one GPX demonstrated the bug and the other didn't. The support teams responded to me today and said there are no plans to fix the website issues.  So Garmin issues, and an unwillingness to fix them, continue to compound on one another, degrading the overall customer experience.