Super MPGuino?

[gtkid2002]

I'm pretty sure I already know that it will, but I don't want to drop thirty five extra bucks and find out "Hey, you're an idiot!" later.

So, because of my circumstances, I need a speedometer a little bit more than mpg gauge. Because of this, I don't really want to use the standard MPGuino. I'm not sure if anybody has built an mpguino with an Arduino Mega, but I think I might. I'm planning on using the graphic 128x64 screen. I know that's going to use up more memory, part of the reason why I want to use the Mega.

Now, besides the dedicated speedometer, I figure I'll have some room for something else. Suggestions?

Would a multi-injector input improve accuracy?

I know this also rather delves from the idea of the Mpguino, but would there possibly be room to add a twin axis accelerometer if I had the Arduino Mega and have it display on the screen? More or less like this one. There might be some way that I could have it tell when I'm going up/down hills and put that into a note or something. That or when there is extreme acceleration or braking. I could use a tilt sensor, but I would rather the accelerometer.

If there's room with the Mega, I could possibly save up and get an sd card adaptor thingy and have it log my mpg with time and date stamps. Record record mpg for trip, lowest mpg for trip, average for trip, maximum distance for maximum/average/minimum mpg with full tank, etc. A few more random features that could be recorded to sd card so I can be nit picky and stuff.

I know that skelly has a thread up about modifications that s/he has done to their Mpguino, but considering I'm not even a novice at coding, I think it's a good idea to ask for some opinions/input.


And yes, I know I can buy one pre-assembled, but to tell the truth, I love tinkering, and would much rather do this in my own way, despite how complex the entire thing may be.

[wikityler]

With the power of a mega I'd be tempted to go as far as a digital dash. Have you looked at ladyada's ATmega328? It might be more reasonable if you don't need all the extra gpio on the mega.

[dcb]

the atmega 1280 is a lot different than the atmega 168, it most likely will not work, as-is anyway. The 328 is much more 168 compatible.

FYI, I don't see much return in monitoring multiple injectors.

[gtkid2002]

wikityler - Yeah, I'm a n00b. I hope by gpio you mean pins (something something I/O?), and if so, then yeah, that's what I'm after. I'm hoping to add a lot of stuff to this, mostly gauge cluster related.

dcb - The multiple injectors was just an idea I threw out. If it would help make the gauging even more accurate, why not? But if it's not going to make much of a difference, who cares. I could possibly see the need of something like this on a V-8 that has the cylinder shutoff, but i'm assuming that would require a lot of code tweaking and a lot of vehicle-specific engine data.

I'm aware that the atmega 1280 is different, but wouldn't the coding still work so long as I adjusted the pin numbers as needed? Please correct me if i'm wrong, but I thought the code was exactly the same for all Arduinos.

I figure what I'll do is have the screen and a needle sweep so I can use the mpg gauge seperately. Or something.

[dcb]

If it were pure arduino then it would probably be portable, but I found myself fighting with the arduino environment early on to get the guino to do what I knew the chip could do but that "pure" arduino couldn't due to space/performance/absent & changing functionality issues.

Arduino is good at making simple things simple, and is a terrific introduction to embedded programming. But I have since abandoned arduino so I could get more functionality out of the same (at the time) hardware.

[Froggy]

It's only a matter of time before OBDuino moves to the Mega board... Currently the extra pins are very few... so add on's are very limited. There is also less room for new fancy features in the code. The Mega provides a lot more room to grow, but it has an even larger footprint...

The Arduino compiler compiles the same source code as per the destination board (Mega or other) so any internal differences between chip types should be transparent to the OBDuino source code and the user. (The pins may need to be reassigned but that is no biggy.)

[dcb]

Yes, life is simple when you just have to twiddle the uart or i2c ports

But that doesn't help 89 prelude guy.

[Froggy]

LOL. So true!

[nickdigger]

Originally Posted by gtkid2002

The multiple injectors was just an idea I threw out. If it would help make the gauging even more accurate, why not? But if it's not going to make much of a difference, who cares. I could possibly see the need of something like this on a V-8 that has the cylinder shutoff, but i'm assuming that would require a lot of code tweaking and a lot of vehicle-specific engine data.

As i understand it, you only need one injector pulse per cycle, because you are calibrating the # of pulses over an entire tank of gas. It makes no difference whatsoever to your calibration, whether you pulse once per 360 degrees (on the distributor), or once per cylinder. The value will either be 1 * N, or exactly X * N, where X = # cylinders and N = # times cylinder 1 fired over the calibration period.

You raise an interesting point with the cylinder shutoff option. Just throwing this idea out there, for comment by those who would know better than I:

Could each injector be tied to the single 'duino input line, by placing a protective diode onto each one? If so, your calibration and tracking would be based on the exact # of pulses, as required by 'shutoff' engines, instead of the once-per-cycle that most of us need. Would the diodes prevent the separate injectors from cross-talking or shorting each other out?

[dcb]

Yup, as long as the pulses don't overlap the diode thingy should work. But the guino is already within 1% accuracy, at least on some cars (my saturn is always spot on), so diminishing returns to start with.

The typical ECU only has one o2 sensor that it makes fuel adjustments with, so all the pulses should be the same length, typically. Not much to be gained by the additional complexity, generally speaking.

But for engines that actually do shut off cylinders (not many), merging the signals with diodes should do it, for the most part anyway. You can tap one injector that doesn't shut off and one that does and cut the usPerGallon in half, I think, hmm...

edit: hmm... went the wrong way with the usPerGallon, didn't I. Lesse... If you have the single injector hookup figure right, then hook up another injector, you will get twice as much injector open time even though the car is getting the same fuel, so you want to DOUBLE the typical usPerGallon if you are monitoring two injectors.