Difference between revisions of "OBD2 Diagnostics reading project"

From BigJimny Wiki
Jump to navigation Jump to search
 
(39 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
= Suzuki Jimny JB74 (2021) - Reading TPMS data over the diagnostic CAN link =
+
= Suzuki Jimny JB74 (2018+) - Reading TPMS data over the diagnostic CAN link =
  
−
'''Status:''' work in progress. Based on one RHD UK-market 2021 Jimny with factory TPMS, owner-made PCAN-View captures, and the Suzuki wiring diagrams (A-8 CAN communication and A-8 Central Gateway/DLC). Items marked ''unconfirmed'' are not yet verified.
+
{{Donate}}
 +
== Overview ==
 +
Purpose-built diagnostic tools (Autel, Launch and similar) already support Suzuki comprehensively. There is also a trend towards replacing the factory head unit with an Android media unit that can run apps to read and display information from the car's electronics. These units are not Suzuki-specific, so this project aims to learn how to read vehicle data (starting with the factory TPMS) and show it on the head unit.
 +
 
 +
=== Equipment ===
 +
{| class="wikitable"
 +
! Role !! Item
 +
|-
 +
| Head unit || XTRONS PX90
 +
|-
 +
| OBD-II Bluetooth dongle 1 || Generic ELM-based (Chinese)
 +
|-
 +
| OBD-II Bluetooth dongle 2 || Veepeak OBDCheck BLE+ (BLE only; works on a Lenovo tablet, will not connect to the head unit)
 +
|-
 +
| CAN bus monitor (Windows) || PCAN-View (PEAK-System)
 +
|-
 +
| Diagnostic tool 1 || Launch X431 CRP919
 +
|-
 +
| Diagnostic tool 2 || SZ Viewer app
 +
|-
 +
| Apps tried || Torque Pro (fails past the first line; tested on a Lenovo tablet), Car Scanner Pro (works), RealDash (TPMS values seen in its debug view; gauges in progress)
 +
|-
 +
| Head-unit Bluetooth || xTRONS IP90  - Classic Bluetooth only, no BLE support
 +
|}
 +
 
 +
=== Method ===
 +
# The diagnostic tools (Launch X431, SZ Viewer) have comprehensive Suzuki support, so they are used to generate the CAN bus requests.
 +
# PCAN-View is connected to the OBD socket to capture the requests and the module's replies, which are then decoded by hand.
 +
# The decoded requests are recreated in the head-unit apps so the head unit can ask the car for the same data directly.
 +
'''Status:''' work in progress. Based on one RHD UK-market 2021 Jimny with factory TPMS, owner-made PCAN-View captures (including a full Launch scan and an instrument cluster test), the Suzuki wiring diagrams (A-8 CAN communication and A-8 Central Gateway/DLC) and the Suzuki parts catalogue. TPMS readings work in Car Scanner Pro; RealDash works in its debug view with gauges in progress. Items marked ''unconfirmed'' are not yet verified.
  
−
== Summary ==
 
 
* The TPMS control module answers an ordinary diagnostic request on the OBD socket. It does not broadcast tyre data.
 
* The TPMS control module answers an ordinary diagnostic request on the OBD socket. It does not broadcast tyre data.
−
* Request ID '''0x798''', reply ID '''0x7A8''', 11-bit CAN, 500 kbit/s, ISO-TP framing.
+
* Request ID '''0x798''', reply ID '''0x7A8''' (11-bit CAN, 500 kbit/s, ISO-TP framing) returns the TPMS data, including four sensor IDs and pressure readings. The module's identification reply (37160-61M0) matches the Model No. (P61M0) on the TPMS controller label. Whether the central gateway forwards or remaps the request is unconfirmed.
 
* Service '''0x21''' (read data by local identifier), identifier '''0x00''', returns 102 bytes containing all four sensor records.
 
* Service '''0x21''' (read data by local identifier), identifier '''0x00''', returns 102 bytes containing all four sensor records.
 +
* Pressure is byte +6 of each sensor record: bar = raw x 0.01372.
 
* The OBD socket is fed by a central gateway, so only diagnostic traffic is visible on it.
 
* The OBD socket is fed by a central gateway, so only diagnostic traffic is visible on it.
 +
* Working: Car Scanner Pro, and RealDash (values seen in its debug view). Not working: Torque Pro.
  
 
== DLC (OBD socket) wiring ==
 
== DLC (OBD socket) wiring ==
Line 27: Line 57:
  
 
Use pins '''6''' and '''14''' for a CAN adapter. The diagram does not label CAN-H and CAN-L itself.
 
Use pins '''6''' and '''14''' for a CAN adapter. The diagram does not label CAN-H and CAN-L itself.
 +
 +
=== Cross-check with other reports ===
 +
A BigJimny forum thread ("JB74 OBD2 connection", December 2020) describes a 2020 JB74 whose OBD plug had pins 4, 5, 6, 14, 15 and 16 wired, with pin 7 (K-line) not wired. The poster, quoting an older Suzuki pinout, lists pin 6 as a blue wire (CAN-H) and pin 14 as a white wire (CAN-L). This matches the table above: a blue CAN wire on pin 6 and a white one on pin 14.
 +
 +
* The CAN-H/CAN-L assignment in that thread comes from a pinout reference that the poster says predates the JB74, so it is a report, not a measurement.
 +
* No wire for standard pin 7 (K-line) appears on the diagram page above, and the forum report also found it unwired. K-line is therefore unlikely to be available on the JB74 socket.
 +
* On the forum poster's car, pin 15 was also wired; the diagram page above shows no wire for it. This may be a market or model-year difference.
  
 
== Network layout ==
 
== Network layout ==
Line 45: Line 82:
 
| <code>1A 8A</code> || <code>5A 8A</code> + ASCII <code>37120-78R0*</code> || ECU identification
 
| <code>1A 8A</code> || <code>5A 8A</code> + ASCII <code>37120-78R0*</code> || ECU identification
 
|-
 
|-
−
| <code>1A 8E</code> || <code>5A 8E</code> + ASCII <code>37160-61M0</code> || ECU identification
+
| <code>1A 8E</code> || <code>5A 8E</code> + ASCII <code>37160-61M0</code> || ECU identification: matches the "Model No. P61M0" printed on the TPMS controller label
 
|-
 
|-
 
| <code>18 00 FF 00</code> || <code>58 00</code> or <code>58 01 9A 31 E0</code> || Read DTCs by status (second form = one code reported; not decoded)
 
| <code>18 00 FF 00</code> || <code>58 00</code> or <code>58 01 9A 31 E0</code> || Read DTCs by status (second form = one code reported; not decoded)
Line 51: Line 88:
 
| <code>21 00</code> || <code>61 00</code> + 100 bytes || Sensor data block (repeated about twice a second by the scan tool)
 
| <code>21 00</code> || <code>61 00</code> + 100 bytes || Sensor data block (repeated about twice a second by the scan tool)
 
|}
 
