Instead of vacuum gauge: multimeter on MAP sensor

[cmj]

Kinda bringing this topic back from the dead, but I thought of the exact same thing (using a MAP to gauge load) just minutes before I decided to register on this forum. I'm in super nerd mode right now (that state of mind that gets you tinkering, and nothing else gets done) so I haven't created an introduction yet.

Back on topic, I had an arduino duemilanove laying around that I was ultimately going to convert into an MPGuino, but upon further thought i'd like to get one of the mini's and run a remote display for ease of installation. Freeing up my main 'development' platform, i threw some LED's in a proto-board, hooked up some wires, installed some resistors and came up with a nice little bar graph that shows me how i'm doing engine load wise. As of now I don't have an actual vacuum gauge to determine exact kPa, or HGpI (however you choose to measure your vacuum) so I can't determine an actual scale. I've calibrated the code to what I think is the best 'load' on the motor for FE and when I punch it, the meter goes red, and when I'm idling or cruising at a good load it goes green. Spirited driving puts me in the yellow zone, so the apparatus does give me a good visual of engine load. I'll take videos of it tomorrow in the daylight. My hopes for this little project is to implement a big bar graph into the MPGuino code that allows you to set your desired optimal load and display it for you in some kind of pretty format.

[gone-ot]

...pictures and results?

[cmj]

I honestly haven't stopped tinkering with it long enough to take pics. As soon as I got the concept working with the Arduino I wanted to see if I could simplify it. Scrounging through a parts bin yielded a 555 timer, some capacitors, and some LED's. Utilizing the 555 as a bistable circuit allowed me to light a green LED under a specified load/current, and a yellow LED over the same threshold. I liked how simple and small the setup was and there was very little noise due to a later added capacitor.

Today as I was driving the 70 miles up to Ball State University to see my lady friend on her birthday I was tickled that the gauge was so simple and effective, but as soon as I picked out a semi to draft up I69 with, I got to thinking about how I could accurately gauge the effectiveness of the draft. When I get home Sunday, I'm going back to the arduino and a nice LED screen to show MAP % as well as TPS % so I can gauge how effective at saving fuel my current driving is. Once again when I get around to buying another duino, and putting an MPGuino setup together, I would like to implement this setup as a screen.

I will make a thread with my findings and some MAP and TPS scales when everything is concrete. It's just hard for me to believe noone else has went down this path as well. FE is greatly dependent on engine load. Some say aerodynamics is key, but a smoother airflow doesn't get you more MPG, it's taking LOAD off of your vehicle that does. A lot of cars come with the sensors already in place to show you how you are driving, I'm just trying to use them to my advantage!

[gone-ot]

...we inveterate tinkerers are...well...inveterate at tinkering!

[dcb]

OP is on a very productive path though, I wouldn't abandon the atmega platform for 555s though, the atmega will make a lot more interesting optons (software logic and lots of inputs/outputs).

I did however do some rough "calibrations" with an arduino and a map sensor and a brake bleeder here for a starting point http://ecomodder.com/forum/showthrea...nsor-5208.html

[cmj]

I don't know if you are referring to me as the OP but I'm not abandoning the atmega platform, I just look for ways to cut down on "moving parts" I'm moving back to the dev board. I can't wait to get home on Sunday to play with this. My wideband setup that was on the race car had a 5v o2 output for tricking stock ECU's into thinking there was a narrowband sensor in line. Once I get the MAP and TPS sensors sorted, I think i'm gonna look at adding that to the board. The whole thing could possibly end up being an add on unit to the MPGuino, because as it looks this is going to take up some space that the MPGuino doesn't have.

[dcb]

The other thing about these microcontrollers is that it can replace hundreds of "logic" ICs and discrete components and can really reduces the parts count dramatically, for reduced hardware costs. I don't see any real benefit to hardwiring the logic in chips when it can be in firmware, for this sort of application anyway.

Parts count is
atmega 328 (perhaps put the lilypad bootloader on it if you don't want to use a crystal or sort out the nitty gritty)
5v regulator
electrolytic capacitor
handful of leds and resistors

and thats it, for a relatively simple led display of vacuum.


FYI, the guino does have available 3 available adc ports and some coding room with a 328. Hardware wise it is trivial to hook up the map signal (or tps), you just hook it up to an available analog port, problem is getting over the software development hump.

[bobski]

Would it be possible to include the I2C library and free up the requisite pins if they're being used? It would make hookup to any number of remote devices (such as an SAA1064-based bar graph or numerical display) a four wire affair... Two for power/ground, two for data.

[dcb]

SAA1064 is an interesting looking chip, yah certainly it is possible. $2.50 chip that you can control 32 LEDs with a 2 wire interface has it's applications. I don't like that i2c uses 2 analog pins though. But for the "simple" 7/8 bar Vacuum gauge it is not necessary since the chip can handle that load and has the pins to spare in a standalone unit.

You could also implement a standalone gauge bar graph with a couple LM339,s that is what is used for my cheap electric scooters "dashboard", to indicate battery voltage and throttle, but the atmega is still one chip and is hardly expensive and is infinitely more flexible. Of course there are tons of other microcontroller chips out there too, but arduino is a good starting point.

[bobski]

Yeah, analog pins are in short supply, but I2C uses device addresses so you can put many devices on the same two pins.
There are some inexpensive I2C general-purpose IO expander chips out there as well, so maybe the buttons (which monopolize 3 analog pins) could be offloaded to one of those? Many such chips provide an interrupt output that goes true when an input changes, and stays true until the chip state is read. Maybe that could be fed to one of the MPGuino's interrupt pins, rather than the injector pulsewidth measurement using them both? Anyone know why that was done?