3.0.1 strips timestamp data from ACTIVE LOGs on eTrexes?

Former Member over 14 years ago

Does BaseCamp 3.0.1 for Mac modify (or rather, filter or strip) data within a device when performing certain operations?

I recently returned home from a multi-day trip to the Grand Canyon, where I used my eTrex Legend H exclusively. I kept the active log running the entire time, which probably generated between ten and fifteen numbered ACTIVE LOG tracks when all was said and done; I also placed about a half-dozen waypoints, including one that was averaged from about 300 samples (getting coordinates at the bottom of a canyon can be tricky!).

When I got home, I launched BaseCamp on my Mac and connected the device. My typical workflow when returning from a hike or trip is to copy all of the ACTIVE LOGs to my hard drive, and then reorganize/rename/join/etc the hard drive tracks as necessary.

This time around, I accidentally renamed the first track on the device itself. The sync-arrows-circle icon spun as it updated the device, and I was relieved to see that it seemed to complete successfully (and I still had the date/time info for that track). I then tried to copy all thirteen-ish tracks (including the renamed one) to my hard drive.

Sometime while the transfer was taking place, a message about "an error communicating with the device" showed up. The sync arrows kept spinning. I left it alone for about ten minutes after dismissing the dialog, and the sync arrows never stopped. At that point, I disconnected and reconnected the device. The error popped up almost immediately again; so I restarted BaseCamp and reconnected the device.

This time, there was no error -- but there was an explosion of ACTIVE LOG tracks. I had nearly forty of them now, and none of them except the last two -- each of which was a single point, located on my living room couch where this was all taking place -- had any date data. It was as if the date and time had been stripped from all of the previous ACTIVE LOG tracks, and they had been duplicated and triplicated on the device itself.

I immediately shut down BaseCamp, and used a Windows VM to launch MapSource. I did a full "receive from device" and verified that the bizarre behavior I had seen in BaseCamp was a result of data (now) on the device.

I should note that the trackpoint positions themselves appear to be correct; it's just that I need data beyond the lat, long, and elevation. Over the course of my week in the Grand Canyon, I took over 600 pictures. Now that BaseCamp appears to have corrupted or filtered the timestamps from everything in my ACTIVE LOGs, I'm either going to have to geotag the photos manually or simply leave them un-geotagged.

I'm very, very disappointed in BaseCamp apparently performing some sort of destructive update on my device without -- at the very least -- popping up a dialog saying "We're about to modify data on your GPS; Do you wish to continue?"

I think I know the answer, but I'll ask anyway: Given that neither BaseCamp for Mac nor MapSource for Windows (nor GPSBabel for Mac) see timestamp information on my trackpoints, is there any possibility that the timestamp data can be recovered?

0 Former Member over 14 years ago

Anyone? Is there any way to tell BaseCamp to never update existing data on the device, or to change the truncate-data behavior that the eTrex series seems to have when hitting "save track"? It sure seems to me that what happened is that BaseCamp somehow caused the device to "save track" when I mistakenly changed the name (and then it didn't finish updating before the error? Can a large amount of data cause a communications error?)...

Given that the eTrex "save track" bug has been around for years, I doubt that's going to be fixed anytime soon; but is there any way to get BaseCamp to avoid tripping that particular bug and wiping out all my timestamps?

The loss of the timestamps is extremely frustrating -- as a result, I can't geotag the 648 pictures I took; I can't get accurate data about my speed or time on the trail (I've been tracking the hours I've spent on the trail this year, attempting to meet a personal goal); the information that I keep on TrailGuru.com now has holes in it, and (due to the geotagging issue) I'm unlikely to be able to post the tracks to EveryTrail.com, where I keep family and friends (some of whom were on the trip) updated and informed on my outdoor activities and personal goals. This is a big deal to me.

I'd like to hear if anyone at Garmin has any theories as to what happened, or how to avoid it happening again (I won't be using Garmin BaseCamp 3.0.1 for Mac again, especially not on once-in-a-lifetime trips like this), or -- even better -- how I might be able to recover the lost timestamp data. I haven't turned the GPS on since I last attempted to download the data; I don't intend to turn it on again until I get some resolution on this problem, just in case it can be recovered.

In the meantime, I think I'm going to have to start looking for a new GPS (I'm going hiking on Memorial Day!) Does anyone know if Delorme or Magellan GPSes truncate data when you save tracks?

0 Former Member over 14 years ago

