Garmin Colorado Performance Experiment #1

[+Marky]

I was curious about the fact that you can have multiple GPX files in the Garmin/GPX folder. What might the difference be between 4 pocket query files each with close to 500 caches and 1900+ files each with one cache in it.

 

Experiment #1a

• Total number of caches 1915 from 4 pocket query GPX files
  
• I put the 4 GPX files into the Colorado (400t) and booted it up.
  
• It took around 2 minutes and 30 seconds before the map screen was displayed.
  
• From the geocache list, if you clicked on a cache, it took around 8 seconds before the cache info and map combo screen displayed.
  
• Show Description took around 23 seconds. Although I didn't test this, it may take longer or shorter depending on where the waypoint is positioned in the GPX file.
  
• I forgot to time how long the hint took, but I remember it being a while, possibly as long as it took to load the description.
  

Experiment #1b

I loaded the for GPX files into GSAK, and then wrote a GSAK macro to walk the list and export a single Geocache waypoint per file, naming the file $d_Code+".gpx" ($d_Code is a GSAK database variable that containes the GC# of the current record.) I exported them directly to the GPS. This is the equivalent to using the "Send to GPS" on 1915 cache pages.

• Total number of caches 1915 in 1915 individual GPX files.
  
• It took around 4 minutes and 30 seconds before the map screen was displayed, a loss of performance at start up.
  
• From the geocache list, if you clicked on a cache, it took under a second before the cache info and map combo screen displayed.
  
• Show description took less than 2 seconds to display. This seemed consistent (I tried about 20 random caches).
  
• Show hint took less than a second.
  

As long as you don't need to be turning your GPS on and off a lot, the performance gain is considerable. It actually makes the GPS very usable for pulling up geocache pages, logs, hints.

 

Besides the start up performance penalty, there is also the pain of loading the GPX files into GSAK and then running the macro to generate the single GPX files (and this took some time, since it takes GSAK about a second to export each geocache to its own GPX file). Maybe there is a way for gpsbabel to do this faster, but I didn't investigate that. Maybe Robert can chime in if there is an easier way to do this.

 

--Marky

[+Marky]

Some additional thoughts. During startup, the Colorado must open each GPX file and parse it, creating in memory geocache waypoints. It must also save the file name that the waypoint came from, which would account for the increase in performace when showing a description. It doesn't have to parse the XML of thousands of waypoints to get to the specific one its looking for.

 

One possible solution to this would be to not only save the file it came from, but also the character offset, so that it could quickly skip over the first N characters without paying a penalty of parsing the file again. This may not be as easy to implement as it sounds, depending on how the XML parser they are using functions.

 

--Marky

Edited January 27, 2008 by Marky

[+g-o-cashers]

I was curious about the fact that you can have multiple GPX files in the Garmin/GPX folder. What might the difference be between 4 pocket query files each with close to 500 caches and 1900+ files each with one cache in it.

 

Experiment #1a

• Total number of caches 1915 from 4 pocket query GPX files
  
• I put the 4 GPX files into the Colorado (400t) and booted it up.
  
• It took around 2 minutes and 30 seconds before the map screen was displayed.
  
• From the geocache list, if you clicked on a cache, it took around 8 seconds before the cache info and map combo screen displayed.
  
• Show Description took around 23 seconds. Although I didn't test this, it may take longer or shorter depending on where the waypoint is positioned in the GPX file.
  
• I forgot to time how long the hint took, but I remember it being a while, possibly as long as it took to load the description.
  

Experiment #1b

I loaded the for GPX files into GSAK, and then wrote a GSAK macro to walk the list and export a single Geocache waypoint per file, naming the file $d_Code+".gpx" ($d_Code is a GSAK database variable that containes the GC# of the current record.) I exported them directly to the GPS. This is the equivalent to using the "Send to GPS" on 1915 cache pages.

• Total number of caches 1915 in 1915 individual GPX files.
  
• It took around 4 minutes and 30 seconds before the map screen was displayed, a loss of performance at start up.
  
• From the geocache list, if you clicked on a cache, it took under a second before the cache info and map combo screen displayed.
  
• Show description took less than 2 seconds to display. This seemed consistent (I tried about 20 random caches).
  
• Show hint took less than a second.
  

As long as you don't need to be turning your GPS on and off a lot, the performance gain is considerable. It actually makes the GPS very usable for pulling up geocache pages, logs, hints.

 

Besides the start up performance penalty, there is also the pain of loading the GPX files into GSAK and then running the macro to generate the single GPX files (and this took some time, since it takes GSAK about a second to export each geocache to its own GPX file). Maybe there is a way for gpsbabel to do this faster, but I didn't investigate that. Maybe Robert can chime in if there is an easier way to do this.

 

--Marky

 

Interesting, did you notice any difference between the first time you started the Colorado and subsequent startups? I'm wondering if during the first startup after a new gpx file is loaded if the Colorado is doing more work to figure out what are waypoints and what are geocaches.

 

BTW, did you include the child waypoints in your experiment or just geocaches?

 

GO$Rs

[+Marky]

Interesting, did you notice any difference between the first time you started the Colorado and subsequent startups?

I'm wondering if during the first startup after a new gpx file is loaded if the Colorado is doing more work to figure out what are waypoints and what are geocaches.

I didn't notice much of a difference between the initial start up after loading all the GPX files onto the unit and subsequent start ups.

 

 

BTW, did you include the child waypoints in your experiment or just geocaches?

 

GO$Rs

I am not sure what GSAK did and I didn't investigate. I just used the EXPORT macro command, and I don't know if that command will export child waypoints by default. There were child waypoints in my GSAK database, so it may have.

 

--Marky

[+g-o-cashers]

BTW, did you include the child waypoints in your experiment or just geocaches?

 

GO$Rs

I am not sure what GSAK did and I didn't investigate. I just used the EXPORT macro command, and I don't know if that command will export child waypoints by default. There were child waypoints in my GSAK database, so it may have.

 

--Marky

 

My suspicion is that the number of child waypoints could be an important performance factor at startup. The internal waypoint list must be saved on flash memory in some sort of database. The first time the Colorado sees a new gpx file it has to parse the entire file searching for geocaches (which we are assuming it doesn't do anything with) and non-geocache waypoints. When it finds one of the later it must save an entry in the waypoint database which takes time. Assuming that it is a smart implementation I'm guessing subsequent startups can skip or entirely eliminate this.

 

Either way, I'm wondering if a gpx file from a PQ which doesn't contain any waypoints (since they are in a separate gpx file) would be much faster to process than a GSAK gpx file with embedded child waypoints.

 

GO$Rs

[+Marky]

I seriously doubt there is a big issue with child waypoints. Of the 1915 geocaches in my 4 pocket queries, there were only 123 child waypoints. This seems to be fairly typical in my area. Yes, it will have to parse across them, slowing the startup some, but the percentage isn't huge (less than 10% of the total geocache waypoints).

 

--Marky

[+Marky]

I went through and checked, and no child waypoints were included when I generated the single waypoint files.

[+Quiet-Tiger]

What I can not wrap my head around is why the Colorado had to parse the GPX file each time it is turned on. Since both the GPS internal memory and any SD card are non volatile surely the parsed data can be kept when the Colorado is put to sleep.

 

To me it would seem allot less intrusive if the parsing process was done only once at the time the GPX files are uploaded to the GPS, and the result stored in the Colorado memory. As long as no new GPX files are added there should be no need for the Colorado to go through the long process every time it is turned on. That is just nuts.

 

I don't know who did the Beta Testing but you would think that this would be an obvious place to cut startup time. What is the point of barging about a less than 30 sec accasition time if it then takes 2+ min for the GPS to finish booting. Its like saying my car can do 300 mph... but I need 200km of straight flat road to get there.

 

Frankly I think that the Cache way points and the cache descriptions should be pre-processed on a PC before uploading to the Colorado. What ever parsing is required will likely be allot quicker on my quad core 2.4 GH PC.

 

Equally I do not really see the necessity to load 2000+ geocache descriptions and way points. I normally load about 500 on my 60Cx with perhaps 200 descriptions on my Palm PDA. The most I've ever done in a day is 9 or 10 caches and that was a full day.

 

 

My 60Cx serves me well as does my Legend Cx. I would like to one day upgrade to something like the Colorado, but I can wait till the device works like I expect. Some aspects of the Colorado are troubling to me.

[+apersson850]

During beta testing, I didn't have any GPX files the Colorado could use, as it took a while before Groundspeak formatted them in the proper way.

Besides, it's wet, cold and dark here right now, so it's not exactly the best time of the year to go out caching.

[+RRLover]

During beta testing, I didn't have any GPX files the Colorado could use, as it took a while before Groundspeak formatted them in the proper way.

Besides, it's wet, cold and dark here right now, so it's not exactly the best time of the year to go out caching.

 

"Neither rain, nor sleet, nor snow, nor dark of night shall keep me from my appointed rounds!"

The Mail-Person's creed.

 

;^)

 

Just a little chide, Anders, I realize you're not the only beta tester, although sometimes it probably feels

that way.

 

Keep up the good work, I for one think your doing a terrific job! But what do I know, I presently own a

receiver from another manufacturer, and the grass is always greener. Especially when compared to

Magellan, now the grass is TechniColor, and PanaVision.

 

Norm

Edited January 28, 2008 by RRLover

[+Quiet-Tiger]

I certainly did not want to disrespect the Beta testers for Garmin. I work in a tech industry and I know how good intentions do not always prove successful.

 

I still feel the Colorado has a great deal to offer particularly the Geocaching community. It may be some time before the Colorado had overcome its early problems, but my experience with Garmin to this point has been nothing but positive. Their service / support department has provided replacement parts (60Cx and eTrex Venture) for free on two occasions, and in both cases well past the warranty period.

 

I had been eagerly anticipating the release of this particular unit. I was very much looking forward to getting my hands on a new Colorado. I am disappointed that I will have to wait a little longer to get what I want, but they do say good things come to those who wait.

 

Garmin... auto dimming BAD. Please give us option to turn that function off. All previous units allowed for adjustment of the back light by taping the power button (no silly time of day override). The options were Off Dim and Bright. In the case of both my current units (60Cx and Legend Cx) I have the dim setting to 25% and the batteries last for ever... well a long time. That system works for me. There is a saying "if it ain't broke, don't fix it!"

[+Lightning Jeff]

I loaded the for GPX files into GSAK, and then wrote a GSAK macro to walk the list and export a single Geocache waypoint per file, naming the file $d_Code+".gpx"

Would you mind sharing that macro?

[+Marky]

Well, my experiment with one cache per file failed today when I went out to do some shopping (about 30 miles away from home) and when I had a second and tried to pull up a nearest cache, the closest one was 18 miles away (when I know there was one less than a mile away that was in that list of caches.) So, at some point it stopped reading the files. That's too bad. I thought I had an actual work around there for a second. Maybe I will try something like writing files with 100 caches in them and see what happens.

 

--Marky

[+nicolo]

Well, my experiment with one cache per file failed today when I went out to do some shopping (about 30 miles away from home) and when I had a second and tried to pull up a nearest cache, the closest one was 18 miles away (when I know there was one less than a mile away that was in that list of caches.) So, at some point it stopped reading the files. That's too bad. I thought I had an actual work around there for a second. Maybe I will try something like writing files with 100 caches in them and see what happens.

 

--Marky

I may have had a similar problem and I now wonder if it was because of using multiple gc.com ( or I would imagine gc.com as well ) gpx files.

 

I had 5 gpx files generated for the Phoenix area and I know for sure that there is one cache less than 1 km away. I loaded the 5 gpx files, booted up my 400t ... no 1-mile-away cache. I replaced it with a single GSAK generated gpx file ... it was back.

 

I didn't really think much of it until you mentioned this.

 

Hmmm

Edited January 28, 2008 by nicolo

[+Timpat]

Today I took 4 of my zipped PQs totaling 1,855 caches, extracted the .gpx files of each, and copied them (without the child waypoint files) to the /GPX folder. Along with this I had 40,000 custom POIs of all sorts of waypoints, which included my combined PQs. I went out caching and all worked fine on my 300. All caches I went by were included.

 

The day before I loaded the entire contents of the 4 PQs of which 321 were child waypoints, and when I booted up it created the 321 as regular waypoints. I wanted to mention this because with my work and caching, I often keep lots of waypoints saved and these might max me out with the 1,000 waypoint lmit. For most folks this would not be an issue.

[+Team GPSaxophone]

Equally I do not really see the necessity to load 2000+ geocache descriptions and way points. I normally load about 500 on my 60Cx with perhaps 200 descriptions on my Palm PDA. The most I've ever done in a day is 9 or 10 caches and that was a full day.

What's the point of having 1GB of memory free if I can only load 500-1000 caches? That's what, 4MB? Within 25 miles of home there are over 800 caches I haven't found. Within 50 miles there are over 1800. This isn't even in a cache-dense place like California. There are some places where you have to load thousands of caches just to get a 100 mile radius. New technology should be able to cope with that.

Edited January 28, 2008 by Team GPSaxophone

[+Marky]

I did a test where I created GPX files with 100 caches each. The performance was definitely slower, and still not all the caches were accessable. I'm wondering if there is a limit on the number of caches (like, only the first 1000 are accessible or something like that). I'm not sure if it's worth my time to track this down, unless I thought that the info would be valuable to the Garmin folks...

 

--Marky

[+apersson850]

What's the point of having 1GB of memory free if I can only load 500-1000 caches?

I would assume for maps.

[+Timpat]

I did a test where I created GPX files with 100 caches each. The performance was definitely slower, and still not all the caches were accessable. I'm wondering if there is a limit on the number of caches (like, only the first 1000 are accessible or something like that). I'm not sure if it's worth my time to track this down, unless I thought that the info would be valuable to the Garmin folks...

 

--Marky

As I wrote earlier, I currently have 1855 caches loaded from 4 PQs and all of them seem to be accessible. I've tested by searching by name at random and the performance seems fine to me. I takes about 4-8 sec from selecting a geocache to having it on screen, and then about 5-10 sec to pull up the full description. The hint comes within 2-5 secs if I choose that. I simply copied my PQs .gpx files to my Garmin/GPX folder, did not use GSAK.

 

I have the 300 running firmware 2.3/2.6 and have loaded all my mapping on a 2 GB SD card of which I have City Select v.7, Topo 2008, and Nat Parks 24K East totaling about 1.2 GB if this is a factor. I also loaded up .jpg images of digital photos and some maps I created for reference while hiking and can view them in the Image Viewer. That is very cool. The internal memory is taking all my geocache waypoints and custom POIs of which I have about 40,000.

[+g-o-cashers]

Here's some more data that I gathered (sorry the table didn't come across), the FAQ has it in an easier to read format:

 

Selecting geocaches from the Geocache list, reading geocache descriptions, reading hints and startup time are all affected by the size of the gpx file(s) in [drive]:\Garmin\GPX which contain caches.

 

This test used seven different gpx files generated from GSAK: 1, 100, 500, 1000 and 3000 caches with 5 logs/cache (like a PQ) and no child waypoints. In addition the same gpx was generated for 1000 and 3000 geocaches file with child waypoints. Data shows the size of the gpx file, startup time, time to select a cache from the Geocache list, time to show description/logs of geocache and time to show the hint for geocache.

 

# caches (5 logs each)

gpx file size

startup #1 (s)

startup #2 (s)

select time (s)

desc show (s)

hint show (s)

3000+628WP

17.0MB

168

133

25

52

26

3000

16.6MB

155

130

25

52

26

1000+266WP

6.0MB

78

50

9

19

10.5

1000

5.8MB

72

50

9

19

10.5

500

2.9MB

50

36

5

10.5

6.5

100

617kB

30

27

1.5

3.0

2.4

1

7.3kB

25

25

1

2.5

2.5

0

n/a

25

25

n/a

n/a

n/a

 

This data suggests several things. All of the measured parameters grow as the number of caches grows. It is also obvious that waypoint handling (as opposed to geocaches) does add some amount of overhead to the startup time, but it is relatively small (2 seconds per 100 waypoints). But both in the case of Geocaches and Waypoints the first startup after the file is loaded is significantly longer, most of this again seems related to Geocache handling. I would assume that there are some databases being built the first time a gpx file is loaded that can be used on subsequent startups to optimize.

 

GO$Rs

[+Marky]

I did a test where I created GPX files with 100 caches each. The performance was definitely slower, and still not all the caches were accessable. I'm wondering if there is a limit on the number of caches (like, only the first 1000 are accessible or something like that). I'm not sure if it's worth my time to track this down, unless I thought that the info would be valuable to the Garmin folks...

 

--Marky

As I wrote earlier, I currently have 1855 caches loaded from 4 PQs and all of them seem to be accessible. I've tested by searching by name at random and the performance seems fine to me. I takes about 4-8 sec from selecting a geocache to having it on screen, and then about 5-10 sec to pull up the full description. The hint comes within 2-5 secs if I choose that. I simply copied my PQs .gpx files to my Garmin/GPX folder, did not use GSAK.

To verify that there is a good chance that all the caches are accessible, can you open the four GPX files in a text editor, scroll to the bottom, write down the last geocache GC# in each file, then with your Colorado powered on, display the geocache list by GC# and then use the "Spell..." search (what a lame button, it should have said "Search..." instead of "Spell...") to make sure that the last cache in each of the 4 PQ GPX files is accessible?

 

--Marky

 

P.S. 40,000 custom POIs? What are those of? What's the difference between POIs and Waypoints? I've never had a Garmin before, so I don't understand the difference.

[+g-o-cashers]

P.S. 40,000 custom POIs? What are those of? What's the difference between POIs and Waypoints? I've never had a Garmin before, so I don't understand the difference.

 

I'm somewhat new to POI's coming from the 60cs where the only deal in town was the Waypoint. So this is probably not the best or most complete description...

 

POI's seem like light-weight (ie. smaller memory footprint) read-only waypoints. All of the map features (i.e. land features, airports, etc) you see on the Colorado which are included as in the Topo map set are implemented as POIs. Garmin has a POI loader tool that many people use in conjunction with GSAK to load 1000's of geocaches into their 60csx's (and now CO's). See the FAQ for a pointer.

 

