Hi!
I read a lot of threads about OBD scantools for the 993 and I am now interested in programming a software of my own. I used ScanTool4 and OBDPlot to get some information in reading the ECUs of my 993 and especially the Sourcecode of OBDPlot (by Julian Bunn) was a very useful for me. My Software is able now to read the Porsche numbers and serial codes from the motronic, alarm, airbag, ABS, climate unit and Tip. OK, I know that ScanTool4 does this all too, but my interest is to programm it by myself and to learn something about the insight of the ECUs. My next step was to read the error codes and now I have a problem where I did not find any information. Scantool does not show any errors in my alarm unit, but my porsche dealer used his obd and found a lot of errors (radio). I really have a problem with the radio and the alarm. When I read the error codes with my software I got a result, but I can not interpret it. So I need the advice of some specialists here that can help me.
My result in a log-file looks like this:

GetBlock: BlockNumber, Blocktype, Length, Values
1; 246; 8 0 73 48 49 65 76 65 82 77 0
I01ALARM _

GetBlock: BlockNumber, Blocktype, Length, Values
3; 246; 11 0 57 50 56 54 49 56 50 54 48 48 50 0
92861826002 _

GetBlock: BlockNumber, Blocktype, Length, Values
5; 246; 12 0 50 53 49 57 57 53 48 48 56 48 49 56 0
251995008018 _

SendBlockType erorr reading
GetBlock: BlockNumber, Blocktype, Length, Values
8; 252; 20; 252 3 252 4 26 10 25 3 252 252 252 3 240 28 10 27 3 252 252 3 0

The first three blocks are the porsche number etc. and this works fine. The 246 as Blocktype means that these are ASCII-Data.
The fourth block has a 252 as blocktype and this is the correct answer to a error reading request. I got 20 bytes as answer but how can I interpret them. Different protocols have different rules for the interpretation. I think that two or four bytes must be interpreted together. In the KW1281 protocol three bytes are used (highbyte, lowbyte, statusbyte) in ISO 9141 there are four or more bytes (I read in a OBD document of FIAT).

Does anybody know, how the error bytes must be interpreted for my alarm and how do i generate the error codes of porsche (11..26)?
Martin

 

This is very interesting! We really need a more modern alternative to Scantool4.
I'd expect the ascii values to be linked to the error code numbers. (see the Trouble codes files in the Scantool file set)
I find it very strange that your dealer are able to read out more fault codes than Scantool does. However, I have no evidence that Scantool really support all types of faults in this unit.
There's only one input on the alarm unit that concerns the radio, this is the "green wire" supervising radio theft attempts. The radio itself has no OBD connection.

I will try to dig into your alarm faults later today. I have hammers, PST-2 and other tools available, as well as alarm units. I could try to sniff the OBD traffic when using these tools connected to an alarm unit.
Cheers,
Tore

 

Hi Tore!
Yes, we need an alternative to scantool4! There are some features that were not implemented in ScanTool4. And I tried to do the first step in reading the CUs for my 993. I think that it would be nice to have a software that is able to log the parameters while driving, display grafics of the logged data and so on. For the motronic this is possible with the input I got from Julian Bunn (OBDplot), but the other CUs are still a dark hole for me. Some inputs and outputs (actual values) can be seen in the configuration files of Scantool4, but there is not much documentation about the programming (reading ADCs, acutator tests and so on). DougB who programmed Scantool4 was not reachable for me, so I begun with my own tests.
I do not know, if I will have success with my programming, but I want to try it as far as I can. And perhaps here are some persons with much more knowledge than I have today...
Let me know, if you have some ideas for decoding the error codes.
Martin
P.S. I used your T-OBD for my first tests and it worked fine with my software!

 

Short info:
I read my errors from the alarm again (4 times) and I think that there are some counters (cou, byte 5 and 7) in the data. They are increased by one (13, 14, 25,26,27,28 and so on).
The byte 6 and 8 could be the error (perhaps 10+3=13 dec? or 10 hex + 3 hex = 19 dec?)
13=Voltage failure term 30 during output
19=Input 2 to gnd during activation
But my problem is the radio (probably the closed loop control).
The first four bytes are mysterios for me. Often they are 252,3,252,4 but not every time. Perhaps I have a timing problem during the reading. I must control this. I will try a delay before reading a block of data.
Next step will be to erase the error memory and to have a look on the counter then. Could be that it is reseted after the erasing.
Greetings
Martin

P.S. My software can read the inputs of the motronic and the actual values now. Looks really good but sometimes I loose the connection to the ECU. May be timing problems too. I will implement these functions to the other ECUs next.

Error data from alarm:

cou? err? cou? err?
252 3 252 4 14 10 13 3

252 3 252 4 26 10 25 3 252
252 252 3 240 28 10 27 3 252
252 3

252 3 252 4 38 10 37 3 252
252 3 252 4 40 10 39 3 252
252 3 252 4 42 10 41 3 252

