Jump to content

Garmin Oregon - odd behavior


Recommended Posts

This does not happen often, but it is rather irritating when it does. Anyone else encountered it?

 

Mine's a year old, Oregon 300. Latest firmware, but it happened with earlier firmware as well. Upload about 1900 geocaches into it, with up to 6 logs each. I use the Colorado / Oregon macro in GSAK to load it. Caches are loaded into main memory, not the microSD card. Everything goes into one gigantic GPX. No additional waypoints.

 

When coming up for the first time after a new GPX, it takes a long time as it is reading in the file. However, about once out of every 5 times, it will just freeze and never complete loading. I need to remove the batteries in order to reboot it. And when it boots up the second time, it would have stopped reading somewhere in the GPX, meaning some caches are not loaded.

 

If I connect it to the computer again, and either "touch" the file or load in the exact same file, it would come up just fine.

 

My workaround for now is to make sure it will come up immediately after loading in new caches. That way I can fix it immediately if there is a problem.

Edited by Chrysalides
Link to comment

This seems to be a long standing issue with no clear answer. 200's, 300's, 400's and even the newer x50 units are all affected.

 

The two work arounds seem to be, 1st, as you've done, either touch or reload the file, and it will boot just fine the 2nd attempt, or, clear any .gpx files (just caches, not tracks, etc) off the unit and let it boot without any caches, then the next load will work.

 

It seems to boil down to this, if you already have a "larger" file on the unit, and you replace it with another "larger" file, the unit will hang on the first boot after loading the newer file. From my testing, it seems that both conditions have to exist. I've seen the unit hang after loading smaller files when a larger file was already on the unit, but have never seen a large file hang it if the unit was cleared first. I've also never seen it hang twice in a row after reloading or touching the new file.

 

There seems to be speculation that this is a gsak issue, BUT, it has been confirmed to happen with two pq's loaded directly to the unit.

 

There doesn't seem to be much difference between different versions of firmware (although the earliest versions of the firmware didn't seem to be able to recover at all without clearing the file first).

 

"Larger" seems to be anything much over 8 to 10 meg. Testing by other users varies on both ends of this.

 

A file with 1900 caches and 6 logs will be in the ballpark range of 11 or 12meg.

Link to comment

FWIW -- I regularly load a PQ of about 3300 on my 450, created and massaged by GSAK, total size of the .gpx around 15.5MB. Mine always "hangs" about half way through, but then continues on after a bit (perhaps 30 seconds or so of delay). Have never had a condition where I had to pull batteries or employ any other heroic measures to get it to continue.

Link to comment

I saw the "hang" issue back when I still had my Colorado 300. At first, I thought it was related to the fact that I work on a Mac (even though it is running Windows natively via Boot Camp part of the time this happens). The problem persisted through my upgrading to an Oregon 400.

 

The one thing that always seemed to work in my favor was that I prefer to load my GPX files on the SD card, so in a worst case scenario, I can pull the SD card, boot the device, then replace the card and startup a second time and it works properly. I generally emulate the same by deleting the GPX files from the SD card, startup the GPSr, clear track logs, etc. then reconnect to the computer and load new GPS files. In loading my geocaches from the SD card, I see that it generally takes about 60-85 seconds to load on the first startup, but following that, it is much faster (half that long or even faster).

 

When this has happened, I have waited 10-15 minutes, and the screen never changed. When it hangs in this case, I am forced to pull the batteries to turn it off, the power switch will not work.

Link to comment

same problem here, oregon 450 with all firmware versions. i don't use GSAK, so that can't be the problem. i do process the GPXs via some scripts though, but i've had the unit freeze on me with vanilla PQ GPX files as well.

 

currently my GPX files are about 8 MB big at most, mostly smaller (around the 6 MB mark). i don't think it depends on the number of files or their size, as i've varied that over time (one big large file vs. many small ones) without any improvement. i think the number of caches and/or waypoints is the only thing that's significant. if i only keep loading about 2000-3000 caches, i'm having no problems at all.

 

crashes vary, sometimes it's still possible to turn the unit off, other times i have to take the batteries out. i've even had it crash on my after only deleting GPX files. that is, i've had a few thousand caches loaded, deleted those GPX files and didn't put any new ones on. on the next boot, the oregon deleted the caches from those files and never finished doing so.

Edited by dfx
Link to comment

Ever since Garmin added the progress monitor I haven't seen this issue. It used to happen relatively frequently on my x00 and x50 (maybe one in five downloads).

 