The good news is that POIs do show up on the CO map screen and they don't seem to affect performance much, if at all. The bad news is that the POI descriptions don't seem to show up on the CO and you can't modify them unless you "promote" them to a waypoint, which you can do on the CO.

 

GO$Rs

[+g-o-cashers]

Edit: Delete double post.

Edited January 28, 2008 by g-o-cashers

[+Red90]

Custom POIs versus waypoints

 

unlimited number vs 1000

44 character name versus 14

88 character note versus 30

can't change on unit vs can change

can have different categories vs can not

can include custom icons vs can't (at the moment) on the Colorado only.

 

Both can have proximity alerts and (I think) speed alerts.

 

Basically, POIs are better than waypoints in most ways other than they can not be modified on the unit. However, you should be able to create a wayoint from a POI on the unit.

 

On the older units (60csx, legend cx...) the only reason to use waypoints when caching was that it was the only way to use the "goeacaching" features or when you needed to create or edit a waypoint. At the moment, with the Colorado, I can't see any reason to use waypoints when caching other than when you need to add a new location. Using cutom POIs will allow you to have caches display on the unit with whatever icons that you want and grouped in whatever categories that you want.

Edited January 28, 2008 by Red90

[+g-o-cashers]

Custom POIs versus waypoints

 

unlimited number vs 1000

