SAE standard J1979 defines OBD-II modes 01 – 0A with according PIDs (Parameter-IDs) below. However most car manufacturers implemented a number of custom non-standard modes and PIDs beyond the common set. These modes & PIDs susually give additional and more accurate diagnostic data (often available as mode 22), trigger functional tests (e.g. mode 2F) or command resets of learned data (mode 11). Diagnostic apps like TorquePro can be parametrized to access and visualize custom PIDs outside of the standard but are not suitable to control PIDs that trigger tests or resets.
Personally I prefer to use a simple terminal to control according PIDs. To do so an according terminal app/program and a suitable connection is required. One option is a Bluetooth communication using a smartphone app. I use my ELM327 clone BT interface and a simple Android Bluetooth-terminal app. There’s a number of specific “ELM327 BT Terminal” apps available but I have not found one among them that’s working reliably. Most of the time they only report “AT+BRSF=24” and remain non-functional. It seems to be caused by a channle issue in the used SDP Bluetooth protocol. Just pick a Bluetooth terminal app among the many choices.
Here’s a sample session to start with:
ELM command AT Z initiates a complete reset of the PIC
AT DP reports the (in this case automatically) chosen protocol established to the car
AT H1 turns header printing on
AT S1 turns printing of spaces on
So far only commands towards the ELM327 PIC have been send.
01 05 is the first OBB-II request towards the car: Mode 01 PID 05 returns the engine coolant temperature, in this case hex 0x62 beeing 98 decimal. The value has an offset of 40 in order to be able to report negative temperatures down to -40°. Hence the real value here is 58°C.
The second request towards the car is 22 11 01. Mode 22 contains a lot of custom PIDs for my Mazda MX.5. A lot of these can also be found within the Ford mode-22 custom PIDs since Mazda and Ford had a quite intense partnership in the past. Unlike the standard modes/PIDs mode-22 uses a high byte and low byte to adress the PIDs. Just typing in the 3 byte command is not answered by the car connected here (MX-5 NC) since ELM reports “no data” meaning no ECU of the car has responded to the request within the expected time-frame.
Mode 22 commands work without additional preparations for a large number of car makers ECUs, however some Japanese brands like Mazda require to set up header data for placing mode 22 commands sucessfully. To address these requests correctly we need to specify the header to address the correct ECU:
Since we turned on header printing at the session-start we can see that request 0105 has been answered by ECU 7E8. We need to define the header to 7E0 to be able to address custom modes/PIDs to the correct ECU using ELM command AT SH 7E0. After that mode 22 requests are answered correctly:
Mode-22 PID 11 01 (brake pedal switch) is coded in bit 1 of the returned value. PID 13 40 (Accel.Pedal Position – full range) returns the accelerator pedal position. Unlike the corresonding mode 01 PIDs delivering potentiometer values the full range scaled up to 0xff/255 = pedal to the metal is returned here.
A simple terminal is a mighty tool to trigger specific non-standard custom commands.