Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by robertlipe

  1. Bumping a 9 y/o thread with a request and then leaving the topic hanging was indeed a bit weird. The bit decay in these 15+ year old devices means that a lot of the links you can find (maybe to gawisp, gpsworld, gpstracklog, or many others that are just plain gone instead of decaying) don't work. Some of the links you can find are in such sketchy corners of the world that it'd be wise to question their content. Builds like 4.20 for CSx that never even hit Garmin's own site are particularly hard to find. It's likely the above request isn't coincidental with https://www.gpspower.net/garmin-receivers-firmwares/243359-gpsmap-60csx-chipsets.html#post1220015 . I'm not registering to see if any of those links pan out, but they at least look llike warm leads, but there are a lot of forum links referencing this version number that ultimately brick their units, too, so maybe it's hard to find for a reason. /shrug Even in my mad stash of a quarter million messages and files from various yahoo gps groups, I can't find a downloadable/executable form of that update.
  2. I clicked the button indicating this answer was "helpful". I suggest others finding answers, well, helpful do the same as a way to surface the better answers/answerers in a lengthy or contested post or just as a way of thanking them for helping fix a setup issue on your personal gear. If you're familiar with geocache favorite points, this is kind of the same, but this section doesn't make much (enough) use of it. Thanx to our product experts!
  3. GPSBabel, a favorite of geocachers for almost 20 years, supports the C/Cs and CSx/Cx family. It's true those models don't let you load cache pages but millions of caches were found before that was a thing. You'll spent some time fussing with drivers, but it's nowhere near the frustration of a serial era Garmin.
  4. There is a lot of seemingly well-intended chit-chat here, but 90% of this thread is off topic. Please try to offer something helpful to the OP and not just chastise them. That generation of GPS required a driver provided by Garmin to work. I think it's this guy: https://www8.garmin.com/support/download_details.jsp?id=591 This driver is required for any software, whether Basecamp, EasyGPS, or GPSBabel to work with that hardware on Windows. Please confirm it's installed. The suggestion to try GPSBabel has merit because I think every error condition it (that isn't a crash...of which we have none reported for years) has an error message associated with it. That said, we either get packets or we don't and we can either talk to the driver above or we can't so we can really only recommend kind of hand-wavy things like rotating USB ports, different cables, cleaning the gunk out of the USB connector etc. Good luck
  5. For most of the last twenty years, the answer to this question has been basically the same: Choose between a touch screen or a dpad. With that decision in mind, choose between the best Garmin in your price bracket or a ruggedized (at least case) smartphone. In the first decision tree, it's largely personal ergonomic preference. For people in cold, gloves may influence the decision. Goldenwattle has the right idea in looking for ergonomics. Comfort matters. A device that won't fit in your hand will get dropped and all of these are too expensive to be casually dropping 20x a day. For the second, Garmin is pretty much the only one standing in handheld geocaching GPS receivers for a long time. There is no competition in tech or price, so there's been no real motivation for them to improve on either in many years. I suspect their update schedule is driven mostly by when parts they rely on become unavailable, so they're kind of "tail-driven" on hardware. These forums are filled with advice on phones being the best ever because you can use external battery packs and you can get live updates and you can run multiple apps that are actively maintained. Or they're the worst ever because they don't bounce off rocks very well, they're hard to see in sunlight, or you can't just pop the cover off and replace batteries. Or there's the chorus of "real" GPS being the best ever because they still use plain ole AA's that you can get at the grocery store so you can hot swap them. They're also the best because they can have a full Quad Helix or even just a large patch antenna and the GPS receivers tend to receive more constellations than "just" the phones which have a GPS that exists mostly to direct 911 to your burning car and to direct you to your hotel for the night. All of this is pretty much true. The models in the boxes change a little bit over time (Oregon 400 vs 500 vs 600 vs 700, or 62, 64, 65, 66 or Samsung ${INTEGER}) but the basic flowchart hasn't really had any different players in almost 15 years now, I think, when Magellan and Rand both made dying gasp entries into the market in the late 200x's. For the third point, price is always an issue for some cases. It's no longer the case where the difference in a $150 unit and a $600 unit will paralyze you vs. jazzing you with glitter and eternal rainbows. An eTrex 10 is unnecessary self-torture. The middle range eTrex was basically the top of the line features from a few years ago, but they cripple the driving features on them. If you have to buy City Navigator for ANY of the Garmins, remember that a Nuvi/Drive "LMT" unit will include lifetime maps, be about the same price as one individual map drop, and be a WAY better driving experience. (Oh, this is an area where smart phones have a HUGE edge. Apple and Google Maps driving experience is just a beatdown...and self-updating for major features all the time.) The remainder of the decision in the $300-$700 range is touch vs. dpad and dialing in the maps and other features like cameras. Garmin makes the niche units like Rino and Inreach, but they're really not for geocaching, so they're off your table. GPSRchive is one of the last GPS sites still standing and a good site for news and honest lists about known defects. The market has imploded and become so boring that a lot of the GPS tech sites that were thriving early in the century (GPSPassion, GPSTracklog, Laptop/PDA world, and several nerdier ones all are gone) Compatibility is pretty much a solved problem. I have the #1 program in that space and I don't have any questions or wishlist items for funky hardware while I had several a week in 2004. That's all a side effect of there being only one maker and slow change these days. If you were happy with your 450, you'd likely be thrilled with a 700 or even a used 600. They're SO much faster and that capacitive glass multitouch screen vs the resistive screen on your Oregon bring it forward into the 2010's. The UX would certainly be familiar to you. It seems like there should be an 800 "soon" becuase the 700 is five years sold (see also: unchanging market) but given their history of problems with new products, the Oregon 700 is kind of the "the devil you know" at this point. The basic formula of "what should I buy" has been the same for a long time and it's been hashed to death in this group before. If someone less jaded than me wants to write a definitive "what should I buy 2020" post, I'll gladly change that pinned post to point to it. Cover the above matrix and try to be somewhat balanced between phones and dedicated hardware, and you're probably "in". Good luck on your purchase.
  6. Seriously. Does anyone else ever get the urge to just drive to Olathe and start wandering the streets until you find a software engineer at Garmin and actually take them geocaching with their own devices? If it is a case where the UI is blocked behind a thread stalled on an SD write and is able to pull the same record again before noticing that this one has just been shot down, that's really silly because it means their design has multiple sources of truth for a really fundamental data item. That's not a case of a missed mutex; that's just a bad design. (Duly noting that speculating about design from speculation of bug sources is a bit silly....) A human should never have to count bananas between actions on devices of this kind of computing capacity. I do remember seeing variations of this as far back as the 450. (I stopped buying at the 6x0 as that's also when I 'retired' from geocaching..) The "mark as found and find next" process has long been a frustrating mess of required keystrokes, muscle memory, and flakiness. I do remember conditioning myself to either bounce back to the map to select the next, which always seemed immune from this weirdness (and was often more strategic when power caching in a city) but that was a long time ago in tech years. So I can't offer anything actionable on the 700 specific (sorry - I'll moderate myself as unhelpful) but I will offer a sympathetic shoulder that this seems to have loooong been a problematic code path for Garmin, even if I'm being charitable about the frequent full-device crashes in this general area that persisted from Colorado through at least the 600.
  7. The non-field-replaceable battery thing isn't as cut and dry as it used to be. When I needed three laptop batteries to get to my office (I had a tough commute...), I could swap that battery with my eyes closed, under the seat, and without lifting my seat back tray. Now that I can compile AND watch video for 20+ hours, I no longer care that I can't swap it. I can't testify if the situation with the 66SR is similar, but it IS possible that the increase in energy density in the chemicals used and the improved physical shape (look at how much space is between two parallel cylinders) can make the experience so much better that you won't miss being able to swap them. You'll still need to plan for cases like not starting the day on E because you can't just pop another set in from the quick-stop on the way, but the common charging "bricks" or even lipstick batteries (usually a single 18650 cell) can probably charge a GPS several times. Spinray has apparently been outside caching and not inside reporting back on his impressions, but IMO he made a good call. $150 for a used 60CSx in 2021 (that's the 2006 version of a 2004 model) just doesn't make sense. That was a workhorse of a GPS, widely used in this crowd, but tech just isn't a place to be sentimental for tools you use. Good input from lots of views here and nobody got nasty, so gold stars for everyone. Executive takeaway: Don't be dismissive of change.
  8. robertlipe

    Garmin GPS

    This is all pretty silly. Magellan's GPS business has been bought and sold from the edge of bankruptcy a few times since geocaching started. The Explorist you're talking about isn't even their first device named "Explorist". Competition in the handheld GPS biz is dead. Garmin's the only player left that's selling hardware in volume. For this generation of hardware, the "Magellan interface" is exactly like the Garmin interface at the protocol level. The device starts in USB Mass Storage mode, you copy a GPX file to it, you unmount it from the computer. Same between the two. Same as in 2016 when you joined. Same as in 2010 or so when the potato-shaped versions of the Explorist were introduced by Mid, the then-fresh owner of Magellan GPS brand, who has now completely exited the handheld market. The "new security" that we're talking about is the turndown of the Netscape Navigator era, which started very early this century. Connect the cable. Drag and drop the GPX file into the place GPX files go. Eject the drive. It takes seconds, with or without a voodoo button. That GPS works as well today as it ever has. I actually write software that's used in GPS markets way beyond Geocaching. I don't think they're actually selling many of what they DO list on their site.
  9. I've posted before how I'm reasonably sure the Garmins handle reading those files ... at least based on how I would build it based on my experience building similar systems. I'd bet strongly there's a SQL3-lite database (or something close to it) that gets (at least partially) clobbered on boot and then populated by GGZ and GPXs on boot. GGZ's contain a crc (the spec had ambiguity on how exactly it was calculated but as long as the same software cmoputed it the same way, it washed) so you could know to shoot down entries that had been seen in that GGZ from the last boot that now had potentially different contents The ordering that was in the Garmin spec I last saw was "undefined" and it's probably in the order they're last seen in the file walk and even within the same file. Last one in wins. Outside the files, the order is _probably_ the order they appear inside the FAT directory table, which is so hard to predict that you could never describe it or predict it so I'd also call it "undefined". I doubt it's doing any scanning at runtime, which is why boot on these things is so painful - pay for that file I/O and XML parsing up front and not on a map draw or a user touch event. So I think I agree with Minera'ls understanding (educated guess - same as mine) except I'd make the "last" instead of "first" be the authoritative copy that's kept in the master DB and that's dragged into the more efficient (likely a quadtree) structure so you can map them without killing that ARM core. Oddly enough, one of my hobby projects right now is programming an OS on a computer ... with 32K of RAM. I'm porting the OS that would have been about what was in use in the mid 70's. I knew the guy at IBM that managed the team that did the Fortran compiler for the 1130 - because I've programmed those, too. I think it was used on either 1800, too, but I never used one of those. Oh, and get off my lawn. :-)
  10. I'm the creator of one of the software titles mentioned and there was a time I could recite the bytes in each packet during a waypoint exchange. I generally agree that the serial units are simply too aggravating to try to use in modern times. The operating system and driver issues will just drive you mad. +1 to "LIfe's too short" A lot of the hardware - as you apparently just discovered - is so old that it's just dying of old age from metals separating or mechanical fatigue. GPSBabel still "supports" this era of Garmins but it's not like I test every model on every release on every OS any more. Several of the serial-era GPS units have serious issues with the GPS week rollover from last year and are just terribly confused about life after April, 2019. I had several people fume at me about this like somehow GPSBabel was supposed to fix their firmware issues. I have given serious thought to removing the Garmin serial support. The reality is that it's deeply entwined with the Garmin USB protocol support and I'm not quite sure that all of the 60C/76C/60Cx/60CSx are out of circulation yet. The Magellan serial support is still there because it's dead simple, but I'd bet that it's not been used in years. That code has tentacles from the Explorist 400/500/600 which are USB, but I'm skeptical that they are in use, either. Somewhat ironically, my other hobby is small electronics and in that world, USB/Serial adapters are _also_ the bane of my existence. Instead of spending a quarter for a "real" USB device that runs at a reasonable speed and is self-identifying, the preference is to build the CPU with a serial port and then spend a nickel on a USB/Serial adapter. This is why your new gizmo is indistinguishable from a Palm Pilot; they all just look like a serial port to the computer. :-/ Still, thanx for bringing closure to the conversation. So many people start these discussions and then don't post the final findings, even when that involves $25 to Ebay for a better GPS.
  11. Wild guess: Silicon availability? It's possible that Garmin isn't fabbing their own SoC; they're probably riding the coattails of high-volume products as used by tablets or phones. Sometimes an EOL (end of life) announcement catches you off guard and you have to pivot to a low-risk chip change that uses an "old" feature set or code base just to buy time in the market until your new product that's in active development can launch because it's held up by a part that's not available quit yet. So you do very little engineering on a "distraction" and product marketing and sales gets to herald a "new" product while you quietly discontinue the original. Maybe the QZSS and IRNSS receiver chip wasn't ready for mass production yet but the LCD panel or the processor or memory or *something* in 64 that they didn't absolutely control was headed for a rapid descent to unavailability, so they got the "b team" (sorry) to squirt out a 64 that they could actually manufacture at scale while they finished the 65. Maybe that had a contract they could win with the 64 which ticked all the boxes except Galileo so they just changed the receiver chip and base firmware to support that. This was pretty much the difference between 60cs and 60csx, if you recall. The "x" was just a better version of an already popular device. Over my time in engineering, I've been involved in several of these, both as the A team and the B team. I'm barely in the GPS biz at this point, but the 62-66 product line is so thickly saturated that I can't remember how they're different offhand. Using smaller integers for newer and more featured products is not helpful. No inside information on why Garmin does/did what they did. Just offering one possible explanation other than "drug use".
  12. Windows actually made some changes recently (in Windows years) to have fewer dirty blocks waiting to be flushed to the USB in case of an abrupt removal. See, e.g. https://www.howtogeek.com/410353/how-to-optimize-usb-storage-for-better-performance-on-windows-10/
  13. And this. This subject dominates our front page of active topics...
  14. Please see below. Between those two choices, the product that actually exists is the runaway favorite. :-)
  15. Quite interesting because they don't list the Oregon as a Linux-based product at https://developer.garmin.com/open-source/linux/. If It's Linux based, there are license obligations that they have to meet. These files should definitely be preserved for research's sake. It's certainly strange that the GPS would have files that are clearly for a Raspberry Pi. It's odd that there isn't really a recognizable filesystem, but maybe one of if the img files is like an ISO image or MacOS dmg where a "real" filesystem is married atop a lesser filesystem. Are you sure that this H: is the Garmin and not some other device that's plugged in?
  16. The piece you are asking for that I don't have is the PC code to send an upload to the 330. It was a special utility and I just don't seem to have it. Any other Magellan packrats out here able to help? PM Sent.
  17. Map330 and Mericolor used similar, but different firmware. The age of these units (~20 years) and the destruction of the yahoogroups archives, which held most of the wealth of info on GPS of this era, have made "classic" info hard to get. (I actually have a copy of the relevant yahoogroups on file...) If you have the version that came with your unit, the relevant part of a doc by Trainlove (!?!) seems to be: Open the firmware file, called something like mgold541.hex, with Windows WordPad or NotePad. When you save it be sure to save it as plain text. It is big, about 5 Megs. Search for 23232328 or if that is not seen, due to its crossing a line boundary, then search for 18181818. This is way down close to 90% of the way to the bottom of the firmware. Either will only occur in the one location in the firmware, and within a couple lines of each other, blanketing the area we want to modify. There is a small tutorial on Motorola S-Record files several paragraphs down from here. Only make the following changes. I will be very specific here, there is space for exactly 6 WAAS satellites, 2 characters are for the Hex PRN number i.e. 7Ahex=122decimal for satellite PRN122 which some know as NMEA ID 35 (but we Magellanites do not care about that). And preceding each satellite are 6 characters, the first 2 always seems to be 00, then the next 4 appear to be the satellites Longitude, in Hex, with special care if that is a West (negative) Longitude. Then open the Windows Calculator. Click <view> and then select <scientific> since you will need to use the Hexadecimal mode. So also click that button. Find out what WAAS satellites exist perhaps using celestrak.com/NORAD/elements/sbas.txt, and what ones should be visible from your location by using a satellite tracking program, or a satellite TV antenna positioning program, to process those NASA 2 line elements. Some WAAS resources online are years out of date. One site that is very current (for the USA) is the FAA but Lat & Long of satellites is only valid for the WAAS satellites, the others are moving really fast relatively to any point on the ground. Convert that PRN number from decimal to hex, I.E. In the calculator, when in decimal mode enter 122 for PRN122, press Hex mode and you will see 7A. That 7A is what you are going to change to or from in the firmware. Remove the 'dead' satellites, and replace them with the good 'new' live ones. I detail that in a later bullet. Make no change of the Longitude, perhaps you will need to do so but not yet. Oh, you might see the things like the 7A repeated all over, but that could be part of a Longitude or Address or Checksum so only modify the specific 2 characters that are the PRN number for the satellite. And they occur in pairs, so be sure to not try to modify the last character of one byte and the first character of the next byte, all you will do is make a mess of things. That all sounds familiar: that generation had a table of hard-coded satellite numbers of the WAAS birds and when the SV numbers were reassigned early in this century, the table had to be hand-changed. Map330 is pretty far in my past and there's a whole lot of (poorly organized) files in the archives that were mechanically grabbed. If you can send me a believable version number of what you're looking for (2.09? 4.0?) based on what's in your model now, I *might* be able to dig something up. But the above is the general recipe to "fix" WAAS in whatever version you have now.
  18. GPSBabel (one word) told you exactly what the problem is. Your GPX file is nonsensical, jumping the rails starting at line #25. There's a closing GPX tag at line 24 but there's gibberish following that. By the time it got to character #40 in the 25'th line, it abandoned hope and baked you an error message cake. <trkpt lon="-122.97039" lat="47.62169"><name>Finish : 28/07/2020 10:40:23</name><desc>38.5 Miles</desc><cmt>0 Mph</cmt><time>2020-07-28T17:40:23Z</time><speed>0.0</speed><ele>106.3</ele><sat>0</sat><course>0</course></trkpt> </trkseg> </trk> </gpx> <rtept lon="-122.97039" lat="47.62169"><name>Start : 28/07/2020 10:40:23</name><desc>38.5 Miles</desc><cmt>0 Mph</cmt><time>2020-07-28T17:40:23Z</time><speed>0.0</speed><ele>106.3</ele><sat>0</sat><course>0</course></rtept> <rtept lon="-123.34444" lat="47.02553"><name></name><desc>97 "Looking fine" isn't the same as being fine unless you're actually familiar with the GPX specification. (I am and the file does not "look fine".) You can't just signal the end of the gpx document and then have dangling rtepts that aren't part of an rte that aren't part of a gpx and such. Structure matters. Those tags actually have meaning and the order usually counts. See the specification at https://www.topografix.com/gpx.asp. GPSBabel will let you get away with an otherwise valid <rte></rte> block before the <wpt> block, but it's not actually valid GPX if you do. GPSBabel will (mostly) "fix" the order of the inner tags when it writes it, but the file has to be at least kind of valid to start with. There are trkpts that have escaped their trksegs with totally absent trk tags. This file kind of resembles GPX, but it needs reconstructive surgery to make it something valid and useful. This also doesn't appear to be actually geocaching related. GPSBabel is a conversion utility, not a file recovery program to unscramble things. A large part of GPSVisualizer is a front-end to GPSBabel. Whatever created this file did not create a valid GPX file.
  19. Rinex files are mostly the domain of professional GIS and GPS receiver that cost as much as a car. They're not much used in geocaching. You should probably be looking int he land of professional tools like ArcGIS, GDAL, or maybe GRASS.
  20. Moderator note: this thread has devolved into bickering and just short of name-calling. Garmin made the change you are stressing out about. Lobbying this site to change something that's useful to a small percentage of their users is unlikely to be productive. Actually, lobbing THIS group specifically is highly unlikely to be effective; nobody reading here can grant your wish so you should make your request to Groundspeak if you want the site changed. But I'd wager they're going to push this back onto Garmin because this site really doesn't need device-specific code in these paths. So. Please stop the bickering here. Redirect your feature request to Garmin to have them remove this feature.
  21. Cool. You're clearly not the mainstream buyer for even a $15 GPS. :-) Hack away. As for "a linux routine that's similar to EasyGPS", I may have some relevant credentials. I released it publicly 18 years ago this month, in fact.
  22. Garmin has sold a Vista (Silver/Serial )and a Vista HC(yellow/USB). They have very little in common operationally. Since he says it's black and white, it's the original from about twenty years ago. The downfall of the original serial Vista is that USB/Serial adapters that actually work with modern operating systems *correctly* are hard to find. The original comes out in an eTrex-proprietary "blade" connector which needs that proprietary cable (which it sounds like FuzzieBear is providing) and then has to to go USB/Serial adapter. The Yellow one comes out in a USB Mini-B and still requires Garmin-specific software to speak to the device for anything but track points. Waypoints (geocaches) won't just mass storage mount and copy. GSAK should work with either once you have the connection right, but it's not easy. A lot of the XP-era serial devices just won't work under 10. Maybe if you're buying new adapters it's better, but serial ports are approaching "collectibles". It's a fair price - near zero - but you should be braced for a challenge.
  23. If the unit is navigating and static navigation is important to you, you can pair it with a common $10 compass. Mentally spin the device so that "N" matches magnetic north on your compass, and the destination arrow will be "right".
  24. These mostly invisible failures are another reason why the non-Windows world just doesn't do UTF-16. Risking damaging your file on an edit is a most unfortunate side effect. "Breaking" the file on a benign change is just defective in design. Lots of UNIX-y tools flip out if you treat UTF-16 files as UTF-8 or ASCII because they often "look" mostly right. Also, TBC, I wasn't disagreeing with you. I was underscoring your assumption, offering up the comments of one of the original designers of that, and confirming your guess was right. For our readers: geocache_visits.txt files are encoded in UTF-16-LE (without BOM). Thanx for helping to clarify this messy topic.
  25. Mineral2 is mostly correct. GPX was designed and developed around the turn of the century by independent software creators to provide a common interchange format between applications (and was then hoped, GPS units). It was focused on waypoint, tracks, and routes - the interesting common denominator at the time. Extensions are available for fitness data, acceleration (racers), marine, and such. It's supported by many programs on many operating systems and probably even more web sites.. It's an open file specification and a mostly plain ole text file in the sense that a simple web page is; GPX is pretty simple. mps and later, gdb and gpi were developed internally by Garmin for Garmin's own apps. Specifications on it were never released and any interoperability via those formats is because souls have stared at piles of raw number and worked out what Garmin would do. These files changed over times in incomptibles, while GPX moves very slowly. (Critics may fairly say that it's too slow - and that's partially on me to fix.) If you're storing your data and it's valuable to be able to open it in other apps where you don't control the readers or in a future where Garmin fails and/or drops these apps, store it in GPX.
  • Create New...