44 character name versus 14

88 character note versus 30

can't change on unit vs can change

can have different categories vs can not

can include custom icons vs can't (at the moment) on the Colorado only.

 

Both can have proximity alerts and (I think) speed alerts.

 

Basically, POIs are better than waypoints in most ways other than they can not be modified on the unit. However, you should be able to create a wayoint from a POI on the unit.

 

On the older units (60csx, legend cx...) the only reason to use waypoints when caching was that it was the only way to use the "goeacaching" features or when you needed to create or edit a waypoint. At the moment, with the Colorado, I can't see any reason to use waypoints when caching other than when you need to add a new location. Using cutom POIs will allow you to have caches display on the unit with whatever icons that you want and grouped in whatever categories that you want.

 

Thanks for the details. Couple of notes:

 

I believe on the Colorado both the name and description of a waypoint are now 32 characters. I've been playing around in GSAK and you can put a lot of stuff in the name of a waypoint now!

 

You can create waypoints on a GPS vs POIs are loaded ahead of time. This means that waypoints have field data like timestamps, temperature and elevation associated with them.

 

GO$Rs

[+Red90]

I believe on the Colorado both the name and description of a waypoint are now 32 characters. I've been playing around in GSAK and you can put a lot of stuff in the name of a waypoint now!

 

