Posts posted by Grasscatcher
Fizzy is right....Period! No difference in lockup time due to WAAS.
TCP you can disagree with ECA on how to keep a m SD card in a GPS unit where it doesn't fall out.
Does he really still use tape?
The ones that think WAAS causes slow lockup are probably the same ones that:
Have 9762 separate gpx files on their unit(s) (yep, I know, impossible, but they would if they could)
Have installed 32 different sets of maps on their unit. (of places they will never go or have ever been)
Have never cleaned archive files out of their units.
And on, and on......you get the picture....
All info has to be read , checked for changes, stored, etc.....before unit ever gets to the point of "locking on".
@ Sussamb, Since this general issue has been around since the implementation of the “New”operating system and file structure, and seems to be totally and completely misunderstood by the overwhelming majority of users, why don't you or someone officially associated with the Garmin Forums, or possibly even someone from Garmin Inc, create and then post officially (and in multiple forums ) an in-depth explanation of the When,Where,What,Why's associated with the “Dreaded Straight Lines PROBLEM” and Odometer Discrepancies / vs Track that many users THINK Garmin has?
Even Garmin Customer Serv Tech Support personnel regularly mis-diagnose the “perceived” problem and give conflicting explanations and many units have been unnecessarily sent back to the mfr. for repair or replacement.
That older model units have a completely different operating system and thus require totally different operating techniques and procedures.
What is Archiving.
How Archiving choices affect results and which choice to choose for which results.
Does Archiving choice have any effect on the number of “straight lines”
What is the purpose of those straight lines "tying info together"
How Archiving prevents data loss.
What is the “last known position” point and how does it affect all of the Speed and Distance data fields on the Trip Odometer page.
What's the difference between Odometer and Trip Odometer?
What is the sampling rate of the trip odometer?
What is the sampling rate and method set by user?
Which method to choose for which desired outcome.
Which method is most accurate for displaying “actual path traveled”
Which method comes the closest to “actual distance traveled”
Why is there a difference in Distance between methods?
Should you “Save” a track or not?
What data does “Clear Current Track “ delete and what data does it NOT delete.
WHEN and WHERE to Clear Current Track.(partially covered above)
User settings and user timing and procedures are what creates or prevents the “straight lines”
@ Sussamb,You are absolutely correct.
All of the "PROBLEMS" posted above are totally explainable and are "User" caused and "User" correctable.
I posted a longer reply to your post #30 above but it was apparently censored and deleted by Forum "powers that be". It was there, then it wasn't! No explaination.
This one may suffer the same fate.
Well, let's see now......my inference in Post #4 was that a "barometer model" wasn't required to do what the OP planned.
In excess of 30+ posts later, you came to the same conclusion.
Conclusion: Common sense and real world experience is just as accurate and is faster than pseudo (un)scientific dribble.
(and wastes fewer pixels)
You answered your own question(in #26) with your post in #27.
Go back and carefully read #20 & #21 and you will see several conflicts in #14.
The importance of user settings cannot be overstated. based on why certain settings are made and for what purpose the unit is being used.
(Perfect example of that is Post #29.... completely different "ballgame") Note: ATIS info is broadcast continuously and the broadcast phonetic ID is changed every hour on the hour so that pilots can be assured that the info they have is current.
Your post #27 is correct and does not conflict with anything I've posted....... except, I wouldn't use the term " assumes". The unit displays exactly the data that the USER has told it to do by settings. The user must understand what settings affect what. Again, #27 is correct.
You do know how to read both GPS Elev AND Baro Elev on your GPS even if your model doesn't have an available GPS Elev "data field" don't you?
Here's a "quick and dirty" real world application since I don't participate in pseudo intellectual stuff.
On your way to the trailhead, turn your unit on and let it "settle in" with a good "lock".
At the trailhead, clear it's brain and calibrate the altimeter by using the GPS elevation value.
(Be sure you are using variable elevation and auto calibration)
(Think about that, since the GPS elev value is the value that the baro elev is going to be adjusted toward all day, why not start there?)
As you hike all day, up or down 2000-3000 ft, have a weather front come through or not, whatever...the auto calibration feature compensates or "adjusts" for all of both variables. Both Elev values will be very reasonably close to being the same. That's the purpose of the feature, to compensate for variables that can easily be mis-interpreted.
When you arrive at camp for the night, immediately change unit to "Fixed Elevation". Now it is a barometer, and you can tell in the morning if the pressure has dropped drastically and maybe you should go back down, or if it's steady or rising and you can continue on.
In the morning, look at the Fixed Elev value. It should be the same as the evening before. Remember that number, because before you start hiking again, you need to change back to "variable elevation" setting. Note that when you do change that setting, if there has been a weather pressure change over night(very probable), your Baro elevation displayed will be incorrect.
Calibrate it using your known actual value and you're back on the trail again.
From start to finish, using only data/equip you have with you, no outside calibration data,etc, your tracklog will reflect accurate elevation data.
For Garmin users...that don't believe that the user has control over which data is reported in the tracklog....
Intentionally "mis" calibrate your unit altimeter by 1000 ft higher than actual.
Use "variable elevation" setting.
Use "auto calibration"
Start walking and recording a track. Watch your Baro elev. It will decrease more and more the further you go. Look at the difference between Baro and GPS Elev values on your unit as you walk.
Now, stop and change your setting to "Fixed elevation". Save a waypoint then continue walking further while recording the track.
Stop and save the track.
Go back home and download the track you just recorded.
Analyze the trackpoint data. The elevation recorded before the waypoint is Baro elevation. The elevation recorded after the waypoint is GPS elevation.
Also, assuming that you walked far enough for the auto calibration effect to kick in, you'll notice that your starting (erroneous)elevation was constantly being adjusted downward toward the calculated GPS (correct) value.
To the original poster,
GPS units without Baro sensors of course can only report GPS elevation. That is a calculated value from satellite position, just like horizontal position, but is the least accurate of the three axis due to being the most sensitive to satellite position and quantity of sats..
GPS units WITH Baro sensors can report both GPS and Baro elevation. However,the Baro MUST be calibrated before it can report any useable information. You must calibrate it by using (user input) either the known baro pressure at your current location or the known elevation at your current location.
So, the accuracy of the Baro elevation that your unit reports is TOTALLY dependent on the accuracy of the data that YOU INPUT. That is true at the start immediately after calibration. If you use the unit's "auto calibration" feature, you should still manually calibrate it to a / the "known" current elevation. It's not mandatory that it be exact, but the closer to actual, the better. Why ?, because that means that there will be less "error difference" to be corrected by the unit's "auto calibration" feature. Auto calibration is not an instantaneous "full error" correction.The correction"s" occur gradually , over time ......minutes/hour"s".
Based on your baseline input, and the pressure that the unit's sensor detects, the unit reports a Baro elevation. The unit also calculates a GPS elevation from sat data for every trackpoint ,just like it does for horizontal position. With "auto calibration" ON, if the unit detects a difference between those two values, it will use the GPS value to know which direction it needs to "tweak" the Baro Elevation value to get it in agreement with the GPS value.
Since this correction occurs over time and in small increments, it has a visual "smoothing" effect on the instant to instant calculated GPS elev results. That's why you really need to calibrate carefully at the start (that gets both values together) and then leave "auto calibration" ON so that weather related pressure changes aren't erroneously reflected as elevation changes. Baro elevation will never be any more accurate than the GPS elev. value that is calculated by your unit.....because that's the value that it is calibrated "with".
Walk at a steady normal walking speed when recording data. Steady = more consistent and accurate data collection.
Post #14 above is absolute proof in writing that many so called "experienced" GPS users DO NOT UNDERSTAND how their GPS units work or how to obtain accurate data from them.
But wait.....there's more....now for some real data:
Ambient pressure change in my area equivalent to 100 feet in a four hour duration this morning.
There are many parts of the country where a "wimpy" little weather front like that would pass through totally unnoticed......
Are you really ,really sure of your position on that?
OK if I respectfully disagree?
As you stated, you can recalibrate the altimeter by entering known elevation before you leave to get the two (Baro and GPS Elev) closer together. However, if you did NOT do that before you left, it would be the GPS elevation (calculated)data being used to gradually "correct" or "auto calibrate" the "Baro" elevation.......not the other way around.
Yes, the elevation axis is the "least accurate" axis vs the X and Y horizontal, but it is still more accurate than the Baro., and thus is (can be) used to "correct" it ...over time.
You can make the unit use one or the other in the tracklog by the setting "fixed or variable elevation".
@ECA & Red90,
Why the "Barometric Altimeter" model recommendation?
Isn't the elevation associated with each trackpoint going to be "GPS Elevation" whether or not the model of GPS has a barometer sensor or not?
Am I missing something here?
Yep, I've already been to that one (CC-11), and there is definitely a "pucker factor" getting to it.
If you read all the "finds" of the South Cold Shivers BM, you'll note that several are actual erroneous descriptions of CC-11.
CC-11 is on the same side of the road as the parking lot and CS Point overlook, while the actual So CS Pt BM is across the road and up on a small hill.
I've also been down in the bottom of the canyon directly below the Cold Shivers Point overlook, looking up at the two legged squirrels taking pics of the squirrel down in the bottom below!
"RIM" is the BM (one of the six) that had no reported finds since being monumented in 1934. That one is about a 7-8 mile round trip either of two ways to get to it. Found it and both Ref marks.
Thanks everyone for your comments. I now know to look "both" directions regardless of datasheet "instructions".
Maybe bad 'ole Garmin needs to start a Psychiatry branch for "Defective Users"
It's Garmin's programmers who are certifiable, not the user! Designed obsolescence should be in the product, not in the company!
The market place will ultimately determine their "Defective Users" future purchases!
Based on Garmin's market share, it already has...........
I hope you guys are right about the bot. We don't officially start selling recreational weed here in Colorado until Jan 1.
I'm sure glad you qualified your statement with the secret code word "Officially".
"Happy Grass" is apparently the platform that Boulder and Denver vote on......for several cycles now.....
I live near Colorado Natl Monument and decided to do a little project of finding the six BM located in the park. I found all the BM and all the reference marks (except two that I haven't been back for the second time). The second trip to some to locate the ref marks really should have been unnecessary except for the goofy location descriptions. The question is, why are the descriptions given that way?
One of the finds was easy but some require up to seven mile round trip hikes. Naturally, the easy one was the one with no Ref marks. Been there, done that, so it's all in the past , just wondering "why" on the "official" descriptions.
KMO443-E BLACK RIDGE-
KMO456-COLD SHIVERS PT- No Ref marks
Note that all are described as "set(however) XX dist" FROM the station, but then the bearing given is only correct if taken "FROM" the RM TO the Station, so it's the reciprocal.
For exactly the same reasons you mentioned, I would not assume that the moving /stopped time calculations are correct. The unit is picking up reception errors and interpreting those as position change ie movement.
I agree with you ......there ought to be a way.........
I just "save" a waypoint when I stop so that I know exactly where to "select" and delete the "bird nest" of random trackpoints (and the waypoint) when I get back home and edit/clean-up the track.
Do it by time or there will be weirdness, for mathematical reasons I am pretty sure nobody cares about here.
I prefer between every 10 and 30 seconds.
Now Fizzy......you KNOW that "wierdness" almost always is more attributable to operator error or Murphy's Law than to "mathematical reasons"......HA!
Look through all the forums and you'll find that most of the displeasure is not really about problems related to "GPS".
Most of the whining and B'ing is about the "paperless" and other "Game Controller" issues, so NOT GPS related.
In THAT half of the puzzle there are waaay too many nuts and too many squirrels....... and not all of'em live in trees.
Right now I'm on my 13th GPS......the last 12 have been Garmins, dating all the way back to S A.
NONE have EVER had to go back for repair and they've all been used both professionally and recreationaly DAILY.
NONE (of the 13) have EVER been dropped....NEVER
ALL have screen protectors on them and NONE have ANY scratches on their screens.....NONE
Together they all have been used to map literally several thousand miles of trails with excellent accuracy and repeatability (sp)
Does this tend to make you think that maybe the wrong thing is being "fixed".
Maybe bad 'ole Garmin needs to start a Psychiatry branch for "Defective Users"
Oh, never mind....here's a better idea.....just go ahead and buy a Delorme or Magellan........that'll Fix'ya.....Bigtime!
You'll know better than I..... I just went through this same exercise and was unsuccessful the first couple of times. Seems the reason was that the file size for the tiles selected was too big and the installer for Windows wouldn't work.
File size limit for FAT32 ????
May have to split US into E & W and consider as separate maps ?....at least to install into Mapsource/Basecamp.
I fould a single file of the entire USA that someone had already done(can't remember what site)but it was just the ".img" file (Without the Windows installer) that could be placed directly on the GPS card.
In your original post , you asked about getting the most accurate "Mileage". In one of your "reply" posts you asked "which is most accurate, odometer or track?"
Those are two different questions which require different answers, which, surprisingly, both have already been posted!
Timpat likes "Auto and more often" and RMB likes" Time and 1/sec". Both are "correct" but under different circumstances.
"Auto and more(or most)often" method will almost always record the "closest to actual" DISTANCE.
"Time and 1/sec" will almost always record the "closest to actual" SHAPE.
Odometer uses the 1/sec logging interval.
The logging 1/sec logs so many points that any and all GPS error caused by carrying method, canopy, terrain,etc gets added in and ends up as "extra length". More points = more opportunity for error.
On the other hand, if there are too few points logged, corners and curves are "cut" resulting in less accurate "shapes" and shorter distances (than actual).
"Auto and more(or most)often" automatically logs fewer points when you are moving in a straight line and more points when you are changing direction (corners and curves). Generally speaking, this is almost always the "best compromise" or "closest to actual".
Timpat is absolutely correct in suggesting to "clean up errant trackpoints" if you want accurate data.
You want both distance and shape correct?, ....or want to find out which is best for your purposes?.....easy fix....carry multiple units simultaneously, set differently and see for yourself!
On and on and on......
So far, it has taken 30 posts to get to Fizzy's last post which describes what should have been obvious in the beginning.....
Set unit to "True North" and forget it.........
Did you select any exceptions or so??
Routing should ba as good as Garmin's.
No exceptions , absolutely default.(and no via points) I can change to the (OSM) routable maps on my GPS or (the same on my Virtual GPS on thumbdrive) and routing's fine. That ia an img file of whole USA.
I can select the route, go to advanced , recalculate .....does it's thing but comes up with the same route. I can then change to different map, same route shows up, but when I do the advanced,recalculate thing , it recalculates and produces a good/reasonable route.
Must be bad routing associated with just this download or just this map.
I selected and downloaded a rectangle "chunk" that gets CO,AZ,NM,KS,OK,TX. Everything went well and installed fine in Basecamp.
However, I started with a simple little route between Grand Junction ,CO to Dallas, TX and found the "Routing" to be TERRIBLE !!!
I'm not talking about a minor highway choice here or there. I'm talking about completely "Off the Wall" choices that literally more than double any reasonable common sense choice of route.
GJ east all the way to KC then south and immediately west thru Wichita KS all the way back to Amarillo,TX, then south thru Lubbock TX, then south to I-20 and back east to Ft Worth......
If I change to a different routable map in Basecamp, with NO OTHER CHANGES in Basecamp, a reasonable route is chosen.
WAAS or GLONASS?
in GPS technology and devices
YOU (several) HAVE GOT TO BE KIDDING !!!!!
Totally unbelieveable! I've got several units with the same kind of latch. Batteries have been in and out thousands of times. I can take batts out and turn the units upside down and shake, rattle, and roll as hard and fast or as long as I want and card will never come out.....never!and with NO TAPE!!
Now, these instructions are EXTREMLY difficult.
Open the back of your unit.
Take batteries out.
Now this one is very important........Put your glasses on and / or get a magnifying glass.
READ on the little stainless steel door covering the card slot.
It's a four letter word.......LOCK.....and there is even an arrow ---->.
When you put the card in, close the door then slide it in the direction of the arrow to LOCK.
Card will NOT fall out PERIOD...EVER! .....even with no tape.
To remove the card, first slide cover to unlock position, then open to remove card. Or you can just turn the unit upside down and shake and it will fall into your hand , or onto the ground or into the snow.
If the door is loose in the lock position, it's because someone has forced it open without unlocking it first and distorted it. Re adjust it's shape and use it the way it's supposed to be used.
Now, don't all of you raise your hands at the same time, but, How many of you didn't even know there was a "Lock" position that cures your exact "problem"??
Yeah, my tone may be a little condecending, but you have to realize that this is not a new "problem". How many models have exactly the same type card latch? It's NOT a latch problem, it's a USER problem.
Some users can read, and some choose not to.