OBDuino Mega
 

Hi guys n gals,

Great work on MPGuino, OBDuino, etc. It's really cool to see Arduino being used as the basis of projects like this, even if they later diverge from the Arduino and become more self-contained. It shows the Arduino doing exactly what it should: providing a quick, easy, and cheap starting point for whatever your imagination comes up with.

Recently I've been switching my previous OBD datalogging / car remote management system over from running on Ubuntu on an Alix-1 to an Arduino Mega, and the OBDuino project has been very helpful in getting it working. I originally wrote my own code that implemented GPS datalogging and storage on a memory stick in a CSV file, but the OBD part of it was giving me problems. I started looking at the OBDuino32K source for inspiration and decided that it would be better to ditch my effort and implement the features I want in OBDuino rather than take OBDuino's OBD code and mash it into my existing code.

I'm coming at this from a very different perspective from you guys so I suspect you're not particularly going to care about what I'm doing but I thought I'd give you a heads-up anyway. This site is all about driving more economically and providing simple tools at the lowest possible cost to help make that happen, while I'm coming more from the rev-head side of town and, for this project at least, don't really care about trying to do this on the cheap. Instead I'm taking the approach of making it do as much as possible, regardless of the cost.

If that mentality annoys you then I apologize and I'll leave you in peace.

For those interested, though, I now have a slightly modified version of OBDuino32K running on an Arduino Mega.

http://www.practicalarduino.com/pics/obduino-mega.jpg

Sorry about the poor picture quality. I just borrowed a work colleague's camera-phone to take the pic but I can post better ones later.

Mounted vertically in the back left is the PCB out of an OBD-II/USB adaptor that has been modified to replace the 3mm LEDs with 0805 surface mount parts, and the FTDI USB chip has been bypassed to link the TTL serial interface on the ELM327 directly to a USART on the Mega (Serial1). The header for the OBD-II cable has been taken to a DB9 socket on the back of the case and I've made up an OBD-DB9 cable that matches the pinout of the standard cables you see around the place.

On top of the Mega is a prototyping shield that provides a handy breakout point for serial ports, status LEDs, controls, and the power supply. The PSU is based on an LM2940CT-5 which is an automotive-grade equivalent to the 7805, since a standard 7805 isn't rated for the 60+ volts that a car alternator can deliver into the loom in the event of a load-dump such as when jump-starting a car or if a battery terminal works loose. The LM2940CT-5 also has a much lower dropout voltage than a 7805 so it can maintain a clean 5V output even if the input drops as low as about 5.5V during cranking the starter. A 7805 can't maintain its output below about a 7V input. The PSU also has a huge capacitor on the input side fed through a diode, with a voltage divider in front of the diode feeding into a zener-protected input connected to an interrupt. This allows the Arduino to detect power-fail and still have a few milliseconds to take care of housekeeping chores like closing files on the USB memory stick.

The LCD is a 20x4 module, nothing special about that. I'm running it configured as a 16x2 though because there are strange artifacts when OBDuino tries to drive it as a 20x4.

To the bottom right is a Locosys LS20031 GPS module, which is quite nice because it does 5Hz updates. That's connected to another of the built-in USARTs on the Mega.

In the bottom right of the case is a Vinculum VDIP1 module loaded with VDAP firmware. It's connected via serial to yet another USART on the Mega, and provides a USB host connection for a memory stick like the 4GB one in the photo. The memory stick is formatted FAT32 and the VDIP1 lets the Arduino manipulate files and the filesystem directly, so in my version of the code it opens a CSV file and writes GPS and OBD values into it. The cool thing with this approach is that you can just unplug the memory stick, take it inside, plug it into your computer, and open the CSV file directly in a spreadsheet.

What I haven't integrated into this particular prototype yet is the vehicle control stuff that I currently have running in my car, which has a permanent 3G internet connection and various devices in it including an Arduino wired into the ignition system so I can start and stop the car via the Internet, and access OBD data via the net as well. If anyone is interested in seeing what I've done with that you can check it out on the Geek My Ride site at:

Jon's RX-8 - GeekMyRide

Finally, all this is being documented to be included in a book called "Practical Arduino" which will (hopefully!) be out in a couple of months:

Practical Arduino: News

My approach so far has been to add support for the Mega using #ifdefs in the OBDuino32K codebase. With my modified version it currently builds exactly the same as the official OBDuino32K mainline unless "#define MEGA" is put at the top, in which case it switches around a bunch of things such as the serial port to use for the ELM connection, interrupts for the buttons, etc. I haven't yet integrated my GPS, Flash, or emergency-shutdown code but that's the next step.

So, keep up the good work, and if anyone is interested in what I've added please let me know. Otherwise I'll just shut up and let you all get on with it.

"wow"

