MPGuino shield: Fork? V2?
 

Hey folks.

I've been following the development of the MPGuino for a while now. It's a great little device, but I've had some complaints about the hardware and software design (what can I say? I'm an engineer ^_^). Since the software end only seems to be getting worse IMO (no arduino boot loader at all?), I thought I would take a crack at making a new version of both the hardware and software that incorporates some of the suggestions made here and is fully compatible with the current Arduino IDE.

So far, the hardware is functional in the form of a Freeduino through-hole solder kit board with '328 controller, a protoboard with a standard 16-pin character display connector (PWM backlight, potentiometer contrast), a 16x2 character display (which can be swapped out for other colors, larger character count, etc.), optoisolated injector and VSS inputs (no more playing with voltage divider resistors), four control buttons that use a voltage divider setup to occupy just one analog input pin, and an I2C port. I put an I2C EEPROM on the protoboard as well for the sake of trip logging, but I'm not that far along yet in the software department. That leaves digital pins 0, 1, 9 and 10 open, as well as analog pins 1, 2 and 3 for any future additions (temperature sensor(s), a pitot tube air speed sensor, automatic display dimming via a light sensor, whatever). Really, the sky is the limit if you consider the I2C bus. Since this is all mounted on a shield and Arduino compatible, its easy to swap in different hardware (such as a Mega board) if your development needs require it (driving a parallel graphic LCD or whatever).

On the software side, my compatibility goal means using existing libraries where possible so as to maintain compatibility with the widest range of hardware and to facilitate any user modifications and additions to the unit.

I'm only a couple of nights' work into the software, but the display's working (really just troubleshooting wiring and loading up liquidcrystal.h), it's reading the buttons, the interrupts for the injector and VSS are working and I have a functioning framework for switching pages and providing unique button functions for each page. That should lend itself nicely to hierarchical menu systems, confirmation dialogs and such.

For now, I guess I'll write some data display pages, hook it up to my CRX and give it a whirl.

I would like to *ahem* borrow the big numbers code from the MPGuino, but I'm not sure how compatible it is with the standard liquidcrystal library (to be honest, I haven't even looked at the code). If anyone's interested in helping out, a standardized port would be very useful.

I've never had a genuine MPGuino to play with, so if someone is willing to list the functions and information it provides, that could be useful for whipping up the first pages.

I'm open to suggestions, so long as you're willing to discuss and answer questions about them.

A few pics of the hardware and a vid of my button test page:
http://dl.dropbox.com/u/9882625/MPGuinoShield_0180.jpg
http://dl.dropbox.com/u/9882625/MPGuinoShield_0184.jpg
http://www.youtube.com/watch?v=iE8Jccv7hTY

Links to previous and current versions of working code:
http://dl.dropbox.com/u/9882625/MPGshield_0.1.pde
http://dl.dropbox.com/u/9882625/MPGshield_0.2.pde
http://dl.dropbox.com/u/9882625/MPGshield_0.3.pde

I think some folks have used the CPP file directly in arduino, though I don't really endorse arduino for "serious" applications based on many first hand experiences.

I've seen the bootloader corrupt the program on powerup, and it takes 2k usually and slow startup. ISP programmers are available for, well nothing if you have a spare parallel cable and port, or can teach an existing arduino to be a programmer. But decent ones are available for $10-$20 and make programming fuses and debugging possible.

No love lost here with the bootloader.

Also Arduino is a moving target, I had to bypass much of arduino to do the critical functions, and those "implementation details" got clobbered with new releases of arduino (in fact got clobbered within hours of the first mpguino release). So arduino is ok for playing around with, but fyi I'm not planning on investing any more serious time in it, though I do occasionally prototype in it.

AVR GCC is much much more stable.

So I can use the MPGuino name? :D

Well I took it for a test drive and it looks like the optocoupler draws enough current to make the ECU throw a VSS error code. I'll try a higher value current limiting resistor and see what happens.

Is there any serious advantage of using the optocoupler over the zener diode? I'd imagine it would be much safer for both the car and the arduino, but that said it doesn't seem the zener diode way has failed people yet.

I'm just wondering if its bleeding off the vss to ground at 5.1v will this cause odo reading errors?

I don't know about "much" safer, or even safer at all. The signal has to go through a 50k resistor before it even sees the zener/CPU on the mpguino.

Many times people use optoisolators (and other things) dogmatically, even though driving that internal LED to a useful level can be more load on the circuit being monitored than a much simpler arrangement (i.e. resistor/zener).

Additionally optoisolators can introduce different asymmetric delays, depending component/manufacturer/circuit. So the table of car settings might not be valid with such modifications.