One thing that worked for some is to completely delete all geocaching gpx files in Garmin\GPX, reboot once, reconnect and download the new gpx file.

 

I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting). In the even the unit hangs during a gpx load you should ALWAYS delete all gpx files, reboot once, and then reload. Repeat as necessary until you get a clean sequence. I've seen too many cases where people thought the unit was okay after a hung load and then got into the field with a partial or corrupted load of geocaches (myself included).

Link to comment
I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting). In the even the unit hangs during a gpx load you should ALWAYS delete all gpx files, reboot once, and then reload. Repeat as necessary until you get a clean sequence. I've seen too many cases where people thought the unit was okay after a hung load and then got into the field with a partial or corrupted load of geocaches (myself included).

i've always used that technique without any problems. when the number of caches i was loading was anywhere over 4000, the procedure reliably repeated itself, every single time i updated the GPX files: connect oregon, put new GPX files on there (overwriting the old ones), start oregon, wait for the hang, turn it off (or pull batteries as necessary), reconnect it, touch files, start it again and this time it will finish loading. i never had any caches missing nor any corrupted entries this way, as opposed to using it directly after it hung during import without going through the touch/reload procedure, which did get me missing and corrupted entries.

 

of course this isn't a solution, it makes loading and reloading a larger number of caches a major PITA. it's the most annoying and most long standing problem with the firmware, second being the occasional "won't connect up to PC even though plugged in" phenomemon.

Link to comment

I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting).

Garmin tracks the date/time stamp of files upon loading (thus the reason it won't attempt to reload a file by just booting the unit again, their real goal seems to be to optimize boot time). If the file has a new time stamp (i.e. you've "touched" the file), the unit will try to reload it. Although I generally reload the same file again, its not a requirement based on Garmin's logic for deciding if a file needs to be reloaded or not, a new time stamp is all that's required.

 

Since this issue seems to have as much to do with expunging the old file (to repeat, I've never seen it happen when there were no .gpx files on the unit to start with), just forcing a reload of the new file is all that's needed, and Garmin's logic forces this with a simple touch.

 

For those that are unfamiliar, "touch" is a utility that has been around since the beginning on most unix systems, who's only purpose is to update the date/time stamp on a file (and to create a zero byte file if it doesn't already exist). When people refer to "touching" a file, they simply mean to force an update of the time stamp.

Link to comment

Thanks for the responses, guys. I was worried I have a lemon here. I'm not sure if I should feel better or worse about the problem being fairly common :rolleyes:

 

Also thanks for the workarounds. The one about deleting all caches, rebooting, loading caches, rebooting is good to know in case the unit gets stubborn. The SD card workaround is also a good one.

 

Ever since Garmin added the progress monitor

Progress monitor? Is this something in the Beta versions? I haven't seen it?

Same here, haven't seen something like that... and I guess only on the x50 series?

 

dfx : I encountered the "failure by computer to recognize USB device" as well. At first I thought it was just with my desktop at home, but I don't seem to have the problem with any other USB devices except my Nuvi 755 and Oregon. Seems to be much better with recent firmware though. I did notice that it does occasionally take 30 seconds for the device to show up.

Edited by Chrysalides
Link to comment
Progress monitor? Is this something in the Beta versions? I haven't seen it?

Same here, haven't seen something like that... and I guess only on the x50 series?

ah, possibly only the x50 models get that, yeah. it's a green progress bar showing you the progress of the GPX import. i suspect they added it after people were thinking the devices got stuck during boot while importing the GPXs. of course now it's a good indicator showing that they do get stuck occasionally.

 

dfx : I encountered the "failure by computer to recognize USB device" as well. At first I thought it was just with my desktop at home, but I don't seem to have the problem with any other USB devices except my Nuvi 755 and Oregon. Seems to be much better with recent firmware though. I did notice that it does occasionally take 30 seconds for the device to show up.

