OBDII plug in help
Moderators: Mangus, robertisaar, dex
OBDII plug in help
I've been working with the plug-in and got it to work on my 06' Pontiac.
I'm having difficulty understanding the definition of the PID request.
To obtain the data sample with an ELM327 interface I've seen that all it takes is 0x01 (mode 1) and 0x01 (01 PID identifier for current RPM)
I'm confused that the definition file indicates the command is "0x4D 0x30 0x31 0x50 0x30 0x43 0x53 0x30 0x32 0x52 0x31 " and don't know what the extra bytes are.
Can anyone explain this protocol or the usage.
I'd like to create a full OBDII list of std PIDs to log from.
Thanks,
JP
I'm having difficulty understanding the definition of the PID request.
To obtain the data sample with an ELM327 interface I've seen that all it takes is 0x01 (mode 1) and 0x01 (01 PID identifier for current RPM)
I'm confused that the definition file indicates the command is "0x4D 0x30 0x31 0x50 0x30 0x43 0x53 0x30 0x32 0x52 0x31 " and don't know what the extra bytes are.
Can anyone explain this protocol or the usage.
I'd like to create a full OBDII list of std PIDs to log from.
Thanks,
JP
// Expected command format:
// Mode + PID + Replies to gather (optional)
// 'M' + HH + 'P' + HH + 'S' + HH + 'R' + H
//
// 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, same as above but get all replies (return last reply)
// 'M' '0' '1' 'P' '0' '4' 'S' '0' '1'
If you turn out a cool definition, please do send it to me. The example definition with the plug-in download is, as you've noticed, very lacking.
// Mode + PID + Replies to gather (optional)
// 'M' + HH + 'P' + HH + 'S' + HH + 'R' + H
//
// 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, same as above but get all replies (return last reply)
// 'M' '0' '1' 'P' '0' '4' 'S' '0' '1'
If you turn out a cool definition, please do send it to me. The example definition with the plug-in download is, as you've noticed, very lacking.
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
Thanks for explaining that.
I'll do some playing with this and experiment with the "R" codes to get a feel for the usage.
Seems better than requesting a single sample every request (if that is its purpose).
sure looks like it will take some doin' to make a full file.
Definatly will share what I come up with.
Jp
I'll do some playing with this and experiment with the "R" codes to get a feel for the usage.
Seems better than requesting a single sample every request (if that is its purpose).
sure looks like it will take some doin' to make a full file.
Definatly will share what I come up with.
Jp
Eureka!
My pea brain finally broke through the start of this.
Yes, you only need to send "01 00" to get a value...
But...
That command must come as ASCII text characters! (NOT HEX directly)
So "01 00" = "30 31 20 30 30 0D'
"0D" on the end is a period in my logger. Might be needed as EOL or something.
30 in ASCii = 0
31 in ASCii = 1
20 in ASCii = "space"
30 in ASCii = 0
30 in ASCii = 0
More to come...
My pea brain finally broke through the start of this.
Yes, you only need to send "01 00" to get a value...
But...
That command must come as ASCII text characters! (NOT HEX directly)
So "01 00" = "30 31 20 30 30 0D'
"0D" on the end is a period in my logger. Might be needed as EOL or something.
30 in ASCii = 0
31 in ASCii = 1
20 in ASCii = "space"
30 in ASCii = 0
30 in ASCii = 0
More to come...
This is moving along, have the first 10 PIDs working (04-0D)
Does take a lot of entry time to create. this file will be HUGE if all PIDs are entered. No way to copy/paste when doing it.
I'm grouping them into sets of 10 so macros can be executed sequentially and if the speed becomes a problem some can be removed from the scan without deleting the definition of them.
9600 baud rate doesn't give fast enough response, going to try 38400 next to see if it gets better. Ports are at 115200 rate with max buffers.
Is there a way to use bit coded response as a control for which PID macros are run?
If not it would be a good addition because you have to poll the ECM for the actual supported PIDs available.
Polling the ones that are not supported would be a waste of bandwidth in the comm line.
Grouping in the "commands" and "bitmasks" list might be helpful too because the list is growing out of control.
Back to typing...
Jp
Does take a lot of entry time to create. this file will be HUGE if all PIDs are entered. No way to copy/paste when doing it.
I'm grouping them into sets of 10 so macros can be executed sequentially and if the speed becomes a problem some can be removed from the scan without deleting the definition of them.
9600 baud rate doesn't give fast enough response, going to try 38400 next to see if it gets better. Ports are at 115200 rate with max buffers.
Is there a way to use bit coded response as a control for which PID macros are run?
If not it would be a good addition because you have to poll the ECM for the actual supported PIDs available.
Polling the ones that are not supported would be a waste of bandwidth in the comm line.
Grouping in the "commands" and "bitmasks" list might be helpful too because the list is growing out of control.
Back to typing...
Jp
16 equations ???
I have a run time parameter that requires a conversion of :
(A*256)+B = Seconds
A = MSB, B = LSB
How can I split the 16 bit output to create this equation?
I'm thinking you have a way to do it and I'm being dense and not seeing it.
thanks,
Jp
(A*256)+B = Seconds
A = MSB, B = LSB
How can I split the 16 bit output to create this equation?
I'm thinking you have a way to do it and I'm being dense and not seeing it.
thanks,
Jp
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
To clarify the question,
I'm figuring to have the data come in as two 8 bit values.
Using the packet offset as 0 (MSB) and 1 (LSB) for each of the two values.
Then having the main (set to 16 bit) value calculate using linked values of A = MSB, B = LSB.
I think that should work but am unsure of the settings for the two separate values being 8 bit or not.
I'm figuring to have the data come in as two 8 bit values.
Using the packet offset as 0 (MSB) and 1 (LSB) for each of the two values.
Then having the main (set to 16 bit) value calculate using linked values of A = MSB, B = LSB.
I think that should work but am unsure of the settings for the two separate values being 8 bit or not.
wouldn't I loose the LSB that way?robertisaar wrote:yeah, that's actually the exact same format that's seen with the OBD1 PCMs, just X * 1 = seconds, with X being the 16 bit value.
I think I'm just being dense on this at the moment.
Last edited by JP86SS on Mon Sep 24, 2012 4:47 pm, edited 1 time in total.
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
Headers?
Here is a sample of my data:
definition seems to be getting what I'm asking for, but...
I'm getting "ghost data" on the vehicle speed that seems to be the same as the RPM level.
I've checked the commands and response setups and am wondering if I'm displaying the right values at all. (the 1's at the end of the commands are not in my sent string)
The response is set for 1 in all the payload boxes except for the 16 bit (set to 2) or binary 4 byte values that request PID status (set 4).
Seeing how the response also includes the command, should I be using a 2 byte offset or possibly entering the command into the "Header" field as hex characters?
Just thinking that may be another part I'm missing.
TIA
Code: Select all
000001: ?
000002:
000003: >ATWS
000004:
000005:
000006: ELM327 v1.5
000007:
000008: >ATE0
000009: ATE0
000010: OK
000011:
000012: >ATL0
000013: OK
000014:
000015: >ATS0
000016: OK
000017:
000018: >01001
000019: 410080000001
000020:
000021: >01201
000022: 412080018001
000023:
000024: >01401
000025: 414040000000
000026:
000027: >01041
000028: 410400
000029:
000030: >01001 (Bad command should be 0105, I fixed it!)
000031: 4100BFBFB993
000032:
000033: >01061
000034: 410680
000035:
000036: >01071
000037: 41077F
000038:
000039: >01081
000040: 410880
000041:
000042: >01091
000043: 41097B
000044:
000045: >010A1
000046: NO DATA
I'm getting "ghost data" on the vehicle speed that seems to be the same as the RPM level.
I've checked the commands and response setups and am wondering if I'm displaying the right values at all. (the 1's at the end of the commands are not in my sent string)
The response is set for 1 in all the payload boxes except for the 16 bit (set to 2) or binary 4 byte values that request PID status (set 4).
Code: Select all
000036: >01071 Mode 1, 07 PID request, 1 is added by plug in?
000037: 41077F 41 indicates mode 1, 07 is PID#, 7F is data (8 bit)
Just thinking that may be another part I'm missing.
TIA
HELP ! Possible Issue ?
Started over and am having some success.
I now have over 60 PID data items defined (around 16 working well) but can't make the command association (in the "Values" dialog) list them all.
The way I'm doing each PID
a.) Transmit definition
b.) response definition
c.) macro definition (sequence a and b then a slight delay)
The response definition "name" is used in the "Value" dialog box and is used as the "command association" so the "Value" is derived from that receipt of data from the PCM.
The "Command Association" dropdown does not scroll to show all available items, hence you can't define the "Value" item to go with the data retreived.
Wish I found this earlier since I see there is a new build out today
I'm going to install that new one now but don't think this will change.
If there is a different way to do this LMK.
I hope the description clear, Can send the new file if you like.
Jp
I now have over 60 PID data items defined (around 16 working well) but can't make the command association (in the "Values" dialog) list them all.
The way I'm doing each PID
a.) Transmit definition
b.) response definition
c.) macro definition (sequence a and b then a slight delay)
The response definition "name" is used in the "Value" dialog box and is used as the "command association" so the "Value" is derived from that receipt of data from the PCM.
The "Command Association" dropdown does not scroll to show all available items, hence you can't define the "Value" item to go with the data retreived.
Wish I found this earlier since I see there is a new build out today
I'm going to install that new one now but don't think this will change.
If there is a different way to do this LMK.
I hope the description clear, Can send the new file if you like.
Jp
Found the problem, It's ME again!
My bad.
I didn't check the "Process Data" box in the response!
All is good (or at least better)
I left the post as is so if someone else makes the same mistake they'll know what to do.
JP
Sure thing once I get it displaying better.
I have been working on this the last couple of days and have made good progress getting data from the ELM Bluetooth device.
I have it over 10 Hz but am not getting values to transfer to TP properly.
The serial port monitor log shows good data coming back, I'm just not getting the data out of the packet right.
This log shows part of the scan macro executing.
I have tried adding the header (2 bytes) with "align to header" but got all errors in TP with 0 Hz.
Even during that run, the Serial port has always showed correct responses being received.
Unchecking the "align" box made data come into TP at up to 18 Hz for like 30 items but they are all zeros.
Should I be setting up the offset to be "2" ???
0 and 1 for the first two bytes, then 2 for the payload offset position.
Its too late tonight to try again but that is my next try.
A little confused if the header has any impact on offset position if it is used.
Jp
I have been working on this the last couple of days and have made good progress getting data from the ELM Bluetooth device.
I have it over 10 Hz but am not getting values to transfer to TP properly.
The serial port monitor log shows good data coming back, I'm just not getting the data out of the packet right.
Code: Select all
Monitored using a serial port monitoring program. (some PIDs removed, not the entire list)
Commands entered into TunerPro are Hex of the Ascii char desired to transmit. (works well)
Requests from TP macro are in Ascii of the Hex value (ELM commands are Ascii)
Response from ELM device is in Hex.
************** INITIALIZING TP CONNECTION ON BLUETOOTH ELM DEVICE **************
Port opened by process "TunerPro.exe" (PID: 2320)
Request: 1/12/2013 9:32:45 PM.22464
3F 0D ?.
Answer: 1/12/2013 9:32:46 PM.50564 (+0.0156 seconds)
3F 0D 0D 3E ?..>
Request: 1/12/2013 9:32:46 PM.50564 (+0.0000 seconds)
41 54 57 53 0D ATWS.
Answer: 1/12/2013 9:32:46 PM.53664 (+0.0312 seconds)
0D 0D 45 4C 4D 33 32 37 20 76 31 2E 35 0D 0D 3E ..ELM327 v1.5..>
Request: 1/12/2013 9:32:46 PM.53664 (+0.0000 seconds)
41 54 45 30 0D ATE0.
Answer: 1/12/2013 9:32:46 PM.55264 (+0.0156 seconds)
41 54 45 30 0D 4F 4B 0D 0D 3E ATE0.OK..>
Request: 1/12/2013 9:32:46 PM.55264 (+0.0000 seconds)
41 54 4C 30 0D ATL0.
Answer: 1/12/2013 9:32:46 PM.58364 (+0.0312 seconds)
4F 4B 0D 0D 3E OK..>
Request: 1/12/2013 9:32:46 PM.58364 (+0.0000 seconds)
41 54 53 30 0D ATS0.
Answer: 1/12/2013 9:32:46 PM.59964 (+0.0156 seconds)
4F 4B 0D 0D 3E OK..>
*********** START OF SCANNING “MY MACRO” ***************************
Request: 1/12/2013 9:32:46 PM.66164 (+0.0624 seconds)
30 31 30 34 31 0D 01041.
Answer: 1/12/2013 9:32:46 PM.69264 (+0.0312 seconds)
34 31 30 34 34 31 0D 0D 3E 410441..>
Request: 1/12/2013 9:32:46 PM.95764 (+0.2652 seconds)
30 31 30 35 31 0D 01051.
Answer: 1/12/2013 9:32:46 PM.98964 (+0.0312 seconds)
34 31 30 35 35 32 0D 0D 3E 410552..>
Request: 1/12/2013 9:32:46 PM.25464 (+0.2652 seconds)
30 31 30 36 31 0D 01061.
Answer: 1/12/2013 9:32:46 PM.28564 (+0.0312 seconds)
34 31 30 36 37 39 0D 0D 3E 410679..>
Request: 1/12/2013 9:32:47 PM.55064 (+0.2652 seconds)
30 31 30 37 31 0D 01071.
Answer: 1/12/2013 9:32:47 PM.58164 (+0.0312 seconds)
34 31 30 37 38 36 0D 0D 3E 410786..>
Request: 1/12/2013 9:32:47 PM.84764 (+0.2652 seconds)
30 31 30 38 31 0D 01081.
Answer: 1/12/2013 9:32:47 PM.87864 (+0.0312 seconds)
34 31 30 38 37 38 0D 0D 3E 410878..>
Request: 1/12/2013 9:32:47 PM.14364 (+0.2652 seconds)
30 31 30 39 31 0D 01091.
Answer: 1/12/2013 9:32:47 PM.19064 (+0.0468 seconds)
34 31 30 39 38 36 0D 0D 3E 410986..>
I have tried adding the header (2 bytes) with "align to header" but got all errors in TP with 0 Hz.
Even during that run, the Serial port has always showed correct responses being received.
Unchecking the "align" box made data come into TP at up to 18 Hz for like 30 items but they are all zeros.
Should I be setting up the offset to be "2" ???
0 and 1 for the first two bytes, then 2 for the payload offset position.
Its too late tonight to try again but that is my next try.
A little confused if the header has any impact on offset position if it is used.
Jp
response conversion
I just thought of something...
The Plug In doesn't convert Hex to ascii for the commands to the ELM,
Does it convert Ascii to Hex on the response?
I'm thinking TP is looking for the hex response to be fed in.
My port monitor program is making the hex conversion in the printout so I started my late night questioning everything again
JP
The Plug In doesn't convert Hex to ascii for the commands to the ELM,
Does it convert Ascii to Hex on the response?
I'm thinking TP is looking for the hex response to be fed in.
My port monitor program is making the hex conversion in the printout so I started my late night questioning everything again
JP
I'll dig into this a bit more this weekend. Yes, when data is returned from the vehicle, the plug-in converts the ASCII to hex, and therefore the data returned is the raw PID data you requested, starting at offset 0 (so your packet offsets should be 0 for all values).
The download should include a sample ADX with three values defined (Engine Load, RPM, and Throttle Position).
The download should include a sample ADX with three values defined (Engine Load, RPM, and Throttle Position).
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
The PID hex I want to enter is $1470 four hex ASCII bytes is this possible?Mangus wrote:// Expected command format:
// Mode + PID + Replies to gather (optional)
// 'M' + HH + 'P' + HH + 'S' + HH + 'R' + H
//
// 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, same as above but get all replies (return last reply)
// 'M' '0' '1' 'P' '0' '4' 'S' '0' '1'
If you turn out a cool definition, please do send it to me. The example definition with the plug-in download is, as you've noticed, very lacking.
Thanks
I'm adding some more parameters at the moment, it is possible to copy/paste between edit boxes - maybe Mark changed it. I'm adding the following:JP86SS wrote: No way to copy/paste when doing it.
Jp
MAP
IAT
Baro
Fuel System Closed Loop/open loop flag
I may add some more - I'm working on a 99/00 Miata and I need to confirm which parameters are supported. I'll send Mark the updated definition when I've tested it.
I have this problem as well, in order to access the proprietary codes I need to send four ascii bytes. The standard OBD2 PIDs are limited but there is a bunch of useful information that could be accessed like battery voltage and injector pulsewidth.petenz wrote: The PID hex I want to enter is $1470 four hex ASCII bytes is this possible?
Thanks
Updated plug in
Can you confirm if the ELM plug In was updated to use the 4 char.
Was looking to restart this again.
THX,
Jp
Was looking to restart this again.
THX,
Jp