Two weeks ago while I was up at the ANT+ Symposium outside of Calgary I had a chance to spend some time running around in circles with two guys (Dr. Max Donelan and Mark Snaterse) from Simon Fraser University who developed a pacing and speed control algorithm and system that allows me to pace precisely against a given defined speed…without ever looking at a watch.
The speed control system works through a number of different hardware components that ultimately give you a beeping tone via ear bud that you in turn attempt to match your running cadence to. One beep equals one step. The faster the beeps, the faster you step. Just like matching a metronome. This effectively drives pace. But it’s not quite that simple, as the system has to be able to dictate a specific cadence to impact your pace.
So why would you want to drive pace anyway? Well they’ve found that for the average runner, you are able to maintain a given pace to within an error rate of 10% – which means on a 10K race run at 50 minutes you could be off by as much as 5 minutes – that’s huge! And for collegiate level runners, they found that was only reduced to about 4% error rate.
Of course, you’ve probably read before about benefits around running cadence (turnover) and the general concept that a higher turnover increases the elastic recoil – ultimately increasing efficiency, and and much of that is still applicable here. But in the case of this particular setup – the focus is more on altering cadence to drive pace than it is on maintaining a given high level cadence from an efficiency standpoint.
So how does it work? Well, I should first note that much of what you see here is about showing a concept – one that can then be ported down to a much small form factor, such as your normal GPS running watch. Obviously the system as displayed below isn’t practical for normal use, but that’s really just a case of how it’s currently packaged – there’s nothing stopping it from being put into a watch or iPhone app.
Anyway, onto the pieces. In the case of my test, I was wearing a backpack that had a few components strapped to it. The first is a highly sensitive GPS unit that’s accurate within a few centimeters – yes, centimeters. That’s much different than your average Garmin Forerunner GPS only accurate to within a few meters (on a good day).
That’s connected to stylish blue hat where the GPS receiver is located:
Also inside the backpack is a controller to wirelessly send the data to the laptop (where another person can control my speed remotely from afar) as well as an Arduino control board with an ANT+ chip mounted to it. This ANT+ chip enables them to capture heart rate and footpod cadence data (though the footpod cadence data actually isn’t required, merely just interesting). There’s also a typical SD card too to capture data – though much of it’s streamed real-time to the computer. And finally, attached is a pair of headphones so I can hear the beeping. Long term there may be other ways to either audibly, visually or via vibration allow you to keep on pace – but for now, this works fairly well.
Now, I mentioned a computer. The computer is manned by Mark, though it could just as easily be manned by your coach or someone else choosing to inflict pain on you. That’s because the computer interface allows one to remotely control your actions by changing the speed of the beeps, which in turn drive your pace.
And again, in a practical application – there’s no real need for this computer. This is purely for demonstration purposes. If this were pulled into a watch or app, it would all happen there – based on the settings you defined.
So now that I’ve talked about the pieces, how does it work in practice? Well, when you first start out the application essentially just watches what you’re doing – looking at your pace based on the GPS data. From there you can set a given speed in the application and the unit will change the beeping frequency that the runner hears via the headphones – and continue to change it until the runners speed requirement is met. This could be set at a defined pace for an entire workout/race, or multiple paces/speeds/parameters could be defined – as in a typical complex workout.
Because it’s probably easiest to show this in a short video clip – we selected an unlucky runner to run around in circles while Mark explained what was going on on the screen, and how it worked as he changed the runners speed remotely. All without the runner being audibly told to increase pace, or even what pace he’d be running at. The runner merely matched the beeps to his steps.
Showing off how the Speed Control system works at the ANT+ Symposium
As you can see, from the computer’s standpoint, the goal is to match the green line (your pace) to the white line (set pace). But as a runner, from your standpoint all you hear is beeping. Sometimes you can detect the changes in beeping (major shifts in pace)…but most often not.
Of course, I too had the opportunity to test this out as well – for quite a while actually.
We did a number of different tests, but probably the clearest was around having me snapped to set paces. In one test we had me run at three different paces, each pace for two minutes. I first started off at a 7:30/mile pace, then went down to a 6:30/mile pace, and then finally a 5:30/mile pace. Each time this occurred, the beeping would generally increase in frequency. But it would modulate (vary) based on the GPS pace (using that incredibly sensitive GPS receiver). So if I slowed down just a tiny bit, it would almost imperceptibly change the beeping frequency to get me back on track. In most cases, I wasn’t even aware it was shifting – since the changes were so subtle.
Perhaps the clearest example you can see is the below chart – which was a separate test where I had a set pace prescribed, then had the pace increased to match the computer directed pace, following which the pace was decreased again. The top chart is showing the frequency (cadence) shifts to keep me on target – while the middle chart is showing my actual speed.
What you see above is my almost perfectly consistent real-time pace (green line) compared to the white line (set pace). But in the case of the frequency (cadence) being delivered to me, it’s actually constantly shifting to keep my pace equal. Yet in my mind, I didn’t even notice these shifts.
It’s also worth pointing out that the little course I was on had two sharp 180* radial turns around a tree curb in it every 25 seconds – thus making it even more interesting that I was able to maintain pace despite having to sharply corner constantly.
Now take this a step further and they can ‘lock’ onto other attributes aside from just pace. For example – they can do the same with heart rate. Using ANT+ heart rate straps they can then change your running cadence to drive pace and in turn effort have you lock onto a nearly exact heart rate BPM – such as exactly 156bpm (+/- 1 beat). This is of interest because most folks today who use heart rate to train, do so by heart rate ranges instead of exact numbers – simply because that’s what is practical to pace by using today’s technology. It’s otherwise simply very difficult to adjust your pace to an exact 156bpm heart rate. But with this system, your brain is removed from that equation – instead allowing the computer to effectively control your pace.
In short: Your pace is now being controlled by someone other than you.
So where’s this all going? Well today it’s merely an algorithm – something to ultimately be implemented in other products. Their goal at the ANT+ Symposium was to talk to other companies about integrating it into products. And the interest was certainly there. Out of frame in some of the pictures on the second day was a host of people from different companies lining up to try it out (and run endless circles around a giant parking lot). These companies in turn would have to determine the mechanics and details of implementation. For example – is beeping the right method, or is something else? Should it instead be timed to music that would be digitally manipulated on the fly to in turn adjust your pace?
Lots of questions are still out there around implementation, but the practical side of the technology is clear: It’s remarkably sharp when it comes to keeping you on pace.
From a technology standpoint, these guys have filed all the right patent stuffs for their algorithm (and that’s what this comes down to – an algorithm) – hence why they were open to me showing it publically. If you’d like to learn more, check out their site with more of the work their doing.
Additionally – for the curiosity inclined in the room, Dr. Doneland did a pretty interesting TEDx talk recently on harvesting human energy from activities like running or cycling, to in turn charge devices. So, for all those of you looking to sip that morning coffee a bit more…here ya go:
TEDx talk on human energy harvesting
And finally – last but not least, if you’d like to read more from others on the concept of Speed Control, check out this serious of posts from the Sweat Science blog regarding the Speed Control project and their thoughts on it. This also touches more on cadence and control.
Thanks for reading – and as always, if you’ve got questions, feel free to drop them below – either I’ll attempt to answer them, or the fine folks from SFU can pitch in as well (after all, they’re the smart ones…they managed to avoid running in circles at 5,000ft and instead suckered me into doing such).