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