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

[MetroMPG]

Originally Posted by LostCause

I do like EcoCrack...

Ooo: Ecoduino... no, no: MPGuino (or "Guino" for short. )

When you get your 'duino I'm sure you'll feel the first roadblock for us all: "Man, what the hell am I doing?"

I sure hope not. I'm telling myself, "it's sort of like Lego, but with a pointy, hot instrument!"

The more paths the better

Agreed. It would be great to see multiple approaches, because as we're already discovering, people will have access to different resources and skill levels for choosing a path that makes sense to them.

I can't see the pictures since I'm not logged in

This is from skewbe's laptop sound card-based MPG computer, which can output .wav files to examine.



vss* on top, injector on bottom
*Yellow line is default threshold for the vss,
*Cyan "..." injector

[dcb]

Here is a barebones version of the diympg gauge, no login required, complete with screen shots and source code:
http://planetchampions.org/diympggauge

Hope this helps

[dcb]

I didn't see any AD converters on the 8051 (figuring out PICs is a tricky business), but I do like the looks of the 12F675, got a $12 programmer on order:
http://www.best-microcontroller-proj...om/12F675.html

[MetroMPG]

All right. Another one dives in. Or sticks toe in water... you know what I mean.

[s2man]

Originally Posted by MetroMPG

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.

As I posted in that thread, I want something to control the mod's instead of a bunch of toggle switches on the dash. If someone else takes the FE logic, I'll work on the relay board, or maybe the built-in EFIE . I used to do industrial controls, and I've looked at the micro PLC's for my needs. But by the time I add high-speed counters and analog, they are $300. *Plus* the programming software. So I've been looking at micro controllers for a while now.

I'll third the motion for ATmel's AT controllers (fourth I guess, since Darin just bought one). AT chips are also available with CAN interfaces, if someone decides to hack into that.

I hadn't seen the Arduino wrapper for the AT processors before, but I really like that too. It's open source (hardware & software). Free programming software. Meets all cost levels: from schematics for the DIYers, to kits, to completely assembled units. Provides a higher level language, but can still be programmed in C. So we can elicit help from both Arduino and AT freaks. I think that building on an existing platform gives us a edge, as opposed to starting from scratch with just a chip, a breadboard, and a C compiler. We can tell folks "build or buy this board, and download the latest version of our software". That simple.

As for the name. For the linux geeks I suggest YAFEG. For the rest of the world I suggest OpenGauge.

Dang, I'm excited. Just hacked my router last weekend and rarin' for more. More thoughts are swimming in my head, but I'll stop for now. <another >

[Coyote X]

How about before everyone starts going off in different directions we come up with a roadmap for the project. That means someone will have to take the lead in the project.

Something like for it to be considered V1.0
- vss input
- injector input
- vss and injector calibration routine
- menu interface to configure and operate the system
- realtime mpg and whatever trip meters or other information that can be gained from those two sensor inputs.

V2.0 for example something like this
-TPS, MAP or whatever additional inputs are desired
-outputs for stuff like alternator disable, vibrating motor attached to the throttle pedal to alert the driver to ease up. or whatever other stuff needs controlled

v3 no idea


Once you get the general idea of how the project should progress it could be created on sourceforge and seek donations to build a treasury to help the developers and to offer a reward/bounty program that pays for each part of the to do list that is completed. That will get a lot more coders involved than would otherwise contribute. For the little that would need to be donated a lot of work could be done.

So really as long as there is one person with enough time and dedication to be the project leader even if they are not really as good at coding as the others, and they are willing to maintain the project and keep it going the right direction, it should be easy. V1 would probably be able to be finished by summer since it would be a basic design. V2 could stretch on for a while depending on how complicated it would be but I think getting a basic V1.0 system up and going fast is most important.

[LostCause]

Looking at the waveform of the VSS and Injector Pulses, I'm trying to wrap my mind around what information is being given. I need to do some research if no one knows the answer definately.

VSS
Skewbe claims the VSS only measures distance, requiring the computer to keep track of time. Based on the waveform, it almost looks like it's a "hand clicker." It seems like he set up a threshold value to determine when the VSS "clicks" (i.e. 9.7V or something).

VSS Waveform Graph


