Tuner Pro V5 and OBDII plug-in?

Printable View

09-03-2012
JP86SS

Tuner Pro V5 and OBDII plug-in?

Wondering if anyone has has success using the plug-in for the ELM converter?
I just bought a cheap BT one from sleezebay and am figuring the thing won't work as expected like others have found.
At least if someone confirms they have connected with it I would feel better.
For the $$ i figured i'd give it a try with the Android phone and the "Torque" software.
Worst case with all of this is I will use the Droid as a dual programmable gauge and save $200 from buying those.
The "interceptor" is nice but very pricey!
http://www.pfyc.com/pc/GN2110/GTGAU/...+vehicles.html

I'd like to log my 06' LS2 GTO with TP V5 if possible and see whats going on in there:)
Any info on the "E40" datastream PIDs?
I guess there are some GM specific PIDs for oil psi, trans temp that are not in the std set.
Just fishin for info on this to begin...
Jp
09-03-2012
Kid-Neutron

I never did get that to work?

There are standard OBDII PIDs and then manufacturer enhanced PIDS.

ScanXL Pro with the GM enhanced PIDS is sweet so far. It's simalar to EFI Live Scan and has a feel of TunerPro. More data then you could dream of and specilty PIDS built in for track times, torque, MPG etc... graphs, maps and dashboards, really has a wow factor for joe smoe, does read and clear codes, watch data or record and all data needed for tuning as well! So far it has more then what is needed to use with TunerCat OBDII.

It's supposed to work with the Innovate OT-2 wireless but as of now no luck. If you just want data with bells and whistles to iPhone it's got a sweet app but I've never tried it and don't know if the app will work on other phones.

In the end if you want to do anything with data you'll need EFI Live or TunerCat OBDII with cables to re-flash PCM. EFI Live has the Scan with it so no need for ScanXL. TunerCat OBDII can still be bought with a RoadRunner, which is back ordered and I'm still waiting...

EDIT: EagleMark on kids laptop again...
09-04-2012
JP86SS

ScanXL looks pretty good.
I'm bouncing between just logging ability and full tuning.
EFI Live is a ton of $$, TunerCat and others are also big $$.
I don't mind spending if it turns into a long term use but for the short term I only need to see what is going on (logging)
i know once I see an issue I'll want to tweak it...
you know how that goes.

PS,
Uou really should buy your own computer, that kid is going to get sick of you borrowing his!
09-04-2012
EagleMark

Quote:

Originally Posted by JP86SS

PS,
Uou really should buy your own computer, that kid is going to get sick of you borrowing his!

Ouch! :laugh:

I need a backup laptop but have never even a qlitch with the HP laptop I bought about 2-3 years ago.
09-10-2012
JP86SS

i actually got it to work today.
Had allot of bluetooth/comm setting issues but it did log some data on the GTO.
I'm looking into the hex commands going to the ELM327 now to see how to build a full set of data into the ADX.
There are a bunch more hex chars going to the device in the request command than what I'm seeing is required.
Not sure why this is, so if anyone has looked at them and has an idea, LMK.
Thanks,
Jp
09-10-2012
EagleMark

Do you realize if it works? How does it get the PIDS? Do you have any idea how many PIDS there are? Have you looked at EFI Live or Scan XL Pro custom PIDS? It's amazing!

I wouldn't want to write that ADX file... how does the ELM Plug in work? Do you need an ADX file?
09-10-2012
RobertISaar

luckily, one ADX would cover almost all applications, to a certain degree.

i'd rather do that than the ~250+ that i have in progress for the GM OBD1 applications.
09-10-2012
PJG1173

I was looking into this a while back but lost interest but I did find this. http://www.delcohacking.net/forums/v...&t=1320#p14773
09-14-2012
JP86SS

I got it to work with the default ADX file.
Looking at the file the commands are kind of foreign to me.
From what I'm reading, all it takes is the "$01 and the PID number in hex to get the current value.
The ADX with the plug in has a longer string that I can't figure out. (like multiple more hex codes)

