position format changed.

[+RussLinda114]

Hello guys. I have a garmin oregon 700 that I use for geocaching and fishing. The other day I went to add coordinates in and I noticed that there was an extra number at the end  of the west portion of the coordinates .Here is an example. It use to read N 40°28.914'  W 078°32.909'  now it reads N 40°28.9143' W 078°32.9099'  I looked at all my saved waypoints and they all now have an extra number at the end of the west coordinates .How do i get it back to three. I went to the position format settings and nothing seemed to work. Can someone please help. Thanks.

[_Art_]

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

 

[+barefootjeff]

4 hours ago, _Art_ said:

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

 

 

But they haven't. Three decimal places gives a resolution on the ground of about 1.8 metres, compared with the 3 metres best accuracy you're likely to ever get under ideal conditions. Having a resolution of 18cm on a device with a best accuracy of 3 metres is just adding random noise and for geocaching the extra decimal place is useless anyway since the coordinates of the cache are only recorded on the website to three decimal places.

[_Art_]

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.

 

 

 

 

Edited March 9, 2019 by _Art_

[+Atlas Cached]

18 minutes ago, barefootjeff said:

 

But they haven't. Three decimal places gives a resolution on the ground of about 1.8 metres, compared with the 3 metres best accuracy you're likely to ever get under ideal conditions. Having a resolution of 18cm on a device with a best accuracy of 3 metres is just adding random noise and for geocaching the extra decimal place is useless anyway since the coordinates of the cache are only recorded on the website to three decimal places.

 

...which means, for both numbers, the fourth digit after the decimal could be any numeral between 0-9. Since Geocaching only publishes to the third digit, you have no way of knowing what the fourth digit is, which means you can simply substitute any number you like and still be more than close enough to find the geocache. I suggest splitting the difference and using a "5".

[+barefootjeff]

1 minute ago, _Art_ said:

Well still, Is there a difference if you just omit the last places by typing nothing?

 

 

 

Try entering Next Stage waypoints in the field on a seven or eight stage multi, particularly when the conditions aren't very favourable (wind, rain, glare, unstable footing, etc.), making sure to tap the extra right-arrow button to step over that useless digit and not make a mistake in the process. Yes, that's what I was doing straight after I installed the update and it was a tad annoying.

 

Or how about going the other way, when transcribing a waypoint you've marked onto a new cache page and having to take extra care when converting those four decimal places down to three without accidentally picking the wrong three or forgetting to round up when the fourth digit is greater than five. Keep it simple - the cache page has THREE decimal places in the minutes and the chances of error are minimised when the device matches that. The eye is very good at matching up multi-digit numbers that have the same format, but is less good when they don't match.

[_Art_]

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.

 

[_Art_]

27 minutes ago, barefootjeff said:

 

But they haven't.

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.

 

[+barefootjeff]

2 minutes ago, _Art_ said:

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.

 

 

It's not desirable because it doesn't make it any more ACCURATE. You could quote the minutes to 100 decimal places if you wanted to but it wouldn't nail down your position on the ground any closer.

 

Quick as a flash, without thinking about it, look at these two screen shots and decide whether or not they're the same coordinate:

 

 

 

When I glance at the second image, the first thing I see on the right is the 276 and the 144, and if I was in a hurry or tired I could easily read those as the three decimal minute digits.

[_Art_]

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.

 

 

[+on4bam]

The only way this extra digit may have any effect is with the European Galileo GPS system.

[+barefootjeff]

2 minutes ago, _Art_ said:

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.

 

If I recall correctly, my 62S would also do waypoint averaging, so it's nothing new. Why the sudden change now, and still I ask, for geocaching, which is the "Activity" the Oregon 700 is set for, what is the point of the extra digit when it can't be used anywhere?

 

4 minutes ago, _Art_ said:

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.

 

I'm sure a UBox timing GPS module is a wonderful thing, but what does that have to do with someone out in the field trying to find a geocache with an Oregon 700?

 

[_Art_]

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.

 

Edited March 9, 2019 by _Art_

[+kunarion]

2 hours ago, barefootjeff said:

 

Try entering Next Stage waypoints in the field on a seven or eight stage multi, particularly when the conditions aren't very favourable (wind, rain, glare, unstable footing, etc.), making sure to tap the extra right-arrow button to step over that useless digit and not make a mistake in the process. Yes, that's what I was doing straight after I installed the update and it was a tad annoying.

 

