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

[dcb]

Lets back up. Why are we doing this, aside from we want to learn how to do this? What is our mission?

From my own perspective:
Misson: To enable as many folks as possible, as soon as possible, to be able to save fuel by driving more efficiently because feedback from a MPG gauge is an essential tool for fine tuning ones driving habits.

Does anyone want to add/modify?


From that perspective though, I don't see that V2 has to be built on the same hardware as V1. V1 should be a compromise between cost/availability and time to market. There is every chance that v2 will be done on even cheaper and possibly better integrated hardware.

Also I think we need to consider carburetors. A mass airflow sensor is just a piece of heated wire with a controller (pic/stamp?) and may give an accurate indication of fuel flow once calibrated with a few fillups. Not perfect, but cheap and possibly quick. Is there a physicysist in the house? Could such a sensor be made and inserted in a fuel line, or is it gasses only?

[MetroMPG]

Originally Posted by dcb

Misson: To enable as many folks as possible, as soon as possible, to be able to save fuel by driving more efficiently because feedback from a MPG gauge is an essential tool for fine tuning ones driving habits.

The only thing I'd change is the time issue. I'm not in any particular rush to enable people to have/build this. Why the added time pressure? If we build it, they will come.

Aside from wanting to learn about this stuff, my original motivation was simply to develop something like the MID - with the same basic features - that many people keep asking about, but can't get for reasons of availability or affordability, or because they can't stomach the thought of a display that doesn't read in mpg (US) .

[AndrewJ]

Originally Posted by MetroMPG

The only thing I'd change is the time issue. I'm not in any particular rush to enable people to have/build this. Why the added time pressure? If we build it, they will come.

Aside from wanting to learn about this stuff, my original motivation was simply to develop something like the MID - with the same basic features - that many people keep asking about, but can't get for reasons of availability or affordability, or because they can't stomach the thought of a display that doesn't read in mpg (US) .

I think that a quicker timeframe is a laudable goal. If it's possible. Lets face it, people are going to want gauges in a few months, when the fuel price spikes really hit home this summer. If it's not possible to get a decent V1.0 in that timeframe then that's ok, but it's something to keep in mind anyway.
I agree wholeheartedly with dcb's mission statement.

A few comments from a self-professed electronics-moron.

--palm OS
-- I like the idea, but it's unnecessary in the V1 stage, would perhaps be a good V2 (or V3) add-on for syncing and online sharing (like Nissan's Japanese system) Plus it's just one more thing to have to find a place for on your dash, and to keep it charged....

--display
--I like LostCause's "potential layout." Very straightforward, just what we need.


--Arduino/freeduino
--sounds ideal. Of course I know nothing about programming/ee. I just like that it's cheap and opensource.


Oh, and correct me if I'm wrong. But the end product is essentially going to be a solder-it-together-yourself hardware unit with a downloaded software component.

The only part that makes me nervous so far is the software downloading bit. Please keep us mac users in mind Looks like I'm stuck with the USB'd 'duino.

Keep up the great work everyone, I'll be following closely (and wayyy over my head.)

[dcb]

Ok, here is kind of what I'm envisioning for V1, I just saw a bunch of palms go for less than $10, and we have a java prototype to copy from so it is easy cheesey. And for $10, you can glue it to your dashboard without losing any sleep and hide the circuits behind it or under the dash.

We can cherry pick the car adapter circuits for v1 (just get the injector pulse one working), though someone probably should try and quantify how many carbed vehicles are still on the road. With seperate components, people can work on different parts simultaneously.

Thoughts?

[dcb]

Why do I emphasize time? For ecological reasons.

Why am I still harping on about the palm? I think it is a terrific reuse opportunity. It's a great little device that deserves better than the landfill. I've had a few and never paid for one of them. Here is a site with one mounted on a motorcycle (and other places):
http://www.conklinsystems.com/palm/pwh/ . And I'm going to be writing the above gui screen for the palm when my elm323 adapter shows up anyway.

Its about twice as wide and half as thick as a scangauge and the same length, so it shouldn't be a real challenge finding a spot to mount it.

I have no problems with an integrated display solution for a future version if the palm supply looks like it is going to dry up of course.

[dcb]

So here is the roadmap as I would see it.

V1:
Palm and laptop version of display.
Injector pulse monitoring version of interface circuit.
rs232 based interface.
interface sends summary data to display when display requests it (~ once a second):
* how long total since last check
* how long were the injectors open since last check
* how may vss tics since last check

Use usb->serial adapter for programming palm if necessary or load it from a less bleeding edge computer. Free downloads for putting programs on the palm (and for palm development).

I'll let whomever steps up for the hardware interface describe how we are going to get the program on the chip, if it even needs a program.

V2 and above:
more vehicle type interfaces (diesel/carb)
DIY display device
usb options for vehicle interface options
other handheld (i.e. cellphone) display options
a bluetooth enabled vehicle interface

[diesel_john]

connection diagram

rough draft installation instructions

[LostCause]

I suggest we do two things, agree on a roadmap and hardware. Polls, majority wins?

My Roadmap Suggestion:

Version 1:

• Injector & VSS Sensor input only
• Instantaneous MPG
• Trip MPG
• Tank MPG
• Gallons Consumed
• Engine Off %
• Menu system that allows
  ---Trip A/B Storage
  ---mpg, l/100km, km/l units
  ---fine-tuning
  ---choose which values to display

Version 2:

• Same features as Version 1
• Ability to export data
• OBDII Input
  ---All sensors available (CLT, IAT, MAP, Voltage, Load, etc.)
  ---Equivalent gauges available
• Analog Input (Non-OBDII Vehicles)
  ---CLT, IAT, MAP, Voltage, etc.
  ---Equivalent gauges available

Version 3:

• Same as Version 2
• Graphical Gauges

Hardware:

Versions (1+2):

*'duino Diecimilia (~$24)
*16x4 LCD Display w/ BL (~$12)
*4 Contact Buttons (~$2?)
*Minor circuitry (Diodes, OpAmps, Resistors, etc.) (~$5?)
===========================================
SubTotal (~$43)

Post 'em if you got 'em...

- LostCause

[dcb]

Vote? This is an all volunteer effort, you kind of have to take what you get, and you vote by rolling up your sleeves and doing something.

Note, my roadmap does not exclude the freedunio, it just makes the realistic assumption that it will take longer to develop a useable model with it. But having LOTS of programming experience, I can say that if you want a fancy GUI the job for that will be made a lot easier with decent tools, like a graphical IDE and an emulator, which I don't know if they exist for the dunio yet. But here are some screenshots for the free palm IDE and the open source OBDGauge that I'm going to be working on if anyone is interested (I deliberately misspelled "throttle" for a quick test:

[diesel_john]

MAF description
MAF meter details

dcb
i finally get what your saying about putting a MAF on carb'd engine, i bet once cal'd to an individual engine and speedo, it would give good real time fuel economy. Pounds of divided by about 13 or 14 gives pounds of fuel. And if some thing changed in the engine, the tank fill numbers would alert the operator. Of practical importance, would be the ability to teak cal. numbers without going through the whole cal. routine again.