I'm not sure about that model of GPS but I have a Vista HCx and have the unit set to log my tracks to the microSD card and all the data is there in BaseCamp without any modification whatsoever. Time/date stamps are all there in the raw data in BaseCamp, letting me geotag photos etc...

0 Former Member over 14 years ago

I'm not sure about that model of GPS but I have a Vista HCx and have the unit set to log my tracks to the microSD card and all the data is there in BaseCamp without any modification whatsoever. Time/date stamps are all there in the raw data in BaseCamp, letting me geotag photos etc...

Yeah, it's obviously something that happens in rather specific circumstances -- this is the first time I've had it happen; it's also the first time I've tried to pull a trip of significant length (grand total worked out to about 40 miles across 13 ACTIVE LOGs, probably about 10k track points) from the device with BaseCamp. Dayhikes in the 10-20 mile range and one-night overnights in the 20-30 mile range with no more than five ACTIVE LOGs are my typical transfers; they've all worked fine before (a little over one per week since the software's release).

Unfortunately, this one loss -- for the reasons I listed above -- make me extremely wary of using BaseCamp for Mac (and specifically version 3.0.1) again. Losing the timestamps due to what currently appears to be BaseCamp attempting to reorganize the data on the device is a catastrophic error for me.

I'd love to hear from the Garmin folks over whether this is indeed a BaseCamp issue, or something the eTrex did on its own for some reason (and how to keep it from doing so, in either case), etc etc. The lack of acknowledgment is now becoming a secondary source of frustration.

0 azdrmn over 14 years ago

We don't have an answer for you yet. We are looking into what caused your issue and how to prevent it.

0 Former Member over 14 years ago

We don't have an answer for you yet. We are looking into what caused your issue and how to prevent it.

I'd be more than happy to send the GPS somewhere if it would help with the forensics.

0 Former Member over 14 years ago

I've been looking into this behavior, and I can reproduce the following:

Every time I edit data on the eTrex, we happily resend the tracks to the device. This is expected, although slower than would be ideal. The unexpected behavior is that the eTrex will happily append this track to the existing Active Log, resulting in Active Log 002, 003, etc., but it does leave the time stamps intact, so it's merely producing duplicates of correctly timestamped data, not corrupting anything.

Renaming an Active Log on the eTrex will result in a copy of that track being sent to the device with a different name, and that copy will not have any date information. Upon remounting the device, though, the original Active Log and its date information is still the same.

In short: I'm seeing the Active Log explosion, and I see how new tracks without time stamp data could be created, but am not able to reproduce timestamp data being removed from existing Active Logs.

Have you tried disconnecting/reconnecting your device and checking for the original active log? Are you sure your device is up to date? You can run WebUpdater to check this. We have ideas as to what the root cause of your issue could be and plan to address it in a future release, but I'd much prefer being able to reproduce your behavior exactly before attempting to fix it.

Since your device doesn't support microSD cards like COGGINSUSA's, there's unfortunately no workaround for this in any version of BaseCamp that supports drag/drop transfer (i.e. you can select devices and directly view the data on them in BaseCamp).

[EDIT:Further behavior that I've seen on a GPSmap 60C is that the timestamp information will be missing from the new duplicates of Active Log data, but not from the original Active Log. EX: ACTIVE LOG 001 still has timestamp data, but ACTIVE LOG 010 - ACTIVE LOG 200 that have been created by this "Active Log explosion" behavior you described do not have time stamps. While this device isn't an eTrex, perhaps this is closer to the behavior on your Vista H? Have you checked the original ACTIVE LOG 001 for timestamp data again? There could be many, many duplicates of that exact same track that are missing timestamp data right on top of it.]

0 Former Member over 14 years ago

Hi Paxter; thanks for the detailed response. I appreciate it. The explanation of how duplicate tracks end up on the device makes sense.

Have you tried disconnecting/reconnecting your device and checking for the original active log? Are you sure your device is up to date? You can run WebUpdater to check this. We have ideas as to what the root cause of your issue could be and plan to address it in a future release, but I'd much prefer being able to reproduce your behavior exactly before attempting to fix it.

After getting this response, I *ahem* borrowed a PC laptop from work today and installed BaseCamp on it, to make sure there wasn't something funky going on with my personal laptop. With a fresh BaseCamp install and the device having been turned off since Monday, I saw the same behavior as before -- there are now 42 ACTIVE LOGs, and all but the ones from my couch are missing time stamps. Additionally, there's a named track with the first 13 characters of the name I gave the first track: "2010-05-19 Gr" (from something ridiculous like "2010-05-19 Grand Canyon: Rim Trail from Bright Angel Lodge to Maricopa Point". Buffer overflow possibility?)

