_Art_

It’s locked to a field contained within the SD card’s CID register, and it won’t be displayed in a file on the card. The GPS device serial number is the equivalent of the SD card CID, but for the memory on the device, but expressed as decimal. Only options are probably best for different forums, but one of them voids your Garmin warranty, and the other violates the EULA for the map data. In Australia, we can bypass protection to back up purchased software, and data, but it’s not usually a friendly thing to discuss on the more official forums. There are specific GPS forums for it though.

There’s merit in tight, robust software running on cheap hardware (60csx). It’s maybe just an esoteric appreciation now, because I do want the fluff of imagery beneath vector mapping. Through back injury, the most serious stuff is in the past, but I’d have laughed at a phone. That would stay in a small Pelican case, and only come out if needed, and if it might connect. I’m still not put off by rain, so long as I’m already started, but even if a phone were suitable, It’s maybe still a conceptual appreciation for a better receiver and rugged hardware that I like. I must also enjoy being disappointed, and complaining their software isn’t as tight as it once was.

Hobby programmer and student Electronics Engineer. Commercial GPS product for me is all about Hiking/Mountaineering/Rock Climbing. I’ve tried to load a list of Geocaches on my 66, but that cocked up somehow. If it happened that I was out and a geocache was near, I’d probably try to find it, but that would be incidental, and you wouldn’t hear about it. For me the treasure is already out there occurring naturally, and waiting to be found. At the same time I have no problem with it at all. Whatever gets people outdoors and active is good.

Viajero, Did the 60CSx come good? That’s one I might have got again just for nostalgia because a lot of memories I have associated with it. I’d be almost happy with it being current if it weren’t for render speed, and no chance of imagery with 8 bit colour.

I’ve seen similar when I’ve deleted menu items so that the number of items is odd, and there’s supposed to be a blank space. Scrolling through the menu, the last blank space becomes populated with a duplicate of the last valid item. Rookie programming mistakes. Another is the sub menu for Birdseye running off the bottom of the display so you can only see the first two options for brightness.

It just got updated to 2.80. Spoke too soon!

I see, but that’s not right. It’s as it says here:https://support.garmin.com/en-AU/?faq=pxlzojy45AAkZMZtuQiSx7 It’s exactly the same as the 64. I’ve reached that 250 tile limit in two ways. Filled it with downloaded Birdseye imagery, and also I own HEMA raster map for Australia, which is IIRC 86 JNX files on a card in the Birdseye directory, but they are scans of paper maps, and are small in size for the area covered. Then I can fill the rest of the internal memory and the card with downloaded Birdseye imagery until the same limit is reached in total. After that you get a message at startup the same as the 64, the first 250 tiles work, and the rest don’t.

Garmin might say the largest card can be 32Gb, but that’s only because any larger card is SDXC, and is formatted exFAT off the shelf, bu there’s no difference between SDHC & SDXC cards other than that, and there are tools to format SDXC cards as FAT32. On a Mac it’s a breeze.

I didn’t say anything about a 32Gb limit, just that the tile limit for Birdseye (if it is all highest quality) is about 32Gb. You can use higher capacity cards if they are formatted as FAT32. You get unlimited Birdseye download, but the tile limit for the device is 250 tiles. After that you get an error at startup. The 250 tiles include Birdseye, Huntview, or any other Garmin raster map, since they all use the same JNX files.

The tile limit for Birdseye imagery of highest quality is about 32Gb in itself I need a 64Gb card before any vector maps are even loaded. Raster map products, including Huntview are essentially also Birdseye JNX files. They are taking their time with updates for it. I guess it’s not selling well.

Those setting probably still work if you have the serial interface adapter. All of the settings in that menu are for serial output format, and AFAIK always have been. https://buy.garmin.com/en-AU/AU/p/26668

Your computer or iPhone will display each pixel with 255 possible shades of red, 255 possible shades of blue, and 255 possible shades of green. Mixing those values is how every other colour is produced.

