MPGuino - $40 FE gauge

yetimus · February 28th, 2009, 17:06

I started a thread a few weeks ago inquiring whether or not it would be feasible to install an MPGuino fuel efficiency gauge in a TDI. The consensus was that it couldn't be done (easily, at least). But I've pressed on with this project and so far I'm quite pleased with the results.

What is an MPGuino? It's an Arduino based open source fuel economy computer based on a ATmega168 microcontroller. The assembled product looks like this:

It is designed to calculate fuel economy by tapping into a vehicle speed sensor and a switched 12V supply to a gasoline engine's fuel injector. Two questions needed to be answered in applying this gauge to a TDI. In the absence of a 12V signal to a fuel injector, is there a workable equivalent signal on the TDI electronics? And, will I fry my ECU or other components in doing so?

In reference to the fuel injector signal, after completing Chris Bell's MFA cluster conversion in my 96 Passat, I became interested in tapping into the fuel consumption signal generated by the ECU which feeds the MFA. I had no idea what this signal looked like, but ecomodder.com user rmccomiskie was kind enough to post an oscilloscope graph of the fuel consumption signal on his Audi A6. I assumed (correctly, as it turns out) that the signal on the VW would be similar. Here it is:

Second question: will I fry my ECU by tapping into this signal. Looking into the Arduino website, it states the following:

Quote:

Arduino (Atmega) pins default to inputs, so they don't need to be explicitly declared as inputs with pinMode(). Pins configured as inputs are said to be in a high-impedance state. One way of explaining this is that input pins make extremely small demands on the circuit that they are sampling, say equivalent to a series resistor of 100 megohm in front of the pin. This means that it takes very little current to move the input pin from one state to another, and can make the pins useful for such tasks as implementing a capacitive touch sensor.

I recall reading elsewhere that they draw 0.7 mA. With that information on hand, I ordered and assembled the kit. Despite my lack of board-soldering experience, I soldered the thing together, plugged it into a USB port, and Voila! it came to life.

Next step was to tap into the VSS and fuel consumption signals from the ECU. Since I had just completed a cluster conversion, I had easy access to the plug on the back of the cluster containing the two necessary signals. Pin 26 on the cluster provided fuel consumption and pin 27 provided VSS.

I decided to install it in the ashtray recess. I scavenged an ashtray from a salvage yard Passat and gutted it so I was left with only the faceplate, then carefully cut out the openings for the LCD display and three pushbuttons. Since an unswitched 12V supply is also needed, I tapped into the cigarette lighter power which was conveniently located nearby.

With all four wires attached, it was time for a test drive. Based on research I had done on the ecomodder.com forum, rmccomiskie had tried adapting this signal from his Audi, but he found that a change in the code was necessary to prevent GPH readings from reading backwards (i.e. GPH rising while coasting/falling while accelerating). After making necessary changes to the code, the GPH and MPG readings started responding as expected. I've spent the past few days calibrating it and it's looking like it's providing pretty accurate readings. Prior to buying the Passat in '07, I had a '98 Jetta equipped with Scangauge and the MPG numbers generated by the MPGuino look very much in line with those generated by the Scangauge (different vehicles, mind you).

The finished product: ( this pic was taken very early on in the calibration process, so it's reading a tad optimistic

)

I realize that Scangauge is WAY easier than going this route. I have a 96 Passat with the OBD-D BK ECU, so that wasn't an option for me. Also, this can be done for around $50-60 installed, which may be attractive to some. It's available in kit form here or a complete pre-assembled unit here. AFAIK, the pre-assembled kit isn't equipped with a USB port which may make changing the code a bit of a challenge, but I've contacted the seller about selling the units with the code changes pre-installed.

Lots more reading can be found here and here.

Chris Bell · March 25th, 2009, 16:59

I love the compact size; it should open up a lot of mounting location options not available with Scangauge. The backloaded flush mounting is a big plus, too, as well as not having an ugly diagnostic plug and cable visible (asthetically unacceptable for me) or, at best, a hidden connector that you must remember to disconnect every time you want to plug in your diagnostic software. Digit legibility leaves a lot to be desired, although the unit label characters are fine.

Overall, very cool! Nice job, Yetimus, and congratulations on your persistence in proving the naysayers wrong and providing a trip computer option for OBD-D ECM cars.

I'm less enthusiastic about your idea of mounting it in the cluster, but stock appearance is a top priority for me, particularly the cluster.

I'd be interested in any other info you gleaned about the nature of the fuel consumption signal. I have tried to modify signal pulse frequency for easier MFA MPG accuracy correction without success so far. The Dakota Digital interface doesn't like that signal and I'd like to find something that does.

yetimus · March 30th, 2009, 18:55

Thanks for your comments, Chris. It's been a fun project. I've learned a lot about electronics and I'm very pleased with the accuracy of the finished product.

