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.

I don't know what liberties you are taking with the schematic or the code, but mpguino vss was designed to use a change interrupt on pin 23 which triggers on both a rise and fall. I point a finger at your lack of understanding how it was designed/works :)

I'm sure you will complain about it though, and have some suggestions for "improvement", at which point I will have to explain that both the edge detection interrupts are being used to distinguish the rising and falling edge of the injector pulse. ;)

Damn newbies. Be a good engineer and look at the schematic and the code and the atmega datasheet please and don't be surprised that making random changes to the code or circuit can break things. There is no hardware OR code ivory tower on this project, they work as a unit. If yours isn't working right, there is only one direction to point.
source data sheet
http://opengauge.googlecode.com/svn/...no/mpguino.png

I'm starting from scratch on both counts. I've borrowed a few hardware design elements, but the code is all new as far as the MPGuino project is concerned.
Unlike the MPGuino, I'm using one interrupt input for the injector signal with the interrupt being called when the signal changes (rising or falling edge). The interrupt code then checks whether the pin is high (just hit a rising edge) or low (just hit a falling edge) and executes the appropriate chunk of code to start or complete the pulse width measurement (adding the measurement to the total dispensed if completing), and/or calculate the period of the pulse cycle. Those two bits of data let you calculate total fuel dispensed, engine speed and duty cycle of the injectors (instantaneous flow rate).
The second interrupt input is dedicated to the VSS and only triggers on rising edges. It's code is a good bit simpler, calculating the time period since the last rising edge (used for instantaneous speed) and incrementing the VSS pulse count.

My latest code, now calculating trip and instantaneous MPG:
http://dl.dropbox.com/u/9882625/MPGshield_0.2.pde

[edit]scratch that. trip MPG is just sitting at zero. :/
probably some stupid programming bug.[/edit]
[edit2]fixed.[/edit2]

Just FYI, I had problems with that approach, and decided that using separate rising and falling interrupts was the most accurate way to monitor the injector pulse. The vss can count x2, not a problem. You are throwing a lot of well tested and considered code/hardware on the floor.

So I guess I will wish you luck at this point :) Just don't complain and point fingers please.

Code that I know nothing about, have met nothing but frustration when trying to read and therefor can't easily work on.

Could you elaborate what the problems were?
Is it the "CHANGE" interrupt wasn't available in the arduino at the time?
Time spent determining if it was an up or down change?

Your implementation is widely tested and obviously works well.

I am hoping to bow out of this discussion at my first opportunity, as the code/design makes perfect sense to me already and I don't see the need to go rearranging everything :) nor do I have the time/inclination to discuss it, or re-live it, here is a FREE working example, what more could you ask? Don't break it then blame it is all I ask.

It could be doing a read in an interrupt was part of the problem, I don't know for sure. It wasn't reliable though. Having a tight interrupt routine on rising and one on falling seemed to fix it. Interrupts need to be tight, signals can bounce a bit, etc.

Speaking of signals, I noticed an entertaining side effect of the zener setup: it acts like a floating input when disconnected from the car. If I hold the hookup wire in one hand, it registers a 52.8 MPH speed (with associated odometer crawl). Using my other hand as an antenna, I can get much higher values by reaching toward various electronic devices. For instance, the LED cabinet lights I use at my desk register speeds in excess of 3 miles per second. If I touch my (grounded) computer case, it drops to zero. A 1M ohm pulldown resistor in parallel the the zener seems to fix it. I suppose most cars already have a pulldown in place so it's a non-issue. It's kind of handy for desktop testing actually.

note R6 in the schematic above, only a problem for reed switch vss. Hall effect don't float nor do real injector signals.

FWIW, I just saw this topic after I posted my feeble attempt at re-railing this Arduino project back into its Arduino roots... http://ecomodder.com/forum/showthrea...ace-16556.html - not meaning to step on hard-working dcb's toes here, but I mean, come on, thousands if not hundreds of thousands more capable, productive, and eager people have Arduino platforms on their desks than have Atmel AVR "core" systems... and the current code (as well as all my mods to it) have worked and run just fine in the Arduino IDE... plus, my prebuilt MPGuino has been running on a stock Arduino bootloader ever since I applied my first "mod" to the MPGuino code (had to flash the bootloader first to get it to take the upload). It's just project-suicide to keep forcing it further and further away from the Arduino platform, which in my experience is perfectly rock-stable and very well standardized compared to free-wheeling and non-standard raw AVR code. Maybe you had a bad chip? I dunno, but I think the project would be much more active and accessible (as opposed to 1/2 a forum page of posts a month) if more people with Arduinos could contribute...