So with no hint of more "protection", plus signal drain, and guaranteed costs and complexities with optoisolators, what is it we are trying to make safe? The CPU? Millions of people spend more on a latte every day than the cpu costs.

re name: I'd rather be able to discern between homemade guinos and the "official" design (or variant designs), so call it the bobguino I guess :) Something that will distinguish in normal conversation, mpgshield?

MPGshield sounds decent enough.

Yeah, as soon as read off the VSS error code I realized what was happening and thought to myself that it's a basic 5V or 12V on/off sensor signal... It's already more or less conditioned for microprocessor use which makes the optocoupler overkill.

The injector on the other hand is a big inductive device, and we're tapping directly into one of its power supply lines. Inductors like to produce big voltage spikes under the right conditions (conditions the ECU probably protects against, but none the less)... For instance, the ignition coil(s) that fire the spark plugs rely on that inductor effect. Thankfully, being an electrically heavy device means the ECU doesn't notice a few milliamps to drive the optocoupler LED. In fact, the way the injector is wired up in my case (constant power, switched ground) means the switched-power circuit for the optocoupler LED shows up as a few milliamp parasitic draw through the closed injector (nowhere near enough to open it or hold it open), and as zero draw when the ECU opens the injector.
As for timing delays, I hooked the opto-coupled injector input up to a function generator spitting out TTL levels (5V) and the interrupt routine's pulsewidth output was accurate up to about 20KHz (down to ~50us) over the function generator's full duty cycle range (5% - 89%). The same bit of code has done better in the past, so I'm not saying there's no effect, but it's negligible when talking about a signal that will never break 100 Hz (well, unless someone sticks this on a sport bike or a jet engine). Also, according to the optocoupler's spec sheet, response times improve as emitter current goes up. Since emitter current is dependent on the current limiting resistor and input voltage to the circuit (12V when installed in a car vs. the 5V I was testing with), its effects should be still more marginal in actual use.

As for the cost of replacing an ATMEGA168 or '328, yeah they're not that expensive. But we're not necessarily just talking about a '168 or '328 chip anymore... Some Arduino boards (both clones and the official boards) use surface mount chips that can't just be popped out of their DIP sockets and replaced. The Arduino Uno is being manufactured in a DIP version, but supply issues resulted in them more recently producing a model using a '328 chip in the ball grid array surface mount package. Leaded surface mount chips can be handled with fairly standard soldering tools. BGA requires a hot air station.
What I'm getting at is that we're not necessarily talking about replacing just a $5 chip anymore, we're talking about a $20 - $60 Arduino board.

So yeah, I'll try the higher value resistor on the VSS line later today and ditch the optocoupler all together if the ECU still isn't happy or it causes some kind of signal error (I'm reading both pulse count and frequency - distance and speed).

Here's the current code if someone wants to play with it:
http://dl.dropbox.com/u/9882625/MPGshield_0.1.pde

here was an opto experiment before I had a decent scope:
http://ecomodder.com/forum/showthrea...tml#post106855

I had to subtract an 1100 additional microseconds per injector open pulse to get the right reading. The guino read .77gph instead of .53gph with the opto circuit in place. I might have screwed up the experiment trying to be protective of the opto though :)

Possibly. The absence of a data sheet for the opto you used in your experiment bothers me too. The input side of my opto circuit is just a resistor in series with the LED, power from the injector line and ground to the arduino (which is also chassis ground when plugged into the car). That means the LED will be on when the injector is closed, but that's easy enough to flip around either on the receiver circuit side of the opto or in code.

Okay. I went from a 2.2K resistor to 10K and now nothing gets through the VSS opto. It's going back in the parts bin.
Now to hunt down a 5.1V zener...

Okay, the zener setup works fine on the VSS, but I think the MPGuino may be double-counting pulses. I got 81700 pulses per 20 miles, or 4085 pulses per mile... about half what the wiki says I should be seeing. I've got slightly larger than stock wheels on my car, so that probably covers the remaining 30/15 pulses per mile. I point the finger at the MPGuino code since it seems far easier for it to be counting both rising and falling edges than my interrupt to be triggering on exactly every other pulse.

My injector microsecond numbers seem within reason as far as the wiki goes... Around 30 MPG for the test trip. Engine warm up, it was raining, most of the trip was up and down I-95 at a fair clip, and I experimented briefly to see what the maximum injector pulse width is (about 12 ms). My back-of-the-envelope calculations say i should be using something like 230 s/gal (rather than 200), but calibration will have to wait until I figure out persistent injector and VSS counters.