My ’14 BMW with a N63TU engine has dual engine computers, one for each side of the V8. I was hoping to get data (IAT, boost, etc.) for each side using some custom defined PIDs (addressed to each ECU), but it appears the ECUs are not responding properly to the requests. Here’s some output from a torquescan telnet session:

>010F
7E803410F4C
7EA03410F4D
>AT SH 7E0
OK
>010F
NO DATA
>AT SH 7E2
OK
>010F
NO DATA
>0105
7E80341055F
7EA0341055F
7E90341055F
>AT SH 7E0
OK
>0105
NO DATA
>AT SH 7E2
OK
>0105
NO DATA
>AT SH 7E1
OK
>0105
7E90341055F

The two engine ECUs are 7E8 and 7EA. I’m guessing the tranny ECU is 7E9 and appears to respond properly to requests addressed specifically to it, but the two engine ECUs only respond to broadcast/functional requests (7DF). It appears the car is not adhering to OBD standards, but not much can be done about that at this point.

To workaround this issue, I’ve tried several things, none of which I’ve found to work 100% yet:

• Set the OBD header (7E0 or 7E2) – results in no data
• Use a later letter in the PID equation hoping Torque would sort the responses and I could access the second response data – I tried from B to M letters, but no luck
• Use a filtering command in “Diagnostic start command”, e.g. AT CRA 7E8 – works most of the time but once in a while the data is from the wrong ECU
• Create a plugin to query the OBD adapter to get the data and provide it via setPIDInformation for use in other Torque displays/logging – it looks like setPIDInformation does not yet work to set PID data in Torque (based on testing and a 3/12/2013 comment by Ian)

Any thoughts on how this could be resolved?

Thanks for the suggestion. I want to display and log data from both banks (both engine ECUs) at the same time – it looks like this would limit all data to just one of the ECUs. I’ve tried using ATCRA7Ex in the “Diagnostic start command” for custom PIDs, but it is not 100% reliable (I tried it with two different adapters).

I had already tried custom PIDs with 7E0 and 7E2 as the OBD Headers, but they return “No data”, same as from the commands from a telnet session. Or did you mean something different?

I’ve already tried AT SH 7DF followed by AT SH 7E0 and a PID in a telnet session and got “No Data”:

>AT SH 7DF
OK
>01 05
7E80341055F
7EA0341055F
7E90341055F
>AT SH 7E0
OK
>0105
NO DATA
>AT SH 7E1
OK
>0105
7E90341055F

I can try it in the initialization to see if that makes any difference (I’ll try it this weekend – I’m out of town right now).

Most excellent – I was hoping you had some hidden capability like this. I’ll try it Saturday.

Ian, I don’t see any additional PIDs on the torque scan and I tried using “get-attable” various ways with no success. I’d appreciate if you could check if it is still in the code. If not, perhaps an implementation like this might work:
– Use the normal “OBD2 Mode and PID” (e.g. 010F) in a custom PID
– Use a special designator in the “OBD Header to use” where the desired ECU can be specified, e.g. “ECU:7E2” (or perhaps another field to specify the desired ECU, but that seems like a lot of extra work for this rare situation)
– Hopefully torque could optimize this to see it is not really a new PID, just an additional response so it does not have to make another OBD query

Hi!

They’re separate responses so Torque will take the first one for the equation parsing (the subsequent ones will be shelved and stored in the app which should have been visible in TorqueScan)

I’m a little busy this week to look at it (trying to get the theme updates out for all the dials), though I’ll set something up to mirror your setup next week and see if I can make the app store the data elsewhere (as I can’t overwrite existing PIDs). It should then be trivial to then add a custom PID for the other ECU

Ian, I signed up for beta testing and can test whatever you can hack together for this.

Any luck getting to this one Ian?

These are standard OBD-II PIDs (https://en.m.wikipedia.org/wiki/OBD-II_PIDs), and I’ve tried others. 010F (mode 1, PID 0F) is intake air temperature and the returned data I see is as expected. This is when I use direct test commands to the 7DF broadcast address. The returned results are from two addresses, 7E0 (7E8 in the response) and 7E2 (7EA in the response). Those are presumably the two ECUs (the data looks reasonable).