It's a bit embarrassing letting people see things while they're in progress, but just in case anyone is curious I've put my modified version of OBDuino32K up on GitHub. As I mentioned previously my approach with this is to try to keep it behaving exactly the same for standard 328P builds, while enabling all the extra features for a Mega at compile time by setting some flags. I've also separated out new subsystems into separate files for clarity so I don't pollute the original codebase too much.

jonoxer's obduino32KMega at master - GitHub

Right now it builds on a Mega with different pin assignments to allow the extra subsystems to operate, and the extra subsystems compile cleanly, but they're not activated in the main loop yet (except the command-line interface for managing the OBDuino from a serial console which does partly work). To use it you'd need a bunch of information about pin assignments etc that aren't documented yet but that will all follow. I only have a couple of days left to finish the first draft for the book so stuff should progress at breakneck speed.
--
Practical Arduino

GPS, memory stick, and command line partly functional
 

It still needs a lot of work but tonight I partly integrated code for GPS, the memory stick, and a console interface into the OBDuino32K code.

As of right now I can connect to the OBDuino via a serial console and perform filesystem operations:
* List files on memory stick
* Delete OBDuino logfile
* Display OBDuino logfile

I can also activate and deactivate logging via the console, and a button on the device itself also toggles logging on / off.

While logging is on the main loop takes a GPS reading once for every pass through and writes it into a CSV file on the memory stick. I'm not logging any OBD data yet, that's the next step. Time to stop for the night and get some sleep now though.

For the curious:

jonoxer's obduino32KMega at master - GitHub

Great work :thumbup:

Excellent to see some expansion using the project into new directions.

What problems have you seen when using the 20x4 display? Is it just left over data that does not get cleared? When does the artifacting happen (what screens are involved, where is the data...) Do you have any pictures of the artifacts?

Hopefully we can get the display corrected.

Thanks.

I'll make a video of it running in both modes so you can see what happens. The problem may be with the LCD module itself and I have a few other modules here I could try, but before going to all the trouble of unsoldering it I was also thinking of quickly substituting the LiquidCrystal library for the current hard-coded LCD routines and see if that makes any difference. Hopefully I can narrow the problem down a bit so we know if it's hardware or software.

In the meantime though I haven't been too fussed about it because it works in 16x2 mode and I've got enough to do with the GPS and memory stick code.

Cheers :-)

Jonathan Oxer
jon.oxer.com.au / twitter.com/jonoxer / www.geekmyride.org

Hopefully we can get the 20x4 working fine for you with minimal fuss (while you work on your GPS and memory stick code...) ;-)

Video of OBDuino driving a 20x4 display, with the first row OK but everything else stacked on top of each other on the second row:

http://jon.oxer.com.au/pics/OBDuino-20x4.avi

Cheers :-)

Jonathan Oxer
jon.oxer.com.au / twitter.com/jonoxer / www.geekmyride.org

I've just been for a bit of a drive with the OBDuino32KMega with a USB memory stick plugged in and logging enabled, and when I got back I wrote a little script to convert the GPS data into a KML file for Google Earth. I plotted location against vehicle speed and ended up with this:

http://jon.oxer.com.au/pics/obduino-track.jpg

Could be quite a handy tool for improving fuel economy, for example by plotting position against instantaneous fuel consumption or perhaps acceleration and trying to keep the height of the graph as low as possible.

lcd_gotoXY probably needs a tweak for 4x20 to get the lcd addressing right, here is the original 2x16 version
/*
* LCD functions
*/
// x=0..16, y=0..1
void lcd_gotoXY(byte x, byte y)
{
byte dr=0x80+x;
if(y!=0) // save 2 bytes compared to "if(y==1)"
dr+=0x40;
lcd_commandWrite(dr);
}

Oh yeah, that's the problem right there. It assumes that if it's not the first row it must be the second.

Thanks DCB!

I'm running in 16x2 mode at the moment but once I've finished mucking around with the datalogging and GPS code I'll have a look at that.

Cheers :-)

Jonathan Oxer

I've fixed the lcd_gotoXY function so it works correctly with 20x4 displays, but at the cost of an extra 54 bytes. That's a lot of extra memory for something that not many people will want, so maybe there should be two versions of the function and the correct one is selected at compile time based on the value of LCD_ROWS.

This is the new version of the function:

8 bytes of that extra volume is the check for calls to a row beyond that allowed for the given LCD size. Without that check in place it's possible for a call to this function to read random memory beyond the end of the offset array, and send that data to the LCD.

This function can probably be optimized but it's working fine for me on a 20x4 and since I'm running on an ATmega1280 with 128K of memory the size doesn't really matter to me. If someone else wants to have a go at putting it on a diet, go for it!

here you go:

//byte row_offsets is unused
byte dr = 0x80 + x + (y&1 ? 0x40 : 0) + (y&2 ? 0x14 : 0);
//32 bytes saved (burp)


edit: this one appears to save 18 more:

byte dr = 0x80 + x;
if (y&1) dr+= 0x40;
if (y&2) dr+= 0x14;

