Jump to content

robertlipe

Moderators
  • Posts

    5300
  • Joined

  • Last visited

Everything posted by robertlipe

  1. Good reference. (And this is perhaps worthy of punting to another thread...) There's a site I use when explaining more about that class of battery, their re-badges, and their counterfeits than most people ever want to know: https://eneloop101.com/ It uses Amazon referral links extensively, but the info seems solid. Their page on fakes is lengthy. If you want to see a real race to the bottom for fakes, look at the cheap battery packs which invariably use 18650's, the cells used in everything from Nuvi to laptops to Teslas. I've seen too many reviews of "bargain" products that do a teardown and then find that only half the cells are even real with the rest actually filled with sand so they feel about the right weight if you're picking them up. Be careful out there!
  2. Bumping this thread with a little more information because it was referenced elsewhere. Since this thread was started, we now know that the 30x does indeed not support ggz. Mineral2's final sentence is a little harsh - let's call the "budget" or "entry" models instead of toys, but I think the distinction is fair. With more than a casual understanding of how geo formats work and being able to probably draw a coarse block diagram of them from, I think that Mineral2 hit the root cause on the head. It's probably not an absolute limit but a practical one of how slow the product can be and still be considered usable. The recipes for making computers fast are well understood. Line one starts with "cost" ? If your $150 unit took 2 minutes to draw a map refresh when you moved the cursor or 20 minutes to do a search, is it actually reasonable to say it "supports" something when your $600 units can do each of those 60x faster? So there's probably a practical (and artificially enforced) limit on the cheaper models. From our experience building Google Earth, we know that drawing 5,000 icons, with labels, and trying to enforce what gets drawn on top of each other while keeping 60fps is hard. To Mineral2's specific musings, RAM is different than internal flash and even internal flash is segmented into the parts you can see (the stuff that shows up when you mount the volume over USB) and the parts you can't that stores the code, settings, fonts, sounds, a version of the user data that's fast to display and search, and such. Memory is a hierarchy of speeds and size, with each run of the ladder representing at couple dozen orders of magnitude. Variations of https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html might help people understand why having enough RAM to hold a table in memory instead of fetching from even parallel flash can easily be 1500x as fast. (A battery operated computer in your pocket is closer to the turn of the century than the data centers used as the inspiration for that chart, but the few people that read my longer writings may still find it helpful to visualize why their phone has 2GB of RAM and 128GB of flash any why programs will work so hard to read one scarcely.) For a fun way to reason how GPSes *probably* store things internally, https://jimkang.com/quadtreevis/ does a very accessible demonstration of an important data structure called the quadtree. (This IS how Garmin's POI format works...) Tinker with it and you can see why it works well with large spatial data sets and why it's super fast to read or display on a map at varying zoom levels and a real pain to change. That's almost certainly the reason there is no "edit/add geocache" page on your Garmin.
  3. Bumping a thread for a peripherally related model does indeed make it really hard for the volunteers here to help. Garmin really hasn't helped by calling three dozen different receivers "etrex", either. I think everyone above has you on the right track. Garmin's doc for that model should have taken you to https://support.garmin.com/en-US/?faq=Sf7jHKwP2V53j6MoP8AeH8 Garmin's confusing naming scheme also makes it really easy for resellers - that are generally just copy/pasting words without ever actually touching the devices - to copy and paste a pile of words and forget to tweak a detail that's actually important to someone. Take a look at https://www.gpscentral.ca/products/garmin/etrexseriescomparison.htm for an example of someone that actually knows GPSes and has amassed some of the eTrexen and even it doesn't track .ggz support. Amazon sellers and makers tend to be pretty annoying about this; they'll get one product page that's well linked and has good reviews and keep using it for products that have very little to do with each other and then the reviews and comments all devolve into a shouting mess where people argue about features missing from the device that they were _sure_ was listed. (The SURFboard and Nighthawk pages are examples where people can think they're choosing color of the product and end up ordering a completely different product.) Be careful out there! Welcome to the hobby, but please help others help you and remember to include full model information when asking for help. I think that earlyer today I pointed someone to this forum from one of the other 643 places I am somewhat online just knowing that this group had the concentration of expertise and experience to work through this.
  4. Thanx for the contribution but since we have so many active topics on this, I'm going to close this one.
  5. The bump of a 16 y/o message with a kind of generic post and an old 'last login' date is suspicious on its own, but I should probably do some moderator stuff and remind posters to stay on tech topics. So, more GPS and less movie trivia, please.
  6. I can't quite spot it, but this bug is/was present in the 600 as well. I've admittedly not been power-caching in a long time, and I don't recall the firmware versions involved (making this "me, too" not very helpful) but this used to bring down my 600 several times a day. You couldn't read the description unless you were navigating to it, so you decide that one isn't for you, press stop navigation and BOOM the unit would go down 100% of the time. I reported it since it was so trivially reproducible. Once I had a test case in hand, I verified that the 450 acted the same way, so that explained one of the crashes that nailed me several times a day when hunting. In short, if it hasn't been fixed by now this bug has spread across many their models and as discussed elsewhere, it may not ever get traction to be fixed. Good luck!
  7. GPSBabel 1.4.3 was 2012. I'm admittedly overdue in getting out a successor to 1.5.3. The changes are so pervasive that we've changed the language it's written in, so anything in 1.4.3 is long forgotten. https://www.gpsbabel.org/changes.html shows proximity in garmin_gpi getting some improvements in 2015 for "large numbers" of proximity alarms and in 2014 we started parsing speed units. You can tease a fuller history out of https://github.com/gpsbabel/gpsbabel/commits/master/garmin_gpi.cc but that's only the writing side; gpx and csv reader are in different files that you can get to in ways that are somewhat self-evident. We can read tons of csv and gpx variations and understand we're at or beyond feature parity with POI loader, but I'll admit to having never used it. The prox alarms are a relatively obscure feature and have been reverse engineered out of the file formats. Buzz me if there is something we're getting wrong. (In current code, not a 2012 version...)
  8. There are several VP's on eBay. There were several different strains of it with different maps for different PND, Outdoor, and Map combinations. Multiply in "freshness" and it's entirely possible there are four. There's a Triton 400 right now with some of the software included on CD for $22 + 9 and it'd be pretty hard to resist splitting the cost of the hardware in a way that workd fairly. I probably have ohter devices to be added to GPSBabel, though. There are a few Tritons in that general space. But I'm pretty sure the API that VP used to use for Waypoint download from GC have gone away or are about to go away so you may just be changing sinking ships. There's also the issue of license serving. If it's like the later Mapsource, you can't (easily) do a fresh install that workd because it tries to call a Garmin server for an actiation key and the conmputer gives them one. Once that licensing computer got lost in the third move or something, they allowed a license generated by hand but they were really grumpy about it and then chanced the policy to "no further activations". So youre going to have to find out that if it's in "no activations" if that means there's a path that actually makes the software useful without the license server. Sorry that what seemed like an easy question became a complicated answer with lots of dead ends and buzzkill answers instead of jackpots and old. I've been recently told that's apparently my contributing gift to this forum. :-(
  9. When you say "and final", you commit, man! It is refreshing to see different approaches from hardware people doing software and software people doing hardware. A whole lot of us would have started with a Pi-like substance with integrated SPI to free of you of the stacked decade counters to look for a clock in those packet/frame edges and the need for the max232 to bring it out to the Psion and all the fussy bit-banging there, too. The only thing worse than one serial port is two serial ports. It's a bit funny to look through your YouTube history and find a gem from my own past: in two different projects in different jobs I've needed to create that same phone circuit emulator where I didn't really needed telephony stack, I just needed a hint of dialtone voltage and not the full thing. Thanx for sharing your project. I admire curious people that'll dig into something that's just an unexplored area. Carry on!
  10. The freeze of Basecamp will be a downer for MacOS users. Current Basecamp is a 32-bit app. The final versions of High Sierra complained a bit about 32-bit apps, but Mojave (the current version) will be the final version of MacOS to support 32-bit apps. Mac users relying on Basecamp (and any other 32-bit apps remaining) will be in a bind starting this fall, or whenever Mojave's successor ships. MapInstall, MapManager will share this trait. Garmin WebUpdater supports two architectures: i386 and Power PC - and Power apps haven't been emulated since 10.6 or so and it's tough to imagine anyone running a G3 or G4 these days.
  11. @Mineral2 your intuition of how this model of Magellan works, based on your experience with devices like Colorado and Oregon would serve you very well. The way you just copy files to the device and it reads them on next boot is the same. There wasn't really any OS-specific custom geocaching component for these devices that was _required_. There may have been a Windows thingy that fetched the GPX file from the server (it probably predated even the Groundspeak API) and unzipped it and put it in the right directory/directories, but it wasn't like the x00 models where you needed something like GPSBabel to smoosh the GPX into something for the GPS. If you ever had to use those in Linux or UnixWare or whatever else, the steps would be pretty much the same. I'm about certain that the device doesn't "consume" the GPX files when it boots. It seems far more likely that the files just weren't completely written or were written to an improper place and they were lost when force ejected. @WillowCreekers (and others) be sure to safely eject the volume(s) with Finder and not just rip the cable out or hit the power button while it's connected. Mineral, on MacOS, the natural way you interact with files and most devices is through Finder, which is about the Windows Files Explorer. Use the eject button that is next to that volume. That's how you disconnect from a thing, whether it's a network drive or an SD card or whatever. You'll have one entry for the GPS itself and another for any SD card that's installed in the device. (That's a generic tip; Explorist GC may not have such a socket or the card might not be installed...) After copying the file (use two Finder windows: one with the source, another navigated to the "MAGELLAN/Geocaches" directory on the target, then just drag and drop) wait a few seconds, and then eject the drive. You should immediately see the target Finder window close. [/me looks for better explanation] This site looks kind of spammy, but https://www.techwalla.com/articles/how-to-transfer-files-from-a-mac-to-an-external-hard-drive describes it pretty well. The script I have for copying geocaches says that MAGELLAN/Geocaches (and MAGELLAN/Waypoints for parking coordinates) is about what Garmin/Garmin/GPX is on the devices you guys know intimately. If you're feeling brave, you can save this copying step by downloading straight from the site into the device volume, but it's probably a good idea to keep a copy on your machine anyway. I've used this combination, though it was long ago. There wasn't anything magic to it. I even exercised this on prototype/pre-release device and bugreported a problem on MacOS that they fixed before release...We have a few members of our local geocaching group that use Macs and Explorist GC and 710s that have been successful using them as described above. It's the same way you'd copy files to a thumb drive. If you don't put the GPX in the /Geocaches directory, I'd expect it to not "stick" on the write. IIRC these units expose the entire WinMo filesystem to the host and it write-protects some (but not all) directories that are bad to clobber. I remember it being a fun discovery that the device uses sqlite3 internally and you could see the tables, views, triggers, and such and explore those with common tools. I think that between the bunch of us plus the cited doc, we've explained it in many different angles to get you to the destination.
  12. I'll eat crow on that one easily enough, GeoTrekker26. I was thinking of devices that come from companies traditionally associated with GPS so I should have couched that more carefully. Sorry about that. While there are Fitbits that have GPS, for example, I don't think I've ever had a single person ask about them in GPSBabel-land, while Garmins that make up new fields in the .FIT come around regularly. Maybe that location data stays totally in their apps or Strava or whatever. Magellan has just had a rough life. While they were a leader at the very beginning of GPS, they went through a series of corporate sales with each generation seemingly replacing everyone in the company that knew anything about the products currently being sold and replacing them. Some generations (Map330/Meri{Gold,Plat,Green}, x10) were good. Some (Explorist x00, Triton) were not well received or were too late. GPSBlake's point about outsourcing the development would explain a lot about how they wound up with ARM-based products that shared bugs with Dragonball code, for example. The usage of the three Magellan formats in GPSBabel is so low that I've considered dropping them. It's been years since we've seen any evidence they're being used and we keep doing mechanical maintenance work to keep them alive for no clear reason... So if you're a geocacher using Mapsend, the Explorist x00, or the Meridian of the serial + SD card age, please pipe up. Honestly, watching the struggles in one of the Yahoo groups for that era of products, it was such a stretch to get those Windows 95-era products to work on Windows 7 that there just can't be many of them that aren't basically a sealed system at this point. I _do_ wish that someone would build a unit that'd give Garmin some competition. Given what we've seen in cell phones in the last ten years, and I do understand economies of scale in electronics, I still think of the TI-84 every time I pick up a new Garmin...that'll take 4 minutes to boot if you touched the GPX files since it last booted.
  13. Lowrance is still active in marine use. Magellan still has some market share in PNDs (dash top units for auto nav) and in some niches like golfing. They seem more popular in Europe than the U.S. Both have pretty much given up on the outdoor and geocaching market, and others entering the market never got traction, leaving one manufacturer. Fitness devices and loggers seem to have more competitors standing. Even in fitness lines, Garmin is leading the market share. The market has changed a lot for both outdoor and auto nav. The pervasiveness of phones really shook up the market.
  14. Mineral2s inference is correct. Explorist GC is a mass storage device that shows up as an external drive and works fine on a Mac...once you have a pocket query with the caches you want in a GPX. The details of getting a premium membership and ordering up pocket queries have been well covered and are exactly the same on any OS.
  15. If you have access to an inline USB ammeter, you should be able to see the current drop to zero or extremely close to zero when it's done charging. See if any of your local friends have a "usb ammeter" - there is a ridiculous variety of choices from places like Amazon or from Asian companies like Banggood or Alibaba. You'll probably find it easier to put on the charging side than the Garmin side because these tend to be "big" and some Garmins make it hard to use cables with a slug on the end. (My Oregon 600 works badly with my miniB + Micro B retractable cables for this reason.) When it really is done charging, you should see 5V still delivered over the wire, but nearly no current(A). These testers are gold when trying to diagnose USB charging issues or see the actual remaining battery capacity of your aging phone, etc. It seems possible that the internal voltage sense across the battery (to know when it's full/empty) or the switching transistor (to disable the current to the batteries once full) is bad, but this is probably a level down from the core unit's software - the electronics are dead-easy and you want it to work when the unit is off - or the representation of that process as something readable to the CPU was buggered but it seems unlikely given the chorus of "me, too!" answers that they're actually defective and continuing to charge. Honestly, if it continued to dump voltage into the batteries and the internal resistance resulted in enough current flow to be non-trivial, there would be more reports of batteries overheating, leaking, and causing physical damage to the device. If this shows a low current (below, say, .1A) and your screen says "charging", you can be sure your screen is fibbing. To Cheminer Will's observation, support techs are often measured by the number of problems they can solve per hour. After two or more techs have verified everything they can, replacement is kind of the "we've done everything we did for this customer" option. Strangely, in many companies, the number of units replaced for any given problem is usually how they measure when a problem is severe enough to escalate to engineering/manufacturing instead of the departments actually talking to each other. That really is the knowing-Hands issue that Atlas Cached described Placebos are also very expensive to the maker. I used to work for a hardware manufacturer and we once calculated that once we RMA'ed a product, the profit on that device was some number that rounded to zero. The more surprising of that report was that once you RMA'ed *one* device for someone, the odds of being asked to do it again went WAY up - far disproportionate to the additional number of devices.
  16. I intended to, but there's only so much I could do on a phone from bed. :-) <- Emoticon. [:-)] <- bbcode ?<- Emoji This is already a tangible problem with existing devices. Each group has teams of artists that decide an overall look to the set (and to handle the approximate 60 added each year). As one example that I know pretty well, my employer tried to abstract that whole human face thing away and use "gumdrops" that kept the spirit of "face, smiling". Some people loved them, some didn't. https://emojipedia.org/google/android-7.0/ vs https://www.wired.com/story/google-emoji-redesign/ You can see samples of representative artwork many places, but just sampling: https://www.unicode.org/emoji/charts/emoji-released.html Now if you're looking at Expedia inside Facebook on a Samsung device with a Google OS or browser, which one do you get? Darned if I know. It may even be different on the same device if you're using Samsung's browser instead of Google's own and even though the Samsung OS is derived from Google's. If you typed a note on your Samsung that relied on one that they removed or changed in a recent OTA update, what happens to your document? Hint, "There's just no guarantee it will display as intended on a recipient phone." Firefox's handling of dumping hex or leaving blanks or "funny characters" are all just as valid, though questionably usable. (In the developer's console where you can zoom on them, those numbers actually are readable...) Unicode is just now working with diversity (2.6) and how to handle groups of differing ethnics and races in groups. I don't envy ther work very much these days. One point of Emoji over just shipping pixel-precise data objects with a picture is exactly to allow such artistic creativity and visual diversity. If your cache page relies on the presence of dimples in your winking face, something has gone very, very wrong. GPS icon sets have always been messy to convert. GPSBabel tries to get Magellan's "Home" to Garmin's "House" and "cross, red" to "emergency services" (I'm pulling loose examples from memory...) but even within Garmin's own product lines this has historically been messy. Garmin devices don't tell the computer what they do support and Garmin has at least two numbering systems they use for each Garmin icon as you can see in our code. (The Quest and Rhino, of all forgotten devices, went totally nuts with emoji-like icons, none of which are related to Unicode names, of course.) GPSBabel even crawls through glass to try to get Delorme AN1 icons and a bunch of others and I've not seen any portable device try to tackle emoji - they're only now really starting to get Unicode right and still tripping over UTF-8 vs. UCS-2 with a few vendors still throwing DOS code pages into the mix. (Loggers tend to really like UCS-2 for ASCII for some weird reason. Most odd numbered bytes are totally wasted...) If if becomes a problem to geocaching.com, it's easy to imagine them simply filtering out the Unicode blocks for ED-20 -- ED-26 from cache pages, user names, and such. That's arguably the "no fun" approach, but it would allow them to focus on the real problems surrounding l10n and i18n issues. I'd certainly do the same for GPSBabel. Unless a customer came to me very badly (with an open checkbook) to address problems in this space, it's just not at the top of my list. Hopefully, by this point in the conversation, we're approaching an end as we we've educated at least a few people that arbitrary emoji are a crazy hard - and still growing - problem for devices and environments with constrained resources. Anything that *has* to be interpreted (or even presented!) unambiguously by a reader should not rely on emoji. We've explained while there is some industry uplift that trying to support emoji generally also improves internationalization, you're simply not going to see a lot of manufacturers getting excited about letting anyone name a waypoint an emoji and deal with the issues of screen resolution to support "six mixed gender people holding hands" and dealing with issues like how to present that in the sort order of the screen, how you enter such a character with a click stick, and so on. GPX (via XML) allows you to represent such things, but my forecast is that you won't see it in outdoor-grade (or even PND) GPSes like we tend to deal with in this forum. The more traditional operating systems dealing with mass market and that can rely on higher res screens and a more diverse user base are more likely to track developments here just from market pressure and because those devices are much more capable. The GPX group is a much smaller group that considers it largely a Unicode issue but we'll need to know what kind of devices woud be ready. I can't imagine that Garmin II is going to be bitten by a radioactive spider and get Unicode supwerpower support. OP, Do you consider this question sufficiently answered now?
  17. Hi, and welcome. You didn't include the GPS Model or what you were doing to confirm they aren't present and those are all important parts of getting you help. If tIf's a Garmin and he points are visible on a map if you zoom far enough out to see the and you 'just' don't see them on the list, that's because Garmin shows the closestN (I think it's 100 or 120 mles) waypoints and all your point are there so they don't get shown.Alternately, search near the destination town (Yeah, that's bad UX and we've told them that... How are you determining they aren't there? Do you see them on the map or in the list or in the searc or as available routepoint list or something else. Are they in the device but at a wrong place? Particularly if you live or are traveling to a new hemisphere mismatch, your points may "merely" be in the wrong place. Some programs get hemispheres right accidentally and if you're traveling to a combination of different sign errors your points may be in a clump at a tifferent spot. Rather than us guessing: What GPS and software was involved? How did you do the transfer? Anything unusual (error, different behaviour?) during or after the copy? How are you confirming that they didn't make it to the device? What else can you tell someone with the same hardware as you sitting on the other side of the table to get the same, presumably wrong, results. Thanx
  18. There are a lot of related terms being used interchangeably in this thread that are different at an engineering level. Emoticons are different than Emoji. They both display (typ. human) expression ina way that allows expression of the art ("house" or "smiling girl"). BBCODE is the thing that leaks from the forums into some cache page descriptions that transforms square brace stuff into icons or text markup. A BBCODE symbol or an Emoji may result in single character or glyph resulting not typically easy to create from a key on a keyboard. GPX (any version) allows encoding any Unicode character, which may or may not be Emoji. It can also signal things like for bolding text until which, if missing, may cancel at the end of thie next work ,paragraph, sentence, block, or the end of the world. BBCode is very poorly specified and remains largely the bulletin boards of the 90s. It's very rare that any handheld GPS (indeed, much of anything) will render everything that may be represented in Unicode. Another bazinga! is unicode (buried in UTF-8 thta's like " RLO (U+202E RIGHT TO LEFT OVERRIDE" which changes layout from right to left, which is a buzzkill for our languages but needed for others. Any creator of GPX can create something that can cause indigestion for some reader. For example, you could have a single field in GPX that's a terabyte long (assuming it's properly encoded) and that's going to trigger bad behaviour in _something_. Coming down from the silly cases, Garmin's GPX reader is pretty well known to crash on invalid GPX and some valid GPX. It gets better on some devices in some versions, but it seems like there's always *something* that'll crash them. It could ignore bad things or issue an error or do lots of other things, but crashes are just how they do it. If you pound them with a specific GPX file, long enough, they may fix it. Validating GPX is easy, and is encouraged by the GPX Developers. It's an easy way to draw a line in the sand on whether a GPX file is correct. Now "correct" and "works like you want" may be fine lines - for example, the GPX spec doesn''t stop you from putting <html><script>alert();</script><html> inside a name and that may render OK in some places with enough resources to embed an HTML/CSS renderer and a Javascript engine (cache pages rendered to a web browser allow a very tiny subset of HTML. Earth allows it in certain contexts like inside a balloon, but not inside a name) but they're just not going to display well on a device with constrained resources. Certain Garmins, for example, crash if they see lower case letters or spaces (honest!) so readers of GPX that have to send to such stupid devices have to try to do something to make it more palatable to the device. This is why GPSBabel (and thus both GSAK and Google Earth) crawls through broken glass to ensure that the amazing, rich GPX makes it to the Garmins (and hundreds of other GPS receivers) by trying to keep the character of the name, but it's admittedly very American English oriented. If you have caches named "P and Grab 2" and "P and Grab 21" and it's going to a yellow etrex (Upper case, no spaces, asdii, no conflicting names" we'll compress frirst "PANDGRAB2" and "PANDGRAB21" but the numbers are outside the length. We'll then start shoving the number back and the end, treating the number as more unique than the prose. P&GRAB2 and P&GRA21". Then another pass is made to dee if ampersand is actually allowed. That mapping of knowing the limits of the devices and trying to take the thorns off the data as it goes through the device is difficult. Figuring out what is actually allowed where and when can be a crazy project of its own. (I'm about 19 years into that. ) " When chasing this class of bugs, context matters a lot, so be careful to not oversimplify your test case. It's also why arguing about a single line of XML in a forum is a trap. Those "is_xhtml" fields in Groundspeask;s XSD, for example, change a lot of the rules. Editorial: The useful set of Unicode for cache pages is much more stable than the set of Emoji. The latin-based languages other than English, for example, are quite fond of diacriticals. There are humans (that are geocachers) that cannot represent their own given names with strict ASCII so Unicode is the standard way to represent the o with aorn umlaut as number X and we (the computer industry) all pretty much agreed in the early 90's that Unicode would be the way we encoded such things. Accent graves, even country flags all seemed pretty reasonable. A smiling face? OK, we don't know what it'll look like but that seemed reasonable. A brown smiling face? OK. A Brown smiling female face? OK. Keep on this path until you have about a dozen modifiers for faces and you end up with an explosion in this space. The 2,789 emojii in Unicode v11 (many new, and there were many more not accepted) are simply not going to make it to your 13 year old Nuvi 350. It would be entirely possible (easy, and responsible) to read them and toss them or replace them with the next level down if in face code block or something. As an engineer, "ignore the problem and let it crash? violates my interpretation of Postel's Law and as a former OS guy, "crashing the entire device" should be best reserved for cases like the device being physically ablaze...and have a rollover process to a machine in the other building to handle that...But recognizing that P&G should be represented and read as P&and;G grab in most context and to come out of the SAX/DOM parser in three tokens, "P", either :"and" or "and;" depending on wheither the lexer or the scanner is first, followed by a token of "g" - and it all depends on the surrounding context - a <blockquote" or an embedded <html>can all change how those three characters actually get stored and sent and everyone involved declaring the right things are done at the right time because if you do it but thosee notifications don't stay in sync, hilarity ensues. Not everyone decided to have the artwork for "dark female zombie running" included into the standard. At some point, the creator is asking an artist to create a representation of their creation for each of the devices that cares, all so they can be rendered interchangeably iwth a few (fiv5 or six) bytes. At some point,a lot of this should get compressed down to a JPG or GIF or whatever and served by the network for somebody to the world, like a real picture. I helped create several of the things being discussed in this thread. It's late as I write this, but if anyone really wants to argue specifics about angle brackets, I'm probably as qualified as it gets. I think the overall TL;DR of "if you put real unicode into a cache page description, such as the language used in the country in or near wher the cache is located, with proper handling in the apps and the hardwarre, you'll probably be fine. If last week's Emoticon (they tend to move fast) it may work on some devices and not on otherrs. If you need to see if a GPX file is valid, the process is at https://www.topografix.com/gpx_validation.asp it needs minor mechanical tweets for geocacching's extensions) but you can then at least put "blame" on reader vs. writer. It is my religion, for example, that any GPX that validates shall never crash code of mine (That's not a dare to find such a case; it's a sign that if you find one, I'll probably fix it, even if "fix" it means "don't crash".) The GPS Schema is fine. I've not analyzed the Groundspaek one. Based on what your'e describing as your motivation, I'd reduce that to the simplest possible case to on the SD card and then send Garmin that SD card and a GXP and ask them weekly what the status of the fix that makes that unit CRASH when reading the file. Convinced them that this same gps is being used for navigation and crashes are bad for navigating and maybe you can get it escalated from "game play disrupted" to "potential vehicle crash from distracted driver" It's complicated.
  19. You got lots of good answers below (thanx, gang!) but I'll come back to this. The track simplifier can sort of be used with the GUI. There are a bunch of options about exactly how you can choose to simplify (by count, by keeping the maximum overall fidelity of the original, by removing points that change the traveled distance the least, etc. These are covered in the doc. As is often the case with GUIs, in order to keep complexity manageable, the GUI makes some of these choices and forces you to just use the 'count' option. It's about as easy as this sort of thing gets. (The screenshot is an older version that's known to be ugly in my configuration - the current version has the layouts fixed...) If you want to pick out individual trackpoints one by one, we're the wrong tool and plucking them in Basecamp or such will be more to your liking.
  20. We talked about this a little at https://forums.geocaching.com/GC/index.php?/topic/349353-april-6-2019-week-rollover-issue Guessing how software will break can be a fool's game. Maybe some code wasn't prepared for time to go backwards. code like start_time = get_time(); do_something_slowly; time_taken = get_time() - start_time; is extremely common and if time happens to go "backward" while you're doing something in that "slowly" chunk, time_taken will be wrong if you're lucky and potentially negative which is almost certainly unexpected. So if something bad happens and it's "just" in the user interface code, that would be merely unfortunate. (It would also be ironic. Every one of those satellites is one of the more precise time pieces ever built and in the navigation message packet that they transmit, it's the very time of week field that's rolling over. Where it would really suck, potentially bricking the unit if they really screwed it up, is that if the time used to index into the almanac is so wacked that it can't resynchronized the coarse acquisitions (C/A) for enough of the satellites to correlate to the precise times (P-codes) to figure out location. More modern units with lots of receiver channels and lots of correlators have a better chance of recovering from even a moderate programmer face-plant than the older ones do. There WERE units that turned to bricks the last time this happened. Remember that not all GPSes are sitting on your car or even have a screen; it's the ones sitting on a tower in a field controlling some process-control device that were more in danger as they're less likely to be attached to something to get updates. There's some nerdy math on this page, but even if you skip the math, this page does a good job explaining what the chips are working with https://en.wikipedia.org/wiki/GPS_signals
  21. There may have bee some rational thinking on keeping the Mini-B on these longer than most of the industry. It was easier to find ruggedized versions of that connector as it was just plain physically larger and had more metal to work with. Waterproof Micro-B's were never really common. That said, Mini-B was still a terrible connector for reliability, Micro-B is rated for more connection/removal cycles but tends to move the shear point to destroying the cable ($) instead of the connector in the device ($$$$). Fortunately for *MOST* users, phones tend to be used like toothbrushes, charged or connected a few times a day, so they benefitted from the Micro-B while the lower volume and less common repair facilities and the ability to hose out dirt kept Mini B common in GPSes. https://electronics.stackexchange.com/questions/18552/why-was-mini-usb-deprecated-in-favor-of-micro-usb For most devices (I'm looking at you, Bluetooth speakers, and of course, Apple devices) USB-C can't take over the world soon enough, but I know it's just plain more expensive to do USB-C right. I'm more forgiving of that on a $.99 book light than I am in a $700 GPS receiver - those SHOULD have been moved to USB-C years ago.
  22. The newer units, built in a time when flash memory is cheap, don't destroy your tracks as readily. Space on SD card is plentiful. The 'auto' setting does a good job of recording switchbacks when needed and not dropping excess points when not. Barring that, Mineral2's advice of dropping by distance seems right to me. If you need to reduce the number of points later, you can use GPSBabel's track simplifier. It can also "deblob" any tracks you have that recorded by time and have a clump of dropped points where you stopped for a water break, stop light, or whatever.
  23. This thread is a train collision of unrelated questions on unrelated hardware and some about website features. The OP isn't even responding any longer. I'm closing this. Please keep one subject per post.
  24. GPSBabel supports Garmin USB protocol on all OSes. It did so before even Garmin's own software. As a moderator note, please pick good subject lines. Try to be specific to capture the attention of the people most likely to help you. You got lots of good answers above, but that subject line is your best shot at getting attention. I've tried to help this one.
  25. Yes. See e.g. https://www.spirent.com/Blogs/Positioning/2018/January/GPS-Rollover-Week for an accessible discussion. It's quite possible that you won't notice a difference looking at your receivers. It's more likely that the NMEA data or the track times during and after that time will act funny, so unless your event is prepared to gather tracks during a walk at that tie and capture and analyzer captured traces, you may never notice.
×
×
  • Create New...