Basecamp Windows - Recent Threads

RE: City Navigator North America NT 2027.1 seems to be detailed streets etc of smaller towns

SergZak — Wed, 08 Jul 2026 21:49:37 GMT

It could be that Basecamp's "map card cache" is corrupted in some way. I've had this happen various times in Basecamp and the procedure below always corrects it. Note that after doing this and running Basecamp again with the unit connected, the maps on the GPS unit will need to be re-indexed by Basecamp for proper usage. This will take some time so be prepared for this delay.

Delete the BaseCamp CardProductCache folder:

Windows:

Press the Windows key + R.
Type %userprofile%\AppData\Local\Garmin\
Click OK.
Open the BaseCamp folder.
Right-click on the CardProductCache folder and choose Delete.

Mac OS X:

Press Command key + Spacebar.
Type ~/Library/Caches/com.garmin.BaseCamp
Open the Folder.
Drag the CardProductCache folder to the trash.
Empty the Trash.

support.garmin.com/.../

City Navigator North America NT 2027.1 seems to be detailed streets etc of smaller towns

5619465 — Fri, 03 Jul 2026 16:59:00 GMT

using the City Navigator North America NT 2027 in basecamp connected via my Zumo 660 and the street resolution of smaller towns or parks etc is now missing - as I recall it used to be visible. Needless to say it makes planning difficult. Is there a way for basecamp to show this additional detail. What is the workaround if any? I tried changing Display rendering quality to high but that didn't work.

RE: City Navigator North America NT 2027.1 seems to be detailed streets etc of smaller towns

Peobody — Wed, 08 Jul 2026 16:34:12 GMT

Yes. I also thought the two map files were for different parts of North America but I just tested how they work using the maps on my XT and viewing a small town in North Carolina. One map showed the city and neighborhood streets while the other just showed major roads similar to what the Global map shows. At first I thought I was looking at the Global map but switching to it made a visible difference in the location and shape of one of the streets. That was a long way of saying: Try the other map.

RE: City Navigator North America NT 2027.1 seems to be detailed streets etc of smaller towns

BTLAAKE — Tue, 07 Jul 2026 13:19:22 GMT

Memory format on devices requires 2 map files for CNNT. Devices can display multiple maps while BaseCamp can only display one at a time. The Maps in BaseCamp should show two 2027 maps. I believe one map covers USA and the other covers the rest of North America.

RE: Latest Topo Maps not compatible with Basecamp

jaqsicoder — Tue, 30 Jun 2026 10:11:08 GMT

It does sound like Garmin may have changed the format or protection of the latest Topo maps, especially if older maps still work in BaseCamp while the new ones don't. Hopefully others can confirm whether it's a broader compatibility issue or if Garmin has effectively ended BaseCamp support for newer map releases.

Latest Topo Maps not compatible with Basecamp

graemesmith1960 — Sun, 31 May 2026 08:44:49 GMT

Just want to check that it's not my system: Normally I can view any Garmin Topo Maps on my devices by connecting them to my PC and loading Basecamp. It's a very slow process but does work. I've just downloaded 2 of the latest maps (Hong Kong and also China) and I now get an error saying there is an issue with both the maps. This happens on my D2 Mach 2 Pro and also on my H1 Plus. Loading the maps from SD card doesn't work either. My other maps are all fine and the devices can use the new maps without issue.

I am aware that Garmin don't support Basecamp anymore and that this was bound to happen eventually. Have the map file formats changed recently? If they have I'll stop trying and find alternative maps as I use Basecamp for all my planing as I can't stand the lag and latency of the online Explore site and my fingers are not nimble enough to use the smartphone app!

can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

8627914 — Tue, 16 Jun 2026 18:54:26 GMT

It's not described in garmin documentation, but it's seem it's the only explanation to the value de <gpxtrkx:Distance> attribute of gpx track by garmin using Garmin64S.

See under a sample:

mean speed : 2.61km/h

duration : 6h16mn

2,61km/h ×(6+1÷4+1÷60)h = 16km36

but the sum of slope distance = 14km78

and the horizontal distance = 14km56

14km78 vs 16km36

from gpx file :

<gpxtrkx:Distance>16360</gpxtrkx:Distance>
<gpxtrkx:TotalElapsedTime>26215</gpxtrkx:TotalElapsedTime>
<gpxtrkx:MovingTime>22586</gpxtrkx:MovingTime>

for Garmin basecamp

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

jaqsicoder — Tue, 30 Jun 2026 10:09:54 GMT

Thanks for the detailed explanation. The distinction between the trip computer's continuously calculated distance and the track log's recorded points helps clarify why the GPX gpxtrkx:Distance value can differ, especially during slow hiking where GPS drift has a greater impact.

RE: BaseCamp & Zumo XT3

SUSSAMB — Thu, 25 Jun 2026 19:52:12 GMT

