Actually, I was thinking of a tone that peaks when you are accelerating most efficiently. If you give the computer throttle control it might be able to find the most efficient accelerator setting for you (for a given gear).

skewbe -

Ha ha! I was thinking that this would be a perfect 2600 article, and here you are talking in terms of "tones" for your solution.

Most excellent work!!!!! I think you should publish this in https://www.makezine.com

CarloSW2

I got a request to provide a binary, so, just this once. If your signal looks like mine (vss cranked on the left channel, injector upside down and about the same height), it might work out of the box.

you will have to save this Mpg.zip file somewhere then run (trust me?!?)
java -jar Mpg.zip

from a command prompt in that directory, or put a shortcut together, whatever. Google is your friend. If you see error messages, start there, or give yoshi his $170 bucks :)

the power of open source, now you just need a odb/odbII to usb2 for newbies and downloadable exe and your set!

Not obd, not for newbies, not exe. It's for folks who can figure out how to compile a "hello world" program in a given language, who can put a simple circuit together and hook it up to the vss and an injector, and can make sense out of what they are seeing.

I'm not even going to try to compete in the support department with paid for products, this is Do It Yourself land (that means you too) :)

Hypermiling User Interface idea:

I think one of the useful things for hypermiling not done by SG2 that this software could do is compute MPG by speeds.

Here's the idea:

Create buckets of speeds, say:
0MPH, 1~5MPH, 5~40MPH, 40~65MPH, 65~100MPH.

For each bucket, compute
- GPH
- average time spent in that bucket
- distance travelled in that bucket
- MPG (when applicable)

Also compute overall MPG.

Now say you're driving in the city, with some highway.

At first you drive normally, and check your buckets, see time spent in each and what part of your driving contributes to your overall MPG.

Now start using hypermiling techniques that apply to specific buckets.

For example, if you see you spend most time on stop lights (the bucket 0MPH will tell you how much gas it costs you), then you know you must turn of your engine at lights to improve MPG.

If the profile shows it costs little gas though it may seem like a long time while you drive, you know you don't need to risk damaging your starter and look for another solution.

Say you spend your gas in the 5~40MPH buchet. Then you can try to focus on gliding.

If it's at highway speeds, then you can try to use drafting instead, and maybe gliding.

The time spent per bucket can also tell you something as you try different techniques, like gliding causes you to hit more red lights, so you need to be more aggressive.

OK a few other things:

- Do you have PICs of the setup, where you wire-in onto your car for collecting Vss and injector signals?

- For OBD-1, you can buy a scan cable, and you could use it to connect a serial cable, with an open source software AND collect the same info I suspect.

- For OBD-2, the scan cable has to hook up to a device ($) that processes and converts the info into data that can be passed to a USB/serial cable.

re buckets: Sure, you can do that, have a blast :) You will need to program a tiny bit. If you add trips for each bucket and at the bottom of processChunk, look at instant.mph() and call update on the appropriate trip(bucket), that will get you close.

re: pic, don't have one, mine was just a couple sewing pins soldered to the resistors and stuck into the appropriate wires. I do not have a permanent installation yet though am considering it. There is a number of folks that already have computers running linux or windows in their cars, for whatever reason.

re: obd, yah someone posted a whole bunch of obd stuff earlier in this thread. That road has been pretty well travelled, and I'm not going down it myself. This approach is universal to electronic fuel injection vehicles and operating systems, and that is worth something.

Agreed :)

I was just currious where you tapped the info and routed the wires.

It helps to have photos to actually commit to do it yourself. There is a sense of concretization, and understanding that the solution is complete :)

Looking at your "diode clamp" again, I have this to say:

I think:
- VSS trips the diodes (sharp horizontal cutoff)
- Injectors voltage is too low and does not trigger the clamp (no cutoff).

It seems to be a 0.4V swing, comparing to VSS cutoffs.

- R is only to limit current if the diode passes current (aka voltage from 0.6V to 13V). At 10KOhm, that is max 1.3mA draw. I dunno if that is noticed by the car's Vss/injector circuits. Likely not?

could you take a picture of your setup and circuit, so I can then try to replicate

thaks

Is there any way to use this if your computer's only audio input is mono?

Are you sure it is only mono? You could only monitor fuel consumption & time OR distance & time with one channel, so it would be worth double checking with a miniscule amount of experimenting (recording) that it is indeed mono.

If I had to choose, I would choose fuel consumption, since I know how long my commute is, and I have reasonably accurate distance instrumentation in the vehicle already.

