OBD MPGuino gauge

[Yoshi]

You can set the RC232C speed up to 500 kbps on ELM327 using PP 0C command.

Toyota Prius also uses WSS, and the skid control computer converts it to standard 4000 pulses/mile signal for speedometer.

Yoshi

[KJSatz]

OK I have kind of--let's see, sort of like treading water but more splashy but still not violent--splashed around here for a couple weeks, being dumb, deciding an MPGuino wasn't for me, still thinking a ScanGauge is expensive and wanting at least some DIY involvement here, staring at OBDII, and more splashing, and finally on this Friday night I find this thread and the Google Code entry for OBDuino.

I believe my car (08 civic) uses CAN, and I am interested in getting involved with this project for sure!

I know there haven't been updates for a couple of weeks, so would it be possible to get a status update of where folks are at this point (most important to me, has someone figured out how to do something simple like just display VSS on the LCD?).

This is dark-stab-ish, but I would also like to say I would advocate keeping the project very parallel to the devilishly-functional MPGuino project like in LCD interface for example.

[ishiyakazuo]

Well, I think I want in on this project too. I'll be ordering my parts ASAP
I've got an '02 Civic (ISO), and I'll start looking over the code and see what I can see based on the protocol specs I have...

Any suggestions on specific Arduino kits?

EDIT: I got this one -- hope it works out.

EDIT #2 (Sorry, just hate to double-post): I'm looking at the code in the repo, and I think I know why serial won't work. It looks like you're not using the Atmel's native serial port communications. You should be able to just set up the UART to 10400 baud and then rock and roll after sending your 5-baud 0x33 by hand. My understanding is that you don't get a response to 0x33, you get a response to an initialization message that goes out at 10400 baud. (If you guys have gotten past this point, then sorry -- it looks like the code is waiting for a VERY approximate 10400 baud, which will realistically be incredibly off, since the difference between 10400 and 9600 baud or worse is only a couple microseconds (just a handful of ticks).

In other words, you NEED to use the hardware UART block, or you will surely fail at sending an intelligible message (I don't think the 5 baud one is quite as sensitive). Trust me, I've tried doing stuff like this in software using an AT91 at 49MHz, and it didn't work out there, and that has a much finer control. I can't remember the polarity of a 1 or 0 in RS232, but if it's the opposite, you can always just XOR the byte with 0xFF to negate each bit and then send it across. Anyway, once I get my Arduino setup, I'll throw it together and see what I see as well.

[ishiyakazuo]

I know I shouldn't double-post, but the other one was becoming obscene.

Okay, so, I've looked over the code and noticed a few things:
- You're using pins 2-3 for the K-line. You'll need to re-wire this to use the UART Tx/Rx pins 0-1 in order to make this work. ISO doesn't have any tolerance for baud rate issues, and the assumption that all you have to worry about is the overhead for digitalWrite is false. (You're in a for-loop, which means there's also compares, branches, etc. happening.) The fact that ATMega168 (or ATMega8) has a UART is a blessing, not a curse
- I was so happy to see the #defines at the top describing the PIDs, and then in other places in the code, there are constants without names (for(i=0; i<3+1+1+len; i++), for example) where the 3, 1, and 1 could be described with descriptive names rather than with long comments ahead of time -- extra #defines are free

I think once you guys use the UART, you'll find yourself very close. I did look and it appears that RS232 uses the same polarity on its bits as ISO-9141, so it should really be as simple as plugging into the UART, adding the line

Serial.begin(10400);
under
// switch now to 10400 bauds

and changing the reads and writes to the respective Serial calls.
Give it a shot when you get a chance

[Magister]

Hi, I am the one who wrote the code. I havn't had a chance to continue it lastly because it appears my car is CAN only and unfortunatly lack of time.

Where there is some hardcoded value inside is to quick test the code and I didn't put any error checking and things like this. The code has been written first and was tested on the hardware later.

The software serial does not use an "approximate 9600 baud" but a right 10400, it should not cause any problem. Anyway after sending the 0x33, the ECU should answer by lowering the K line for its start bit and it will unblock the iso_read_byte() while statement. At this point, no 10400 baud is in use, the 0x33 bits are send with delay(200) which are ok.

The UART is used to send debug message, of course it's easy to just change the call of iso_write_byte() to Serial.write(). I may test it to proove my car is CAN only, Hyundai USA says it is CAN, Hyundai Canada says not

EDIT: if my car is CAN only, I may use an ELM327, it's $32 + a few $ of components (a crystal, some resistors/capacitors) to wire it for CAN protocol. And we have the possibility to wire it for all protocol for a few $ components more.

[ishiyakazuo]

Hi, thanks for responding.
The issue is that if you throw it on a scope, it definitely won't be exactly 10400 baud because your calculations are just approximations.
To guarantee a consistent baud rate on a CPU running at such a slow speed, you need to use the hardware baud rate generator.
I've done plenty of protocol projects (such as monitoring an I2C bus I wasn't talking on) and I couldn't keep up when it was written mostly in ASM, on a 50MHz ARM7, and the I2C bus was only talking at 5-10kHz (about the same time as this one). iso_read_byte() definitely will have some issues in keeping up.
The bottom line is, even to talk to an ELM, you're going to need a consistent baud rate, and you will need to listen and talk simultaneously (the reason RS232 has Rx and Tx). You can't implement these things in software -- it's just not possible.
For debug, you're going to need to rely on the 2x16 LCD to print out some info at this point, I think. The data will be limited, but you don't really have much choice as far as interfacing goes. The other choice for debug is to make a debug bus (maybe hook up another CPU to get another serial port, and make the two CPUs talk?)
Your calculation just doesn't seem to take into account the fact that a message can come to you at any time -- on serial busses there's framing on bytes as well as bits, and that doesn't look like that will be adhered to with all these function calls being made. Using the hardware RS232 fixes this.

