OBDII PIDs from CAN ID 2026 (0x7EA)

[EricZ]

I've encountered issues accessing PIDs 8 and 9 on my 2008 Audi RS4 using my RaceCapture MK2 Track and the built in OBD channel setup. I have no issues with any PIDs that use CAN ID 2024.

On my Audi, I have confirmed the OBDII CAN messaging using Ross-Tech VCDS for the following channels:
PID 6: Long Term Fuel Trim Bank 1, Request uses Message ID 2015 and the response uses Message ID 2024 only
PID 7: Short Term Fuel Trim Bank 1, Request uses Message ID 2015 and the response uses Message ID 2024 only
PID 8: Long Term Fuel Trim Bank 2, Request uses Message ID 2015 and the response uses Message ID 2026 only
PID 9: Short Term Fuel Trim Bank 2, Request uses Message ID 2015 and the response uses Message ID 2026 only

RaceCapture will read PIDs 6 and 7 just fine along with any other PID that I have setup using Message ID 2024. As soon as I add a PID that uses Message ID 2026, RaceCapture does not work with these PIDs, but it also stops working with PIDs 6 and 7. It will continue to read other PIDs, such as 5 (Coolant temp), 12 (Engine speed), 16 (MAF), etc.

I have been able to direct CAN map all other data I need from the car, except MAF, STFT + LTFT for both banks as those are not available on the bus without requesting them either thru OBD PIDs or thru the proprietary Audi PID request method. I would much prefer to use the OBD PIDs for these parameters.

Any ideas on what to check or how to resolve?

[aUzer]

See the following post:
viewtopic.php?f=33&t=6288

Spoiler alert ... for non-extended PIDs, use mask 2031 to allow response from all possible controllers (I've suggested that this should be RC's default).

[EricZ]

Thanks for the response! I read thru your linked post and I follow the logic, but its strange that the OBDII channel setup does not work with a 2026 Message ID when 2026 is entered in the CAN ID field?!?!

I tried setting the CAN ID to 2024 and Mask to 2031. This still works fine for 2024 messages, but does not work correctly when any 2026 messages are on the bus. See my screenshots below:

Settings for OBD PIDs 6, 7, 8 and 9:



RaceCapture Screenshots below are CAN traffic filtered for Message IDs 2015, 2024 and 2026.

Enabled OBDII PIDs 6 and 7 with 2024 CAN IDs using the built in OBDII functions (GOOD):



Corresponding OBD PID 6 & 7 request & receive from my VCDS tool (GOOD):



Enabled OBDII PIDs 8 and 9 with 2026 CAN IDs using the built in OBDII functions (BAD):



Corresponding OBD PID 8 & 9 request and receive from my VCDS tool (GOOD):



Even though the PID 8 response is shown in the serial monitor, the RaceCapture Gauges do not display anything other than 0. The PID 9 response is never shown. Also, the unit seems to be unnecessarily flipping back and forth between standard format and extended format.

[EricZ]

Any ideas Brent? I'd really like to get this one checked off the list. I have not figured this out yet

[Canyonfive]

can you use the race capture to log what is sent from your VCDS tool to the ecu and received from the ecu?

[EricZ]

To close this issue, Brent confirmed the 2.17.8 Firmware code will only read OBD PID responses with ID 2024. He has provided a beta firmware version that fixes this issue.

[aUzer]

I repeat:

The standard OBD PID setup (for non-extended PIDs), should default to mask 2031 to allow capturing the responses from all possible controllers. With some cars (e.g., Mercedes/AMG) it's quite common for multiple controllers to respond to various PID queries.

There's likely also the same thing that applies to extended PIDs, but (after multiple searches) I've never been able to find any information on the valid range of controller IDs that can respond to a PID query (assuming it's essentially the same as non-extended PIDs, but with a greater quantity allowed).

[EricZ]

Even using the 2031 mask, the built in OBDII channels are hard coded to only accept 2024 responses, regardless of what mask is assigned. See the thread on the RC Discord thread where we discuss this and Brent provides an updated firmware to address the issue. https://discord.com/channels/7507352822 ... 1482226718

[aUzer]

Even using the 2031 mask, the built in OBDII channels are hard coded to only accept 2024 responses, ...

Yes, monitored that. I was just repeating my suggestion with hope that it gets implemented in the new version. It's the correct way to do things.

I'd also _really_ like to understand if/what the equivalent is for extended queries (but I'm too cheap/lazy/busy to buy the standards document[s] and do all the reading).

[EricZ]

I'm curious about your 2031 mask idea. When you request an OBD PID, you are expecting a response with a single message id i.e. 2024 or 2026, etc. but not more than one i.e. 2024 and 2026. If the RC OBD channel accepts responses from multiple message ids, how will the channel know how to process the data in the response?

For example, lets say Mass Air Flow is returned using both message ids 2024 and 2026. If the data will be repeated the same on both responses then there is no value to monitor more than one response. If the data is different between the 2024 and 2026 responses, how is the RC supposed to know how to create one output from two inputs?

Long story short, I don't see the value in having an OBD PID channel accept responses from more than one message ID per channel.

[aUzer]

My experience with this is limited to my AMG C63 S. Various queries generate responses from more than one controller. The difference is timing. Since there can only be one CAN message on the bus at a time, different responders send different values (i.e., the value that was valid at the time they were responding).

In my observations, the following seems true (where there are multiple modules that respond to a given query):

- for certain queries, one module seems to be more likely to respond (seemingly, it is "preferred" or "has priority" in the duty to respond)

- for certain queries, it appears that only one module -- but not the same module, every time -- will respond to a single query

- for certain queries, the response time varies significantly between modules that can/do respond

- (I suspect that) in some instances (e.g., wheel speed) different modules are responding with different data sets (e.g., the speed of the wheel monitored by that controller) ... in such cases, it may be better to limit the data to one module (e.g., the "most often inside front wheel" ... assuming your car doesn't have front-wheel lift in corners) -- or use smoothing to ensure that data is not too spikey due to wheel-spin, etc.

After looking at the response timing, for some queries I use the data from only one responding module because its response time is fastest and the other(s) are dismal. I suspect the dismal responses are coming via a gateway module, but have yet to confirm that. In other cases, I want all the responses from all responders as that gives the best data rate or it's one where the controllers seem to respond in some arbitrated manner where only one of the modules will respond to each query.

It seems that the only price to be paid for accepting responses from all modules is perhaps a bit of extra processing, but the benefit is a more guaranteed data rate.

If I was writing the code, I'd want to:

- default the mask to accept responses from all applicable modules

- accept responses from all modules allowed by the mask

- as an optimization, ignore additional responses after a query's response has already been received for the current "time slice" (where "time slice" is 1/query frequency) ... and that's assuming that the overhead of keeping track of responses isn't greater than the work of simply processing extra responses