Cool. Can you see if the note field is also larger?

 

This means that waypoints have field data like timestamps, temperature and elevation associated with them.

 

Is this data uploadable from the unit? On previous units, the only data that was saved and uploadable was "Name", "note", and "icon". All of the "other" fields that you can specify with Mapsource did not transfer back and force to/from the unit. If this is true, then this is an important improvement from previous handhelds.

[+Timpat]

GO$Rs explanation of POIs is quite good. A typical custom POI file has four fields; Lon, Lat, ID, Comment. In our 60X's we can display 44 characters in the ID (name) field and 88 more in the Comment (note) field. So you can get a fair amount of cache info loaded. In my 300 it only allows the 44 character name field to display.

 

I keep all my combined PQs of caches and child waypoints loaded as a POI file in my 300 because they will display on the map. They can be saved (copied) as a waypoint if you want to edit it for any reason. For now I do that to keep a record of found caches since we can not currently change a geocache icon as "found" or save it as a waypoint to edit it. For the 40K number of POIs, I did because I can, not that I need them all. I have all the USGS benchmarks in eastern NY, all the airports in the world, zip codes in the U.S. (not all), all my found caches and all my owned caches and parts of multis, etc.

 

Red90's description covers things very well I just saw and I agree 100%. I like being able to select by database and having unique icons for each category displayed, just like I have done on my 60Cx.

 