Or how about going the other way, when transcribing a waypoint you've marked onto a new cache page and having to take extra care when converting those four decimal places down to three without accidentally picking the wrong three or forgetting to round up when the fourth digit is greater than five. Keep it simple - the cache page has THREE decimal places in the minutes and the chances of error are minimised when the device matches that. The eye is very good at matching up multi-digit numbers that have the same format, but is less good when they don't match.

 

When was the extra decimal place added?  I tried it just now on my Oregon 650t, and with the latest version 5.50, it's still three decimal places for DDM.  That's the ideal number format for Geocaching, and would be suitable as a setting option on the device.  "Three decimal places" or whatever.

 

On the 700 and any others that develop it, the extra digit will create confusion for Geocachers.  Brace for new Forum threads about this.

[_Art_]

I just checked a GPSMAP 66 track log, and it’s actually 10 decimal places that are stored.

 

4 hours ago, barefootjeff said:

 

But they haven't. Three decimal places gives a resolution on the ground of about 1.8 metres, compared with the 3 metres best accuracy you're likely to ever get under ideal conditions. Having a resolution of 18cm on a device with a best accuracy of 3 metres is just adding random noise and for geocaching the extra decimal place is useless anyway since the coordinates of the cache are only recorded on the website to three decimal places.

 

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.

 

 

 

 

Edited March 9, 2019 by _Art_

[+ecanderson]

At our latitude, every 0.001 minute represents about 6' N/S and about 4' E/W.  I don't care if you're averaging a waypoint or not, you're not going to resolve your location any finer than that with a consumer device and no ground reference.  A fourth digit is beyond useful.  It's hard enough to get an average to settle within 0.001 repeatably.

 

Edited March 9, 2019 by ecanderson

[_Art_]

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.

 

 

Edited March 9, 2019 by _Art_

[+arisoft]

5 hours ago, _Art_ said:

I guess for geocache, the whole idea is not giving a precise location because you’re supposed to find it yourself.

 

In geocaching the whole idea is to use accurate coordinates. It means precise location - not the opposite. Finding caches without precise location is called letterboxing. It is another hobby.

[+ecanderson]

I've done some research on tracks and 'drift in clear, open skies', and found the results fascinating. 

 

Have also used extended periods of averaging for placing of my own caches over the course of a couple of different days to get different HDOP included in the results, though a spacing of some hours would be enough with any typical constellation configuration.  In the averaging case, with patience, you can narrow it down to +/- 0.001 repeatably.  Beyond that, no.  +/- 0.001 is the best I am able to achieve with any of my various devices. 

 

The reason that Garmin recommends (correctly) averages to be taken across a period of time is because HDOP can be (but is not always) quite variable.  In fact, for any specific lat/long and point in time, there are calculators that predict HDOP, and once in a while, you see some really bad configurations appearing in the constellation that are assured to cause some degradation of the results.  I'm sure most people who keep the current "EPE" visible on the screen have noticed times where in even the most advantageous circumstances (no obstructions, nothing around to cause multipath errors, etc.) there are times where HDOP issues are more pronounced than at other times.  "EPE" is a mathematical construct based upon the subjective coding of the algorithm used by a given GPSr device, but in relative terms, it does have meaning.

 

 

[+RussLinda114]

When did the fourth digit get added and can i go back to three. I often copy cordinates from my navionics app on my phone to my Oregon 700 and the saved cords on the navionics only have three so what do i enter for the forth digit?

[+Atlas Cached]

11 minutes ago, RussLinda114 said:

When did the fourth digit get added and can i go back to three. I often copy cordinates from my navionics app on my phone to my Oregon 700 and the saved cords on the navionics only have three so what do i enter for the forth digit?

 

Are you reading the replies above?

 

If you never needed the fourth digit before, and don't need it now, just leave it a zero, or a 5, or whatever - It's not going to make any difference to someone who wasn't using it in the first place!

[+on4bam]

2 minutes ago, Atlas Cached said:

If you never needed the fourth digit before, and don't need it now, just leave it a zero, or a 5, or whatever - It's not going to make any difference to someone who wasn't using it in the first place!

 

In fact, I can't count the times I missed the last digit of a coordinate and just used a 5. Doesn't make a difference for finding caches/tags ... Besides, there's always some inaccuracy when the CO measures up the coordinates and again at the seeker's side.