Essentially, it seems like it is counting revolutions. The more "clicks" in a given period of time, the more revolutions, the further you have traveled. Make sense? If so, we need to figure out the distance traveled per revolution and we need to figure out how to deal with variations of that parameter in different cars (unless it's standardized).

Injectors
I believe diesel_john's statement about the 14V, ground to fire, but confirmation from import, other makes would be nice. Skewbe's graph reaffirms diesel_john and he also uses a threshold value to start counting the pulse width. It looks like Skewbe counted the troughs (ground states) rather than the peaks as he did for VSS.

Here is the $1,000,000 question: are all injector pulses the same length (as the VSS pulses seem to be) or do they vary?

Injector Waveform Graph


If they are all the same length then the clicker analogy should do. I doubt that they are. I suppose the length the threshold is tripped needs to be counted.

Arduino
The last area of concern I can think about right now is the arduino's inputs. Apparently we are going to have to use two of the analog inputs (1 for VSS, 1 for Injectors).

The analog inputs only accept up to 5V (@ 10 bit resolution) so a "voltage divider" seems necessary...According to this forum post, the following schematic would look something along the lines of:

Voltage Divider


Apparently, it needs some more work, but it is just a heads up.

- LostCause

[dcb]

re: $1,000,000 No, the pulse widths are changing, as is the duty cycle. The prototype keeps track of how long the injector signal is above(below) the threshold and how long in general.

P.S. I like the name OpenGauge

P.P.S. I've done a whirlwind tour of palm development options (it is CRAZY with options, waba, KVM, superwaba, mobilecreator, pocketC, hotpaw, cbaspad, etc, etc,). I am settling on the same one that OBDGauge was written in. It is a 180 meg download from http://www.accessdevnet.com/ for Garnet (formerly palmOS). I was actually able to modify OBDGauge and run the modified version on my palm III.

I really want to do a comparison with the palm as an option because:

1. They are cheap and plentiful. I got mine for free. They are often on ebay for $10 apiece. With $6 worth of raw circuitry, microchips PIC, max232, voltage reg, misc, not including fancy cables/plugs, it can get the data it needs and be a complete solution.

2. They have a display built in, APA graphics display at that.

3. it is a touch screen, no external buttons to wire up, just add a widget to the screen and press it.

4. mine is backlit.

5. The support for palm programming is immense, the resulting device will be pretty awesome in that it can automatically log your fuel/mileage/date when you hit the refuel widget and hotsynch it to your desktop. Graphical displays will be a snap.

6. the garnet development system is based on eclipse (=awesome). We might even be able to integrate with OBDGague at some point and get more people looking at their mpg.

[dcb]

So Darin, I'd say at this point that if you can get your hands on an old palm for cheap (with cable) and want to try and get the freeduino to be a signal processor for it then that would be an excellent starting point. I can probably get the palm to display something meaningful with it. Divide an conquer

Did you follow my jist under "flow" in:
http://www.ecomodder.com/forum/showt...4924#post14924 , just replace 8051 with freeduino

[LostCause]

My only biff with the Palm idea is that it is the equivalent of hooking up a home PC to a mainframe to operate a wordprocessor. Why the home PC? Well, it needs to interface with the keyboard.

The *duino can do everything on its own except display stuff (would need to added) and user input (needs buttons added). If super complex additions want to be made (which would be cool), then the Palm makes sense. Otherwise, why drop a 454 into a Fiesta to go to the grocery store, even if you can get it cheap?

The *duino can be downsized to around quarter-size (arduino-mini), so the gauge can eventually be made Scangauge-sized and still be simple to build.

No need to convince me, though... I'm open for whatever path, as long as something gets done. If everyone likes the Palm idea, Palm it is. Just showing my logic (which we all love, right?...Right?) .
__________________________________________________ __________
P.S. Looking at Skewbe's MPG file shows a lot of his logic through his sidebar comments. If anyone is interested, have a look. VSS is a "clicker" & Injectors do have variable pulse widths (but they do need to be counted, anyways).

- LostCause

[MetroMPG]

dcb - you make a strong case for the Palm route. Enough that I waffled for a while, but I'm inclined to stick with the 'duino route vs. duino+Palm route for a couple of reasons:

1) one fewer piece of alien technology to learn about (that's correct, I have never touched a Palm :O)

2) selfish reason: I can think of a couple more unrelated projects where I could use a *duino, so I'm more motivated to focus my efforts there, to get the most learning about the platform from this experience.

[s2man]

Originally Posted by Coyote X

How about before everyone starts going off in different directions we come up with a roadmap for the project.

Definitely. The core FE gauge needs to be completed before any branches are considered. I was just echoing Darin's thoughts on future add ons. I think it would be good to consider modularity on V1, though. So the core doesn't have to be rewritten every time someone wants to add a feature.

And we'll definitely need to use sourceforge, or some other control system, for keeping track of all modifications to project source code files.

I agree with Coyote X that we need a road map. We haven't defined our hardware needs yet. Should we use the smallest processor that will support a basic FE gauge for V1? Or should it be extensible, with enough peripherals for everything we can imagine? AVR or PIC processor? (folks have spent money on both already) I/O's. Timers? Memory? Are we going to have boards etched so folks can build their own? Use existing boards? (Arduino or other) Bread boards? LCD or Palm? RS232 or USB?

If we don't know where we're going, we'll never get there.

[s2man]

It looks like several people voted while I was responding to Coyote X. I too vote for *duino, for several reasons:

1 - it's available assembled for $33 or in kit form for $24. So anyone who can afford a car can afford one.

2 - it runs the ATmega168, which four of us have voiced preference for, and one has already purchased. Which has 23 i/o points, up to six analog in and three out, three timer/counters, PWM, and more. This should do almost anything we desire.

