SiliconFiend
-
Posts
358 -
Joined
-
Last visited
Posts posted by SiliconFiend
-
-
Averaging is ALWAYS better. Its called an increased sample size, I'm sure we have a few people on this forum who took stats in highschool.
I think the point that Anders was trying to make was that averaging can give you a false sense of better accuracy, when in fact just marking the waypoint at a time with an optimal satellite configuration can improve your accuracy much more.
-
<snip>
So what your saying is that the fact the Colorado is missing waypoint averaging is GREAT! Its BETTER! Its NOT an oversight, it was planned because NOBODY averages waypoints because it "DECREASES" accuracy. What Bunk!
That line of thinking is absurd to me. Why can't you just say something like, yeah, thats crap and I hope they add that feature in a future update.
As Red90 said, this is the first handheld unit to use the same base software as the car units. I'm guessing it's an attempt to unify their software development (it's what I'd do if I were them). Obviously, the car units are lacking many of the features we expect in a handheld unit.
And as dopoka said, in most product companies, the features and the timeline are set by marketing. The timeline was release for CES 2008, obviously, and missing that would have been a huge loss, if only because everyone expected something new from Garmin at CES. So, the timeline was fixed. When you have a list of features and a fixed timeline, engineers have to make compromises when the inevitable delays crop up. So, Garmin focused on the "glitzy" features (GPX file support, terrain shading, 3-D view, the new Wherigo games) and the older "standard" features went missing. It's the rational thing to do--most bang for your buck (or timeline in this case). A company like Magellan sacrifices quality instead to meet a (multiply-slipped) timeline.
Yes, it would have been great to have all the features from the old handhelds and more, but sadly, reality intrudes. We can wish and hope and complain, but ultimately wait to see if Garmin makes the Colorados the "ultimate" geocaching GPS (there will always be some people who aren't satisfied). Quite a few people have enough trust in Garmin (and patience) to have bought them already, despite knowing their current shortfalls.
-
Our family has just gained its second Garmin 60cx, and I just bought a 2 gig card. I'm hoping to upload the entire USA openstreetmap.org map onto this card. Has anyone done this? If so could you share the steps involved? I used to work as a CAD draftsman, and worked with a lot of government map data, so believe this is doable. What software? Load directly? etc... I don't want to compromise the original base map that comes on the unit.
For the first 60cx we purchased garmin mapsource usa street maps, and loaded the entire US onto one 2 gig card. I thought the software was good for 2 units, so uploaded a small test map onto the second unit (before getting memory card). It didn't work, so now we get a map needs unlocked warning every time the unit is turned on. I somehow need to unload this map before loading the open street map data.
The routing that is part of the Garmin software is very handy, but on the second unit we really just need more complete maps. Living in a rural location, our town is just a dot on the Garmin base map! Geocaching would be much easier with the roads on the map as well.
My cousin just bought a 76cx, and she's very interested to see how this works as well.
Thanks in advance!
sunflowerflyer
I'm glad you're interested in the OpenStreetMap data (especially since the TIGER map data import just completed--now the entire US has fairly complete, although sometimes inaccurate street map data). As Red90 said, mkgmap is the way to go for now. Note that with that program, you'll get the street data, but it isn't routable. I'm working on a routable version. In a longer-term plan, we're looking at setting up some infrastructure to help with creating GPS maps, because downloading 3.6 GB (currently) of compressed data, cutting it up into appropriate-sized tiles and running it through the mkgmap processor is not something everyone can do (or really very many people are inclined to do).
I'm not an expert on mkgmap, but I'm willing to help you get this working. Look at a Java tool called Osmosis for helping you slice up the Planet file into manageable chunks (you might want to start with a USA extract first, then use that smaller file to create your tiles). Also check out the mailing lists (probably dev@openstreetmap.org is the one you want) for other support.
-
My Vista is usually in and out of it's holder between the dash mount and the Garmin holder. How easy is it for this cover to open/close to place the GPS on a holder - be it a bike or auto dash kit?
It's easy to open and get your GPS out, but you'd have to take the mount point on and off the rear screw hole every time you want to change to and from your mounts, unless you had a type of mount that gripped the sides or something. I'm thinking about creating something for my bike that could work with the super-strong belt clip on this case.
-
There seems to be a dearth of information about the Foarm GPS cases, so I thought I'd write a proper review of the eTrex case, with photos.
Front
Left
Right
Construction
The case is made from a texturized rubber over a black fabric backing.
The case hinges at the top, and the bottom is secured by the lanyard. The lanyard passes through holes the top and bottom halves of the case. The two ends of the lanyard are sewn together and this end secures the bottom half.
When the GPS is inserted into the case, the loose end of the lanyard is pulled through the holes in the top half to cinch the top half to the bottom. The lanyard is then secured from slipping by a pinch-type slide.
A plastic clip slides on the loose end of the lanyard.
On the rear, there is a steel belt clip.
Impressions
The texturized rubber seems very durable and doesn't add much to the size of the svelte eTrex GPS, although if your're accustomed to using it without any case, you might struggle somewhat with the extra thickness. My Vista HCx fits in snugly--even with the case open, it won't fall out when I hold it upside down. The fabric backing seems to give it good tear resistance. The case is not spongy--it's fairly rigid. It wouldn't necessarily absorb the force of a drop, but the rounded corners would help distribute the blow and so it seems to give good protection. It probably would help more with scratch & dent protection, and the GPS itself is probably tough enough to handle the shock from a drop. The texturizing makes the case very grippable.
The clip on the lanyard is a nice touch and seems very durable. It has a feature on the tip of the clip latch which engages with the mating surface and keeps the clip from being pushed out to the side. The steel belt clip is strong spring and it's not likely to be falling off your belt. Note that after placing your GPS in the case, you will need to recalibrate the electronic compass (if your unit is equipped with one) due to the significant metal in the belt clip.
One of the nicer aspects is that the window for the screen is completely open--it doesn't have a cheesy plastic cover to interfere with a screen protector or to get get scraped and impair the visibility. So, the case doesn't affect screen visibility at all. They provide two peel-and-stick screen protectors which are the size of the window. The protectors seem to be made of the same material as the excellent Invisible Shield product, but they don't cover the entire screen--just what you can see through the window. I already had an Invisible Shield fitted, so I didn't use the supplied screen protectors. I'll probably cut one up and use it for my watch.
Usability
The case doesn't interfere a lot with the user operation of the unit, but it does somewhat. The side buttons are largely unaffected. Probably the most noticeable is the click stick. The case causes the joystick to be somewhat recessed, so it's not as easy to operate with your thumb. It can still be done, but it's somewhat awkward. The upside to the recessed click stick is that you won't be accidentally marking waypoints anymore (if it's in your pocket or on your dash up against the windshield). The case makes it somewhat harder to wipe fingerprints off the screen, too. The screen protector picks up fingerprints easily, and needs wiping regularly. Out of the case, it's easy to wipe it off, but in the case, it's quite a bit harder. That's the trade-off for using a screen protector and window in the case instead of a plastic screen cover.
The satellite reception seems to be completely unaffected by the case, in case anyone was worried about that.
Availability
As far as I know, the only place you can buy it is on Amazon (the manufacturer's web site directs you there). It runs about $17 + tax & shipping. It's listed on Amazon as a "Military-Grade" GPS case, but for some reason searching for "GPS Case" doesn't turn it up. Searching for "Foarm" will show you all their cases, though. I got the white case, but it looks like they currently only have a tan one. I would have preferred a black case, but it wasn't available.
Verdict
To sum up, I like the case. I'd trust it to protect my toy from a significant drop as well as the normal bangs and scratches from a geocaching outing. I'd probably give it 4 out of 5 (insert your favorite rating unit here), because I'd prefer a black case, and because of the slight interference to operation.
-
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.
-
This issue of the segment count limit of 2025 for the 60/76C(S)x units has been discussed, and complained about, a lot over the past couple years. I am one of the complainers.
So, OK, it's a been 9 months since I last bugged Garmin about this. And the Colorado has come out. I recently emailed tech support: "Do your new Colorado series, as well as your HCx series, have the same 2025 segment count limit that my 60Cx has?"
They replied: "The Vista HCX does have the limitation, but the Colorado devices do not have the limitation."
So, not wanting to give up just yet, I further asked: "Will Garmin issue a firmware update for the 60/76/C(S)x and HCx to remove or increase the limitation?"
To which they replied: "At this point in time there is not a future software update to increase the 2025 map set limitation."
So, there you have it. The Colorado is the new king of the handheld mountain, and update support for the 60/76C(S)x will taper off to zero.
Too bad, since the 60/76C(S)x units are the ones that everybody loves and have no problems with. Right now, nothing out there from Garmin, Magellan, Delorme, or Lowrance is good enough to motivate me to replace my trusty 60Cx.
I'm guessing there is some inherent limitation in the software (or maybe the hardware) used in the units with expandable memory. It just doesn't make sense to drastically re-engineer an older software platform when you've moved on to a newer, hopefully improved platform. It sucks, I know, but that's just the reality of product and/or software development. To be fair, Garmin is better than most at continuing to release software updates for units long after they're out of active production.
2025 segments is a lot of maps (at minimum, with Topo maps, that covers more area than you could likely drive in a day), and you could always swap cards...
-
Soon I'm hoping to be able to create routable Garmin maps from OSM data, so there's giving back for you. You can currently create non-routable Garmin maps using mkgmap.
It will be interesting to see if you have success.
IME, it is very difficult and requires a lot of manual work to get routing to work.
It's tricky, but it is possible to automate it. OSM is particularly suited for this. I already had some success creating routable maps, but it was an XSLT sheet and it totally choked on even 10 MB of input data, which is a tiny area. Don't worry, once I get something working I'll post a notification here. Maybe we can get people to "cache & map" like they "cache in, trash out", and improve the OpenStreetMap data in the process.
-
IndyJpr,
This is great stuff. I want to create some maps of the major ski areas. Also bike trails in the Denver metro area where I live. You've already got a base map of sorts done. Would it be possible to short-cut the process? For example, I would create the lift lines, ski runs, trails, etc and then use them as an overlay on your topo and avoid repeating your work with the contours, major geographic features, etc. I see how to create all those objects, I just don't know if I need to do anything special to have them as an overlay. Any ideas?
I would also be willing to send what I do your way for inclusion into your topo map. It would be sort of an "open source" project. Feel free to contact me directly through my GC profile as well.
Did you know that some other guy has also done a similar project but charges for it? His doesn't appear to run on MapSource, though.
You could just create those features as a transparent map and they should show together with the topo map.
If you're going to go to the trouble of collecting those GPS traces, consider contributing them to OpenStreetMap, too. Soon I'm hoping to be able to create routable Garmin maps from OSM data, so there's giving back for you. You can currently create non-routable Garmin maps using mkgmap.
-
I think I was hoping to hear that the auto routing feature really IS that good! Hopefully it will prevent the navigation "discussions" we get into in new cities using the rental car maps. Guess I will go ahead and spring for Navigator. Anyone out there with input on the NP topo?
I've heard that the National Parks 24k Topo maps support auto-routing on the trails, which is kind of cool, if not terribly useful.
-
or is it only for the 60CSx?
I don't know why not. I have the GPSMAP 162/168 Tide Points (available free from Garmin) loaded in my HCx, and they work fine.
-
........Basically he told me the chipset was the same in the 60csx and the colorado and the H series........
Someone correct me if I am wrong, but the 'H' series units use the SiRF Star III chipset not the Garmin chip that is used in the Nuvi and the Colorado.
The H series does not use the Sirf chipset. It was rumored to use a MediaTek chipset (based on boot-up messages on early firmware) but they might actually use Garmin's (also rumored) chip. There's also the possibility that different runs of the units have different chipsets (but the chipsets would have to be very similar in order for that to work). Maybe Garmin collaborated with MediaTek to create their own chipset?
-
They do test. The problem with that is that in the very short time from pilot run units available until availability at the retailers, not every single issue can be found and corrected.
Some issues are pretty "special". It takes more luck than planning to happen to spot them. Like if you follow a route, made with City Navigator, then decide to display the elevation plot, then stray off the route so a recalculation takes place. Now nothing special happens, but before testing...
I understand the beta cycle better than most, as a previous paid gig, I did contract work. They said I have the reverse midas touch... for those that have never heard about the midas touch, everything he touched turned to gold...
They said I could break an anvil!
Ah, yes, I have that, too. Everything I touch turns to s***, then takes my gold.
-
I know to always recalibrate the compass on my Garmin after changing the batteries. I just don't know why. Anybody have a good, technical explanation on the relationship between battery strength and compass accuracy?
It don't think it really has much to do with battery strength. The issue is probably more with the metal in the batteries that affect how the magnetic flux sensor reads. The earth's magnetic field is very weak, so a small amount of metal can affect the sensor. So, each battery might have slight variations that could affect the compass. Even the same batteries (if you're using rechargables) could conceivably affect it depending on how they're installed (there could be small axial variations so if you rotate the battery in the slot it might skew it).
-
Also when you go to set your datum you have to select "NONE" under datums if you want WGS84, then it says that the spheroid is WGS84?????? What? WGS 84 is a datum not a spheroid.
WGS84 is both a datum and a spheroid, but it is weird to have a datum of "none". You always have a datum--you have to start somewhere...
Also, everyone settle down. The Colorado firmware has some incomplete functions, but compare it to the Triton firmware! At least it's generally functional and doesn't lock up all the time just trying to do common tasks. Expect Garmin to continue improving the firmware.
-
Sorry if I was harsh. There's been a lot of hype and overreaction about issues with the Vista HCx, when it's a very good unit that is a great choice for a lot of people. ....
There has been no overreaction!!
The odometer of the HCX had big problems. - And the newest firmware still has problems.
now it shows to much kilometers - but the calculation has been improved - still not corrected
Have some patience. Garmin has shown that they're willing to work on the problem. It may take a few iterations, but the most recent firmware has gone a long way to fix it. Don't forget that the eTrex H series may be competing with the Colorado for developers' time.
-
Ever heard of an opinion? Let's keep these forums friendly. They are nothing but opinions including yours. We don't work at Garmin so there is no way either of us can know. Anyhow, the Sirf chip works perfectly. So they wrote the firmware correctly for the first high sensitivity GPS and then botched it up on the next generation? I bet there's more to it than that. Anyhow, it was simply my "observation" that these firmware fixes on the HCX are probably compensating for a hardware spec differences on the new chip that the Sirf chip didn't have. If it was just a firmware issue they would have fixed it a long time ago. However, if the new hardware has limitations that the Sirf chip didn't have then the firmware might not be able to compensate. It doesn't sound like it's completely fixed yet based on feedback in this thread. Anyhow, hopefully they can dial in the firmware. It will be interesting to see how the Colorado performs.
Sorry if I was harsh. There's been a lot of hype and overreaction about issues with the Vista HCx, when it's a very good unit that is a great choice for a lot of people. Certainly the chips are different and the GPS chipset firmware will necessarily be different, too. I'm guessing the vendor's reference implementation firmware was much better for Sirf than for the MediaTek (or whatever chip they're actually using now), so now Garmin's having to go back and fix it, which is likely not trivial. The signal analysis is probably done by DSP, which would be controlled by software (most likely that's what the GPS chipset software is--DSP code).
-
The issues were with the odometer not reading at slow speeds. I think the current firmware on the HCX still won't read below 1.1mph. This normally isn't a big deal but if you are using detailed topos then you could be climbing steep mountains and going very slow. There also seems to be an issue with max speed being glitchy. Some people have done hikes where their max speed was reported as high a 90mph. So maybe you can check this stuff out. It's very possible that the Colorado could be using a newer version of the chip that addresses all of those issues. I was thinking that is was a hardware issue all along.I believe I read that the Colorado is based on Garmin's chip set -- not the Sirf. So far I haven't noticed any issues with reception and lock but it is the dead of winter around here (MA) which normally isn't a problem anyway! GO$RsI was watching the odometer this morning and I don't remember seeing any issues even at slow speeds, but I really wasn't looking for trouble either. I'll have to do a comparison between my 60cs and the Colorado tomorrow.
GO$Rs
TrailGators is misinformed (and widely spreading that misinformation). It's almost certainly not a hardware issue. The newest Vista HCx chipset update (2.6) fixed the slow speed threshold. I've seen speeds of 0.7 km/h reported, which is excruciatingly slow. The odometer bug was all tied up with the speed threshold, and now it almost seems like Garmin overdid it and the odometer is overreporting distance now. It seems to be a matter of fine-tuning anyway. The max speed issue was one person's report, and the circumstances surrounding it are not fully known. There are still some outstanding issues with the HCx such as correctly reporting total elevation change, but Garmin has a long history of fixing firmware bugs, so I'm confident these issues will be resolved.
-
The Sanyos were a little higher priced then the others...
I got mine at Costco in a set of 8 AA and 4 AAA and some weird C and D sleeves (which I will never use) and a 4 bay charger for I think around $20. That didn't seem too expensive to me, but I didn't shop around at all.
--Marky
Hey, if you're not going to use those "weird sleeves", send them to me.
-
For the people that do a lot of caching, holding lots of information is desirable.
For instance, I hold all of my found caches, plus unfound for the normal areas I travel. This gets up around 3000 caches.
Yes, but with the GPX file support, that's almost a moot point. If you're that into caching, you'll likely be a premium member and will be using GSAK to manage your GPX files. True, we don't yet know for sure how many caches it will hold, but it's probably more a function of memory than of some artificial limit.
For "normal" usage of waypoints (to mark something of interest to you, one point at a time), 1000 is a lot.
A GPS file has 500 caches. GSAK has a steep learning curve and it flat out doesn't do things the way I like. i'd rather load my GPXs straight to the GPS and load it up and skip GSAK. No muss no fuss.
According to what Anders wrote earlier, you can just drop the GPX files onto the Colorado and you're set. No need for GSAK. I think he also said it supports multiple files, so there ya go. 500 at a time is 6 files for the 3000 caches you mentioned.
-
Hey guys, let's not get confused.
The 2025 segment count limit has nothing to do with the memory size limit.
When we talk about 2025 segment count limit, we mean that the gpsr can accept up to 2025 map segments, regardless of their individual or collective memory size.
For example, for TopoUSA, the map segments are numerous and small. If you try to load up all the western states and you keep track of the segment count in Mapsource, you will find that you hit the 2025 segment count limit at about 375 mb of memory size on the uSD card. Therefore, if you are using TopoUSA for your maps, any uSD card bigger than about a 512mb is a waste of silicon.
This is not true for the other mapping products that have fewer, and much larger, map segments. For the street maps, you can put the entire USA onto a 2gb card without hitting the 2025 map segment limit.
We need Garmin to modify the firmware to accept more than 2025 map segments, or produce a Topo product with fewer and larger segments, like their street maps do.
I'm not confused. I was talking about Metroguide Europe, which has 2367 maps, and altogether takes slightly over 2 MB. I deselected a few map segments to get it below the 2 GB limit (but it was still over 2025 map segments). It successfully loaded to the microSD card and displayed on the GPS, but it had weird problems as I described above. Once I reduced the map segments down to 2017 (I tried 2022 as well), it worked fine.
It's probably a structural issue with the number of map segments, so I wouldn't count on a firmware update to help you. A "Topo NT" might help, though--compressed and with larger segments. Although there's probably a practical limit to the number of entities in a single map segment, too, so that might not be possible (Way more topo contours than roads for a given area, except maybe Kansas
). The Colorado series seems to have much more horsepower for drawing maps so those practical limits are probably much higher for it. -
Went on a short hike today and had some issues. The unit shut off a few times which we *think* was due to some full charged but weird batteries. This seemed to cause part of the track log not to record going up.
The distance going up on the odometer did match the track log coming down though (track log on the way down was complete, just over a mile).
The trip was with a 4 year old, which meant our speed varied from chasing after him to barely moving to standing about.
When we left, stopped the track log and headed home, loaded coordinates and then went off to find a cache, maybe a total of 12 miles. When I got home noticed that the trip computer recorded 320 miles on the odometer and 102 max speed
I'd be real interested if anyone has experienced anything like this or heard of stuff like this happening?
I think your experience with the flaky batteries makes that test less than authoritative... Probably some power blips caused those outliers in your speed & distance.
-
4) Uses AA batteries as opposed to the AAA or rechargeable lithium-ion.
I'd rather have the rechargable... Good batteries are expensive these days! And you can buy spares (the Motorola cell batteries) very cheaply on eBay.
Why does everyone like the special batteries? I want everything to run on rechargable AAs (or AAAs)! If I'm traveling, I want to take 1 charger, not 7. Plus, then I can pull batteries out of one device to power another, in case of emergency. Standards are a good thing.
Edit: botched the quote nesting.
-
There is definitely no 2025 map limit for 60 CSX/CX and the HCX series. The 2GB limit seems to be independant of formatting cause people with 4GB cards were able to stuff up the whole card, however only 2048MB of map data --> here is a link over to the german forum about this topic.
Oh maybe 2025 Map limit exists if you load maps directly to GPS I don't know, I use a card reader and for that there is definitely no map limit.
Vista HCx reference 2025 Map Limit Topic
http://www.naviboard.de/vb/showthread.php?...;highlight=2025
Reference for 2GB Limit on 60CSx and 2025 map limit somewhere in that topic:
I don't know about that. I tried loading more than 2025 map segments on my Vista HCx via a card reader. It took the maps and displayed them, but it acted funny. It wouldn't route--claimed no roads at destination or something strange like that. Trying to find cities revealed strange names, incomplete indexes, etc. It occasionally failed to re-draw when scrolling. Once I dropped the map segments to below 2025 (I think I used 2017), it worked great.
). The Colorado series seems to have much more horsepower for drawing maps so those practical limits are probably much higher for it.
Oh the agony
in GPS technology and devices
Posted
Dude. Backup.