Subaru SSM3 via Can
Posted: Mon Jul 23, 2018 5:21 am
Hello all!
I just purchased my second race capture unit for my 2015 WRX. I'll start by saying, I'm not a programmer or engineer, so if I'm asking something totally incorrect, please just stop me.
First and foremost, I thought I'd share this Can Library. I'm not 100% sure how accurate all the information is, but I'll test it when my RCP Track arrives. https://subdiesel.wordpress.com/ecu-ana ... -messages/
I found out subaru has a specific protocol called SSM. Newer generations of subarus communicate on this diagnostic protocol via CAN. This is much faster than serial. It requires you send request commands to the ECU. There is much more vehicle information on SSM. A lot of this is defined by Romraider. Knock sensors, AFR, AF learning, AF correction, fuel pressure, etc.
Moving on. From this page, https://subdiesel.wordpress.com/generic ... 2-via-can/
I assume this would be my transmit Can ID to communicate with the ecu.
A8 00 (hex)
A8 = 168 (dec)
00 = 0 (dec)
I'm not sure what this is for, but it appears required. The quote above states that 00 is required as padding, I assume this would be another byte in the payload.
Given the above request of:
00 00 07 E0 A8 00 00 02 9D 00 02 9E
00029D = 669
00029E = 670
Would it be correct to guess that this would be the correct txCAN command?
channel = 0 (assumed I'm connected to CAN 0)
id = 2016
ext = 0
data = {168,0,669,670}
res = txCAN(channel, id, ext, data)
I don't think I can request a dec value greater than 255 in one byte. Is there a way around this? Or am I wrong?
Moving on and breaking down the response:
00 00 07 E8 E8 01 23
000007E8 = 2024
This would be the can ID I look for. Then data would be {E8,01,23} or {232,1,35}. I'm arbitrarily assuming this is how the racecapture software would capture the ecu's response. I know there is a can frame format and that race capture parses this in the background. I could be totally wrong, does anyone have any insight?
There other issue here is that I can only send 8 bytes and I know I will likely need to send more, but I'll start here before going too far down the road.
I just purchased my second race capture unit for my 2015 WRX. I'll start by saying, I'm not a programmer or engineer, so if I'm asking something totally incorrect, please just stop me.
First and foremost, I thought I'd share this Can Library. I'm not 100% sure how accurate all the information is, but I'll test it when my RCP Track arrives. https://subdiesel.wordpress.com/ecu-ana ... -messages/
I found out subaru has a specific protocol called SSM. Newer generations of subarus communicate on this diagnostic protocol via CAN. This is much faster than serial. It requires you send request commands to the ECU. There is much more vehicle information on SSM. A lot of this is defined by Romraider. Knock sensors, AFR, AF learning, AF correction, fuel pressure, etc.
Moving on. From this page, https://subdiesel.wordpress.com/generic ... 2-via-can/
Ecu ID = 000007E0 or 2016 (dec)READ SSM2 ADDRESS(ES)
<CAN ID Tester> A8 00 <Address1[3]> <Address2[3]> ...
Note: Mode byte (after A8) must be 00 – fast poll not supported unlike SSM via Serial.
Request single address, 0x000008 for example:
00 00 07 E0 A8 00 00 00 08
Note: the zero byte after A8 is a padding byte and probably has no effect. Same as in serial SSM2. Just like with serial SSM2 you can request multiple addresses at once by adding more SSM addresses (3 bytes each).
Example: DPF Regeneration Count
Need to request two bytes, addresses 0x00029D and 0x00029E, which make up this Diesel parameter.
x [-] = A*256+B like SSM2 0x00029D; tracks fully completed regenerations only
x: response payload data as 16 bit unsigned integer (uint16), big endian; alternative view: A = high (first) byte, B = low (second) byte
00 00 07 E0 A8 00 00 02 9D 00 02 9E
Example respose:
00 00 07 E8 E8 01 23
→ SSM data bytes are "01 23"
→ x = 0x0123 = decimal 291; → result = 291 regenerations
Alternative view by handling individual bytes: → A = 0x01; B = 0x23 → result = 0x01 * 0x100 + 0x23 = decimal 1 * 256 + 35 = 291
I assume this would be my transmit Can ID to communicate with the ecu.
A8 00 (hex)
A8 = 168 (dec)
00 = 0 (dec)
I'm not sure what this is for, but it appears required. The quote above states that 00 is required as padding, I assume this would be another byte in the payload.
Given the above request of:
00 00 07 E0 A8 00 00 02 9D 00 02 9E
00029D = 669
00029E = 670
Would it be correct to guess that this would be the correct txCAN command?
channel = 0 (assumed I'm connected to CAN 0)
id = 2016
ext = 0
data = {168,0,669,670}
res = txCAN(channel, id, ext, data)
I don't think I can request a dec value greater than 255 in one byte. Is there a way around this? Or am I wrong?
Moving on and breaking down the response:
00 00 07 E8 E8 01 23
000007E8 = 2024
This would be the can ID I look for. Then data would be {E8,01,23} or {232,1,35}. I'm arbitrarily assuming this is how the racecapture software would capture the ecu's response. I know there is a can frame format and that race capture parses this in the background. I could be totally wrong, does anyone have any insight?
There other issue here is that I can only send 8 bytes and I know I will likely need to send more, but I'll start here before going too far down the road.