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

Are there any people here who would be interested in developing an open source FE gauge/computer?

We see lots of inquiries about the SuperMID, which works by monitoring the vehicle speed sensor and a fuel injector signal. Unfortunately, Yoshi's a busy guy, so he hasn't been building too many. And the value of the US dollar relative to the Yen is making the MID more and more expensive.

http://ecomodder.com/imgs/aerocivic/SuperMID.jpg

I don't know much about this stuff, but it seems to me the open source Arduino computing device ($35) would be an ideal platform. The cool thing about it is that it could also be connected to a laptop/palm if desired.


I know skewbe @ GS developed a quick 'n' dirty FE gauge that uses a laptop sound card & audio input to monitor injector cycles, but an Arduino based system seems like it would make more sense to more people.

Doing something like this is outside my experience. I could probably figure it out, but I've got enough projects as it is.

So I'm just putting it out there to see if anyone else would want to spearhead things.

Thoughts?

What, you mean like a Megasquirt? That's way out of my league. I know where the ON button is, and I can bang my forepaws on the keyboard to make words.

Ask me plumbing, house wiring, or carpentry. All those little wires I leave to someone else.

Forepaws ... :D

No, it wouldn't have to control the fuel injection, just tap into an injector wire to monitor the pulses. It would theoretically just need two inputs, and some basic (literally, I think) programming to do the calculations.

Yes, this just need be a display, not a tool for modification or even anything too fancy like that.

It doesn't technically even need an LCD display. If someone wanted to, they could download the data onto an old laptop, or use a laptop to view the data live.

That's the neat thing about open source - more options.

I've always wanted to get into micro controllers :)

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.

Ladyada makes an arduino clone - the boarduino - http://www.ladyada.net/make/boarduino/ and is sold as an assembly yourself kit for ~$17

http://farm2.static.flickr.com/1082/...52161a30_b.jpg

Just food for thought. I don't have time now, but if something gets going - I'll throw myself into the project (throwing myself deep into projects is both an asset and a weakness of my personality :p)

I'm with Treb. I'd love to get into it as I have interest in electronics and experience with programming. However, like you, time is a huge limitation. However, I'd be willing to do what I could to help out.

Treb: good link. You can buy the Arduino as a DIY kit to assemble as well, but I'm not sure what the price is.

Daox - that about sums up my position = interest + some programming ability.

Let's see if anyone else dives in. If not, I was thinking of getting myself an ar/boarduino anyway, just to play with.

EDIT: forgot to comment on the OBD2 issue - the nice thing about the MID is it's universal to any vehicle with fuel injection. I figure people who have an OBD2 vehicle would just get themselves a ScanGauge anyway (unless this turned out to be significantly less money for equivalent functionality).

I would recommend using an atmel avr and use the codevision c compiler. This setup is very common and a lot of people use them all the time. Embedded C programming and the Atmel AVR is the book I recommend reading on it.

I have been thinking about making one for a while. The way I figured would be to monitor the injector signal and the vss sensor. Have the controller calibrated by driving and adjusting the speed constant to get it to match the speedo. Then for the gas fill the tank then drive around for a while while the controller adds up the total injector open time. Then it can calculate the flow rate of the injectors when the tank is refilled.

From there it is just a matter of calculating and displaying it on an lcd.

The reason I say use codevision is that 75% of what is needed for this is already included in the libraries it includes. The lcd interface library is on there and it is simply a matter of telling it what to display. The only thing that would need some real consideration is to build a circuit that can work with pretty much any injector signal and any vss signal. Having a few different circuits would make installing it much harder and nowhere near as user friendly.

Any idea how much the atmel platform would cost?

Reason I ask is because I think cost is going to be a big concern for the type of person who's driving a pre-OBD2 vehicle.

Or for the type of person with an OBD2 car, but can't afford an SG.

EDIT: I like your calibration idea.

Since a very basic atmel chip would be enough for this I would say the controller would be less than 3 bucks. A 2x16lcd is under $20. So I would say the whole setup with the vss and injector circuits should be less than $50.

A basic interface to calibrate the speed and fuel might need 2 buttons. With a 2x16 display you could have 4 numbers displayed. So I would say instant MPG, last minute avg MPG, Trip MPG 1 and Trip MPG 2. The buttons could be used to reset the trip numbers in normal use. Maybe use a jumper on the board to put it into programming mode. Be a very simple addition but could make it a lot easier for normal use.

There would be no point in putting a tank mpg on there since one of the trip meters could be used for that or not depending on what the person using it wants to do.

Also: I could calibrate mine quickly against the SG and then pass the settings on to anyone else with a mk4/5 car.

What would be the difference between avg MPG and Trip 1/2?

Another good parameter the MID has: % engine on vs. engine off by distance.

