I have looked extensively for something that explains the actual creation and structure of the ADX files but haven't been able to find much.
Can anyone explain what the perpose of each of the values in the Hex cmd string is?
For example I have an ADX I have managed to knock together that works with my ELM interface (which is hooked up to an arduino as a fake OBD2 output) that has the following values:
Hex - 0x4D 0x30 0x31 0x50 0x30 0x43 0x53 0x30 0x32 0x52 0x31
ASCII - M01 P0C S02 R1
Now I understand that the two values after the 'P' are the OBD PID in hex (PID 12 in this case) , and that has been enough of an understanding to get most channels working but it would be nice to understand a little more of what the values in that string actually do.
Any advice on this topic is greatly appreciated.
ADX file ELM setup (Hex cmd String)
Moderators: Mangus, robertisaar, dex
Re: ADX file ELM setup (Hex cmd String)
Here's some notes from the code. I really need to open-source the ELM327 plug-in. It's incomplete and could use some love and attention from a developer with more time than I have, at this point.
// Expected command format:
// Mode + PID (1 or 2 byte) + expected reply size (1, 2, etc) + Reply count to gather (optional)
// 'M' + HH + 'P' + HH + 'S' + HH + 'R' + H
// 2-byte PID:
// 'M' + HH + 'P' + HH + HH + 'S' + HH + 'R' + H
//
// Pass-through command - all bytes after the 'P' are sent directly to the ELM
// 'P' + HH + ...
//
// Where "HH" is two hex ASCII bytes (e.g. 'F' 'F' for 0xFF). 'M' is for Mode,
// 'P' is for PID, 'S' is for size of PID data reply, and 'R' is for reply count.
// Note that the 'R' data is a single hex digit (e.g. '2').
//
// Example PID request for Mode 1 PID 4, get only 1st reply:
// 'M' '0' '1' 'P' '0' '4' 'S' '0' '1' 'R' '1'
// Example PID request, same as above but get all replies (returns only last reply)
// 'M' '0' '1' 'P' '0' '4' 'S' '0' '1'
// Example 2-byte PID request (Mode 1, PID 0x0432, 2-byte reply size)
// 'M' '0' '1' 'P' '0' '4' '3' '2' 'S' '0' '2'
// Example pass-through command (AT warm reboot command - ATWS)
// 'P' 'A' 'T' 'W' 'S'
// NOT IMPLEMENTED Example hardware command (show header bytes in response)
// 'H' 'A' 'T' 'H' '1'
// Expected command format:
// Mode + PID (1 or 2 byte) + expected reply size (1, 2, etc) + Reply count to gather (optional)
// 'M' + HH + 'P' + HH + 'S' + HH + 'R' + H
// 2-byte PID:
// 'M' + HH + 'P' + HH + HH + 'S' + HH + 'R' + H
//
// Pass-through command - all bytes after the 'P' are sent directly to the ELM
// 'P' + HH + ...
//
// Where "HH" is two hex ASCII bytes (e.g. 'F' 'F' for 0xFF). 'M' is for Mode,
// 'P' is for PID, 'S' is for size of PID data reply, and 'R' is for reply count.
// Note that the 'R' data is a single hex digit (e.g. '2').
//
// Example PID request for Mode 1 PID 4, get only 1st reply:
// 'M' '0' '1' 'P' '0' '4' 'S' '0' '1' 'R' '1'
// Example PID request, same as above but get all replies (returns only last reply)
// 'M' '0' '1' 'P' '0' '4' 'S' '0' '1'
// Example 2-byte PID request (Mode 1, PID 0x0432, 2-byte reply size)
// 'M' '0' '1' 'P' '0' '4' '3' '2' 'S' '0' '2'
// Example pass-through command (AT warm reboot command - ATWS)
// 'P' 'A' 'T' 'W' 'S'
// NOT IMPLEMENTED Example hardware command (show header bytes in response)
// 'H' 'A' 'T' 'H' '1'
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am