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

jim_m_58 over 7 years ago

A few things here - like watch watch you are testing on - does it have a HW compass? Also, with using Position (and I beleive Activity.Info), GPS comes into play and not just the compass. One thing I've heard in the past, but never checked out, is that above a certain speed, GPS overrides the compass. Another thing I know is with a compass, unless you are holding it such that you are looking at it, the heading will be off, as the top of the watch could be pointing west when you're heading north with your arm by your side.

There are other ways to get the heading on watches with a compass, such as Sensor.Info.heading and the raw data from the compass itself - see the AccelMag sample in the SDK.

That said, I have a few apps that show heading and in some a compass, that seem to work just fine using the things I mentioned, and I have also used also Activity.Info Using mag directly is a bit of a pain though. :)

Maybe a few more details on what you are trying to build, speeds involved, etc.

Jeff over 7 years ago

Hi Jim,
The watch I'm currently working with is the Vivoactive HR, but the question applies to any ConnectIQ device that has a GPS.
I'm only interested in speed of travel and direction of travel.... motion.... not the orientation that the watch is being held in, so I don't believe that the compass will help.
The speeds involved range from a leisurely walk to a solid sprint.

I'm hoping that the Garmin team can provide technical information about how Position.info.heading is produced, and what limitations are imposed when it is calculated, beyond the basic accuracy limits of GPS. As I said above, it looks like it stops updating... like it just isn't calculated, when speed drops below some threshold. I haven't completely proven that yet, and I'd like to get good information rather than spending time testing to see what the Position class actually delivers.... when the numbers are meaningful, and when they are not, beyond just the indication that satellites have been acquired and the GPS hardware has good signals to work with.

I'd also like to know the outcome / resolution of RaceQs questions about the GPS Sample Times being off and skipping a second, I think one in 20 if I remember right.
Any resolution there ?

jim_m_58 over 7 years ago

I have a few walking/hiking apps and I've never seen the data just stop updating. They are recording apps, so I pull the heading from Activity.Info or Sensor.info.

I could see it "stalling" if the GOP quality is bad for some reason. Are you checking accuracy for your positioning data? When you say stalls, is it a second or two, or more like 10-15 seconds? Are you seeing the stall due to the timestamp, or on the screen itself?

Is it released to this:

https://forums.garmin.com/forum/developers/connect-iq/connect-iq-bug-reports/150142-the-gps-time-on-the-va-hr-runs-5-slow

Jeff over 7 years ago

The value of Position.info.accuracy is used to display an indication of GPS signal quality, with GREEN indicating QUALITY_GOOD.
I only start my test when the indicator is green and I haven't seen it change to Yellow or Red (lower quality).
I added that indicator to the PositionSample.

jim_m_58 over 7 years ago

I was sending by post when you posted, but the main thing is how long are these stalls? a second or 2 or 10-15 seconds? What I'm not understanding is I doesn't see these stalls in my own apps, so it's unclear what you are seeing. Maybe try something like HIKE2 and tell me when you see the stalls, on which screen and under what conditions?

Jeff over 7 years ago

Not a bad idea to try one of your apps.
My tests are...
- Start the app
- Wait for the indication of a good GPS signal.
- Heading will show some number.... not relevant to any motion.
- Start a timer on my phone.
- begin to walk and watch the HEADING indication
- the original HEADING number continues to be shown while speed and Lat / Lon update.
This state, with Lat / Lon and speed updating and Heading not updating persisted for 2 minutes before I stopped the test.

I did the same test with the PositionSample and got the same result.
Neither app is a recording app.

I did the same test with the RaceQs app and immediately got heading reports (course over ground) that updated and made sense, showing a 180 degree change when I reversed directions.

Another test.... I ran the Sailing app (not RaceQs) in my car while running an errand.
It reported solid heading values that changed as my direction changed.
When I got out of the car and walked a bit, without stopping the app, the heading value stopped updating and stayed stuck on a heading.
I tried walking back and forth a bit....
The value didn't change.

This is why I'm curious about whether there is a difference between the processing, and the number that's provided through Position.info.heading v.s. Activity.info.heading.
It's quite possible that the Activity processing provides a different number for heading.
I'd like to know what is being provided rather than having to attempt to reverse engineer this to end up with a guess about what is being provided.

Garmin Team ??

Jeff over 7 years ago

There is, in fact, a lower speed threshold.
Walking slowly results in heading values that don't change with changes in direction.
Walking fast results in heading values that change and track changes in direction.

jim_m_58 over 7 years ago

Two questions:

1- have you calibrated the compass on the watch?
2- when you say you are displaying a number for heading, is it in radians or do you convert it into degrees? In radians you won't see that much of a change.

Alan.raceQs over 7 years ago

Jeff, just to let you know I am following your thread but am keeping my powder dry for the moment, hoping you can elicit some response from Garmin.
I believe there are some deep flaws in the GPS interface on the VA-HR, but without access to any other CIQ2 device, I'm uncertain how widespread the issues are.
Working at sailboat racing speeds of around 5-10 knots, these issues seriously impact the task of capturing the real speed and heading of the yacht.

Jeff over 7 years ago

RaceQs... I had a feeling you'd be monitoring. I was hoping so.
It sounds like you've put quite a lot of work into coming up with a work-around.

Jim... I haven't calibrated the compass for these tests. I don't believe that the compass is a factor here, but I can do that and re-test.
The Sailing App and RaceQs app display heading (COG) in degrees.
I've modified the PositionSample app to display heading, and display it in degrees to 4 decimal places.
When I'm walking slowly, the value does not change at all.
Before I changed to displaying in degrees in PositionSample, it displayed in radians to 5 or 6 decimal places.
That value did not change at all at low speeds.

Preliminary conclusion -
If your apps do not exhibit this behavior.... not updating heading at slow speeds regardless of changes in direction, then my guess is that the Activity code that produces Activity.info.heading is smart enough that, at low speeds, it waits to calculate heading across multiple sample periods in order to get enough physical distance between points to produce a "good" heading value..... a value that is meaningful in the face of GPS position noise..... and the Position code does not do that.

I'll be back shortly with test results after calibrating the compass on my watch.....