jellybeans

TLDR
Hi all,
Figured I might as well share what I've found playing around with CANBUS on the series 1 Rx8, in case it's of any interest to others. TLDR: below is a list of all the s1 PIDs you can read data from, as well as PIDs you can CONTROL

Bit of Background Info
Communicating with the s1 Rx8 PCM is at first quite annoying, because unlike cars today which are generally uniform in their use of UDS, the Rx8 was in that transitional period of time where CAN standardisation was an on-going process. Thus we find it using the precursor to UDS, KWP2000, but not only that, a Ford variant of KWP2000. So if you use the KWP2000 spec you'll still run into issues -- I spent a LOT of time working all this out, especially given the documentation is relatively scant and/or expensive. As a result, it has not seemed possible anecdotally to disable DTCs, but only to mask CELs. This is not exactly true. I will now go through the various findings that may be of interest to people. This assumes you understand how the CANBUS works (which is easy to learn -- a good start is https://www.csselectronics.com/pages...ultimate-guide) and can talk with the ECU (probably through an Arduino or similar -- I used an ESP8266 with ).

Valid Service IDs
Here are all the valid service SIDs the Rx8 uses.

The Rx8 PCM understands the following UDS-identical SIDs:
0x10, 0x11, 0x14, 0x22, 0x23, 0x27, 0x2F, 0x34, 0x36, 0x37, 0x3E, 0x85
And these KWP2000 SIDs:
0x18, 0x21, 0x31, 0x32, 0x33, 0x3B
And these Ford diagnostic spec unique SIDs:
0x12, 0x28, 0xB1

Whilst these might be the same SIDs for UDS/KWP, the subfunctions and correct order of PIDs/DIDs can be different, which often leads to negative return codes (NRC) that make you think the service is unsupported.

Disabling DTCs
s1 Rx8 uses SID 0x85 to disable DTCs just like UDS. However, different from both UDS and KWP, the correct frame is 0x85 0x02 to disable ALL codes. You cannot disable individual codes. What is strange here is that you seem to only be able to send this frame successfully in default session, whereas you would normally expect to be required to be in diagnostic session (and probably secured diagnostic, at that). Furthermore, of main interest concerning disabling DTCs, the PCM makes a distinction between the severity of DTCs. There are 'continuous' ie standard codes, that are set whilst driving around like normal, and there are 'on-demand' or what we would nowadays call permanent DTCs that require multiple drive cycles to clear. 0x85 0x02 only disables continuous DTCs. Guess what type of DTC your OMP DTCs 0x1686, 0x1687, 0x1688 are ? Because these codes can be set during start-up (every 0th modulo 12 start-up from battery connect) in a Ford inherited thing called a KOER (key on engine running) self-test, they count as on-demand DTCs and can NOT be disabled with the service 0x85.

