SPEED Source

There seems to be two errors in the API docs:

https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Position/Info.html#speed-instance_method

First, on a bike, the speed sensor is more accurate than GPS, esp when mountain biking. MUCH more accurate as the trees and twisty turns cause the GPS to often be short by 10% or so. And the speed sensor seems to take priority on the device. But the docs say:

Speed is derived from the most accurate source in the following order: 1. GPS 2. Footpod 3. Accelerometer

Second, barometric sensors are better at altitude than GPS in general and seems to be prioritized on the device. But the docs say:

Elevation is derived from the most accurate source: Barometer or GPS in order of descending accuracy. If no GPS is present, then barometer readings will be used.

Finally: is there any way in CIQ to know what method the device is using for speed or elevation?

Former Member over 6 years ago

I've been doing some checking and from what I've heard, there's no way for CIQ to know what method the device is using for speed or elevation. CIQ is using whatever the system says is the best source, the best speed or the best altitude. I've put in a ticket to see if an update to research if API docs is needed (Tag: Weretech-6216).

Thanks,
Kamau

jim_m_58 over 6 years ago

Kamau, there's a number of things like this, including HR (Ohr vs a belt), cadence (watch vs footpod), heading (compass vs GPS, and this one is tricky as it changes based on speed - standing still it's the compass but at a certain speed, GPS if available))

Former Member over 6 years ago

Hi Jim, yeah, there will be others at large but hopefully with some small changes we can get some better clarity on the data we are getting. In this case I think we are getting GPS Data calibrated by footpod or accelerometer first and I think we are getting barometric altimeter data (calibrated by GPS) first. Let me start with these two and see if we can get an improvement, I could be wrong but it's worth a shot.

DaveBrillhart over 6 years ago

Hi Jim, yeah, there will be others at large but hopefully with some small changes we can get some better clarity on the data we are getting. In this case I think we are getting GPS Data calibrated by footpod or accelerometer first and I think we are getting barometric altimeter data (calibrated by GPS) first. Let me start with these two and see if we can get an improvement, I could be wrong but it's worth a shot.

Thank you Kamau. If you are suggesting that possibly a future API release will include insights into the current source of metrics, that would be fantastic.

One other related metric that many of us wish was exposed is gradient. I know this is a calculated metric the device figures out from a variety of sources, possibly GPS, barometer, 3D speed, distance traveled over time, etc. But we CIQ developers have to create sophisticated algorithms to determine the current grade, by smoothing the noise by accumulating values from over time (but not too much time or we can't capture higher frequency slope changes). Surely it would be extremely easy for the Activity.Info structure to simply add ".gradient" to the set of metrics exposed?

Former Member over 6 years ago

Thanks Dave we'll take a look at it. Put in a new ticket for gradient (Tag: Weretech-6228).

Former Member over 6 years ago

HI Dave, the documentation was reviewed and is correct for Speed and Altitude as they relate to the Position module.

Thanks,
Kamau

ekutter-dnu over 6 years ago

Ideally, at least with some of these, we'd be able to get access to multiple values. Like elevation. It would be really good to be able to get both the GPS and barometric elevation values as they are more accurate in different situations. When you summit a mountain, GPS elevation is almost always more accurate, especially if you have just ascended a couple thousand feet. In trees and canyons, clearly BP elevation is more accurate. Having access to the multiple values would open up CIQ developers to provide creative solutions to some of these problems.

I really like on the Epix how you can have a data field for each GPS and BP elevation shown in a normal activity. No way to do this in CIQ.

Similarly I can imagine the same type of thing with speed and distance from footpods vs GPS. I have data field that will compare just this but it means I have to read the Ant+ footpod channel my self and then you can't have it paired as a standard device.

Heart rate would clearly have some advantages here as well. Being able to show both HR values from the built in Optical sensor and a chest strap would be useful. There any many cases where the Optical HR sensor on the wrist just doesn't give me decent data. But there are other times in dry conditions, zooming down a long descent, where the chest strap doesn't work.

I can understand not wanting to give end users too much data, but giving CIQ developers more tools to develop creative apps would unleash things we can't even think of right now. That's how the various smart phone app stores have become so successful.

DaveBrillhart over 6 years ago

HI Dave, the documentation was reviewed and is correct for Speed and Altitude as they relate to the Position module.

Thanks,
Kamau

Interesting. Maybe there are more than one module then? Because I *know* for sure that when I use a Speed Sensor on my MTB it always records more accurate distance/speed than without it, and as compared to friends who only use GPS. And the speed sensor takes priority for the native device data fields. But the CIQ documentation says that GPS has priority.

So does this mean that the native device can choose to make the speed sensor the priority source. But as CIQ developers, we can't and are forced to accept GPS in our apps and widgets and data fields?

Just trying to understand. Thanks!