Hello! I created an ELM327 emulator that communicates with Torque using Protocol 6. After reading up the ELM327 datasheet, I was able to implement Single Frame & Multi-Frame Responses and everything is working well.

Now, I just finished the code to handle Multi-PID Requests that dynamically returns Single Frame or Multi-Frame Responses depending on the # of PID Request. However, Torque doesn’t seem to want to request Multi-PIDs. I wonder if any of you guys had the same experience, and would like to know how you solve this.

Is there a special response during initialization phase that will allow Torque to query with Multi-PIDs?

Thanks in advance!

First of all, thanks for taking time to reply. Regarding the link you’ve posted, I’ve already implemented Multi-Frame Responses both with Headers On and Off. So we’re good with that. Here is the log of my program with Torque set to Automatic (Thorough Protocol Scan) Protocol:

Request = ATPC | Echo = ATPC | Response = OK

Request = ATPC | Echo = ATPC | Response = OK

Request = ATZ | Echo = ATZ | Response = CUSTOM_PROGRAM

Request = ATE0 | Response = OK

Request = ATM0 | Response = OK

Request = ATL0 | Response = OK
Request = ATST62 | Response = OK
Request = ATS0 | Response = OK
Request = AT@1 | Response = ELM327_EMULATOR
Request = ATI | Response = CUSTOM_PROGRAM
Request = ATH0 | Response = OK
Request = ATAT2 | Response = OK
Request = ATDPN | Response = 6
Request = 0100 | Response = 4100BE7F8013
Request = ATH1 | Response = OK
Request = ATDPN | Response = 6
Request = 0100 | Response = 7E8064100BE7F801300
Request = ATH0 | Response = OK
Request = 0100 | Response = 4100BE7F8013
Request = 0120 | Response = 412000022001
Request = 0140 | Response = 41406C018005
Request = 0160 | Response = 416060000000
Request = 010C | Response = 410C8D10
Request = 010C1 | Response = 410C1350
Request = 010C1 | Response = 410C420C
Request = 010B1 | Response = 410B3D
Request = 010C1 | Response = 410C9C0C
Request = 010D1 | Response = 410D52
Request = 01111 | Response = 4111D1
Request = 010B1 | Response = 410B5E
Request = 010C1 | Response = 410C5770
Request = 010D1 | Response = 410DEB
Request = 01111 | Response = 411168
Request = 01051 | Response = 410533

The ‘>’ prompt character has been removed in logs only but is transmitted to Torque
The problem is Torque only sends the following Requests:

010C1 where 01 is Mode, 0C is for RPM and 1 is for wait for 1 line only (Faster Communication)

while what I wanted is:

010C0B0D1105 where 01 is Mode, 0C is for RPM and other (0B, 0D, 11, 05) are for other sensors.

It is an ELM327 emulator software, and no ECU is involved. I’ve already coded the capability to receive & process multiple PIDs and respond appropriately. The problem is, Torque doesn’t request it.

Thanks for answering. I’m emulating Protocol 6 (ISO 15765-4 CAN (11 bit ID, 500 kbaud)). Please look for the response of “ATDPN” Request in my logs above. My emulator returns the correct responses (I think). Torque always sets the Header Off (AT H0), so the responses are very short. I guess this results to a faster turn around between transmit and receive for more performance.

From my understanding, Torque talks to the ELM327 through ELM327 commands (AT, 01, 09 etc.). The ELM327 device/emulator then does the heavy lifting of converting the request to OBD compatible commands depending on the Protocol after the handshake.

Torque App —–> ELM327 (BT Serial) —> ELM327 uController ———> ECU Protocol 3
01 0C —–> conversion (81 10 F1 01 0C 8F) ————–> Receipt

Torque App —–> ELM327 (BT Serial) —> ELM327 uController —>CAN Chip—-> ECU Protocol 6
01 0C —–> conversion (7DF 02 01 0C) —————————–> Receipt

Basically, it doesn’t matter what Protocol the ECU & ELM327 is using. All requests are standardized by the ELM327. The ELM327 device takes care of everything. The Torque App can query requests of “01 0C” and will get the same response format standardized by ELM327.

I believe you are right, maybe the Torque “01 00” request is expecting something else in order to enable Multi-PIDs, but I just can’t find any detail about this in the forums.

For the time being, I will look into that.

Hello! Thanks for replying.

Have you tried just making a custom PID with, for example 010C0D05?

I would have thought Torque would send that correctly, but you’d only be able to pick one item out of the response so it would be a bit pointless.

I have tried the Custom PID route, and you’re right! Unfortunately Torque will only reference to one “Override PID”. So, even if I put 0C (RPM), 0D (Speed), 05 (Coolant Temp) in one Custom PID Request, it is treated by Torque as one Sensor or Display only.

You would probably have to put the same request in 3 separate custom PIDs, with each one picking out a different part of the response. I’m not sure it would make it any faster though?

This would be counter-productive and actually increases unnecessary transmit & receive length. In this case, I’m better off just requesting the standard single PIDs.

010C0D05 would not actually be a valid OBDII request though as the standard doesn’t support multiple PIDs in one request.

010C0D05 is actually a Multi-PID Request. OBD2 CAN Bus can request up to 6 PIDs at the same Frame. ELM327 carried over this feature to their Command set and actually created their own format of response when Headers are off and CAN Auto Formatting is on. Here is an example from the Datasheet (pg 46):

>01 0B 04 0C 05
00A
0: 41 0B 21 04 3F 0C
1: 17 B8 05 44 00 00 00

The above response is not an OBD Standard Response. It is a special response intended for applications using the ELM327 Standard like Torque. Here is another used by Torque:

010C1

The 1 at the end is not OBD Standard and is created by the ELM327 to facilitate faster turn-around by not waiting for the time-out to happen. This is implemented by Torque using “Faster Communication” setting.

UDS Service 22 does though.
The equivalent request would be 22F40CF40DF405.

This looks promising, I will look into this. Thanks!

You will then get into issues of messages exceeding 8 bytes though, which I don’t think standard ELM327 devices can handle for transmission.
I know to get this working on an OBDLink LX I had to use a couple of ST commands which are additional to standard ELM327.

ELM327 Standard has the feature “ATAL” which allows unlimited receive Bytes. If it is not turned on, the ELM327 device is expected to return Multi-Frame Responses.