Software On ELM Street - OBD2 Software Development

[TazzI]

Awesome work!!!!
Perfect & not 1 buffer full message yet!

Now need to get a filter in place to catch different responses!

J1850VPW is just 41.6kB/s

HSCAN though at 500kB/sec is where you will see dramas without filters

Were not even requesting the 41.6kb/s, only using 1xVPW so its 1/4 of that lol.

But Grunts been logging on both CAN Hi and Low, havent actually tested on VPW properly yet. Also, this has only really been tried on the pcm on bench, still waiting to see how it goes in car, I imagine thats where we will begin seeing the Buffer full again.. assuming there are any other modules broadcasting.

Slowly working out the kinks and required header/messages ect.

[jezzab]

Yeah but dont forget your displaying the information in ASCII hex not as a true single byte, so you are sending alot more info to the PC This though is another reason the ELM pissed me off for flashing and working with converting everything all the time. With the LPC I can just work in pure hex inputs and outputs

[TazzI]

Yeah, for shits and giggles, if you run a test with converting between characters to bytes compared to just dealing with bytes in a loop of say 20,000. Theres a fairly big time difference.

A think a raw input/output module/cable/device is going to be a must if this was to be anymore then a logger/diagnostics app.

I also dislike the elm doing the filtering for me. Rather do it myself!

[gruntly69]

What's the LPC cable you talk of Jezza?
So have you got custom software to read/write PCM/ECM/TCM?
I generally use HPT but have been looking at other options to use the AVT cable I now have!
But there's not many that support the alloytec E55 & E77 ECM's!

[TazzI]

I swear the elm gets more frustrating as you progress.

Im a bit confused on the CAN formatting. And what the elm "apparently" inserts with the auto formatting turned on. Had to turn it off since GM's formatting causes "CAN ERROR" with it turned on.

Sending: 0105
will retrieve: 7E8 03 41 05 4A

So the header response being 7E8, so we would set our request header to 7E0.
Looks like the 03 is the length of the data. Eg (41,05,4A)
The 41 is the response to our mode 01 request. (All responses are 0x40 increase of the mode)
And the 05,4A is the actual data to be interpreted.

Now, with the auto formatting turned off, Im unsure whether I need to insert that "message length" byte or not. Might be a couple tests to find out.

Will chuck up a version later today here and on delco for testing.

[jezzab]

The 03 is the PCI byte, it tells the CAN interpreter how many bytes are to follow. The ELM can calculate it for you or you have to do it yourself if you have auto formatting off

Wait until you get multi line responses, that will do your head in :p This because when they get long you are using a nibble and a byte as the length. Short ones are ok coz you just use the byte section and the nibble is zero:

10 FF xx xx xx xx etc would be 255 bytes
But the 10 you actually are using the second nibble which is 0 so

1F FF xx xx xxx xxx etc is 4095 bytes which is our max frame limit you would have no doubt seen or heard about

The 7E0 and 7E8 are the sending and receiving addresses. When you are using 11bit CAN you always send on one address and receive on another. Say the ECU address was 644, this would be the address you listen to for responses and the sending address would be 244. 7Ex is very special because its the engine ECM so it has quite a few address's. Most other modules just have 2 (3 if there is a back diagnostics address for a failed flash etc..

Sending unformatted frames on the ELM327 required a "trick" to get it to work because of a bug from memory. I can't even remember what it was, I only had to do it when I ported some stuff to it from the ELM329. The 329 you just put a '.' before the frame

More of this stuff comes into play when you are reading DID's or trying to flash the ECU, not so much with diagnostics requests

Something like

AT CRA 7E8
AT SH 7E0
AT FC SH 7E0
AT FC SD 30 00 00
AT FC SM 1

This will setup the ECM and then send a flow control message when it sees multi line frames

then try and read the DID for the VIN with

02 1A 98

[TazzI]

Absolutely awesome stuff there Jez! Helps a tonne when someone knows the limitations of the tech2
Looks like Iv got a while to go in understanding multiline responses and flow control.

[TazzI]

Some new updates,

For the VPW protocol:
-Can read vin,OSID and pcm#
-Monitor all traffic or monitor a specific receive address
-Auto Renew monitor session on buffer full or "STOPPED" messages
-Custom send/receive implemented
-Engine data read re-implemented

And for CAN protocol:
-Implemented filter, filter is untested so unsure if it accepts current parameters
-Should be able to read VIN (again, if it accepts the parameters based off what Jez posted)
-Custom Send/Receive should also work.. needs to be tested


On a side note, the tech2 reversing moved forward for the VPW (LS1) protocol, the shitty old elm 322 that I picked up today works.. but is very slow due to it working over a serial->usb converter.. but its enough to fool the tech2!
So far, tech2 sends a message checking if pcm is present:
[15:30:52:187] Received: 6C 10 F1 20 64
[15:30:52:187] Received: 6C F1 10 60 72

