Incredibly slow route calculation - Garmin Edge Explore

MaxR6 said:

Are you a GARMIN employee?

No!

The fact that Garmin developed a new Explore 2 model proves for me that they recognise that the original Edge Explore 1 has design flaws and (for some / many people) missing features.
The initial calculation of the TBT data every time for an already loaded course is a design choice that Garmin implemented in all Edge models from the beginning. You can accept that or not, and if not, don't buy an Edge.

My saying "Good news..." was mainly meant for new buyers because now with the Explore 2 they can have a cycling oriented bike computer without the annoying TBT calculation time lag before every ride and a completer package.

I will agree on that when I see hardware specs comparison. If there is no significant increase (say 30% or more) in hardware power, there is no reason this problem can't be, at least partially, solved by re-coding. For now it just looks like reaping moneys from cyclists (not that other companies aren't doin the same, it's all capitalism)...

linguinee said:

But neither detailed route loading/calculation and what, if anything, has changed there. Where did you learn of the route calculation protocols being improved? I can find nothing on that topic.

I read about the changed calculation implementation for the TBT data in a review of a specialist Dutch Garmin reseller "Waypoint" (www.gps.nl). The review (in Dutch) is here: https://www.gps.nl/blog/review_garmin_edge_explore_2.html

And I own an Explore 2 already and I can confirm the 'immediate' availability of the TBT guides after pressing "Ride" of a selected course that is stored on the device. In the file structure on the device there are folders with cached data. There is a folder 'Calcs' containing a .cal file for every course and a folder 'PointCache' with corresponding .gpc files.
The device itself is a rather new experience compared to the original Explore - different menu's, different structures, Three cycling profiles, etc., etc. The design team looked at the 1040 possibly? Time will learn if all changes are benefits for the enthousiastic recreative cyclist and how many firmware revisions will be needed to make the Explore 2 full grown (or not...).

Of course you are right in saying that the original Edge Explore needs firmware upgrades to correct existing flaws. I'm not optimistic they will appear still.

Thanks for the link to the Dutch blog. Impressive that such a detailed run through is available so soon after the Explore 2's release. I agree that whatever future firmware upgrades are slated for the Explore 1, if any, they'll address nothing substantial. The Explore 2 signals the end of further (dubious) improvements for version 1. We get what we've got.

The Explore 2 is the device I wanted a few years ago. Now? I'm not in any rush to repeat the regret. Generally, the real good news is that the sector abounds in choice like never before. Wahoo, Karoo, Bryton, etc.; simply relying on a smartphone for navigation is more viable than ever as well. For me, the enduring lessons of the Explore 1 are: a) a GPS is an indispensable accessory for a touring cyclist; and b) Garmin's implementation has been frustrating and disappointing.

bikepc01 said:

The initial calculation of the TBT data every time for an already loaded course is a design choice that Garmin implemented in all Edge models from the beginning. You can accept that or not, and if not, don't buy an Edge.

No!
That the forced by the software new recalculation of already calculated and in GARMIN Connect created routes takes so extremely long that I have to wait 15min in front of my bike before a short 40km ride, is nowhere communicated in the GARMIN advertising.
Also, all the paid product testers on the Internet have not honestly tested the device or warned of such glaring performance weaknesses.

MaxR6 said:

I have to wait 15min in front of my bike before a short 40km ride

That's an extremely long time indeed, but not representative in general for "the Edge Explore". If I load a 120km course, prepared in old trusty Mapsource, the initial calculation does not take more than 5 to 6 minutes. So something must be peculiar at your side. Agree, will not be easy to determine the cause(s). Please don't feel accused - I'm not saying YOU are doing wrong. There is a complicated matrix with interrelated facts and circumstances, Maybe interesting for people who like puzzling.

Allways take measures so that the map in Mapsource (more general: the tool that you use to design your route) is the same (also version!) as the one on the Explore. I use the (OSM) OpenFietsMap Benelux - not the Garmin Cycle Map.

When I prepare a tour from scratch:
- plot the tour as a route in Mapsource and save the route as a .gpx file on the PC
- convert the route to a track without filtering. I'm using a small external program WinGDB3 because that cooperates very well with Mapsource via the Clipboard. I think designing the route and conversion to a track can be done too in Basecamp.
- filter the number of trackpoints to about 12 - 15 per km (the more complicated the track, the more trackpoints). I'm using a small external program JaVaWa RTWtool for that job because the filtering algorithms in that program is smarter compared to the one in Mapsource. RTWtool also corrects small glitches when a trackpoint has a small deviation from the road it should be on. Save the final track as a .gpx file and is ready now to copy to the ..\Garmin\NewFiles folder on the device.

The result is a very clean track that fits perfectly on all roads on the map and the filtering reduces the initial TBT calculation time. Also during the ride only recaluclations are proposed when you deviate from the course and not recalculations that are caused by inaccuracies in the course caused by a inaccurate track.
It maybe look like a complicated and time consuming procedure, but it is baked in my normal routine and doesn't hurt in any way. Other people may think differently about this of course.

When I have downloaded a track from a foreign source I remake the track by overdrawing it with the Route Tool in Mapsource, followed by the same steps as above, resulting in a 'clean and mean' track ready to be loaded in the Explore. Foreign tracks often suffer from inaccuracies and often they are designed on different maps, for example Google maps, compared to the one on the Explore.

Why this long story? I hope to illustrate that it is possible to use the Edge Explore in a non-frustrating way with maybe some precautions to circumvent a few flaws.

bikepc01 said:

Why this long story? I hope to illustrate that it is possible to use the Edge Explore in a non-frustrating way with maybe some precautions to circumvent a few flaws.

Well, you’ve got me chuckling. What you’ve managed to illustrate amounts to a detailed indictment of Garmin’s software design and engineering efforts.

Reading through your circumventions the reasonable conclusion is that Garmin is selling a problem rather than a solution. Let's return to first principles.  All of us here just want to ride our bikes and know where the hell we’re going. That’s what we signed up, and put our money down, for.

GARMIN designed the ecosystem (Connect, Express and devices) and its protocols for that purpose and you’re basically advising they be rejected and the process complicated with third party apps and processes because the outcome is too frustrating. Hey GARMIN, what do you think of that endorsement?!

The notion that it should be incumbent on a customer to accommodate and solve a product’s flaws is self defeating. We buy tech because it services our needs and solves our problems. Not the reverse.

I hope GARMIN reads your post. I suspect you care more about making their products work satisfactorily than they do. Thank you for the insight though, seriously.