Better way to drive an auto tachometer

[skimask]

The project as it stands...
I built an OBD reader, calculates everything I want, fuel usage, fuel mileage, etc. In addition to the LCDs, I've added a 'standard' 8 cylinder tachometer (one of the big 5 inch ones) to display MPG instead of RPM by feeding it 12v pulses.

Since the main body of my OBD reader is based an 18F4685 and it's too busy talking to the OBD port and doing calculations, etc., I set up the firmware to output a 0-80ms pulse once in awhile which represents fuel mileage (0-80MPG, as displayed on the tach, 0-8000rpm). I'm doing this the easy way with an 80ms PULSOUT to a 2nd PIC12F683.

I run the PIC12F683 off the internal clock set to 125khz (don't really need accuracy). The firmware in the '683 does a PULSIN on the signal coming in (with a resolution of 320us), does a bit of math and scales that number to convert it to a value to be fed into the PR2 register.

I use the '683s PWM module prescaled by 16 to generate a 50% duty output at between 7.x - 1953Hz and I feed this signal into a 74LS74 set up like a divide-by-4, which gives me an 'RPM' output of between 26-7373 ( <1hz - ~488hz) rpm as displayed on the tach, almost, but not quite full scale, and it gives me the resolution/accuracy I need for a quick look. If I want accuracy, I'll look at the LCD output.

There has to be a better way to trick one or more of the timers/ccp modules on the '4685 into generating a 50% (doesn't have to be 50%, but it seems to be optimal) square between 1-533.3Hz (I'll get my 0hz by just turning it off).

(Side note...I was using a pair of Xicor digital pots controlled by the '4685 connected to a 555 to generate my variable freq signal, but the lookup tables to linearize the output turned out to be too big of a hassle and I never could get it to read the same from day to day anyways, crappy cap's, old 555, I don't know. Anybody following this?)

[skimask]

Jeeze...figure I would've have thought of this before...
The PWM (which I'm using as a variable frequency generator) on the 18F4685 @ 40Mhz will go down to ~2441Hz, I need it to go all the way down to zero or as close as I can get it, and go up to about 533Hz.
I take that PWM output from the '4685 and use it as the clock for an external 12F683. Very simple firmware in the '683, increment a counter and toggle an output pin at a fractional rate.
So, basically I end up with an over-engineered, over-thought, overly complicated, 'divide-by-2441' counter.

[BigWumpus]

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...

[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