binzi

Here's something I'd like to see in a future update next to the possibility of waypoint averaging, Wherigo actually working and spoiler image handling: Different sounds for left and right turns while navigating. This way one wouldn't have to look at the unit at every turn...

I too can confirm the bug where the Garmin crashes when touching the map while navigating somewhere and then returning to the automotive map by pressing that arrow in the lower left corner... Doesn't happen all the time though but still often enough...

For the sake of completeness: I'm back from Florida where my Oregon running 2.86 was amazingly accurate. Back in Germany I was back to the same problems: When searching for a cache the Oregon would lead me to on point and then all of a sudden point me to another spot about 10 to 15 meters away and then to another and so on... Didn't change a thing but my own location. I'm now on 2.93 and will post my experience in that thread...

Hmm interesting thought. Thinking about it, in my case I had the terrible results while I was in Germany. At the moment I'm in Florida and the Oregon works like a charm. It is always spot on. I did another 30 or so caches and in the vast majority I would land exactly on top of the cache. Even if the cache was somewhere in the woods or the mangroves. Even under heavy tree cover I had very good reception and would land right on top of the caches. Btw I didn't get a WAAS signal so I switched the GPS to normal mode. When I'm back to Germany I will do some additional testing and post my results here. I'll give the Oregon plenty of time to build up its almanac and will also give it some time to settle when I arrive at GZ.

First of all sorry for the mess and for warming up an old topic. I guess I was just frustrated of not being able to get all the cache descriptions I wanted... The trip was on very short notice and very spontaneous. I did a caches along the route query and intended to do five queries for the major stops (with about 50 or so caches each). One thing I love about PQs is that you do not need to decide which caches to do beforehand. Unfortunately the last PQ didn't work and this would have been the one for the destination of my trip... Don't get me wrong I really do understand the need for limits on queries to the database. Actually I perfectly understand and agree with the 500 cache limit on each query. However I really don't agree with a limit of 5 queries a day. The reason is that I usually only do a couple of PQs every month, I'd say less than 10 a month on average and for sure far less than 150 queries a month. So I would pretty much be in favor of something like a 150 or 100 PQs per month limit and maybe an x minute between two queries limit. This would give me much more flexibility.

Thanks for your quick replies! @Allanon: Of course I could have planned in advance. However, I don't want to pay for a service that forces me to organize myself better In addition I just decided to go on that trip today, so there actually was no time to plan ahead... @TailGators: Where can I find this button? Do you mean the button that creates a Pocket Query or a button that actually lets me directly download the results of the query as a gpx file. I'm looking for the latter. Creating a new Pocket Query with the same limitations wouldn't improve the problem, I guess...

I just planned a geocaching trip which required me to submit 6 pocket queries. Thus, for the first time I stumbled across the 5 PQ per day limit. I think this limit is ridiculous for someone who is actually paying for that service! I never really understood why I couldn't just simply download a gpx file containing the results of my query. I really like the preview in google maps option as it nicely shows all caches of my PQ on a map. Can't be that hard to add a download button for those caches... So in the end I had to "spider" the remaining caches I needed. So I guess I'm asking geocaching.com to get rid of that 5 PQ per day limit, offer a direct download option or improve the pocket query in another way...

So far I was one of the guys heavily complaining about the accuracy of the Oregon on 2.86. However, in the meantime I took my Oregon on multiple geocaching trips and actually started to love its accuracy as long as I use the unit in the following way: - Make sure that the Oregon has been switched on for at least 15 minutes - Re-calibrate the compass - Once you arrive at the coordinates just wait some time before you trust the Oregon Following these rules my Oregon would precisely stop at the location of the cache in 20 out of 30 cases! In the remaining 10 cases it wasn't that bad either (just a couple of feet away which might of course also have been due to inaccurate coordinates of the cache itself). This is even true under heavy tree cover. I even do get a signal inside the house with the hurricane shutters down. It just seems as you have to give it some time until it is as accurate as it claims it is. So far I haven't checked on the accuracy of my tracklogs. However, I did record a track while I was out kajaking and the recorded track showed a smooth line (again after assuring that the unit was switched on for at least 15 minutes before relying on it). I then recorded a tracklog while driving around in the vicinity and checked that tracklog against openstreetmap. Again, the tracklog was right in the middle of the roads... I didn't change a thing on my unit since I wrote those negative reports about the accuracy of 2.86. I don't have any idea why it seems to be so much better now... Last time I definitely was more impatient when arriving at a cache. Now I slow things down a little and tend to re-calibrate my compass more often. So here's a suggestion to the people at Garmin (in case you are reading this forum): Seems like there are a lot of people in this forum who would be willing to act as voluntary beta testers (I know I would). Why don't you guys just exploit this and coordinate whatever tests you think would be helpful for you. I'd be happy to collect some traces as long as this would help to improve the quality of my unit...

