One of the biggest hurdles to DIY on any of these cars that feature the F1 style transmission is being able to connect into the various ECU’s for reading data and controlling actuation on them.
Standard, off the shelf OBD readers can gleam only a small insight into a few of the engine parameters. It leaves all other computers (including the gearbox) untouched. To access these other computers, you either need to use (expensive) factory equipment like the SD series tools, or aftermarket (things like the Leonardo down to some of the cheaper Autel/Launch hardware).
I set out to find a lower cost way to achieve this and can be done with low cost ELM327 based scan tools. These range anywhere starting at around $10 and often contain sufficient hardware to read these computers.
I’ve been able to at this point, connect to the engine ECU and the gearbox ECU and be able to read arbitrary parameters out of them in real time. With this, I want to build a mobile phone based status screen to display in the car in real time.
Before I begin, I will note that without knowing exactly what functions corresponding to what, there is RISK OF BRICKING OR DAMAGING THE ECUS OR YOUR CAR. I highly suggest you don’t attempt these yourslef unless you know precisely what each of these entails and I can’t be held responsible.
Case Study #1 – Engine ECU
The engine ECU seems to respond using two different protocols. The first is ISO9141-2 on address 11. This is what most OBD readers seem to default to connecting to and give you access to all the standard EOBD functions (basic standard PIDs, engine codes, etc).
The system also seems to respond to ISO 14230-4 KWP (5 baud init, 10.4kbaud). However, the trick here is that the default address for nodes on this bus is 33. I needed to change this to 11 and was then able to establish a connection to the computer.
Once established, mode $21 commands can be sent to the computer (this the a standard way of getting addressed parameters from computers). Finding which address corresponds to which sensor/reading in the car is the tricky part and will take some time to solve. In an example here, I was able to locate what I believe to be the coolant temperature (by disconnecting the sensor and reconnecting, it was possible to see the values change as expected).
Note, that this is a different way of reading the coolant temperature than most scan tools will use(using generic EOBD). This is important to note because although reading coolant temp isn’t really interesting here, it opens the door to read other parameters on the computer that AREN’T accessible via normal OBD.
From this simple table, we can take a look at two separate measurements to try and figure out how to convert the response data into an actual temperature reading. Ideally, I would have more than two points here, but if we plug these measurements to find a fit slope,
Tc = (107 – 99) / (32 – 26) = 1.33
From there, we find the intercept.
b = 107-1.33(32) = 64
We can see a very simple relationship after a bit of rounding. Basically the coolant temperature appears to be raw = temp * 1.33 – 64, or temp = (raw-64)/1.33.
temp = (107-64)/1.33 = 32.3C and
temp = (99-64)/1.33= 26.3C
It will take some additional effort now to try and deduce some of what the other addresses are, and their meanings but this basic one shows that it’s possible to communicate with the ECU directly (outside of normal OBD modes).
Case Study #2 – Gearbox ECU
The gearbox is arguably the more interesting computer. Scan tools seem to find a second ECU on the bus at address $19 using ISO9141-2. Again, like the engine computer this seems to respond to basic EOBD type items, however mode $21 parameters are not accessible. However, when connecting using ISO 14230-4 KWP (5 baud init, 10.4kbaud) we seem to get a response which is good.
Parameters here will be a bit harder to figure out as there isn’t a EOBD equivalent that can be queried. Some are bit obvious due to the way that the system operates and by extracting and plotting a large number of these, certain parameters become somewhat obvious.
One such is the hydraulic system pressure. We know that it varies between 40-50 bar and oscillates between these two points. We can also see the data respond by jumping up when the pump kicks in, and slowly decaying until it meets the pumping threshold.
The raw readings (Say 02 16) need to be first converted from hex (base-16) to decimal (base-10) or 624 in this example.
By graphing finding some nice fitting points, we can get approximately to a equation that seems to match these two.
Pc = (624 – 522) / (50 – 40) = 10.2 (we will round down to 10 as we don’t know the *exact* pressures the pump turns on/off)
Now find the intercept again,
b = 624-10(50) = 124 and
b = 522-10(40) = 122
From this, we can probably approximate b should be 120.
pressure = (624 – 120) / 10 = 50.4 bar and
pressure = (522 – 120) / 10 = 40.2 bar
Which seem very reasonable.
If we now take periodic measurements over a few minutes, we get a data set that looks somewhat like this:
The data point at 02 80 corresponded with the F1 pump kicking in.
Graphing it, we can see clearly the pressure decaying, and the pump kicking in to get it raised again. The data here looks very reasonable.
Obviously the next big steps are to further map out various parameters through trial and error. This will be tedious and hard to do consistently for everything other tools have.
One set of parameters of big interest is the clutch closed/new/PIS measurements (see Setting Clutch PIS for why).
The other interesting thing is around setting actuators (e.g. adjusting PIS, bleeding the system, etc). Its not clear to me yet precisely what methods are used here yet but will be next part of the investigations.
Finally, the connection to the ECU’s does die after a short period of time (seems to be about 10 seconds) and re-establishing the comms on the protocol needs to happen. It’s likely there are some keep-alive messages that aren’t being sent. It can be worked around by continually requesting new parameter reads.