Any interest in developing an open source fuel economy gauge/computer?

[AndrewJ]

Count me in as way-totally-super-interested.


Damn SuperMID is a PITA so far, plus it would be nice to have wider computability.

[MetroMPG]

I think a *duino based gauge would be an equal if not greater PITA. But it would be your baby, & probably less expensive PITA, thus making it worthwhile!

It occurred to me last night that doing this on a programmable, expandable platform opens the door to getting all kinds of groovy additional features we've been dreaming about in a FE gauge.

[Bearleener]

Every new feature is just a few lines of code away!
I nearly implemented an Atmel ATMega 32 as an FE gauge, but also to auto-shut-off the engine whenever coasting. The latter feature didn't work too well so I mothballed the project but now I'm dying for an FE gauge so I'm glad that you guys are interested, too!
Most of the FE code (which can be programmed in C or Basic) I basically had running. The ATMega 32 is nice (has floating point arithmetic, lots of counters etc.), but is rather expensive when bought with a development board.

One issue was measuring low-frequency signals such as vehicle speed (about 1 Hz per km/h) and engine speed (which I measured at the Hall sensor on the distributor, running at 1/2 the engine speed = 15 Hz at idle). The processor had built-in frequency counters but at any decent refresh rate you just don't get enough pulses in the sampling period to be accurate. I instead did it with event counters.

So I'd be glad to contribute some coding ideas and info about which signals to tap and how to interpret them (at least on my Volkswagen).

Some other nice-to-have features would be not only measurement but also control features, such as auto-stop-start, engine preheat, etc.

[LostCause]

EcoMeter, EcoModder, eh? eh? I like to think of the important stuff first.

Before we all start hashing away at this in detail, we should agree on hardware. While open-source means open-ended, if we all work towards the same device then I think it'll be easier to collaborate. I think useful goals will be maximizing bang per buck and staying simple...

Hardware
*Arduino/Freeduino MicroController
*16 x 4 LCD Display
*4 surface mount buttons

The display is important for standalone functionality. 16 x 4 appears to be 40%+ cheaper than a 20 x 4. 4 surface mount buttons allow simple device interaction.

For tapping into the OBDII port later down the road, can someone post the pinout the ScanGauge uses? It looks like it uses a 4 wire telephone cord, so it can't be too complex.

Software
At this point, KISS...

The number one priority should be instantaneous MPG as determined with data from ECU injector output #1 and VSS. Once Inst. MPG is perfected, other details can be easily added. I think it's important not to take too big of a bite.

Conceptual Layout
We should also outline how this will be done conceptually. Here is my understanding.

Injector pulse width:
*Injectors are rated in cc/min
*The ECU sends out a digital signal of either 0V or 5V
---0V means closed, 5V means firing
*The arduino will sense the 0V, 5V states at one digital input
---The length of 5V state will determine injector pulse width
*The pulse width times the cc/min rating will give fuel consumed

Injector Pulse Width Diagram


VSS:
*VSS gives off an analog signal that varies between 0V and 5V
---i.e. 45mph shows a voltage of 3.13V
*The arduino will sense voltage at one analog input
*Voltage gives vehicle speed

VSS Diagram