Quote:

I'm less enthusiastic about your idea of mounting it in the cluster, but stock appearance is a top priority for me, particularly the cluster.

I agree with you in your preference for a stock-appearing cluster. I just don't like looking all the way down near the shifter every time I want to check FE - much rather keep my eyes on the road! So, hopefully I'll be able to fabricate a clean-looking installation in the cluster. Time will tell.

Quote:

I'd be interested in any other info you gleaned about the nature of the fuel consumption signal. I have tried to modify signal pulse frequency for easier MFA MPG accuracy correction without success so far. The Dakota Digital interface doesn't like that signal and I'd like to find something that does. 02-28-09 04:06 PM

Any and all info I learned on the fuel consumption signal came from here. Funny you should mention modifying the signal pulse frequency - I had a very similar concept in mind. The Arduino is a very flexible computing platform and I was thinking I could eliminate the need for the Dakota Digital tach interface in the B4 MFA conversion entirely by programming it to perform the pulse frequency adaptor function. I have another Arduino board on order and will be trying to figure out how to do so in the upcoming weeks. Here is an example of a program controlling a servo motor (i.e. tach needle) using an analog input. Of course, we're dealing with digital inputs here, but a similar program could probably be written using the pulseIn command. I'm still very low on the learning curve here, but it's been fun learning about all this.

Powder Hound · March 31st, 2009, 11:15

So what you are saying is that for fuel consumption, the ECU is sending a digital signal to the cluster, and every leading edge of the signal corresponds to the injection of some discrete quantity of fuel. Do I have that right? And in the same manner, every leading edge of the VSS signal corresponds to moving a discrete distance, determined by the effective wheel radius (which is affected by tire size, inflation pressure).

The MPGuino device then does a couple of additions, a division, and a couple of accumulations to report to the display.

Sounds like fun.

Chris Bell · March 31st, 2009, 16:48

The VSS generates 7 pulses of constant width for each wheel revolution, regardless of tire diameter (for B4s; A3s generate 4 pulses per rev.). The odometer is calibrated for an inferred distance with "new-tread" stock diameter tires at recommended pressure.

When I went to a larger wheel & tire diameter, I corrected the VSS signal with a pulse adaptor and had to choose between an adjustment that would allow the odometer to read correctly with new full-tread tires (the factory approach) or with tires worn to half tread depth, which would allow more accurate average odometer readings over the full life of the tire. Rightly or wrongly, I chose the full tread approach.

Chris Bell · March 31st, 2009, 17:10

Yetimus, thanks again for the info.

yetimus · March 31st, 2009, 17:47

Quote:

Originally Posted by Powder Hound

So what you are saying is that for fuel consumption, the ECU is sending a digital signal to the cluster, and every leading edge of the signal corresponds to the injection of some discrete quantity of fuel. Do I have that right? And in the same manner, every leading edge of the VSS signal corresponds to moving a discrete distance, determined by the effective wheel radius (which is affected by tire size, inflation pressure).

The MPGuino device then does a couple of additions, a division, and a couple of accumulations to report to the display.

Sounds like fun.

You're on the right track, Powder Hound. The MPGuino does count every leading edge of the VSS Signal. It then calculates distance travelled (and speed) through a user parameter "Pulses/mile" which allows you to calibrate the computer based on drive ratio, tire diameter, etc.

The fuel consumption signal works a little differently. The MPGuino measures the time (in microseconds) that the fuel consumption signal is HIGH. It then multiplies "injector high" microseconds by another user parameter "microseconds/gallon" to calculate consumption.

Sayyad · June 10th, 2009, 20:44

Yetimus, fantastic work. I'm a member here and at ecomodder and I have a 99 Jetta (A3) TDI. How would I get the MPGuino to work with my car? I'm in Canada and it looks like a Scangauge is somewhere north of $200 including all taxes; I only want to know how much fuel I'm using.

RMHayes1954 · August 4th, 2009, 05:06

Quote:

Originally Posted by yetimus

The fuel consumption signal works a little differently. The MPGuino measures the time (in microseconds) that the fuel consumption signal is HIGH. It then multiplies "injector high" microseconds by another user parameter "microseconds/gallon" to calculate consumption.

Nice work.
Can I suggest that you might multiply "injector high microseconds" by "gallons per microsecond" to get "gallons per injection", then integrate (sum up) "gallons per injection" over a 1 second period to get "gallons per second", then divide "miles per second" from the speed signal by "gallons per second" to get "miles per gallon". How reliable is the Arduino microseconds measurement?

How did you get "gallons per microsecond"? Is that a calibration factor based on a tank-full? Is it temperature sensitive?

Can you get similar base signals (fuel consumption and speed) from the CAN or OBDII interface?