Read again the page you linked to early on: prj.perquin.com says that you have to send 0x33 at 5 baud, then send the payload c1 33 f1 81 66 at 10400 baud to get a response. (You should be waiting for response 83 f1 01 c1 e9 8f ae). Waiting for a response that wasn't asked for may be a big problem you're facing as well

For CAN, you might want to check out the AT90CAN series Atmel CPUs. It seems like it may be fairly software compatible with a good portion of the Arduino's ATMega. But in order to get the project done quick, yeah, use the ELM327. (My car is ISO, so I'm interested in getting the ISO stuff working, personally. )

[Magister]

The page on perquin is about ISO14230 (KWP2000) slow and fast init.
In the standard ISO9141, you just send 0x33 at 5 bauds and the ECU answer at 10400 bauds. I tried the three init in my car (see old version of code) but it does not answer, even to the regular 5 baud so it's not a timing problem I think. Timing in the software serial is in fact 10416 baud, it should be close enough. It works well at 9600 baud and a terminal. Also talking OBD protocol, it's a half-duplex protocol, there is only one pin, the K one, you can not read and write at the same time. Unfortunatly I have never been able to test it IRL, just emulating it, so I don't know if it will work 100% or not

For the 5 baud init I monitored on a scope and the timing is right to the millisecond. I monitored the K line in my car with a trigger on it and it does not move at all after the end bit of the 5 baud 0x33.

The AT90CAN dev board is $50 and I would have to re-write almost everything from scracth, and the CAN protocol is more complicated than ISO so yeah the ELM327 will be a good choice I guess, but it add $ to the cost of the OBDuino. I'll talk to the ELM through the pin 0 and 1 because of speed of 38400 baud or even 115200.

[ishiyakazuo]

Sounds like you've got a good handle on this stuff. I don't have the ISO 9141-2 spec, so I'm just going by what I've seen, but it seems like there has to be something missing because ISO 14230 claims to be backwards compatible to ISO 9141. In other words, since ISO 14230 sends a message right after 0x33, it would cause the ECU to not be able to respond with its ISO 9141 response...

My comment about reading was assuming that the ECU can talk without a request from you if it's talking on the same bus to another device. And reads are harder to determine your baud rate (you can't assume it will be the same as the Tx baud rate even with similar code, and you can't throw it on a scope easily). After multiple bytes, if you aren't constantly re-framing the data (which you aren't because you don't appear to be edge-sensitive), you might get a misread too even if you're only 20Hz off of nominal, depending on when you're sampling...