yeah, i have no problem with waiting a bit until it connects. but sometimes it doesn't connect at all. then sometimes i can get it to connect by unplugging it and replugging it, but other times that doesn't help either. occasionally the unit freezes completely so that i have to pull the batteries again. other times replugging it causes it to go back to showing the "connected" screen, but this time with the brightness turned all the way up, and when i unplug it (it still doesn't connect up) i get the "power lost, shut down now?" screen, however with the buttons unresponsive and the countdown frozen at 30. at this point i always have to pull the batteries, or replug it again to restart the whole cycle, still without getting a connection.

 

the most frustrating part is that this happens absolutely randomly, and i hate it when software does stuff randomly. it's the whole reason why i switched to linux on my desktop.

Link to comment

I absolutely loath adding caches to my Oregon 550t. Its almost guaranteed that it will lock midway.

What a pain this thing is. This problem has been around forever, I dont understand how Garmin has not fixed it yet?

 

Last night I spent almost one hour recovering my 550. What happened is that I was using the save battery option and put a new GPX file in the unit. The files has 4500 caches.

Well, the smart folks of Garmin in their infinite wisdom decided to have the screen turn off during the booting process. Result I found myself with a black screen and no idea what was going on. After 10 minutes I figured that it locked.

I pulled the batteries out and from then on the machine was so messed up that I had to remove the sd card and all the gpx files in the gpx folder for it to start otherwise it would just crash at boot.

Got it to boot and imediately turned off battery saving and did the operation again...

It crashed and finally worked on the second attempt.... <sigh>

Edited by ZeMartelo
Link to comment

I shouldn't even comment...but I'm loudly "knocking on wood" with both hands...I have not experienced this anomaly on either my 450 or 550t. I always deleted loaded .gpx files before loading new one; I don't use GSAK...just copy the PQ .gpx directly to the on-board Garmin/GPX...and I don't ever load more than 1K caches + waypoints. I'll have to keep an eye on this topic.

 

Bill

Link to comment

ah, possibly only the x50 models get that, yeah. it's a green progress bar showing you the progress of the GPX import. i suspect they added it after people were thinking the devices got stuck during boot while importing the GPXs. of course now it's a good indicator showing that they do get stuck occasionally.

 

On the Dakota, Oregon x50 and GPSMAP 62/78 you get a file loading progress "bar" during boot. I just checked my x00 and it doesn't seem to have made it to these devices unfortunately.

Edited by g-o-cashers
Link to comment
On the Dakota, Oregon x50 and GPSMAP 62/78 you get a file loading progress "bar" during boot. I just checked my x00 and it doesn't seem to have made it to these devices unfortunately.

Thanks for checking. *sigh* And now that the x00 is discontinued, unlikely to ever get in. Like the fat arrow on the compass screen, features I'd like to have, but not enough to upgrade to the x50.

 

I'd pay some money for it though. Hey, Garmin, are you listening? How about letting a third party modify the firmware (with an iron clad NDA), sell it, and you collect a royalty?

Link to comment

I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting).

Garmin tracks the date/time stamp of files upon loading (thus the reason it won't attempt to reload a file by just booting the unit again, their real goal seems to be to optimize boot time). If the file has a new time stamp (i.e. you've "touched" the file), the unit will try to reload it. Although I generally reload the same file again, its not a requirement based on Garmin's logic for deciding if a file needs to be reloaded or not, a new time stamp is all that's required.

 

Since this issue seems to have as much to do with expunging the old file (to repeat, I've never seen it happen when there were no .gpx files on the unit to start with), just forcing a reload of the new file is all that's needed, and Garmin's logic forces this with a simple touch.

 

For those that are unfamiliar, "touch" is a utility that has been around since the beginning on most unix systems, who's only purpose is to update the date/time stamp on a file (and to create a zero byte file if it doesn't already exist). When people refer to "touching" a file, they simply mean to force an update of the time stamp.

 

What you describe is exactly how it is supposed to work. I'm saying that I've personally had cases on these devices (and read about others) where touching files or simply doing a battery pull and restarting wasn't enough to clear the corruption (ie. missing or incomplete caches). I had to delete the files (or remove the card if I was smart enough to have the files on SD card), reboot and then reinstall the files. I believe that there are corruption modes in the internal geocaching database which can only be cleared by rebooting the unit with no geocaches loaded.

Link to comment

I have it lock up on my 550t on a regular basis.

 

Today when I was out caching I discovered while I had the caches, I did not have any cache description and it would lock up each time I tried to access the description. I thought I had the caches loaded correctly but did not.

 

With hindsite it would appear that I should be loading my PQs on the card instead of internal memory. If I had the PQs on my card if I would have removed the card, booted up, shut down, replaced the card, it would have reloaded the PQs and fixed the problem.

 

Am I right about this?

Link to comment

.Today when I was out caching I discovered while I had the caches, I did not have any cache description and it would lock up each time I tried to access the description. I thought I had the caches loaded correctly but did not..

