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

Thanks Brandon.
That sounds like progress.

From my point of view, having a single variable that sometimes reports course (COG, direction of motion), and sometimes reports the orientation of the watch, is problematic.
It makes much more sense to me to have separate values that indicate those distinctly different measurements of physical reality.
Making Position.info.heading (to be renamed) indicate only the direction of motion from the GPS subsystem, and Sensor.info.heading indicate watch orientation based on the compass, makes it very clear to the developer, what they are getting, and where to go to get the measurement that they're interested in.

jim_m_58 over 7 years ago

Jeff, but it also makes sense that Activity.info.currentHeading show the compass data (if available) at low speeds and then the GPS heading above a certain speed.

Position - GPS but only changes above a certain speed
Sensor - Compass, if available, or maybe GPS even a low speed for other devices? (I've only used this on devices with a HW compass so not sure)
Activity - "what's best" based on speed - compass or GPS based. (this is the only one of the 3 that can be seen in a data field) The hybrid of the other two.

Somewhere (maybe an old forum post) I understand the switch in Activity.Info occurs in the 3-4 mph range

"what's best" comes into play even in Sensor with other things like HR (WHR vs an external band) or cadence (watch vs foodpod)

Alan.raceQs over 7 years ago

Jeff, but it also makes sense that Activity.info.currentHeading show the compass data (if available) at low speeds and then the GPS heading above a certain speed.

I strongly disagree. It makes no sense to confuse course over ground (heading) with watch orientation. They are totally different dimensions.

jim_m_58 over 7 years ago

maybe in your use case you need an alternate to what's currently in place as far as Activity.Info, but I don't think what's currently there should be changed just for your case.

Jeff over 7 years ago

Brandon....
Is there a technical description of how the GPS subsystem is designed... how it works... what's under the hood.... what is done in hardware, and what is done in software ?
If that's not readily available, would you be willing to provide a brief description ?

And.... are there technical descriptions of the watches that are supported by Connect IQ ?
Memory, processing speed, storage limitations, etc ?
I'd like to make the most of the platform and not overburden it, so understanding the details seems important.
Thanks
Jeff

Brandon.ConnectIQ over 7 years ago

From my point of view, having a single variable that sometimes reports course (COG, direction of motion), and sometimes reports the orientation of the watch, is problematic.
It makes much more sense to me to have separate values that indicate those distinctly different measurements of physical reality.

Yes, I agree. I can't make any promises at this point, but there are some pretty compelling reasons beyond this conversation for us to move in the direction you're suggesting. There's a similar discussion around other sensor information, too, like whether to provide a calibrated pressure value like we do now, or make calibrated and non-calibrated values available and let the developer decide what to use.

Traditionally, Garmin has always tried to provide customers with the best available data, so that's the cultural mindset we tend to have as a company. This has carried over into Connect IQ, resulting in things like Position.info.heading that are "overloaded" to provide the best available information via a single attribute. Developers are not customers, of course, so we've had to gently influence the culture to start thinking differently about how data is made available through Connect IQ. My impression is that we would like to start broadening these APIs a little bit to give developers more options and flexibility, but it's difficult to say how quickly these changes may happen.

Is there a technical description of how the GPS subsystem is designed... how it works... what's under the hood.... what is done in hardware, and what is done in software ?
If that's not readily available, would you be willing to provide a brief description ?

In short, no. :) This kind of info would is considered a trade secret and won't be shared. This is generally true for other sensor information, too, like how the step count is obtained by devices.

And.... are there technical descriptions of the watches that are supported by Connect IQ ? Memory, processing speed, storage limitations, etc ?

Not exactly. All supported devices are listed here: https://developer.garmin.com/connect-iq/compatible-devices/. This links to the product pages on the main Garmin site, which has some device-specific technical information. We also have a little of this information in the Programmer's Guide (see Appendix A). Specific to Connect IQ is the /bin/devces.xml file supplied with the SDK, which contains app memory limits, screen sizes, data field layouts, etc.There are plans to expand Appendix A to include more technical information, but I doubt we'll get too deep into hardware specs. However, one of our regular developers has created a benchmarking app that might be useful to you:

https://apps.garmin.com/en-US/apps/ac3c85cc-e467-4610-9a3b-90f3b8fbecc8

Alan.raceQs over 7 years ago

Developers are not customers, of course,[/url]

Amen to that!

jim_m_58 over 7 years ago

Just a note to the app Brandon linked to, be sure to click on "more", as Petr includes the scores he's collected from all the CIQ devices.

Also, in the SDK's bin directory, is devices.xml. It takes a bit of looking around, but you can find things like max memory per app type for a device. Don't modify this file though! You can also see memory info by setting a device as a target in the sim, and you see the current mem for the app as well as the max for that app type on that device on the bottom line.

Jeff over 7 years ago

Thanks Brandon.
I understand about trade secret decisions.
I was hoping that technical info in some form would be available to developers so that we can optimize performance on the devices.
I'll check out the links provided.
And Jim... thanks for the additional information.