Montana Odometer Issues

[+A.T.Hiker]

The issue I'm posting is regarding odometer mileage errors on the Montana 650. I'll try to explain as best I can.

 

The Montana will always count mileage traveled to all of the odometers, as it should. However, it also applies the straight line mileage traveled between power cycles, which it should not. For example, I can power up here at home, reset mileage to zero, and power off. I can drive 50 miles, power on again, and will have a trip odometer reading of 50.0 miles within seconds of my power up. As a result, you can get screwed up information like this:

 

Notice the outrageous 200.9 miles in 14 seconds in the first screen, and the second screen, at 1 minute 21 seconds, calculating an average of 8928 mph based on 200.9 miles in 1 minute and 21 seconds. In the unit's "brain", it believes it's traveled 200.9 miles in an instant.

 

Note: I really had traveled 200.9 stright line miles from West Virginia to New Jersey, but the unit was turned off in my backpack. I powered on and reset in New Jersey, and as soon as it acquired the sattelites, that's what I got.

 

It's probably not a big deal to many, but for me, and possibly other distance hikers, I like to accurately track miles and averages over days. It's very cumbersome when the unit behaves in this manner. When it's off, I don't want mileage logged. I wonder if anyone has ever contacted Garmin on this issue? I did a while back, but never recieved a reply, and I see no mention of it anywhere on line except in another topic I posted here a while back. The unit does have the most recent software, I just updated it before the trip.

 

As always I welcome the opinions and feedback, and hope people will hound Garmin a little bit! Thank you.

Edited June 30, 2012 by gpsnavigator2012

[+Atlas Cached]

Sounds similar to Montana wiki Bug 28.

[tr_s]

I've seen a similar thing happen at least once on the eTrex 30 as well, as I noted in a track log. Had it powered up close to home, then hit a commuter train southbound for 40 km, powered up the GPS close to the trail I was gonna walk. Presto, recorded was one straight ~2000 km/h bread crumb in the track log, leading from home to the start of the trail.

[+A.T.Hiker]

Sounds similar to Montana wiki Bug 28.

 

It does. I'm glad it's at least been documented and noted somewhere. Thank you.

[+A.T.Hiker]

I've seen a similar thing happen at least once on the eTrex 30 as well, as I noted in a track log. Had it powered up close to home, then hit a commuter train southbound for 40 km, powered up the GPS close to the trail I was gonna walk. Presto, recorded was one straight ~2000 km/h bread crumb in the track log, leading from home to the start of the trail.

Well, that's the other part of the issue I didn't originally mention. If I don't save and clear track logs after every single hike, they will be a mess of lines connecting my previous ending points to my current starting points. The Oregon behaves this way too, but does not apply these excess track point mileages to the odometer like the Montana does.

 

What I've been doing is section hiking the Appalachian Trail. So I'll drive somewhere, hike 8 miles, end that hike, power down the unit. Then drive 50 miles to another section, power on, hike 10 miles, end, power down the unit, drive another 20 miles, power on, hike 4 miles, etc, etc. You get where this is going. The Montana is a disaster when trying to track mileages, averages, and record tracks over several hikes in different locations without some annoying improvising.

 

It's just odd to me that it functions this way, and that Garmin rolled it off the assembly line like this.

[tr_s]

It's just odd to me that it functions this way, and that Garmin rolled it off the assembly line like this.

 

Heh, feels a bit like the eTrex problems I've been bringing to light. I believe many of the issues encountered are due to data objects and system features not being initialised and used in the right order. Of course, the odometer or track log should upon power up never start updating or adding up before the system has confirmed a stable GPS fix. Straight lines should, in my opinion, only be drawn over stretches with signal loss.

 