Reading and Controlling PIDs
Reading data is done the same as UDS with SID 0x22. Also, you'll note the SID 0x2F is also valid above, which is InputOutputControlByID service. This service requires secured diagnostic session. This service lets you control, for example, the operation of your fuel pump, or your fans, or your fuel injectors etc. It's pretty cool. The caveat is that the PCM only permits control when the accelerator is not depressed (seems to be ~10% max, I suspect it's 13% which is the fail safety limit when you go into limp mode), so you can't control stuff when driving. You CAN diagnose potentially useful stuff with your car idling, like if your SSV is jamming or if you suspect your fuel pump is on its way out.
I checked all 65536 possible PIDs, for both reading and controlling. As you'd expect, most PIDs are for reading, and some of them can also be read ie SIDs 0x22 and 0x2F both work for the same PID. But unexpectedly there are some PIDs which can ONLY control ie be used with SID 0x2F. Looking carefully at the service highlights, there is a section under Engine>On-Board Diagnostic>Simulation Test. This appears to itemise PIDs which are designed for eg dealership test routines or similar, and thus control other PIDs that usually can be read separately with 0x22.

PIDs
I emailed these to Versatuner along with a suggestion they could use the control PIDs as a sort of diagnostic tool in the user dashboard, but didn't get a response -- maybe the email looked like malicious code. A good chunk of these Versatuner already has in their dashboard, but far from all.
Anyway, here is the list of ALL PIDs w/ valid SIDs for a manual 2003 -- there will be a few more for cars with cruise control, different trims etc:

* 0x0000 1-20 PIDS Supported 0x22
* 0x0002 Freeze DTC 0x22
* 0x0003 Fuel System Status 0x22
* 0x0004 Calculated Load 0x22
* 0x0005 ECT 0x22
* 0x0006 STFT 0x22
* 0x0007 LTFT 0x22
* 0x000C RPM 0x22
* 0x000D Speed 0x22
* 0x000E Leading Timing 0x22
* 0x000F IAT 0x22
* 0x0010 MAF 0x22
* 0x0011 TP % Sensor #2 (Sub) 0x22
* 0x0012 Commanded Sec Air 0x22
* 0x0013 O2 Sensor Locations 0x22
* 0x0015 Rear O2 Voltage 0x22
* 0x001C OBD Conformity 0x22
* 0x001F Run Time 0x22
* 0x0020 21-40 PIDS Supported 0x22
* 0x0021 Distance w/ MIL 0x22
* 0x002E Commanded Evap Purge 0x22
* 0x002F Fuel Tank Level 0x22
* 0x0030 W-ups since DTCs Clrd 0x22
* 0x0031 Distance w/ DTCs 0x22
* 0x0033 Baro 0x22
* 0x0034 AFR : FO2 Current 0x22
* 0x003C Catalyst Temp 0x22
* 0x0040 41-60 PIDs Supported 0x22
* 0x0042 Battery Voltage 0x22
* 0x0043 Abs Load 0x22
* 0x0044 Target RO2 AFR Trim % 0x22 // service highlight suggests % ? looks like lambda
* 0x0045 Relative Throttle % 0x22
* 0x0047 Abs Throttle % 0x22
* 0x0049 APP % Sensor 1 0x22
* 0x004A APP % Sensor 2 0x22
* 0x004C Target Throttle % 0x22
* 0x0200 Continuous DTC Count 0x22
* 0x0202 KOEO / KOER DTC Count 0x22
* 0x0904 Trailing timing 0x22
* 0x0914 APP Voltage #1 (Main) 0x22
* 0x0915 APP Voltage #2 (Sub) 0x22
* 0x0917 TP Voltage #1 (Main) 0x22
* 0x0918 TP Voltage #2 (Sub) 0x22
* 0x091A Target Throttle Angle 0x22 & 0x2F
* 0x093C Throttle Angle 0x22
* 0x0968 Gen Warn Light ?:0x00 0x22 // 0x01 0x00 engine off, 0x00 0x00 engine on. set briefly by e91a to 7 1
* 0x096E Target RPM 0x22 & 0x2F
* 0x097C Target RO2 AFR 0x2F & 0x22
* 0x09D3 VFAD : ?0x00? 0x22
* 0x1101 Brake Switch 0x22
* 0x1103 APV Voltage Status 0x22
* 0x1104 A/C Relay 0x22
* 0x114A IAT Sensor Voltage 0x22
* 0x114D PCM Temp Voltage 0x22
* 0x1153 Idle Air Control % 0x22
* 0x1154 TP % Sensor #1 (Main) 0x22 // LSB increments 0.25%
* 0x1169 ????????????? 0x22 // increments 0x40, steady, 1c D0. = 500mv? varies from day-to-day.
* 0x1177 MAF Voltage 0x22
* 0x1340 APP 0x22
* 0x1410 Fuel Injection MS 0x22
* 0x1631 O2 Sensor Heaters 0x22 // 0x03 is F+R O2 on (e.g. during decel fuel cut), 0x01 just FO2
* 0x1634 Field Coil % ? 0x22
* 0x163E ???????????? 0x22 // first byte is FF or 0x00. last byte moves around. often on for large purge evap; intake related ?
* 0x1681 ???????????? 0x22 // usually 0, sets to 0x40
* 0x1688 Air Solenoid Valve 0x22
* 0x16B3 Baro Voltage 0x22
* 0x16E8 (Target?) Gen Voltage 0x2F & 0x22
* 0x16E9 Min Closed TP Input V?0x22 // 0x00 ~0x70, largest seen 0x77, smallest 5e
* 0x16F0 Tyre Revs per Mile 0x22
* 0x1706 OMP Switch 0x22
* 0x1710 MIL : ?? 0x22 // nibbles 1,2,4 MIL related
* 0x1711 Fuel Pump Speed Relay 0x22
* 0x1715 VDI Status 0x22
* 0x1718 Fuel Pump Relay 0x22
* 0x172A Estimated ECT 0x22
* 0x172D OMP Position 0x2F & 0x22
* 0x1746 Knock Retard 0x22
* 0x175C Primary Injectors % 0x2F
* 0x175D Purge Solenoid % 0x2F // other ecu control usually prevents getting to commanded %
* 0x175E Target RO2 AFR Trim 0x2F
* 0x175F (Target?) Gen Voltage 0x2F
* 0x1782 ???????????? 0x22 // ~0xE0 0x00 moves increments 0x40. sensor volt
* 0x17A6 ???????????? 0x22 // counts down from A to 0 on ECU start
* 0x17C3 Fan Enable 1 0x2F
* 0x17C4 Fan Enable 2 0x2F
* 0x17C6 A/C Relay Enable 0x2F
* 0x17C8 VFAD Enable 0x2F
* 0x17DE ????????????? 0x2F & 0x22 // enable, normally never set ?, changes nothing, not delivery mode. test mode?
* 0x17DF ???????????? 0x2F // field coil % ? -- causes car to almost stall belatedly
* 0x17E0 ???????????? 0x2F // % ? -- 0 kills engine straight away, 150 engine changes slightly
* 0x17E1 ???????????? 0x2F // enable controls 1681
* 0xA211 (In-Gear:Neutral):CPP 0x22
* 0xA216 ???????????? 0x22 // 0xFF 0xC0 constant. 5v?
* 0xC115 ???????????? 0x22 // 0x33 bit encoded ?
* 0xC117 ???????????? 0x22 // 0 40 8 0 bit encoded
* 0xC124 ???????????? 0x22 // 0x44. bit encoded. not sure why within seconds goes 44->4->44. only seen when engine off
* 0xE21B Calibration ID 0x22 // ascii
* 0xE21C PCM Part No Infix 0x22 // "
* 0xE21D PCM Part No Suffix 0x22 // "
* 0xE21E PCM Part No Revision 0x22 // "
* 0xE611 Calibration Hex File 0x22 // "
* 0xE901 Air Rly/Valve Enable 0x2F // sets both 0x0012 and 0x1688
* 0xE902 Air Rly/Valve Enable 0x2F // sets both 0x0012 and 0x1688
* 0xE906 Fuel Pump Enable 0x2F
* 0xE909 Target FO2 AFR 0x2F // 0x80 0x80 = 1 lambda max DID
* 0xE914 F Pump Speed Enable 0x2F
* 0xE915 APV Enable 0x2F
* 0xE91A RO2 Heater Enable 0x2F // NRC 78, then 0x1631 re-enables itself when 0xE968 sets to 0x07 0x01
* 0xE925 VDI Enable 0x2F
* 0xE926 SSV Enable 0x2F
*
* Still unaccounted for:
* TP sensor input voltage (supposedly different from sensors 1 + 2, is this a constant/difference ?)
* delivery mode
* test mode
* idle validation
* refrigerant switch
*

DIY and Attachments
For a lot more information, see the attached zip which contains my master Arduino IDE ino file: this has everything in this post and more.
To make use of this information you'll need to be Arduino and CAN savvy, obviously, and I trust you can glean what you need. Don't use my mess of an ino file -- just use the info in it, specifically what's used for seed/key stuff and all the definitions / global constants. The unint8_t * globals are everything that follow the appropriate SIDs, which gives you the combination of subfunction, PID, DID etc needed to construct the full CAN frame.

Limp Mode and OMP DTCs
If you look at my ino file, it is currently set-up to take measurements of the ECT and set off a buzzer if it's too hot. It also monitors the OMP position, and sets a relay I stuck in the back of the PCM to simulate a working OMP / OMP switch to bypass my broken pump causing limp mode. This is because, even with the OMP tables zeroed out, there are other tables not in Versatuner that set the OMP eg the start-up test causing limp mode, very cold start driving above 2krpm, etc.
Whilst you can control the OMP position to always be zero, preventing the setting of DTCs, remember that you can only control the PCM when the car is idling. Furthermore, when you release control of the OMP position, the start-up check function restarts itself so you can't avoid the PCM setting limp mode this way.

ciprianrx8

I had figured some of these myself... just spamming every possible ID across 0x01 and 0x22 modes. Didn't know about 2F though!
But beyond this, how do you determine the payload structure? For example at 0x1746, how'd you know what's the actual knock retard ?

jellybeans

Yeah you guys on here are quite resourceful, I've seen PIDs for tyre pressure and so on that I haven't captured, so it's definitely not the definitive list for everyone: for auto cars you should have a few different ones, and also querying other ECUs apart from the PCM might get you something.
As for payload structure, PIDs 0x00XX correspond to the OBD2 standard: 0x01 0x05 reads ECT, and thus 0x22 0x00 0x05 also reads ECT. For these, you consult ISO-15031-5 (which I had trouble uploading sorry) which tells you, for instance, that you minus 40 from the raw value returned to get deg C: response 0x62 0x00 0x05 0x30 gives you 0x30 = 48 = 8 C. Instead of using the ISO paper you can go here https://www.csselectronics.com/pages...gnostics-j1979
Now, for everything else like the knock retard, it's a matter of deduction. I set my Arduino up to print out values of PIDs whenever the values changed, and would drive around observing stuff. For the OMP position, you could see the maximum value coresponded to decimal 60 (for 60 steps) and that the values in the PID changed by 1, sequentially whenever it moved. For the throttle position voltages, by looking at the service highlights we know that they're 5V max systems. But, they have to be VERY accurate, so they would work in 1mV resolution. As a result, the PIDs with 0x06 0xXX fit this description that also change with the throttle. Another thing depending on what you're looking at, is bit encoding. So if you see lots of "nice" powers of 2: 0x01 0x44 0x80, for eg, this tells you immediately each nibble is a status. In 0x80 = 0b1000 0000, the first nibble might be saying 'front driver side door open'. 0b0100 could mean 'rear driver door open' and 0b1100 would mean they're both open.
For the knock retard, it only has to deal with a "small" amount of degrees, so I would presume 1 byte is returned (enough for 256 unique values). If this is not the case, it could suggest to you a few things: the MSB could be a sign bit i.e. 0x01 0xXX is advance, 0x00 0xXX retard... or maybe it measures in 0.01 degrees (unlikely).... In terms of resolution, whether it measures in 0.01, 0.5, 1 degrees, I'd look at what the leading and trailing spark PID values are because it would most probably be the same. The service highlight often has unintentional clues, too, if you read it carefully. I'd also try to look at how the raw data changes (increments of 0x10 vs 0x01 maybe) when driving it -- maybe flash a tune with maxxed trailing advance or a lean AFR and induce some slight knock.