OBD MPGuino gauge

[Magister]

I agree that to make work the ISO part is the first goal, the hardware is here, an Arduino and the "free" MC33290.

For CAN you need conformance and qualification, so you have to use either the ELM327 or the AT90CAN. The atmel CAN exist only in a "thin quad flat pack" like you said and unfortunatly there is no arduino like dev board for it.

I really don't know... ATMega168+LCD+ELM327+parts would cost about $60 for sure. If we take the AT90CAN way, we have to design our own board and still use externals MC33290 and MC33390 + some parts etc. It should cost less except for the board/PCB.

I didn't want to use the Arduino for iso/vpw *and* the at90can for CAN, the solution is to use either the arduino+ELM327for all protocols, *or* the at90can for all protocols, not a mix

[dcb]

So start with a 327 and figure out how to reduce the price later then?

Or abandon or adapt the arduino ide to the at90can?

Is there any chance the 327+arduino would be code compatible with, say, an arduino+323? There's a few bucks back right there.

[Magister]

Originally Posted by dcb

So start with a 327 and figure out how to reduce the price later then?

Or abandon or adapt the arduino ide to the at90can?

I want to evaluate how much an at90can board would cost, I have no clue after designing a small PCB in Eagle, the price charged by a company to make 10 of them for instance, and if they can solder the at90can or not like a stuffer, etc.
For the ELM327 there is a reference design board in the PDF and gerber files are available.

Originally Posted by dcb

Is there any chance the 327+arduino would be code compatible with, say, an arduino+323? There's a few bucks back right there.

Yes, especially for basic thing. I took the pdf of the ELM and man, it is so easy... the ELM does everything, you send on the serial port "01 0C" (01=request, 0C=RPM) in plain text for instance and it answer with "41 0C 1A F8" (41=answer, 0C=RPM, 1AF8=RPM*4), if it's a 320, 322, 323 or 327, it's the same thing, same "ELM protocol".

The ELM327 has more pins than the 323 however and is not pin compatible, but the software would be 99% compatible I guess, and it's easy to detect at boot the type of ELM you have anyway.

[ishiyakazuo]

I agree completely with Magister.

What we really need to decide is what the goal is here.
Are we making a device that is completely like ScanGauge where it can talk with all protocols in the same unit? If so, we need to bite the bullet with either AT90CAN running the show, or adding on the ELM327.

ELM323 really is a waste -- the Arduino can do ISO alone. Code savings doesn't necessarily equate to cash savings, when you have a large flash in your part. I think space-wise, the Arduino is more than capable of supporting all of the protocols individually (and if it becomes a problem, you can always custom-build things with #IFDEF anyway).

So the question is, which are we aiming for?
- ISO + VPW in the Arduino with minimal HW
- AT90CAN supporting all protocols? (Admittedly, that will be a problem for sharing HW between the pre-OBD-II MPGuino and this, but we're not sharing a code base right now anyway, so...)
- Arduino + ELM327 to handle everything.

EDIT: An AT90CAN board probably won't cost much at all -- it's a super small part. I'd imagine if we could get 20 units made (my friends and I would easily want 5-10 of them anyway), the bare boards would be well below $5 apiece. I'll try laying one out some time this week if I get a chance, and we can determine how we want to move forward from there. Soldering the chip shouldn't be too hard -- just start with pins you don't care too much about Placing and stuffing is pretty expensive. I think we have some materials here at work though where we might be able to stuff the chips onto the boards relatively quickly, so maybe we can do it as a kit where the board comes with the CPU soldered on?

[dcb]

I think the plan is to get an arduino + 327 working for obduino 1.0, and get something out there and address the price issues later.

I would agree that the 323 is a waste if someone has already done iso on an arduino, ishiyakazuo are you willing to port the freediag or scantool iso code (or start from scratch) to arduino to make that happen for 2.0? I wouldn't jump to the can chip without some actual code first.

We've been sticking with the arduino IDE thus far to make development possible for the widest audience. I've had to wrestle with it in a couple spots so I'm not entirely adverse to using another public domain programming environment (gcc+avrdude?), but it merits some discussion of the pros and cons before abandoning arduino alltogether.

[ishiyakazuo]

I hear you -- Arduino does have its benefits

I think we're pretty close on the ISO protocol as-is... I don't have a problem with porting existing code in either though. I'm pretty adamant that we need to use the UART provided by the chip for reliable comms though, based on other projects I've worked on in the past. (Yes, you probably can get there if you work really really hard, but it's totally not worth it.)

GCC+AVRDude would be my first choice, actually. Arduino does some very basic stuff for you in the bootloader and API, but nothing that wouldn't take just a couple of days to implement on another AVR yourself.

Honestly, I'm all for Arduino+327 just to see something work.

[dcb]

Ok, arduino+327 sounds like a plan, I agree life will be better with on-chip UART support (Serial.write/read). I cannot condone reverse engineering a commercial product however, and cannot afford a copyright attorney, so please do be careful in your approach to arduino based direct obd communications.

[Magister]

ishiyakazuo: I am more a software guy than an hardware guy, if you can design an AT90CAN PCB with I/O for LCD, buttons, and all the pins for ISO, VPW, CAN, etc, it would be cool of course

For the moment I will go with the Arduino+ELM327. It's a solution that can work for *all* protocols.

Be careful of the chinese ELM clone on eBay, a lot are using the old 1.0 revision illegally cloned on a PIC...

OBDuino 1.0 version can be Arduino+ISO(+VPW), minimal hardware
OBDuino 2.0 version can be Arduino+ELM327 or AT90CAN, more expensive but you need this for CAN, meaning if your car is 2008+ (and some earlier) only.

[ishiyakazuo]

@Magister: Fair enough. I got one of those off of eBay before I even really looked into it (and realized the real ELM parts are over $30, which would've been a warning siren going off in my head).

At this point though, I'm kinda thinking OBDuino 1.0 should be the Arduino+ELM (mitigates risk), and 2.0 could be the AT90CAN or a more limited version that only does ISO/VPW in software on Arduino.

I'm also a software guy, but I've laid out boards successfully in the past with similar requirements without issue, so I'm sure we can come up with something decent for this. I was planning on laying out an "Altoiduino" board -- an Arduino clone board (probably based off of RBBB) with the components needed for the various protocols, but now I'm wondering if I shouldn't concentrate on the AT90CAN.

@dcb: I should rephrase that -- I wasn't really speaking of full-on reverse engineering, but just getting an idea of the protocol, since I'm not completely familiar with how they work (voltages, pulse shapes, etc.) I wasn't thinking too much about taking the data going across the bus and straight cloning it. But I suppose you're right -- it's a fine line.

To be honest, if ELM has a copyright on their implementation of the protocols in a CPU, the project is kinda doomed to begin with, isn't it?

I'm not condoning anything I perceive to be illegal either. If I open up the case of this thing I got off of eBay and find out it's a clone (and now I am fairly certain it is), I'll be a little disappointed -- mostly in myself for being suckered! But with a protocol, there's typically only one way to skin a cat. If I was talking about ripping the code from an ELM327 and reverse engineering that, that'd definitely be wrong, but seeing the messages it sends out just to get an idea of the protocol's ins and outs in a real-world example seems to be clean.

[dcb]

Originally Posted by ishiyakazuo

...but seeing the messages it sends out just to get an idea of the protocol's ins and outs in a real-world example seems to be clean.

You will be putting me in a very difficult position if you do.