Documentation Request

The issue of having multiple possible inputs for speed, cadence, distance and elevation gets a bit complicated and not all watches and not all activities handle the inputs in the same way.

I just spent a lot of time reverse engineering the speed filtering on the VivoActive and Epix. The 2 watches filter differently, they filter differently on CYCLING vs RUNNING, and they filter differently depending on if the input is GPS or a footpod.

It would be nice to have a matrix that covers these nuances because the reverse engineering approach is not very practical when trying to make a consistent user experience over multiple watch types.

The pieces of information that I think are most needed are:

Which input sources are possible for each metric, each watch and each activity?
If multiple inputs are present, which one does the watch give priority to?
What are the units?
What determines when the data gets updated?
Is there any pre-processing of the data like smoothing, stop detection, etc?
What happens when the signal is lost?
Are there any known bugs?

Brandon.ConnectIQ over 9 years ago

Thanks Roger--I think these are good suggestions. We're actively working to improve our docs, so I'll put this on the books as a potential addition for the future.

Brandon.ConnectIQ over 9 years ago

Hi Roger--just thought I'd loop back to you on this. I submitted your ideas for doc improvements, and I guess a lot of this information crosses over into territory that's considered proprietary, since it relates to how our positioning system works.

Even though I can't publish this information, I understand your situation. I think a lot of the responsibility falls on us to bring more consistency between our devices. Since most of our products are purpose-built, there is always the possibility of differences.

julienvm over 9 years ago

Hi Brandon,

I'm on Roger's side on this one. Maybe the people you talked to internally thought we want to know in detail how the device works, and uncover some proprietary information (perhaps "reverse engineering" spooked them). That's not the case.

An example of what we want to understand is, for each product, whether "Position.altitude" (supposed to be GPS-based elevation):
- is always in meters
- whether there are times when the watch switches from GPS to altimeter (in case GPS is unavailable)
- is the update rate of the data always 1 Hz (not internally in the sensor, but what data is provided to the framework)
- etc..

This is not us requiring proprietary data. This is developers that try to make your product even better, requesting a technical specification of the data provided, so we can use it to deliver great apps and increase the value of your product.

I honestly believe Garmin can provide such specifications, without revealing any proprietary information.

Thanks Brandon for your help on this forum!

Julien

Brandon.ConnectIQ over 9 years ago

HI JULIENVM,

I appreciate your thoughtful response. The internal conversation about this isn't over yet. In fact, I'm going to be discussing this more in-depth with AlphaMonkey this afternoon. Your posts requesting more aviation data specifics have been timely, and is some of the evidence I'm using to argue for more information to be made available.

Part of the trouble from my position is that we (as in Connect IQ) are often just exposing values, like altitude, cadence, etc., which are served up from a deeper level in the OS. Connect IQ doesn't have any real awareness of the nature of the data--it just requests it from the system, and returns whatever it's given. So it's not that I simply cannot find out more, but many of the specifics aren't apparent to me either. :)

I think we can find a happy medium between providing developers useful specifications without opening up the entire Garmin OS, but I need to have a better understanding about our concerns before I can say for sure. If you all can bear with me a little longer, I should be able to have a better answer soon.

julienvm over 9 years ago

Hi Brandon,
Great! Thanks for your response.

OK, so as I said, I'll be putting together a document explaining which datafields we need and why, with eventual priorities. I'll try to ship it by Monday.
Julien