getActivityInfo Current Speed Filtering

I'm using the following function to get the current speed.

function getCurrentSpeed() {

        var info = Activity.getActivityInfo();

        return info.currentSpeed;

    }

When the Activity is setup like below:

_activity = Recording.createSession({

            :sport => Recording.SPORT_CYCLING,

            :subSport => Recording.SUB_SPORT_GENERIC,

            :name => "515"

        });

The returned speed value appears to have almost no filtering. It responds to a change in speed very quickly but it's also very noisy.

When the Activity is setup as a running activity like:

_activity = Recording.createSession({

            :sport => Recording.SPORT_RUNNING,

            :subSport => Recording.SUB_SPORT_GENERIC,

            :name => "515"

        });

The returned speed value appears to be smoothed for 30 - 60 seconds.

Is this the intended behavior? Can the smoothing be adjusted?

For my application, the 30-60 seconds is too slow of a response. I don't want to use the CYCLING sport type because then it doesn't record running cadence from the watch accelerometer. What are my options for getting at a less filtered speed value from the GPS?

Nikeow over 9 years ago

for the currentspeed value - I personally don't see a difference between then 2 diff sessions.
But - they may be diff behaviour between a full blown app vs a datafield app.

I've not tried a full blown app using cycling but I have one with running and does not appear smoothed u less I put in a 10sec moving average.

MoxyRoger over 9 years ago

The difference in filtering also exists even if I use the following code to get the speed value.

function onPosition(info) {

        // do nothing

		var posnInfo = info;

		if (posnInfo.speed != null) {

        	gpsSpeed = posnInfo.speed;

        }

    }

This video shows the difference. The only change between the two versions is that the activity type was CYCLING in one case and RUNNING in the other case.

https://youtu.be/u_5jvrBJqeo

The running pace is too sluggish for my application but I want to capture the running cadence.

Nikeow over 9 years ago

https://forums.garmin.com/showthread.php?311442-Pace-averaging-over-loong-time-total-disaster

Could this be hardware related?
Do you have another watch to test the code on? Or if u want, I can test it provided u provide the prog. (I can write / change my own. But I'm lazy)

MoxyRoger over 9 years ago

https://forums.garmin.com/showthread.php?311442-Pace-averaging-over-loong-time-total-disaster

Could this be hardware related?
Do you have another watch to test the code on? Or if u want, I can test it provided u provide the prog. (I can write / change my own. But I'm lazy)

This does appear to be the same issue.

I was on firmware 2.9 on my VA so I upgraded to 3.1 to see if that would help. It did seem to make an improvement in the response when starting or stopping, but there is still a huge time lag to changes in pace when using a running activity type compared to a cycling activity type. It takes at least 1 minute to respond to a change in speed.

Here's a video that shows the response to a step change in speed. The cycling activity responds like I would expect.

https://youtu.be/Z59p98FtqVY

1) Is this the expected behavior from this code when using a RUNNING activity type?

var info = Activity.getActivityInfo();

        return info.currentSpeed;

2) How can I get an unsmoothed speed values like I do in the cycling activity and still get the running cadence data?

MoxyRoger over 9 years ago

Can someone from Garmin comment on this?

Is this a Bug or a feature? If it's a feature, is there a way to get unsmoothed data?

I posted on the thread that Nikeow mentioned and haven't heard back there either.

Thanks!!

MoxyRoger over 9 years ago

I'd really like to hear back from Garmin on this one. Can we get someone to take a look at this?

I did some more testing to help find the root of the problem.

I setup a VivoActive and an Epix with an app that writes the Speed Data to the debug file using println. (I couldn't just use the fit file because the VA only has smart update rate)

The following line of code wrote the data to the text file every second. (I subtracted the big number off of the time to keep the text file from going over 5K in size)

var junk = Time.now().value() - 1438897481;

Sys.println(junk + ", " + info.currentSpeed.format("%0.2f"));

I also setup IpBike on my phone to read out speed from the speed and cadence sensor on my bike. This has almost immediate response to changes in speed.

Then I started from rest, then pedaled at a slow speed, suddenly switched to a fast speed, suddenly switched back to slow, then stopped. I maintained steady speed based on the readout from IpBike.

The following 2 graphs show the difference between the Running And Cycling Activities. Both the VivoActive and the Epix look filtered on Running, but they use considerably different algorithms. The cycling GPS speed data matches the Spd/Cad data with apparently very little filtering.

Then I setup SimulANT to simulate a foot pod speed and simulate the Bike Spd/Cad sensor and I ran the same test. The following graph shows the results. The time lag between the watches and the IpBike is due to the time it took me to switch the speeds on both the footpod and the Spd/Cad simulators. It looks like there is no filtering on speed when a footpod is used. This is that graph.

So in summary, this is what we see:

Running Activity with GPS Speed
- VivoActive - About a 1 minute rolling average filter (it looks a little higher order than that)
- Epix - About a 1 minute rolling average filter with some kind of reset detection after 15 seconds

Cycling Activity with GPS Speed
- VivoActive - No Filtering
- Epix - No Filtering

Running Activity with FootPod Speed
- VivoActive - No Filtering
- Epix - No Filtering

I would prefer to have a No Filtering Option for all cases. That will make it easiest to produce a consistent user experience across multiple watches and when I have no control over whether they use FootPod or GPS for speed input (I could prevent footpod, but that's not a good solution).

If this is the way that the .currentSpeed is intended to function, then how can I make an app that guides the user through a running graded exercise test (e.g. run 8:00 minute pace for 5 minutes and then 7:30 and then 7:00) and also record running cadence??? The cycling work around doesn't pick up running cadence and it makes the activities show up as Cycling activities in Garmin Connect.

Former Member over 9 years ago

Roger,

I've done a little digging into the issue you've reported (I apologize for the delay). The SPORT_CYCLING session mode is indeed unfiltered on both the Epix and vivoactive, and SPORT_RUNNING is designed to be filtered to generate a stable running pace (removing as much noise as possible). It does appear that the filtering on the vivoactive has a significant delay based on your test results (thank you for sharing the details), and doesn't match what we'd expect. I've discussed this with the vivoactive device team and they will be looking into the SPORT_RUNNING smoothing algorithm and increasing its responsiveness; it won't be zero like SPORT_CYCLING, but should be more like your Epix test results.

Please stay tuned for updates (I'll link this thread into the internal ticket I filed).

MoxyRoger over 9 years ago

Hi Jason,

Thanks for the reply.

The critical need for my application is to have speed values that respond in about 5 seconds (10 at most) AND get Running Cadence data.

Is there some way to work around the current limitations?

Roger

Former Member over 9 years ago

Roger,

I don't think there's a way to work around this given the current software configuration. In the short-term the vivoactive will likely get response times similar to Epix, but not faster than that. An alternative to get closer need now is using a foot pod paired with the vivoactive. This should give you better data with the current software and will still be more accurate than the resulting vivoactive filter change.

Boris-oOo over 9 years ago

Hi Jason,
Thank you for explanation. I have posted same issue in Vivoactive part of forum (link is above), but nobody from Garmin responded there.

I hope you can agree this is big issue for runners, and I am happy to learn it will be addressed and looking forward to be able to use running activity instead cycling for running. From pictures above Epix has 15 seconds delay, which also seems too much. 5 s is in my opinion maximum acceptable delay. I hope VA developers would take shorter time into consideration.

You can make default datafields that would average data over 15 s, just leave CIQ developers option to use real time data in custom datafields in running activity! Please ;).