Position.info.heading vs Activity.info.heading and limitations

Background -
I'm trying to understand what Position.info.heading actually indicates, and what the limitations of that number really are.
After doing a bit of searching on the forum, I see a number of threads that indicate that the number provided is problematic so app developers have been putting time into "massaging" the number to get something that's more useful in their apps.

I've built and side-loaded the PositionSample app for a bit of testing, and I've loaded and experimented with a Sailing app that provided sources, as well as contacting the developer of that app.
My observations are.....
- The Sailing app uses raw data from Position.info.heading, so changes in reported heading are a direct reflection of the reporting from the Position class.
- In that app, and in the PositionSample app, the heading value does not change for long periods of time at low speeds (walking). I'll be doing more testing.
- Another app, called RaceQs reports heading. That developer has posted here about problems with Position.info.heading, and about reported time of GPS samples, and has stated that coming up with a Course Over Ground that is useful at low speeds takes a lot of massaging of the data.
- The RaceQs app reports meaningful Course over Ground almost immediately and at low speeds.
- All of these tests were done with GPS signal status being shown as GOOD.

Conclusions -
- It looks like there are limitations on the Position.info.heading values and reporting that I cannot find a description of in the API documentation, or on this forum.
- Developers like the RaceQs developer seem to have found that to get meaningful numbers, they have to develop their own substitute for Position.info.heading

Questions -
- What can I, and other developers count on from Position.info.heading ?
- Does the calculation of that value stop below some speed, and if so.... when does it start and stop ?
- Is there a difference between the value reported in Position.info.heading and in Activity.info.heading, or in any other reporting of heading ?
- What is the best, most accurate source of heading information, and what limitations on accuracy are associated with that source ?

After spending some time looking for these answers, I don't find them.
I hope someone at Garmin, or developers who have already been down this road will provide definitive answers.

Thanks

Jeff over 7 years ago

I calibrated the compass and re-ran my test.
No change in the result.
There is definitely a lower speed threshold, below which the info.heading value is not updated.
The heading value that I'm looking at is in degrees, to 4 decimal places.

Jeff over 7 years ago

It looks like the minimum velocity to get info.heading to update is 1 m/s.

jim_m_58 over 7 years ago

Actually, I see it change when standing still and just turning a bit (the compass comes into play here). With Hike2 on a va-hr I slowly walked in a 10' circle and it changed as it should. The version of Hike2 in the store just shows the 8 compass points for heading, but a got a version on my wrist that shows the degrees, and it's also working fine. It changes when I'm stopped, or walking up and down the street.

Jeff over 7 years ago

Three questions:
What data is your code reading to produce the heading you see ? Activity.info.heading ?
If you change watch orientation whilw you walk, does the heading value change ?
if you walk slowly in some direction, then turn around and go back, do the heading indications make sense?

jim_m_58 over 7 years ago

In Hike2, I'm using currentHeading from Activity.Info, but for the compass, I'm using Sensor.Info.heading

Yes to both questions. (I only update the screens every second so there can be a lag of a second or two)

BTW, Hike2 has been in the store since may 2016, but much of the code like this came from Hike that I started sometime in early/mid 2015. Combined, that's over 65k downloads, and nothing has been reported about a stalled heading (the va-hr was the initial target for Hike2, as it was the first CIQ 2.x device I supported)

I'm at a loss to explain what you see.

OK, a wild guess here.... You're using some sample code in a widget or an app. Could it be that you're not updating the screen often enough or something? The value is changing, just not the screen? This is something that's really hard to test in the sim, so you wouldn't see it there.

Jeff over 7 years ago

Hi Jim,
I just tried out your Hike2 app from the app store.
It looks like your Heading and Bearing numbers come from the compass, meaning the watch orientation to true north, not from the direction of motion.
If I hold the watch in a fixed orientation to true north as I walk around in various directions, the app indicates the direction the watch is pointing, not the direction of travel.

Jeff over 7 years ago

The PositionSample is one of the apps I've been testing with.
It updates all displayed values every time it get a GPS notification, so it redisplays Lat/Lon, Speed, and Heading in each update.
I can see Lat / Lon and Speed update rapidly.... probably once a second, and never get stuck on a single value.
Heading freezes on the last reported value if I'm walking slower than 1 m/s.
It updates again when I walk faster than 1 m/s.

The other app I use for this testing is called Sailing, from the app store.
It exhibits the same behavior.
It reports speed in knots.
1 m/s is about 1.9 knots.
If I walk slower than 1.9 knots, the Course Over Ground value stays fixed at the last value, whatever that was.
When I walk at 1.9 knots or faster, the Course Over Ground (heading) updates to my actual direction of travel.
If I turn around 180 degees and walk at a speed of less than 1.9 knots, the last heading continues to be shown
until I walk faster than 1.9 knots.

I am now quite clear about what is happening.
My question now is... is Garmin clear that there is a problem, and are they interested in it ?
The Speed number is updated without fail, regardless of the value, so the calculations to produce the speed are happening when each location sample arrives.
Why the Heading is not being updated when speed is less than 1 m/s is the mystery.

Someone from the Garmin team please ?

jim_m_58 over 7 years ago

I guess I don't understand what you are expecting. When it comes to any sensor on a garmin watch, the firmware has a priory that's based on what's available, and may choose one over another based on the FW's own methods. If there's a footpod, use that for cadence instead of the watch itself, for example. As far as the compass, that's used at certain speed, and then GPS is used, the way I understand it. And since this is a watch, it's kind of assumed it's on your wrist and points in the direction you are heading when you look at it, and not always pointed at true north :)

Maybe you could use a pair of lat/lon locations to get what you want (point "1" and the current location?) I do that for waypoints as well as start location in Hike2.

jim_m_58 over 7 years ago

You want to submit a bug report in the bug report forum, and be sure to go by the rules in the sticky post at the top of that forum with a description and a way to reproduce it, etc.

You probably want to include a link to this thread in the bug report.

Jeff over 7 years ago

I'm working my way toward writing an app that cares about direction of motion regardless where the watch wearer's hand might be.
You're right... for a lot of apps, expecting the user to bring the watch up for viewing is reasonable, and giving them good information at that moment would be the priority.
What I was hoping for was that the GPS hardware and the supporting software would provide a meaningful value for Heading.... direction that the watch is moving.... whenever there are good GPS signals. I believe that I've proven that that is not the case.

A side-effect for an app like yours might be, that if you plot heading over time and compare it to position over time as someone walks, with their hand in their pocket, or pointing at something, or swinging it back and forth as they walk, or holding someone's hand..... the compass reading that you'd be using would show directions that are not related to the direction that the user was walking.

Again... I understand that for many, probably most apps for these devices, what I'm looking for may not be very important, which may explain why this "feature" of the GPS operation hasn't been considered worth fixing by the folks who set priorities at Garmin.

That said... as a developer who has worked with GPS before, it's entirely reasonable to expect that if you have good satellite signals, the hardware & software that supports the GPS should deliver Lat/Lon, Altitude, Speed and Heading (direction of motion) information to the accuracy of the signals being received from the satellites.

I can say with confidence now, that that is not happening in the Vivoactive HR at speeds below 1 m/s.

And... you're right, I can add logic and calculations to use pairs of lat/lon locations to come up with the direction of travel between those two points, but that adds work and code and debugging etc, as well as increasing the run-time processing of my app, which impacts battery life..... and this is fundamental to what a GPS subsystem should deliver to it's users.

So.... I hope that someone at Garmin takes interest.
Thanks for helping out.