Even if garmin by their logic wants to draw straight lines and add up distance between power cycles (dodgy and I'd never implement the feature that way in my wildest dreams: off is off - but I suppose it would be okay, no logic is "right" here, best if configurable), the speed in the track logs should be correct. Having moved 40 kilometers in an hour does not make for 2000 km/h...

Edited July 1, 2012 by tr_s

[MtnHermit]

It's just odd to me that it functions this way, and that Garmin rolled it off the assembly line like this.

You're suffering from an illusion that Garmin actually tests their software, they don't. You're the tester.

 

Since all these units (OR, DK, MT, etc.) have the same basic software, I just found the same defect on my OR 450 and I just reverted from the latest firmware v5.80 to an older v5.50. Time will tell.

[+A.T.Hiker]

It's just odd to me that it functions this way, and that Garmin rolled it off the assembly line like this.

You're suffering from an illusion that Garmin actually tests their software, they don't. You're the tester.

 

Since all these units (OR, DK, MT, etc.) have the same basic software, I just found the same defect on my OR 450 and I just reverted from the latest firmware v5.80 to an older v5.50. Time will tell.

 

It would seem that way. It's overall a good unit, and I like the features, graphics, and configurable options, but something like this is just pizz poor programming or a glaring oversight, or both, and you'd think something like this should be caught earlier.

[+LadyBee4T]

I've seen a similar thing happen at least once on the eTrex 30 as well, as I noted in a track log. Had it powered up close to home, then hit a commuter train southbound for 40 km, powered up the GPS close to the trail I was gonna walk. Presto, recorded was one straight ~2000 km/h bread crumb in the track log, leading from home to the start of the trail.

 

This happens all the time on my montana also

[+A.T.Hiker]

It's just odd to me that it functions this way, and that Garmin rolled it off the assembly line like this.

You're suffering from an illusion that Garmin actually tests their software, they don't. You're the tester.

 

Since all these units (OR, DK, MT, etc.) have the same basic software, I just found the same defect on my OR 450 and I just reverted from the latest firmware v5.80 to an older v5.50. Time will tell.

Indeed, the Oregon is now exhibiting this behavior as well, and I'm pretty confident it was not doing it before upgrading to version 5.80. They must be copying over bad code, and they've probably suceeded in toasting the odometers on all of the new handhelds. Here's more screen shots:

 

Trip log of kayak trip, at the dock, upon conclusion, just prior to powering down:

 

Trip log upon returning home, powering up, and walking a few footsteps. Note the large jump in the odometer reading in just one additional minute of accumulated time. Also affected is the average speed calculation:

 

And finally, an example of the straight line track that another poster mentioned. That track is almost a 26 mile straight line leading from the lake straight back to my home, and instantlly appeared after powering up and acquiring a satelite lock here at home:

 

My conclusion is that the odometer and track log are starting their calculations based on the last ending point, and not the current starting point. I'm not a GPS programming expert, but does it make sense to do it that way?

 

I might try to figure out how to roll back software on the Oregon, and the Montana I'll just live with (the Montana has been doing this since I got it anyway). In the meantime I may also call Garmin this morning and would encourage others troubled by this to do the same.

[MtnHermit]

They must be copying over bad code, and they've probably suceeded in toasting the odometers on all of the new handhelds.

I believe all the modern handhelds and many automotive units are all based on the STM Cartesio chip. It's an all in one wonder chip with the GPS receiver, ARM CPU and GPU on one piece of silicon. To make a finished GPS the manufacture need only add an antenna, 4GB flash memory and battery. Probably a LCD and case would be nice too.

 

Because of this, they all run on the same base software with supersets for touch vs button, barometer chip, etc.

 

My conclusion is that the odometer and track log are starting their calculations based on the last ending point, and not the current starting point. I'm not a GPS programming expert, but does it make sense to do it that way?

Just a simple error in the base code, easy to correct, assuming basic testing to find the problem. Remember, you and I are the testers, not Garmin.

 

I might try to figure out how to roll back software on the Oregon, and the Montana I'll just live with (the Montana has been doing this since I got it anyway).

Incredibly easy. Insert the correct file in the Garmin folder, power up, it'll ask if you want the older version, yes. Done!!!

 

More here

Edited July 3, 2012 by MtnHermit

[+A.T.Hiker]

Anyone had any other experiences / feedback for this since my initial post in July? I spoke to Garmin 3 times in regards to it - still no fix. Still happening, even following every step of track off, clear, archive. The straight line problem is avoidable this way, but the odometer is still piling on the mileage between power cycles on Montana and also add Oregon to the list, but only since the last couple of software updates.