This is really awesome, finally some paved ground for a meter on my non-obd car. Can you think of a way that you'd use a serial or parralell port to capture the signals instead? Because I'd like to get more signals then just those two. Namely RPM because then I can show instantaneous HP and TQ and well and log and throw into StreetDyno.

Also one other nice thing that I'll add to this when I get it all working is an automatic crr and cid recording. I'm thinking choose a 'stop' MPH (like 20MPH entered through a text box) and then have a start button. I cruise to 70MPH, hit start and slip into neutral and let the vehicle slow to whatever the 'stop' MPH is. BAM, I know now exactly how long it takes me to slow down different thresholds, in fact instead of just 5 numbers at different speeds I have a full curve! Not exactly sure how to automate something to solve the crr cid equation based on this curve, but I'll certainly figure it out.

Do you think you could sample from the microphone jack AND line in at the same time? That might be easier than serial/parallel.

Actually thinking a bit more I'm pretty stupid to need rpm signal. I can easily get that from the injector pulses! I guess the only difference is that as their duty cycle changes the peaks may start or stop at different times causing a very miniscul shift, but the Hz*2 should be rpm.

In fact if you just had your program ask for the gearing ratios of the transmission and final drive, as well as tire diameter and size, as StreetDyno does, then you wouldn't need VSS either, since you could calculate speed based on RPM. Of course you'd contantly have to tell it which gear you were in on the fly....

Now that you mention it, you should be able to automatically find the gear ratio then with the 2 signals you get then, and when you're not in gear.

sonyhome, maybe a smaller resistor on the injector would give a larger pulse signal (and thus more resolution)? I think the automatic gain control might be kicking in on the VSS and reducing both channels.

itjstagame, Yah RPM is right there, so is accelleration and deceleration, and if you know the cars weight then power can be deduced.

I don't think we care about the ratios. If you have RPM AND VSS they are the ratio when the clutch isn't slipping.

I also don't know how to get windows to let you record from more than one jack. Other ports are possible but I don't have any firm plans for them.


The coastdown tests could be completely automated, sure. The computer will gather a lot more than just 5 points on the curve, it will gather the whole curve from , say, 60mph to 0mph :)


One last note, trying to determine distance from rpm and gear ratios wouldn't work for me, I spend most of my time coasting with the engine off. I really need that vss signal if I want to know how far I've travelled (the 'M' in 'MPG').

Ah, very good point. Yeah, VSS is easier, I was only saying that if you only had a mono jack, just that you could get fairly close with one signal.

For calibration there are a set number of VSS pulses per mile, speed is just the rate of pulses, but I'm calibrating toward the constant number of pulses per mile?

Also how'd you decide how much fuel to attribute to each pulse? Do you have some formula based on the cc of each injector? Becaues obviously 50% pulsewidth isn't an exact amount of fuel, only if you know how much fuel the injector delivers at that 50% pulsewidth. And do most injectors ramp up linearly? ie. 80% pulsewidth used exactly 60% more fuel than 50% pulse width?

Lastly, I can solder and I can follow a diagram, but I'm afraid my electronic skills fail at the basics, so if I'm told I want to output a constant .6V I don't know if that means I need a resistor a transistor a whatever, etc. Can you give me an idea of what kind of diodes you use and what rating (varies based on VSS out signal I'm sure). And it looks like you hook the + audio signal to before the diode bridge but still on the negative (grounded) side of the VSS/injector? Or do you tap in to the + side and use the - only after the diode bridge, also aren't you making the whole ground for that injector pass through that bridge, is that an issue? Can I just use any common ground in the car? This seems it might work for the injector, but the VSS is a stand alone pulse (probably VAC)?

Actually I guess the only other signal that would be nice to have is TPS. Then you can compare throttle position to pulse widths and various loads.

