80% Coded for an MVP and Thoughts

For those of you who are unfamiliar with the term MVP in the context of a startup, it is simply the “Minimum Viable Product”. A minimum viable product is a product that is to enter the market and test a market hypothesis. Things in today’s economies change quickly, very quickly, and because of that Eric Ries recommends that business plans are essentially a terrible idea for a startup. For SRM powermeters were a startup, for Cycleops less so, Quarq even less so. And the rest of us, we are behind the curve in some respects. Everyone’s startup now revolves around something novel about the power meter, but nothing equivalent to the revolutionary effect of a powermeter.
I’m further late to my own party. My original work pre-dated any announcement by ROTOR on their powermeter. They may have concurrently thought about strain gauging the arms as a bending bridge or precluded my own cognitive thoughts on the matter. Suffice to say I was missing some information about strain gauges and I decided to finish a Masters degree (Grad student advice: 2 Years Masters << 2 Years Work Experience initially until you have more years under your belt). However, theirs is not “Low Cost”, in fact people refer to it as SRM territory. Personally I don’t believe that SRM is the “Golden Standard”. They have certainly done a good job making everyone believe that. However, Rotor showed a temperature curve below.

From: http://www.rotorbike.com/products/road/power_198
Two things strike me:

1. There seems to be a slight ripple, but you need much smaller vertical scaling.
• I plan to put mine in an oven and do a measure in the coming weeks and post what I get. I wouldn’t say 100% immune if I can draw a line and see it’s not perfect. More like 99.9%?
2. I’ve never seen this type of graph for anyone else’s meter.

“What am I getting at”, you may be asking yourself. It’s simple. Temperature compensated designs are easier when there are less strain gauges and they are very close to each other. My design is similar to Rotor’s except my gauges are on the outside for the arm (inside for the torque tube). That’s important as it gives rotor an advantage in theory. There can be local effects on my design even though it is thermally compensated. The top of the crank might heat or cool faster than the bottom. This would cause some drift potentially. But on the Rotor design, with the strain gauges being inside the arms which are aluminium (Not Carbon!), means that there is a larger thermal mass to help even out the temperatures before the gauges making it less prone to this effect. The aluminium acts like an insulator in a way.
Back to the MVP. There is a lot of work to be done, and ensuring temperature compensation is critically one more problem in the Last 5%. That last 5% is huge and grows everyday. There is always multiple things left to sort out beyond code and hardware. It’s tweaking that hardware and software bit by bit. That refines a product. But the key to an MVP is to not fret all the little things.
The beta group will tell me a few things

• How does this compare to higher end systems
• Do I need more features for minimum functionality?
• How does non-power meter cyclists, more amateur cyclists, find using a power meter?

I’m giving away something here. I’m not after the SRM market, nor the ROTOR market. I’m after a market that has a HRM, knows a little about power meters but have never experienced them. They would train for a Sprint / Olympic / Half Ironman triathlon or cycle races. They would own bikes in the range of 1200 – 2500 dollars, not 3k+. They’d have a cycle computer, 90%+ would have a HRM and use it.
Oh, and one more thing: I don’t have a clue if there is really a market there.
What will I compromise for this untapped market? Here is a list

• Nothing from operation
• Might not be as pretty as others… initially?

Here is what the MVP will have

• Thermal Compensation (by design and digital backup)
• 1 – 2% accuracy.
• L/R Balance, Basic Power Profile – TE/PS as an update
• Not seeing any advantage to Crank Profile. Added accuracy is not worth it and reduces the L/R balance transmission rate
• Water / splash proof – It can’t die when caught in the rain

My design will match up the 1 – 2%, thermally compensated designs out there
Now to the update on the coding. I’ve been trying to figure out how to make it sound interesting. One lame thing that I’ve been fighting with is how to store variables. Computers work in bytes, but analog to digital convertors work in bits. Mine is 24 bit, but there isn’t a 24 bit container. Computers (and microcontrollers) don’t like 3 bytes! They like 1,2, or 4 for storing integers. While I praise Nordic for all the work they have done with their SDK, I seriously could not be this far porting to a new chip without them and honestly I likely would be a year away from beta instead of the projected three months, but I seriously miss some of the pre-baked Arduino things. Like Serial.print(‘variable’); I’m using Realterm and outputting two ints, putting realterm in a mode to decode int16’s, and getting wacky errors. But after spending 3 evenings at this I blame Realterm. I don’t get these erorrs when I transmit them over ANT+.
I forgot to mention. Basic setup now is a bending beam, I read raw values in, average them, and transmit that raw value as power on the basic profile. Works well. I need to do a few simple things now. Calibration curves, offset sampling, adjust sampling rate, etc.
More ahead.