Better way to drive an auto tachometer

[skimask]

I would use 1 timer/ccp to generate a constant interrupt as a timebase. Inside the isr you can count in order to get your frequencies...

Problem there...is that I'm busy checking/double checking for serial comm's with the OBD. Miss one those and the whole packet is toast. With ISO9141, it takes about 200ms just to get a response from OBD...a lot of wasted time there.
The '683 idea in my last post is working rather well. I only have to get the timing right. Basically, the '683 is acting just like a blinky LED, except it's not blinking an LED. Like I said, just an over-engineered 'divide-by' chip...

[Nicmus]

Hi Skimask,

If I understand your application right you are sending a 0 – 80 mS pulse from your main processor to your 683.
The 683 receives it 9with a 320uS resolution) and, after a little processing, creates a 4X output frequency for your tachometer set up as a MPG display.
So basically you start with a known value in digital format, process it to a 0 – 80 mS pulse, send it out, receive it with a 320 uS resolution, process it some more, output a 4x necessary frequency for the tachometer, divide it by 4 and finally display it.

If we do a little math we are basically dealing with a little over 240 steps of MPG information and a lot of processing taking its toll on accuracy and your main processor timing.

I was wandering if it is not easier to start from your known MPG value (0 – 80 MPG), multiply it by lets say 3 and you will have a value 0 – 240 (this is under 256 so you can treat it as a byte). You can even use a 0 – 80 value if you happy with 1 MPG resolution.

Just use your favorite serial communication module and send it out serially from your main processor to your secondary processor (this should take less than 80 mS even at low baud rates). In return your main processor timing will be more predictable and you preserve accuracy.

You can get really creative on the last 2 steps. I’m only suggesting one way.

On the 683 level process the received byte as your 3xMPG and do what you use to do:
Generate a frequency for the tachometer. You can get creative here also.

The idea is to keep it all in digital without going into the “artificial” digital to analog, analog to digital conversion done with PULSIN, PULSOUT.

BTW: I do not think you should be too concern with the close to zero values. Once you know your idle MPG, you can ignore and zero any readings way under this value (you should use a safety cushion).

Hope this will give new avenues to explore.

Regards,

Nick

[skimask]

If I understand your application right you are sending a 0 – 80 mS pulse from your main processor to your 683.

It's not so much the pulse width as it is the pulse freq, and it's not so much a pulse as it is a 50% duty square wave. I'm using the E-PWM output from the '4685 to drive the OSC on the 12F675 (EC_OSC mode). The '675 only runs thru a loop turning an output on and off with a bit of a pause in between steps, like a really slow blinky LED program, only 23 words of code or something like that. The '675 ends up being a 'divide-by-586' chip.
I do lose a little bit of 'accuracy' at the very top end (rather large steps), and the tach jumps a bit at the very low end, below about 100 rpm as indicated on the tach (which can display 0-8000 rpm) which is actually .1MPG . I don't really need accuracy on the tach as I've got a color LCD displaying all of my raw numbers. The tach idea was just for a quick look solution. The other problem is the friction error caused by the movement in the tach. If I slowly come up to 4000 rpm from under, it reads 3800. If I slowly come down to 4000 rpm from above, it reads 4200 rpm. Common problem I'm sure. It's an old tach I used to use in my old '76 Blazer.

I took it out for a test drive last night. Works like a champ. For grins, I'm going to transfer the program over to a 10F200 and see how much crap I can cram into that.

It's kinda neat...that's all I wanted
Maybe I'll start building boxes that convert tach's into MPG meters.

[Acetronics2]

Hi, Ski

Why not drive your tacho indicator with a stepper motor ???

The idea is not new ... nor mine !!!

Regards
Alain

[skimask]

Hi, Ski
Why not drive your tacho indicator with a stepper motor ???
The idea is not new ... nor mine !!!
Regards
Alain

Because that might involve soldering and hand tools! Do you really want me anywhere near a soldering iron? Much less hand tools!

[Acetronics2]

Hi, Ski

The mechanical solution is the old jeweller's ...

place your mechanism on a blotting paper with some paraffin oil ( for miner's lamps ) under.

vapours ( do not dip into oil !!! ) will slowly clean and lubricate all moving parts.


Old trick to clean your mechanical watches ...

Alain