1.) @Hampshire Hog: In your post you said that the screenshots were taken with Oregon 300 v2.6. The latest "stable" release is v2.8 and there are two beta versions: v2.85 beta and v2.86 beta. It would be interesting to see accuracy tests with those versions. 2.) After some more field trips I think that v2.86 beta does see more satellites under heavy tree cover or between buildings than v2.85 beta. However, v2.86 frequently tells me that it is within 2 meters of a waypoint when a couple of seconds later it thinks that the waypoint is 15 to 20 meters away. Unfortunately I don't have any logs to share (yet). 3.) Since v2.86 beta kind of drove me crazy I downgraded to v2.85 beta and definitely have the feeling that the accuracy is way better again. At least the user-perceived accuracy. 4.) Being back on v2.85 beta I unfortunately do experience a problem I already had before with this version: When the screen goes black while routing somewhere and I touch the screen to make it come back again, the screen turns white and stays white until I reset the Oregon. This happens like 1 in 25 times. Did anyone have the same problems with v2.85beta?

Went out geocaching on 2.86 today. The Oregon would show an accuracy of about 2 to 3 meters all the time, even in the city between buildings. However, the actual accuracy was way worse than that and probably didn't change since 2.85. Sometimes the Oregon would claim that I'm within 3 meters of my target when I was standing at two different points which were actually about 10 to 15 meters apart from each other... So I think they probably changed the formula used to calculate accuracy on the Oregon while the actual accuracy stayed the same.

Problem solved! Seems like there was something wrong with the batteries, old nimh 2000 which are definitely dead now! I put in fully charged nimh 2700 and now everything is back to normal! Sorry for the mess...

Some further information: I (currently) keep my geocaches on the internal memory of the Oregon. I tried to start it with and without SD card => no difference.

I'm currently running the 2.85 beta on my Oregon. So far (almost) everythin was really fine. However, since this morning, when I try to start my Oregon it freezes while showing the GARMIN logo. That doesn't give me enough time to do a master reset by pressing the upper left corner... If I press the power button and keep it pressed the unit will show the GARMIN logo as long as I keep the power button pressed down. Once I release the power button, the unit freezes again. Unfortunately I won't be able to connect the Oregon to a PC before Wednesday night. So I 'm kind of stuck at the moment. Yesterday night I was out geocaching and everything went just fine. Last thin I did was to connect the Oregon to my PC, access my field notes using the geocaching website and then disconnect the Oregon. Other than that I didn't transfer any files to or from the Oregon! This morning it would start to freeze as described above. I will reply to this on Wednesday night when I had a chance to connect the Oregon to my PC and do some further analysis. Until then does anyone have any idea what else I could try?

Took my Oregon 300 Firmware 2.8 out for an extensive caching-trip yesterday and can confirm the problems now 1.) When changing from one profile to the other while routing the Oregon would sometimes freeze and had to be power cycled 2.) When changing to my self-created geocaching profile the Oregon would sometimes show the wrong background image. The only thing that helps to get it back to normal behavior again is to power cycle the unit. I also think that it does not correctly remember other settings of my profile. 3.) When trying to access the compass calibration screen by pressing my finger on the compass for a couple of seconds the Oregon would also shut down a couple of times.

