Ok. so we’ve set ourselves up to be able to look at what is going on with a Caterham diagnostics port, we’ve talked a bit about the theory of what we might see from the port and we’ve also seen that Easimap talks to the ECU using a higher level protocol called ISO 15765-2 (ISOTP). We also saw how Easimap is asking the ECU for its model and serial number.
Easimap Data Request Protocol
At about this time, we also made a bit of a leap in our understanding of the communications between Easimap and the car.
We’d seen how Easimap sending 0x04000d to the car gave a response of the model and serial numbers (0xe4000d23394134626535333000). Notice how the first byte of the request is 0x04 and the first byte of the response is 0xe4. Seemed to me as though the response was echoing the 4 and setting some higher order bits creating a response code of 0xe4… Hmm…
If we look further down the communications that Easimap sends to the car (with the default gauges and pages set in Easimap) then we can also see some patterns.
It seemed to me that the first byte of the model/serial request was going to be a message type (0x04 means get some config data).
Looking through the next communications we see Easimap send:
0x0100000000126667a8a9
and gets a response of:
0x81aaaa1600
If we think back to the 0x04 and 0xe4, request/response, of the model/serial exchange then this new exchange looks like a request/resonse of 0x01/0x81. That’s the same sort of pattern… a request of 0x01 and a response with the topmost bit set. That’s starting to make sense, but what of all the other data?
It was at about this time that James (Aerobod) had been looking at his car and had seen a pattern where there was an Lowest Significant Byte (LSB) and Most Significant Byte (MSB) being sent periodically that matched some of the data he was looking for.
It then dawned on me that my previous hunch about pages and addresses in the EC2 files was starting to make sense. If we look at our request to the car of:
0x0100000000126667a8a9
then the first byte we know about (0x01) and then there are some more bytes of 0x00 with a 0x12 next, that could a page. Then there are sequences of similar numbers 0x66 followed by 0x67, then 0xa8 followed by 0xa9. They could be addresses.
I searched the EC2 file for 0x6667 and 0xa8a9 but there wasn’t anything that made sense.
It then occurred to me that perhaps the pages and addresses in the EC2 file weren’t being used exactly as written in the file. And if James’ thinking about LSB and MSB was right then perhaps the 0x6667 was the LSB of the address in the EC2 file followed by the same LSB+1.
With the data we have above that would mean we needed to look in the EC2 file for a variable with a page of 0x12 and address LSB of 0x66. A quick search in our EC2 file turns up:
[RT_IGNITIONADVANCEBANK1] Number of Dimensions = 0 Page = 12 Address = 6766 Bytes per Cell = 2 0 = SCALE_NADV
Some of the right data was present, the 12, 66 and 67 were there. And it seemed to indicate that this was related to Ignition Advance Bank1. Ok, that could be, our Caterhams could have something like that in them.
Next was to look at the response from the car:
0x81aaaa1600
We know that 0x81 is the response type for a request of 0x01. That leaves data of 0xaaaa1600. That’s probably 0xaaaa and 0x1600. Neither seemed to make much sense for an Ignition Advance Bank 1 response. It could be right, it could be wrong.
At this point I also started to pull apart the test.lsn file I’d found in the Easimap configuration directories on the PC. That file seemed to be the setup Easimap was using to say what gauges and displays to put on the screen for each “page” of the software display. It had a section like this:
[Parameters] RT_THROTTLESITE1, Throttle Position|Throttle Position Limits and Default Setup, Throttle Site 1 RT_BATTERYVOLTAGECOMP, Fuel|Voltage Fuel Compensation, Battery Voltage Comp RT_ENGINESPEED, Engine Speed Setup & Limiter, Engine Speed RT_IGNITIONADVANCEBANK1, Ignition, Ignition Advance RT_TPSVSSPEEDIGN+TRIM1, Ignition, TPS vs Speed Ign + Trim RT_INJECTIONTIMEA, Fuel, Final Injection Time RT_COOLANTTEMP1(LIM), Sensors|Coolant Temperature, Coolant Temp RT_AIRTEMP1(LIM), Sensors|Air Temperature, Air Temp RT_MAPPINGPOT1LIM, Mapping Box|Mapping Pot 1, Mapping Pot 1 RT_MAPPINGPOT2LIM, Mapping Box|Mapping Pot 2, Mapping Pot 2 RT_COOLANTFUELFACTOR, Fuel|Coolant Temperature Compensation, Coolant Fuel Factor RT_BATTERYVOLTAGE(LIM), Sensors|Battery Voltage, Battery Voltage RT_AIRTEMPFUELFACTOR, Fuel|Air Temperature Compensation, Air Temp Fuel Factor RT_DUTYCYCLEA, Fuel|Duty Cycle, Duty Cycle RT_TPSFUEL+TRIMBANK1, Fuel, TPS Fuel + Trim RT_SOFTCUTTIME, Engine Speed Setup & Limiter, Soft Cut RT_HARDCUTTIME, Engine Speed Setup & Limiter, Hard Cut RT_THROTTLEANGLE1(RAW), Throttle Position|Throttle Position Limits and Default Setup, Throttle Angle 1 (Raw) RT_ENGINERUNTIME, Data Logging, ERT RT_ECUSTATUS, Fault Conditions, ECU Status RT_BAROSCALEDLIM, Sensors|Barometric Pressure, Baro Pressure RT_THROTTLEANGLEINCREASING, Throttle Position|Throttle Position Limits and Default Setup, Throttle Angle Increasing RT_BAROFUELCOMP, Fuel|Barometric Pressure Fuel Compensation, Barometric Pressure Fuel Compensation RT_CRANKCOUNT, Development, Crank Count
That was clearly a list of variables (in upper case) that Easimap was going to request data for from the car.
And an obvious candidate for a search in there was RT_ENGINESPEED, or Engine RPMs. I knew that I’d not had the car engine running when I did my packet captures, so there was a good chance that if I found the request for RPM then I could see a response of with zeros back from the car.
Looking in the EC2 file, you can find definition of RPM variable as:
[RT_ENGINESPEED] Number of Dimensions = 0 Page = F8 Address = 237C Bytes per Cell = 2 0 = SCALE_ENGINESPEED
Ok. So, we’ll looking for a request with a page of 0xf8 and an address that’s either 0x237c or possibly 0x7c7d.
Looking through the CAN bus as ISOTP output again we find this request:
0100000000f83031363744454c4d4e4f50515a5b5c5d646a6b7c7d9e9fa0a1d8d9dadb
and this response:
814e39094a9c52b886e8844e39a80d70a000b04f00005695800900800080
In the request there’s the 0x01 at that start that is some kind of data request and the corresponding 0x81 in the response. We then see 0xf8 after the 4 x 0x00’s. Ok, that’s looking good, we’re looking for a page of 0xf8 for RT_ENGINESPEED.
We can also see that 3/4 of the way along the request we can see 0x7c7d. If we break the request down into the bit at the start (pre-amble) of 0x0100000000f8 and then the pairs that could be LSB/MSB combinations, then we get this:
0100000000f8 3031 3637 4445 4c4d 4e4f 5051 5a5b 5c5d 64 6a6b 7c7d 9e9f a0a1 d8d9 dadb
That’s all looking good for the LSB/MSB theory of LSB/LSB+1 and shows us that 0x7c7d is 19 bytes into the data section. I also took note that some data being requested has only one byte of request information… I’ll need to remember that later.
Now if we look at the response from the car and break it down like the request data and slot in the request data on the left:
Request Response 0100000000f8 = 81 3031 = 4e39 3637 = 094a 4445 = 9c52 4c4d = b886 4e4f = e884 5051 = 4e39 5a5b = a80d 5c5d = 70a0 64 = 00 6a6b = b04f [7c7d = 0000] 9e9f = 5695 a0a1 = 8009 d8d9 = 0080 dadb = 0080
Then… low and behold… where I’ve put brackets around the line, we can see that our theory about RT_ENGINESPEED needing a request of 0x7c7d is returning 0x0000 in exactly the right spot in the response… showing that the car isn’t running.
That’s good enough for me… I think my theory is as good as I’m going to get, I need to write some code to test this out.
Leave a Comment