As you have a Zumo you will get better support here https://zumouserforums.co.uk/

BaseCamp & Zumo XT3

Salavat — Thu, 25 Jun 2026 14:05:23 GMT

I’ve downloaded both Garmin Express and BaseCamp. Is BaseCamp not compatible with the Zumo XT3? Also, I can’t figure out how to load the detailed map into BaseCamp. Can anyone help me? Thanks!

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

8627914 — Sun, 21 Jun 2026 20:05:09 GMT

Thank you very much

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

BTLAAKE — Sun, 21 Jun 2026 18:45:57 GMT

[quote userid="2392439" url="~/apps-software/mac-windows-software/f/basecamp-windows/438178/can-you-confirm-gpxtrkx-distance-is-computed-using-mean-speed-by-duration/2039536"]Do you mean odometer of "trip computer" use those 26 000 points?
and tracks only 1320 points?[/quote]

Yes this is probably the case. A one second interval makes the coding easier. The calculated distance will be in meters. With a 1 second interval the distance value is also the speed in m/s. A different interval would require calculating the speed to determine stationary or moving (distance alone would not be reliable). So, yes the trip computer likely looked at and dealt with some 26 000 positions, but it doesn't store 26 000 points.

The trip computer doesn't show the final results of a trip but is constantly updating. The easiest way to do this would be to keep a running tabulation of time and distance. From a logic standpoint, the device takes adjacent position solutions and calculates the distance between the solutions. This value determines moving or stationary. Add the time interval to either moving time variable or stationary time variable. If stationary, ignore the distance. If moving, add the distance to the distance variable. Then convert the results to the user set device units for display.

Users have some control over the time interval for logging a point. The shortest fixed interval is or was 1 second. So this is probably the interval of the device determining a solution to position. Devices generally have a logic based non-fixed interval as a default. I can not tell you how it works. I would suspect that there is a maximum time interval when the unit must log a position. I could imagine a change in direction threshold would trigger a logging of data. Beyond that would be complete guess work.

The following is also guesswork. In the early days, the question of why the trip computer had a different distance than the track log was not a rare event. I suspect customer service got tired of dealing with this discrepancy. Someone made the decision to include the trip computer stats with log data when saving or downloading a track. This makes some people happy. But, as your friend noticed, it creates questions about the accuracy of Garmin devices compared to other devices. I agree that including the trip computer stats was a bad decision on Garmin's part.

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

8627914 — Sun, 21 Jun 2026 15:55:06 GMT

[quote userid="26858" url="~/apps-software/mac-windows-software/f/basecamp-windows/438178/can-you-confirm-gpxtrkx-distance-is-computed-using-mean-speed-by-duration/2039513"]The trip computer used over 26,000 points (it determines a position in 1 second intervals)[/quote]

Thank you very much for yours answers

Do you mean odometer of "trip computer" use those 26 000 points?
and tracks only 1320 points?

What are the relations between "trip computer" parameters and "tracks" parameters?

No explanation in Garmin 64S docs

BTW, I do not have any issue with the tracks and its length, even if the collected points would not fall on a straight line due gps accuracy and moving speed.

I have an issue with the way Garmin fills the "gpxtrkx:Distance" attribute of tracks and the way trip computer works.

I read on other forum that the error of odometer can be between 10% and 40% due to slow moving speed of hikers and measure frequency
Of course I found also some mitigations and workarounds, like yours...

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

BTLAAKE — Sun, 21 Jun 2026 11:15:57 GMT

The track log recorded 1320 points. The trip computer used over 26,000 points (it determines a position in 1 second intervals).

GNSS does not give a true position. The direction and magnitude of error varies. The more points collected the greater the cumulative error.

Determining motion at a 1 second interval can be done simply by looking at the distance between adjacent points. In the track log it is easier to use speed.. The first 5 points in the data you provided indicate 16m of movement. According to the internet, turtles walk around 0.8 to 1.6 km/h. If I assume your friend is faster than a turtle, the speed column suggests that your friend was stationary and that 16m should not be included in total distance.

If one were to collect data while walking a perfectly straight line, all of the collected points would not fall on that line. The distance based on all of the points would differ from that using just the first and last point.

Garmin didn't always included the stats from the trip computer. But they were getting a lot of questions from people wondering why the trip computer distance differed from the track log.

Too many points accumulates to much error. Too few points does not accurately capture the curves in the true path.

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

8627914 — Sat, 20 Jun 2026 15:08:04 GMT

[quote userid="26858" url="~/apps-software/mac-windows-software/f/basecamp-windows/438178/can-you-confirm-gpxtrkx-distance-is-computed-using-mean-speed-by-duration/2039102"]The trip computer calculates then distance, direction and elevation between two positions. The change in position is also the speed in m/s (1 sec interval between positions). [/quote]