Galileo is said to be accurate up to 1 meter and for that the 4th digit might be useful, until then... nope. But hey, it's great marketing

 

 

[+Atlas Cached]

1 minute ago, on4bam said:

 

In fact, I can't count the times I missed the last digit of a coordinate and just used a 5. Doesn't make a difference for finding caches/tags ... Besides, there's always some inaccuracy when the CO measures up the coordinates and again at the seeker's side.

Galileo is said to be accurate up to 1 meter and for that the 4th digit might be useful, until then... nope. But hey, it's great marketing

 

 

 

That starts to make more sense now...

 

The GPSMAP 66 is Garmins first GALILEO capable device, and it uses the same core software as the Oregon 7x0. So, I imagine when they added the extra digit into the code, both units benefited.

[+Henne1312]

Is the O7x0-chipset Galileo capable as well and this feature is not yet „unlocked“ by the firmware? 

[+barefootjeff]

4 hours ago, _Art_ said:

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.

 

 

 

 

 

Internally, it uses decimal degrees (well it'd be binary degrees at the machine level) and doing its averaging functions internally in higher resolution is likely helpful, but that's a totally different thing to what it displays to the end user. Displaying 4 decimal places in DD mm.mmm format, particularly when the device is configured for geocaching, isn't helpful, it just adds the potential for errors in either entering or reading off coordinates. Did you look at the screenshots I included earlier? Did you see the potential for errors?

[_Art_]

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.

 

 

[+arisoft]

2 hours ago, barefootjeff said:

Did you look at the screenshots I included earlier? Did you see the potential for errors?

 

I may see the potential for errors more clearly if you explain how this error is going to happen. What steps you need to do?

I have made practically all coordinate calculations by using four minute desimals for years. I do not recall any incident caused by the extra digit.

[+barefootjeff]

40 minutes ago, arisoft said:

 

I may see the potential for errors more clearly if you explain how this error is going to happen. What steps you need to do?

I have made practically all coordinate calculations by using four minute desimals for years. I do not recall any incident caused by the extra digit.

 

These are the coordinates I captured in the field for a recent cache I placed (GC831AR). Fortunately I created the cache page before the update so it still displayed three decimal places at the time. If I was doing it now, perhaps thinking about what I was going to write in the description while copying the coordinates from the Oregon screen onto the cache page, I'd say there's a fair chance I could have put the decimal minutes as 276 and 144, with nothing to indicate my error until the DNFs started rolling in. After all, I'm used to seeing the decimal minutes as the last three digits, not the next-to-last three digits. In this case in particular, with the coincidence of the first decimal digit being 0 in both latitude and longitude, the eye easily skips over that and just sees those last three digits.

 

I'm an engineer by profession and used to working with multiple precisions in decimal numbers yet I still wouldn't trust myself not to make a mistake with those numbers. Show that screen shot to a lay person off the street and ask them what the decimal part of the minutes are, and I'd wager they'd say 276 and 144.

 

There are enough caches out there with erroneous coordinates without adding another mechanism for mistakes. And for what? That extra digit contributes NOTHING to finding or hiding a geocache, nothing at all, because everything on the website is based on DDD mm.mmm with three decimal places.

 

Edited March 9, 2019 by barefootjeff

[+arisoft]

36 minutes ago, barefootjeff said:

After all, I'm used to seeing the decimal minutes as the last three digits, not the next-to-last three digits. In this case in particular, with the coincidence of the first decimal digit being 0 in both latitude and longitude, the eye easily skips over that and just sees those last three digits.

 

I understand this. My way to record coordinates is based on multiple measurements which I average off-site. I think that I would be glad to have 4 digits instead of 3. My GPS has theoretically 0,5 meter accuracy when using real time differential correction data from ground stations.

 

I know that you can enter all 4 desimals for you cache editing form. Your potential problem is that you are unnecessarily skipping some digits from the coordinates when copying them from the GPS screen to the cache editor. You need only to forget this habit.

Edited March 9, 2019 by arisoft

[+31BMSG]

1 hour ago, arisoft said:

 

I may see the potential for errors more clearly if you explain how this error is going to happen. What steps you need to do?

I have made practically all coordinate calculations by using four minute desimals for years. I do not recall any incident caused by the extra digit.

Since the compass doesn't work when stopped I don't use it to search for a cache, only my current coordinates and the coordinates for the cache. If I'm within a minute of the cache I'll occasionally glance at the last three digits to make sure I'm still heading in the right direction, it's an old habit I apparently need to break. When I noticed the four decimal feature I was balancing on the side of a rock and mesquite covered hill trying to find a good route for my next move. I didn't understand why I was now 1500 feet away from the cache before I realized what I was looking at. 

 

It's great that accuracy has improved to the point that four decimals can be displayed and I also understand how calculations are more accurate, but I can also understand how someone searching for a cache while trying to keep from rolling downhill could make the same mistake I did. An option to display three or four decimals would be nice.

[+Atlas Cached]

22 minutes ago, 31BMSG said:

It's great that accuracy has improved to the point that four decimals can be displayed and I also understand how calculations are more accurate, but I can also understand how someone searching for a cache while trying to keep from rolling downhill could make the same mistake I did. An option to display three or four decimals would be nice.

 

This request has already been made to Garmin, more of you should do the same to show them it is important to some of their customers. 

[+ecanderson]

29 minutes ago, 31BMSG said:

Since the compass doesn't work when stopped I don't use it to search for a cache ... I was balancing on the side of a rock and mesquite covered hill trying to find a good route for my next move.

Now THAT'S my kind of caching, and is why I've preferred a unit with a magnetic compass option for quite a number of years now.  It's too often necessary to stop and sort out the next move, during which it's often nice to get a quick new bearing on the target.

 

Quote

It's great that accuracy has improved to the point that four decimals can be displayed

Technically, they could always display four after the decimal.  Whether the last digit would have been (or currently is) of any real significance is another story.

 

Let's review what 0.0001 actually means, even in the best case at the equator where it matters most for E/W measurements:  We're talking about 0.0001 minutes = about 0.6 feet.  It's always that for N/S measurements.  Yes, find me a consumer unit where that level of granularity in linear measure could possibly matter.

 

Edited March 10, 2019 by ecanderson
Had to get rid of weird formatting of prior quote.

[+ecanderson]

1 hour ago, arisoft said:

My GPS has theoretically 0,5 meter accuracy when using real time differential correction data from ground stations.

"ground stations" ... do you mean EGNOS (SBAS) correction, or local fixed ground based (GBAS) references?  If the former, any 0.5m spec is just that -- theoretical.  If the latter, who caches with THOSE???  What kind of GPSr are you telling us about? 

 

[+31BMSG]

17 minutes ago, Atlas Cached said:

 

This request has already been made to Garmin, more of you should do the same to show them it is important to some of their customers. 

Well I can't convince the web page I'm not a robot so that will have to wait.

[+Atlas Cached]

Just now, 31BMSG said:

Well I can't convince the web page I'm not a robot so that will have to wait.

 

Which webpage?

[+31BMSG]

Just now, Atlas Cached said:

 

Which webpage?

The support email page.

[_Art_]

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.

 

 

 

 

Edited March 10, 2019 by _Art_

[+barefootjeff]

21 minutes ago, _Art_ said:

For Oregon, did this change with the last fw update?

 

Yes, it changed with firmware version 4.40.

[+arisoft]

5 hours ago, ecanderson said:

"ground stations" ... do you mean EGNOS (SBAS) correction, or local fixed ground based (GBAS) references?  If the former, any 0.5m spec is just that -- theoretical.  If the latter, who caches with THOSE???  What kind of GPSr are you telling us about? 

 

 

I am telling about DGPS.

[+ecanderson]

7 hours ago, arisoft said:

 

I am telling about DGPS.

Well then that's the GBAS type system (Ground Based) that  I was talking about, and isn't very relevant here.  Sure, a professional unit like that with convenient ground based reference points installed can get benefit from a 4th digit.  But not a consumer unit that would be carried around for geocaching. As I asked earlier, "If the latter, who caches with THOSE???"

 

[+kunarion]

2 hours ago, ecanderson said:

Well then that's the GBAS type system (Ground Based) that  I was talking about, and isn't very relevant here.  Sure, a professional unit like that with convenient ground based reference points installed can get benefit from a 4th digit.  But not a consumer unit that would be carried around for geocaching. As I asked earlier, "If the latter, who caches with THOSE???"

 

 

Maybe Garmin added the digit to allow entry of found coordinates, especially coordinates from fancier systems, or to make room for whatever new invention comes along.  Or maybe it's to give the impression of super accuracy.

 

I've dealt with Digital Degrees since I started Geocaching.  The GPS shows, for example "33.741575, -84.392213", but in practice, I can ignore the last three decimal places or so.  It is a genuine calculated number (or I'd suppose it is), but it's merely a snapshot of one calculation, the practical reading swings several feet in any direction, so the cache is not in fact within the pencil point of that exact figure.  If I used a ground based system, a suitable GPS could accept the number anyway, and then I could have the numbers handy for use with a ground based system (or a map or whatever you use beyond a commercial handheld GPS).  But, yeah, I don't know if I'd call it "Geocaching Coordinates".  The web site coords are Decimal Degrees Decimal minutes, to three decimal places.

 