The times I've heard about it locking up when you look at the details for a particular cache (assuming it didn't lock up when you first loaded the .gpx files to the unit) have always been traced back to a particular cache, and that cache will consistently cause problems. There may be certain characters that it doesn't like or some other data in the description or something it doesn't like. I don't have any caches in my area (that I know of) that have ever caused this issue, but I've seen it mentioned before and has always come down to a particular cache.

Link to comment

.Today when I was out caching I discovered while I had the caches, I did not have any cache description and it would lock up each time I tried to access the description. I thought I had the caches loaded correctly but did not..

The times I've heard about it locking up when you look at the details for a particular cache (assuming it didn't lock up when you first loaded the .gpx files to the unit) have always been traced back to a particular cache, and that cache will consistently cause problems. There may be certain characters that it doesn't like or some other data in the description or something it doesn't like. I don't have any caches in my area (that I know of) that have ever caused this issue, but I've seen it mentioned before and has always come down to a particular cache.

 

The problem today was an incomplete load. None of the caches had descriptions, logs, or hints. (But I found all three).

Link to comment
One thing that worked for some is to completely delete all geocaching gpx files in Garmin\GPX, reboot once, reconnect and download the new gpx file

 

The key here is "worked for some"

 

I have tried and still use this method on every load and still often get the hang up when I boot my 400T after it's loaded using the GSAK colorado/oregon macro. I haven't tried the touch thingy but it always boots fine after I pull the batteries. I also check various random caches to see that they are loaded correctly and to date they always have been.

Link to comment

Perhaps one reason that my mega loads to the 450 aren't causing any problem is related to something someone suggested, and that I'd just done as a matter of course. GSAK offers a check box to delete all of the *.gpx files on the unit before adding any new ones. In my case, that just means deleting one big *.gpx before replacing it. Like I say, my progress indicator always "hangs" at about 50%, but then picks up again after a bit.

Link to comment
Perhaps one reason that my mega loads to the 450 aren't causing any problem is related to something someone suggested, and that I'd just done as a matter of course. GSAK offers a check box to delete all of the *.gpx files on the unit before adding any new ones. In my case, that just means deleting one big *.gpx before replacing it. Like I say, my progress indicator always "hangs" at about 50%, but then picks up again after a bit.

what's the difference between first deleting the file and then putting a new one, and just overwriting the old file?

 

i get the hang at 50% too, but that's not the terminal crash we're talking about. it can get stuck any time during the process, sometimes the progress bar had barely moved a few pixels when it dies, sometimes it hangs at 50% and never recovers, and sometimes it crashes a few pixels before the end. sometimes it dies and then the "can't find satellites" screen comes up, and when i hit "no" it goes back to the frozen progress bar. sometimes that screen pops up and then the unit is already frozen solid so that i can't even push the button any more. then (after poweroff/battery pull) i do exactly the same thing again and it works just fine. ain't making no sense dude!

 

currently my GPXs hold 3009 caches and 3779 waypoints (incl the caches) total. it seems to work just fine with that number of caches/waypoints. guesstimating i'd say the problems start for me when i'm loading and updating 3500+ caches and their waypoints. the more they are, the worse it gets.

 

and from my gut feeling i'd have to say that the "not connecting to PC" problems also start and get worse once the number of loaded caches exceed the magic limit and the GPX loading problems start too.

 

PS: just updated again, and yep, worked fine. i know that once i add one or two more PQs to the bunch, the import will start dying again.

Edited by dfx
Link to comment

what's the difference between first deleting the file and then putting a new one, and just overwriting the old file?

To my understanding of the OS and file handling, absolutely nothing. I report that only because some have said that if they first delete the old file before adding the new one, it has some positive result. The only possible things that could be different in the delete/add vs. overwrite method are that when deleting, the occupied space is deallocated first. With an overwrite, the new file may be overlaid in the same space. Beats me.

 

i get the hang at 50% too, but that's not the terminal crash we're talking about. it can get stuck any time during the process, sometimes the progress bar had barely moved a few pixels when it dies, sometimes it hangs at 50% and never recovers, and sometimes it crashes a few pixels before the end.
Fortunately, I've never had any of those conditions on my 450 (so far).

 

I ran a load last weekend that pushed me up near 4000, and nothing bad happened -- just took a little bit longer to complete than the usual 3200 or so that I usually load (I added another PQ to the collection in GSAK before loading).

Link to comment
...but it always boots fine after I pull the batteries. I also check various random caches to see that they are loaded correctly and to date they always have been.

I'm not 100% positive, but you may want to check the last cache in your current GSAK filter and sort order when running the macro, and make sure that is loaded.

 

