Crap, I just noticed it should have been 811033 
EDIT: Disregard that, 811033 didn't work either (same responses).
EDIT: Disregard that, 811033 didn't work either (same responses).
Last edited:
Technical Anyone had any success with an ELM323/327 interface
- Thread starter Argonought
- Start date
-
- Tags
- ecu elm323 elm327 maf
Currently reading:
Technical Anyone had any success with an ELM323/327 interface
7F is a negative response. But its progress as you are actually getting a response from the ECU.
oh crap lol, Ive given you the wrong ones too
it should be 8110F1
10 the ECU address, F1 the tester address.
Sorry mate
oh crap lol, Ive given you the wrong ones too
it should be 8110F1
10 the ECU address, F1 the tester address.
Sorry mate
Last edited:
Ah, so that's the correct address! I'll sure be willing to give it a try in the morning. If it all works, gods be praised, I'll be happier than a dog
8110F1, then.
Will report back tomorrow!
8110F1, then.
Will report back tomorrow!
Best of luck, let us know how you get on. If that doesnt work try C110F1.
If that still doesnt work I have some software which uses the serial port directly. Ill use that on my own car and log the comms so you can see how it works, as that was known to work on a pre eobd Punto
If that still doesnt work I have some software which uses the serial port directly. Ill use that on my own car and log the comms so you can see how it works, as that was known to work on a pre eobd Punto
It didn't work, mates... Still got the same response
Any suggestions?
Any suggestions?
Ill connect to my car and log the serial comms for you, you can look at the log then and try with your own.
Right,
Ive logged the serial comms and used sanderqv's kwp2000 test with an old serial cable to connect to the car. You use the DiagnosticTroubleCodesByService commands.
Rather than the way you would do in an eobd vehicle issuing commands to 0x33h, you use 0x10h. You then use the Fiat implimentation of KWP2000 which means the commands are different.
DiagnosticTroubleCodesByService request message is
18 00 ff 00
and the response is
58 11 22 33 44 55 66 77 88
58 = Response Identifier
11 = number of DTC's
22 = DTC #1 Hi Byte
33 = DTC #1 Lo Byte
44 = Status of DTC 1
55 = DTC #x Hi Byte
66 = DTC #x Lo Byte
77 = Status of DTC x
On my car, in hyperterminal to do the above you issue
ATZ
ATL1
ATE1
ATTP5
ATSH 8110F1
1800FF00
I recieved ;-
58 02 03 00 81 03 01 B1 CB
Which means response id 58, 2 DTC codes, first one 0300 , second 0301.
The status for both DTC's is B1, which is... cant be bothered at the minute.
Anyway, give the above a go it should work on all pre eobd fiats with just a kline. I used the same program with the same settings with my old Punto HGT, and that wasnt eobd either.
Dan
Ive logged the serial comms and used sanderqv's kwp2000 test with an old serial cable to connect to the car. You use the DiagnosticTroubleCodesByService commands.
Rather than the way you would do in an eobd vehicle issuing commands to 0x33h, you use 0x10h. You then use the Fiat implimentation of KWP2000 which means the commands are different.
DiagnosticTroubleCodesByService request message is
18 00 ff 00
and the response is
58 11 22 33 44 55 66 77 88
58 = Response Identifier
11 = number of DTC's
22 = DTC #1 Hi Byte
33 = DTC #1 Lo Byte
44 = Status of DTC 1
55 = DTC #x Hi Byte
66 = DTC #x Lo Byte
77 = Status of DTC x
On my car, in hyperterminal to do the above you issue
ATZ
ATL1
ATE1
ATTP5
ATSH 8110F1
1800FF00
I recieved ;-
58 02 03 00 81 03 01 B1 CB
Which means response id 58, 2 DTC codes, first one 0300 , second 0301.
The status for both DTC's is B1, which is... cant be bothered at the minute.
Anyway, give the above a go it should work on all pre eobd fiats with just a kline. I used the same program with the same settings with my old Punto HGT, and that wasnt eobd either.
Dan
Attachments
Last edited:
Sounds fancy! I'll try it tomorrow, hopefully! Maybe even today!
If there is such a strange protocol for the DTC codes, I'm pretty sure somehow, sensor implementation may be possible as well!
If there is such a strange protocol for the DTC codes, I'm pretty sure somehow, sensor implementation may be possible as well!
Ah, I've been reading on the KWP2000 protocol... Seems the 'cb' ending is end byte for all replies, and if 0300 and 0301 are your errors, b1 in front must be the error type... Quite an odd format.
What happens when you get over 2 errors? Multi-line reply?
What happens when you get over 2 errors? Multi-line reply?
Yup thats it, Id had a few beers last night and thought Id leave the message there before I diluted what I was trying to say.
For the request you can change the Hi/Lo byte to request different DTC groups. FF 00 requests all of them (Powertrain/chassis etc).
The status part is binary coded.
To clear the codes you send the clearDiagnosticInformation command,
Request
> 14 FF 00 (Request byte, Hi Byte, Lo Byte)
Response
< 54 FF 00 (Response byte, Hi Byte, Lo Byte)
This is getting very interesting! Has anyone found a protocol specification online yet? had a quick search last night to no avail..
Interesting will be once I get my software to also read realtime values!
Will test DTC reading right now
Will test DTC reading right now
The protocol specification is already an attachment in this thread.
If you want to help with anything drop me a PM, ive got a lots of docs/code/schematics etc that might help you on your punto diagnostic adventures..You cant be far from me either... Im in Pudsey/Leeds.
Realtime comes next, ive got a full list of scalings and quite a lot of requests for data. Anyway thunderfox let me know if what ive put above works for you so we can move on...
Regards
Dan
Last edited:
Success, man!
The car replied '58 00' to the above chain of commands, which means no errors (positive reply) from the ECU. Indeed, it answers fine to KWP2000 requests!
This is a very very big step taken, right here!
Also, just a small correction, ATTP5 (test protocol 5) won't do for my ELM (version 1.2a), and you have to issue ATSPA5 (set protocol 5 / auto) for it to respond properly!
Tonight, I shall improve my OBD2 tester program to support KWP2000 fiats
Now, for the live data!
The car replied '58 00' to the above chain of commands, which means no errors (positive reply) from the ECU. Indeed, it answers fine to KWP2000 requests!
This is a very very big step taken, right here!
Also, just a small correction, ATTP5 (test protocol 5) won't do for my ELM (version 1.2a), and you have to issue ATSPA5 (set protocol 5 / auto) for it to respond properly!
Tonight, I shall improve my OBD2 tester program to support KWP2000 fiats
Now, for the live data!
Wahey!! I knew we would get there in the end. Ill have a go with some realtime data stuff tomorrow and see what else can be done.
Your ELM is different to mine, mines the 1.3
Regards
Dan
Your ELM is different to mine, mines the 1.3
Regards
Dan
Last edited:
Mate, since my car has absolutely no errors on the ECU, I can't possibly test my program, except for a no-error scenario.
Any of you have any idea how I can force the car to come up with an error? Maybe some of you have errors, and will be willing to test the software for me? (provided you have an ELM327, of course).
Any of you have any idea how I can force the car to come up with an error? Maybe some of you have errors, and will be willing to test the software for me? (provided you have an ELM327, of course).
The easiest way is to unplug the MAF sensor on the air intake, but thats on my car. But I dont think your car will have one. I really dont know enough about your car to recommend something you can safely do to create one.
Ive got an ELM327 so I am happy to test it for you and give you some input, ive got two errors on my car and can easily create others.
Regards
Dan
Ive got an ELM327 so I am happy to test it for you and give you some input, ive got two errors on my car and can easily create others.
Regards
Dan
if you have an oil level sensor you could try unplugging that?
Okay, before going any further with the coding, I should implement the code to do the live data probing. If I go and just make the program using the current model of code, it may not even work later, and I'll have to start from scratch...
Dan, I was reading the KWP2000 specs before, I find reference to several commands which could possible refer to the live sensors, but no idea whatoever on how to use it (no PIDs, for example), and there are several possible implementations which could lead to what I want or not.
readDataByLocalIdentifier
readDataByCommonIdentifier
readMemoryByAddress (i'm guessing this one has nothing to do with sensors, but rather read the RAM data on a specific address)
These are what I found. There are also references to an encryption system within the ECU, to which you need to request and process a seed, in order for some commands to work. Quite a nice idea of Fiat to have done that, but it's a freaking ECU, not an internet computer. Any idea on how that one works, and how it affects the live diagnostic data?
Cheers man! :slayer:
Dan, I was reading the KWP2000 specs before, I find reference to several commands which could possible refer to the live sensors, but no idea whatoever on how to use it (no PIDs, for example), and there are several possible implementations which could lead to what I want or not.
readDataByLocalIdentifier
readDataByCommonIdentifier
readMemoryByAddress (i'm guessing this one has nothing to do with sensors, but rather read the RAM data on a specific address)
These are what I found. There are also references to an encryption system within the ECU, to which you need to request and process a seed, in order for some commands to work. Quite a nice idea of Fiat to have done that, but it's a freaking ECU, not an internet computer. Any idea on how that one works, and how it affects the live diagnostic data?
Cheers man! :slayer:
Yep quite right, get the commands right through the terminal is your best bet.
What language are you writing in/targetting if you dont mind me asking?
Ignore the seed/key and encryption, that is for accessing the ECU for programming and for a tester to upload its own code into the ECU's and EOL tests, write date etc.. It seems a bit drastic I know but is needed for the above to make sure correct data is written and to keep people like us playing with things we shouldnt be.
The bit for realtime data is read datablock by identifier. This bit isnt completely standard accross all cars, some cars support all/some of the locations. I know some of them for the Bosch ME ECU's but have no idea wether or not they will work with others.
Ill go out to the car in a bit and test some...
BTW, what ECU does your car have?
What language are you writing in/targetting if you dont mind me asking?
Ignore the seed/key and encryption, that is for accessing the ECU for programming and for a tester to upload its own code into the ECU's and EOL tests, write date etc.. It seems a bit drastic I know but is needed for the above to make sure correct data is written and to keep people like us playing with things we shouldnt be.
The bit for realtime data is read datablock by identifier. This bit isnt completely standard accross all cars, some cars support all/some of the locations. I know some of them for the Bosch ME ECU's but have no idea wether or not they will work with others.
Ill go out to the car in a bit and test some...
BTW, what ECU does your car have?
Last edited: