Help improve my classic mini digital speedo - Open source it?


I've been developing a digital speedo for my classic mini for a few years now. I am on major version 3 and have created a full write up on my blog here;

Full project write-up

Short video of it in operation here;

Short Video

I've got it working quite well with a few advanced features. Well advanced for me as a self-taught coder/hacker. It can detect speed using either a GPS module or hall effect VSS. The odometer is written to EEPROM using wear levelling and the hardware can be used to calibrate wheel size. I've also designed and produced my own PCB's for it.

I've had a lot of interest in supplying the speedo conversions as a kit to other car restores who have all contacted me through my website. I am little nervous about supplying a kit in it's current state i.e. hasn't been peer reviewed and my inevitable mistakes removed.

So, is anyone interested in helping improve and develop the project?

Full disclosure: My day job is in IT. I have no formal dev experience so I expect my coding is not elegant whatsoever and will make a professional cringe.



Like this you mean?

Like this you mean?

Similar yes. I'm fairly sure the creator of that commented and offered to help out a little when I first talked about my version back in 2015 on a mini forum. At that point their product hadn't been launched to the public.

As I said in my first post. I created my own that I've been improving over the last 5 years. People have contacted me via my website asking to supply them a kit so they can build their own. They are welcome to buy a ready made one from another supplier.

Hello Luke.

Nice work. I've made two speedos for my car --- one uses Hall Effect input , the other GPS. Both are working well.

I've been looking at your code. Nice work starting from zero experience.

Did you create the Frequency library?

I would aim to use of more procedures. This makes the code more readable and easier to maintain. Just take a block of code that achieves a certain task, put it in a procedure named to match the task and then just call the procedure. This helps "hide" detailed code.

Some variable names could be more meaningful. For instance, "If gpsMode do......" is better than "if (MODE_STATE == HIGH)....".

Plenty of comments is good, but keep em brief. They normally just remind the programmer what's going on, rather than explain the rationale. The rationale is better managed in separate documentation.

Is your code intended to be modified by the user?

I've got other thoughts but will keep exploring your code for now.


Hi John

Thank you for taking the time to read my code and reply. Some useful guidance as well that I will try to incorporate.

I haven't written any of the libraries so full credit due to the authors. The code has evolved over a few years as I've added complexity to the physical speedo and as I've learnt better ways to do things or tried out different libraries.

Perhaps my biggest challenge to overcome is making the needle update smoother. Minor fluctuations are fine. The needle "twitches" and responds quickly. Sudden drops in speed cause the needle to move in a jittering, delayed manor. I am guessing it's either the amount of code being processed causing a delay to run and update the needle position code or its an issue with my method of sampling the speed input smoothly or fast enough.

I hope that makes sense.


I’ve had a lot of interest in supplying the speedo conversions as a kit to other car restores who have all contacted me through my website. I am little nervous about supplying a kit in it’s current state i.e. hasn’t been peer reviewed and my inevitable mistakes removed.

My cousin and a friend both make a living supplying electronic kits for their respective interests. I suggest you start supplying them as kits and see what happens. If one comes back with a problem learn from it and fix the problem, then send the guy a modified one and maybe a box of chocolates for pointing out the problem.

Good luck.

Hi Luke.

I doubt the time to execute the code is causing any delays in updating the needle. The Nano will execute one loop far faster than the data is coming in from the GPS or HE sensor.

If the jerkiness is happening when you are in GPS mode, it is likely the speed reading from the GPS is itself jumping around. This happens. Even when stopped, mine can suddenly go to some non-zero value, even quite large values. I think spurious speed readings are an inherent characteristic of GPS. So, if this matters, some filtering out of non-sensible values is required or a rolling average.

The experts say hardware serial (pins 0&1) is superior to software serial. I connect the GPS to pins 0&1 on the Nano.

Checking that the number of sats being seen does not tell you that you have a fix. There is a field in one of the NMEA sentences that indicates if the positional data is valid or invalid. This can be accessed by TinyGPS's custom field function.


Interesting Project. I've built 2 totally different spedometers in my life. The first one used the ignition coil pulses and a gear shift decoder. Once calibrated it worked fantasticly well for 10 years until the car was sold. The more likely Construction today would be the "Hall sensor approach" You tell about.

The second speedometer was built some 3 years ago and uses GPS, a NEO-6M GPS. The purpose was to use it as a master to calibrate old, unreliable speed indicators in museum-, veteran-, railroad vehicles. It works well during the right circumstances. Its greatest weakness is when the meter is surrounded by trees, especially whet trees. Then the indicated drops to half or less, garbage values.

I would recommend the Hall effect method using the speed wire rotation. To Your idea that calls for mechanical interfaces to a veriaty of different mechanical interfaces I guess.


I communicate with my speedo devices from an Android app on my phone. Below is an image of the app screen. The screen displays data sent from the device and can send control commands to the device to change parameters in the sketch. All that's required on the device is an HC-05 Bluetooth module connected to a software serial port on the Nano.