3- apparently, the programmer in built in.

4 - it's a standardized platform, and we can move right on to programming, instead of designing circuit boards.


Lostcause: the timer/counters are on digital inputs, not analog. But Coyote has that covered in post #18. I'm sure he can set whatever threshold we want on the input board. We'll just need to count the pulses and the widths.

[MetroMPG]

I just got your username "s2man"... Stew. *smacksforehead*

[dcb]

re: post 18, I don't see how you can have a rising and falling trigger and a programmable /directional threshold. Maybe the AD comparators come into play there?

re: 454 in a fiesta, LOL if it was cheaper/easier and quicker to market, I'd be all over it
The *duino is something of overkill in itself (and I don't think we have a handle on the actual hardware costs yet). FYI, elmscan 327 adapters use a PIC18F248 and the scangauge uses a pic18f458 from microchips. Also I just found and bought a 323 (iso/japanese obdII) elm scan adapter for $20 cuz I'm all over this palm thing for my 4 wheel rice burner

I didn't think the exercise in teaching the *duino to process a fuel injection and vss signal would have been a complete waste of time however. Indeed, without being able to do that the rest of this is worthless. It makes a most logical starting point, while we are waiting for someone to tell us what the roadmap is supposed to look like or whatever we are waiting for Certainly what is learned there can be applied to PICs to some degree as well if that is needed to get the component count and costs down or if it needs better performance.

[diesel_john]

on the KEL computer i am using if am cruising at 20 MPG, and i pop it into neutral and coast engine on, it continues to update the display @ 20 MPG for about 4 more seconds and then goes to 45 MPG in a couple blinks. Then when i pop into gear and apply power the reverse happens it updates 45mpg for 4 sec and then goes back to 15 mpg or whatever. So the display is updating 5 times a second but the processor is giving it the same input for 4 sec.

question is: in you'll's design can that averaging work more like a stack(throw away the oldest sample and add the newest)(overlap processing), rather than a block (sample for 4 sec. display new result). just curious.

[dcb]

I was thinking a one second refresh time was sufficient for now.

And are carbureted vehicles out of scope? I could sure use some help there. Would putting a mass airflow sensor and a o2 sensor on my bike help? Well, it would have to be the expensive type of o2 sensor so forget that.

Edit: maybe a map sensor and a temp sensor and an rpm signal would at least give the PIC/stamp the airflow, and could be tuned to simulate accelerator well discharge when the pressure drops without the rpm dropping and could get reasonably close to guessing the fuel consumption. Lots o sensors sitting in the junk yard...

[Coyote X]

I think we could do this with a 12c509 if we wanted as cheap as possible, it would be a pain to code and have no expansion possibility but we could build it and a 3 digit lcd display for probably $10. (not that I can remember what i/o pins it has, it has been a while)

I think if we can get the hardware cost around $50 that would be a reasonable point. The ATMega series has a huge possibility for expansion and also we could do away with the *duino and build the circuit with just the 168 chip if someone wanted to have a surface mount compact system built. The development board could be optional for the people that just want a mpg gauge and aren't interested in future expansion.

If I was going to do the injector sensing. I would first cut the voltage down to 5v using a zener diode. That will give you a more or less 0v/5v signal. The signal could be cleaned up with a few additional components if necessary. The easiest way to do it would be set 2 pins to interrupt, one rising edge and one falling. Use those and a counter to figure out the injector open time. True duty cycle could be calculated but it really isn't as important as injector open time. I would probably let it go through 3-5 injector firings adding the open times together to use in a calculation. A metro has 3 injector pulses per 2 revolutions so that would still be a lot of calculations per second. Averaging 30 would still give a pretty fast response for the display.

The VSS signal is always so many pulses per mile. Something like 2000 pulses per mile is typical. Cleaning up the signal so you get a digital 0/5V would be the best in my opinion so the avr could just use an interrupt to process it. That would be much easier than doing an A/D setup and monitoring the voltage for the pulses.

That will save the A/D inputs for future expansion to monitor the analog sensors available on a car. But for V1.0 a good expandable menu system and basic functionality should be the goal. So before any hardware is totally settled on a rough idea of the roadmap through V2 or V3 would be nice.

[dcb]

Yah, we are only going to look at one injector if injector pulses is the game.

And I whole heartedly agree that edge triggering a timer event is the way to go if it can be done in a fairly standard way and doesn't ramp up the cost/complexity. There should be a lot more cpu cycles left for doing other things if it can be done.

But I think $10 dollars makes a much better target than $50 (especially since I'm putting together the equivelent of a scangague with source code control for $20), and it NEEDS a resettable trip, otherwise how will you ever calibrate it if it can't keep accurate track of fuel consumption and distance over a tankfull of gas.

So I'm making the assertion again that V1.0 has an instant mpg AND a trip mpg that can be reset, and if you have to change the program and reload it to calibrate it, that is probably OK for V<1.0

[s2man]

Originally Posted by dcb