The macro generates the GPX by your current sort order, and the Oregon loads them in sequentially. I've seen partial loads a number of times.

Link to comment
I ran a load last weekend that pushed me up near 4000, and nothing bad happened -- just took a little bit longer to complete than the usual 3200 or so that I usually load (I added another PQ to the collection in GSAK before loading).

try reloading that 4000 wpt file a few times. maybe mark some caches as found before each reload. i'm curious as to what happens.

 

of course it's perfectly possible that caches are always being loaded fine, and that it's actually the regular waypoints which cause the lockups.

Edited by dfx
Link to comment
of course it's perfectly possible that caches are always being loaded fine, and that it's actually the regular waypoints which cause the lockups.

I eliminated that possibility by no longer loading waypoints, only GPX. Still hangs occasionally.

 

I wonder if it is totally random or if there is some pattern behind it. Yesterday I loaded in 1891 geocaches, overwriting. No waypoints. Before disconnecting I deleted current.gpx and geocache_visits.txt. It paused a bit before coming up - not sure if it is longer than the standard loading pause since I don't have the progress bar. But it came up fine. I should start taking notes.

Link to comment

I've had this problem on my 300 as well. What I now try to remember to do is to start the unit up after disconnecting from the PC. If it works OK I'm all set, if not I pull the batteries and reload it. Also had a couple cases of not having all the info for certain caches but haven't figured out the reason for that yet.

Link to comment

updated to 3497 caches / 4331 waypoints, no problems. testing continues.

 

my theory is that it doesn't depend on how many new caches/waypoints are being loaded, but rather on how many are already loaded and will thus be deleted/updated.

Edited by dfx
Link to comment
what's the difference between first deleting the file and then putting a new one, and just overwriting the old file?
To my understanding of the OS and file handling, absolutely nothing. I report that only because some have said that if they first delete the old file before adding the new one, it has some positive result..

The key in deleting the files first is to allow the unit to boot without any caches loaded, without the boot, it makes no difference if you overwrite vs delete and create.

 

Once the unit "reads" the caches, they are stored internally and the .gpx file is never touched again, that is unless the unit detects a difference in the .gpx file upon boot (like a new date, etc).

Link to comment
my theory is that it doesn't depend on how many new caches/waypoints are being loaded, but rather on how many are already loaded and will thus be deleted/updated.

Strogly agree, I believe this is a very strong factor, and is basically proven by the fact that if the unit is booted without any caches, the next load will always boot up without any problems, regardless of size (assuming your not over 2k or 5k caches and 200 files).

Link to comment
The key in deleting the files first is to allow the unit to boot without any caches loaded

unfortunately i've had the oregon die on me during boot after doing exactly this at least once before. i.e. i deleted the files and then booted it up. it never finished booting.

Link to comment
if the unit is booted without any caches, the next load will always boot up without any problems,

 

I've been using this method for some time now and do not agree with the above statement. For me it is "usually" but not "always" as I've had the unit freeze and need the batteries pulled after loading the waypoints. This method is better but not infallible.

Link to comment
does anyone of the affected people use vanilla PQ files? or at least GPXs with geocaches and waypoints seperated into different files?
FWIW, I haven't been loading the waypoints. Probably should, as some parking info is helpful at times, but I usually scout everything in advance. All I'm loading to my 450 is a very large and slightly GSAK massaged (name field tweaked for additional info) version of the *.gpx file without the -wpts.gpx file.

 

Another big (4200) load over the weekend, and no glitches.

Link to comment
I load a gpx file via GSAK then also export a POI file of the same caches as a backup

so does that mean you're mixing caches and waypoints into a single file, and you're seeing the hangs?

 

FWIW, I haven't been loading the waypoints. Probably should, as some parking info is helpful at times, but I usually scout everything in advance. All I'm loading to my 450 is a very large and slightly GSAK massaged (name field tweaked for additional info) version of the *.gpx file without the -wpts.gpx file.

yes, you've mentioned that before. another thread made me realize that the inability to modify loaded caches in any way might be because they wanted to avoid having to rewrite the "extended" GPX files coming from PQs, which is somewhat understandable. now when you start mixing regular waypoints and caches into the same GPX, an edit or deletion of any contained waypoint would cause a rewrite of the whole GPX file. so maybe the firmware just assumes that caches and waypoints are never mixed in a single file and maybe that's where the problems come from.

 

just a wild, untested and probably incorrect idea...

Link to comment

just a wild, untested and probably incorrect idea...