|}
 +
Part labels on the test car: TPMS controller 37160-78R00, "BASE ASSY-TPMS", Model No. P61M0, Continental A2C13930301, 433.92 MHz; central gateway controller 33580-79R01. The <code>1A 8E</code> reply (37160-61M0) matches the TPMS controller's base number and model number; the <code>1A 8A</code> reply (37120-78R0*) shares "78R0" with the full part number, but its meaning is not confirmed.
 +
 +
A Launch full scan reported "Left Front Tire Pressure Low" for the TPMS module, and the module returned one stored code (<code>9A 31</code>) in the same scan. That code is probably the low-pressure warning (inferred; the report does not show the code itself).
  
 
== Reading it with an ELM327 ==
 
== Reading it with an ELM327 ==
Line 67: Line 107:
 
* <code>ATSH798</code> sets the request address. The reply address (0x7A8) is worked out automatically.
 
* <code>ATSH798</code> sets the request address. The reply address (0x7A8) is worked out automatically.
 
* <code>ATFCSH798 / ATFCSD300000 / ATFCSM1</code> make the adapter send the ISO-TP flow-control frame (30 00 00) itself.
 
* <code>ATFCSH798 / ATFCSD300000 / ATFCSM1</code> make the adapter send the ISO-TP flow-control frame (30 00 00) itself.
−
* <code>ATS0</code> removes the spaces between bytes. Without it, one clone adapter reported <code>BUFFER FULL</code> near byte 81.
+
* <code>ATS0</code> removes the spaces between bytes. Without it, the generic Chinese ELM327-based dongle (dongle 1) reported <code>BUFFER FULL</code> near byte 81.
 
* Expected output: a length line (<code>066</code> = 102 bytes) and numbered lines <code>0:</code> to <code>E:</code>.
 
* Expected output: a length line (<code>066</code> = 102 bytes) and numbered lines <code>0:</code> to <code>E:</code>.
−
* With default settings the same adapter returned only the first line (<code>61 00 xx 01 00 00</code>).
+
* With default settings dongle 1 returned only the first line (<code>61 00 xx 01 00 00</code>).
  
 
== Reply layout (21 00) ==
 
== Reply layout (21 00) ==
Line 103: Line 143:
 
| +5 || Value 57-74. Behaves like temperature, possibly with an offset of 40 (''unconfirmed'')
 
| +5 || Value 57-74. Behaves like temperature, possibly with an offset of 40 (''unconfirmed'')
 
|-
 
|-
−
| +6 || Pressure candidate (see calibration)
+
| +6 || Pressure, gauge: bar = raw x 0.01372 (see Calibration)
 
|-
 
|-
 
| +7, +8 || Not understood
 
| +7, +8 || Not understood
Line 123: Line 163:
 
Sensor IDs are specific to one car. Yours will differ.
 
Sensor IDs are specific to one car. Yours will differ.
  
−
== Calibration (provisional) ==
+
== Calibration ==
−
Byte +6 against gauge readings:
+
Byte +6 against gauge readings (bar). The five deflation-test counts were reconstructed from the app's displayed values.
 
