non-obd tach solution

**Chuzuki** · 06-13-2007, 10:41 PM

Hi, I'm new to this site, but I've done plenty of searching the forums and I couldn't seem to find the answer I was looking for. OBD connectors are expensive, somewhere in the $100 range, and after that I'd have to hope the software was open source because I didn't care for any of the gauges I found. A serial input to count the tach signal pulses per second seemed like a great idea, then I could code my own gauges from scratch, but I don't know how to count those pulses and apparently no one else does on the internet either.

Just as I was about to give up and leave my tachometerless standard transmission Cavalier with no carputer and no digital gauges, I came up with a great solution that will most likely be free, and ridiculously easy to do. OpenGL is my preferred graphics language, and one of the first things I learned to do was mouse click detection for programming video games. So what's easier than replacing a mouse button with a transistor, with the tach signal being the switch? That leaves me with all kinds of neat graphics options, along with an excellent frequency counter. I suppose it could also be used for anything else that has a pulsed signal, possibly speedometer or something.

Anyways, this may be one of those "duh, that's super obvious" moments, but I couldn't find a suitable solution anywhere else and I thought I'd share.

Great site by the way, plenty of ideas to keep me out of trouble.

**bibaja_llc** · 06-14-2007, 02:02 AM

I think the pulse rate of the tach signal is higher than the mouse button can take. The mouse is designed to take human-speed clicking.

You may wish to check out the fusion brain, a product developed here by some forum members. It's a long thread, but somewhere in there they may say if the fusion brain can accept pulse inputs such as the tach. Plus they have open source software so you can interface it with your OpenGL gauges.

If that one can't do it, then there are several other products out on the market that can accept pulse inputs and store up a count. Several are USB based, others are serial based.

I like your thinking, though. Using what you have readily available. Very clever! Find out what the maximum number of clicks per second a mouse can take and check it against your tach's maximum pulses per second.

Mark Stubbs
http://www.bibaja.com

**Chuzuki** · 06-14-2007, 03:16 PM

I would assume my tach signal would be one pulse per spark, or two per revolution on a 4cyl engine. This would mean at a redline of around 6000rpm, that's only 100Hz or 200 tach pulses per second. Seems a little high, but probably not unreasonable. I believe my mouse has a 500Hz report rate, although that could be just for position. Anyways, I'm at work at the moment, I'll check out this Fusion Brain thing when I get home.

**greenman100** · 06-14-2007, 08:08 PM

Fusion brain tops out at about 50Hz as of now, and you need a sampling frequency several times higher than the signal source

**davesaudio2** · 06-15-2007, 11:10 PM

measure the frequency of pulses using a sound card

**Chuzuki** · 06-17-2007, 02:51 AM

Originally Posted by davesaudio2

measure the frequency of pulses using a sound card

Amazing idea! I still don't know how to code for that, but it should be much easier to find than com port I/O. Anyways, how would I go about doing that? I'd be concerned hooking it up to the Line In because its amplitude might be too high and fry something...

**davesaudio2** · 06-17-2007, 09:02 PM

must be lots of open source o'scope/frequency meter code to use as examples...
-would assume the tach output is logic levels but when in doubt put a large ceramic cap and a 10k in series, then a pair of antiparallel diodes across the input.

if the above didn't make sense don't try it without knowledgeable help

insert the usual disclaimer about blowing stuff up, killing yourself, its your own damn fault etc

**bibaja_llc** · 06-17-2007, 09:50 PM

Downside of doing it using DSP through the audio input is processor utilization. It will require recording from the audio input continuously and processing the data in chunks. Plus you don't want to miss any pulses, so you will need ping-pong buffers or a fifo to transfer the data chunks from the audio input to your processing algorithm. Can get fairly complex fairly quickly.

On the plus side, it requires minimal signal conditioning/protection circuitry on the outside as davesaudio mentioned.

Another option is a commercial product, like a LabJack. I was just googling for something and LabJack has a $99 USB input that includes counter inputs. Simple conditioning on the tach to the counter input of a LabJack and you'll have what you are looking for with low chance of missing any pulses (between reads of the labjack, the count will accumulate in the LabJack device).

Plus you will have all kinds of spare inputs and outputs to use for other purposes.. temperature monitoring, etc.

Looks like they have some good example code on their website to help make integration into your OpenGL stuff simpler.

Mark Stubbs
http://www.bibaja.com

**Mechanic** · 06-21-2007, 04:17 PM

There is a simple and inexpensive solution. It uses your sound cards microphone input through an easy to make inductive pickup. Software and instruction is available from here. Its actually used as a dyno for performance tuning, but it will certainly give you a fairly precise tach readout as well. Should be fairly simple for a skilled programmer to convert the output into a nice gauge display.

**CraziFuzzy** · 07-05-2007, 12:20 PM

How accurate do you really need a tach to be? I'm thinking a simpler solution would using the pulse to charge a draining cap, which will result in an analog signal. This analog signal will not be linear, but could be brought into something like the fusion brain's (mentioned above) analog input jack, and linearized/ranged in software. A couple calibration points for low, mid, and high, and it would be fully functional, and certainly accurate enough for driving use.

EDIT: The same principal could be used for bring a speedometer into the computer as well, though possibly harder to calibrate.