I've figured out how to program the tire size and pressure settings in JK vehicle ECUs (Electronic Control Units) via OBDII without depending on a commercial programmer.
I've done this on a 2018 JK.
This is done via the OBDII DLC (Data Link Connector) by the driver's left knee.
The basic low level protocol is ISO 15765-4 CAN, 11 bit ID, 500 kbaud. There is an addition protocol layer on top of or next to that that is similar to Keyword Protocol 2000, ISO 14230-3.
For tire size it appears that the speedometer ratio is in the TIPM (Totally Integrated Power Module) in "local identifier" 0x0c. That value is also programmed in the TCM (Transmission Control Module) in local identifier 0xb1. Plus there are a couple other rather cryptic values in that same location.
The general command stream for tire size is:
01C 3E 02 to unkn2, tester present
7DF 3E 02 to general, tester present
620 10 92 to tipm, diagnostic session control
to tipm, write local ID 0x0c
620 3B 0C 0E 92 03 E8 0F A0 p1 p2 FF FF 00 03 11 1B A0 01 00 01 02
01C 3E 02 to unkn2, tester present
7DF 3E 02 to general, tester present
620 10 92 to tipm, diagnostic session control
7E1 10 92 to tcm, diagnostic session control
write tcm local ID 0xb1
7E1 3B B1 6A 64 34 72 05 01 00 0A 02 00 05 10 27 27 01 06 02 02 0C 00 00 01 00 02 00 02 00 00 4F 01 92 0E E8 03 A0 0F p2 p1 23 00 qq rr 41 56 43 2D
784 11 82 to unkn4, reset
620 11 82 to tipm, reset
784 11 82 to unkn4, reset
7E0 11 82 to ecm, reset
All of the above values are in hexidecimal. The first three digit number in each line is the CID (Controller Identifier, i.e. addresses the TIPM, TCM, ECM, etc.) The second number is the SID (Service Identifier). The third number is the PID (Parameter Identifier). On data write the PID is followed by the data bytes as above.
The variable parameters for tire diameter are p1, p2, qq, and rr above. The appropriate p1 and p2 values are easy to calculate. P1 is the most significant byte and p2 is the least significant byte of a value that I'll call 'pp'.
pp = diameter (in inches) * 80 – 8
So for 32.75 inch diameter we have:
pp = 32.75 * 80 – 8
= 2612
Converting that to hex we have 0x0a34. The most significant byte, p1 = 0x0a. The least significant byte p2 = 0x34.
Note that the diameter should be the rolling diameter and not the unloaded diameter of the tire. An unloaded 34 inch tire has a rolling diameter of 32.75 inches once you put the weight of the vehicle on it.
I was not able to find a formula for the qq and rr values. The qq value might be a signed analog value and the rr might be flags. I don't know. So I just have a table of some observed values.
Diameter (inches) qq rr (hex)
31.2875 35 29
32.0 21 9d
32.25 e3 ad
32.5 eb 3d
32.75 ee cd
33.0 f7 5d
34.0 cf 9d
35.0 d5 5d
I was able to do the above with cheap commonly available OBDII interfaces. One was a Bafx and the other was the OBDLink SX USB. The Bafx uses a knock-off of the ELM327 chip. The OBDLink uses the STN1110 chip. One difficulty is that neither of them do multiframe writes correctly. The STN is a little better than the ELM. I had to hack around using tricks like going in and out of Auto Format (caf0/caf1) and Response (r0/r1) modes. It would be possible to create a clean interface using a Raspberry Pi and CAN bus interface but I was able to get by with the ELM/STN for my purposes.
- Happy Trails
I've done this on a 2018 JK.
This is done via the OBDII DLC (Data Link Connector) by the driver's left knee.
The basic low level protocol is ISO 15765-4 CAN, 11 bit ID, 500 kbaud. There is an addition protocol layer on top of or next to that that is similar to Keyword Protocol 2000, ISO 14230-3.
For tire size it appears that the speedometer ratio is in the TIPM (Totally Integrated Power Module) in "local identifier" 0x0c. That value is also programmed in the TCM (Transmission Control Module) in local identifier 0xb1. Plus there are a couple other rather cryptic values in that same location.
The general command stream for tire size is:
01C 3E 02 to unkn2, tester present
7DF 3E 02 to general, tester present
620 10 92 to tipm, diagnostic session control
to tipm, write local ID 0x0c
620 3B 0C 0E 92 03 E8 0F A0 p1 p2 FF FF 00 03 11 1B A0 01 00 01 02
01C 3E 02 to unkn2, tester present
7DF 3E 02 to general, tester present
620 10 92 to tipm, diagnostic session control
7E1 10 92 to tcm, diagnostic session control
write tcm local ID 0xb1
7E1 3B B1 6A 64 34 72 05 01 00 0A 02 00 05 10 27 27 01 06 02 02 0C 00 00 01 00 02 00 02 00 00 4F 01 92 0E E8 03 A0 0F p2 p1 23 00 qq rr 41 56 43 2D
784 11 82 to unkn4, reset
620 11 82 to tipm, reset
784 11 82 to unkn4, reset
7E0 11 82 to ecm, reset
All of the above values are in hexidecimal. The first three digit number in each line is the CID (Controller Identifier, i.e. addresses the TIPM, TCM, ECM, etc.) The second number is the SID (Service Identifier). The third number is the PID (Parameter Identifier). On data write the PID is followed by the data bytes as above.
The variable parameters for tire diameter are p1, p2, qq, and rr above. The appropriate p1 and p2 values are easy to calculate. P1 is the most significant byte and p2 is the least significant byte of a value that I'll call 'pp'.
pp = diameter (in inches) * 80 – 8
So for 32.75 inch diameter we have:
pp = 32.75 * 80 – 8
= 2612
Converting that to hex we have 0x0a34. The most significant byte, p1 = 0x0a. The least significant byte p2 = 0x34.
Note that the diameter should be the rolling diameter and not the unloaded diameter of the tire. An unloaded 34 inch tire has a rolling diameter of 32.75 inches once you put the weight of the vehicle on it.
I was not able to find a formula for the qq and rr values. The qq value might be a signed analog value and the rr might be flags. I don't know. So I just have a table of some observed values.
Diameter (inches) qq rr (hex)
31.2875 35 29
32.0 21 9d
32.25 e3 ad
32.5 eb 3d
32.75 ee cd
33.0 f7 5d
34.0 cf 9d
35.0 d5 5d
I was able to do the above with cheap commonly available OBDII interfaces. One was a Bafx and the other was the OBDLink SX USB. The Bafx uses a knock-off of the ELM327 chip. The OBDLink uses the STN1110 chip. One difficulty is that neither of them do multiframe writes correctly. The STN is a little better than the ELM. I had to hack around using tricks like going in and out of Auto Format (caf0/caf1) and Response (r0/r1) modes. It would be possible to create a clean interface using a Raspberry Pi and CAN bus interface but I was able to get by with the ELM/STN for my purposes.
- Happy Trails