Glad to see I'm not the only one that's been thinking about this.
I'll try to get a schematic of my current hardware drawn up this week. It's nothing particularly impressive, but should be a good starting point for discussion, further development and revision.
My code works fine on IDE 0021, uses standard libraries, has basic functionality at this point and should be easy to adapt to different hardware designs. Using different size displays, multiple displays and even graphic LCDs (which I just started playing with yesterday, after picking up a couple of $10 128x64 units) should be a simple matter of writing info pages that make full use of them.
The problem with typical graphic LCDs or more than one character display being the number of IO pins they demand. Serial interfaces can cut down the pin count, or one can go the opposite route and use a board with more IO pins - an Arduino Mega. AFAIK, the code should work fine on any Arduino compatible board at this point.

It was not a bad chip, it was bad process, conflicting mentalities (folks tend to peter out after the creative parts, leaving something of a mess), too much effort. Have fun. Please don't call it mpguino v2 though though because there is a "production" version that constantly gets confused in the discussions.

user: "My mpguino broke!"
me: "what is the problem"
user: "I tried a pic18f instead because it is a better chip"
me: "Doh!"

Understandable... sometimes you've just gotta smack a newb upside the head though. I've dealt with managing my own project (google FalconFour's Ultimate Boot CD), and dealing with user error has always been a fun one... it's pretty easy though when you realize that for every 1 user that's complaining about some obvious user error, there are also about a hundred other people silently enjoying your work every day and thanking you for it in their heads :) Not saying I tell myself that or something (ooh, ego stroke! lol), just saying that's what I find for any small-group effort I find online. Just let the guy know they're working with an unsupported configuration, help the guy out if possible (e.g. "that's not supported, but duh, you plugged it in backwards"), and don't think too much of it!

Mmmkay... Current hardware:

http://dl.dropbox.com/u/9882625/MPGs...1Schematic.png

well i like what it does just wish it expanded where I could have a tach on the screen too. and you guys make my head hurt reading this stuff.

I like the voltage buttons, this would free up 2 inputs :D

bobski

If your DX is stock DPFI your going to need to monitor both injectors. This of course would require using one interrupt per injector rather then the current arrangement of both interrupts to monitor one injector.

My thought on using one interrupt to capture an injector pulse is as follows. A pair of one shots are configured to trigger one on the rising edge and one on the falling edge of the injector pulse. The outputs of the two one shots feed an OR gate producing a signal that has a pulse on both edges of the injector pulse. This signal is feed to an interrupt input. The raw injector pulse is also fed into another digital input. The interrupt service routine is called for each rising and falling edge of the injector pulse and simply needs to check the state of the raw injector signal on the other input to determine what edge called the routine. This approach still requires two inputs to monitor an injector but only one interrupt per injector.

For the input zener diodes I would go with a lower voltage then 5.1 volts. Anything between 4.0 and 4.5 volts would be a better choice. The purpose of the zener is to limit the input voltage below the supply voltage so something less then 5.0 volts should be used. The input logic levels on the MCU are very low with anything over about 1.0 volts being recognized as high. A zener as low as 2.0 volts should work just fine but there is no need to go that low.

Mike

It's not. Over the years, I've gone from stock DPFI D15B2 to a D16A6 with DPFI, to D16A6 with MPFI, to a D16Z6 with OBD-1 conversion.

Agreed, but in practice the voltage never hits 5.1 volts. When I bench tested the circuit with a 50K resistor and 5.1V zener, I could max out my power supply at 31-point-something volts and the voltage at the test point (the uP input in practice) only hit about 4.9V. I believe the rated voltage is at the diode's rated maximum current. I was using a pretty hefty zener current-wise, so the trickle of current through the 50K resistor at 12V was nowhere near that limit.

I wish I could say it was my idea. ^_^

I wasn't quite following before, but I get what you're saying now. Use the interrupt as a "hey, something changed" input, then have the ISR check the various inputs to see which one it is. From there I guess it would take appropriate action, then set a variable or just a bit so it can figure out what's changed next time it's called.
For every injector (or other pulsed input) you would have a pair of one-shots outputting to that one interrupt line, and run the injector signal itself to a dedicated general purpose digital input so the ISR can check it.

Yes, that's the concept. The ISR for the first injector would simply combine the current injector open and injector closed routines with a bit read and conditional statement that determines which routine to execute. I'm pretty sure it could look something like: IF (input bit) THEN (injector open routine) ELSE (injector close routine).

Of course this would be a pointless exercise that adds two chips unless the second interrupt is put to good use.

Since you are working on a general re-rendering of the concept you might try and add DPFI support. It would be a significant contribution and you would be a hero to a number of people with throttle body injection.

Adding support for a second injector would require a second set of injector calibration values and summing the output of both injectors for total fuel flow.

On another topic. If you want to really keep the inductive kick of the injector away from the MCU you can give the input side of the opto it's own ground wire back to near where you pick up the injector signal, presumably at the ECU.

Mike

I like to think the VSS is "good use", though I suppose it could be moved over to the new interrupt expander setup. Keeping the VSS and injector(s) on interrupts lets the non-time-critical code (such as variable calculations, display rendering, button handling and whatever else people come up with) run amok without affecting the accuracy of those core measurements.

I'll see what I can do.

Yeah, the software side seems pretty easy: A check-what-changed code snippet that triggers the appropriate chunk(s) of code in the interrupt. I've pretty much already written the chunk(s), I would just need a few additional variables to differentiate the two injectors.

Yeah, I thought about that. The ground line you get on the Arduino's headers is uninterrupted back to the negative external power terminal, which would presumably be connected to a ground wire near the ECU. A second wire might help with noise rejection (not really a problem afaik), but I don't think the shared ground is going to cause problems protection-wise.

I thought of an alternative circuit design for the interrupt expander last night. Each input would have 1 bit of a D-latch and an XOR gate. The data input to the latch would be the signal you want to watch, and the latched output would go to one of the XOR inputs. The other XOR input would be the raw signal. That way, the XOR would go true any time the input doesn't match the data in the latch, which would trigger the interrupt. When the interrupt gets triggered, part of the routine would clock the D-latch which would make the data and input match up again. That would make the XOR go false and clear the interrupt signal until the input changes again. It's still two chips, but those two chips could serve multiple inputs. A 74HC86 quad XOR and a 74HC373 octal D-latch costs about a dollar together and would serve 4 inputs. Add another XOR chip and it would serve eight (if there were enough free pins on the Arduino).
After looking around a bit, I found some IO expanders use this same setup to drive their interrupt outputs. Using a single-chip IO expander would be nice, but they're all serial interfaced which is probably too time consuming for an interrupt routine.

Current code, as posted in the Release Two Workspace (/Fork name TBD) thead:
http://dl.dropbox.com/u/9882625/MPGshield_0.3.pde

I had been busy with school, so not much progress, but here's the current state of things:
http://www.youtube.com/watch?v=6JS2qwB39S8

Holy... frickin'... lover of Jesus. WOW. That is one SERIOUS pro setup you've got there in that video. Yikes. Makes me feel kinda insignificant here with my most elaborate logic device being my Arduino (programming it to decode whatever logic I need to read), and my most elaborate analog device being my $50 kit digital oscilloscope based on an ATmega64. My breadboard setup is a modded Radio Shack Electronics Learning Lab (modded with an LCD, internally wired to 14 breadboard rows)... that's why I'm leaving all the monitoring and calculation code in MPGuino alone in V2, because I don't have the equipment to test any changes to that part! =P Heck, I'm even having trouble figuring out how I can test the data display routines outside the car if all I can show is "0" ;)

