I'm in the process of writing a Java-based application to interface with a car. For hardware, I'm using one of the Wi-Fi ELM327 modules available from Amazon (this one, to be precise: http://www.amazon.com/gp/product/B00FQ7O88M/ref=oh_details_o00_s00_i00). To test that it's working, I picked up the DashCommand application for my iPhone.
To get a bit of a look into the protocol used to interface with the module, I recorded the network traffic of a session (via wireshark) where I went on a drive while the DashCommand app recorded it's usual metrics (the car used for testing was a 2009 Acura TSX).
Most of the traffic initially is what I would have expected from what I've read in the documentation of both the ELM 327 and OBD II. However, once I got going, DashCommand ended up using PIDs that I can't seem to figure out. An example of what I saw would be:
...
Request: 01 0B2
Response: 01 0B2
18 DA F1 11 03 41 0B 1B
18 DA F1 1D 03 41 0 B 1C
>
Request: 01 0C2
Response: 01 0C2
18 DA F1 1D 04 41 0C 0C A0
18 DA F1 11 04 4 1 0C 0C A0
>
Request: 01 0D2
Response: 01 0D2
18 DA F1 11 03 41 0D 00
18 DA F1 1D 03 41 0 D 00
>
Request: 01 101
Response: 01 0D2
01 101
18 DA F1 11 04 41 10 01 3E
>
Request: 01 332
Response: 01 332
18 DA F1 D1 03 41 33 62
18 DA F1 11 03 41 3 3 62
>
…
The full list of three digit PIDs I've found so far are: 031, 0B2, 0C2, 0D2, 101, 332, and 341. Each of these are sent with mode 01 as shown above.
Is there any documentation on these PIDs? Or am I misinterpreting what I'm seeing?
The last digit is not part of the PID.
The number after the PID represents the number of replies you're expecting. You can see that this is always a number.
For example, when you add a '1' to your normal 2-digit PID, the ELM327 will wait for exactly 1 response from an ECU. When 1 ECU has responded to the ECU, the ELM327 will directly respond that result to you. When you add a '2', it will wait for 2 repsonses.
Source: ELM327 Documentation - Go to page 32.