Instantaneous MPG:
*(Fuel consumed over full pulse width [peak + trough] * # cylinders) / vehicle speed
---multiplied by whatever conversion factor desired (km/l, l/km, mpg)

__________________________________________________ _________

If this conceptual logic makes sense (voltage values are made-up, BTW), then the next step would probably be language logic. Since most of us aren't coders, developing the code in understandable terms first will help outline the software. The use of and, or, nor, not, if, then, else statements would probably help.

For example:
If pin 1 = 5V
then start counter
If pin 1 = 0V
then stop counter

Anyways, that's my logic

Lastly, for motivation?
A potential payout:
*Instantaneous MPG
*Trip MPG
*Fuel Consumed
*Engine Off %

Potential Layout


- LostCause

[MetroMPG]

Woohoo! We have a project manager!

Yes, important things first: eMPGauge... EcoDisplay... FEedback... GameGauge... EcoCrack... (I've always thought the SG is highly addictive)... OCDgauge...

Hey I just googled ecometer. Has anyone seen this - http://ecometer.com ??

I agree on all your major points, too. Minor suggestion: L /100 km instead of km/L.

My *duino shipped today.

[dcb]

Well, I've been thinking about the hardware a bit too. The path I'm starting to look down is something like a plain old 8051 microprocessor ($2) as a signal processor that sends a few bytes to the device that does the displaying/logging/whatnot via an rs232 connection (use a usb adapter if you have usb). I'm thinking of this approach personally because I have an old serial based palm pilot, and I'm sure there are probably a few pallets of them for dirt cheap somewhere. And it has display/touchscreen and other functions built in.

Just thinking out loud here but the flow would be:

8051 boots up, waits for init command on serial port.

palm (or laptop, or cellphone or pda or ardunio or ???, henceforth referred to as "palm") sends and "I" (for init) followed by a few bytes to tell the 8051 what to use for voltage thresholds and direction for decyphering the VSS and injector pulses. The 8051 will use a couple of its A/D converters to connect to the vehicle.

8051 says "OK" and starts polling the injectors and vss

Once a second the palm will send an "F" for fetch.

This will trigger an interrupt on the 8051. The 8051 will respond with several bytes:
1st 4 bytes: total number of sample cycles since last fetch
2nd 4 bytes: number of sample cycles where the injector appeared open since last fetch
next 2 bytes: number of vss tics since last fetch
and then the 8051 will clear all counters and resume

The palm will take the counts and update the various trips/instant data based on adjustment factors (vss tics/mile, how much fuel was actually delivered) and update the display, and draw pretty pictures if you like

In this way, all the configuration data is kept in the palm, and you can save/load specific parameters for specific vehicles, and probably hotsynch your fuel log with your computer.

[trebuchet03]

Originally Posted by LostCause

[B]

Injector Pulse Width Diagram

Scroll down for injector waveform - I think you'll have to be logged in though...

It's not as pretty as a 0v or 5v logic :/ Perhaps if !=0 - but requiring some form of calibration (like the SG tank to tank sort of deal).... I don't think calibration can be avoided either way though as some sort of adjustable gain is needed...

[LostCause]

Originally Posted by MetroMPG

Woohoo! We have a project manager!

Yes, important things first: eMPGauge... EcoDisplay... FEedback... GameGauge... EcoCrack... (I've always thought the SG is highly addictive)... OCDgauge...

My *duino shipped today.

Just stoking the fire...

I do like EcoCrack... I think we should call them SkanGauges and sell them in Tijuana.

When you get your 'duino I'm sure you'll feel the first roadblock for us all: "Man, what the hell am I doing?"

Originally Posted by dcb

Well, I've been thinking about the hardware a bit too.

The more paths the better, but the cool thing with the 'duinos is that they are completely standalone and completely opensource. I just have visions of a black box w/ a screen and some buttons a la ScanGauge. You definately have the know-how, so I watch with interest.

Originally Posted by trebuchet03

Scroll down for injector waveform - I think you'll have to be logged in though...

It's not as pretty as a 0v or 5v logic :/ Perhaps if !=0 - but requiring some form of calibration (like the SG tank to tank sort of deal).... I don't think calibration can be avoided either way though as some sort of adjustable gain is needed...

This is the point where I pass the baton...

I can't see the pictures since I'm not logged in, but I suppose the injectors can be placed on an analog input and set to count at some threshold value (i.e. start counting at 0.92V, even if it peaks at 4.75V). I was thinking calibration could be done by changing the injector size as a part of the setup menu... (193cc, 194cc, etc.)...

Step 1 for me ---> Learn C.

- LostCause

[Silveredwings]

I got an obd2 board (elm323 variety) and planned to embellish a basic Java applet but alas the board has rs232 and my laptop has only usb. I haven't gotten an adapter (that's how little time i have to play with it anyway).

[diesel_john]

Any domestic injector i ever tested had 14 volts on it continuous and the ECU grounded it to fire it.
The pulse width is constantly changing every other engine revolution and instant FE is not readable without some averaging.
Only need to log one injector's on time.
Calibration to each vehicle using a known quantity of fuel and a known distance is the way to go IMHO.
So it needs accumulate total injector on time for one injector.