mojorizing

Martin,

Yes, 964 motronic is 8800. And as you say, the 03H endblock is also stripped off.

The cut and paste to the forum software pretty much wiped out the formatting. PM me your email address and I'll send you all the streams that I have - the flow of data will be obvious.

I haven't researched how fault tolerant the protocol is, and if there's a checksum, or simply checking if the correct corresponding complement is rec'd.

Kevin

dochilli

Hi!
I have got very nice data of hammer streamings from kevin and I am analyzing these data now. My first result is, that my error reading procedure for the alarm could not work. From the alarm the errors are not read with the Blocktitle 0x07 (get errors), which seems to be the right procedure for the other controllers. Instead the errors are read from memorycells (Blocktype 0x01). So forget my data that I posted at the beginning of this thread, these do not have any sense. I will program a new error reading procedure and then I am hopeful that I will get good results. The errors are read in three blocks of 4, 2 and 1 byte. The interpretation is unclear, but Kevin said that he has a paper with some explainations.
The alarm is not manufactured by Bosch, perhaps that is the reason for the unusual error reading.
Martin

dochilli

OK, here are some news:
I tried to programm the reading of actual values for the ccu and I had some success. Attached you will find an Excel-File with two readings of 21 ADC channels.
Some readings I can interprete but some are unclear for me. Up to now I can see two differences compared to the 964. The left and right mixing temp are on other channels at the 993. If someone knows something about the unclear channels, please let me know.
Very helpful were the hammer data of the 964 from Kevin. If someone has hammer data of the 993, please contact me. Unclear are especially the linear equatations for the temperatures.
For some temperatures (inside, left/right mix) I could calculate the formulas for the linear equations. When the wheather in germany will be better, the oil cooler temperature can be found easy by driving the car.
I can also read the switches (ACmax, ACmin, Defrost and Aircirc) without problems.
My procedure for the actuator activation does not work yet, but I hope that I can get it to work in the next days.
Error reading works too, I have no errors in my CCU and the error reading procedure shows no errors. The error delete procedure seems to work too.
My next steps will be:
- to get a working actuator activation
- to program an error reading procedure that gives out some error codes and descriptions. I do not know a lot about the error coding in the ccu.
- to program the next ECU (perhaps the alarm; there I have some working procedures, but I need some more information (error coding, ...)).

Greetings
Martin

mojorizing

Excellent info in your attachment - all I can add is from my notes ADC Channel 20 is "actual voltage".

For actuators, look into my "Drive Links" Folder under CCU.
Basically it's an 04H request to actuate, car answers back with F5. Subsequent bytes are an analog read (08H) as the flapper, etc is opened/closed.

Example 04H 03H (stripped of bytes to follow, counter, and 03H end) is right mixing flap to open. Then 08H 07H to read the analog value as the flapper opens. car answers this analog request with 00H XXH where XX goes from 0 (closed) to FF (open). 04H 20H is the right mixing flap to close.

Kevin

dochilli

Hi!
Here are some pictures of my program. Most procedures for the CCU are working and I can read inputs, sensors and part numbers. Error reading and deleting are running well. I tried to activate an actuator and it seems to run.
I do not know some equations for the temperature calculation (rear blower, oil cooler, evap, the program shows the ADC values). The other equations were calculated by myself.
For the interpretation of the error codes (4 Bytes) there could be a solution, but were are not sure. Perhaps the first byte contains the error number. My CCU does not show errors, so I could not test a result with errors.

Now I try to read the alarm. Serial numbers and so on can be read, but if I try to read the error memory I get an error. The Ecu does not answer and sends a blocktitle 10 (no acknowlegement). The procedures to contact the ecu are the same as in CCU, but they do not not work. I have to do some more research...

Martin

dochilli

I made some more steps forward:
The reading of the alarm works. I can read the errors, delete the errors and read some inputs of the alarm. My results are in the attached excel file. Some bits of the second value of the inputs are unclear and I do not know what the third byte shows. In my data there is a 129 in Kevins Hammer data there is a 128 or a 0. Perhaps my radio closed loop problem may cause this.
Up to now, I do not know anything about the error numbers. I get a 16 in the sixth error byte and this must be the radio closed loop problem. I need more information in decoding of the error bytes in the alarm...
Martin

01coccobet

following this interesting trd
keep on thanks

