OBD MPGuino gauge

[Froggy]

I've got a new build with better Slow and Fast inits, but have not sat down and looked at the timing issues yet. I have a bit more testing on it before check in...

I would need to know what exact unsupported PID's cause a reset before attempting to debug it. It could be a divide by zero problem, or it could be something else. On one hand, running unsupported PID's should not be done, so this failure is not a priority.

More of a priority is finding a work around to GET the correct data somehow from the ECU. How does the Jetta supply the data that it does not supply through generic OBDII commands? Is there an extended OBDII command that works, or do we have to rely on the VW/Audi specific commands that are not OBDII? It's been seen that the Scan Gauge can get the data required somehow from the car, but they are not an open source project. I'm not sure on where to look for this solution.

Thanks, ElectroMike for finding the Swedish 14230 documents... I will implement what I can from them for the next check in. (Not for a few days at least.)

[Demonhawk]

Electromike: I gave the test code you sent me a try. 14230 slow & fast do not connect. I can only manage to get 9141 to init successfully.

Froggy: I know for the jetta, it provides additional data through KWP2000(iso 14230) but it is encoded in their proprietary format "VAG". Only thing is the OBDuino isn't even able to read the status of the o2 sensors, and correct me if I'm wrong but isn't that a required PID that is used when you get your car inspected?

On a side note I was thinking about trying to use my freescale chip and trying to wire up a laptop adapter so I can try out various OBD scanning programs. I need to use USB since my laptop does not have serial. I was wondering if there was anyway to use the arduino as a usb/serial adapter for the freescale chip? If not I can just use one of the various diagrams online.

Also, I found this software http://groups.google.com/group/monoscan Which is dedicated to reading Keyword 1281, and 2000 which are the VW/Audi protocols. I might give it a try to see what data I can access from the ECu.

[electromike]

Froggy:

I haven't looked closely at your init code, but if it is improved, we will set that aside until next check in because the iso 9141 and 14230 slow init should be the same and generate the same result on any car that is ISO. That would be needed for Demonhawk's Device to work.

What needs to be added to the code is new header infromation for the KWP 2000 protocol to respond properly. As it stands now, the header information being sent is indicating that 8 Bytes of data will be sent, when in reality their are only 2. This would be messing with the Car's ECU and generating some unexpected results.

modify the code as follows:


byte iso_write_data(byte *data, byte len)
{
byte i, n;
byte buf[20];

// ISO header
#ifdef ISO_9141
buf[0]=0x68;
buf[1]=0x6A; // 0x68 0x6A is an OBD-II request
buf[2]=0xF1; // our requester’s address (off-board tool)

#else //assume we are using 14230 protocol
buf[0]=0xc2; // Request of 2 bytes
buf[1]=0x33; // Target address
buf[2]=0xF1; // our requester’s address (off-board tool)
#endif




Lets get that new init code, and that change for the header byte to Demonhawk. It might be all that is needed for his thing to work! Great work Froggy.

[tom43571]

Great, I got it to work on my 99 civic but I also have a 99 saturn that I would like to use it on. I believe it uses SAE J1850 VPW. If I build the ELM interface will what you guys have work on my saturn?

[electromike]

Tom:
As far as I know the ELM327 handles all protocols, so if you hook up all proper hardware to the ELM chip and to your car, the OBDuino32K will work for it.

If i am wrong... well, maybe someone will send me one of those chips and we can fix it in the code for you

Others:
For the fun of it. I tried to start using the Issues tab on the google code page. With a few of us working on the project now, it might be nice to have that feature used.
It could be nice, for example when one of us has a free moment and want to accomplish something on the project we could have a list to choose from.
This could help us be aware of issues others discovered in the code. Also this will keep two of us from doing the same work.

At the moment when big features are being worked on, like the ones froggy has in the works, it's not so beneficial, but as the project grows, this will help us make a nice polished product -- and make sure we don't forget about going back to fix things that are only half done now... like CRC error check and such.

[tom43571]

I was under the interpretation that OBDuino32K only worked for CAN because the interface is for CAN or ISO. If this is not the case let me know and I will get the ELM chip ordered right away.

[electromike]

Yes, the ELM interface, when you use the 327, works for all interfaces. The chip acts as a middle man between the OBDuino and the car.

There are cheaper ELM chips that only support certian protocols, i think, so you could just get the one that only does what you need to save a few dollars.

but either way, our code talks fine with the official ELM chips, after the ELM chip you just need to add the hardware they suggest to finish connecting it to your car.

[mattjreilly]

Hey guys,

I haven't had much time recently to work on it but if you need some debugging, I've got my OBDiuno that works with a 2005 Honda Pilot but still refuses to connect to my 95 Subaru Outback. It seems to like the 14230 init.

matt

[Froggy]

I have been unable to do much in the short past here due to hectic stuff, but a new check in may help on the 14230 side of things (two corrections). In the next few days things should settle down, and I should be able to spend some more time on getting things checked in.

ElectroMike, the Issues tab would be good to utilize. Ha, which I see you have already started!!! Excellent.

[Magister]

I think the Subaru use 9600bauds, isn't it? or something special called SSM protocol.