Tacho output using TIM08

[Bloodhound]

Hi all,

Just after some ideas on the best way to approach generating a pulse signal from the Timer that could be fed into something like an Automotive Tacho to display RPM.

Just loading the Timer in OC mode with values would work fine, but I can't seem to figure the maths behind setting up the Timer prescalers (from 8MHz XTAL) to get the right range of pulse times.

Below is some examples of RPM values for an 8 cylinder 4 stroke (hope I got them correct!).

100 RPM =   400 Pulses /60 for 6.666Hz  (150 mSec)
1000 RPM =  4000 Pulses/60  for 66.66Hz  (15.000 mSec)
1001 RPM =  4004 Pulses/60 for 66.73Hz  (14.985 mSec)
10000 RPM = 40000 Pulses/60 for 666.6Hz  (1.5 mSec)
10001 RPM = 40004 Pulses/60 for 666.73Hz (1.49985 mSec)

Anyone got any suggestions please?

Thanks,

Ross

[Ake]

Hi,

A couple of years ago I wrote a paper that was supposed to become an app note, but it never did.

It is about how to use a HC908 to behave as an RPM.

Instead of counting the number of of clock pulses between two tacho pulses, the number of tacho pulses are counted for a certain time limit.

The code is written in assembly language for the HC908QT4.

The max counts/s was 320 000.

I guess it would be fairly simple to write it in C for the 9S08 and get even better performance out of it.

I have not got the source manual however, so you will have to interpret the assembly language.

Regards,

Ake

[peg]

Hi Ross,

First the toggle points will be half the periods quoted.

Assume 4MHz buss
use /8 prescaler = 500kHz
2us resolution.
10,000rpm is 375counts/toggle
100rpm is 37500counts/toggle
Given the inherent limitations of the internal combustion engine, you can achieve this in one range, with possibly sufficient resolution.

[bigmac]

Hello Ross,

What is the nature of the tachometer signal you are attempting to simulate?  Is it a square wave, or thereabouts, as Peg has assumed, or something with a much shorter pulse duration?  If the latter, to simulate a 100RPM signal would require a prescaler division of 16, rather than 8 (for 4MHz bus frequency).  This would further reduce the available resolution at higher rates, if using a single prescale value.

To achieve sufficient resolution at the upper rev limit (assuming 9999RPM), the prescaler division will need to be 1, or if more resolution is needed, a higher bus frequency used.  With this prescale value, the minimum RPM that can be simulated will be something like 900RPM (depending on pulse duty).  With 4MHz bus frequency, the resolution at the upper limit, as follows -

Pulse repetition:  Equivalent RPM:

1500.25 us                        9998.3

1500.50 us                        9996.7

You will need to increase the prescale value for low simulation frequencies.

I assume you would "dial up" the required RPM value.  Within the output compare ISR, you will need to calculate the next required output compare setting, based on a 16-bit  "increment" value.  This increment value would be derived from the required RPM setting.  The calculation will involve more lengthy multiplication and division operations (presumably fixed point integer rather than floating point), so should be done outside of the ISR.

Regards,

Mac

[Bloodhound]

Thanks for the replies, I'll read your reply a couple more times to get my head around it bigmac

The actual application is for a friend of mine who does some engine dyno work in he's shop, one of the OEM controllers they have to run has no Tacho output at all, however, the engine RPM is broadcast over the CAN bus at about a 80 times per second.

The scaling of the CAN message RPM data is X / 4 , so for a Hex value of $1F40, div by 4 = $7D0, or 2000RPM.

We then want to generate a pulse output to feed in to a normal Tacho (just like you would buy at an Auto store) to display the RPM. I might be wrong, but it's probably not critical on the number of pulses the HC08 outputs for a given cylinder count, the Tacho can select all sorts from 2 - 12 cylinders, as long as it can convert the CAN RPM value into an RPM pulse output that can be matched to anything in between 2 - 12cylinders.

The RPM range only needs to span from approx 400 - 8000 RPM.

Cheers,
Ross 

Message Edited by Bloodhound on 2007-12-11 01:38 PM

Message Edited by Bloodhound on 2007-12-11 01:39 PM

[peg]

Hi Ross,

It all really depends on the sort of signal the tacho you propose to use wants to see.
Mac is thinking (i believe) of the old style aftermarket tachos that use inductive pickups on the coil, or from the points or something and perhaps you need to simulate this very low duty cycle signal in order for it to work properly.
I was giving the simplistic case where the tacho would work from a 50% duty cycle frequency.
It is slightly more difficult to "manufacture" the low duty cycle signal than a 50% duty cycle one.
So it really comes down to what your tacho (or tacho input) will accept.

[Bloodhound]

The generated pulse output needs to simulate a points type signal. Now having said that, I don't mean a great big inductive spike because most aftermarket Tachos (like Autometer etc) accept a 0 - 12V square wave input as a trigger.

So PWM is not the signal I need here, it needs to be a frequency change with a 50% duty cycle.

Cheers
Ross

[Bloodhound]

Would it be a dumb idea to use a table lookup of timer reload values based on the CAN RPM value? Doing this saves the maths part in converting the CAN RPM value to a timer reload value to get a specific frequency.

On something like a 68332 this would work because of the table lookup and interpolate command would 'smooth' out the values between table values, but I can't see the HC08 doesn't have any fancy table interpolation commnds

Cheers,
Ross

[peg]

Hi,

That idea changes from dumb to clever depending on:
Algorithm complexity.
Available memory for table.
Available CPU time to do algorithm.
Laziness of programmer.
etc.

[bigmac]

Hello,

If you wish to achieve resolution of one RPM, using a simple look-up table method, the size of the table will be of the order of  7600 16-bit values.  Using a lookup table, plus linear interpolation method will reduce the size of the table, but add to the calculation complexity.  I would probably still tend to opt for the direct fixed point calculation method as overall likely to be most efficient.  If you code in C, the coding should not be too onerous.

Is it necessary for the RPM value to be displayed on an analogue meter?  A simpler alternative might be to simply display the input value directly to a digital or alphanumeric display of some type, or a combination digital display plus bar graph.

Regards,

Mac

[bigmac]

Hello Ross,

Yet another thought - is it possible to modify the normal tacho, to bypass its frequency-to-voltage circuitry, and gain direct access to the meter movement?  If so, you might simply convert the incoming speed value directly to an analog voltage, using a PWM channel in a completely standard manner, and then feed the output voltage to the meter, using a suitable scaling arrangement (perhaps a series resistor).

Regards,

Mac

[Bloodhound]

Well, what I ended up doing was the easier (to code), flash space hungry method.

I scaled the CAN Rx'd RPM value so that each 30RPM was one step in a 255 entry sized table.

The table contains the Timer values for the RPM range for each 30 RPM step (easy to populate in Excel).

Then just using H:X (offset by the scaled RPM value) it looks up the table that contains the timer values.

It works, it works fast enough, it only takes 19 lines of code (assembler, no C for me) to look up the table value and load the timer. Then come back out of the INT to get the next CAN message with plenty of time to spare before the next CAN message arrives.

Now if I was tight on space then this is not ideal because the table consumes about $200 bytes, but I was not pushed on space at all, or needing accuracy down to 1 RPM, this is only going to be used as a visual indicator on a Tacho with a needle (like THIS one).

Thanks for all the idea's folks, it's nice to be on a forum with people willing to assist each other rather than bickering.........well, maybe I could start a HC08 v's PIC thread to start that up

Cheers,
Ross