Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Grasscatcher

  1. I know I have never had, and I doubt if you have either, a GPS that acquired a totally accurate lock immediately on "power up". It just doesn't happen..... With all the gpx checking, and map loading, and other tasks, the starup times are much slower than before. It has to start from somewhere (last known location) or otherwise it would be like a "First time acquisition" every time. Long....... Reseting trip data and clearing Current track are so simple a fix that I can't understand all the hoopla.
  2. Here's a post I made over on the Montana wiki: Since I don't get the straight lines because I "clear current track" and save, I went back and checked a bunch of downloaded Archive files. Voila! straight lines !, so I did some investigating....... The "saved track files" are totally clear. The archive files for that same date start off with a straight line! Those straight lines "go back" to ("at least Very close") the location where you last turned the unit off. They don't actually "connect" to the previous track....at first, I thought they did until very close inspection. Sometimes it's only a single point or few points and sometimes it's a few more, depending on how long it takes to lock onto a good fix. Even with the Archive period set at daily, when you turn your unit on for the first time of the day, it starts logging (it turns out that they are lousy) points based on where it was last "ON".....until it gets a sat lock to update it's position. Same concept as when you move a long distance between GPS usage and it takes longer to lock...... It does the same thing "during" the day but to a lesser degree because it locks on quicker. You can figure it out by zooming in on your computer. The difference is that NOW , with Archiving, those "first" lousy points get "captured" for posterity, and are included in the archive file. It is NOT including random points logged the previous day in today's tracks, as some think. It is just "starting" with it's "last known" location until it gets enough sat data to correctly determine it's actual location. Why is it different now than in the past? Because new units take much longer to initialize at startup, They have to check all the gpx files for changes, load maps, etc etc. All the while, they start logging points based on previous location.....That's the same as it's always been, just a longer process now.And....those points get saved in the archive. So......power cycling all the time actually makes the situation worse. It is constantly having to start from a different location than it's memory says it was/is. The slower the startup time, due to GB after GB of maps, and tons and tons of (mostly worthless) Archive files, and "elebenteen thousand" Caches......the more bogus trackpoints get logged before a good fix is acquired and then an accurate location determined. If you turn your unit off one night and don't turn it on until the next day, those points and straight line are included in the archive file for that "next day" (at the beginning)....because that's when they were logged (at the first "ON") That also explains why I DON'T get the lines and others do....because I ALWAYS "clear current" before logging. and dating all the way back to a 12XL I have ALWAYS turned the unit(s) on for a "significant" period of time to get a solid lock first and, even then, do a "clear" to get rid of the "lousy initializing data" before starting to log a track.
  3. You are correct, one at a time.....and that's probably why it's called a "Trip" Odometer. Just for the record, I too agree with the complaints that the extra mileage gets added to all the "odometers". It shouldn't. If it didn't get added to BOTH, then Track Distance could be used for an "overall" odometer and Trip Odometer for individual specific trips, easily reset as desired. I "believe" that was/is the original intent, and also, somewhere in the menus the unit need to specify clearing "Track Distance" instead of just have it happen lumped in with Clearing Current Track, but only from certain places.
  4. No problem. I understand where you are coming from. Your method DOES solve the track problem, and I totally get that and have figured out how to avoid it. However, for the life of me, I cannot yet solve the odometer issue. Even with all tracking completely disabled, cleared, and turned off, the excess mileage still accumulates to account for distances traveled between power cycles. I'll keep playing around with this archiving feature and if I find it's a workable solution for the odometer too, I'll tip my cap, but as of right now, no luck, and no feedback yet from Garmin. No the archive period won't fix the Odometer. To fix the odometer, reset to zero at the beginning of what you want to measure. And for the Track Distance, that has to be zeroed by "clearing current track" at this page specifically.... Trip Odometer\Reset\Clear Current Track . Note: The Track Distance can also be zeroed at the "Reset" page on main menu....BUT NOT from the Track Manager page\ current track\clear current track. Don't know why that is but Garmin is investigating. Need to be able to clear both back to zero by setting up a User shortcut for a one touch fix. Setting both of those back to zero at start, will fix the added mileage and the wonky speed data.
  5. @GPSNAV12, Please do not take anything I say as a personal attack, definitely not intended that way. I'm just not very P.C. Are you aware that "clearing current track" from different places within your unit clears or doesn't clear the same data? Are you aware of the difference between Trip Odometer and Track Distance? and how to clear / reset each separately? On a Montana have, you tried to set up a shortcut to do several functions with a single button press? There is a VERY logical reason to log tracks and mileage in this manner and then give the users options and capabilities to to customize their units however they like. That is exactly what they have done. Right at this minute, with Garmin doing absolutely nothing more to /for your unit, you have the capability to NOT get the lines, and for your Odometer to work properly(well, at least not have the extra distance added) Doing a power cycle as a "Fix all" like back on some older models, is a thing of the past. It cannot substitute for correct unit settings and correct operating procedures and timing. There are waaay too many different possibilities. Completely and totally different systems. Can we agree to disagree? Based on your answer above, you "Do Not" understand the "Archiving" function and how it works. See how nice I can be? I didn't even mention being called "Obnoxious" and my attempts at trying to describe a solution to perceived problems being labeled as "Meddling". I'll get over it......
  6. Those examples are great EXCEPT for the label at the top that says "This is the issue:" No, "The Issue" is that some users are so convinced that there is a "Bug" or "problem" that they refuse to understand what they are seeing and how easy it would be to "fix it" . It's one of those "don't confuse me with Facts 'cause I've already got my mind made up" kind of things..... Using your examples.... Power cycling and "moving for a few seconds" at each of three points should produce exactly what it did because of Archiving. (with ANY of the Auto Archiving user choices) (should also produce extremely lousy accuracy data) Now, when you "cleared the track log" BEFORE LEAVING WPT 3 , that's where you screwed up. Wait to clear until you get to the next trailhead or waypoint location. When THERE, "clear track log". What you are doing is clearing the unit's brain of unimportant data that occurred after wpt #3 and while initializing at your new location and any data that occurred while your unit was off. (you changed locations !) It's not just a matter of WHAT you do , it's also important WHEN you do it. Now, NOTE CAREFULLY.....clearing current track FROM THE ODOMETER PAGE clears the Track Distance but does not reset the Odometer. If you want the odometer reset, then RESET it. Check out the different places you can reset it and note that it does different things from different locations. NOTE that if you "clear current track log" from Track Manager, it DOES NOT clear the Track Distance. Your odometer correctly showed that in fact your new location was 20+ miles away from wpt 3 because it logged a few trackpoints after you cleared the current track but close to wpt3 before being turned off, then, when turned back on it started logging points while it was initializing, then (because of archiving) it tied those two locations together. Don't like that? then just clear current track at the second location and "reset" your odometer for a clean start. It is, after all, a "TRIP" odometer for recording data for that specific TRIP.
  7. As previously stated above, Archive is just your "History". Depending on your "Auto Archive" setting on your unit, it creates a separate gpx file for each specific period (daily, weekly, when full,etc) Just create a new folder on your PC in "My Documents" and copy and paste those gpx files to that folder. Then you can delete them on your unit (with Windows Explorer)(or Mac equivalent) Then sometime when you don't have anything more interesting to do, you can open each of those individual gpx files with Basecamp or ??? on your PC or Mac and check them out. You'll find that a bunch of the data is just junk, but some of it you may want to keep. Either way,deleted or kept, you haven't lost it and it can't slow down startup if it's not on your unit.
  8. Yes, and that is the way older (60 / 76 series units) worked (new track file with power cycle) ....... BUT....and everyone seems to forget this...that was before "Archiving", and before ALL the track data being saved when a track is saved, and before file structure "tree" being changed, etc,etc,etc. (newer units are much more capable of storing / handling much more data) In order for the "unit to decide if a new track should be started......based on...."...... That would have to be based on your settings, correct? So, since you are in complete control of whether you get the connecting lines or not RIGHT NOW....... change your settings / procedures !
  9. Changing batteries in the middle of a hike? Now that would be a major power interuption! SOMETHING "better" start over / create a data break / etc! MY way????? I was simply asking questions to get info to see if i could duplicate "the problem." I don't get the straight lines and neither do I end up with two duplicate? tracks, so just forget my post. I'm not the one with "the problem" Let's see here now....don't want one single connected track and don't like two tracks....Hmmmmm ????
  10. NOT FIXED. I was hiking today and still getting the excess mileage on my trip odometer. It's the same incorrect functionality it's been doing since inception. I know not all agree, but I just don't get the logical sense for the units to log mileage and tracks in this fashion. Contacting Garmin, for what good it will do. This was my experience also. I reported to montana.beta@garmin.com I want to try to see if I can duplicate the problem. What is your auto archive setting set on? Which specific "data field" do you see the extra distance being added to? Trip odometer or Track Distance? or another field??? Did you clear current track log before starting first track? If yes, what page did you do this operation from? Did you "save track" at the end of the first track before traveling to second? Did you reset "trip odometer" data to zero before starting? (both before the first and also before the second?) Also did you also "save track" at the end of second track? Did you also reset "Track Distance" data field to zero before starting? (both before the first and also before the second?) (Need to very specifically verify that this data field is zero before starting second track....)
  11. @ Sgt Strider, You asked how to merge GPX FILES ,,,,,,,and "they" are answering how they would merge different DATA WITHIN a single GPX file. Different animals..... I use Expert GPS by Topografix to merge GPX files all the time for keeping a "Master" file of data contained within multiple individual GPX files.
  12. Track log connecting straight line example. Let's say I have three separate trails to map today and tomorrow, and do not want them connected by the dreaded artificial connecting line. I have my "auto archive" period setting on my unit set on "Daily". Note: I ALWAYS have "track logging" ON, and set to "Record and show on map"..ALWAYS......Also, always set to auto, and most often. I turn my unit on at home to be sure that I have several specific waypoints loaded in the unit, and to check the battery level, and whatever... As soon as I turned it on and it locked onto sats, it started logging a track. Inside the house it's lousy condition, so lousy accuracy, etc but logging still. I turn it off, and drive to a trailhead 10 miles away. At the TH I turn it back on, .....immediately, (after sat lock) it draws a straight line between it's last position (at home) and the TH. (because as the user), I've told it (Daily archive setting)that I want it to keep all the track data within this period (each day)"together" as a lump for preservation. (long term saving) Now, at that point, you have a straight line on your screen. Don't panic! It connects the "junk data" at home when you were checking the unit, with the "junk data" at the trailhead logged while you were getting out of your car , getting your poop in a group,etc. Walk to the trailhead proper, where you want to start saving data. AT THAT POINT, go to Track Manager, Current Track, then Clear Current Track. (It will ask you if you're sure,...yep) If you use it, reset the trip odometer here also. Now you're ready to walk down the trail, look at your screen. NO STRAIGHT LINE ! The one that was there before, is gone. When you cleared the current track, you deleted it, and the junk data logged at home and also the junk data at the TH. What you are left with is a nice clean start to your track, with no connecting line, At the end of the trail,where you want your good/valid data to end, stop and go to Track Mgr , Current Track, Save (either rename it or leave default "date name"). If you use the trip odometer then you need to write that info down also because it only pertains to this specific trip. Go to your next trail head.....either Feet, Miles, or 10X miles. If you turned your unit off at the end of the last trail and turned it back on at this one, then you'll have a straight line connecting those two points. Again, don't panic.....that's just junk data anyway. When you get to the trailhead proper on this second trail, repeat your actions from the first TH. (Track Mgr,Current Track, Clear Current Track, Yep) Now, think about this,....understand that you have all the track data from the first track preserved. Saved as a separate track. When you Clear Current Track this time, what you are deleting or clearing is the ongoing "Current Track" "COPY" of that data AND the junk data at the end of the first trail AND the Junk data at the beginning of the second, and the Junk line connecting them. At the end of the second trail, save it and "drive on". Next trail, whether today, tomorrow or next week......same o, same o, being sure your actions are the same, in the same order, and at the same "point in the process" Always clear "current track" before starting to log data you want to save. Note: If you wanted to preserve the drive route or path between the trails, then you have to leave your unit on all that time and actually log that also (can be treated as a separate trail and saved separately). Save your last track of the day just like the others. Why? When you get home and are going to download the data on the same day,when you're ready to download (but before actually downloading), do the "clear current track" action again. What you just eliminated is just the (Current track)COPY of that last trail and the connecting line between the end of that trail and your home. I hope this helps.
  13. @ Red 90 and A C, I,too, am not "arguing for", just stating that that is the way it is now supposed to work, and explaining why it's doing it and telling "whomever that doesn't like it" how to "fix it"....(not get them.) I'll explain below why it's really no big deal (at least to me). Red, Which model units don't get them and which do? Models like old 60/76 series ? Models after the file structure change ? I believe that the 60/76 series started a new "active log" file with every power cycle. Models when the ability to "archive" started? AC, I don't understand what you're talking about ......." easier to join tracks after the fact than try to find and remove individual segments and points within the hundreds and thousands you want to keep." Aren't you complaining about the long straight lines that connect two separate trails, some distance apart"? On my PC I use Expert GPS. If and when I rarely "get them", because of something I've done or not done, I just "select" the track (in the straight line portion),right click and choose "break track", and it(the straight line) is gone. Literally in one second..... There are "Zero" trackpoints on that connecting line, so all that is removed is just the connecting segment. For on the PC, Garmin could do the same thing with Basecamp. Right now Basecamp doesn't work exactly that way. When you "divide" the track, it takes that segment ,with the trackpoint on each end and makes (those two points and that segment) a separate track.......kinda a goofy way to handle just dividing a track. But if I'm understanding things correctly, you guys are mainly complaining about seeing the straight lines on your GPS units......right? @ Mtn Hermit, What was/is your archive period setting? (Mainly for the example above?) As Sussamb said, if it had been set on "daily", those two tracks logged several days apart would NOT have been connected/tied together.....or the mileage added. Here is the part that I flat cannot understand...... RIGHT NOW, right this instant, without Garmin having to do ANY changes, you users are in COMPLETE control of whether or not you get/see the "connecting lines" on your unit.....so, If you don't want them, then don't get them! I have a 76CSx, a 78S, an Oregon 550, and a Montana 650, used for Daily track logging and I don't get the lines on any of them........unless I as operator screw up. If I do, and then have a connecting line when I download the data, no big deal ....a one second fix! I wish all my screw ups could be fixed that easy! I'll try to give an example in another post. I really don't think that many users understand their units.
  14. Hopefully this makes it to the OR x50 soon. Hopefully it works. I wonder if it will still draw the straight lines? That issue can at least be worked around by turning your track log off at the end of one segment, and then track on again once you've acquired a fix and started moving at your new location. I sure hope it still draws the straight lines.....that's the way it's supposed to work! The unit is "tying together" everything WITHIN an archive period. Within a week if your archiving is set on "weekly", within a day if on "daily", everything if set on wrap when full,etc. If you don't want them, then change your settings and your operating procedures. To eliminate the drawing of connecting line between day to day tracks (today & tomorrow's) then change your archive period to "daily". To eliminate the connecting line between multiple tracks on the same day, then "Save" the track at the end of each segment and then "Clear Current Track" immediately before starting the next.
  15. I was wondering if the GGZ format "in concept" might be similar to the GPI format (and possibly with a new "loader") where the only limitation is the size of the memory card. I'm not a programmer so I don't know if that would even be possible. I'm sure changes would be required to handle the different functionality required for caches instead of POIs. The current "POI loader" of course converts a GPX file to a GPI .
  16. It's very predictable what happens when entities get overly paranoid about proprietary "things". Look at Delorme and Nat Geo.......
  17. Why do you say that? I don't have that (software program) and I just hooked up my 76CSx and my 78S by serial cable to my laptop and in TOPO! I went into Handhelds, setup auto tracking and it started tracking. Immediately my position showed up onscreen.
  18. I can't remember if the Venture H has a serial port or not....... (round 4 pin Garmin connector) What is required to do what you want is to use one of the (older) Garmin models compatible with serial cable. (old e-trex, 60 / 76 series and other older models) Don't believe it can be done hooking up with USB. Unit must be set on "Garmin" or "Garmin Serial" (not nmea in/out, spanner,etc) under Main menu/system/interface. I just did it with my 76CSx and my 78S and it worked perfectly.
  19. @ Don J, Thank you for injecting actual common sense reasoning and actual facts ......that is refreshing! Your explanation is why, that when I am hunting "accurate, adjusted location Benchmarks" with my compass turned off, I still try to approach GZ from several different directions, just to try and verify that my unit is "telling" me the truth and that "IT" truly understands where it is and can "repeat" (with itself). I have examples of waypoints that were marked simultaneously ,at exactly the same point by multiple GPS units on a very narrow single track trail, NONE of which accurately describe the actual spot. All three are incorrect and it's surprising how far "away" "They thought they were". (100+ ft and all different) All due to multipath error.... By elimination of the multipath, I since have been able to get the correct trail location as well as "spot" location.(and can "repeat". The user must be able to recognize when the unit "may" be lying and what changes in settings or procedures possibly need to be made to correct for those errors......that's why I referred to "thinking persons tool".
  20. ..and the 'stuff' MapSource does will be done improperly. Example: MapSource only knows how to read a single GPX file from your GPSr, 'current.gpx' Older GPSr kept all GPX information (waypoints, tracks, routes, etc) in the 'current.gpx' file, while newer GPSr keep all this information in separate/individual *.gpx files. Your Oregon, Colorado, Dakota, Montana (etc) keep only the current track log in the 'current.gpx' file. If you use MapSource to send data to your newer GPSr, it will be added to the current track log file. Clearing or deleting this information on the GPSr may result in a loss of all this information. If you save a track log, mark a waypoint, or otherwise save/edit information directly on your newer GPSr in the field, the information will not be saved in the 'current.gpx' file, and MapSource will NOT be able to import the information. If you use MapSource to send maps to your newer GPSr, you may not get all routing and POI information as MapSource is no longer in development and can not read/use all information from newer Garmin maps products. MapSource can not be used with BirdsEye imagery, nor can you edit information on your GPSr directly from within MapSource. The list goes on and on..... OMG !!!!!!! The answer to most of the above insurmountable !! problems!! is one simple thing.... known as Windows Explorer. Put what you want on your unit where it is supposed to go ! Get what you want to get from your unit from where it actually is ....not from some obsolete location on whatever unit you used to have! The "list (that) goes on and on" is really VERY VERY short and easily manageable. Over time I have used more that 20+ different programs to convert data from one type to another, to make data from one program compatible for use in another,etc,etc. Do you really think that they all work exactly the same? GET REAL ! Mapsource & Basecamp are different programs and work differently, but BOTH WILL WORK .....and that is all that has been said above. A GPS is supposed to be a thinking person's tool.....based on some of the above posts, there seem to be some people that don't qualify.
  21. Read the part...."Depends on what data you're working with and what you want to do with it." Talk about deaf ears................!
  22. Sussamb is correct. 76CSX,Oregon,78S,Montana .....any/all will work with either program. Depends on what data you're working with and what you want to do with it. Basecamp is probably less hassle for newer users and the differences between the two are more hassle for older users...... Basecamp started out as a real PITB....but is slowly improving. It's almost to the point now of being worthwhile to occasionally use for a specific purpose, but not often enough to stay familiar.
  23. I am curious. How do you think the GPS knows so accurately what direction you are walking? Totally mathematical calculations based on satellite location signal triangulation.
  24. @7XRC, "Being able to recognize what one is looking at on the display and use it is a user responsibility and and is up to the individual." You are absolutely correct......and the fastest way for the OP to have determined what the problem was would have been to turn the compass off and use strictly the bearing pointer. It would have lead him straight to the correct coordinate location.......then it would be a matter of figuring out what was causing the interference with his compass. A VERY high percentage of GPS "errors" and "problems" are operator error......I'm not being personally critical.......it's just lack of experience,knowledge,understanding of what the unit is telling you and why. The more variables that can be eliminated until a higher level of proficiency is reached, the better.
  25. also read my last post above @ J E C, ??? What "two points that could be 30 ft off" are you talking about? Surely not the "go to coordinates"....because even the e compass uses those for establishing its reference. You can never eliminate the possibility of those being in error....never! That's why in my post above I mentioned hunting Benchmarks, while I failed to mention only those with adjusted coordinates. The procedure is the same, just that you might be zeroing in on an erroneous location with GC. IMHO the bearing pointer is still the most accurate....for reasons mentioned above.
  • Create New...