What else does it have, Ben?

The ability to view FE in different measurements would be good too. It's one of the things that held back the SMID's popularity on this side of the pond. L/100 km, km/L, mpg (US), mpg (Imp).

I've done PLC's/PIC's, LCD's, and I do a lot of general coding for Linux projects; I think I can contribute a lot, but it may have to wait 6 weeks. Anyways, what I need help understanding is how to access the data - that is get the measurements on the wide range of vehicles we want it for. I do not know cars yet!

Can we gather the information directly from gauges already installed? Which are best to read from? Will they all be sending the same conditioned signal - that is, the same voltage range scaled the same amount? If not then we need some rudimentary way of calibrating it, which would be easy for mileage but harder for fuel.

I would be quite interested in a Pre-OBD2 setup. If you could make it interface with a Linux PC so much the better.

I'd go with a common processor over a prefabbed/complex circuit. If the computer is built from components that can be had from boston to timbuktu, from now until 2015 then we can help everyone help themselves...

Yoshi had the right idea and I think the easiest route would be to learn from his lead. Common microchip, homemade PC board, cheap 20 line display, etc.

http://prius.2-d.jp/blog/archives/images/R0010467.jpg

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 pretty sure Yoshi pulled the signal from one of the injector wires coming out of the ECU and tapped into the electronic VSS signal at the speedo.

- LostCause

Depending on the PIC and school, there is a good chance one of us at a university has access to the development kits for the controller so we can develop and test before committing to buying them. Generally development kits are not so cheap in my experiences.

Buy an ATmega168 (common) and burn the boot loader :thumbup:

The only thing that makes the arduino nice is that it's an easy to use platform that doesn't require external hardware. For the same reasons you say the superMID design is nice are the same reasons why I wouldn't try to replicate DIY. I'd much rather prototype on a nicely etched and silkscreened board that I can just plug into rather than deal with a homemade PC board and a bunch of components :p Now, if I were making something to sell - I think I would agree with you (and I'd spend the extra time) because having an on board programmer isn't really that necessary :p

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.

I think for the input signals the easiest thing would be run a 10k resistor to a 5v zener. Then maybe use a transistor to isolate the microcontroller if needed. That should get a signal the controller is able to handle.

The VSS is just a voltage pulse every so often. Usually so many pulses per mile. So to measure it, just set an interrupt and use a bit of math to calculate speed by averaging the last few pulses for a steady number.

The injector would need a pair of interrupts. One rising edge and one falling edge. That can give a good way to measure pulse width of the injectors.

Once the basic math is figured out converting to whatever unit is needed would be a simple matter I figure. The avg mpg I was thinking of was 'Last minute avg MPG' That seems useful to make sure you aren't getting high peaks in the instant mpg reading but killing your avg by doing it wrong.

Really once the vss and injectors are going into the controller anything you can do with those numbers would be pretty easy to implement. Writing it in a higher level language like C and not assembly makes stuff like that just a few minutes worth of work.

There are some really simple atmel programming setups. So a programming circuit could be as simple as a single IC and a few wires. I figure there will be a lot of people not willing to build their own and will want to buy one. Having a easy to build system would be nice for whoever wants to make and sell them assembled. Another advantage of the atmega setup is that even if the chip is discontinued it would be a 5 minute job to port the code to a new one assuming there isn't one that is directly compatible.

Aww, you guys quoted before I had a change of heart and edited my post. :p

I'm just concerned over availability and cost. By building the circuit with basic components that are widespread and cheap, then what is developed here will always be available. I just like the idea of ordering everything at once from Digikey or Mouser rather than having to go through specialized sources (arduino, someone on this forum, etc.). There are less logistics to deal with that way.

Ahh, this is the method I am trying to describe! Simple, available to all, and easily adaptable if a component is no longer supported. If it isn't too much trouble, it would be cool to see the development (i.e. steps taken in detail) laid out so we can follow the logic.

- LostCause

The superMID also has lap capability, which is good for lots of testing and not writing things down, but if it was possible I'd much rather have usb data logging than lap recording.

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

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?

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

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.

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. :p 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

http://us.st11.yimg.com/us.st.yimg.c...61_1993_111061

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? :D

- LostCause

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

I just ordered one.

Isn't RPM the same thing?

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

Man that's fast...:p 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

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

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.

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


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

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.

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.

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

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
http://i264.photobucket.com/albums/i...PulseWidth.jpg

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
http://i264.photobucket.com/albums/i...nisoaS/VSS.jpg

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
http://i264.photobucket.com/albums/i...oaS/Layout.jpg

- LostCause

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.

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.

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

Just stoking the fire...:p

I do like EcoCrack...:D 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?"

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. :)

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. :o

- LostCause

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

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.