Thanks for the hard work guys. I log in to see what's up and see some great looking code already posted.

Using Nickdiggers code, it only costs 4 more bytes. (Zero increase for two line displays if we exclude the second if statement.) Very nice.

nickdigger, you're a champion.

Tested on my 20x4 and works perfectly. I've committed that to my copy of the OBDuino32KMega tree.

Cheers :-)

Jonathan Oxer
http://jon.oxer.com.au/

I have checked in the revised OBDuino32k code that allows 4 line displays to function correctly. (version 165)

Thanks to all involved in the correction.

That's quite the impressive Google Earth display. There's a lot of potential there.

Thanks Froggy.

I did a blog post about it on Practical Arduino yesterday, too:

Practical Arduino: News - Car engine datalogger project update

I ran the logger again this morning on my trip to work, and now that I have everything in place it only takes a few seconds to plug in the memory stick, run the conversion script, and open it in Google Earth to see a trip visualization. This morning I had a few work colleagues looking over my shoulder as I flew around the trip and they thought it was pretty cool.

Cheers :-)

Jonathan Oxer

Thanks for this fantastic addition to the OBDuino project.
You might be interested in connecting those three buttons wirelessly via
basic strap on style steering wheel remote kit, in that fashion you can easily cycle through the different PID and contrast settings on the LCD and still be safely focused with both hands on driving.

some links:
steering wheel remote - Google Search

That's an interesting idea. Elsewhere in the book there's brief mention of how to interface with the existing steering wheel buttons that are connected via floating contacts or clockspring electrodes, so I suppose one option would be to take over existing buttons rather than add new ones. The problem with a radio link is that most simple RF remotes won't handle multiple simultaneous presses, while the OBDuino relies on pressing multiple buttons to perform some actions.

By the way, I've now moved the OBDuinoMega branch to a repo on GitHub so that it's in a similar location to the other projects featured in the book:

github.com/practicalarduino/obduinomega

Cheers :-)

Jonathan Oxer
Geek My Ride: www.geekmyride.org
Practical Arduino: www.practicalarduino.com

Do you think that your kit could evolve in the future in something like single pcb board solution as this "basic" CAN OBDuino. Obviously with that added functionality it doesn't have to be 1 DIN frame size oriented as Frederic
is planing for his boards:
http://ecomodder.com/forum/showthrea...ress-9643.html
OBDuino Hardware
OBDuino

According to this french written blog,
OBDuino pcb kits should be available Q4/2009 at pricetag < $75
http://www.hyperkilometreur.com/blog/?cat=6
---

And with such complex project why don't you just migrate up to ARM9 level,
you then can run it on WinCE5/6, Android, Linux/Angstrom, .. , including 3,5" touchscreen or bigger

http://www.watterott.com/ARM9
http://www.friendlyarm.net/home
http://www.andahammer.com/

http://ecomodder.com/forum/showthrea...uino-8778.html

--

and/or alternatively there is this PAL/NTSC TV shield called TellyMate
for Arduino, which could run small LCD panel, many code samples here:
http://www.batsocks.co.uk/products/S...e%20Shield.htm
http://www.batsocks.co.uk/products/S...d_Examples.htm

now incl. new firmware for larger/custom fonts&graphics:
http://www.batsocks.co.uk/#nogo

hooked to 3,5" 4:3 TFT (.5W) 640(H) x 480(V) RGB car display
(sold as for CCTV camera):
http://cgi.ebay.co.uk/ws/eBayISAPI.d...m=310100862640

--
OBD-II project for RAV4-EV:
http://www.idleloop.com/robotics/RAV4-EView/

this version of obduino show me this errors:

obduino32KMega.ino: In function 'void __vector_5()':
obduino32KMega:882: error: 'PINK' was not declared in this scope
obduino32KMega.ino: In function 'void serial_rx_on()':
obduino32KMega:1026: error: 'Serial1' was not declared in this scope
obduino32KMega.ino: In function 'boolean iso_read_byte(byte*)':
obduino32KMega:1062: error: 'Serial1' was not declared in this scope
obduino32KMega.ino: In function 'void iso_write_byte(byte)':
obduino32KMega:1083: error: 'Serial1' was not declared in this scope
obduino32KMega.ino: In function 'void iso_init()':
obduino32KMega:1265: error: 'Serial1' was not declared in this scope
obduino32KMega.ino: In function 'void setup()':
obduino32KMega:3106: error: 'hostPrintLn' was not declared in this scope
obduino32KMega:3120: error: 'hostPrint' was not declared in this scope
obduino32KMega.ino: In function 'void loop()':
obduino32KMega:3262: error: 'processHostCommands' was not declared in this scope
obduino32KMega.ino: In function 'void params_load()':
obduino32KMega:3637: error: 'hostPrint' was not declared in this scope
obduino32KMega:3657: error: 'hostPrintLn' was not declared in this scope

please help me to solution the error in the code, thanks

Did anything more ever come from this project?

Pete