Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by robertlipe

  1. Sounds like the magic words you need to utter to the developer are "Android Intents". This is the mechanism that Android uses to allow programs to request another program (Messages, Chat, Maps, Dialer) to do a thing (Send a message, draw a pin on a map, place a call) without knowing the mechanics of each other. The calling program (e.g. the geocaching app) doesn't have to maintain a list of apps that knows how to draw a map; it asks the system to draw a map and the OS looks through the array of apps that have registered their ability to service such requests. That app might be Google Maps, Waze, Google Earth, OpenStreetmap or whatever. (OK, three of those four apps are Google, but those are just the examples I know from memory...and because I implemented this stuff in the early days of one of those apps.) Basically, your request to Bosch should be to get them to register themselves correctly via the manifest and then handle the incoming intent, parsing the bundle as necessary for the payload ("navigate to Lat: X, Lon: Y"), and acting on it. If you've used Android for any length of time, you'll hopefully now recognize the basics of how such apps call each other and make it easy for your favorite Pizza app to do common tasks like draw a map of the pizza stores (like the list I just named) and call the store to place an order with each of these steps having multiple applications available that can handle either step. Honestly, if an end user has to describe such a fundamental Android concept to a software vendor, that says a LOT about the amount of institutional Android knowledge from the vendor. This is either a bug in a really basic part of their software in not registering these intents or displaying a sad knowledge of the surrounding Android ecosystem. Bosch is a huge company. They should know better. This sounds like it may be an outsourced project that wasn't run by "Android People". Sorry (not sorry) for the tough love.
  2. Imagine that playing out in a geocaching app. The logging module is an extra $8. Logging events costs an additional $1 each. Finding anything other than a film canister costs $.75 per stage. (Multis are, of course, additional.) Logs are limited to once per 30 minutes in the free version. GPS interface, optional so you can pay the GPSBabel guy, is $29.99. :-) It's no longer even a fine line between charging extra for extra features as much as it is the airline model of hobbling the basic service as much as you can to get the initial price as low as you possibly can, but make the system just horrible enough that people don't immediately leave, while adding back baggage fees, use of vowels in logs, water and restrooms during a 5 hour flight, etc. The article I cited takes a while to come to that topic, but covers that. Kidding aside, you're exactly right that ratings and pricing have basically made developers and users antagonistic with each other. Apps regularly get trashed for not having features they didn't promise. I worked on Google Earth for 13 years (and with them for a few years before that) and when I wanted my esteem crushed, I'd go read the reviews. (Yes, developers actually can read that feedback you type inside apps. It's even translated for them...) We'd get 10% of the users that would trash us for it not being real-time, even though it's forbidden by international law to be so. "I went in my yard and waved at the sky, but the picture didn't change." We'd then see an equal amount of users fussing about the privacy invasions. We'd get the flat-earthers tripping that we were part of the hoax. We'd get complaints that we didn't have street view imagery of their house in 1973. It was a really surreal part of the experience, but overall I was proud to be part of an app that everyone knew. The $2 flashlight app mentality really devalued software in the mind of the public. In this century, there are very few markets left where users can justify spending more for an app than for a coffee. That's not healthy for either the producers or the consumers of software.
  3. I purchased a number of such apps. Every one of them self-destructed. As a dev myself, though, I'm somewhat sympathetic to their problem. There are a few problems that inherently makes the geocaching app market work poorly. I think it's gotten better for low-volume apps, but the OS provider (Apple, Google) gets a third of that right off the top. Now that's a fixed COGS and was hopefully built into the price model, but the dev now gets $6.50. The twist is that geocaching apps are something a user may stare at intently two days a week instead of, say, a joke-telling app that's used a few times and discarded or even something as specialized as a map converter that you only need a few times a year. Geocaching apps are just not typical App store apps: Geocaching apps are a small market. A successful app may have hundreds of installs and a really successful one may break into the thousands. So maybe that app maker made $10K. Maybe. (Download count is not the same as purchased user account...) It's a demanding market. Look at the endless raging controversy over 3 vs. 4 digits after the decimal point on some Garmin firmware. If your app works differently than the user expects, you're going to get an earful. Maybe you built - and sold as such - a bare-bones "follow the arrow" navigation app. You're going to get one star reviews because the app doesn't have native puzzle-solving abilities, such as decoding caesar ciphers on the device. That actually has nothing to do with geocaching, but there's an expectation that it's there. Maybe your app doesn't think it should be involved in travel bugs (and you made no promises about travel bugs in the app listing) but someone will say their life is ruined if your app can't automatically dip travel bugs with a log that auto increments, includes the timestamp, and reports "3/14 for the day", for each log. Oh, and it needs to handle the day ending when they went to bed, not at midnight because they were caching after dark. It's a moving target. Groundspeak was disrespectful of developer investment in their API and at least twice has restructured the way applications had to communicate with the server in an incompatible way. Not a minor, annoying, "let's change the spelling" way, but a major "rewrite the bottom half of the app" way. Multiple times. Cache types and log types and maximum API calls per hour and other things change (or at least did - I've quit following it) regularly. It's a localized target. Geocachers are worldwide. You'll need SI and Imperial. You'll need to know that altitude may be in feet, but ground distance may be in meters. You'll need at least most of the Romance languages supported. Individually these are trivial, but it's a lot of _stuff_ to keep track of and to exercise all the combinations. It's a changing target. Even within a given API level, Cache and log types come and go. Security rules around logins change. OSes change version and deprecate some service that you were using. There are new event types to handle. You'll need to build and test on phone and tablet, probably on real hardware and not the emulator because geocaching is a physical thing and it's hard to simulate the experience in the field. You'll need to handle all the new devices coming on as well as all the old devices that ever worked because someone will have a phone identical to yours, but is on a carrier that's withholding the OS upgrade so your "identical" phones offer two different sets of features to develop, test, and support. It's a demanding target. You don't control the schedule when any of this happens. OS updates get pushed and you're either on the train or your app quits working. Groundspeak changes the login process - again - and all your users are locked out. The solution space is small. You're never going to get VC funding to get an iOS dev, an android dev, a support person, a testing person, some equipment, etc. This is always doomed to be a one person operation (Every open-source attempt into this space I've seen has usually been a single-person show, perhaps after a brief flurry of introductory activity) and it's not like it's even going to be big enough money to be a full time job with insurance, etc. It's big enough to be painful (to do it well) but not big enough to actually hang a business around. Even Garmin made a run into the "geocaching" app space and eventually quietly withdrew. Not unique to geocaching is the split of the market. While there are frameworks that help you move your app between iOS and Android, they don't really cover things like the compass and the GPS and battery issues that are all crucial in a geocaching app, but less so in others. If you're a serious dev out to capture serious market share, you can then count on basically building,, testing, and marketing your app twice: Once in Swift and once in Kotlin. (And ten years ago, neither of those languages existed, so you've probably replaced the original Java and Objective C++ versions....) So now you're fighting for relevance in two markets, on two different fronts. I just looked at the android app store at the top paid apps from indy devs: #1 $5 - Sync for Reddit actually shares some of these problems. However, there are 430 million monthly Reddit users. The market is actually large enough to bring non-trivial income. Yay for them. Only they also just added monthly subscription fees ON TOP OF the base app price. This didn't go over well. #2 $3 calendar app. 1M users. (Hint: you're never going to get 1M geocaching app users) The target market is people that need a calendar. Not sure it competes on ongoing maintenance, though. #3 $1.39 watch faces. A watch face app is probably a weekend project. Build it once and you're done. 10K users. #4 $4. An application to talk to ghosts. Seems unlikely to have much tech support demand or changes from ghosts going on strike. So all of these are apps with a WAY larger potential user base and either less ongoing required dev/maintenance/support costs, or an additional monthly subscription fee to cover that. Yet, if you build an app for $10 (the same app for $2 would drive you insane with looky-loos demanding support) users basically expect the app to keep working forever, but without an economy around it that supports this. Build a $2 fart app where the market is anyone that was ever eight years old and people will forget about the app in a week and you never hear from them again. A watch face app may get a cease and desist from Rolex about using their artwork (and that could be detrimental if executed, but you're out a weekend of development) but you'll notice that other app types in the industry don't have this whole large ecosystem that they have to live in, but can't control. Mobile apps blew out the pricing of software. People now associate app prices with that $2 fart app, a $4 flashlight app, or the $1.39 watch face (honestly, I think the market for that kind of junkware has kind of blown over, but it still cratered consumer expectation of paying for software) and if you ask them to pay $50 for a specialized mapping program or some other market-specific tool, it's like you're a baby-killer. Yes, I was there for the wailing every time Clyde rolled out a paid upgrade to GSAK...and watched him put up with users going to great lengths to avoid paying for those upgrades, but still taking up his time. This isn't the article I was looking for, but it cites a lot of related articles that touch on these topics. See https://www.sciencedirect.com/science/article/pii/S0167811619300473 So, yeah. A failed $10 geocaching app is just par for this course. Sorry. If I need credentials, I've been developing geocaching-related tools off and on since 2001. I've built at least two Android apps and one cross-platform GSAK-like app for cross-platform to prototype stage. I have geocaching-specific code in GSAK and in Google Earth (drag and drop a PQ into Google Earth Pro. Thats me.). I've studied this market and I've thought about it a LOT. Concluding advice: develop geocaching apps to scratch your own itch or do it for fun, but there's no money in it.
  4. > I find myself geocaching by phone these days I think you've hit the market summary spot on. They're in a tough spot. Look at their product line and you can see a hole and some rollup opportunities. Etrex: small and large. $100 and $200 are good price points. GPSMap: separate product entries at $300, $350, and $400 - each with submodels of different sensors, mapping options is too crowded. Clean house. A BME280 and a HMC5883L combined are under a buck in quantity. Does a camera make sense in these at all, especially at $100 when the sensors are < $3. Volumes for the multi-SV chipsets and antennas have driven the price to nearly the same as the GPS-only solutions. Printing and stocking different SKUs with training sales and support people (bwaaahahaha ) costs more than that. Fold all the 64, 65, and 66 devices together into one model. Remove Topo as a SKU and make it a download. Rhino and Montana are niche products at best. I just can't imagine that people are buying $800 Montana 750is. Make Spot a separate unit that connects to the phone for a keyboard and location. Just don't even put it in the GPS. Just like the camera, that's on a different upgrade cadence than the core GPS tech. New volume lineup: eTtex small $100 and large $200. GPSMap touch or dpad at $350. (Ask if we really need three different UX's with click-stick, dpad, and touch at all...) Hire a team to fix the problems that have been in these things for >10 years. The self-destructing buttons, switches, and rubber band problems are just not funny any more. Hire a usability engineer to count the number of button presses to street/foot navigate for a day of power geocaching, then go fix the UI. Read AC's list of long-standing bugs in the firmware and actually fix them. Crashing on certain PQs has been with us since Colorado. Make a legit sustaining engineering group to fix and support these things Last time I picked up a eTrex, the performance was just torture. When we had 8Mhz Dragonballs, I understood why keypresses lagged by a second. Modern multi-core RISC-V and ARM parts with a good peripheral set and good power management are, again, about a buck in quantity. Quit using parts that just make the hardware so laggy to save pennies. But you've exactly called out the elephant in the room. All, but particularly the entry level devices, have to be feeling the pressure from phones. As long as your touch screen device is $600, it's really hard to justify one instead of the touch screen you already own. That really leaves their island between those two points: hyper rugged (compared to a phone) hardware. They'll never be able to compete with the volume economies of Samsung or Apple - heck, probably not even Oppo or OnePlus. I think there's space for them to survive with geocaching-capable devices inside the larger "outdoor" class of devices, but I suspect the $500 touch screen Oregons are so indistinguishable in the minds of consumers from a phone (that the already have) in an otterbox that we just won't be seeing more of those. Instead of trying to shove everything into every device, consider your handheld "power geocacher" unit using BT to pair with your Drive so the cache you just marked found disappears from the map and your next (auto-routed) GOTO is the navigation target. Quit trying to solve driving directions on a 2.4" screen and an AA battery budget for some users. They used to have 20 Nuvis and then mobile phones happened. Now just have models at 5", 6", 7", and 8", I think it's time for some tough love in their outdoor line to clean the models up and lock them down into a sustainable maintenance mode product line. In that product line, like their fitness devices, external competition forced them to clean up. In handheld GPS, their hand isn't forced, but they can't coast with this product line forever. If I were King, things would be a lot different here... I'm just not sure we need an Oregon 800 at $500.
  5. Is it the same source file for 650 and 64 or are they merely similar? On the 64, are you dropping them into the Geocaches directory or the Waypoints (?) directory?
  6. https://www.gpsbabel.org/htmldoc-1.8.0/filter_transform.html
  7. The basic pattern should be: [pre] gpsbabel -i gpx -f yourpq.gpx -o garmin -F usb: [/pre] That is [i]nput type gpx [f]rom yourpq.gpx [o]utput of Garmin protocol [F]ile usb: If the garmin serial module thingy is installed (it used to not work very well....) you can replace "usb:" with /dev/ttyZZZ where ZZZ is what's reported by modprobe/dmesg when that module is initialized. As for being easy, it used to be easy to put that in your mimecap and trigger that command when you did a download of the GPX from the site. That was long ago and time/security may make that single click harder to set up now, but it was once possible for it to be easy. This is the approximate recipe https://www.gpsbabel.org/tips/browser.html but that recipe is surely on brown crackling paper with torn edges from age. The main content there probably predates Pocket Queries, but the inspiration should still be in there. Of course, if you and I have to go debug USB protocol stuff, it's no longer "easy". Later, you can do the kinky stuff like: https://www.gpsbabel.org/tips/geocaching.html If we need to get debugging out of the USB protocol stuff, add -Dn where n is a number from 0 to 9, with 0 being silent and 9 being an explanation for every byte moved. 1 or 2 are less chatty, like "This is a Foo packet and it says Bar, but I'm not going to show you alll 4,092 bytes of it." If you're getting an error about us being unable to claim the USB port, be aware that https://www.gpsbabel.org/os/Linux_Hotplug.html is a thing on Linux. If you have the round serial cable and a *working* USB/Serial port (or maybe even a antique motherboard "COM1" port) you can replace the "usb:" above with the serial port name. That should be a completely different set of problems, but it's probably more readily debuggable to the average Linux user that's comfortable debugging, say, a modem than the esoterica of stalled USB control and data pipes. So let's see the error messages, the details on what you tried and we'll chooe between USB and serial and try to conquer it.
  8. GPSBabel has been around for over 20 years. It's had geocaching-specific features all that time and it knows how to get things to your 60Cx. It's not a database like the appropriately named GSAK; it (among other things) picks up a GPX and puts it down inside your GPS. I found thousands of caches with that combo, but it's fair to say that it's not a 'cache manager' as much as it's a transfer/conversion tool. There's only so much data that GPS will hold, but GPSBabel knows, for example, to put letters in the description to indicate the cache type and embed the difficulty and terrain. Mass storage mode doesn't transfer waypoints in that era of devices. https://gpsfaqs.org/faqs/garmin/xseries/g60cx/waypoints.html#wptsonmem You can only transfer tracks via SD. These units are now 18 years old. We were always happiest using as little kernel support as we could, but they frequently broke the USB implementation. I haven't tested it personally in years, so it's possible you have some debugging to do. The pieces SHOULD all be there. https://www.gpsbabel.org/htmldoc-1.8.0/fmt_garmin.html This used to be a huge problem. I haven't heard it in a long time, so either nobody's using that combination, the distros finally fixed it, or that page is more easily found via search than our mailing list address. :-)
  9. Moderator note: please include particulars (Magellan made dozens of models) and information like your approximate location, willingness to ship, willingness to ship overseas, expected costs, etc. Oh, and please close the topic once it's claimed.
  10. Oh, yeah. This is Garmin that's still not USB-C, so yeah, you may need an USB-C->USB-MiniB or just move the card from the GPS to the phone if you're concerned phone cooties use a USB-C card reader and move the GPX file on the memory card. Or put the card in the phone on phones so equipped. And don't be a crank. OP amended the request in a later post to include wireless. The goal is to transfer caches. If it takes a wire, it takes a wire.
  11. I haven't tried this, but can't you just attach a USB cable between them, treat the GPS like an external disk, and copy the GPX to ...whatever/Garmin/GPX/Geocaches or whatever that directory name is. You'll probably need some kind of file management app (not geocaching specific) since Android likes to pretend there aren't files and disks, but these are common. You'd handle it just like copying a folder of photos. (Not via a "share" menu, but copying files.) We've come a long way since the days when mobile phones didn't have USB host mode and Garmins used dumb protocols instead of just acting like a disk drive.
  12. <rant> I swear if Garmin would finally fix the UX on this and the "I have waypoints, but I'm not going to show them if they're > N miles away" issue (neither of which are exactly defects; they just violate the principle of least surprise and they're not That Hard to improve) we'd have had 10% fewer tech support posts over the last 15 years. Maybe use better power switch sticks and rubber glue so we don't have to explain how to jam ink pens into their $500 hardware that's now "obsolete" and unable to replace that worn out $0.06 part. We free tech support types could reclaim a couple of vacation days per year. The first Garmin I know of with this overly-persistent memory issue was the 60CSX class of units in 2006, as they were the first that had waypoints read from files on boot, but the "too far" problem goes back to the serial models. </rant> I think the answers you got above, @JL_HSTRE, are all over your problem. You either have a copy of those files somewhere in some form (GPX, GGZ, POI, etc.) on the mass storage that you can't see (Finder on MacOS "deletes" files by moving them into a directory that's not shown by default....) or the device's flash memory is corrupt where it's seeing a different thing than what you see on your end of the USB cable. (Less likely, but this forum has seen it at least once.) A factory reset is an inexpensive prescription for that. ChuckEd's last sentence may not apply to this case as you don't have removable memory. We should confirm, too, what you mean by "still there". Garmin has a different hidey hole for the list of found caches than it does for live waypoints that are editable, show on the screen, etc. Also, hand-crafting a perfect GPX file isn't quite trivial. One blown angle bracket and the device may be throwing an error in the parser and not continuing on with the rest of housekeeping bootup duties.
  13. XXX delete above As an engineer, I know there are at least six different rounding conventions in common use in the real world. Since most of us aren't in Asia with convenient positive lats and longs, there's surely some required agreement here on the sign traits, right? You're not standing in the woods arguing about rounding toward zero vs rounding to even or whatever, are you? I wouldn't be surprised if there isn't an actual convention chosen here because this digit is fiction in our units anyway. Next we should all be fretting about marking up our fields with the number of significant figures, too. The "precision" of UTM is a bit of a fallacy. It has more digits, but they're imaginary also. Your GPS "thinks" in spherical data, a geographic coordinate system from WGS-84. UTM is a projection. The process of getting from a flat map to a spherical one introduces distortion at the edges. It takes some hairy code that looks about like https://gist.github.com/attilaolah/6cf22de8949d45a6cc06286536050e42 (GPSBabel's code does this using lots of smaller functions, so it's harder to point at a single block and express the horror.) The formulae to correct distortion near the page seams is reversible, but it's kind of synthetic to declare it "more precise" when it just plain takes more characters because it's encoding a region, a zone,, and a number of meters N and E within that page. See also: https://gis.stackexchange.com/a/1328 As for your later example, you can do this within GPSBabel, too. ➜ ~ echo "N60 16.0543, E24 51.6818" | gpsbabel -i csv -f - 60.267572N 24.861363E WPT001/WPT001 ➜ ~ echo "N60 16.0543, E24 51.6818" | gpsbabel -i csv -f - -o gpx -F - <?xml version="1.0" encoding="UTF-8"?> <gpx version="1.0" creator="GPSBabel - https://www.gpsbabel.org" xmlns="http://www.topografix.com/GPX/1/0"> <time>2022-06-14T09:35:23.652Z</time> <bounds minlat="60.267571667" minlon="24.861363333" maxlat="60.267571667" maxlon="24.861363333"/> <wpt lat="60.267571667" lon="24.861363333"> You can see our (my) GPX writer suffers from peer pressure on fantasy precision. That's a recent-ish change. It wasn't that long ago that the site had a rather more hostile input method. Jeff Boulter and I were fussing about that almost 20 years ago, back when bookmarklets roamed the earth. Geocachers Boulter and Parkerr helped add that 18 years ago and we were begging geocaching.com to implement it from our example parsing human-readable freetext coordinates.
  14. [b]Moderator Note:[/b] this basic discussion has been going on in this group for years. Garmin added it and nobody has produced a tangible reason [i]why[/i]. The precision/accuracy/digits of significance point are all facts and people that misuse them continue to misuse it. As THIS thread is getting tiresome/personally snippy, I'm going to make one request to keep discussion here factual and away from the rude, personal, sniping that this style of posts so often turns to. Play nice or post closed. At least do an experiment. Paint an X on your lawn/driveway. Take the coords, as you would with a cache. Now, daily for a few weeks, navigate to that point, as you would with a cache, and see if that last digit is immutable. My assumption is that it's noise, but it at least covers something beyond the same tired ground... But at the very least: play nice and let's not have the same eternal thread.
  15. For waypoint, track, and route transfer, GPSBabel should still work, though I won't die of shock if that combination has decayed of neglect. That's an 18 year old model and my days of plugging everything up on each release are long over. You can read a GPX or LOC from geocachign.com and write to "garmin" format on usb. https://www.gpsbabel.org/htmldoc-development/fmt_garmin.html It's free. Try it. Or not.
  16. > I think the problem is that the GPSr doesn't really handle the routes very well. We typed a variation of this at the same time, but now that I understand this better, I'm pretty sure you're destined for frustration. Building a route from a PQ is going to do things like lead you to the front door of the subdivision that happens to share a rear fence that borders the back edge of the park that houses the ammo box. It's going to navigate to the "wrong" place to park. You're going to be messing with it at the final minutes and if youre the driver, it's distracting that you have to outsmart all that tech. I think that taking the GPX generated by the first software listed would help you eliminate the basecamp issues. The GPX *should* just eat the GPX directly. Another "fresh perspective" in all this would just be to leave the unit on the dash running the map overview and pick your destination from the map . Mark them as found and they'll disppear from the map as you go and your bread crumbs make it clear where you've been. Much less software fiddling involved. This was what I did when I was traveling (most of the last of my final years) and didn't want to carry a bucket of hardware on the planes. It worked OK with a single GPS and the trick is to set the PQ paramaters for what you'll actually hunt (a process you must be doing if you've narrowed it down to an 87 point list) and use the diff/terr and ignore lists appropriately.
  17. Following up on that last point. I can't find the max number of routepoints, but at least one piece of Garmin software may have a limit of 29 points if te last post in https://www.expressmounts.com/questions?qid=37847 is to be believed. If it's about size and not ordering or a name conflict (three point named "tree" shouldn't be merged into a single one, but I'm sure that some software somewhere may do that) you might try breaking the route into 4 chunks of 20. Name them Morning, Afternoon, etc. or something where you can easily control the sequence from the unit while you're on the move. When I was finishing my 50 state challenge and covering hundreds of states, I went even lower tech: a note taped to my dashboard of states in the order I needed to hit them. From there, choosing one from the map is easy. I had access to over a hundred GPSes at my peak and I never found any of them that would really route that many in a day. Reality would always hit - a road closure, a town parade, etc. - that meant you had to hop from 57 to 59 and let 58 go and the GPS would go nuts trying to navigate you back there. It was usually just too finicky to mess with while driving. There was also a time I'd have two dash units - one doing the actual cache to cache routing and another that was zoomed out and kept more of a big-picture "you are here" that kept me heading the approximate direction I needed to move to keep on track during the run. Yes, it was absurd hardware overkill. So you have lots of things to investigate and alternatives on the table in case you do find what's dragging you down. Good luck.
  18. Your post mentioned "route point 1", so I latched onto the leading zero thing. That may be a distraction.| My point was that if you're starting with a GPX file that you know is right, dragging through GSAK and through a variety of their Macros, feeding that through Basecamp along the way, and pitstopping it in CacheRoute30SM (which is a new title to me), there are a lot of fingerprints on things that have a chance to "damage" the file in weird ways. If you start with a GPX file, mount the device in mass storage mode, copy the GPX file to it, carefully unmount/eject, and the GPS should read it on next boot.. Things like Basecamp (or whatever they're calling it now) and even some GPSes tend to snap route points to roads that can also result in routes looking different on the device than they do if you're just looking at it. My power geocaching days are over, but I also found a happy place using one dedicated unit in the car and another on my hip. I used a StreetPilot 2720 long long after they were trendy, but it's a nice combination. (I'm not at all recommending buying a 2720 in modern times.) Remember that GPX files are "just" a very carefully crafted text file. If you aren't intimidated by, say, reading a web page source code, pop one open in a text file and see if the order and details match your expectations. The GPX file format is described in great details on expertgps.com if you have to split hairs, but I think a pencil and paper, not a magnifying glass will help find where it's going off the rails. You can see a well-constructed GPX file at https://github.com/GPSBabel/gpsbabel/blob/master/reference/transform-rte.gpx Pardon the lack of vowels, but an <rte> is made of an ordered list of <rtept>s. Order matters. Almost everything insden rte or rtept is optional. Notably, the <name>, <cmt> and <desc> fields to not have anything to do with the order of the turnpoints. Even the names are optional. This one has <time> and <ele>, which is pretty rare for routes (but legal) because this file is part of GPSBabel's test suite and it was converted from a track into a route. They're optinoal and a distraction for you. So pop open your GPX files each step along the way and see where the order goes wonky. Also check that your GPS can even hold that many. Most consumer grade units won't let you put in infinite routepoints . Motorcyclists, in particular, run into this issue a lot. The GPS - especially ones that do routing - really want to be given a route that says "Mountain View, Palo Alto, San Mateo, SF" and not 150 turn points for every stop light between those points. (This is a terrible example because either 101 or El Camino would be basically a straight line; I just needed a few cities that are moderately well known and somewhat close.)
  19. My approach would be to try to use leading zeros. If it's doing an alphabetic sort instead of a numeric one (not unreasonable, though you'refree to ask which of these steps is sorting them at all) "02 ... 09 10 11 12 ... 19 20 " will do what I think you're asking for. An alphabetic sort of that same sequence without tthe leading zeros would put 10 11 12 before 2. You may have too much software involved. Can you just copy the GPX file straight to the device and land it in whatever device directory it expects to find such things? I can't recall if 2597 mounts like a disk drive and reads GPX or if it was of the generation that wanted to be a camera and only talk through a protocol that didn't respect folders/directories. Goopd luck.
  20. Play nice, guys. You two don't have to snip at each other every time. In this group, it's reasonable for "Garmin" to default to handheld/outdoors class hardware. We may have GPS experts, but this is still a geocaching forum and an encyclopedic recall of their backup cams or body scales isn't required.
  21. This seems dangerously close to advertising. Please be careful, Kunarion. Post a review, if you like, and walk away. Thanx.
  22. That would be very surprising. Garmin has historically had some Very Bad USB implementation quality, but USB3.1 has been around for a while and we've not seen a lot of crowing about this. USB2, USB3.0, and USB 3.1 are all compatible via fallback; if you don't *ask* for the new stuff, or you ask and are declined, you just don't get the new stuff and you get the old protocol levels instead. Did Garmin really tell you it doesn't work with any computer built in the last 8-9 years with no fix or workaround? Source: I'm the one that first added Garmin USB support on Mac and Linux , a task involving engineering at Garmin and Apple, and even now my software supports more Garmins on USB on Mac and Linux than even Garmin does...
  23. 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.
  24. 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!
  25. 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.
  • Create New...