This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Edge Explore: Experiments in Initial Route Calculations and Enabled Maps

First the preliminaries: Firmware: 5.30; Unit is North American version, pre-loaded with North American maps; Turn by Turn Navigation is enabled in the Rider Settings; Bluetooth and peripheral connectivity all disabled; battery saver mode is enabled; Navigate to course start refused. All tests done at the desktop.

The course being calculated is 192KM long, was created in Garmin Connect, then sync'ed to the Explore via Garmin Express.

One Stock Garmin Map Enabled: a) AMR Standard Basemap, NR. Initial Route Calculation: 1 minute. Notes: This config ended in a Route calculation Error. Unusable.
Two Stock Garmin Maps Enabled: a) AMR Standard Basemap, NR; b) Garmin Cycle Map Amer, North. Initial Route Calculation: 9 minutes.
Four Stock Garmin Maps Enabled: a) AMR Standard Basemap, NR; b) Garmin Cycle Map Amer, North; c) Garmin DEM Map North America; d) Garmin Geocode Map North America. Initial Route Calculation: 9 minutes. Notes: No difference from having two maps enabled.
One Third Party OSM Map Installed and Enabled: A Routable Bicycle Map (Openfietsmap Lite) for Ontario, Canada (downloaded from garmin.openstreetmap.nl/). Initial Route Calculation: 8 minutes.

Conclusion: Looks like 8-9 minutes is the best case reference for calculating the 192km course with TBT navigation. NOTE: This is not the Ride Settings-->Routing-->Recalculation option which is OFF in this case. (That feature really gums up the works IMO).

This is the longest course I've ridden with the Edge Explorer and the unit performed adequately however every feature that wasn't essential for the ride was disabled; it was operating in a bare bones minimalist capacity.

Addendum: It seems the onerous route calculation times are just the nature of the beast. Various active map configurations don't seem to make that much of a difference for TBT enabled courses. That leaves the hardware--can't do anything about that--and firmware. In other threads it's been noted that firmware 5.30 may be aggravating calculation times and commenters remember earlier versions to be much speedier. I'm willing to try reverting back to version 5.xx but don't know where they're archived or the installation process. Any insights?

0 linguinee over 3 years ago in reply to Peraklo

Thank you. I'm off to work shortly and so it'll be a while before I install and test. I'll post results here.

0 TrippyZ over 2 years ago

If I turn off Guide Text on my Edge 1000 I don't have any 'route calculation' at all. It just instantly begins navigation.

0 bikepc01 over 2 years ago in reply to TrippyZ

Could'nt it be that the Edge Explore behaves differently?

0 linguinee over 2 years ago in reply to TrippyZ

Yes, that's so on the Explore was well. Without the Guide Text though you don't receive TBT guidance; the Explore will simply trace your journey on the map while you ride it (also outlining the loaded course). Therefore no data-table has to be generated involving point to point distances, street names and turning directions--ostensibly that's what's happening when the course is being "calculated".

So sans Guide Text you'll have to pay attention to the screen when riding the course. My preferred configuration has TBT guidance with battery saver enabled. I ride and the Explore wakes up with a notification to turn left on Main St. in 150m, then 70m, then now...then goes back to sleep until the next turn is imminent. Most of the time the Edge is sleeping, its screen blank and I only glance at it when it beeps and wakes to display a turn.

0 dpawlyk over 2 years ago

linguinee said:
One Stock Garmin Map Enabled: a) AMR Standard Basemap, NR. Initial Route Calculation: 1 minute. Notes: This config ended in a Route calculation Error. Unusable.

The Basemap doesn't have anywhere near enough information to do routing (it's missing many, many roads).

It's "doing things wrong" to use it for routing. Since it won't really work, how fast it is is irrelevant.

linguinee said:
Conclusion: Looks like 8-9 minutes is the best case reference for calculating the 192km course with TBT navigation. NOTE: This is not the Ride Settings-->Routing-->Recalculation option which is OFF in this case. (That feature really gums up the works IMO).

These devices use slow CPUs to reduce power consumption. So, you are, in part, seeing the result of a compromise.

The speed of the calculation also depends on the complexity of the track and the complexity of the network the track overlies. That is, calculation is faster if the track has fewer turns and if there aren't many roads.

Part of the increase in time might be due to trying to get a better route.

192km is on the longer side of the rides people are doing. If 9 minutes is too long, one might consider splitting the route. Another advantage to doing that is if you need to recalculate the route for some reason.

The speed of the route calculation doesn't depend on the "recalculation" settings or the battery saver stuff (these things affect things while riding, after the route is calculated).

0 linguinee over 2 years ago in reply to dpawlyk

This post represented my first concerning route calculations and was as much about determining calculation times as about what parameters do and don't affect the outcome. (I've another involving two firmware versions). It's a learning process; thank you for your insights.

Yes, recalculation has no bearing on the initial calculation times; I thought to include that parameter because in other threads there seemed to be some confusion between the two. To elaborate: route recalculation only pertains when straying off course while riding an active course--this can only happen after the course has been loaded and undergoes its initial calculation. Recalculation is what happens when the unit, on the fly, generates directions to steer a wayward rider back to the loaded course under navigation.

Don't know what, if any, bearing battery saver mode has on initial calculation times; it was noted in case its enablement throttled CPU cycles across the board (and slowed calculations). Typically, this is what a battery saver setting does on other gadgets.

dpawlyk said:
The speed of the calculation also depends on the complexity of the track and the complexity of the network the track overlies. That is, calculation is faster if the track has fewer turns and if there aren't many roads.

Part of the increase in time might be due to trying to get a better route.

It's evident that calculation times are contingent on course complexity and/or length but, where it involves this post, I don't think it has anything to do with algorithms trying to get a better route. The course(s) concerned was created in Garmin Connect and sync'ed to the unit where the Explore's calculations created a navigation table of directions (for TBT guidance). It didn't, nor should it, modify the course.

Now, with the Explore's feature "Courses-->Course Creator" where the unit itself generates a course using location inputs from the rider, yes, calculation does integrate popularity routing data and other user settings (Avoidance Setup, etc) to create an optimal route. In this scenario you've a point.