cadence (runzi like)

[raver2046]

Hello,
recently i found an app that count impacts when you run, and in my advice it's a good idea (i have found this because i have an achile tandinitis ...)

It seems the app count impacts with accelerometer, can you do that ?

thank you by advance

[pace6666]

What you mean by cadence is number of steps / minute ?

[raver2046]

yes number of steps (foot impacts) minute

[nebmo]

I'm sort of working on implementing this... but it's probably gonna take some time before it gets added.
Trying to find a good algorithm for it.

[jonasoreland]

I thought this was only for when having a cadence sensor, e.g like once
available for ANT+
i.e no "algorithm" needed...

Or ? what do you have in mind ?

(btw, i think the nexus5 has a cadence sensor...)

/Jonas

On Tue, Jun 17, 2014 at 8:50 AM, nebmo notifications@github.com wrote:

I'm sort of working on implementing this... but it's probably gonna take
some time before it gets added.
Trying to find a good algorithm for it.

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[nebmo]

You can use the accelerometer and some algorithm to detect steps. The problem is that is kind of hard creating an algorithm that can handle run/walk while wearing the device anywhere on your body.
Easiest would of course be to use the steps sensor in nexus5 but that is unfortunately not an option.
The gyroscope could also be used but it's only available on > 2.3.
I will continue working on it and we'll see if i get it accurate enough to actually put in runnerup..

[jonasoreland]

why is step sensor in nexus5 not an option ?
(or cadence sensors e.g using ANT+)

i think it's a great option.

/Jonas

On Tue, Jun 17, 2014 at 9:01 AM, nebmo notifications@github.com wrote:

You can use the accelerometer and some algorithm to detect steps. The
problem is that is kind of hard creating an algorithm that can handle
run/walk while wearing the device anywhere on your body.
Easiest would of course be to use the steps sensor in nexus5 but that is
unfortunately not an option.
The gyroscope could also be used but it's only available on > 2.3.
I will continue working on it and we'll see if i get it accurate enough to
actually put in runnerup..

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[nebmo]

is it a good idea to implement it if it only works for a fraction of our users?
i dont have ant+ and i dont have nexus5...

[jonasoreland]

BLE only works for fraction of users...or ?
i think it's a good idea to implement if it's a useable feature and doesn't
disturb people not having/using feature.

i think my point is that I doubt that step sensor will be real-life-useable
without HW support...
but maybe i'm wrong...

you not having ant+ and/or nexus5 is ofcourse a bummer...

/Jonas

On Tue, Jun 17, 2014 at 9:16 AM, nebmo notifications@github.com wrote:

is it a good idea to implement it if it only works for a fraction of our
users?
i dont have ant+ and i dont have nexus5...

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[gerhardol]

High end dedicated use sensors, with some success it seems.
Running Cadence and backup distance/speed from accelerometer/gyroscope would be good.
But I am an even smaller fraction of users with an Android smartwatch, where cadence could be good enough. (Runzi just crashes for me, so I cannot say.)
RunnerUp would also need some GUI changes, it is not possible to start workouts without faking the dpi. (Omate True Smart, standard Android but resolution at 240x240@120dpi, screen is 1.56 inch though so dpi is by default fake).

[CharString]

@nebmo it think it would need one hell of an algorithm as there are several locations where people wear their device: stiff to the upper arm, against the hip in a tight, semi-dangling in a backpocket in a short. I guess all have varying characteristics in the resulting accelerometer data. It would be pretty impressive if you pulled it off.

It doesn't replace good ANT+ support, though. Do you expect cyclists to wear their phones strapped to their cranks or legs? What about the ANT+ accurate speedometers, the power meters, altimeters and other ANT+ sensors?

The Wahoo Tickr Run is a ANT+/BLE HRM with an accelerometer in there. Since it's located in the cheststrap, it's strapped to the core of the runner, simplifying the task at hand, to get a running cadence out of the data. I don't know in what form the data is presented via ANT+, but if it's a preprocessed cadence, that would mean less CPU cycles spent by RunnerUp trying to get the same data by precessing the accelerometer-stream from the phone.

Still impressive, if you pull it off though.

[nebmo]

Hi Chris!
I sort of put this feature on hold after realizing that it, like you said, would be almost impossible to get the algorithm correct enough to support all users and while not affecting performance.
Too bad runzi is not open-source because i think that one is fairly accurate.
I used a pretty simple algorithm which for me resulted in about 90% accuracy while both holding in hand or in a pocket. However, sometimes it dropped to 50% and I never figured out why..
Since I have no other equipment but the in-built accelerometer someone else has to do the ant+-integration.

[dhiltonp]

Did you look at implementing a phase-locked loop?
On Aug 12, 2014 5:59 AM, "Niklas Weidemann" notifications@github.com
wrote:

Hi Chris!
I sort of put this feature on hold after realizing that it, like you said,
would be almost impossible to get the algorithm correct enough to support
all users and while not affecting performance.
Too bad runzi is not open-source because i think that one is fairly
accurate.
I used a pretty simple algorithm which for me resulted in about 90%
accuracy while both holding in hand or in a pocket. However, sometimes it
dropped to 50% and I never figured out why..
Since I have no other equipment but the in-built accelerometer someone
else has to do the ant+-integration.

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[nebmo]

You have any good link?
I based my implementation on this paper
http://www.analog.com/static/imported-files/tech_articles/pedometer.pdf

[dhiltonp]

Well, there's a bit to it. PLLs are usually analog circuits that produces a smoothed output frequency; basically, locking an oscillator in time with an input. Internally it is a combination of phase detection+replication:
http://en.wikipedia.org/wiki/Phase-locked_loop#Block_diagram (also contains matlab code for the whole thing)

It's probably better to look for frequency detection algorithms... autocorrelation seems like the ticket:
http://cnx.org/content/m11714/latest/
http://www.instructables.com/id/Reliable-Frequency-Detection-Using-DSP-Techniques/?ALLSTEPS

Here's my code/summary:

// Keep samples for 2 times the longest period you'll want to detect.
//  these samples should probably be filtered; the algorithm you mentioned
//  just averages 4 samples together, creating a basic low-pass filter.
samples[longest_period*2];

// i=0 is a match with itself; it's our "perfect match" score.
perfect_match = 0;
for(i=0; i<longest_period; i++)
  perfect_match += samples[i]*samples[i];  // dot product

best_match = -1;
best_match_period = 0;
for(k=0; k<longest_period; k++)
  this_match = 0;
  // full data: [...|.....|.....|]
  // k = 0, do: [...|....] * [...|....] = a perfect match! (high value)
  // k = 1, do: [...|....] * [..|.....] = low
  // k = 2, do: [...|....] * [.|.....|] = low
  // k = 3, do: [...|....] * [|.....|.] = low
  // k = 4, do: [...|....] * [.....|..] = low
  // k = 5, do: [...|....] * [....|...] = low
  // k = 6, do: [...|....] * [...|....] = high!
  // k = 7, do: [...|....] * [..|.....] = low
  for(i=1; i<longest_period; i++)
    this_match += samples[i+k]*samples[i];
  if(abs(perfect_match-this_match) < abs(perfect_match-best_match)) { // closer match found!
  // this condition is weak, if we have multiple matches in the signal, we don't know 
  //  which it will return. (room for improvement)
  //  tracking the average match, and aborting when a peak has been found...
    best_match = this_match;
    best_match_period = k;
  }
 return best_match_period; // returns the number of samples in the phase.

This could be run independently on the 3 axes, or you could try to find a way to merge the sensors.

It is computationally expensive as written, but there is plenty of room for optimization... once you have a frequency, you can immediately start looking in the ballpark... maybe start at .7*k?

• my code assumes unsigned values - a perfect match is a maximum, not a minimum.

[dhiltonp]

Cadence on bicycles would be a bit more difficult to detect (unless the phone is kept on a leg), but you are typically limited to just a few different gear ratios at a given speed - if you know the speed and the gear, you know what cadence would be required to go that speed.

[RunningCl0ud]

@nebmo
I found https://github.com/aleung/RunningCadence and in the referenced issue above you can see that he is happy to share hes code if it could be of any use in this project. It would be really nice to have that kind of function implemented in RunnerUp. It worked well with TTS.
https://play.google.com/store/apps/details?id=leoliang.runningcadence

[dhiltonp]

I'll take a closer look and compare it to autocorrelation (which I suspect
may be more resilient to how the phone is carried). I should have time to
check out out closer to Christmas.
On Dec 2, 2014 3:08 AM, "RunningCl0ud" notifications@github.com wrote:

@nebmo https://github.com/nebmo
I found https://github.com/aleung/RunningCadence and in the referenced
issue above you can see that he is happy to share hes code if it could be
of any use in this project. It would be really nice to have that kind of
function implemented in RunnerUp. It worked well with TTS.
https://play.google.com/store/apps/details?id=leoliang.runningcadence

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[RunningCl0ud]

👍

[gerhardol]

As time goes by, step sensors get more and more common, in many high-end phones the last years.
Using Step Counter or accelerometer(/gyro) should be configurable, maybe even accelerometer can be better (and anyway used in no-GPS mode?), but step counter is low power.

Anyone that have tested step counter vs accelerometer?
Anyone compared to a separate footpod?

[gerhardol]

Cadence from stepsensor in v1.58
Acceleratometer support could be added too (but that is likely less accurate)

[davidedelvento]

@gerhardol @jonasoreland wasn't the cadence via phone accelerometer already supported in the previous beta?

[gerhardol]

Cadence from stepsensor supported in #490
Included in v1.57 (likely 1.58 when officially released)

[davidedelvento]

@gerhardol It took me a while to sort this out, so let me make it clear for the sake of the casual reader.

• as of now, I'm talking of a version not yet released on the play store, but will be soon

• you can measure cadence in 3 ways:

  • accelerometer in the phone
  • dedicated cadence sensor in the phone
  • external cadence sensor

Only dedicated cadence sensor in the phone are supported at the moment, however there is interest in supporting the others, but no ETA yet.

See also #24 #337 and #433
@davidedelvento