{| class="wikitable"
 
{| class="wikitable"
−
! Raw !! Gauge
+
! Raw !! Gauge (bar) !! Raw x 0.01372
 +
|-
 +
| 136 (rear left) || 1.868 || 1.866
 +
|-
 +
| 131 (rear right) || 1.795 || 1.797
 
|-
 
|-
−
| 136 (rear left) || 1.868 bar
+
| 131 (front right) || 1.795 || 1.797
 
|-
 
|-
−
| 131 (rear right) || 1.795 bar
+
| 126 || 1.73 || 1.729
 
|-
 
|-
−
| 131 (front right) || 1.795 bar
+
| 119 || 1.63 || 1.633
 
|-
 
|-
−
| 128 (front left, start) || about 25 psi (from memory)
+
| 112 || 1.54 || 1.537
 
|-
 
|-
−
| 110 (front left, lowest) || about 21 psi (from memory)
+
| 101 || 1.39 || 1.386
 +
|-
 +
| 96 || 1.29 || 1.317
 
|}
 
|}
−
Straight-line fit through these points:
+
The last five rows are from one tyre, the front left, during a slow deflation.
−
* bar = raw x 0.01627 - 0.344
+
* bar = raw x 0.01372
−
* psi = raw x 0.236 - 5
+
* psi = raw x 0.199
  
−
The two front-left gauge values were remembered, not recorded, and most of the fit comes from them. Treat the equations as an estimate to be replaced by better data.
+
No offset is needed, which suggests the byte holds gauge pressure. All points are within 0.004 bar except the lowest (0.027 bar off), which may be sensor update lag or slight non-linearity. More readings at low and high pressure are needed.
  
 
== Torque Pro custom PIDs ==
 
== Torque Pro custom PIDs ==
Line 160: Line 206:
 
Equation uses a letter for each data byte. <code>A</code> is the first byte after <code>61 00</code> (reply byte 2).
 
Equation uses a letter for each data byte. <code>A</code> is the first byte after <code>61 00</code> (reply byte 2).
 
{| class="wikitable"
 
{| class="wikitable"
−
! Wheel !! Byte +5 (temperature?) !! Byte +6 (pressure candidate)
+
! Wheel !! Byte +5 (temperature?) !! Byte +6 (pressure candidate)” to “Byte +6 (pressure)”
 
|-
 
|-
 
| Front left || P || Q
 
| Front left || P || Q
Line 170: Line 216:
 
| Rear right || AJ || AK
 
| Rear right || AJ || AK
 
|}
 
|}
−
Example: <code>Q*0.01627-0.344</code>. Letters must be upper case. Whether Torque accepts two-letter variables is ''unconfirmed''.
+
Example: <code>Q*0.01372</code>. Letters must be upper case. Whether Torque accepts two-letter variables is ''unconfirmed''.
  
 
=== Known problem ===
 
=== Known problem ===
−
On the test setup Torque read bytes <code>A</code> to <code>D</code> (first line of the reply) correctly, but every byte from <code>E</code> onward returned -1, even though a terminal received the full 102 bytes with the same commands. The start-command field is applied (adding <code>ATH1</code> changed the output). Tried without success: turning off "Faster communication", removing <code>ATS0</code>. Not yet tried: <code>ATAT0, ATSTFF</code> timeout settings, other apps, other adapters. Unresolved.
+
Using dongle 1 (generic Chinese ELM327-based) with Torque Pro on a Lenovo tablet, Torque read bytes <code>A</code> to <code>D</code> (first line of the reply) correctly, but every byte from <code>E</code> onward returned -1, even though a terminal received the full 102 bytes with the same commands. The start-command field is applied (adding <code>ATH1</code> changed the output). Tried without success: turning off "Faster communication" and removing <code>ATS0</code>. Not tried: <code>ATAT0, ATSTFF</code> timeout settings.
 +
 
 +
Dongle 2 (Veepeak OBDCheck BLE+), also on the tablet, gave the same result. Car Scanner Pro reads every byte with both dongles and the same commands, so the limitation is in how Torque Pro handles this multi-line reply, not in the adapter or the Android device. Unresolved; a request has been posted on the Torque forum.
 +
 
 +
== Car Scanner Pro (working) ==
 +
Car Scanner Pro reads all the bytes where Torque Pro fails. Custom PID settings used:
 +
* Header: 798
 +
* Request: 2100
 +
* Start command (backslash-separated): <code>ATAT0\ATSTFF\ATS0\ATL0\ATFCSH798\ATFCSD300000\ATFCSM1</code>
 +
* Equations use the same letters as the table above, for example <code>Q*0.01372</code> for front left (bar)
 +
 
 +
The start command has not yet been shortened. Both dongle 1 (generic ELM327-based) and dongle 2 (Veepeak OBDCheck BLE+) work with Car Scanner Pro on the Lenovo tablet. Dongle 2 will not connect to the XTRONS head unit.
 +
 
 +
== RealDash ==
 +
RealDash describes its OBD2 communication in an XML file. With dongle 1, RealDash's default init plus the lines below works: the TPMS sensors reply, and the values appear in RealDash's debug view. Dashboard gauges are in progress.
 +
 
 +
Changes to RealDash's default file:
 +
* Add the three flow-control commands to the init section, before the <code>0100</code> and <code>0120</code> checks.
 +
* Every TPMS command sets <code>header="atsh798"</code>. The docs say to set the header on every command when the rotation uses more than one. Any standard command in the same rotation then needs <code>header="atsh7df"</code>, or it would be sent to 0x798.
 +
