GPSrChive Discussion Forum

GPSrChive wrote: Fri Mar 21, 2025 9:51 pm

gpsjorgen wrote: Fri Mar 21, 2025 7:28 pm
As far as I understand the feature you can only log 3 waypoints to be averaged. I did not test this.

What makes you think this?

I tried the feature. After logging the waypoint you are offered to make a next sample with the advise to have 90 minutes between subsequent samples. You are only allowed to take 3 samples.

Nail wrote: Tue Mar 25, 2025 7:22 am It took some time for 67 to correct its position and travel with 66sr.

Yeah, that's quite a large error.

Nail wrote: Tue Mar 25, 2025 7:22 am One day this problem disappeared and 67 stopped drifting, but now I see it is back again.

Well, it's not always. It occurs when satellite reception is not ideal, e.g. in the forrest or when the device is in home.

Nail wrote: Tue Mar 25, 2025 7:22 am And did you try to start the route when your unit drifted into the next street before you pressed OFF/ON?

Basically what I did was start recording (enter -> start).
Off/On and than resume.
What I did not do is let it drift and then start recording.

I did extensive research on this issue and reported it back to Garmin Support in Netherlands and US. They don't (want to) understand the problem.

Spoiler

Blog

I have both the eTrex SE (AG3335MN) and Solar (AG3335M) at the moment, which has the same chipset AG3335M used in the GPSMap 67. SE is not multi-band but the Solar is.

I ran a drifting test last night with the GPS indoor, but with reception.

Setup
- eTrex SE: multi-GNSS mode
- eTrex Solar: multi-GNSS and multi-band.

Results
- eTrex SE: HAS drift issue, was 238 meters away after 8 hours over night.
- eTrex SE: does NOT appear to have drift issue. Track points formed a nice circle around where it should be.

eTrex SE screenshot after test:

Spoiler

F3UF0146.png

F3UF0325.png

F3UF0909.png

eTrex Solar screenshots:

Spoiler

F3UF0458_1.png

Workaround
- As noted, the workaround is to simply turn off GPS reception, and back on again.

Don't need to turn off the GPS. This can be done super fast on some devices. Unfortunately on the eTrex SE and Solar, this involved too many key press, which I think is a design flaw. (On other GPSMap it's a toggle on the satellite page, where it should be).

I verified the position on the SE snapped back to the correct position as soon as I switched from Demo mode back to Multi-GSSN.

There was another instance where the drifting problem showed up. When I had the SE a week or two ago, I left it running overnight inside the house to get an idea of battery usage, without starting any activity. The next day I took it out on a car ride to a location 20 minutes away, saved to an Activity. When I looked at the activity later on the computer (since the SE has no map and no reference of any kind), I was shocked to find the starting point being completely wrong, few streets away! It converged to the correct road after about few minutes on the highway.

I didn't know what to make of it initially, as the issue never came back in my testing. But after seeing your post, I realized it may have been the drift issue you mentioned.

@gpsjorgen, your theory is that the GPS maybe using accelerameter for dead-reckoning. Does the the SE even have this accelerameter? I feel like it's simply the GPS applying some delta on top of an existing position when satellite reception is poor. Somehow this formed a out of bound random walk that slowly drifted the position out of true location by a huge margin.

For the Solar, it's not clear if the reception is simply that good with multi-band, or if there are some algorithm or guardrails to prevent this type of random walk from getting out of hand. But seeing that it is fine on the Solar gives hopes that it is probably fixable on the 67.

For kicks, I ran the experiment on a 66s, which has the "Type M5 (3313)" chipset, with 2.90 GPS firmware (and 10.7 software).

GPSMap 66s:

Spoiler

32692_1.png

While there were moments of gross error, and trip odometer said 12.9 miles, overall the random walk is much better centered around the correct position, and most importantly, it remained at the correct position after the 8+ hours.

I think someone at Garmin knows about this issue and understands what can be done. It's just that you and I have no practical way to actually reach the right people to discuss this with. There are just too many layers and layers of people in the middle that have no idea what we are talking about.

wildgoose wrote: Sun Mar 30, 2025 7:24 pm @gpsjorgen, your theory is that the GPS maybe using accelerameter for dead-reckoning. Does the the SE even have this accelerameter? I feel like it's simply the GPS applying some delta on top of an existing position when satellite reception is poor. Somehow this formed a out of bound random walk that slowly drifted the position out of true location by a huge margin.

Original quation is not directed to me, but I will share my experience with eTrex SE.

eTrex SE internally has GPS receiver, magnetometer and accelerometer (for digital compass both are needed, it has calibration routine). Based on Garmin info, it uses GPS direction when moving with digital compass when standing still. I haven't seen any info about merging GPS data with accelerometer data, but that is very likely if not implied between the lines.

When eTrex SE is standing still, consecutive coordinates in eTrex SE track log are exactly the same (from 5-10s to minutes). That is not possible with raw GPS receiver data in principle. Repeating coordinates also appear during long stationary logs, thus random walk is not exactly random in traditional sense. I would speculate that there are some threshold values for GPS and/or accelerometer/magnetometer movement before getting new GPS receiver coordinates.

IMO, GPS and accelerometer/magnetometer raw data is being merged by data processing algorithms in eTrex SE (or in GPS receiver) to give better discrimination between "standing still" and "moving" states among other things. Data merging may introduce some strange effects, that's for sure. However, Garmin doesn't disclose any details of benefits/drawbacks of this data merging approach. Maybe others can contribute more on this.