I updated my device about six weeks ago, IIRC. WebUpdater for Windows (also a fresh install) repeatedly informed me that "there was an error connecting to the Internet", which was of course a bit sketchy since I had just downloaded it from the same Internet a minute earlier, and pings to other sites weren't showing any problems. I'll chalk it up to a server down and try again tomorrow.

I'm guessing at this point it was a fluke related to the connection dropping out (and producing the "error communicating with the device"); I don't think it would've been related to power to the USB port, since the laptop was plugged into the wall when it happened. I'm also fairly certain the USB cable I was using is just fine, since I've been using and continue to use it for a photo transfer cable without problem.

I'd offer to create a few tracks and start unplugging the cable just after starting data transfers to see if I can reproduce it that way, but I'm still holding out hope that avoiding using it much might result in getting the timestamps back (yeah, I know, it's an extreme long shot).

The offer to mail it somewhere to help with forensics still stands; sounds like it might not be particularly useful for you guys to have the device in-hand anyway, though.

0 Former Member over 14 years ago

Have you tried reinstalling the firmware update?

0 Former Member over 14 years ago

Unfortunately, BaseCamp is displaying the timestamp data it's receiving from the device, so once it's displayed without timestamp data in BaseCamp, your eTrex is not likely to regain that track timestamp data. You could certainly try receiving tracks from the device in MapSource or RoadTrip (both apps that do not support "sync" devices or display connected devices in the left sidebar) to see if the tracks differ there, but I doubt that being the case.

Obviously this track resending issue makes the data on your device far more volatile than we'd like, but as a general rule it's best to save any data you want to be preserved for the long term to your hard drive by dragging it to My Collection.

To clarify, when did this "an error communicating to the device" message show up? We only receive from device once at startup, and following failed sends; any future transfers from the device just copy data from the already-received data displayed in the app. It's most likely that the source of this error was actually sent data of some sort.

0 Former Member over 14 years ago

You could certainly try receiving tracks from the device in MapSource or RoadTrip (both apps that do not support "sync" devices or display connected devices in the left sidebar) to see if the tracks differ there, but I doubt that being the case.

Yeah, I tried MapSource in a Windows VM immediately after the problems showed up; no luck there. Also tried GPS Babel with the same results; that's when I headed over here. Ah well.

To clarify, when did this "an error communicating to the device" message show up? We only receive from device once at startup, and following failed sends; any future transfers from the device just copy data from the already-received data displayed in the app. It's most likely that the source of this error was actually sent data of some sort.

My best recollection:

Connected the device, powered on, launched BaseCamp
Clicked on my device, the Legend H, at the top-left
Clicked on the first ACTIVE LOG track on the bottom-left, verified it was one of my "hikes" (actually a Rim Trail walk, but whatever)
Renamed the track, went "Oh crap", let the sync-icon next to the device stop spinning at top left
Selected all ACTIVE LOGs and dragged to a folder under "My Collection"
Got the error, cleared the dialog, immediately got the error again (without doing anything?), cleared the dialog, let the laptop and device sit for ten minutes hoping the sync-arrows would stop spinning.
Disconnected the device after ten minutes of incomplete sync
Reconnected the device, got the error again, cleared the dialog, shut down BaseCamp and the device
Re-plugged, launched, powered, and saw the missing timestamps.

Unfortunately, my memory isn't perfectly clear on steps 4-6 above. It's possible that the error occurred while it was syncing the rename, but I don't think that's the case. It's also possible that the error happened after the first rename but while I was examining other ACTIVE LOG tracks by clicking on each one and selecting "show on map" instead of going straight to transferring them all.

If I understand your comment about sends, though, the sequence of events from the device's perspective would've been:

Powered on and connected, BaseCamp launched, full read (from device to laptop)
Track rename on laptop causes write to device
... there is no #3.

So either something really wacky happened in #2, or this might be an issue internal to my device? Should I bring this up in a different forum?

I distinctly remember getting two error dialogs in quick succession -- is it possible that I could've hit a failed send for #2 (thus a re-send or re-read), then tried to copy everything (triggering a rogue send or starting from an incomplete read), then when I reconnected it "succeeded" to send the incompletely-read data back to the device (er, for all ACTIVE LOGs) but reported it as an error?

(Sounds like a reach to me too.)