Edited March 10, 2019 by kunarion

[+arisoft]

2 hours ago, kunarion said:

But, yeah, I don't know if I'd call it "Geocaching Coordinates".  The web site coords are Decimal Degrees Decimal minutes, to three decimal places.

 

When you download a GPX file the coordinates are on decimal degrees format. It is also the internal format for waypoints in the website. Only human readable coordinates are displayed in degrees and minutes for convenience.

 

[+kunarion]

2 hours ago, arisoft said:

 

When you download a GPX file the coordinates are on decimal degrees format. It is also the internal format for waypoints in the website. Only human readable coordinates are displayed in degrees and minutes for convenience.

 

 

Cool.  It would be best for the GPS to continue to have a setting for "Geocaching Coordinates" showing three decimal places, not four.

 

 

Edited March 10, 2019 by kunarion

[+Atlas Cached]

23 hours ago, kunarion said:

 

Cool.  It would be best for the GPS to continue to have a setting for "Geocaching Coordinates" showing three decimal places, not four.

 

 

That may actually happen!

[+31BMSG]

Garmin support replied to my email today and it was pretty clear I didn't explain it well. After calling, the support rep said this is the first he has heard of it and the call ended with basically "we're sorry it no longer does what you purchased it for but it is what it is". Looks like it's time to find a way to roll back this update.