I don't think I like MPG as an indicator, I'd like to see acceleration or maybe energy produced per gallon. I often wonder is accelerating slowly at 12MPG is better than accelerating quickly at 8MPG, etc. Finding the most efficient spot for acceleration coupled with EO P&G should help a lot. I would assume this would be maximum torque rpm, but I wonder how much of an effect throttle position has, especially with today's ecus, even at the max tq rpm, if you're cruising or WOT it's very different, typically different target AFRs and advances. Even building my own ECU I'm not sure 'theoretically' which would be better, lean is for efficiency but more power seems more efficient (unless it's less power/Gal).

Maybe the cruising/leaning is simply to try to help the fact engines aren't as efficient maintaining a steady state load versus accelerating against a load? That's why stuff like dropping out cylinders helps?

Sorry I keep posting, I'm just anxious to get playing with my vehicle and can't at the moment.

I'm lost here, but excited too... what do you have "do" to use this DIY MPG Monitor?

I know a little bit about programming, and my brother knows Java, so that helps.

In fact I have used "WIN ALDL" and an old computer to track the performance when I upgraded to TBI in my car.

There's a couple ways to approach it, but referring to:
https://www.gassavers.org/showthread.php?p=64732

Assuming you can solder/record and view wav files/and understand what the program is doing given the wave forms and thresholds, and how to tweak it to make it work with your car after analyzing the signals:
1. you have to locate a good injector signal and a good vss signal. On my metro it was the yellow injector wire going into the resistor and the yellow and green wire going into the ecu.
2. hook them up to your line-in jack
3. run the program once then exit, locate the mpg.properties file it creates.
4. prepare to record line in in PCM at 44100hz 8 bits 2 channels into wav file
5. drive at a known speed (and rpm), make a guess at what mpg you should be getting, and start recording.
6. park it and save recording.
7. analyze the wave forms, if they look like mine you are done.
7a. If the are on the wrong channel, then you can fix it in the wiring or swap the processing of even and odd bytes in the processChunk method.
7b. If they are the wrong direction, then you will have to change the sign on the threshold in the mpg.properties file and the associated comparisons in processChunk for that channel.
7c. If the signals don't cross the default threshold, or noise is crossing the threshold then adjust the threshold (-128 to 127) in the mpg.properties file and/or fix your signal.

Ok, so if you made it through all that, lets "calibrate" it on the bench using your recording:
1. change defaultFile in mpg.properties to point to your recording.
2. run the program, note the speed and mpg
3. exit the program, adjust fuelfudge and vssfudge in mpg.properties a proportional amount (they are used in the divisor), and save.
4. rerun, note speed and mpg, and go to 3 if more adjusting is necessary, otherwise declare victory :)
5. set defaultFile back to blank and hook the computer back up to your car, enjoy.

Note, I'm considering a more user friendly version of the software, but not a priority for me at the moment. I was going to put this in my metro but the scangauge quit working in the saturn (so it is in the metro) and the saturns driver hasn't warmed up to the idea of having a computer in the car yet. ;)

If a few of you are serious about this and understand what is going on with this cheezy bit of signal processing, PM me and I'll do what I can to help you sort it out.

Here are some pics of my circuit I made. I am not sure if it Is right, but I tried. My wires arent too thin are they? (speaker wires) And I put it in a nice box. I still have to connect it to my laptop and calibrate. (going to connect it to an older computer first, just to make sure, I dont fry my good laptop)

one more question... since my car is a 91 metro 3cyl, similar to your metro skewbe (is it 3cyl ?), I was wondering if I will still have to do all the calibrations etc...

https://i12.tinypic.com/6c7c7pk.jpg

https://img399.imageshack.us/img399/7...0003pz7.th.jpg

https://img399.imageshack.us/img399/1...0005oi3.th.jpg

https://img61.imageshack.us/img61/497...ctormf5.th.jpg

looks right, you might want to use shielded wire to the probes and ground them near where they tap into the signal for less noise.

You might get lucky and not have to calibrate. I'm a little confused on right vs left so you may need to swap those to get it to work right.

skewbe:

I'd love to code the program to make what I think would be a great hypermiling diagnostic tool, I have quite a few ideas on how to present the data usefully. However I need lo learn Java first :). I did look at the graphic libraries, and it's too bad, it seems one has to code the graphic interfaces (for like 2D graphs, gauges etc.) so there's some overhead work to make a cool tool.

I think the config file you have is pretty well thought, it does allow adjusting the tool.

itjstagame :

With this gizmo you could have what you want. It's just a matter of programming.

Caprice:

I think it boils down to this:
- Find Vss and one injector wire
- Solder wires to needles and stick them in to tap those signals.
- At the other end, follow the diagram, aka solder to a 1/4" (?) headphone plug (each wire to center connectors and the diode bridges between those wires and the outside ground connector), and the ground to the car's chassis. Note that there's a resistor there, and it's to make sure you don't just ground the signals with the diodes. When the diodes pass current, it's via the resistor, which makes the current draw very small.
- Boot your PC or whatever, and run skewbe's Java app. For that I personally made a batch file that just calls the java program, else Windows doesn't launch it (maybe one needs to register the .java extension as a runnable program?).

The program works w/o the car: just with noise on the microphone it'll do some random stuff.

mpmetro:

That's some ugly soldering LOL :)
make sure that glue holds tight.

mpmetro -

Plastic box containter. Righteous!

CarloSW2

i know...:o i cant solder.