BesideTheBox

Great detective work - you are making great progress.

Kevin's signature indicates that he has a Targa. Perhaps the bit reflecting 16 in byte number 2 is for the Targa top open/closed.
And perhaps a convertible has 2 sensors reflecting 16 and 32 in byte number 2?
It could be that both 64 and 128 are always set or cleared together, indicating (set) that the alarm cannot be set or (not set - clear) that the alarm can be set. Perhaps that designers thought that it would be better security to set and check 2 bits.

dochilli

I made some tests and the 16 in Byte 2 stands for Ignition on or off. As far as I know, the roof of a targa or the cab are not controlled by the alarm. There are some other inputs left that I did not / can not test:
- In some cabs there is a rear parcel shelf behind the seats (could be 64 or 128 in byte two)
- The radio is controlled by a ground contact. If you draw the radio, it gets ground contact (could be 64 or 128 in byte two). Perhaps I can conect my radio sensor (green cable) to ground and then I can see, which bit is set.
- The closed loop control of the radio (may be in 1 of byte 3? draw fuse of radio and test bytes 3)
- Interior control in some cab (mine has no)
- microswitches for activation and deactivation
- speedo signal?
Because of the quantity of inputs I think that all bits of byte 2 are used, although it is not so safe.
So there are some problems left and I have to search a little bit more.

For the error messages I could solve some problems. I tried to activate the alarm with open doors, hood, glove box and so on and got some different error messages. I can not see any systematic to calculate the porsche error numbers/messages from these results, but I can code some error messages for my program.

Martin

ToreB

Martin, keep up the good work!
The alarm module has two or three extra (unused) alarm inputs, one of them is the cabrio rear parcel shelf.
You are right about the radio, the green wire should be left unconnected/insulated if you have a (aftermarket)radio installation frame without the alarm contact.
The alarm module has an Event log too, in addition to the fault codes. This contains recent events, and can be erased by the OBD tool. I guess you already has seen the list of fault codes in the Scantool Trouble Codes files?

I have a full test bench for the alarm module and could take some OBD logs. PM/email if you need help.
Cheers,
Tore

dochilli

Hi Tore!
Yes I saw the error messages in ScanTool4 and I read the porsche workshop manual, where all errors are described. Most of the errors can be decoded from the seven error bytes (especially Byte 4,5,6) and are shown in my program.
Interesting for me is the info that there is a event log. Do you know, how this can be read (Blocklength, Blocktitle and so on)? Do you have an OBD log or more information about this?
What does the speedometer in your device? Can this be read as a input?
Martin

993c4ie

Old-ish thread coming back alive...
Out of interest, i have written a quick pc application which sniffes the data exchanged between the Scantool software and my car (1995 993C4) OBD-enabled component, and parses the blocks.

Find attached a complete trace of Scantool CCU exchanges.

Few questions:

1- Anybody could please tell me what OBD block title value Hex14 (0x14, decimal20), HexF3 and Hex F7 mean?

2- do not see how the "Actual Values" , e.g. Cabin temperature, are read? I see the "block request" e.g. title 0x01, and no the replies ?

3- What are the "Switches" inputs , e.g. AC & ACM , and how is their state read?

Thanks in advance

mojorizing

Cool,

1) Those "block titles" are the responses from slave to master as the data stream progresses. See table 3.2.6 at https://dl.dropboxusercontent.com/u/.../Fiat-9141.pdf
I have not seen 0xF3 and 0x14 combo, need to look at my notes.

2) Are you actually receiving "Actual Values" when running Scantool? It appears that you're getting back the response (F7) to an ACK block, when you should be getting back block title FE (ram cell reading request) followed by the value in HEX. See http://members.rennlist.org/mojorizi...ualvalues2.txt for the actual value data stream with ACK blocks substituted and block numbers and ending 03 H stripped out.

3) I have to look at my notes.

993c4ie

Thanks for the document, very helpfull.

993c4ie

Hi Kevin,
I am wondering if you have had a chance to look at your notes?


>> Are you actually receiving "Actual Values" when running Scantool?
This is my first time running Scantool, so not 100% sure as to what to expect.
But i am not getting "Actual Values" from waht i can see,
For instance , Scantool displays a blank window when reading the Alarm actual values?

Or display "1" for all the ABS actual values like "Stop Light SW", "Valve Relay", etc...