BTW, I don't understand your explanation, and why the gps device records a wrong statistic in "gpxtrkx:Distance" attribute. I guess BaseCamp just read this attribute without any new computation. So the issue is Garmin 64S computation 😞

This track was recorded by the Garmin64S of one of my friends

She asked me why her gps device gave a wrong distance in comparison with the distance computed by the hikers's others devices (smartphones, watches,etc) and in comparaison with the result given by opensource software like gpxsee, gpx_editor or viking.. This is why I computed myself the distance in cartesian projection using Qgis and Calc.

1.5 km error, it's around 10% error even if even if it flatters the hikers' ego 🙂

I own myself an older one , I will check if the issue was there also

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

8627914 — Sat, 20 Jun 2026 14:42:35 GMT

[quote userid="26858" url="~/apps-software/mac-windows-software/f/basecamp-windows/438178/can-you-confirm-gpxtrkx-distance-is-computed-using-mean-speed-by-duration/2039102"]In basecamp, make a duplicate of this track. In the properties window select and delete point 6. This will force a recalculation of the statistics and they will be based on the track log.[/quote]

you're right, the statistics are ok now
and it's the horizontal distance : 14km56 rounded to 14km6

btw, if I delete a non-zero distance, the result is the same, it's just a way to ask Bascamp to recompute stats

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

8627914 — Sat, 20 Jun 2026 14:34:16 GMT

[quote userid="26858" url="~/apps-software/mac-windows-software/f/basecamp-windows/438178/can-you-confirm-gpxtrkx-distance-is-computed-using-mean-speed-by-duration/2039102"]I assume you added up the leg distance column to obtain the 14km56, and added the ascending/descending values to obtain 14km78. [/quote]

I import track in qgis, then export track data using CRS Lambert93 (so in cartesian projection), then using Excel, I compute distance thanks to Pythagore

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

8627914 — Sat, 20 Jun 2026 14:30:38 GMT

of course, I use pythagore

RE: can you confirm "gpxtrkx:Distance" is computed using mean speed by duration?

BTLAAKE — Thu, 18 Jun 2026 18:15:12 GMT

A saved or sent track contains statistics based on the trip computer and the track log.

Devices determine a position every second. The trip computer calculates then distance, direction and elevation between two positions. The change in position is also the speed in m/s (1 sec interval between positions). The programing probably uses a threshold value to determine moving or stationary. If moving add 1 to moving time; distance to total distance, elevation change to ascending or descending based on sign. If stationary, add 1 to stationary time. The distance value is likely rounded to the nearest meter at the end of the track.

The track log records positions based on it's own logic or your setting. I assume you added up the leg distance column to obtain the 14km56, and added the ascending/descending values to obtain 14km78. If you did this, you included distances recorded for stationary movement that were rejected by the trip computer. You also suffer from rounding errors in each leg distance.

In basecamp, make a duplicate of this track. In the properties window select and delete point 6. This will force a recalculation of the statistics and they will be based on the track log.

As an aside, adding ascent/descent to horizontal distance does not give total distance. Climb 10m over 100m horizontal is a distance of ~100.5m not 110m. Climb 100m over 100m horizontal is ~141m not 200m.

RE: windows wants to format my Approach S4, what is the problem?

Peobody — Mon, 08 Jun 2026 23:24:15 GMT

This forum is neither for Garmin Express or the Approach S4. It is the forum for Garmin Basecamp routing software. That said, check out this Garmin support article.

My Approach Device Is Not Found by Garmin Express

windows wants to format my Approach S4, what is the problem?

JoeWSr — Sat, 06 Jun 2026 17:32:36 GMT

Garmin Express does not find my S4 and it is plugged in and charging.

RE: Latest Topo Maps not compatible with Basecamp

dpawlyk — Fri, 05 Jun 2026 14:16:02 GMT

Yeah, I saw you figured this out.

Hopefully, the info is useful for other people.

(I doubt Garmin is going to address the problem.)

RE: Latest Topo Maps not compatible with Basecamp

graemesmith1960 — Fri, 05 Jun 2026 14:11:10 GMT

I use Talkytoaster for most of my maps as they do specific Basecamp maps for everywhere.

RE: Latest Topo Maps not compatible with Basecamp

dpawlyk — Fri, 05 Jun 2026 13:04:04 GMT

There was an issue with one of the Europe maps not displaying.

I brought up the issue to Garmin. They looked at it some but never resolved it.

Depending on what you are doing, you might be able to use a map from one of the many alternative providers of OSM maps in BaseCamp. These maps are often free.

I use maps from bbbike, for example.

RE: Latest Topo Maps not compatible with Basecamp

graemesmith1960 — Thu, 04 Jun 2026 09:24:50 GMT

Hi, thanks but I've tried that already as it happens to me every now and then as well. I just loaded a new map of a different area and it was fine. Looks like it just affects the China and HK maps.