The accelerometer in the Garmin device is used for precise magnetometer readings regardless of the deviation of the device from the horizontal, which is why calibration in three planes is required.

It is also used to position (rotate) the screen depending on whether the device is in a vertical or horizontal position.

It is not connected to the GPS signal - this is an advantage.

Forget about the GPS!?

gps_techie wrote: Mon Apr 14, 2025 5:46 pm eTrex SE internally has GPS receiver, magnetometer and accelerometer (for digital compass both are needed, it has calibration routine). Based on Garmin info, it uses GPS direction when moving with digital compass when standing still. I haven't seen any info about merging GPS data with accelerometer data, but that is very likely if not implied between the lines.

Where did you find this Garmin info?

gps_techie wrote: Mon Apr 14, 2025 5:46 pm IMO, GPS and accelerometer/magnetometer raw data is being merged by data processing algorithms in eTrex SE (or in GPS receiver) to give better discrimination between "standing still" and "moving" states among other things. Data merging may introduce some strange effects, that's for sure. However, Garmin doesn't disclose any details of benefits/drawbacks of this data merging approach. Maybe others can contribute more on this.

Basically, using accelerometer/magnetometer data as well, next to GPS info, is a good idea. What GPS devices typically do is to predict (by calculation) the most likely position based on current position and all sensory inputs. The Kalman filter is a typical filter that does the job, even taking into account the error in each of the inputs.

Spoiler

Kalman filter

However, to entirely forget the GPS when standing still seems a bad idea to me.

Final measurements on Madeira
I took the GPSMAP67 on a hiking holiday on Madeira and compared it to the Fenix 7. For GPSses Madeira is a tough environment, since you mainly walk along levadas along steep mountain slopes. You often walk the route and have to take the same route back. This gives us an opportunity to get a measure for precision: both routes, to and fro, should coincide, right? Next image gives a typical example. Fenix 7 blue, GPSMAP67 green.

Spoiler

For four hikes I counted the deviations larger than 10 m (educated guess for a limit beyond which you might mark the deviation as an error).

Fenix 7: 7
GPSMAP67: 24

Fenix significantly performes better.

Spoiler

See blogpost, bottom of page

This concludes my overall finding: when the going gets tough, the tough leaves you in the dark
I sold my GPSMAP67 on the second hand market.

gpsjorgen wrote: Mon Jul 14, 2025 6:27 am

gps_techie wrote: Mon Apr 14, 2025 5:46 pm eTrex SE internally has GPS receiver, magnetometer and accelerometer (for digital compass both are needed, it has calibration routine). Based on Garmin info, it uses GPS direction when moving with digital compass when standing still. I haven't seen any info about merging GPS data with accelerometer data, but that is very likely if not implied between the lines.

Where did you find this Garmin info?

Field knowledge of how these things work. I think that Garmin may use digital sensors to better discriminate "standing still" and "moving" states. This technique would not help much in terms of absolute accuracy.

gpsjorgen wrote: Mon Jul 14, 2025 6:27 am However, to entirely forget the GPS when standing still seems a bad idea to me.

Where do you get idea that GPS data if dismissed if standing still? It's not.

gpsjorgen wrote: Mon Jul 14, 2025 6:27 am Final measurements on Madeira
For GPSses Madeira is a tough environment, since you mainly walk along levadas along steep mountain slopes. You often walk the route and have to take the same route back. This gives us an opportunity to get a measure for precision: both routes, to and fro, should coincide, right?

GPS reception is very tough in such conditions. Routes will newer coincide because reception conditions differ in both directions (antenna positions are not identical, weather is not identical, satellites drift). In my opinion data gives some indication of precision, but these are only 2 tracks with 2 different models in different conditions. What would these test show if instead of [Fenix 7/67] combo [Fenix 7 & Fenix 7] or [67 & 67] were used?

Actual reasons for error are hard to judge without very specific tests - mainly because resulting data files are from internal (hidden) processing of raw input (whichh is not identical for each device). Different GPS models may have different tuning of algorithm and there are limitations of GPS accuracy anyway, especially for consumer devices.

gpsjorgen wrote: Mon Jul 14, 2025 6:27 am I sold my GPSMAP67 on the second hand market.

Unfortunately, more and more people have gone down this path. Garmin no longer cares about its automotive and hiking devices. Those of us who sold our old ones to get new ones turned out to be fools.

venci67 wrote: Tue Jul 15, 2025 9:32 pm Unfortunately, more and more people have gone down this path. Garmin no longer cares about its automotive and hiking devices. Those of us who sold our old ones to get new ones turned out to be fools.

Same here but I returned my 67 to Amazon within a few days of purchase (sadly at the great price of $399) due to a basic UI issue (important enough to me, however) that may never be resolved. Seems as Garmin's priorities have changed to other more profitable things like trolling motors and a bazillion different watches. I remember reading something, somewhere from a user reporting an issue to Garmin Support that they "didn't have the resources" to properly address the issue. If an important issue may not be resolved because of limited resources, why would they resolve a silly but blatant UI issue that is 100% reproducible, 100% of the time?

Although not directly firmware/unit software related, the below example also doesn't give much confidence:

v9.90 February 28th, 2025

Fixed crash on map when reviewing certain map points
Fixed possible missing find menu category

I believe the GPSMAP 67/67i is at v9.10, not v9.90. This has been displayed incorrectly since it was posted on Feb 28th, 2025.

Link to the GPSMAP 67 Firmware Update Release Notes page