Marky, I checked my .gpx files the way you suggested and of the 4 PQ files of caches one did not include the final GC# in my 300 where it was listed in the text editor. Not sure what that means for you. The one not showing up was GCX41E for what it's worth. There are many others with an "X" in the name so it's not due to that. So how would know if I'm missing just one cache out of the 1855 this way?

[+g-o-cashers]

 

Cool. Can you see if the note field is also larger?

 

 

It is 32 characters as well.

 

This means that waypoints have field data like timestamps, temperature and elevation associated with them.

 

 

Is this data uploadable from the unit? On previous units, the only data that was saved and uploadable was "Name", "note", and "icon". All of the "other" fields that you can specify with Mapsource did not transfer back and force to/from the unit. If this is true, then this is an important improvement from previous handhelds.

 

Elevation and timestamp are available in the current.gpx file and via mapsource upload (in addition to the 3 items above). Temp, depth and proximity are not. Depth probably requires hardware I don't have!

 

GO$Rs

[+Timpat]

[edit: delete dbl post]

Edited January 28, 2008 by Timpat

[+Red90]

Elevation and timestamp are available in the current.gpx file and via mapsource upload (in addition to the 3 items above). Temp, depth and proximity are not. Depth probably requires hardware I don't have!

 

That is good to hear. Many people have wanted the timestamp in the past and the elevation should be handy as well.

 