Yes, but a darned interesting one. If I understand, you're postulating that a single *.gpx file that is a mixed bag of *.gpx data for caches and data from the *-wpts.gpx (the combined file generated by something like GSAK) might be part of the issue?

 

Back "in the day" with the eTrex when I felt pretty constrained by a 500 cache count, I didn't even load up the extra waypoints as POI, although that wouldn't have been hard - just didn't know better.

 

I've since grown accustomed to busting down incoming PQs and just loading the cache *.gpx files (not including the -wpts.gpx files). Haven't ever directly loaded the *.zip file with GSAK, either. So the -wpts.gpx files have always been excluded from the *.gpx result.

 

There's certainly no reason I can't have a go at creating that sort of file to see if it breaks anything.

 

Pause...

 

OK - took the most recently built GSAK version of a 6 PQ load and from GSAK, added one of the -wpts.gpx files belonging to one of the PQs. Picked up a couple of dozen waypoints from that.

 

Used the box that says "Clear GPS before sending" as I always do. "Waypoint" type = geocaches as I always do. Disconnected normally. So all normal procedure (for me) apart from the waypoints addition to the *.gpx being sent to the 450.

 

No change. Got stuck at 50% of the load for about 20 seconds, then moved right on to complete the load --- just like always.

 

I'll continue to follow the "adding waypoints" procedure for the next few weeks of loads and see if anything hiccups.

Link to comment
Yes, but a darned interesting one. If I understand, you're postulating that a single *.gpx file that is a mixed bag of *.gpx data for caches and data from the *-wpts.gpx (the combined file generated by something like GSAK) might be part of the issue?

exactly.

the only explanation i could come up with as to why it's not possible to delete or edit loaded geocaches at all on the device itself is that they don't want to rewrite GPX files containing the Groundspeak extensions. for this to hold true, they'd have to presume that geocaches and waypoints are always located in seperate GPX files, as they are in PQs. so maybe this assumption is important during the GPX import phase as well.

 

Used the box that says "Clear GPS before sending" as I always do. "Waypoint" type = geocaches as I always do. Disconnected normally. So all normal procedure (for me) apart from the waypoints addition to the *.gpx being sent to the 450.

 

No change. Got stuck at 50% of the load for about 20 seconds, then moved right on to complete the load --- just like always.

that's the problem with testing this: it doesn't always do it. i haven't had any hangs myself for quite some time now, as the number of caches i'm loading these days is relatively low.

Link to comment

I'm having the same problem on my 62s. I think it's the amount of time it takes to do the load. Like someone else mentioned, replacing a large previous export with another large export takes longer than replacing a small cache load.

 

What I think is that the unit decides to do something in the background while the load is happening which causes the load to fail. I usually have the "Searching for satellites" screen cause it but had the "Chirp detected" screen do it once.

 

With the latest firmware things changed a bit. The searching for satellites screen comes up but sometimes the buttons don't work so I can't clear it. I know the unit is not totally frozen as applying external power pops up a message.

Link to comment

the only explanation i could come up with as to why it's not possible to delete or edit loaded geocaches at all on the device itself is that they don't want to rewrite GPX files containing the Groundspeak extensions. for this to hold true, they'd have to presume that geocaches and waypoints are always located in seperate GPX files, as they are in PQs. so maybe this assumption is important during the GPX import phase as well.

Waypoints are loaded into a private memory region in the unit. If you load a GPX with waypoints on the SD card and pull the card, the caches disappear but the waypoints stay.

 

I don't load waypoints into my unit but still have hanging issues.

Link to comment
Waypoints are loaded into a private memory region in the unit. If you load a GPX with waypoints on the SD card and pull the card, the caches disappear but the waypoints stay.

huh. really? i don't think it should do that, and at least my oregon 450 doesn't. when i delete a GPX containing a waypoint and boot it up, the waypoint gets wiped from the internal memory as well. the same as it does for caches.

Link to comment
Waypoints are loaded into a private memory region in the unit. If you load a GPX with waypoints on the SD card and pull the card, the caches disappear but the waypoints stay.

huh. really? i don't think it should do that, and at least my oregon 450 doesn't. when i delete a GPX containing a waypoint and boot it up, the waypoint gets wiped from the internal memory as well. the same as it does for caches.

 

The x00 and x50 are very different in this respect. Avernar is describing x00 behavior.

 

FYI, I use the GSAK export macro and always convert child waypoints to POIs so I never have a gpx with mixed waypoints and geocaches and I've seen the hang. I have not seen the hang nearly as much since the progress bar has been introduced on the 62/x50.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...