[+Red90]

On 3/9/2019 at 8:28 AM, _Art_ said:

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.

 

 

You are using the wrong format.  They are talking about DD MM.MMMM

[+31BMSG]

Before you roll back the version on an Oregon 750 and lose your user settings like I did go to system settings/interface/Garmin spanner/minute precision and you have your choice of 2, 3, or 4 digit precision. The owner's manual doesn't mention this and apparently Garmin is not aware of this setting.

[+31BMSG]

1 hour ago, 31BMSG said:

Before you roll back the version on an Oregon 750 and lose your user settings like I did go to system settings/interface/Garmin spanner/minute precision and you have your choice of 2, 3, or 4 digit precision. The owner's manual doesn't mention this and apparently Garmin is not aware of this setting.

After switching between firmware versions 4.2 and 4.4 it's apparent this setting does nothing. In version 4.2 no matter what this setting is three decimals are displayed, in the latest four decimals are displayed regardless of what is chosen. After I called Garmin a second time about this setting the representative agreed it was not documented but now that makes sense, why document a setting that doesn't work. I'll be sticking with the previous version until things are sorted out.

[_Art_]

On 3/13/2019 at 7:24 AM, 31BMSG said:

Before you roll back the version on an Oregon 750 and lose your user settings like I did go to system settings/interface/Garmin spanner/minute precision and you have your choice of 2, 3, or 4 digit precision. The owner's manual doesn't mention this and apparently Garmin is not aware of this setting.

 

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

 

 

 

Edited March 23, 2019 by _Art_

[+31BMSG]

9 hours ago, _Art_ said:

 

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

 

 

 

This is what the Garmin representative said until he walked through the settings and was surprised. All my receivers are set to spanner mode, when they are plugged into my laptop"s USB port they prompt to go to USB mode. Choosing YES allows me to go into USB mode and communicate with Basecamp while choosing NO allows the receiver to remain in spanner (serial) and provide live tracking through USB to the laptop software, no additional cables or hacks required. When the same receivers are set to serial they go straight to USB with no live tracking available.

 

Back to the original subject, no matter if the interface is set to serial or spanner these settings have no effect that I can see. Since it's been a couple of weeks and to make sure I wasn't seeing things I fired up my receivers and laptop this morning to test again. In both spanner and serial I switched minute precision between 2, 3, and 4 digits with no effect, the GPSr stays at 4 digits and my laptop stays at 5. My question to Garmin was since these options are already in the software why not let the user choose what they want to see?