See there are some improvements to talk about.

[+Marky]

So how would know if I'm missing just one cache out of the 1855 this way?

Without manually pulling up every cache, I'm not sure you can know just how many are actually loaded.

 

I haven't ruled out parsing as the reason why not all caches were loaded. It very well may be that some cache caused a parsing error that caused the loading of caches to stop. The only way to address the issue would be to send specific GPX files to the developers with a specific known test case and have them look at why it isn't working.

 

--Marky

[+Marky]

Can someone point me to instructions how to create POIs on the Colorado? Can you really have your own custom icons? (Like, make gc.com looking icons for the different cache types?) I'd really like to give the POIs a try, since my previous set of pocket queries (100 mile radius search) was at something like 12,000 caches. It would be kind cool to load them all in.

 

--Marky

[+Red90]

Can someone point me to instructions how to create POIs on the Colorado? Can you really have your own custom icons? (Like, make gc.com looking icons for the different cache types?) I'd really like to give the POIs a try, since my previous set of pocket queries (100 mile radius search) was at something like 12,000 caches. It would be kind cool to load them all in.

 

DO a search for "custom POIs". There are tons of threads.

 

IMO, the easiest method is to use a GSAK macro.

 

There are few choices, http://gsak.net/board/index.php?showforum=23

 

I use a modified version of this one: http://gsak.net/board/index.php?showtopic=3172 In addition, I have my Waypoint and Mapsource icons setup to use the same custom icons as described here: http://www.thepropers.com/geocaching/60Ser...stomSymbols.htm Once you have this setup, it is all pretty automatic with very little required work.

