Related

3.0.1 strips timestamp data from ACTIVE LOGs on eTrexes?

Former Member
Former Member over 15 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?
  • Former Member
    0 Former Member over 15 years ago
    4. Renamed the track, went "Oh crap", let the sync-icon next to the device stop spinning at top left
    5. Selected all ACTIVE LOGs and dragged to a folder under "My Collection"
    6.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.


    If this is the case, it seems that the ACTIVE LOG data was already timestamp free at the time of your dragging the data to your computer, and thereby when you initially plugged in the device, or else the timestamps would have been preserved when dragged.

    If you actually got the dialogs before dragging the data to the computer, then there may have been an additional receive from the unit because of the detected error, but this would likely have been noticeable due to the modal error dialogs and needing to wait for another receive.

    Perhaps your device is dropping timestamps for larger tracks? As an experiment, you could try to record another similarly long (hopefully less important) track and see if there are timestamps on it then. So far as I know there aren't many intentional ways to blast the timestamps in a track besides explicitly clicking "Save" for your active log, but even that should leave your active log intact.
  • Former Member
    0 Former Member over 15 years ago
    If this is the case, it seems that the ACTIVE LOG data was already timestamp free at the time of your dragging the data to your computer, and thereby when you initially plugged in the device, or else the timestamps would have been preserved when dragged.


    I like this theory, but I just checked and I definitely have the timestamps on that first ACTIVE LOG track in the BaseCamp "My Collection" version -- but when I grabbed it via MapSource (after the error, after -- I've been claiming -- they "got stripped"), they were gone. I've been using the tracks that I got from MapSource for distance/elevation/mapping, and had forgotten I'd still had the timestamped first track in BaseCamp.

    I'm kicking myself now, thinking that it's possible that disconnecting the device and then quitting BaseCamp after the error dialogs showed might be what caused the initial cached copies (of which at least the first one still had timestamps) to disappear; if I'd moved slower at that point it might have been possible to get the timestamped versions? (Or does that error state make it impossible to copy the cached device copies into "My Collection"?)

    Perhaps your device is dropping timestamps for larger tracks? As an experiment, you could try to record another similarly long (hopefully less important) track and see if there are timestamps on it then. So far as I know there aren't many intentional ways to blast the timestamps in a track besides explicitly clicking "Save" for your active log, but even that should leave your active log intact.


    I'll see what I can do, in this regard; I think I'm going to have to find another GPS before my hike this weekend, but there's nothing saying I can't carry two.

    Thanks again.
  • Former Member
    0 Former Member over 15 years ago
    I like this theory, but I just checked and I definitely have the timestamps on that first ACTIVE LOG track in the BaseCamp "My Collection" version -- but when I grabbed it via MapSource (after the error, after -- I've been claiming -- they "got stripped"), they were gone. I've been using the tracks that I got from MapSource for distance/elevation/mapping, and had forgotten I'd still had the timestamped first track in BaseCamp.


    Are you saying that the first ACTIVE LOG you dragged off your device does have timestamp data? If that's the case, that indicates that the corruption didn't happen until those error messages displayed. Unfortunately, the re-receive we do upon being notified of a send error would automatically overwrite the cache of that track data. Only dragging the track off before the send which caused this error would have backed up the pre-error track.

    It seems likely that repeatedly resending all of the user data on your device to itself, especially the active log, could make bad things happen. If that's the case, this problem should be addressed in a future release of BaseCamp.
  • Former Member
    0 Former Member over 15 years ago
    Are you saying that the first ACTIVE LOG you dragged off your device does have timestamp data? If that's the case, that indicates that the corruption didn't happen until those error messages displayed. Unfortunately, the re-receive we do upon being notified of a send error would automatically overwrite the cache of that track data. Only dragging the track off before the send which caused this error would have backed up the pre-error track.


    Yes, the first ACTIVE log does have timestamp data. Which I guess means that the ultimate cause (device/software errors notwithstanding) was renaming the track on the device. Which I knew was a bad idea due to the "save track" stripping behavior in the device proper, and I usually go out of my way to avoid. Argh.

    Lessons learned:
    • Copy ACTIVE LOGs to "My Collection" before doing ANY editing. I mean, I knew this, I just failed/forgot for a second.
    • There's some sort of (apparently extremely rare) issue that can occur if a communications error happens, but without being able to reproduce it it's tough to say what the "proper" next step is, if any.
    • I need to pick up a GPS with removable memory, so I can (as a ridiculous extreme) dd off the entire contents of super-important hikes for a backup. Less extreme, just getting the raw GPXes after mounting the SD card without the device would usually be sufficient; and then I can use BaseCamp as a library tool.


    It seems likely that repeatedly resending all of the user data on your device to itself, especially the active log, could make bad things happen. If that's the case, this problem should be addressed in a future release of BaseCamp.


    That's good to hear, thanks.
  • Former Member
    0 Former Member over 15 years ago
    Under the hood in BaseCamp, renaming your active log actually just sends a copy of that track with a different name to your device, so it generally shouldn't affect the current active log. However, the renamed track will be taken as a "saved" track, as you guessed.

    I believe the error that you were notified of is the underlying cause of this problem. While it certainly is safest to copy tracks you want a permanent copy of to your hard drive (perhaps even duplicating them before editing), we don't want tracks or other data on the device to accidentally get destroyed by user updates/transfers. Please do keep us informed if you're able to reproduce this active log timestamp issue, especially if the next version of BaseCamp doesn't fix this issue for you (I'll bump this thread with a link when the version containing this fix gets released).