Garmin software engineers are working on it, but everyone (myself included) are all having a difficult time discerning exactly what steps are causing the ("seemingly random but not") loss of track point time and altitude data.....
If you frequently edit track names and track colors on Basecamp (and send them back to the unit).... I'd bet you have some tracks missing both time and altitude data too, but may not even realize it.
I"m assuming (based on reading other threads) that few users realize/use the swapping view feature. (Control+Tab gets you there easily.)
This provides you with the ability to filter and sort on many different field headers.
BUG: Frequently I notice (on subsequent runs of Basecamp) that some of my edited tracks (which ultimately are returned to my Montana 650) show up missing altitude and time data.
This is not even always apparent when looking at a filtered view without looking at the details. (Sometimes the start time data does show up under the header even though track has been "stripped" of the data, but not always.)
"Double clicking" on the track to see details is what reveals the loss of all time and altitude data for each point in the track.
(This has been happening all too frequently on both old tracks recorded several years ago, and on new tracks recently recorded in GPS with updated/current firmware.)
These tracks were all "read" into Basecamp for editing track colors and names only and then resent to the GPS. (Some of the transferred tracks were archived on the unit when they get "received' into Basecamp for editing.)
When this data is "stripped" two things become obvious (once you know what to look for):
- All individual points within the track are missing this data. ~ Even the headers for time (and altutude I believe) are missing when you look at the details of the track from within Basecamp.
- Removal of this data was "deliberate" in the sense that: All the XML data (looking at the files sent back to the GPS with a text editor like notepad) has been "rewritten" (very neatly and concise), without the extra time & altitude tags embedded in the .GPX files.
- (What doesn't become obvious is exactly when this happens. I never seem to "notice" the stripped data until subsequent sessions with my GPS attached. That's why I'm wondering whether the problem has to do with reading archived tracks off the GPS, editing them in Basecamp, and sending them back multiple times. (When Basecamp "receives", it receives all the tracks, including the archived ones. When it "sends" them back, it returns the track to a "favorite", as opposed to an "archived" track.) ~ This in itself is not good.
Sending should be "smart enough" to return the track to it's "preexisting status." AND during the "Receive" process, "it would be comforting" if Basecamp provided users with the ability to visualize and select (via the directory/location of the data on a GPS unit.) ~ So that only a subset of the data "favorites" (or "archived" data) could be selected individually!
On a related note (GPS firmware):
Basecamp doesn't differentiate between archived and favorite tracks. Therefore, every time the tracks are read into basecamp and sent back to the GPS, "archived tracks" perpetually "re-become favorites" again, over and over and over.
(I have to "re-archive" each one individually, ever time they make a round trip back to the unit.) ~ It sure would be nice to have track color filtering & sorting, track filtering based on startpoint/endpoint distance, track color displayed in lists & "archive all" functionality on the GPS. Similar support exists for waypoints, why not tracks too?
PS: This issue is not exclusive to the Montana series. Another user with an Etrex had posted (along with a screen capture) "evidence" that he has been experience the exact same problem.
https://forums.garmin.com/showthread.php?61663-BaseCamp-the-track-lose-information-like-elevation-and-time&p=226516#post226516
