RC OBDII: Difference between revisions
Line 66: | Line 66: | ||
[[image:OBDII_customize_channel_mode_22.jpg|800px]] | [[image:OBDII_customize_channel_mode_22.jpg|800px]] | ||
====29 bit Mode==== | |||
Some OEMs, like Honda, implement OBDII using an extended CAN address, known as 29 bit mode. | |||
If you are not getting OBDII data from your Honda or other car, try enabling 29 bit mode for each channel. | |||
===Setting the CAN mapping=== | ===Setting the CAN mapping=== |
Revision as of 17:53, 27 February 2020
Getting started with OBDII
You can easily set up OBDII channels by navigating to Setup / OBDII and selecting the OBDII preset. Make sure you have OBDII turned 'ON', as well.
Once you've selected the Preset, you'll see a few essential channel listed. Press Write to write the settings to your RaceCapture system.
After writing the changes, you can navigate to the dashboard to view the real-time values while your engine is running.
Creating additional OBDII channels
You can create additional channels by pressing the (+) button in the OBDII setup screen. An editor will pop up, and you will be able to select a standard channel from the list.
Once this channel is selected, you can press the check to add the new channel, then press 'Write' to write the updated settings to your RaceCapture system.
Converting between units
If you want to convert channel units, such as converting Celsius to Fahrenheit, you can enable that by swiping to the right most tab of the OBDII channel editor:
Note about Standard Channels
The list of default channels are part of the SAE standard channels provided by the OBDII specification. Learn more about the SAE standard channels
Not all cars support all channels
Cars will typically implement a subset of the SAE standard channels. If you see no data for a particular channel, the car's ECU does not support it.
Channels you can rely on
Channels that are virtually guaranteed to work are:
- TPS (Throttle Position)
- RPM (Engine speed)
- EngineTemp (Engine temperature)
- MAP (Manifold pressure; also indicates turbo boost pressure if value is greater than 100Kpa)
- IAT (Inlet Air temperature)
Extended OBDII channels
Many manufacturers implement custom extended OBDII channels, commonly known as "Mode 22" OBDII.
Creating an extended channel
Start by pressing the (+) to create an OBDII channel. Then, press the gear button next to the channel to edit the settings.
In this case, we will set up an OilPressure channel.
Select a sample rate for this channel.
- Note: Select a low sample rate (1Hz) for sensors that change slowly, like EngineTemp and FuelLevel. Select a higher sample rate (10-50Hz) for sensors that change faster, like RPM and Speed.
Customizing the Mode and PID
If you are getting the extended mode 22 information from an app like Torque, you will receive this information with a series of hexadecimal numbers.
- Example 22115C (Oil Temperature for GM)
The 22 represents Mode 22, and the PID is 115C. Select the Mode 22 from the drop down, and specify the PID by entering it in the PID section.
- Note: You will need to convert the hexadecimal number to decimal for the PID field. How to convert
In this case, 0x115C = 4444 decimal.
29 bit Mode
Some OEMs, like Honda, implement OBDII using an extended CAN address, known as 29 bit mode.
If you are not getting OBDII data from your Honda or other car, try enabling 29 bit mode for each channel.
Setting the CAN mapping
Under the CAN ID match tab, specify 2024 for the CAN ID to match on. This is the CAN ID for the OBDII response Leave the other settings as default.
Setting the Raw Value mapping
Under the Raw Value Mapping tab, specify the following values:
- Offset: 4
- Length: 1 - 4 (see guide below)
- Endian: Big
- Bit Mode: Unchecked
- Source Type: Unsigned
- Note: The length will vary based on the size of the value returned by the ECU. The clue is in the conversion equation supplied with the PID information (e.g. Torque app).
Use the following as a guide:
- If only A is specified in the equation, use 1 for length.
- If A and B are specified in the equation, use 2 for length
- If A, B and C are specified in the equation, use 3 for length
- If A, B, C and D are specified in the equation, use 4 for length
Example used: (A * 0.65) - 17.5 - length is 1
Setting the conversion formula
The ECU will respond with an encoded value, which may not represent the meaningful real-world value. Therefore, a conversion formula will need to be applied.
Under the Formula tab, specify the multiplier, adder, and divider that will be applied to convert the raw value to the real-world value.
The information that came with the PID will typically include a conversion equation. In this example for GM Oil Pressure, the equation is (A * 0.65) - 17.5
The A in the equation represents the raw value read from the ECU. Therefore, you would specify 0.65 for the multiplier, and -17.5 for the adder. Leave the divider as 1.
(Optional) Selecting a units conversion
You can optionally convert the value to your preferred units. Select the units conversion in the Units Conversion tab.
Finishing and Verifying
Press the Check button on the editor popup and then Write the settings back to your RaceCapture system.
Then, switch to the dashboard mode to verify you are receiving data for that channel.
OBDII Performance
You will notice that OBDII performance may drop as you add more channels. OBDII was never meant to be a high performance data-logging interface, but rather intended for periodic use with a scan tool.
What makes it slow? The request / reply protocol OBDII prescribes. The behavior is universal, and every OBDII-compliant ECU operates in this manner:
- Data system to ECU: “hey, send me RPM”
- ECU to data system: “ok, here’s the RPM value”
- Data system to ECU: “hey, send me throttle position”
- ECU to data system: “ok, here’s the throttle position value”
- Data system to ECU: “hey, send me engine temperature”
- ECU to data system: “ok, here’s the engine temperature value”
…and so on. So, while OBDII requests channels one at a time, direct CAN bus streaming can data (typically available on modern and aftermarket ECUs) acts like a one-way firehose of broadcasted data. RaceCapture supports this mode as well, see our CAN bus integration guide
Given those limitations, we have a few things that make our OBDII interface as fast as possible:
We use a powerful 32 bit ARM processor in RaceCapture that interacts with your car’s ECU directly, minimizing the lag between querying for an OBDII channel and processing the reply. Indeed – our code is running right down at the metal, and is much higher performance compared to your typical OBDII dongle.
RaceCapture also uses a priority scheduler that optimizes all of your OBDII channels. Here’s how it works:
Prioritizing OBDII queries
Let’s say there’s 3 channels you want from OBDII: RPM, TPS and EngineTemp. Since RPM and TPS are fast-changing channels, you set their rate to 25Hz. EngineTemp changes much more slowly, so you set that to 1Hz.
RaceCapture will now automatically schedule OBDII channels based on their configured rate – optimizing the OBDII schedule so the higher rate channels are queried more often than slower channels. In the above example:
- RPM and TPS are queried at the same rate (round-robin querying)
- EngineTemp is queried at 1/25 the rate as RPM and TPS.
This way we maximize the update rate we can get for RPM and TPS at 25Hz, minimizing the lag on the RaceCapture dashboard as well as in your data stream.