Tuner Pro V5 and OBDII plug-in?

[JP86SS]

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/AeroForce+Interceptor+Scan+Gauges+for+most+late+mo del+GM+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

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

[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!

[EagleMark]

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.

[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

[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?

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

[PJG1173]

I was looking into this a while back but lost interest but I did find this. http://www.delcohacking.net/forums/viewtopic.php?f=10&t=1320#p14773

[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

[JP86SS]

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

[JP86SS]

luckily, one ADX would cover almost all applications,
That is my plan

[RobertISaar]

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.

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



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 ]

[JP86SS]

Just got a reply from Magnus on this :)


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

[JP86SS]

from my post on Mark's site.

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

[RobertISaar]

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

why would they purposely make the OBD2 PID request protocall with more overhead than necessary?

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

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

[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

[1project2many]

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

These can also be used as scan data.

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

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

[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

[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?

[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

[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-Injection/showthread.php?981-LS1-ADX-for-tunercat-OBD2-cable

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

[JP86SS]

Here is a sample of my data:

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


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

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

[34blazer]

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

[EagleMark]

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

Hope they help.

[1project2many]

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.

[JP86SS]

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

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

[EagleMark]

Alos found this on Moates site.

[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

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

[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?