* RealDash requires <code>ATE0</code>, <code>ATL0</code> and <code>ATS0</code> (already in its default init).
 +
 
 +
<pre>
 +
<init>
 +
  ... RealDash default init lines ...
 +
  <command send="atfcsh798"></command>
 +
  <command send="atfcsd300000"></command>
 +
  <command send="atfcsm1"></command>
 +
  <command send="0100"></command>
 +
  <command send="0120"></command>
 +
</init>
 +
<rotation>
 +
  <command send="2100" header="atsh798" skipCount="10" keepInRotation="true" name="TPMS: front left" units="bar" conversionABC="Q*0.01372"></command>
 +
  <command send="2100" header="atsh798" skipCount="11" keepInRotation="true" name="TPMS: front right" units="bar" conversionABC="AU*0.01372"></command>
 +
  <command send="2100" header="atsh798" skipCount="12" keepInRotation="true" name="TPMS: rear left" units="bar" conversionABC="AA*0.01372"></command>
 +
  <command send="2100" header="atsh798" skipCount="13" keepInRotation="true" name="TPMS: rear right" units="bar" conversionABC="AK*0.01372"></command>
 +
</rotation>
 +
</pre>
 +
 
 +
<code>conversionABC</code> uses the same letters as Torque and Car Scanner (A is the first byte after 61 00). The TPMS inputs appear in RealDash's ECU Specific category.
 +
 
 +
The Veepeak OBDCheck BLE+ (dongle 2) will not connect to the head unit because the head unit does not support BLE, so only dongle 1 was used.
 +
 
 +
== Other modules found by a full scan ==
 +
A full health-check scan with a Launch X431 CRP919, captured with PCAN-View on the OBD socket, shows 12 modules answering on the DLC. Every module that replied is listed here. The reply ID is not always the request ID plus 8.
  
−
== Open questions ==
+
{| class="wikitable"
 +
! Request !! Reply !! Protocol !! Identification replies !! Module !! How identified
 +
|-
 +
| 0x7E0 || 0x7E8 || KWP || 33980-78R0, 33980-78RC* || ECM || Standard engine address
 +
|-
 +
| 0x261 || 0x661 || KWP || 56100-77RA, 56100-78RF* || ABS (inferred) || Only brake module left by elimination
 +
|-
 +
| 0x263 || 0x663 || KWP || 38720-77R0, 38720-77R0* || EPS controller || Parts catalogue
 +
|-
 +
| 0x271 || 0x671 || KWP || 36775-77R0, 36775-77RC* || Body control module || Parts catalogue
 +
|-
 +
| 0x274 || 0x674 || KWP || 34100-78R0, 34110-78RD* || Instrument cluster || Rev counter sweep test
 +
|-
 +
| 0x798 || 0x7A8 || KWP || 37160-61M0, 37120-78R0* || TPMS controller || Label and parts catalogue
 +
|-
 +
| 0x79A || 0x7AA || KWP || 37210-74PA, 37210-74PE* || Lighting and turn switch || Parts catalogue
 +
|-
 +
| 0x778 || 0x788 || KWP || 33990-52R0, 33990-78R8* || Dual sensor brake support || Parts catalogue
 +
|-
 +
| 0x793 || 0x7A3 || UDS || 38910-77R0, 38910-78RC* || Airbag (SRS) controller || Parts catalogue
 +
|-
 +
| 0x772 || 0x782 || UDS || 38885-77R0, 38885-78R0* || 4WD shift controller || Parts catalogue
 +
|-
 +
| 0x799 || 0x7A9 || UDS || 38960-78RA, 38960-78RA* || E-call controller || Parts catalogue
 +
|-
 +
| 0x751 || 0x761 || UDS || 33580-79R0, 33580-78R0* || Central gateway || Label and parts catalogue
 +
|}
 +
Reply ID offsets: engine +0x08; 0x261 to 0x274 +0x400; all others +0x10.
 +
 
 +
* KWP-style modules answer <code>1A 8E</code> and <code>1A 8A</code> (identification) and <code>18 00 FF 00</code> (DTCs). UDS-style modules answer <code>22 F1 01</code> and <code>22 F1 88</code> (identification) and <code>19 02 FF</code> (DTCs).
 +
* Requests to 0x273 and 0x262 (tester present) got no reply, so those modules are probably not fitted.
 +
* One name is still inferred and not confirmed by a part label: 0x261 (ABS). All the others come from the parts catalogue, a label, or a test.
 +
* The E-call controller (0x799) returned a stored code record (<code>92 4E 00</code>, status 02) that the Launch report does not list. Its meaning is not known.
 +
 
 +
=== Instrument cluster output test (0x274 / 0x674) ===
 +
A rev counter sweep commanded by the Launch X431 appears as a single KWP output-control request, after which the cluster sweeps the needle up and down by itself:
 +
{| class="wikitable"
 +
! Request !! Reply !! Notes
 +
|-
 +
| <code>3E 00</code> || <code>7E</code> || Tester present, about every 2.15 s
 +
|-
 +
| <code>30 01 07 80 40 00 00</code> || <code>70 01 07</code> || Starts the sweep (service 0x30, local ID 01, "short-term adjustment")
 +
|-
 +
| <code>30 01 07 80 00 00 00</code> || <code>7F 30 22</code> || Refused ("conditions not correct"); possibly a stop request sent after the sweep had finished
 +
|}
 +
