more analog
 

and if you are wondering what tach and dwell circuits might look like:

https://www.gassavers.org/attachment....1&d=1184130175
from: https://www.4qdtec.com/Automob/TachDwell.html

status
 

I'm realizing that this isn't quite a comprehensive DIY article yet, I'll have to clean it up when I get something working.

Status, instant mpg isn't nearly as good as a short term average, so I'm shying away from the analog/tach dwell approach.

I was going to persue obdII/ISO after assembling a real trivial circuit. BUT the scangauge stopped working on the saturn (AGAIN?!?) so I need a non obd solution for that car as the scangauge is back in the metro.

So currently I'm trying to load up Visual C++ 6.0 on an old win 98 laptop that has a line-in jack and will try and modify some simple windows based oscilloscope source I found to keep track of how long the injectors have been open and how many clicks we've travelled. It may miss a few beats under windows, but it should be close enough (and provide a reasonable platform for keeping other useful apps on, i.e. some maps and whatnot)

i agree, as long as it is accurate.

keep us updated on the progress :):thumbup:

Forgive my ignorance, but would a Basic Stamp be a good platform for a DIY FE gauge? Anyone know about these?

A more hardcore embedded person would do it with a handful of counters and a PIC (i.e. basic stamp) and have a standalone device. But the problem becomes the fact that they have to put more complicated circuts together and purchase a special programmer to load the BASIC (or C++ or assembler or whatever) program onto the chip and learn how to operate the programmer, or someone has to sell chips to the "Do It yourselfers".

I see a lot of utility in having a full fledged computer handy though, play mp3 files, talk to your lan from your driveway, run maps/whatever. All my portable computers can run on 12 volts directly (no accident). I've even got a ramline 510 touchscreen (used to be in a cop car) that needs to find a second life which would be ideal for this. But the ramline is a PITA to develop on (as are embedded chips), which may be my real motivation for this approach :)

Ooh yah, and a with a well positioned display you can plug in a $20 web cam that is pointing backwards and shave off those mirrors :)

LOL!

So back to an OBD solution then, instead of tapping the injector's duty cycle directly?

Too bad for my '93 OBD-1...

This ALDLcable store sells cables using these schematics except it's voltage adaptation uses a cig. lighter, instead of hacking the DTR line (pin 4 of the serial port):

https://winaldl.joby.se/interface.gif

They sell a $10 OBD2-Serial cable:
OBD2-serial cable

They also list a bunch of freeware used to monitor OBD data.

Othe OBD-1 links:

https://cable.invisibill.net (schematics, used on datamaster, freescan, winaldl)

I'm NOT currently planning on doing OBD, it won't help me as my saturn is not happy with OBD MPG attempts, for whatever reason, and I'd like to get something out of my efforts.

I'm planning on the audio approach on a laptop for ease of implementation and more universal application. Any any car with electronic FI should work. One just need a laptop with a Line-In to run the mpg program on and a simple circuit to limit the voltage going in.

1998 geo metro TBI injector pulse analysis:
 

44100/8 bit/mono recording using a diode clamp interface and a 10k resistor on a 133mhz laptop with integral sound card via line in left channel . Car in neutral in driveway. Probe connected to yellow wire between fuel injector resistor and fuel injector.

3 samples, 1 low rpm, 1 accalerating to higher rpm, 1 high rpm. Images stretched horizontally for easier duty cycle visualization/comparison.

https://www.gassavers.org/attachment....1&d=1185002121
steadyish @ ~1200
period 1714 bytes
pulse width 119 bytes
duty cycle 0.0694


https://www.gassavers.org/attachment....1&d=1185002139
just starting to ramp up on the way to 2000rpm in neutral
period 1273 bytes
pulse width 137 bytes
duty cycle 0.1076


https://www.gassavers.org/attachment....1&d=1185002153
steadyish @ ~2000rpm
period 833 bytes
pulse width 73 bytes
duty cycle 0.0876
(duty cycle increased for higher rpm and throttle setting.

sanity checks:
(3 pulses/2 revolutions)*2000 rpm=3000 injector pulses/minute = 50 pulses/second
44100/833 = 52.94 pulses/second. Enh, close enough for a single wave analysis.

accelerating had the largest duty cycle (most time spent squirting fuel)

hi rpm has a proportionally larger duty cycle than low rpm.

833 byte sized samples @ 2000 rpm equates to a potential 99.75% accuracy at 4000rpm

Note: this signal doesn't look very clamped to me, maybe 10k is too much or my diodes fried. Agc is having fun with the signal too.

Here's the actual recording
 

for the above images. It was a raw wav, so I could pipe it through a program for development, but it is here converted to mpeg 3 compression for space considerations. Recorded with windows sound recorder and subsequently compressed with sound recorder.

if you run it in windows media player, set the visualizations to "scope" by:
views->visualizations->bars and waves->scope

OOPS, this is the recording of the wrong channel!! The other side records a bit cleaner. :o I sure hope there isn't this much crosstalk when the other channel is plugged into the VSS.