Edited January 28, 2008 by Red90

[+g-o-cashers]

Can someone point me to instructions how to create POIs on the Colorado? Can you really have your own custom icons? (Like, make gc.com looking icons for the different cache types?) I'd really like to give the POIs a try, since my previous set of pocket queries (100 mile radius search) was at something like 12,000 caches. It would be kind cool to load them all in.

 

--Marky

 

The Colorado FAQ has a link to the GSAK thread / macro that I used to accomplish this. Pretty slick I must say. I have every cache in New England loaded as a POI.

 

The only problem I have is that I would like to be able to configure the display of custom POIs on the map independent of user waypoints. Right now they use the same setting. It would be nice to be able to turn off POIs and still see user waypoints.

 

GO$Rs

[+Marky]

I can't figure out how to get the icons onto the Colorado. I read every thread I could get my hands on. The only way I saw mentioned was using xImage. I downloaded xImage but it doesn't recognize my GPS. Is there some secret step I didn't find?

 

--Marky

[Moun10Bike]

You just need to create a bitmap of your custom icon, give it the same name as your chosen POI file, and place in the same folder as the POI file. It will be automatically uploaded and associated with the POIs in that file. Use a magenta background (RGB = 255,0,255) for transparency.

[Moun10Bike]

A couple of other helpful tips = make your bitmap 16 x 16 pixels and save with 8 bit depth (256 colors). I can send you an example bitmap if you want.

[+Prime Suspect]

What I can not wrap my head around is why the Colorado had to parse the GPX file each time it is turned on. Since both the GPS internal memory and any SD card are non volatile surely the parsed data can be kept when the Colorado is put to sleep.

 

To me it would seem allot less intrusive if the parsing process was done only once at the time the GPX files are uploaded to the GPS, and the result stored in the Colorado memory. As long as no new GPX files are added there should be no need for the Colorado to go through the long process every time it is turned on. That is just nuts.

I'm assuming the GPX files are stored on the removable media, and the actual waypoints are stored in internal memory. The unit knows when new waypoints are loaded to internal memory, because the unit has to be up and running for that to happen. But when it's powered down, it has no knowledge of what changes have happened to the memory card. So it has to examine its contents on each boot up.

[+Marky]

A couple of other helpful tips = make your bitmap 16 x 16 pixels and save with 8 bit depth (256 colors). I can send you an example bitmap if you want.

Thanks Jon, I got it working now. The macro I used made hint POIs, which I really don't want, so I guess I need to play with it some to get it just how I like it.

 

--Marky

[SiliconFiend]

What I can not wrap my head around is why the Colorado had to parse the GPX file each time it is turned on. Since both the GPS internal memory and any SD card are non volatile surely the parsed data can be kept when the Colorado is put to sleep.

 

To me it would seem allot less intrusive if the parsing process was done only once at the time the GPX files are uploaded to the GPS, and the result stored in the Colorado memory. As long as no new GPX files are added there should be no need for the Colorado to go through the long process every time it is turned on. That is just nuts.

I'm assuming the GPX files are stored on the removable media, and the actual waypoints are stored in internal memory. The unit knows when new waypoints are loaded to internal memory, because the unit has to be up and running for that to happen. But when it's powered down, it has no knowledge of what changes have happened to the memory card. So it has to examine its contents on each boot up.

You're probably right, but there are ways to optimize it. They could keep a list of files that were processed on the last startup and see if those files are still there or if they've changed (they could do it by name & timestamp or MD5 even). On the next startup, update the list and process any files that have changed or are new. I wouldn't be surprised to see that sort of optimization show up in a future firmware update. Could cut out a lot of the startup lag with a lot of caches loaded.

[+SnoWake]

I've been bouncing around using Waypoints (coming from the 60-series, this is what I was most comfortable with), then POIs, then both - and now alternatively one then the other. At the same time, I'm putting the unit through a variety of paces: auto navigation, hiking, navigating from one point to the next, etc.

 

There's one additional difference, which may be irrelevant, but I thought worthy of mentioning:

 