Thanks for your comments. I hoped it was me but it turned out that it is actually unecessarily complicated to manage waypoints on the Oregon... Now my best practice is the following: - delete all waypoints on the Oregon - connect the Oregon to a PC - delete those gpx files I no longer need - rename those gpx files I want to keep Still not quite satisfied with this but at least I know how it works now...

Yet another maybe simpler way to describe the problem: - Say I have several gpx files containing waypoints on the Oregon - I also created say 50 waypoints using the mark waypoint function - Now I want to delete those 50 waypoints on the Oregon - Since I don't want to manually delete all 50 waypoints I use the Oregon's reset function to delete all waypoints - If I now reboot the Oregon it will ignore all the waypoints in my gpx files no matter how often I reboot the system. There's no way of undeleting those waypoints in the gpx files or to force the Oregon to reload them. At least not without connecting the Oregon to a PC - when I connect the Oregon to a PC delete the gpx files, reboot the Oregon a couple of times, copy the gpx files back to the Oregon and reboot the Oregon it will at some point actually reload the waypoints from the gpx files into its memory The same problem arises if I want to delete all waypoints from one of the gpx files. Deleting this specific gpx file on the Oregon doesn't change anything on the Oregon since the Oregon keeps the waypoints in its internal memory. Deleting all waypoints on the Oregon puts me back to the problem that it won't reload the waypoints from the gpx files that I still want....

I'm running the latest software 2.6 on my Oregon and in general I know my way around handling waypoints. However, I'm frequently running into the following problems when deleting waypoints using the Oregon built-in delete function: - First I copy a gpx file containing say 100 waypoints to the Oregon - Then I need to delete say about 30 specific waypoints on the Oregon. However, since it takes too much time to do so on the Oregon, I simply delete all waypoints using the Oregon built-in delete function - Then I replace the gpx file on the Oregon by a fresh one containing only those 70 waypoints I still want to be on the Oregon - When I then reboot the Oregon it somehow remembers that I deleted those waypoints and will simply ignore them. - I usually end up renaming the gpx file, rebooting the Oregon several times and at some point it will show the waypoints again... So I guess my question comes down to how you guys handle deleting a large number of waypoints on the Oregon while keeping a large number of waypoints at the same time. I really think it sucks that the Oregon has some kind of internal memory which it uses to store its waypoints and only uses the gpx files put into its gpx folder to read the waypoints into its internal waypoint memory. Confused? So am I Maybe this is another way to describe the problem: When loading some waypoints to the Oregon using a gpx file that I put into the Oregons gpx folder and then deleting those waypoints using the Oregons built-in function, then the Oregon remembers that I deleted those waypoints and will ignore the gpx file in its gpx folder during the next reboots. That is, even though there is a gpx file in its gpx folder it will ignore the waypoints in it. When I want to undelete these waypoints I don't really know what to do. I usually rename or delete or replace the gpx file, reboot the Oregon a couple of times and eventually the waypoints will reappear in the Oregon's internal memory... Still confused? So am I Any comments appreciated.

What software version do you have on your Oregon? The most current version is 2.6. Previous versions showed similar crash behavior when trying to boot the device. However, so far I haven't heard of the problem that the Oregon would start normally but crash when connected to a PC. Usually it would crash in both cases. There a two things that come to mind: - Make sure you are on the most current software http://garminoregon.wikispaces.com/Versions - try to downgrade and upgrade again: http://garminoregon.wikispaces.com/Miscellaneous#toc3

The compass was set to auto mode and I was thus using the electronic compass. Sometimes when I stand still I notice that the electronic compass does not seem to update itself anymore. I then turn the Oregon to see whether the compass updates its direction. If it doesn't I will replace the batteries and it usually starts to update again more frequently. Maybe it doesn't have to do with battery life but with restarting the unit...

I have an Oregon 300 and lately I noticed that the accuracy as well as the update frequency of the compass seems to go down if the battery strength drops below a certain level. Does anyone know whether there actually is a connection between battery life and accuracy/update frequency of the compass? I am using relatively new NIMH 2700 rechargeable batteries. As long as they are fully charged the compass needle will update frequently when moving around and/or turning the Oregon. However, once the batteries are down to a remaining life time of around 2 hours the compass needle will only rarely update its direction. Sometimes it doesn't update at all or only after what seems to be an eternity... As soon as I exchange the batteries with some fully charged ones it is back to normal again. Did someone notice the same behavior? Does the Oregon go into some kind of energy saving mode once the battery life drops below a certain level? Is there a setting which keeps the Oregon from doing that?

It is a well known problem by now that the Oregon does have problems with playing some cartridges. By now I tried a couple of very simple cartridges that would not play on the Oregon but would work perfectly well on the Colorado or Windows Devices. Since Garmin is responsible for updates to Oregons Wherigo-Player there is not much you can do except to wait for an update. So far there has not been any update to the Wherigo-Engine (Engine: v.2.11) on the Oregon. Garmin keeps incrementing the Wherigo-Player Version with every software update, but to the best of my knowledge this doesn't have any effect whatsoever.... From a couple of Forum posts I learned the following two things that might help making a specific Wherigo-Cartridge playable on the Oregon: - When something doesn't work while playing the cartridge, press the button on the right side of the Oregon, wait for the "Lock Screen" page to come up, then press the button again to make that page disappear again. Sometime this will make a missing dialog or stuff like that appear in the Wherigo-Cartridge - downgrade the Oregon software to 2.2. Apparently there were some users which were able to play certain Wherigo cartridges on Oregon software 2.2 but would no longer be able to play that cartridge anymore when upgrading the Oregon software to anything above 2.2 (up to version 2.6) I'd be happy about any comments, additional hints and your experiences...

I did already try it on the Oregon (Software 2.5) and it made my Oregon crash. However, I took the time to put together a cartridge and will send it to you, so you can try out for yourself (and at your own risk). I will send you the original lua code, a cartridge compiled for the Oregon and an empty test.gpx file. You need to put both the cartridge as well as the test.gpx file into the Wherigo folder on the Oregon. Then simply start the cartridge, open the GPSr in the inventory and press the rename button. If everything goes well the file test.gpx should have been renamed to test.tmp. This worked fine for me using the Emulator (which comes with the Builder). However, it does not work on the Oregon. In particular the Oregon will crash and freeze when pressing the rename button without the file beeing renamed.

I was out on a 12h caching hunt yesterday using just one set of 2700 NIMH rechargeables in my Orgeon 300. Batteries are relatively new and were fully charged. After like 30 minutes the battery life display would drop down to just two bars and stay there for a couple of hours then it dropped down to 1 bar and stayed there for the rest of my trip. So yes, I think there definitely is something wrong with the battery life display. Another thing I am curious about: After like 10 hours I had the feeling that my unit somehow went into sime kind of energy saving mode. The compass didn't update as often as it used to before and it felt like the unit was not that accurate anymore. When I put in some fully charged batteries it seemed like the unit was back to normal. So my question: Does anyone know whethere the Oregon has something like an energy saving mode that it switches into once the battery life is below a certain level?

Just had the time to play around with os.rename. I implemented a Wherigo-Cartridge which renames a file called test.gpx to test.tmp using the following code: local rv, str = os.rename("test.gpx","test.tmp") Wherigo.MessageBox{Text=[[rv = ]] .. tostring(rv) .. [[ str = ]] .. tostring(str),} The cartridge compiles and works just fine using the Wherigo Emulator. If test.gpx exists and is in the same folder as the cartridge it will be renamed to test.tmp. If test.gpx does not exist a corresponding message will be displayed. Playing the cartridge (i.e. calling the above code) on the Oregon, however, simply freezes the unit and it has to be restarted. Thereby the file is not renamed... So unfortunately this idea doesn't work. Either because os.rename is not implemented or the Wherigo-Player doesn't have the necessary rights, I guess... Anyone any ideas?

Wow, great idea! Unfortunately I don't have any time to investigate that at the moment but here's an idea of how it might work: According to the Builder-Wiki http://wherigobuilder.wikispaces.com/Globals one has access to "os", the standard Lua library of operating system methods. This might make it possible to use os.rename(oldFileName, newFileName) somewhere in the Author Script section. I might be able to try this out at the weekend. If anybody is able to do it earlier I'd be interested in whether it worked