Birdseye is JPEG in Basecamp and the device, but the device displays RGB565. 32 shades for red & blue, 64 shades for green. All of those include black as a shade.

For Oregon, did this change with the last fw update? These strings are assembled with standard sprintf string formatters, and some of the simpler strings precision can easily be changed. Unlike stings that aren’t interesting .. speed, altitude etc. The coord pairs have nothing legible to search for.

If they are the same point, it just tells me the the device rounds for the precision being printed to display, so the extra digit you type should be zero. I use decimal degrees, and always have, so I’m not used to anything else in any case.

Have you had need to average 4-8 samples at least 90 minutes apart for a single point as Garmin suggest? I haven’t. Looking at a lot of people’s logs of the same track over a year or so, those track logs do converge (even though a track log doesn’t log the same points). I was able though, to move west to east, back and forth about 2-3 meters in my house, under my roof, and reliably move the last two decimal places. That means if I’d made a track log of just the two points, it would be a line rather than a point, and I’d know the bearing between the two points, and zoomed in on a map, I’d see a distinction between the two points, and that’s all indoors, and without any need for dead reckoning.

I just checked a GPSMAP 66 track log, and it’s actually 10 decimal places that are stored. Don’t know if anyone read that, but it isn’t true. They printed the next decimal place simply to reflect improved GPS accuracy. Firstly, the numeric difference between a pair of coordinates relates in no way at all to any distance unit measurement on the ground. You have to map those coordinates to a spheroid first, to calculate a distance between them. Secondly, I picked a random location in my country, in Queensland Australia: S27.6211453 E152.7525275 Keep the same latitude, and move east 3 meters, and you have: E152.7525587 The numeric difference between longitudes: 0.0000312. Had I chose a location further north, that difference for the same 3 meters would get smaller.

It was to better describe a reply to this: "It's not desirable because it doesn't make it any more ACCURATE." When it actually does: https://www8.garmin.com/manuals/webhelp/gpsmap66s_st/EN-US/GUID-DC65C2FC-0EA3-4182-9B6D-8DB8E4125B56.html Maybe for a Geocaching profile. and I guess for GC coord entry it shouldn’t be there, but for other uses, it’s desirable. If the 62 does waypoint averaging, it might not show the entire float, but it would still exist in memory. You could possibly see the entire precision value printed once the data is exported and viewed somewhere else.

Sampling the same position multiple instances over a duration, and calculating the mean of all samples does make the position more accurate. I haven’t used it, but that would be what the GPSMAP 66 Waypoint Averaging feature does. A UBlox timing GPS module can be prompted to enter a self survey mode that takes a day or two to find a very accurate position, which can then be entered into a field that gives it’s PPS output higher accuracy, to make a real time clock more accurate.

But they kinda have, because Waypoint Averaging is a thing, and it was a thing long before Garmin decided it was a thing. You could take samples from multiple devices at different times to create a better map or track.

I guess for geocache, the whole idea is not giving a precise location because you’re supposed to find it yourself. For any other purpose a GPS or mapping has, I don’t see why more precision would be undesirable.

Well still, Is there a difference if you just omit the last places by typing nothing? What they will have done is always used 32 bit floats which can have 7 decimal places precision, and just printed the rest of the value that always existed in memory anyway. 40.4819050°, -078.5484983° You could have a coordinate pair to enter (geocache or not) with 32 bit precision.

It’s the same format with an extra digit of precision. They probably did it as the receivers have become more accurate.

Every Garmin handheld doesn’t necessarily work fine when it was sent It would be a little more confusing for the seller of an older unit that was once a daily user. I do feel sorry for those who make a career out of becoming a licensed distributor for the stuff though.

It will be interesting that all over the world, some people are going to sell some GPS hardware on eBay that worked fine when it was sent, and has an issue straight away when it arrives at the buyer’s address.