I've already done some of the programming. Java was new to me too but not that hard to pickup. I added a way to 'guess' VSS pulses based on tire size and final gear and a way to calibrate vss pulses over a given number of miles.

I'm also trying to add the cid and crr calculations but stopped at trying to figure out how to use the actual temp, pressure and humidity to get air pressure index. Also I didn't want to release anything until I could get it installed and calibrated (and debugged!) in my truck, but I'm kind of scared to throw a resistor in line with the negative on my injector and can't find my VSS (tons of wires to my trans and transfer case and not sure what I need). For now I'm just using small tankfuls and trying to drive (I have no time to work on most these things anyway).

A graph might be nice but I think I'd rather see a more 'gauge' like interface (with a needle). The only other diagnostic I'd like to add is instantaneous HP/power and keep track of that over trips too.

For instance the same trip done at 45MPH and at 75MPH, the 75MPH will neccisarily have to have generated more energy/hp and most likely used more fuel.

I was also wondering about trying to find a pinout diagram of my ecu and pull signals there. Not the processed signals from an ODB connector, but the actual inputs to the ECU and bridging them.

Ok, that's what I understood from diagram posted earlier, but I still can't tell if you're tapping inline to the 'ground' from the injector or if you're bridging off or if you're tapping into the positive side.

I'm also still confused on what the diodes do (which is fine I don't really need to know :p) and I'm confused why VSS signal would be hooked to a common ground, I picture it acting like the pulsing coil on my motorcycle, it's generates a small VAC current due to the magnet going toward and away from the circuit.

Also I was going to swap the 10k res for a 25k pot for calibration (I just need to be unlazy).

sonyhome: Yes on all accounts

itjstagame:
I believe my injector has a switched ground, so I'm on the other side of that, counting on the voltage drop across the resistor to give me a signal.

My VCC is a switch, which mysteriously does go positive and negative??? Don't care. The wagon is a magnet, or a hall effect thing, I expect that might take some figuring at slow speed and/or an op amp.


anyone: You can mess around with my wav recording for defaultFile. It's a bit more relevant than mic noise. It's too big to post so PM me your email and I'll forward it,2.5 meg. Tell me if you think the rpm "whine" on it is the alternator if you listen to it.

Ok, so you're on the same leg with the resistor in the middle, sounds good to me. I still worry about changing the ground of my injector (through a resistor) affecting pulsewidth, but I guess it doesn't matter and I can always change it back if there's a problem.

Yeah, I suspect VCC to go positive and negative but I guess that's all good too. Just need to find my VSS and start splicing.

skewbe -

Have you thought about porting this to a PDA? I noticed in other "data logging" car programs that they would use PDAs.

CarloSW2

This should work fine on PDAs, he made it in Java for the very reason that it should work on almost all platforms and OSes. I'm pretty sure there's full java support on all PDAs and smart phones and that's what most of their applications are made in. You just need to have a line in port on the PDA... which I'm not sure will exist, it should exist on a smartphone or any cellphone for that matter (they all have full Java I think), well microphone input will anyway.

Wouldn't you need to pull infront of and behind the resitor in order to read the drop across it? In fact wouldn't doing it that way cut your max voltage off at whatever can pass through whatever weight the resistor is?

Right now you're pulling from infront of and behind the diode array (which I still don't understand as I don't understand diodes). I will give it a try though.

I had to make compromises because of the common line-in ground between the two signals. There's a lot of variables so If you point me at a schematic for your injectors and vss I will take a look and make a suggestion.

Think of the diode as an open switch until the voltage drop across it is 0.7Volts.
Then it is a closed switch with a constant 0.7V drop.

So it has 2 modes of operation to consider when you read the diagram. The "bridging" is done to garantee it behaves the same independant of the current direction.

A diode is also a "one-way valve" for current, if you don't mind a plumbing analogy...

yay... I just connected mine in my 91 geo metro, 3cyl, and It is working. One thing is not right though. The speed that the program shows is about 5 mph higher than the actual speed on the speedometer. Like if I am going 15mph, the program will show I am going 20 mph. What could be causing this? and how can it be fixed?

Way Cool!! Try this:
locate the mpg.properties file , edit it, and change distanceFudge so it is 20/15 (4/3) larger.

It could be caused by 12 inch tires and other model difference from 92-98 I suppose

I have also noticed that now that I have the circuit wired to the car, I have a check engine light on, and the code 24 shows it to be the speed sensor, even though the speedometer works fine. It goes away when I disconnect the vss from the circuit. I migh make a switch when I make this permanent.

Sounds like input loading by the 10K resistor. Maybe a higher value would fix it? Maybe.