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

[MetroMPG]

The Arduino has serial output (and input - that's how it's programmed), not sure about the other platforms mentioned so far.

[MetroMPG]

Originally Posted by trebuchet03

That's just me, as someone with limited experience with microcontrollers - which is very likely the case for someone that is going to replicate any efforts.

Originally Posted by LostCause

Look at the simplicity of the design compared to the arduino. No pre-etched board and just a bunch of components that can be bought at once from Digikey, Mouser, etc.

I'm with Trebuchet, because of my experience with this stuff ( = nil).

The thing that appeals to me about the Arduino is that it's ready to go, and I understand the programming process - plug it into a PC serial port and install the code.

I wouldn't know where to begin if I also had to select components & make the platform.

How is an atmega or other IC programmed?

[dcb]

I think it has to have some kind of display, and an instantaneous and at least one resetable trip readout, to be a really useful "learn how to drive again" tool.

So at a minimum it:
1. has instant MPG displayed at all times.
2. has trip MPG displayed at all times.
3. is cheap on parts.
4. is adjustable to different vehicles.

Other computable items from injector pulse and speed sensor:
RPM
MPH
Gallons
Distance
Acceleration
Decceleration
Hours

[dremd]

I can't help much, other than my moral support, and pledge to buy one for my supra once it gets going.

Once feature that my bike has, that my SGII lacks is Cadance, might be cool for MPG computer . . .. . . Just an Idea.

[LostCause]

Originally Posted by MetroMPG

I'm with Trebuchet, because of my experience with this stuff ( = nil).

The thing that appeals to me about the Arduino is that it's ready to go, and I understand the programming process - plug it into a PC serial port and install the code.

I wouldn't know where to begin if I also had to select components & make the platform.

How is an atmega or other IC programmed?

It seems that the arduino uses an atmega168 microcontroller w/ a bootloader, so it is programmed directly via serial/usb. I think other IC's (PIC, BASIC Stamp, etc.) require a board to interface with a computer via serial. Really old stuff (EPROM) requires data to be erased by UV and then loaded. Thank goodness it's not 1984...

Since I also have no experience I won't advocate the tough path anymore. It just seemed like the logical path if the experience can be found in this board. Essentially, the end product would be MegaSquirt-esque: purchase components, solder, download code, install, done...

If the arduino path is taken, another option is the freeduino: completely open source + USB. ~$24



Info for getting an LCD up and running. Apparently, to have buttons, input pins available, and run an LCD it needs to operate in 4-bit mode. Here's what I've found so far.

Reasoning
LCD interface in 8-bit
LCD interface in 4-bit
Source of LCD's (w/ or w/o backlighting) ~$15-20

This is kind of dumb, but what about an "analog" fuel economy gauge?

- LostCause

[MetroMPG]

Good link. Anything with "free" in the name must be good!

I just ordered one.

[trebuchet03]

Originally Posted by dremd

Once feature that my bike has, that my SGII lacks is Cadance, might be cool for MPG computer . . .. . . Just an Idea.

Isn't RPM the same thing?

[LostCause]

Originally Posted by trebuchet03

I know you can buy, from SAE, the book on the OBDII protocols and how to interface - probably something necessary if you want to plug into the diagnostics port and not tap a bunch of misc. wires.

1.
2. Bus positive Line of SAE-J1850
3.
4. Chassis ground
5. Signal ground
6. CAN high (ISO 15765-4 and SAE-J2234)
7. K line of ISO 9141-2 and ISO 14230-4
8.
9.
10. Bus negative Line of SAE-J1850
11.
12.
13.
14. CAN low (ISO 15765-4 and SAE-J2234)
15. L line of ISO 9141-2 and ISO 14230-4
16. Battery voltage

The assignment of unspecified pins is left to the vehicle manufacturer's discretion.

PID's for requesting information (i.e. water temp, TP, vehicle speed, etc.)

Now, how to use all that data...

- LostCause

[LostCause]

Originally Posted by MetroMPG

Good link. Anything with "free" in the name must be good!

I just ordered one.

Man that's fast... I think I might too, I like how this is rolling along quite quickly.

The internet is a cool place, like a mega-library.

Adding buttons
Tutorial List

- LostCause

[MetroMPG]

Originally Posted by LostCause

I like how this is rolling along quite quickly.

Oh, don't mistake my buying one for committing to the project!

That said, if several of us were to get the similar platforms and start investigating further, I could see how it could snowball into actual progress.

Re-reading the thread, I can see why the *duino may not be the perfect platform for this project for a couple of reasons. But I've been intrigued with them for a while, so I thought, might as well get one.

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