I downloaded "touchscan" (a free program that went commercial) and it has a raw data screen that has some of the same long format retrieval codes going to the PCM.
I'm attempting to correlate the port monitored hex chars to an actual request / recieve theme but its not adding up in my pea brain.
I'd really like to make a std OBDII set of data from this (so any compliant car can use it) and then investigate OEM PIDS for my 06 GTO.
Its kind of working but I'm not grasping what is really going on there.
The supplied ADX only has throttle position, RPM and one other parameter (I forget what it was)
Any ideas would be appreciated.
I'll try to grab some of the data and post it so you can see what I'm describing better.
Jp
09-14-2012
JP86SS

Wondering if the additional commands are to interpet through the ELM device interface.
Not sure...
Still digging with enthusiasm :)
Jp
09-14-2012
JP86SS

Quote:

Originally Posted by RobertISaar

luckily, one ADX would cover almost all applications,

That is my plan
09-14-2012
RobertISaar

Quote:

Originally Posted by JP86SS

Wondering if the additional commands are to interpet through the ELM device interface.

if i had to guess, that would be where i would expect extra commands to be needed.
09-15-2012
JP86SS

This is a raw data dump from the Touchscan SW as it connected and was displaying data.
Its not all of it just the first part where it connected and then I started the engine.
I'm "supposed to be" the E40 setup on my car.
This program finds it as the "7EA" or "7E8" not sure why that is.

Code:

Trying Protocol: ISO 15765-4 CAN (11 bit ID, 500 Kbaud) ATSP 6: [OK] 01 00: [41 00 80 00 00 01 41 00 BF BF B9 93 ] Protocol detected: ISO 15765-4 CAN (11 bit ID, 500 Kbaud) ATH1: [OK] Reading vehicle information 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 20: [7EA 06 41 20 80 01 80 01 7E8 06 41 20 80 07 E0 19 ] 01 40: [7EA 06 41 40 40 00 00 00 7E8 06 41 40 FE D0 00 00 ] Detected PIDs: ECU: 7EA 0x00 - SupportedPIDs0 0x01 - MonitorStatus 0x20 - SupportedPIDs1 0x21 - DistanceTraveledWithMILOn 0x30 - NumWarmUpsSinceCodesCleared 0x31 - DistanceSinceCodesCleared 0x40 - SupportedPIDs2 0x42 - ControlModuleVoltage ECU: 7E8 0x00 - SupportedPIDs0 0x01 - MonitorStatus 0x03 - FuelSystemStatus 0x04 - EngineLoad 0x05 - EngineCoolantTemp 0x06 - ShortTermFuelTrimBank1 0x07 - LongTermFuelTrimBank1 0x08 - ShortTermFuelTrimBank2 0x09 - LongTermFuelTrimBank2 0x0B - IntakeManifoldPressure 0x0C - EngineRPM 0x0D - VehicleSpeed 0x0E - TimingAdvance 0x0F - IntakeAirTemperature 0x10 - MassAirFlowRate 0x11 - ThrottlePosition 0x13 - OxygenSensorsPresent 0x14 - OxygenSensor1Voltage 0x14 - OxygenSensor1ShortTermFuelTrim 0x15 - OxygenSensor2Voltage 0x15 - OxygenSensor2ShortTermFuelTrim 0x18 - OxygenSensor5Voltage 0x18 - OxygenSensor5ShortTermFuelTrim 0x19 - OxygenSensor6Voltage 0x19 - OxygenSensor6ShortTermFuelTrim 0x1C - OBDStandard 0x1F - RunTimeSinceEngineStart 0x20 - SupportedPIDs1 0x21 - DistanceTraveledWithMILOn 0x2E - CommandedEvaporativePurge 0x2F - FuelLevelInput 0x30 - NumWarmUpsSinceCodesCleared 0x31 - DistanceSinceCodesCleared 0x32 - EvapSystemVaporPressure 0x33 - BarometricPressure 0x3C - CatalystTemperatureBank1Sensor1 0x3D - CatalystTemperatureBank2Sensor1 0x40 - SupportedPIDs2 0x41 - MonitorStatusThisDriveCycle 0x42 - ControlModuleVoltage 0x43 - AbsoluteLoadValue 0x44 - CommandEquivalenceRatio 0x45 - RelativeThrottlePosition 0x46 - AmbientAirTemp 0x47 - AbsoluteThrottlePositionB 0x49 - AcceleratorPedalPositionD 0x4A - AcceleratorPedalPositionE 0x4C - CommandedThrottleActuator 09 0A: [NO DATA] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] ATSH 7DF: [OK] 09 02: [7E8 10 14 49 02 01 36 47 32 7E8 21 56 58 31 32 55 30 36 7E8 22 4C 35 36 31 35 37 37 ] 01 01: [7EA 06 41 01 00 04 00 00 7E8 06 41 01 00 07 65 00 ] ECU disconnected AT@1: [OBDII to RS232 Interpreter] 01 0D: [7E8 03 41 0D 00 ] AT@2: [?] AT@2: [?] AT@2: [?] AT@2: [?] 01 10: [7E8 04 41 10 02 75 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 44: [7E8 04 41 44 80 00 ] STI: [?] STI: [?] STI: [?] STI: [?] 01 04: [7E8 03 41 04 33 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 0B: [7E8 03 41 0B 25 ] 01 1C: [7E8 03 41 1C 07 ] 01 0C: [7E8 04 41 0C 09 06 ] 01 0E: [7E8 03 41 0E 97 ] 01 11: [7E8 03 41 11 2D ] 01 14: [7E8 04 41 14 A9 80 ] 01 15: [7E8 04 41 15 81 FF ] 01 18: [7E8 04 41 18 A9 80 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 19: [7E8 04 41 19 85 FF ] 01 2E: [7E8 03 41 2E 00 ] 01 33: [7E8 03 41 33 63 ] 01 3C: [7E8 04 41 3C 11 9E ] 01 3D: [7E8 04 41 3D 11 9E ] 01 43: [7E8 04 41 43 00 2F ] 01 4C: [7E8 03 41 4C 14 ] 01 0D: [7E8 03 41 0D 00 ] 01 10: [7E8 04 41 10 02 46 ] 01 44: [7E8 04 41 44 80 00 ] 01 04: [7E8 03 41 04 30 ] 01 0B: [7E8 03 41 0B 24 ] 01 0C: [7E8 04 41 0C 08 85 ] 01 0E: [7E8 03 41 0E 9B ] 01 0F: [7E8 03 41 0F 66 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 11: [7E8 03 41 11 2D ] 01 14: [7E8 04 41 14 AE 7F ] 01 15: [7E8 04 41 15 83 FF ] 01 18: [7E8 04 41 18 A9 7F ] 01 19: [7E8 04 41 19 86 FF ] 01 2E: [7E8 03 41 2E 00 ] 01 33: [7E8 03 41 33 63 ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 3C: [7E8 04 41 3C 11 B2 ] 01 3D: [7E8 04 41 3D 11 B2 ] 01 43: [7E8 04 41 43 00 2F ] 01 4C: [7E8 03 41 4C 15 ] 01 0D: [7E8 03 41 0D 00 ] 01 10: [7E8 04 41 10 02 53 ] 01 44: [7E8 04 41 44 7F E0 ] 01 04: [7E8 03 41 04 31 ] 01 0B: [7E8 03 41 0B 25 ] 01 0C: [7E8 04 41 0C 08 F1 ] 01 0E: [7E8 03 41 0E 95 ] 01 11: [7E8 03 41 11 2E ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 14: [7E8 04 41 14 9B 7F ] 01 15: [7E8 04 41 15 87 FF ] 01 18: [7E8 04 41 18 A2 7F ] 01 19: [7E8 04 41 19 85 FF ] 01 2E: [7E8 03 41 2E 00 ] 01 33: [7E8 03 41 33 63 ] 01 3C: [7E8 04 41 3C 11 BC ] 01 3D: [7E8 04 41 3D 11 BC ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ] 01 43: [7E8 04 41 43 00 31 ] 01 4C: [7E8 03 41 4C 15 ] 01 0D: [7E8 03 41 0D 00 ] 01 10: [7E8 04 41 10 02 58 ] 01 44: [7E8 04 41 44 80 00 ] 01 04: [7E8 03 41 04 31 ] 01 0B: [7E8 03 41 0B 24 ] 01 0C: [7E8 04 41 0C 08 B5 ] 01 0E: [7E8 03 41 0E 98 ] 01 11: [7E8 03 41 11 2E ] 01 00: [7EA 06 41 00 80 00 00 01 7E8 06 41 00 BF BF B9 93 ]
09-15-2012
JP86SS

Just got a reply from Magnus on this :)

Code:

// 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'

Will be playing around this weekend, stay tuned (yes, that was a bad pun!)
Jp
09-16-2012
JP86SS

ASCii text !!!!!

from my post on Mark's site.

Quote:

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...
09-16-2012
RobertISaar

that's...... so odd.

why would they purposely make the OBD2 PID request protocall with more overhead than necessary?
09-16-2012
1project2many

So the comms are ASCII representation of hex?? Huh????? Did someone put Microsoft in charge of OBDII PID's???

Maybe I can find time to try hammering away at this PCM I have here using ASCII xmits instead of hex.
09-16-2012
JP86SS

I think the communication protocol is in Hex, the Plug-in or the interpreter to the ELM327 is using ASCii based input (and possibly output)
The confusing part is that the existing command in TP has 0x20 indicating Hex but is a hex representation of an ASCii character "space'.
Still wrapping my brain around all of this.

The response from the interpreter/Plug-in appears to be just hex because there is no offset or anything in the response command definition.

Figuring at this point, Send ASCii, Receive in Hex.
the interpreter must be sectioning out the variable size data from the 11 bit CANbus response format.
09-19-2012
1project2many

That makes more sense. I checked the ELM327 documentation. Hyperterm is suggested as the easiest way to communicate with the chip which means yes, ASCII. If you're oldschool enough to have used hyperterm then most of this will seem old hat. I'd copy the text here but the copy I'm looking at is protected so that's not an option. There's slow or fast comms with the ELM (9600 or 38k baud). All responses by ELM are terminated with single carriage return (0D) and optionally, with linefeed as well. AT Z is reset signal to ELM which may be in the file you're looking at. Commands to ELM are preceded with AT while commands intended to be passed onto OBDII controller are only allowed to contain the ASCII codes for hex digits, and all commands must be terminated by carriage return. Any commands sent to ELM by pc take preference over comms on OBDII data and ELM will stop OBDII comms if a new command is received from PC before an answer is returned on OBDII line. Timing is everything.

http://elmelectronics.com/DSheets/ELM327DS.pdf
09-19-2012
1project2many

Here's a link to GM mode 6 PIDs.
http://service.gm.com/gmspo/mode6/

These can also be used as scan data.
09-21-2012
JP86SS

Thanks for the help :)
I'm finding out that timing is everything.
I thought I was getting good data until I added 10 items.
Now they seem to be "ghosting" into each other (speed rises with RPM, etc)
I have to go back and see if the plug-in is terminating the command or if I need to.
Could need a delay after each item as well.
seems odd that if my Bluetooth device is seen by the Winders tool it won't connect but if Windows and the BT app do not see the device, it connects at 38.4K.
The rabbit hole is getting deeper...
09-21-2012
RobertISaar

i believe that's partly why a lot of the ELM327 based applications have PID "priorities". high priority gets updated often, low priority, not so much.

it would seem that the OBD2 communications are pretty picky about message length/repetition.
09-21-2012
JP86SS

Just looked at my port sniffer log,
Seems you need to terminate request with a CR. (will add ASCii 0D to the end of all my requests and try again)
Man those things come in handy.
Jp
09-21-2012
1project2many

There's a note in the documentation about a timeout while waiting for data to ensure items don't get lost of missed. Apparently if you know how many data items are going to be returned there's a way around this. I don't know if it's relevant but it was implemented for scantool software to increase refresh rates so it may be applicable.

What are you using for a port sniffer?
09-22-2012
JP86SS

The 0D at the end seems to cause some strange output.
The returning data now has two "0d" chars at the end and some have a ">" added.
The "space" character has also disappeared from the transmit side of things and the codes are coming out together.
Still returned data but they do seem to be ovewriting each other.
Could be that the plug-in is adding it (CR) already.
May also have something to do with the "7EA" response leading the "7E8" response data.
I want the 7E8 data.
I could be picking up the wrong response. Still need to play with it and record the comms.
A small delay after each macro of request/reply might help.

I downloaded a trial of a Serial Port monitor. It works real good but only has another couple of days to use it.
I'll dig around the net and see if I can find something to use after that.
Just need raw data, although the packet count screen is helpful to see how fast my routines are executing.
I'm 1/3 of what a commercial logger is doing but that could be erroneous counts due to overlapping.

I did see that on one of the logs that the ELM initialization reset the comm to 9600 rate, definition is set for 38.4K
09-22-2012
EagleMark

Your having fun way over my head... but wouldn't the ADX already done for LS1 have some of this info?
http://www.gearhead-efi.com/Fuel-Inj...cat-OBD2-cable
09-23-2012
JP86SS

Never saw that, That would have been helpful a couple weeks ago :)
My file has more in it now though.
The commands are the same as mine so I'll go back to not using the "0D"
If that file has been proven then I may have comm issues on my laptop causing the scrambles.
09-30-2012
JP86SS

Here is a sample of my data:

Code:

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

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).

Code:

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)

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
12-28-2012
JP86SS

found out the 7E8 is the PCM and the other could be a trans controller or another module on the network.
Still trying to make this work.
i'm going to try the header and footers with variable length replys to see if that works better.
12-28-2012
34blazer

sorry to 'jack your thread but where the heck did you guys learn all this?! LOL
01-02-2013
EagleMark

1 Attachment(s)

I found some files while going through my back-up before my computer crash of 2012... :rolleye:

Hope they help.
01-03-2013
1project2many

Quote:

sorry to 'jack your thread but where the heck did you guys learn all this?! LOL

Everywhere. It's all over the 'net. The hardest part is figuring out where to start. I use OBDII every day at work but not at this level. I spent some time a few years ago trying to communicate with an OBDII pcm but I've forgotten most of what I learned. So I've spent the last few days looking through posts and threads reading this and that. And just like anyone else, I can get overwhelmed with the amount of information. If I see something I think might be useful later I download it and save it. The files Eaglemark just posted are a great example. I think I've got the same data in two or three different formats but I'm going to download it anyway. Sometimes I'll find a thread with a good discussion so I save the whole thing. Eventually I get to a point where I decide I want to "Do something" and I get to work. In my experience it's much easier to learn new info if you're trying to apply it at the same time as you're learning it.
01-08-2013
JP86SS

Quote:

Originally Posted by 1project2many

In my experience it's much easier to learn new info if you're trying to apply it at the same time as you're learning it.

That's exactly it.
You just have to keep picking at it till something is figured out, then poke at it some more.
I can't seem to get anything to work now so I'll take a step back and get one item to read out, then take everything I've learned up to this point and build up the definition again.
Hopefully it will only take 2-3 more times before it all works out.
Jp
01-08-2013
EagleMark

May be late to the game here but there is a lot of good info at:
http://obdcon.sourceforge.net/2010/06/obd-ii-pids/
01-13-2013
EagleMark

1 Attachment(s)

Alos found this on Moates site.
01-21-2013
JP86SS

Got some more info and testing done.
The TP plug-in DOES convert the response from the ELM327 (in Ascii) to hex.
The data is the only thing passed out of the Plug-in.
All of the response definitions must have the following settings:
Body size =1
Payload size =1
Payload offset = 0

Even if this is a 16 bit response, the setting is the same.
The "value" definition will be the place to select if it is 8 bit or 16 bit value.

Got lots of items defined, and have data flowing at 16-18 Hz but that seems to be the total number of command responses you get so you must limit how many items you want to see.
Playing with different sets to get better dashboard display. Feels like your watching 160 baud on an old car though.
Still want to try and increase the speed of the ELM using AT commands but that might not be possible.
Jp
01-21-2013
EagleMark

:thumbsup:

Even with EFI Live Scantool the rule of thumb is no more then 24 PIDS at a time. So duplicating ADX commands for fuel, spark, O2. DTCs etc may be the way to go when you find a bunch. Then one for tuner data.

If you need some testing let me know.
01-21-2013
RobertISaar

i don't think it's the ELM so much as it is the incredibly large overhead the OBD2 PID request requires...

Mark, what kind of update rate do you see with 24 PIDs? does EFILive display an update rate?