OBD2 Diagnostics reading project

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, an instrument cluster test and SZ Viewer TPMS captures checked against its screen), 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 the module supply voltage and all four sensor records.
• Each sensor record gives the wheel position (byte +4), air temperature (byte +5: °C = raw − 50) and pressure (byte +6: 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.
• All the module addresses, and the full byte-by-byte decode of the TPMS data block, are kept on ECU diagnostic CAN addresses.

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 (no codes) or 58 01 9A 31 20 (one code)	Read DTCs by status. 9A 31 is B1A31, "Left front tire pressure low" (confirmed by SZ Viewer). SZ Viewer shows status 20 as History (stored, not current); E0 was seen in earlier captures
21 00	61 00 + 100 bytes	Sensor data block (repeated about twice a second by the Launch tool, every 0.12 to 0.15 s by SZ Viewer)

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. SZ Viewer decodes that code as B1A31, "Left front tire pressure low", stored as History.

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. The letter is the variable name used by Torque Pro, Car Scanner and RealDash (A = byte 2). This is a summary; the full decode, with example values checked against SZ Viewer, is in Sensor data block (21 00) layout.

Bytes	Letters	Content
0-1	–	61 00 (positive reply)
2	A	Module supply voltage: V = A / 10 (confirmed against SZ Viewer)
3-11	B-J	Not decoded (byte 3 was 01, the rest zero so far)
12-21	K-T	Sensor record 1
22-31	U-AD	Sensor record 2
32-41	AE-AN	Sensor record 3
42-51	AO-AX	Sensor record 4
52-71	AY-BR	Five 4-byte sensor ID slots, probably a log of recently received sensors (inferred)
72-75	BS-BV	One value per wheel, x 0.0137 bar. Possibly the low-pressure warning threshold (inferred)
76-79	BW-BZ	One value per wheel, x 0.0137 bar. Possibly the threshold at which the warning clears (inferred)
80-101	CA-CV	Not decoded

Sensor record (10 bytes)

Offset	Letters (records 1 / 2 / 3 / 4)	Content	Formula
+0 to +3	K-N / U-X / AE-AH / AO-AR	Sensor ID	4 bytes, hex
+4	O / Y / AI / AS	Wheel position, learned by the module's auto-location	value / 8: 1 = right front, 2 = left front, 3 = right rear, 4 = left rear
+5	P / Z / AJ / AT	Air temperature	°C = value − 50
+6	Q / AA / AK / AU	Air pressure, gauge (see Calibration)	bar = value x 0.01372
+7	R / AB / AL / AV	Rotational (centripetal) acceleration, held from the sensor's last transmission	g = value / 2
+8	S / AC / AM / AW	Sensor battery status	42 = Normal; other values not yet decoded
+9	T / AD / AN / AX	Unknown	Always 0 so far

The records are not in wheel order. The module keeps them in its own order (the decode page says sensor-ID order) and reports the wheel in byte +4. On the test car the order is front left, rear left, rear right, front right, which is what the app setups below assume. After tyres are rotated or a sensor is replaced, the record that holds each wheel can change: check the position bytes (O/8, Y/8, AI/8, AS/8) and swap the letters in the app setups to match.

Record	Wheel	Sensor ID	Byte +4	Position (value / 8)
1	Front left	4E AA 09 43	0x10	2
2	Rear left	DD 91 B5 25	0x20	4
3	Rear right	4E AA 03 19	0x18	3
4	Front right	4E AA 09 C9	0x08	1

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
• kPa = raw x 1.372

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.

The SZ Viewer app scales the same byte by exactly 0.0137 bar per count (psi x 0.1987, kPa x 1.37); all four of its displayed values match that to three decimals. The two factors give the same reading to two decimal places, so either can be used. Use *0.0137 if you want the app to agree exactly with SZ Viewer.

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). Letters for the test car's record order:

Wheel	Record	Position (byte +4)	Temperature (byte +5)	Pressure (byte +6)
Front left	1	O	P	Q
Front right	4	AS	AT	AU
Rear left	2	Y	Z	AA
Rear right	3	AI	AJ	AK

Examples: pressure Q*0.01372 (bar); temperature P-50 (°C); position O/8; module supply voltage A/10 (V). 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 pressure PIDs are tested. The PIDs below use the same header, request and start command and follow the decode, but have not yet been tried in the app (untested):

PID	Equation	Unit	Min / max
TPMS module voltage	A/10	V	0 / 16
Temperature front left	P-50	°C	-40 / 120
Temperature front right	AT-50	°C	-40 / 120
Temperature rear left	Z-50	°C	-40 / 120
Temperature rear right	AJ-50	°C	-40 / 120
Record 1 position	O/8	–	1 / 4
Record 2 position	Y/8	–	1 / 4
Record 3 position	AI/8	–	1 / 4
Record 4 position	AS/8	–	1 / 4

Position values: 1 = right front, 2 = left front, 3 = right rear, 4 = left rear. If a record's position no longer matches the wheel in its PID name, swap the letters (see Sensor record).

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 letters assume the test car's record order; see Sensor record if the tyres have been rotated.

Optional extra inputs (untested): the same pattern should give tyre temperatures and the module voltage. They change slowly, so a higher skipCount is used to poll them less often:

  <command send="2100" header="atsh798" skipCount="40" keepInRotation="true" name="TPMS: temp front left" units="C" conversionABC="P-50"></command>
  <command send="2100" header="atsh798" skipCount="41" keepInRotation="true" name="TPMS: temp front right" units="C" conversionABC="AT-50"></command>
  <command send="2100" header="atsh798" skipCount="42" keepInRotation="true" name="TPMS: temp rear left" units="C" conversionABC="Z-50"></command>
  <command send="2100" header="atsh798" skipCount="43" keepInRotation="true" name="TPMS: temp rear right" units="C" conversionABC="AJ-50"></command>
  <command send="2100" header="atsh798" skipCount="44" keepInRotation="true" name="TPMS: module voltage" units="V" conversionABC="A/10"></command>

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. Current names and request details for each module are kept on ECU diagnostic CAN addresses.

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; SZ Viewer reads it under its ABS/ESP tab (inferred)
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.

Open Questions

• Which bytes carry vehicle speed and the low-pressure lamp state (SZ Viewer shows both); a capture while driving with the lamp on is needed.
• Battery status values other than 42 (Normal) at byte +8, and the unexplained regions of the reply.
• Confirming the inferred threshold values at bytes 72-79.
• More gauge readings at low and high pressure (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.
• Owner PCAN-View captures of the SZ Viewer app (TPMS tab) with matching screenshots, 14 November 2026. Full decode on ECU diagnostic CAN addresses.
• 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.