Overview of the Tachometer PICAXE code

Home Geting Started How it Works Code Overview Program Flow Timing Diagram Photos Original Files Connection Notes SRF Videos 

By:  Jeremy Leach

Introduction

    The following gives an overview of the code used in the Tachometer. It has been carefully designed and employs the use of Timer1 routines  - which is only possible because of the Happy Hippy's investigations and discussion on the PICAXE Forum.

    The measurement of RPM is achieved by measuring the interval between ignition pulses. The Pulsin  command is used to measure the pulse-width of a signal from a flip-flop. The width of the pulses is the ignition pulse interval.

    There are different ways of measuring RPM, but the use of Pulsin seems the best for engine RPM's. An alternative would be to use the Count command, but because the frequency of incoming pulses isn't that high, it would be necessary to count over a long period to get any accuracy, but that would also mean a very unresponsive tachometer !  Using Interrupts for lower RPM's is also a possibility but then there would be issues at higher RPM's. Considering all factors it seems Pulsin gives a high resolution result, albeit with some tricky issues that need to be addressed.

 

Considerations

    So, using Pulsin, it seems that it's just a case of repeatedly performing a Pulsin measurement then displaying the value. This is essentially what we do, however there are some considerations to take into account:

 1. Moving average

    A real-life engine's RPM will fluctuate, so to smooth the displayed readings we display a Moving average RPM value, not the actual RPM value. We store 6 readings and take the readings at regular intervals (SampleInterval). To achieve a regular sample interval, we use Timer1 routines that allow us to precisely measure elapsed time of executing code.  The Sample Interval has got to be relatively small to make the Moving Average responsive enough.

    In an ideal world we would always have a rock-solid Sampling Interval, and never miss any samples. Unfortunately this isn't possible to achieve. While the code is updating the display it can't take a sample. It takes approximately 100ms to update the display, so this is a regular pause in the samples being taken. The only way to address this issue would be to have a second PICAXE that runs the display routine in parallel to samples being taken.

    Also, because the execution time of the Pulsin varies wildly depending on the RPM, at lower RPMs the Sample Interval gets extended.

    However despite these limitations, they don't stop the code from being effective at  calculating a totally satisfactory  moving average !

 2. Display Refresh

    Because the execution time of the Pulsin depends on the RPM,  if we just read the Pulsewidth then calculated and displayed the RPM, the display refresh rate would be much higher at higher RPM's. Ideally we want a fixed refresh rate regardless of the RPM. We decided that we wanted a refresh rate of around 4 times a second, because it needs to be responsive when used in a real-life car. 

    It isn't actually possible to always keep this refresh rate at all RPM's. Below about 400 RPM the execution time for the Pulsin command gets so long that it begins to slow the refresh rate down. However we don't think this is important in normal use.

    As well as using Timer1 routines, the display code also has a prediction built in, to try to ensure a regular Display refresh rate at intermediate RPM's (300 to 900 RPM).