So are you planning on building a new "device" for MPGuino (the hardware side, that is), or just working on software?

Eheh... Thanks. NKC has had a deal on the two (DS1052E and DG1022) for some time now, so I convinced my parents to pick up the bill as a graduation present. I've been wanting a decent oscilloscope since I was like 10 or 11 years old. But yeah, I had one of those same oscilloscope kits before this (128x64 display, 3 switches, 7 pushbuttons, PCB front and rear panels). I pretty much learned surface-mount soldering on that kit. It's affordable and decent as a basic scope if you have nothing else, but you can do so much more with a decent commercial bench scope.
Yes, I'm building new hardware. The above hardware is very similar to the MPGuino, but I wouldn't say it's "for MPGuino". Now that the basic framework is laid out, I'm leaning toward a design with a graphic display. Code-wise, it's pretty much just a matter of including the glcd library and writing the code to draw the display pages. Hardware-wise, graphic LCDs that are compatible with the glcd lib take up way more IO lines than character displays, so a mega-style Arduino board is probably a necessity. There are serial-controlled graphic displays out there, but it seems that would require pretty heavy modification of glcd, which is beyond my present abilities.

I am jumping up and down in my seat. I am a complete Arduino dummy but download a sketch you shared, hit upload and it LOADED!!!!!

I am now going to assemble the hardware on a breadboard for further testing!

YOU ROCK!

Edit: I should have read more, I assumed this was the MPGuino.

I'm totally lost. I have an Arduino Uno and truly have no clue how to get the MPGuino code loaded on it.

I must be confusing the Uno with other hardware. :(

Nope. This was my re-hash of the MPGuino.

Could be. I haven't looked at it in quite a while, but one of my complaints about MPGuino was that it's not compatible with the Arduino IDE. IIRC, the creator ditched the Arduino bootloader to free up space in flash and (I think?) make it less prone to bricking itself (re-writing its flash while in use). I can understand and respect that, but it means you need a dedicated ISP programmer to get new code onto the board.
The Uno (and subsequent boards) replaced the FTDI USB-serial chip with a second native-USB AVR processor which acts as a programmer and/or serial comm chip. I'm not sure whether or not that second chip will satisfy the requirements of a dedicated programmer.

Anyway, good luck and feel free to play with the code I posted.

Wow thank you for a quick response! It seems getting any help with MPguino these days is very hard.

If I follow the schematic below will this work with your code?

If not is there a schematic somewhere I can use with your code?

Thanks again!

Page 3: link.
Don't bother with the I2C stuff (attached to analog 4 and 5), it's not used for anything important.