SuuntoPlus feature: how can I get the next waypoint of a route?

renard

What I am building

A SuuntoPlus Feature Engine app for waypoint navigation, in the
general sense: boat, aircraft, walking. The idea is a heading
indicator, a ring around the bezel with a marker showing the bearing
to the next waypoint relative to the current ground track, so the
pilot or skipper only has to keep the marker centred.

The watch is a Suunto Ocean, on firmware 2.51.28, the current one.

Routes are created and pushed to the watch with the Suunto mobile
app. My feature does not create, store or select routes. Navigation
is started the normal way, from the sport mode’s own Navigation menu.

The feature sits next to the native data screens I already use:

Screen 1, navigation details: remaining distance to the next
waypoint, waypoint ETE and ETA, lap duration, nautical speed, ETE
to the end of the route, time of day.
Screen 2, global overview: remaining distance to the end of the
route, route ETA, lap number, sunset, altitude, temperature, total
time. I trigger a lap as I pass each waypoint, so the lap number
doubles as the number of the leg I am on.
Screen 3, summary: nautical distance, vertical speed, battery
percentage and hours, ascent, descent, max altitude.

So the watch clearly knows about the next waypoint. Screen 1 shows a
distance and an ETE to it.

What I need

The coordinates of the next waypoint of the route being navigated.
From those I compute the bearing myself, along with the distance and
everything else.

The map view does let me find my way back to the route, but reading a
map is not practical while flying or sailing. A single heading cue is.

The bigger problem is this: once I am more than about 100 m off the
route, the numbers stop. The map still draws the route, of course,
but the distance to the next waypoint goes blank, and so do its ETE
and ETA and the ETE and ETA to the end of the route. I saw all of
them sitting at “–” on a test walk where I left the route on
purpose.

That is exactly the moment when those numbers matter most. In an
aircraft or on a boat, being pushed off track by wind or current is
normal, and the questions “which way to the next waypoint” and “how
long until I get there” do not go away just because I am off the
line. Reading them back off a map is not an answer at 100 kt.

What I have measured

I built a debug screen that only reads native resources and displays
them raw, then walked a 2 km route with 8 named waypoints while
navigating it natively, photographing the screen along the way.

Working as documented:

/Navigation/Routes/NavigatedRoute/DistanceToDestination started
at 1991 m for a route measured at 2001 m and decreased to 0.
/Navigation/Routes/NavigatedRoute/Position went from 0.006 to
1.000.
/Navigation/State read 3 (on route) throughout.

Not what I hoped:

/Navigation/Targetlocation/Coordinates is not the next waypoint.
It never changed at all, from the first second of the walk to the
last, while I went up to 460 m away and came back. It holds the
point where I started the exercise.
/Navigation/Targetlocation/Distance is the distance to that same
fixed point, not to anything on the route. I checked it against my
own computation on eleven readings, all within 6 m.

So as far as I can tell, no documented resource exposes anything
about the next waypoint of a navigated route, or about the route’s
geometry at all. NavigatedRoute only offers scalars: distance to
destination, relative position, closest point index, ascents and
descents, ETA and ETE.

What makes me think something exists anyway: the reference documents
AscentToWaypoint and DescentToWaypoint as output formats. Those
are per-waypoint values, so the watch must track a next waypoint on a
route internally, and something has to feed those fields. The
reference is also demonstrably incomplete. Two features shipped to my
watch use paths it does not document at all:
Navigation/Poi/Active/Bearing is subscribed by one, and
/Navigation/Targetlocation/Latitude and /Longitude are written by
an official Suunto one.

Questions

Is there a resource, documented or not, that gives the
coordinates of the next waypoint of the route being navigated?
Coordinates are what I need. Distance and bearing I can compute
myself, and computing them myself also means they keep working
wherever I am relative to the route.

Better still would be a way to read the coordinates of every
waypoint of the route, not only the next one.
What resource feeds AscentToWaypoint and DescentToWaypoint?
What is /Navigation/Targetlocation/* supposed to hold while a
route is being navigated? Is the behaviour I saw intended?
Is there any way at all for a feature to read the waypoints of a
route that was pushed from the Suunto app?
Is the roughly 100 m off-route cutoff a fixed limit, and is there
a way for a feature to keep getting waypoint information past it?

Why I cannot just carry the route myself

The obvious fallback is to store my own copy of the route inside the
feature and compute everything from it. It does not hold up.

Routes change from one trip to the next, and a route is not always
reversible. An out and back can be read backwards, but a triangle, A
to B, B to C, C to A, cannot. So a stored copy would have to be
rebuilt into the feature for every new route, which defeats the point
of having the routes in the Suunto app in the first place.

What I want is the opposite: the pilot pushes a route the normal way,
and the feature reads whatever the watch already knows about it.

Thanks for any pointer.

sky-runner

@renard I don’t have any answers for your questions but I wanted to share a few observations from extensive usage of navigation with waypoints.

Suunto clearly has a concept of a sequence of waypoints because it can show waypoints on elevation profile and allows users to zoom in or out to show just one upcoming waypoint, or two, or three, or all of them. However I think the sequence is not numeric or predefined, but rather waypoints are attached to distances on the route - how far each waypoint is from the beginning of the route. However the trigger for the waypoint is the remaining direct distance to it.
As I mentioned above there is no predefined sequence of waypoints. I think it is far more dynamic. I think periodically the navigation determines where you are on the route and at which direction you are moving, and from that it dynamically builds a list of upcoming waypoints. But once it determines that you are off route it completely loses track of where you are. For example it assumes that you may have started moving in the opposite direction. So without you being on route it does no longer have a list of waypoints. Similarly, it can easily jump from one part of the route to another if the route intersects itself, which is immediately reflected in upcoming waypoints. Similarly, if the route backtracks for a short part before continuing in other direction, like having a short spur to a summit, Suunto navigation often mistakenly reverses instead of just continuing on the route, and then it shows the sequence of waypoints leading back to where you started. This all sort of confirms that the list of waypoints as a pre-planned sequence doesn’t exist as a concept.

Suunto Ambit handled waypoints exactly the way you describe, so it can be done. But it looks like Suunto team is hellbent on having this adaptive navigation which in my opinion causes more issues than it solves. It definitely doesn’t work for the cases that you describe. Also it doesn’t really work well for off trail navigation like a glacier where it may be impossible to stick to a pre-planned route. Furthermore the current navigation is overly sensitive to triggering off-route - often it is far less than 100 meters and sometimes there are clearly false positives where the watch shows me right on top of the route while triggering off-route alert. I think a lot of improvements are needed in this area.

renard

Thank you. Your description matches everything I have measured
from inside a SuuntoPlus feature, and it explains the one result I
could not account for.

Here is what I can add, measured rather than guessed, in case it is
useful to you or to anyone else reading.

The trigger really is the direct distance

A feature can read /Navigation/Poi/Active/Distance. While a route
is being navigated, that is the direct distance to the next named
waypoint, and it is accurate to about a meter: I logged it once a
second for a whole walk and checked all 495 samples against the
route’s GPX, and the best match is the expected waypoint every time,
to within 1m. /Navigation/Poi/Active/Name gives that waypoint’s
name and switches at the passage.

So the concept you describe from the outside is visible from the
inside too, and it is the only usable thing a feature is given about
a waypoint. There is no resource for a waypoint’s coordinates, and
none for a bearing to it.

Off route it all stops, exactly as you say

On one walk I left the route deliberately. For 178 seconds
Poi/Active/Distance, /Name, /Coordinates, /Bearing and
Routes/NavigatedRoute/DistanceToDestination all went silent
together. ClosestPoint and Position kept answering. Coming back
on route brought everything back.

This is the part I find hardest to accept as a design. Being off
track is the moment you most need the watch to tell you where the
next waypoint is, because that is the information you need to get
back on the route at all. On the line, where everything still works,
you can already see where you are going. The data is withheld exactly
where it becomes necessary, and for a pilot or a skipper pushed off
track by wind or current that is not a rare corner case, it is a
normal part of the trip.

Your point about reversing explains a result I had left open

I walked a short loop whose start and end sit 26m apart. The very
first sample, before a step was taken, read Position 1.000 and 50 m
to the destination, and the watch never ran waypoint navigation at
all for that walk. Position then went negative for the rest of it.
I could not explain it and left it unexplained. Your description of
the navigation reversing on an out and back, and then listing the
waypoints back to the start, fits it exactly.

What I did about the missing bearing

Since the distance to the next waypoint is exposed and its position
is not, the position can be recovered from the distance alone. Each
measurement says the waypoint lies on a circle of known radius around
a known position, and circles taken from a moving observer meet at
one point. Solving that over a leg puts the waypoint within a few
meters of where the GPX says it is, and from then on the bearing is
computed locally, so it survives the watch going quiet.

It works, but only for the waypoint the watch is currently offering.
Once off route there is no new waypoint to learn, so it carries the
current leg and no further.

The question I am left with

Is there any resource, documented or not, that gives a feature the
coordinates of a route’s waypoints? I have tried about twenty
spellings across Routes/NavigatedRoute and found none, and after
your answer I understand why: if the list is recomputed rather than
stored, there is nothing to read.

If that is so, then the only stored thing with coordinates that a
feature can reach is the POI library, through /Navigation/Poi/Count
and /Navigation/Poi/<index>/Coordinates, which do answer. Is that a
supported way to read them, and is it expected to keep working?