The meaning of the four control bytes (80 40 00 00) is not known.
 +
 
 +
* Meaning of reply bytes +5, +7, +8 and the unexplained regions.
 +
* A more reliable pressure scale (more gauge readings at low and high pressure are needed; the lowest calibration point is 0.027 bar off).
 +
* Whether the central gateway forwards the request to the TPMS controller or remaps the address.
 +
* Why Torque Pro stops after the first line of the reply (the adapter is ruled out).
 +
* The meaning of the control bytes (80 40 00 00) in the instrument cluster sweep command.
 +
* The meaning of the stored code from the E-call controller.
 +
* Confirming the ABS (0x261) and dual sensor brake support (0x778) names.
 +
 
 +
== Open Questions ==
 
* Meaning of reply bytes +5, +7, +8 and the unexplained regions.
 
* Meaning of reply bytes +5, +7, +8 and the unexplained regions.
−
* A reliable pressure scale and offset (more gauge readings needed).
+
* A more reliable pressure scale (more gauge readings at low and high pressure are needed; the lowest calibration point is 0.027 bar off).
−
* Whether other Suzuki modules use addresses near 0x798 (not checked).
+
* Whether the central gateway forwards the request to the TPMS controller or remaps the address.
−
* Why Torque stops after the first line.
+
* Why Torque Pro stops after the first line of the reply (the adapter is ruled out).
 +
* The meaning of the control bytes (80 40 00 00) in the instrument cluster sweep command.
 +
* The meaning of the stored code from the E-call controller.
 +
* Confirming the ABS (0x261) name.
  
 
== Sources ==
 
== Sources ==
Line 185: Line 332:
 
* Suzuki wiring diagrams: A-8 CAN communication system; A-8 Central Gateway Control and DLC System (RHD).
 
* Suzuki wiring diagrams: A-8 CAN communication system; A-8 Central Gateway Control and DLC System (RHD).
 
* Forum thread "Jimny JB74 (2019+) - Torque Pro PID for TPMS".
 
* Forum thread "Jimny JB74 (2019+) - Torque Pro PID for TPMS".
 +
* BigJimny forum thread "JB74 OBD2 connection" (December 2020).
 +
* Suzuki Jimny parts catalogue 9900B-40312-004 (type 1, October 2021), figures 350A, 351A and 351B.
 +
* RealDash-extras OBD2 documentation (OBD2 XML description file).
 +
* Car Scanner ELM OBD2 custom PID documentation.
  
 
[[Category:Jimny technical]]
 
[[Category:Jimny technical]]
 
[[Category:JB74]]
 
[[Category:JB74]]
 +
[[Category:Electrical - gen3]]
 +
[[Category:FAQ - gen3]]
 +
[[Category:Howto - gen3]]
 +
 
[[Category:Electrical - gen4]]
 
[[Category:Electrical - gen4]]
 +
[[Category:FAQ - gen4]]
 +
[[Category:Howto - gen4]]

Latest revision as of 11:28, 1 November 2026

Suzuki Jimny JB74 (2018+) - Reading TPMS data over the diagnostic CAN link

Support this project: The information on this page is free, but it took a lot of work to gather, test and write up. If it has been useful to you, you can say thanks with a donation at buymeacoffee.com/bigjimny.

Overview

Purpose-built diagnostic tools (Autel, Launch and similar) already support Suzuki comprehensively. There is also a trend towards replacing the factory head unit with an Android media unit that can run apps to read and display information from the car's electronics. These units are not Suzuki-specific, so this project aims to learn how to read vehicle data (starting with the factory TPMS) and show it on the head unit.

Equipment

Role Item
Head unit XTRONS PX90
OBD-II Bluetooth dongle 1 Generic ELM-based (Chinese)
OBD-II Bluetooth dongle 2 Veepeak OBDCheck BLE+ (BLE only; works on a Lenovo tablet, will not connect to the head unit)
CAN bus monitor (Windows) PCAN-View (PEAK-System)
Diagnostic tool 1 Launch X431 CRP919
Diagnostic tool 2 SZ Viewer app
Apps tried Torque Pro (fails past the first line; tested on a Lenovo tablet), Car Scanner Pro (works), RealDash (TPMS values seen in its debug view; gauges in progress)
Head-unit Bluetooth xTRONS IP90 - Classic Bluetooth only, no BLE support

Method

  1. The diagnostic tools (Launch X431, SZ Viewer) have comprehensive Suzuki support, so they are used to generate the CAN bus requests.
  2. PCAN-View is connected to the OBD socket to capture the requests and the module's replies, which are then decoded by hand.
  3. The decoded requests are recreated in the head-unit apps so the head unit can ask the car for the same data directly.

