Toyota GR86, 86, FR-S and Subaru BRZ Forum & Owners Community - FT86CLUB - View Single Post - OFFICIAL Torque Android app PID/Misc Thread

arghx7 · 12-04-2012, 04:18 PM

I think there's some confusion going on here.

You're getting different types of information mixed up. For our purposes, I'll break them up into 4 categories.

1) Universal OBD II diagnostic PIDs. This is set by the standard j1979 , with the latest relevant revision (digital annex section) being released in October 2011. That's what these universal tools read. They're standardized PIDs (PID = Parameter ID). The basic stuff is going to be readable on every OBD II vehicle, like coolant temperature. The more recently added (and application specific) stuff like PID 71, Commanded Variable Geometry Turbo A Position, is basically up to the manufacturer.

2) Manufacturer-specific diagnostic PIDs. This is information that a dealership technician can read using service communication protocols. It's like Techstream and such. I am not sure a universal tool can be easily configured to read these. This same protocol can be used for active testing of various actuators and modules on the vehicle, like the low pressure fuel pump.

3) Proprietary CAN messages. This definitely has to be reverse-engineered. Basically, a ton of information passes along the CAN network. You can listen to it all you want if you have the right tools. Probably the most common commercial tool is Vector CANalyzer, which is expensive software requiring expensive interface hardware. Even if you have this hardware, all you will see is a bunch of hexadecimal nonsense.

You need to have the CAN database file to get descriptions and actual units. for the messages being passed around. The CAN database is under lock-and-key. This information is accessed on a need-to-know basis. Only certain development engineers and technicians will have it. A supplier might get an abridged version that applies only to their specific projects.

That being said, if you know what you're looking at you can start to figure out what the messages mean. For example, you could guess what the headlight switch status message is by flipping the headlights on and recording the messages that go across the bus. Obviously this is a tedious process, and getting more complex stuff like steering angle, yaw rate, transmission temperature, etc is not going to be easy.

4) ECU RAM addresses. This is physically reading calculated values inside the ECU. Something like ECUtek is going to be able to do this, because somebody reverse-engineered how to get access. Then they reverse-engineered the RAM addresses for specific signals and hopefully figured out what they mean.

Realistically, you are probably only going to get #1 from this list using a cheap Android app. The PID list is in j1979 and is thus not confidential information. Then you have to figure out what the vehicle is reporting and see how fast it is reporting the information. Typically OBD requests are low priority on the CAN network, so you might not get a great sample rate.

12-04-2012, 04:18 PM	#15
arghx7 Senior Member Join Date: Nov 2011 Drives: car Location: cold Posts: 599 Thanks: 72 Thanked 614 Times in 185 Posts Mentioned: 33 Post(s)	I think there's some confusion going on here. You're getting different types of information mixed up. For our purposes, I'll break them up into 4 categories. 1) Universal OBD II diagnostic PIDs. This is set by the standard j1979 , with the latest relevant revision (digital annex section) being released in October 2011. That's what these universal tools read. They're standardized PIDs (PID = Parameter ID). The basic stuff is going to be readable on every OBD II vehicle, like coolant temperature. The more recently added (and application specific) stuff like PID 71, Commanded Variable Geometry Turbo A Position, is basically up to the manufacturer. 2) Manufacturer-specific diagnostic PIDs. This is information that a dealership technician can read using service communication protocols. It's like Techstream and such. I am not sure a universal tool can be easily configured to read these. This same protocol can be used for active testing of various actuators and modules on the vehicle, like the low pressure fuel pump. 3) Proprietary CAN messages. This definitely has to be reverse-engineered. Basically, a ton of information passes along the CAN network. You can listen to it all you want if you have the right tools. Probably the most common commercial tool is Vector CANalyzer, which is expensive software requiring expensive interface hardware. Even if you have this hardware, all you will see is a bunch of hexadecimal nonsense. You need to have the CAN database file to get descriptions and actual units. for the messages being passed around. The CAN database is under lock-and-key. This information is accessed on a need-to-know basis. Only certain development engineers and technicians will have it. A supplier might get an abridged version that applies only to their specific projects. That being said, if you know what you're looking at you can start to figure out what the messages mean. For example, you could guess what the headlight switch status message is by flipping the headlights on and recording the messages that go across the bus. Obviously this is a tedious process, and getting more complex stuff like steering angle, yaw rate, transmission temperature, etc is not going to be easy. 4) ECU RAM addresses. This is physically reading calculated values inside the ECU. Something like ECUtek is going to be able to do this, because somebody reverse-engineered how to get access. Then they reverse-engineered the RAM addresses for specific signals and hopefully figured out what they mean. Realistically, you are probably only going to get #1 from this list using a cheap Android app. The PID list is in j1979 and is thus not confidential information. Then you have to figure out what the vehicle is reporting and see how fast it is reporting the information. Typically OBD requests are low priority on the CAN network, so you might not get a great sample rate.