Then sends off another frame which I have absolutely no idea about:
E9 3A F1 3C EC
I know the 3C mode reads a section of data eg 3C 01 which gave vin part 1 ect. Not sure whats sent on a blank table/did request? (Note EC is checksum)

But when the 6C F1 10 60 72 frame is sent back to the tech2, it briefly displays the "identifying" message, but disappears as I have no message to spam back on this request. But it means its working.. even with a crappy device, at least Ill have two elms when the other rolls up, one deticated to monitoring traffic and the other to fire off the frames.. wont have to juggle between swapping from monitoring to sending which takes a fair time to do.

Anyone that can test to see what response is sent back for the above frame would be great!
Setup is Header: E9 3A F1 and message to send is: 3C

[TazzI]

Finally..a parcel rolled up today.. fairly small.. and ITS THE ELM! FINALLY! 4th time is a charm...

Made a whole heap of progress in the reversing of the tech2 frame.

Can open up all menus and manipulate the messages to send back anything we want, will be posting up bits and pieces as I find them and decipher what they mean/how they are implemented.

The main screens to select from on the tech2 for an OBD2 PCM is:




And the main messages that are sent from the tech2 and a response sent back to get past the first screen are:
6C 10 F1 3C 08 F0 (PCM Part Number Request)
6C F1 10 7C 08 00 BA 49 7F XX (Part number:12208511)

6C 10 F1 3C 93 D4 (No idea.. Tech2 displays something about module S/W version.. JDU?)
6C F1 10 7C 93 41 44 XX

6C 10 F1 3C 0A CA (OSID Request)
6C F1 10 7C 0A 00 C0 28 CE

6C 10 F1 3C 0B D7 T(Engine Calibration)
6C F1 10 7C 0B 00 8E CD 55 XX

6C 10 F1 3C 0D 99 (Transmission Calibration)
6C F1 10 7C 0D 00 8E CB F4 XX


Have also had luck with the GM fault codes, although Iv found that there arent really any "holden specific" codes and most of these GM specific codes have already been found.
Its also a PITA to reverse each code with the tool as there doesnt seem to be any "logical" order in which to obtain the codes.The numbers seem fairly random, and trying each one by hand is ind numbing boring.

And from my testing, I think the tech2 refreshes the displayed faults, after losing connection to me "fake pcm" and then reconnecting.. so this may play into our advantage by hooking up a simple loop to run through every possible combination.. then using the webcam, take a pic of each screen of the tech2 each time. Least that way all I have to do is delete the screens with "unsupported DTC" on them the next morning. Hmm might look into it.
say 2 seconds per code (send code, wait a sec for tech2, them take image.. plus some slack).. would be roughly 5.55hrs to do every P1 combination. Might have to do some testing to make sure the tech2 behaves the way I think it does.


Also on a side note, I realised that the tech2 can pull the current software and calibrations of multiple modules in the car. This including the PCM, Telematics module and.... the cluster
Looks like for the PCM, it fires off a pcm unlock request (27 01). And will grab its vin and such as well. Might look into pulling that apart soon too.

[TazzI]

Thanks to Jayme over at PCMhacking.net, has really helped in breaking down how dynamic PID's work.

Fired up the tech2 and clicked on "Display data" and then "Engine data", and recived:

Code: Select all

[09:06:16:912]   Tech2 Sent: 6C 10 F1 20 64
[09:06:17:478]   Received: 6C 10 F1 22 11 72 01 B9
[09:06:17:691]   Received: 6C 10 F1 22 11 72 01 B9
[09:06:17:905]   Received: 6C 10 F1 22 11 72 01 B9
[09:06:18:120]   Received: 6C 10 F1 2C FE 4B 12 55 11 92 F3
[09:06:18:285]   Received: 6C 10 F1 2C FE 62 00 05 11 6F AB
[09:06:18:449]   Received: 6C 10 F1 2C FE 71 00 0F FF FF A6
[09:06:18:613]   Received: 6C 10 F1 2C FD 4B 00 0B 00 10 AE
[09:06:18:776]   Received: 6C 10 F1 2C FD 63 12 50 19 70 D4
[09:06:18:939]   Received: 6C 10 F1 2C FC 4A 11 9D 00 11 FA
[09:06:19:102]   Received: 6C 10 F1 2C FC 5A 11 43 00 0E D3
[09:06:19:265]   Received: 6C 10 F1 2C FC 6A 11 70 11 08 EE
[09:06:19:429]   Received: 6C 10 F1 2C FB 4C 12 5A 12 5B 29
[09:06:19:592]   Received: 6C 10 F1 2C FB 6A 11 A6 11 06 3A
[09:06:19:755]   Received: 6C 10 F1 2C FA 4C 13 2C 11 72 19
[09:06:19:918]   Received: 6C 10 F1 2C FA 6A 16 17 FF FF DC
[09:06:20:083]   Received: 6C 10 F1 2C F9 4A 11 44 11 12 5D
[09:06:20:246]   Received: 6C 10 F1 2C F9 5A 19 9A 11 5C 2B
[09:06:20:409]   Received: 6C 10 F1 2C F9 6A 00 0D 11 41 3E
[09:06:20:572]   Received: 6C 10 F1 2C F8 53 11 18 11 A1 D1
[09:06:20:735]   Received: 6C 10 F1 2C F8 6A FC 12 FF FF 89
[09:06:20:897]   Received: 6C 10 F1 2C F7 4A 11 05 11 00 C6
[09:06:21:061]   Received: 6C 10 F1 2C F7 5A 11 02 11 04 D6
[09:06:21:224]   Received: 6C 10 F1 2C F7 6A 11 03 11 14 BB
[09:06:21:386]   Received: 6C 10 F1 2A 14 FE FD FC FB 35
[09:06:21:399]   Received: 6C 10 F1 2A 24 FA F9 F8 F7 E3

