Monthly Archives: December 2012

Self Calibrating Potentiometer

Update: Code edited for clarity and make sure you read pbrook‘s comment

So I have a dial connected to an Arduino, a potentiometer (pot), it’s the typical item you might use for volume or brightness control, turning it all the way up to 11. Here’s the problem though, you’re reading in the analogue values of the potentiometer and you think it goes from 0 to 1023, possibly higher if it glitches a bit (though this is dependent on how it is handled in your code).

However, what you’re controlling, only goes from 0 to 10, maybe. What do you do?

Well one idea, is that you convert it to a percentage before making the comparison, I think this is effectively ‘normalising‘ the values – statistically speaking. This is really useful. So in this code I’m doing two things, one is that I am normalising the values but the other is that I am calibrating the values that I am reading.

Why should I be calibrating? Well, this code is then portable (the mathematics could apply to anything similar, as I see it), not only that but if the ‘pot’ needs replacing, then if it is placed in the ‘maximum’ value position for a while, then it’ll be accurate (well enough so).

#include "math.h"

int sensorPin = A0;
int maxVal = 0;
float sensorValue = 0.0f;
float percentile = 0.0f;
float temp = 0.0f;

void setup() {

void loop() {
 sensorValue = analogRead(sensorPin);
 percentile = (sensorValue / maxVal) * 100;
 temp = fmod(percentile,10.0);
 if (temp > 0.5)
     percentile += 0.5;
 if (percentile > 100.4)

The code utilises the C++ Math library, and rounds the value from the pot up (I think, I should probably double check it) using the function ‘fmod‘. If the pot is set at the maximum it is capable of being at, it will increase the ‘maxVal’ variable to work out the correct 100% value to calculate with.

If anyone has feedback or corrections on this, please comment!

Weaponry makes the Perfect Gift

As a member of the Hackspace it crosses a few members minds of how to use the functionality of the space with the opportunity of giving a present to someone.

A long friend of mine is a devout fanatic of the TMNT – collecting nigh everything available and it’s his 30th birthday this year near christmas. So myself and the girlfriend thought, what better than to give him something he cannot buy?

With Jo‘s talents in Fimo and the resources available to me, we decided upon figurines. However, these required weapons. With a bit of resourcefulness, soldering, patience and heavy hitting by myself and pbrook and some laser off-cuts we managed to produce something resembling the TMNT load-out:

TMNT Weapons

They have since been touched up with a bit of paint to cover the initial attempts at soldering the metal pieces together and neaten up the blades from being hammered. The ‘grips’ on the swords may be lightly painted, to retain the look formed by squishing the metal under great pressure by a vice.

I’m quite happy with the result and the ‘chain’ for the nun-chucks, made by braiding wire together.

Update: Here are the finished items:

TMNT Weapons

Source Control

As a small team of two people it may seem a bit over complicated to introduce the practicalities of source control. Or may be what I mean is “revision control“.

I think this is the best time to do it though, because you can learn how it works, how it doesn’t work how you may think and what can go wrong. For example, for the current project we’re both working on an ActionScript v3 project in FlashDevelop, utilising BitBucket. The first stumbling block we happened upon was that, the two don’t directly integrate. It involves the use of at least three to four other applications which, handily, are compacted together into tools such as TortoiseHg and PuTTY – the former contains some hybrid of Mercurial/Git to some extent.

So after discovering that the SourceControl in FlashDevelop doesn’t appear to work beyond ‘Commit’ for the files that have changed (synchronising, especially on the fly doesn’t appear to work from the guides we have found) that having more than one person share the ‘main’ or ‘trunk’ of your project source is just not a good way to go about it:

What a mess

Simply put, partly because I lack the ability to describe what’s going on short of the Wikipedia article on source control, it turns into a mess as shown by what I will call the ‘tree’ (or headed Graph) on the left hand side.

Suffice to say, we’ve decided that to help separate development it may actually be better for us to have a main project which either one or no persons work on it directly, but they ‘fork’ it (effectively making a copy) and then commit and push to their own, with ‘builds’ of files they’ve changed, pushed to the main ‘trunk’ (or main project as I stated) which then means, there’s only merges done that make sense and people can happily mess up their own copy, while re-cloning or pulling from the trunk as required.

It’s taken a bit to get our head around, I try to think of it as a main river splitting off into streams, or a tree trunk into branches (probably the common analogy).