Status: work in progress. Based on one RHD UK-market 2021 Jimny with factory TPMS, owner-made PCAN-View captures (including a full Launch scan and an instrument cluster test), the Suzuki wiring diagrams (A-8 CAN communication and A-8 Central Gateway/DLC) and the Suzuki parts catalogue. TPMS readings work in Car Scanner Pro; RealDash works in its debug view with gauges in progress. Items marked unconfirmed are not yet verified.

  • The TPMS control module answers an ordinary diagnostic request on the OBD socket. It does not broadcast tyre data.
  • Request ID 0x798, reply ID 0x7A8 (11-bit CAN, 500 kbit/s, ISO-TP framing) returns the TPMS data, including four sensor IDs and pressure readings. The module's identification reply (37160-61M0) matches the Model No. (P61M0) on the TPMS controller label. Whether the central gateway forwards or remaps the request is unconfirmed.
  • Service 0x21 (read data by local identifier), identifier 0x00, returns 102 bytes containing all four sensor records.
  • Pressure is byte +6 of each sensor record: bar = raw x 0.01372.
  • The OBD socket is fed by a central gateway, so only diagnostic traffic is visible on it.
  • Working: Car Scanner Pro, and RealDash (values seen in its debug view). Not working: Torque Pro.

DLC (OBD socket) wiring

The service-manual diagram numbers the DLC terminals differently from SAE J1962. In all five cases on the diagram, manual terminal n matches standard pin 17 - n.

Manual terminal Standard pin Function Wire / source on diagram
1 16 Battery +12 V GRY, fuse No.49 "DOME2" (10 A)
12 5 Signal ground BLK
13 4 Chassis ground BLK
11 6 CAN-H (from standard assignment) BLU, gateway pin 8
3 14 CAN-L (from standard assignment) WHT, gateway pin 7

Use pins 6 and 14 for a CAN adapter. The diagram does not label CAN-H and CAN-L itself.

Cross-check with other reports

A BigJimny forum thread ("JB74 OBD2 connection", December 2020) describes a 2020 JB74 whose OBD plug had pins 4, 5, 6, 14, 15 and 16 wired, with pin 7 (K-line) not wired. The poster, quoting an older Suzuki pinout, lists pin 6 as a blue wire (CAN-H) and pin 14 as a white wire (CAN-L). This matches the table above: a blue CAN wire on pin 6 and a white one on pin 14.

  • The CAN-H/CAN-L assignment in that thread comes from a pinout reference that the poster says predates the JB74, so it is a report, not a measurement.
  • No wire for standard pin 7 (K-line) appears on the diagram page above, and the forum report also found it unwired. K-line is therefore unlikely to be available on the JB74 socket.
  • On the forum poster's car, pin 15 was also wired; the diagram page above shows no wire for it. This may be a market or model-year difference.

Network layout

The DLC is not on the vehicle bus directly. The central gateway control module joins the vehicle CAN bus (its pins 20 and 21, RED/WHT) and provides a separate CAN pair to the DLC (its pins 8 and 7, BLU/WHT).

Modules on the vehicle bus (diagram): ECM, 4WD control module, TCM (A/T models), BCM, ESP control module, headlight auto levelling module (if equipped), dual sensor brake support control module (if equipped), P/S control module, steering angle sensor, TPMS control module / receiver (if equipped), combination meter, SDM, combination switch.

Gateway power: fuse No.60 "IG1 SIG" (10 A) and fuse No.52 "CONT" (5 A). Treat the ignition as needing to be on.

Observation: two captures from the DLC contained only IDs 0x798 and 0x7A8 (plus two error frames). No broadcast traffic from other modules was seen, so passive listening on the DLC will not show TPMS data.

Diagnostic requests seen

Request Reply Meaning
3E 7E Tester present
1A 8A 5A 8A + ASCII 37120-78R0* ECU identification
1A 8E 5A 8E + ASCII 37160-61M0 ECU identification: matches the "Model No. P61M0" printed on the TPMS controller label
18 00 FF 00 58 00 or 58 01 9A 31 E0 Read DTCs by status (second form = one code reported; not decoded)
21 00 61 00 + 100 bytes Sensor data block (repeated about twice a second by the scan tool)

Part labels on the test car: TPMS controller 37160-78R00, "BASE ASSY-TPMS", Model No. P61M0, Continental A2C13930301, 433.92 MHz; central gateway controller 33580-79R01. The 1A 8E reply (37160-61M0) matches the TPMS controller's base number and model number; the 1A 8A reply (37120-78R0*) shares "78R0" with the full part number, but its meaning is not confirmed.

A Launch full scan reported "Left Front Tire Pressure Low" for the TPMS module, and the module returned one stored code (9A 31) in the same scan. That code is probably the low-pressure warning (inferred; the report does not show the code itself).

Reading it with an ELM327

Terminal commands, one at a time (CR line ending): 

ATZ
ATSP6
ATSH798
ATS0
ATL0
ATFCSH798
ATFCSD300000
ATFCSM1
2100
  • ATSH798 sets the request address. The reply address (0x7A8) is worked out automatically.
  • ATFCSH798 / ATFCSD300000 / ATFCSM1 make the adapter send the ISO-TP flow-control frame (30 00 00) itself.
  • ATS0 removes the spaces between bytes. Without it, the generic Chinese ELM327-based dongle (dongle 1) reported BUFFER FULL near byte 81.
  • Expected output: a length line (066 = 102 bytes) and numbered lines 0: to E:.
  • With default settings dongle 1 returned only the first line (61 00 xx 01 00 00).

Reply layout (21 00)

Byte positions count the 61 as byte 0.

Bytes Content
0-1 61 00 (positive reply)
2 Varies 117-142. Looks like system voltage x 10 (unconfirmed)
12-21 Sensor record 1: front left
22-31 Sensor record 2: rear left
32-41 Sensor record 3: rear right
42-51 Sensor record 4: front right
56-71 Four 4-byte sensor-ID entries whose contents change (meaning unknown)
other Not decoded

Sensor record (10 bytes)

Offset Content
+0 to +3 Sensor ID
+4 Position flag
+5 Value 57-74. Behaves like temperature, possibly with an offset of 40 (unconfirmed)
+6 Pressure, gauge: bar = raw x 0.01372 (see Calibration)
+7, +8 Not understood
+9 Always 0
Wheel Sensor ID Position flag
Front left 4E AA 09 43 0x10
Rear left DD 91 B5 25 0x20
Rear right 4E AA 03 19 0x18
Front right 4E AA 09 C9 0x08

Sensor IDs are specific to one car. Yours will differ.

Calibration

Byte +6 against gauge readings (bar). The five deflation-test counts were reconstructed from the app's displayed values.

Raw Gauge (bar) Raw x 0.01372
136 (rear left) 1.868 1.866
131 (rear right) 1.795 1.797
131 (front right) 1.795 1.797
126 1.73 1.729
119 1.63 1.633
112 1.54 1.537
101 1.39 1.386
96 1.29 1.317

The last five rows are from one tyre, the front left, during a slow deflation.

  • bar = raw x 0.01372
  • psi = raw x 0.199

No offset is needed, which suggests the byte holds gauge pressure. All points are within 0.004 bar except the lowest (0.027 bar off), which may be sensor update lag or slight non-linearity. More readings at low and high pressure are needed.

Torque Pro custom PIDs

Common fields for every wheel:

Field Value
Header 798
Mode and PID 2100
Diagnostic start command ATS0, ATL0, ATFCSH798, ATFCSD300000, ATFCSM1 (comma-separated)
Unit / min / max bar, 0, 4 (or psi, 0, 60)

Equation uses a letter for each data byte. A is the first byte after 61 00 (reply byte 2).

Wheel Byte +5 (temperature?) Byte +6 (pressure candidate)” to “Byte +6 (pressure)”
Front left P Q
Front right AT AU
Rear left Z AA
Rear right AJ AK

Example: Q*0.01372. Letters must be upper case. Whether Torque accepts two-letter variables is unconfirmed.

Known problem

Using dongle 1 (generic Chinese ELM327-based) with Torque Pro on a Lenovo tablet, Torque read bytes A to D (first line of the reply) correctly, but every byte from E onward returned -1, even though a terminal received the full 102 bytes with the same commands. The start-command field is applied (adding ATH1 changed the output). Tried without success: turning off "Faster communication" and removing ATS0. Not tried: ATAT0, ATSTFF timeout settings.

Dongle 2 (Veepeak OBDCheck BLE+), also on the tablet, gave the same result. Car Scanner Pro reads every byte with both dongles and the same commands, so the limitation is in how Torque Pro handles this multi-line reply, not in the adapter or the Android device. Unresolved; a request has been posted on the Torque forum.

Car Scanner Pro (working)

Car Scanner Pro reads all the bytes where Torque Pro fails. Custom PID settings used:

  • Header: 798
  • Request: 2100
  • Start command (backslash-separated): ATAT0\ATSTFF\ATS0\ATL0\ATFCSH798\ATFCSD300000\ATFCSM1
  • Equations use the same letters as the table above, for example Q*0.01372 for front left (bar)

The start command has not yet been shortened. Both dongle 1 (generic ELM327-based) and dongle 2 (Veepeak OBDCheck BLE+) work with Car Scanner Pro on the Lenovo tablet. Dongle 2 will not connect to the XTRONS head unit.

RealDash

RealDash describes its OBD2 communication in an XML file. With dongle 1, RealDash's default init plus the lines below works: the TPMS sensors reply, and the values appear in RealDash's debug view. Dashboard gauges are in progress.

Changes to RealDash's default file:

  • Add the three flow-control commands to the init section, before the 0100 and 0120 checks.
  • Every TPMS command sets header="atsh798". The docs say to set the header on every command when the rotation uses more than one. Any standard command in the same rotation then needs header="atsh7df", or it would be sent to 0x798.
  • RealDash requires ATE0, ATL0 and ATS0 (already in its default init).
<init>
  ... RealDash default init lines ...
  <command send="atfcsh798"></command>
  <command send="atfcsd300000"></command>
  <command send="atfcsm1"></command>
  <command send="0100"></command>
  <command send="0120"></command>
</init>
<rotation>
  <command send="2100" header="atsh798" skipCount="10" keepInRotation="true" name="TPMS: front left" units="bar" conversionABC="Q*0.01372"></command>
  <command send="2100" header="atsh798" skipCount="11" keepInRotation="true" name="TPMS: front right" units="bar" conversionABC="AU*0.01372"></command>
  <command send="2100" header="atsh798" skipCount="12" keepInRotation="true" name="TPMS: rear left" units="bar" conversionABC="AA*0.01372"></command>
  <command send="2100" header="atsh798" skipCount="13" keepInRotation="true" name="TPMS: rear right" units="bar" conversionABC="AK*0.01372"></command>
</rotation>

conversionABC uses the same letters as Torque and Car Scanner (A is the first byte after 61 00). The TPMS inputs appear in RealDash's ECU Specific category.

The Veepeak OBDCheck BLE+ (dongle 2) will not connect to the head unit because the head unit does not support BLE, so only dongle 1 was used.

Other modules found by a full scan

A full health-check scan with a Launch X431 CRP919, captured with PCAN-View on the OBD socket, shows 12 modules answering on the DLC. Every module that replied is listed here. The reply ID is not always the request ID plus 8.

Request Reply Protocol Identification replies Module How identified
0x7E0 0x7E8 KWP 33980-78R0, 33980-78RC* ECM Standard engine address
0x261 0x661 KWP 56100-77RA, 56100-78RF* ABS (inferred) Only brake module left by elimination
0x263 0x663 KWP 38720-77R0, 38720-77R0* EPS controller Parts catalogue
0x271 0x671 KWP 36775-77R0, 36775-77RC* Body control module Parts catalogue
0x274 0x674 KWP 34100-78R0, 34110-78RD* Instrument cluster Rev counter sweep test
0x798 0x7A8 KWP 37160-61M0, 37120-78R0* TPMS controller Label and parts catalogue
0x79A 0x7AA KWP 37210-74PA, 37210-74PE* Lighting and turn switch Parts catalogue
0x778 0x788 KWP 33990-52R0, 33990-78R8* Dual sensor brake support Parts catalogue
0x793 0x7A3 UDS 38910-77R0, 38910-78RC* Airbag (SRS) controller Parts catalogue
0x772 0x782 UDS 38885-77R0, 38885-78R0* 4WD shift controller Parts catalogue
0x799 0x7A9 UDS 38960-78RA, 38960-78RA* E-call controller Parts catalogue
0x751 0x761 UDS 33580-79R0, 33580-78R0* Central gateway Label and parts catalogue

Reply ID offsets: engine +0x08; 0x261 to 0x274 +0x400; all others +0x10.

  • KWP-style modules answer 1A 8E and 1A 8A (identification) and 18 00 FF 00 (DTCs). UDS-style modules answer 22 F1 01 and 22 F1 88 (identification) and 19 02 FF (DTCs).
  • Requests to 0x273 and 0x262 (tester present) got no reply, so those modules are probably not fitted.
  • One name is still inferred and not confirmed by a part label: 0x261 (ABS). All the others come from the parts catalogue, a label, or a test.
  • The E-call controller (0x799) returned a stored code record (92 4E 00, status 02) that the Launch report does not list. Its meaning is not known.

Instrument cluster output test (0x274 / 0x674)

A rev counter sweep commanded by the Launch X431 appears as a single KWP output-control request, after which the cluster sweeps the needle up and down by itself:

Request Reply Notes
3E 00 7E Tester present, about every 2.15 s
30 01 07 80 40 00 00 70 01 07 Starts the sweep (service 0x30, local ID 01, "short-term adjustment")
30 01 07 80 00 00 00 7F 30 22 Refused ("conditions not correct"); possibly a stop request sent after the sweep had finished

The meaning of the four control bytes (80 40 00 00) is not known.

  • Meaning of reply bytes +5, +7, +8 and the unexplained regions.
  • A more reliable pressure scale (more gauge readings at low and high pressure are needed; the lowest calibration point is 0.027 bar off).
  • Whether the central gateway forwards the request to the TPMS controller or remaps the address.
  • Why Torque Pro stops after the first line of the reply (the adapter is ruled out).
  • The meaning of the control bytes (80 40 00 00) in the instrument cluster sweep command.
  • The meaning of the stored code from the E-call controller.
  • Confirming the ABS (0x261) and dual sensor brake support (0x778) names.

Open Questions

  • Meaning of reply bytes +5, +7, +8 and the unexplained regions.
  • A more reliable pressure scale (more gauge readings at low and high pressure are needed; the lowest calibration point is 0.027 bar off).
  • Whether the central gateway forwards the request to the TPMS controller or remaps the address.
  • Why Torque Pro stops after the first line of the reply (the adapter is ruled out).
  • The meaning of the control bytes (80 40 00 00) in the instrument cluster sweep command.
  • The meaning of the stored code from the E-call controller.
  • Confirming the ABS (0x261) name.

Sources

  • Owner PCAN-View captures, October 2026.
  • Suzuki wiring diagrams: A-8 CAN communication system; A-8 Central Gateway Control and DLC System (RHD).
  • Forum thread "Jimny JB74 (2019+) - Torque Pro PID for TPMS".
  • BigJimny forum thread "JB74 OBD2 connection" (December 2020).
  • Suzuki Jimny parts catalogue 9900B-40312-004 (type 1, October 2021), figures 350A, 351A and 351B.
  • RealDash-extras OBD2 documentation (OBD2 XML description file).
  • Car Scanner ELM OBD2 custom PID documentation.
Retrieved from ‘http://www.bigjimny.com/mediawiki/index.php?title=OBD2_Diagnostics_reading_project&oldid=10098’