And the corresponding options in the tech2 are:

Code: Select all

Engine Speed RPM
Desired Idle Speed RPM
Engine Coolant Temp Deg C
Start UP ECT Deg C
IAT Deg C
Manifold Absolute Pressure KPA
Manifold Absolute Pressure V
Mass Air Flow g/S
MAF Frequency Hz
Barometric Pressure kPa
Barometric Pressure V
Throttle Position %
Throttle Position Sensor V
Fuel System Status
Injector Pulse Bank 1 ms
Injector Pulse Bank 2 ms
Air Fuel Ratio   x:1
Spark Advance  CA
Ignition Coil Cyl 1
Ignition Coil Cyl 2
Ignition Coil Cyl 3
Ignition Coil Cyl 4
Ignition Coil Cyl 5
Ignition Coil Cyl 6
Ignition Coil Cyl 7
Ignition Coil Cyl 8
Knock Present
Knock Retard CA
Camshaft Activity
Purge PWM %
High Speed Fan
A/C Request
A/C Clutch
A/C Pressure kPa
A/C Pressure Sensor V
Reverse Inhibit Solenoid
Engine Oil Pressure kPa
Engine Oil Pressure Sensor V
Theft Status
Coolant Level Switch
Idle Air Control STEPS
Desired IAC Airflow g/s
Vehicle Speed km/h
Battery Voltage V
DTC Status
Time from start

So now, breaking down each message, we can find the PID's that are known and unknown:

Code: Select all

Starting from the top of the Dynamic requests..6C 10 F1 2C FE 4B 12 55 11 92 F3
2C - Is the mode.
FE - Table that the PIDs are being loaded into. Up to 8 can be configured
4B - 01001011, therefore: 01 is use PID, 001 is start at byte 1, 011 is get 3 bytes
1255 - PID 1255 Request..(unknown so far)
1192 - PID 1192, Desired Idle Speed.. One before might engine speed RPM?
F3 - Checksum
So this means, one parameter will have 1 byte, and the other will have 2. Id assume it would be the first parameter will have 2 and last will have 1.

Next Frame: 6C 10 F1 2C FE 62 00 05 11 6F AB
2C - Is the mode.
FE - DPID that the PIDs are being loaded into.
62 - 01100010, therefore: 01 is use PID, 100 is start at byte 4, 010 is get 2 bytes
0005 - PID0005 Engine coolant Temp (Deg)
116F - PID116F Start Up Engine Coolant Temp (Deg)

Next: 6C 10 F1 2C FE 71 00 0F FF FF A6
2C - Is the mode.
FE - DPID that the PIDs are being loaded into.
71 - 01110001, therefore: 01 is use PID, 110 is start at byte 6, 001 is get 1 byte
000F - PID000F Intake Air Temp (Deg)
FFFF - Padding


6C 10 F1 2C FD 4B 00 0B 00 10 AE
2C - Is the mode.
FD - DPID that the PIDs are being loaded into. (New DPID Used here)
4B - 01001011, therefore: 01 is use PID, 001 is start at byte 1, 011 is get 3 bytes
000B - PID000B Manifold Absolute Pressure (kPa) (Just Convert to Volts as well?)
0010 - PID0010 Mass Air Flow

6C 10 F1 2C FD 63 12 50 19 70 D4
FD - DPID that the PIDs are being loaded into.
63 - 01100011, therefore: 01 is use PID, 100 is start at byte 4, 011 is get 3 bytes
1250 - Not sure.. MAF Frequency Hz?
1970- TCC PWM Duty Cycle (According to fastfieros)

