GPSrChive Discussion Forum

And there's a new funny discovery:

When changing data fields, suddenly some developer debug console appeared, saying "No Error Rpts" on yellow background and "# mallocs, # waited, Total wait (ms), Mem. Hndl. Open, % nonvol" and other stuff.
No idea how it happened.

Maaan, this device is...

Solaris wrote: Thu Mar 25, 2021 2:15 am So again: as I explained before and I thought that it is clear already, when I choose to Save a Track in GPSMAP 62, it is logically stored in "Saved Tracks" folder. And that's what I expect.

To archive it, when I don't need direct access to it, I manually choose "Archive" from the menu and then it's being moved to "Archived Tracks" folder. That's all, can't be simpler.

You have to remember that the device can only index a small number of 'saved tracks'. so, eventually, those places all fill up and new tracks have to be saved in the 'Archived' directory.

As I recall, this became a common issue where users were wondering what happened to their saved tracks (they didn't realize they had exceeded the number of 'Favorite tracks') when they were not displayed in the list after saving them. Turns out, they were saved, but not indexed, so they could access them with a PC and USB cable, and they would then have to delete some tracks to make more room on the device. This is when 'Archived Tracks' were born, yet the same problem would still occur, and the user would have to connect via USB and manually move saved tracks to the archive folder, a real pain. So, now, as a further improvement, saved tracks automatically go to the archive folder until the user makes them a favorite! If the favorite list is full, the device will not let you unintentionally 'hide' the track in the 'Favorite tracks' directory, and this resolves fully the issue of 'Disappearing tracks'.

So, not quite as simple an issue as it may seem.

Solaris wrote: Thu Mar 25, 2021 2:17 am And there's a new funny discovery:

When changing data fields, suddenly some developer debug console appeared, saying "No Error Rpts" on yellow background and "# mallocs, # waited, Total wait (ms), Mem. Hndl. Open, % nonvol" and other stuff.
No idea how it happened.

Maaan, this device is...

...is what?

You have unintentionally stumbled across a 'hidden test page' that is documented at:

GPSrChive > GPSMAP 66 > Troubleshooting > Hidden Test Pages.

gpsrchive wrote: Thu Mar 25, 2021 12:32 am I do not expect the addition of a single keystroke to your workflow will cause you much grief or place you in additional danger.

One keystroke or more - it doesn't matter. Adding unnecessary steps to achieve the same result means one thing: a bad design.
I hope that all those who use GPS receivers is hazardous situations also appreciate downgraded accessibility.
Oh, wait! But now they can use Activities instead!

gpsrchive wrote: Thu Mar 25, 2021 3:17 am You have to remember that the device can only index a small number of 'saved tracks'. so, eventually, those places all fill up and new tracks have to be saved in the 'Archived' directory.

The GPSMAP 66 series can store up to 250 saved tracks. I'm not a developer, but if this apparatus is able to to receive and visualize data received from Space, I'm pretty sure it's possible to add a few lines of code checking if the "Saved tracks" folder is full, and then, if it is, to save the file in a different location, accompanied by a notification.
Just a wild guess.

gpsrchive wrote: Thu Mar 25, 2021 3:21 am You have unintentionally stumbled across a 'hidden test page' that is documented at:
GPSrChive > GPSMAP 66 > Troubleshooting > Hidden Test Pages.

Well, the point is, I really don't want to be graced with some debug screen while I'm doing something else. If it happens, well, again, it's a bad design. Or a glitch.

Phew, what a long discussion we have here...

Solaris wrote: Thu Mar 25, 2021 10:46 am

gpsrchive wrote: Thu Mar 25, 2021 12:32 am I do not expect the addition of a single keystroke to your workflow will cause you much grief or place you in additional danger.

One keystroke or more - it doesn't matter. Adding unnecessary steps to achieve the same result means one thing: a bad design.
I hope that all those who use GPS receivers is hazardous situations also appreciate downgraded accessibility.
Oh, wait! But now they can use Activities instead!

I do not understand what activities have to do with keystrokes required to view a track.

As suggested earlier, if you find yourself in a hazardous situation, perhaps waiting until it is safer to view a track would be wiser? The data will still be there.

Solaris wrote: Thu Mar 25, 2021 10:46 am

gpsrchive wrote: Thu Mar 25, 2021 3:17 am You have to remember that the device can only index a small number of 'saved tracks'. so, eventually, those places all fill up and new tracks have to be saved in the 'Archived' directory.

The GPSMAP 66 series can store up to 250 saved tracks. I'm not a developer, but if this apparatus is able to to receive and visualize data received from Space, I'm pretty sure it's possible to add a few lines of code checking if the "Saved tracks" folder is full, and then, if it is, to save the file in a different location, accompanied by a notification.
Just a wild guess.

Apparently the software engineers at Garmin felt it was wiser to always save tracks to the same location, presumably for the sake of consistency. Most people appreciate consistency. I do. You apparently do not.

Solaris wrote: Thu Mar 25, 2021 10:46 am

gpsrchive wrote: Thu Mar 25, 2021 3:21 am You have unintentionally stumbled across a 'hidden test page' that is documented at:
GPSrChive > GPSMAP 66 > Troubleshooting > Hidden Test Pages.

Well, the point is, I really don't want to be graced with some debug screen while I'm doing something else. If it happens, well, again, it's a bad design. Or a glitch.

The exact key-press sequence required to open that service menu will never happen during normal use of the device, that is why it was chosen. There was absolutely no reason for you to perform those key presses on that screen.

This is not a bad design, it is operator error.

Speaking of bad designs, you seem to think just about everything about your GPSMAP 66 is a bad design, and you seem to be very unhappy with it, so I would like to suggest you consider the possibility that Garmin GPSr are not the correct solution for you, and perhaps you should move on to something different.

Solaris wrote: Thu Mar 25, 2021 10:46 am Phew, what a long discussion we have here...

And.... It's over.*


* GPSrChive is not a place for fascistbook drama. Please keep discussions constructive.