My fuel meter - first results...
 

I took my fuel meter out for a spin for the first time today. From what I gather, it's similar to the SuperMID I keep reading about. Right now I don't have a VSS signal hooked upto it, so it's just a fuel meter, but far more accurate than a Scangauge. Here are some features...

16-bit injector resolution
124Khz injector sampling rate
64-bit fuel table

Basically, what this means is that the gauge knows what your car is doing with every single droplet of fuel. Where the SG gives you details down to a tenth of a gallon, mine gives you more digits than you'd care to see. Also, since it's injector based, it reads correctly regardless of fuel ratio, lean burn, injector cutoff, etc.

Today, I wanted to figure out which fuel ratio would yield the best MPG for my Cavalier (something the SG was useless at doing) and this is what I found...

14.7:1 - 37.834 MPG
15.9:1 - 38.437 MPG
16.3:1 - 39.705 MPG
17.4:1 - 35.423 MPG

I'll have to do some more testing to fine tune the ratio even further. Best MPG ratio is definietly lean of stoich, but I can't run as lean as a Civic HX/VX with the same results.

Interesting stuff. Got any pictures/details on the meter? Been following the mpguino stuff?

From what I see, the MPGuino is supposed to be an open-source alternative to the SG. It looks like the project is being written in C.

My project runs on the same family of hardware (AVR), but I'm writing in pure assembler. C is my choice for doing stuff with Linux, but on a platform like this, I prefer to have absolute control whenever I can get it. If my code is tight enough, I think it should run fine on an ATTiny.

I wrote the display routines a few days ago, and just recently, a 32-bit division routine that came in handy.

The display is about 5% smaller than the SG's, but much brighter and easier to read with bright text.

Unlike the MPGuino project, I'm not going to open-source this one. Also, I have no interest in cloning the ScanGauge. Honestly, at $170, it's not ball-bustingly expensive. I bought one myself, but it's not a good option for hypermilers, it's merely the best we have. It's wonderful for real-time engine stats and clearing codes, but it just isn't accurate for fuel consumption. It cannot give accurate feedback because it doesn't know anything about special fuel-saving modes. The scangauge is to hypermilers what the G-Tech is to racers. Anything less than injector input is a crap shoot.

Uh, no. MPGuino is designed to be a high precision fuel injection monitor. The signal processor has been published for weeks, don't know how any self respecting coder can get the two approaches confused ;)

I am indeed a self-respecting coder, but I haven't spent any time analyzing the project. From the few things I've read, it seems targeted towards the OBDI folks. I see now that it does connect to the fuel injector. In that case, it would be closer to the SuperMID than the SG.

Right now, my code is light enough that running on a ATTiny2313 is entirely feasible.

Also, I'm not really sure what all this Arduino business is about. Does it use C or its own language? Either case, I'm sticking with assembler.

Welcome to the site JohnnyGrey.
I appreciate your opinion here.
If you do get time to read up on the MPGuino, I would be interested in any constructive comments you have.
16.3 to 1. I wonder if its much different for other engines of simliar type.

diesel

Thanks, I've been reading and posting in this thread as well:
http://www.ecomodder.com/forum/showt...?t=1725&page=3

Hey Grey, how are you doing air fuel ratio? Do you have a wideband o2 sensor? Is that what the fuel table is for?

Re: arduino, it is just an affordable ($15 for the board/cpu/and all components) and open source hardware platform with a lot of people working on it to improve it and do new things with it all the time. It is based on the atmega168 and the boards currently in curculation are easy to program with the provided IDE (also open source). the IDE (written in Java) supports a c-like syntax, and figures out what to include and link to make the binaries based on what your code references. But all of wiring and AVR and GCC, and even assembler are still at your fingertips (I would save the assembler for spots that need optimizing in performance or size).

So the platform is easier for pic newbies, has a huge user base, can do anything an atmega168 can do, usually in an easier fashion than the dropping into a lower level because someone has put a library together, but the lower levels are still there for more advanced users. Also it doesn't require extra programming hardware. But certainly an experienced person could solder a few wires to an atmega168 on the cheap and reuse the code.

But doing everything in assembler to get it on a ATTiny2313? I don't get that. What you gain in size and performance, you usually lose on development and maintence and features. Those ATTinys are like $2.50, and an atmega168 chip is like $4. Oh well, no accounting for taste :) Glad you are into it.

Let me know how you figured out air fuel if you please.

Yes, I do have a Bosch wideband installed in my car. That signal is read by an AEM gauge, which sends its linear 0-5v signal to this custom board:

http://forum.ecomodder.com/attachmen...1&d=1209954264

which emulates a narrowband sensor, and lets me pick two different AFRs that I can cycle between via an external switch.

If I ever exhaust the 2K flash of the Tiny, I can move up to an ATMega162 fairly easily. I'm not using assembly as means to get the program to fit on a Tiny. I'd still use assembly on a 162. Compared to x86 asm, the AVRs are a pleasure.