6C 10 F1 2C FC 4A 11 9D 00 11 FA
FC - DPID that the PIDs are being loaded into.
4A - 01001010, therefore: 01 is use PID, 001 is start at byte 1, 010 is get 2 bytes
119D - Barometric Pressure kPa
0011- Throttle Position %

6C 10 F1 2C FC 5A 11 43 00 0E D3
FC - DPID that the PIDs are being loaded into.
5A - 01011010, therefore: 01 is use PID, 011 is start at byte 3, 010 is get 2 bytes
1143 - Throttle Position Sensor
000E - Spark Advance CA

6C 10 F1 2C FC 6A 11 70 11 08 EE
FC - DPID that the PIDs are being loaded into.
6A - 01101010, therefore: 01 is use PID, 101 is start at byte 5, 010 is get 2 bytes
1170 - Controlled Canister Purge Solenoid (From Fastfiero).. Is this Purge PWM %?
1108 - Unknown... Fuel System status??

6C 10 F1 2C FB 4C 12 5A 12 5B 29
FB - DPID that the PIDs are being loaded into.
4C - 01001100, therefore: 01 is use PID, 001 is start at byte 1, 100 is get 4 bytes
125A - Injector Pulse Bank 1 ms
125B - Injector Pulse Bank 2 ms

6C 10 F1 2C FB 6A 11 A6 11 06 3A
FB - DPID that the PIDs are being loaded into.
6A - 01101010, therefore: 01 is use PID, 101 is start at byte 5, 010 is get 2 bytes
11A6- Knock Retard CA
1106 - Unknown

6C 10 F1 2C FA 4C 13 2C 11 72 19
FA - DPID that the PIDs are being loaded into.
4C - 01001100, therefore: 01 is use PID, 001 is start at byte 1, 100 is get 4 bytes
132C- Unknown
1172 - Idle Air Control STEPS

6C 10 F1 2C FA 6A 16 17 FF FF DC
FA - DPID that the PIDs are being loaded into.
6A - 01101010, therefore: 01 is use PID, 101 is start at byte 5, 010 is get 2 bytes
1617 - Unknown
FFFF - Padding

6C 10 F1 2C F9 4A 11 44 11 12 5D
F9 - DPID that the PIDs are being loaded into.
4A - 01001010, therefore: 01 is use PID, 001 is start at byte 1, 010 is get 2 bytes
1144 - A/C Pressure kPa
1112 - Unknown

6C 10 F1 2C F9 5A 19 9A 11 5C 2B
F9 - DPID that the PIDs are being loaded into.
5A - 01011010, therefore: 01 is use PID, 011 is start at byte 3, 010 is get 2 bytes
199A - Unknown
115C - Unknown

6C 10 F1 2C F9 6A 00 0D 11 41 3E
F9 - DPID that the PIDs are being loaded into.
6A - 01101010, therefore: 01 is use PID, 101 is start at byte 5, 010 is get 2 bytes
000D - Vehicle Speed km/h
1141 - Battery Voltage V

6C 10 F1 2C F8 53 11 18 11 A1 D1
F8 - DPID that the PIDs are being loaded into.
53 - 01 010 011, therefore: 01 is use PID, 010 is start at byte 2 (wheres byte 1?), 011 is get 3 bytes
1118 - Unknown
11A1 - Engine Run Time

6C 10 F1 2C F8 6A FC 12 FF FF 89
F8 - DPID that the PIDs are being loaded into.
6A - 01101010, therefore: 01 is use PID, 101 is start at byte 5, 010 is get 2 bytes
FC12 - Unknown
FFFF - Padding

6C 10 F1 2C F7 4A 11 05 11 00 C6
F7 - DPID that the PIDs are being loaded into.
4A - 01001010, therefore: 01 is use PID, 001 is start at byte 1, 010 is get 2 bytes
1105 - Unknown
1100 - Unknown


6C 10 F1 2C F7 5A 11 02 11 04 D6
F7 - DPID that the PIDs are being loaded into.
5A - 01011010, therefore: 01 is use PID, 011 is start at byte 3, 010 is get 2 bytes
1102 - Unknown
1104 - Unknown

6C 10 F1 2C F7 6A 11 03 11 14 BB
F7 - DPID that the PIDs are being loaded into.
6A - 01101010, therefore: 01 is use PID, 101 is start at byte 5, 010 is get 2 bytes
1103 - Unknown
1114 - Unknown

So this leaves us with an unknown PID list of:
1103, 1114, 1102, 1104, 1105, 1100, FC12, 1118, 199A , 115C , 1112 , 1617, 132C, 1106 , 1250, 1255

Should now hopefully be able to send off each table 1 by 1 and see watch changes on the tech2. Should be able to easily manipulate the frames and test what all of these unknown PID's are.