252 3 252 4 70 10 69 3 252
252 3 252 4 72 10 71 3 252
252 252 3 4 74 10 73 3 252
252 3 252 4 76 10 75 3 252
252 3 252 4 78 10 77 3 252
252 255 255 4 80 10 79 3 252
252 252 224 4 82 10 81 3 252
252 0

 

I can't help with your questions, but I wanted to know if your solution will work on my '95 with ODBI instead of the later ODBII? I also wanted to thank you for doing this. Your's (and others) efforts are what our 993 community needs. As time passes, tools that we need to keep these great vehicles running are becomeing more and more scarce.

 

Have you looked at http://www.blafusel.de/obd/obd2_kw1281.html to see if it is of any help?
Send me a PM if you would like help developing the software. I would like to be part of an effort to provide a free (or very low cost) tool to the 993 community.

 

Hi!
@ble2011: I test my software with my 993 (1995, model year 1996). I have the 16 pin OBDII adapter but the protocol which is used is OBDI (ISO 9141-1989 I think). Older 993 had the round OBD adapter with 19 pins and need another connector but this will all work with the software. Some information can be seen here:
https://rennlist.com/forums/993-foru...-scantool.html
and one further interesting site is here:
https://sites.google.com/site/bofinit/obdplot
My 993 has the immobilizer (DBS) which causes some problems in reading the motronic, but I can read my motronic. I use the interface T-OBD from Tore.
@BesideTheBox: Yes I know the blafusel-site and used some information from there. KW1281 and ISO9141-1989 are very similiar and the wakeup of the ECUs, the reading of data blocks and the reading/deleting of the errors was programmed with this informations. The coding of the error codes must be different at the ECUs in the 993. As far as I understood it, the porsche error codes in the 993 have only 2 digits and there is no need for a highbyte or lowbyte. But perhaps I am wrong...
Some information from Fiat with other decoding of error codes can be found here:
http://pcbunn.cacr.caltech.edu/jjb/p.../Fiat-9141.pdf
My impression is that bosch/porsche/other manufacturers of ECUs did there own coding of the error code.
My software is under development and shall be a free software when it is nearly errorfree. I develop it with an old software called Delphi 6, which is like Pascal. I am happy about anyone who can help me in understanding the ECUs and their inputs, outputs, memorycells, calculation of parameters, activation of actuators and so on.
A lot of work was done by DougB who programmed ScanTool4, but the source code can not be found anywhere and DougB does not respond to questions. So I try to "invent the wheel" again...

 

Hi dochilli,
I'm popping over from the 964 side. Finding OBDplot a bit buggy. I'm a hack of a programmer and haven't poked around the source code very much. Have you come across anything to increase the sampling time in OBDplot? Currently, I get 1-second resolution in the OBDplot log.

Also, my dream is to be able to add an additional input lead to one of the empty obd socket pins. In particular, adding a wideband analog lead that can be plotted up simultaneously with the other parameters. Currently, I'm grabbing the data arrays from obdplot and innovate logs and crudely lining them up-

