I've been looking into this for a few days now, but DCB just send me to this thread.
Here's what I know and think -- feel free to disagree or correct where I'm mistaken. I'm coming from a car (Kia/Hyundai) that I believe is all-CAN. In either case, CAN is mandated in the future (MY2010, I think), so it's a good focus.
First off, I think ELM is the wrong way to go. Those chips are over $30 and they don't add any appreciable value to the circuit... certainly not $30 worth. Instead, I would go with the MC2515/MC2551 combination. Advantages:
- Less than $5 in single quantities, less than $3 in 100+.
- Available in DIP (and smaller form factors)
- SPI instead of RS23x -- forget baudrates, AT-commands and all that junk + run full-speed.
- ELM still calls their (expensive!!) chips "experimental", while Microchip is already on the 2nd generation of production.
- MC isn't going anywhere... ELM?
Disadvantages:
- Slightly more code.
Secondly, I think the arduino/ATMega platform is fine; AVR's automotive chips with built-in CAN are interesting, but beyond the reach of a hobbyist as far as handling goes. If code size really becomes an issue, there's the option of the ATmega328 with 32K flash. Additional advantages of the Arduino platform are the bootloader and IDE; and the 168 and 328 are available in DIP forms.
Thirdly, I'm not using an arduino -- I didn't gleam any info about what you folks are using, but I've taken to using the Boarduino (
Adafruit Industries, Unique & fun DIY electronics and kits) and the RBBB (
Modern Device Company). Both those kits are bread-boardable, and have much improved boatloaders. Don't forget the USB cable if you purchase one.
As far as code goes, there are some valid points made here -- both as far as planning ahead, as well as to the end of just getting things working. Proof-of-concept is great and positively a requirement, but it shouldn't be much more difficult to structure to code in such a way that it's adaptable. (Disclaimer: I haven't looked at the code yet).
My approach to this (as I've formed it in my mind over the last few days of researching OBDII, CANbus, etc) would be somewhat modular:
(A) Physical
(B) Protocol
(C) Application/UI
For all buses, (C) would be the Arduino with LCD and buttons. It would receive an abstracted form of the data, ideally (** more below) indepdent of the physical interface.
(A) would be a combination of cable, MC2551+MC2515 for the CANbus, then connect via SPI. For the other buses it could be another processor (mega48 or tiny2313) which interprets the data-stream from the OBDII and turns it into either SPI or UART-Serial. We could go nuts and emulate the MC2515 and have it truly plug-and-play, but given (B) is flexible, we probably wouldn't have to go that far.
(B) would likely reside on the UI processor and directly communicate with the 2515; it may partially reside within (A).
For my CAN scenario, I'm looking at $10-$12 in parts excluding the PCB, LCD and connector. The whole thing, in single quantity, should come in under $30 -- that's less than the ELM chip alone.
As far as the PIDs go, that is pretty well standardized:
OBD-II PIDs - Wikipedia, the free encyclopedia ; ideally, the code would simply issue a $0100 to see what's available, and then look for those PIDs in the broadcast.
It looks as if all the parts are there... and we just have to glue them together with a little solder and a little more code. I won't be very active on this as far as hardware goes until after vacation (mid October), but it seems like a nice winter project.
Oh, and before I forget, my intention here is to achieve the following functionality:
- Replace the "trip computer"
- Add instant mpg
- Add avg mpg last x minutes/miles, since last stop, since beginning of trip, today, this week, this month.
- Track/log mpg for different drivers.
(and a few more)