Automate/AutoPID: Mapping between WiCAN and Torque byte indexes

[philipkocanda]

Porting over PIDs from Torque mappings found online can be frustrating because they do not align with WiCAN's automate feature - this requires guessing where the correct byte will be. Guess no more - you can use my little look up table instead and save yourself some time and effort. Explanation below the table.

WiCAN Index	ISO-TP	Torque 1	Torque 2	ISO-TP Frame Type	CAN Data	UDS Response
0				FF:PCI(0)	B0
1				FF:PCI(1)	B1
2	0x00			FF:data	B2	UDS SID
3	0x01			FF:data	B3	UDS subfn.
4	0x02	A		FF:data	B4	UDS subfn. optional
5	0x03	B	A	FF:data	B5	UDS data
6	0x04	C	B	FF:data	B6	UDS data
7	0x05	D	C	FF:data	B7	UDS data
8				CF1:PCI(0)	B0
9	0x06	E	D	CF1:data	B1	UDS data
10	0x07	F	E	CF1:data	B2	UDS data
11	0x08	G	F	CF1:data	B3	UDS data
12	0x09	H	G	CF1:data	B4	UDS data
13	0x0A	I	H	CF1:data	B5	UDS data
14	0x0B	J	I	CF1:data	B6	UDS data
15	0x0C	K	J	CF1:data	B7	UDS data
16				CF2:PCI(0)	B0
17	0x0D	L	K	CF2:data	B1	UDS data
18	0x0E	M	L	CF2:data	B2	UDS data
19	0x0F	N	M	CF2:data	B3	UDS data
20	0x10	O	N	CF2:data	B4	...
21	0x11	P	O	CF2:data	B5
22	0x12	Q	P	CF2:data	B6
23	0x13	R	Q	CF2:data	B7
24				CF3:PCI(0)	B0
25	0x14	S	R	CF3:data	B1
26	0x15	T	S	CF3:data	B2
27	0x16	U	T	CF3:data	B3
28	0x17	V	U	CF3:data	B4
29	0x18	W	V	CF3:data	B5
30	0x19	X	W	CF3:data	B6
31	0x1A	Y	X	CF3:data	B7
32				CF4:PCI(0)	B0
33	0x1B	Z	Y	CF4:data	B1
34	0x1C	AA	Z	CF4:data	B2
35	0x1D	AB	AA	CF4:data	B3
36	0x1E	AC	AB	CF4:data	B4
37	0x1F	AD	AC	CF4:data	B5
38	0x20	AE	AD	CF4:data	B6
39	0x21	AF	AE	CF4:data	B7
40				CF5:PCI(0)	B0
41	0x22	AG	AF	CF5:data	B1
42	0x23	AH	AG	CF5:data	B2
43	0x24	AI	AH	CF5:data	B3
44	0x25	AJ	AI	CF5:data	B4
45	0x26	AK	AJ	CF5:data	B5
46	0x27	AL	AK	CF5:data	B6
47	0x28	AM	AL	CF5:data	B7

ISO-TP Index: Pure ISO-TP payload index.
WiCAN Index: Index in CAN frame data payload. This is what's used by WiCAN for byte addressing (Automate/AutoPID feature). Because of this it includes the ISO-TP PCI bytes of each frame (one or two bytes, depending on ISO-TP frame type). This is what causes the difference between WiCAN and Torque and what makes porting over known PIDs more difficult.

Torque 1 column: For UDS requests with 1 sub function byte. For instance: 21 01, 22 00, etc.
Torque 2 column: For UDS requests with 2 sub function bytes. For instance: 22 F1 90 (read VIN), 22 F1 97 (read ECU name).

Deeper explanation

Remember the stack we’re typically working with is:

CAN → ISO-TP → UDS

WiCAN operates on the raw CAN data payload, while other tools like Torque and CarScanner typically are ISO-TP and UDS aware. Which is what we’re often most interested in when connected to OBD2.

Why I made this

What my typical use-case is: I want to add PIDs to my vehicle profile, and most of them you find online use the Torque-style letters, for instance:
Hyundai Kona and Kia e-Niro BMS PIDs
Hyundai Ioniq 28 kWh VMCU PIDs

I hope I’m not misunderstanding anything too badly here, not an experienced car hacker by any means. I did verify the mapping however with my Ioniq (2017) and various online resources using the Torque letter coding.

[tylerharvey]

Hi Phillip, this is really useful! I'm working on a python script to (semi-)automatically port. I think I've gotten most of it but I still don't understand the occasional 7th digit in WiCAN PIDs (where Torque has 6). Do you?

For example, the WiCAN State of Charge Display PID for an Ioniq 5/6 is 2201057 whereas in Torque it's just 220105. Any idea what this is?

[meatpiHQ]

The 7 is optional parameter, it's the expected number of the frames, so it returns after 7 frames instead of waiting for the timeout to expire

[tylerharvey]

Does this correspond to "ISO-TP Frame Type" above? I wrote code based on that assumption and then realized there were also 9s.

[meatpiHQ]

What do you mean by 9s?