(obviously, I've got some mixture issues...)

Not sure if this can translate to 993 motronic, but I'm curious about burning my own chips with tunerpro.net and etc. Looks like an interesting possibility.

Cheers!

 

If you fellas get this scan diagnostics tool ironed out, I would be a potential buyer...96 OBDII application.
Best of luck, gentlemen

 

@ -nick:
The sampling rate is also one of my problems. The reading of one parameter is faster than reading more parameters (5 or 6). The communication with the motronics runs with 9600 baud at the 993 and there have to be a lot of bytes to be send and read before you can read an acutal value. So I do not believe that a faster sampling rate may be possible.
A line diagram of choosen parameters of the motronic during driving will be one of the planned features of my software. A log file with all data for an excel import would be interesting also.
I can read meaningful values and inputs from the motronic, but sometimes I loose the connection (may be timing problems). So I have to fix this problem...
Greetings
Martin

 

Martin, I have all the data streams from all ECU's on the 964. I have a device that sniffs the coms between the car and the Hammer. I have a copy of Delphi 3.

FYI, the format of the data stream is between master and slave. The master ( be it the car or the hammer) has the format:

#of bytes, counter, function code, rec'd data, END (03H)

The slave acknowledges each byte with the complement. The master uses this as a verification that the proper byte was rec'd.

Thus an ACK (function code 09H) would look like this:

FROM CAR (MASTER) ------------------------FROM HAMMER (SLAVE)
03 (# of bytes to follow)
-------------------------------------------------FC (252 in decimal)
XX( counter loops from 0 to 255)
------------------------------------------------ complement of the counter
09H ( function code ACK)
-------------------------------------------------F6H (complement of 09H)
03H
-------------------------------------------------no response from slave

In this way, the start up with the Alarm ECU, including handshake, stripped of the counter would look like this in hexadecimal:

55
0B
02
FD
0B
F4 F6
09 49
B6 30
CF 30
CF 41
BE 4C
B3 41
BE 52
AD 4D
B2
ACK Block from hammer

0E
F1 F6
09 39
C6 32
CD 38
C7 36
C9 31
CE 38
C7 32
CD 36
C9 30
CF 30
CF 30
CF
ACK Block from hammer

0F
F0 F6
09 30
CF 32
CD 31
CE 39
C6 39
C6 31
CE 30
CF 30
CF 38
C7 30
CF 31
CE 32
CD
ACK Block from hammer

ACK Block from car
ACK Block from hammer

edit: the forum software is not carrying over the formatting and indenting of the code to well.

 

A faster sampling rate is possible. Below is the hammer displaying battery voltage:


Data stream at 8800 baud:
A request from the hammer for the battery voltage with corresponding complement.
A response from the car to the hammer with corresponding complement
An ACK block from the Hammer
An ACK block from the car
do it all over again


06
01 F9
01 FE
00 FE
36 FF
C9

04
FB FE
01 CA
35
ACK Block from hammer

ACK Block from car

06
01 F9
01 FE
00 FE
36 FF
C9

04
FB FE
01 CA
35
ACK Block from hammer

ACK Block from car

06
01 F9
01 FE
00 FE
36 FF
C9

04
FB FE
01 CC
33
ACK Block from hammer

ACK Block from car

 

Martin,

There's an interpretation of the faults, a scheme that I have in my notes at home. Unfortunately, I'm travelling right now and won't be home till 1/13/2015.

My interest in this was from my desire to reverse engineer the hammer and use an 8 core 32 bit processor, an 4x20 lcd and a handheld case, much like the hammer. I'm into microprocessors, not much into windows based software.

How proficient are you at Delphi?

 

Hi mojorizing!
Thanks for your posts! They are very useful for me! The procedure from your first post is implemented in my programm. This works fine. I can read the porsche numbers and so on (I01ALARM, 92861826002, 251995008018). My first problem is that after the last character is read, I send an ACK and then I expected to get an ACK from the car. But I get an error because the blocktitle sent from the car is 0x0A and I do not know what this means. Perhaps there may be some timing problems in my procedures.
Your second post will be analysed by me in the next days. These values are very interesting for me! Up to now I can read inputs and actual values from the motronic. But these procedures do not run very well with the alarm. I will try to implement your procedure into my program. By the way: at the end of a block there must be a 0x03. You do not have the 03 in your numbers, but I think you stripped it like the blockcounter, right?
I searched a while for the interpretation of the error messages. If you have a solution I will be very pleased. I think that there are three blocks of errors and scantool4 does not show all errors. I have a problem with my radio (closed loop). My porsche dealer says that he can read error messages from the alarm, scantool4 shows no errors, an OBD tool from netherlands (for 928 to 993) shows a closed loop error. Scantools4 does not read any inputs of the alarm (with my 993). The shown numbers are not of any sense for me. I have the same problem with the CCU.
I program in delphi for many years, but I learned programming in the 80s (Pascal). So I am not very good in object oriented programming. But I programmed a lot of measurement software for biomechanic research (data acquisition).
If you have further protocols of other controllers and about reading memory, calculation formulas for values, reading inputs and actual values, please give it to me! Specialists like you are needed for this project! My knowledge about inputs, actual values and so on is so far generated from the config files of scantool4 and some websites about KW1281 and ISO9141.
Greetings!
Martin

 

OK, here I am again: I analysed your second post and can explain some parts. But some values are mysterious. Here are my ideas:

I think you used the Motronic because of 8800 baud! Battery Voltage=Input 2 (Scantool4). In the example a ramcell reading is done! First discrepance to Scantool4...
At 993 battery voltage = Ramcell 0x36! Perhaps the same at 964? Scantool has no adress 36 for the motronic for the 964.
Here is my interpretation of the values:

06 (Blocklength)
Complement Blocklength? Should be F9
Blocknumber?
Complement Blocknumber?
Blocktitle?
Complement Blocktitle?
01 (Value request; RAM reading = 0x01, needs three values, Nr ramcell, adress, adress )
F9 (??) (Complement value request? Should be FE! Why F9?)
01 (Value 1; 01 means: read one ramcell)
FE (Complement of value 1)
00 (Value 2; 00 could be a highbyte of the ramcell adress (16bit?)
FE (Complement of value 2?, should be FF? Why FE?)
36 (Value 3; 36 could be lowbyte of the ramcell adress 0036hex)
FF (?? no idea what this means; in my program I send a 0x03 as block end)
C9 (??no idea what this means)
Could the last two numbers be checksums or something like this?
Where is the blockend (0x03)?

Answer Car:
04 (Blocklength)
FB (Complement Blocklength)
Blockcounter?
Complement Blockcounter?
FE (Blocktitle (FE = Answer to RAMcell reading))
01 (Complement Blocktitle)
CA (battery value, 202 dez: 202*682/10000 = 13,77 Volt)
35 (Complement battery value)
Where is the blockend (0x03)?

ACK Block from hammer

ACK Block from car


Greetings!
Martin