Monthly Archives: August 2014

Period vs frequency

In my previous post, I was struggling a bit with accuracy on the acceleration component of the power tracking.

I’d originally been calculating instantaneous roller speed from the period between the last two sensor pulses, but I think this was suffering with a bit of jitter in the measurements. For the next attempt, I started to calculate the speed from the pulse count over a set period.

These frequency based results (based on pulses per second) were somewhat smoother, but in order to remain responsive to speed changes, I needed to make the period shorter. The data in the graph below was generated at 4hz, but still smoothed over 4 samples.


To maintain accuracy, with a reasonable number of pulses per period, I’ve also needed to increase the pulse rate. For the above test, I just stuck another three magnets onto the roller, but have since ordered an optical sensor. This should allow very easy adjustments of the pulse rate, just by printing up new encoder disks.


Until now, I’ve been sending the raw speed data over a serial link to a PC, where it’s saved and then post-processed in a spreadsheet. Next post I’ll cover a new development platform, where I’m able to do the curve fitting and power calculations in real time.


Summer slowdown

In a fairly predictable turn of events, my development efforts pretty much ground to halt over summer. But a recent touch of autumnal chill in the air has shuffled the trainer project a couple of notches back up the todo list..

So, progress since the last post? Not much – just the addition of a micro and hall effect sensor to the prototype for some more accurate speed measurement.


This is presently just dumping a serial datastream to the PC for post-processing, while I wrestle with the maths for the un-braked roller assembly. There is obviously work to do, but the very first attempts at calculating speed & power weren’t entirely terrible.



The trainer power consists of the steady state power derived from a spindown test, plus an estimate for acceleration/deceleration (see shonky graph above).

While the steady state power is tracking pretty well already, it’s fair to say the acceleration component needs some work! I think this is primarily down to a very slack update rate from the initial firmware. I’m only sending speed updates to the PC every second, which is then averaging the acceleration over a 2 second window, so it’s this area that I’m aiming to improve on next..