There are additional 'facilities' for managing waypoints, as opposed to POIs. It's a separate, dedicated list, as well as a dedicated bit of functionality ("Waypoint Manager").

 

FWIW- I'm using the "GarminCsvPoiExport.gsk macro, v1.8, and successfully generating 11K POIs each with the respective GC.com icon, by type. This macro optionally generates additional 'hint' POIs.

 

Oh, one last comment, since I was catching up on a lot of posts on this thread. I share Marky's opinion about the choice of button label.

 

"Spell..." ?

 

Certainly, I knew what it mean, and it was more concise than "Find by name" as used in the 60-series, but... c'mon. I dunno - perhaps my usability designer fiance would tend to disagree with us, Marky. Ever read Cooper's book "The Inmates are Running the Asylum"? I think you and I (and likely, most of us in this forum) fall into a particular category... ;-)

 

Thanks SO much to everyone for all the shared research and results. I think the trade-offs between initial load time and performance are very interesting -- if ONLY it weren't for the 'missing caches' phenomenon.

 

Marky, with regards to your question: I don't know if it would be useful to the guys at Garmin - but it would certainly be useful to the community at large, if we knew there was a certain threshold after which, we would start losing caches. I've pushed single GPX files of < 1000 and my random sampling has shown that I've got all the data. However, performance is less than ideal - and that 20-30 second lag can feel like an eternity in the field - especially, if you have to suffer it several times.

 

I'm keeping a careful watch on this thread - and will contribute back any additional tests or findings. Thanks!

[+Marky]

However, performance is less than ideal - and that 20-30 second lag can feel like an eternity in the field - especially, if you have to suffer it several times.

Just wait until the next update. The performace of the units at the REI event was awesome.

 

--Marky

[+SnoWake]

However, performance is less than ideal - and that 20-30 second lag can feel like an eternity in the field - especially, if you have to suffer it several times.

Just wait until the next update. The performace of the units at the REI event was awesome.

 

--Marky

 

I eagerly await it's arrival, with baited breath!

[+SnoWake]

So, I tried to take Marky's original experiment a few steps further, in trying to identify limits/thresholds.

 

Once I finally managed to cobble together a GSAK macro to walk through a database and spit out a unique GPX file for each cache - I was ready to experiment.

 

So - Marky determined that with 1900 caches - either in one large, single file, or as 1900 individual GPX files - resulted in 'data loss' (e.g. caches that were pushed to the unit, not appearing under 'geocaches'.

 

Trying to identify the limit, I tried some tests with a dataset of 990 caches. First, I pushed them as a single file (which I've been doing since I got the unit) and was surprised to find that there were caches missing (I hadn't experienced this in my day-to-day use).

 

BTW: My 'test' for quickly determining if all caches are appearing is this - I push the same dataset as POIs (which seem to have no problem with tens of thousands of points). Then, I go to "geocaches", scroll down the page a bit (say, to the 10th cache, listed by distance). Then, go to the Custom POI database, and list the nearest points - and I see that the cache I selected is more like 20th on the list. I can identify specific caches from the POI list that SHOULD be shown in the geocache list.

 

Okay - so 990 in a single file is a dropping data. So - I then pushed 990 individual GPX files. This takes some time - best to be done the night before. You sure don't want to be waiting to head down the hill from Tahoe for a blitz through Reno while this process crunches (about 45 min).

 

Once completed - I found similar results. What I didn't determine was if it were the exact SAME caches missing from the list. Nonetheless, there were plenty of gaps/missing caches. On the other hand - once the unit finally booted up, the response time when viewing geocaching data was, as Marky observed at the beginning of this thread - impressive. Cache descriptions loaded within a second - the type of performance we've come accustomed to.

 

So - 990 was too many. I then pared back my dataset even further: I repeated the experiment with just 203 caches. Once more - both the single file, and 203 inidividual GPX files, both resulted in missing cache data. :-(

 

Let's see what happens when the next firmware release hits - and in the meantime, I'm going to try some more detailed experiments to see if there are particular caches that won't load - e.g. some special character in the description or logs that is choking the parser, or ???

 

Just a quick report out - I'll post any further findings as I make them.

 

Have a GREAT day!

Billy