In any case, it still seems very dangerous to try to implement a serial protocol via CPU. You can maybe get away with sending RS232 @ 9600 baud to debug elsewhere, since the PC will do better at re-framing the data you're outputting than your code will. (It uses dedicated HW to do that.)

Once I get my HW, I'll throw it together and I can do some debug with some real data coming back and forth. I'd say the first question we should answer is, if you send 0x33 properly, wait and see if the ECU sends anything. If it doesn't, your assumption of "it should be sending something" is flawed, and we can go from there. If it does, then it's a matter of figuring out why it isn't being seen. Both should be fairly easy to get to the bottom of I've got some little USB scope at work that I should be able to borrow and probe around with in my car, so I'll get some data when all this stuff comes together.

EDIT: Okay, I see now about the 0x33 -> 0x55 handshake. I found an article describing it as well. So, my only concern now is that delay(200) followed by a delay(60) -- you already wait 300ms in iso_read_byte() so I don't think you need to delay(60). I'm worried that you might be missing the 0x55, simply since it'll be sent within 1ms (at 10.4kbps).

Again, I'd still say that the safest thing is to use the UART. It has a buffer so that you're guaranteed not to lose data (so long as the data isn't > 128 bytes, but no ISO 9141 message is that long anyway). If you need to print debug info to serial, you can emulate a serial port on a GPIO without worrying about time-sensitivity (if it breaks occasionally, oh well, debug isn't going to be a permanent part of the design).

In any case, I'm really excited to try this out, and many thanks for the work you've done on it thus far I was going to try to implement this sort of thing in an 8052, but I think the ATMega is the better choice.

[dcb]

If cost of the final product is a concern, the "right" approach is to try and decipher the protocols (VPW, PWM, ISO, CAN) and do them on the duino. But it is a LOT of work, there are working examples of these in the public domain but they need to be tied together into a working model.

If you want results quick, then slap a 327 in there I don't own any CAN vehicles, but that would be a good first protocol to get working, maybe a low cost atmel CAN based chip with an elm like interface to the duino would leave a clear path forward for the lower cost protocol specific elm chips?

[ishiyakazuo]

I'm not too worried about CAN at the moment. (Honestly, this project isn't so amazingly difficult that the whole thing couldn't be ported to a non-Arduino AT90CAN completely in a handful of days).

My personal opinion is that if CAN is important, using the Arduino becomes more of a hindrance than a help, honestly -- ATmega168 and AT90CAN are basically software-compatible parts already, so why not just use the AT90CAN for everything? But then one has to worry about solderability, since AT90CAN is only a flat-pack part.

AT90CAN has dual USART, which means one could be dedicated to J1850 PWM (via a transceiver chip) while the other is doing ISO 9141. I think you could probably get away with J1850 VPW in software -- it's not as baud-sensitive a protocol. They're a $10 part in low quantity, and everything can be run in the same place -- that's really where you want to be if cost is an issue.

But I digress. If you want it done quick, re-use stuff people have done before you. If you want it done cheap, do it all over again yourself. But to be honest, using an Arduino for half of the task and then the ELM or an AT90CAN to save your butt when you find out Arduino isn't up to the task doesn't make too much sense to me, honestly. (Well, the Arduino+ELM one does, but only if the situation we're dealing with is "I need it right away.")

What we need here is to consider the pros and cons of a design before trying to brute-force it. My estimate is that on an Arduino, we have this situation:
- ISO 9141-2: Likely able to implement using UART + level converting chip
- J1850 VPW: Likely able to implement using GPIO + level converting chip
- J1850 PWM: Likely able to implement using UART + I/O handler chip
- CAN: Requires external chip to make it talk at decent speeds.

With an AT90CAN, we run into most of the same situation, but you have two USARTs instead of the one UART the ATMega168 has, so running both in the same bit of software becomes a little more feasible. Plus CAN has dedicated HW, so no external chip. If I had a car with CAN, I'd be heading this route right about now... but luckily, I don't!

With Arduino+ELM327, we have no problems except for our pocketbooks. I can't imagine the cheapest solution involving an ELM327 costing significantly less than $60.

Bottom line is, before tackling CAN, I think getting ISO and VPW to work on the existing platform would be a reasonable milestone, since the hardware is there to do so.