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

[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

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?

Sorry, I didn't mean to imply post 18 had the situation covered. What I should have said was, "Since we have to condition the signals anyway (see post 18), I'm sure Coyote can convert that analog signal to discrete for us on the input board. Then we can use the timers and counters...". It seems from post 58, my confidence in Coyote was founded.

If we go with a lightweight PIC chip for the FE only gauge, is there a PIC platform similar to *duino to make later versions affordable for end users? We will want the code to be an easy port from V1 to Vx. Perhaps an ATtiny24? ($1.91 ea)

12c509 doesn't have eeprom data space. We'll need that for trip logs.

I"m fine with changing the program and reloading to calibrate. If someone has the skill to build a board and install the software, surely they can edit a file and reinstall.