Posted on

Getting Started with CAN Bus Sniffing / What Can I See via the OBD Port?

(this is based on vehicles which use CAN; older vehicles may not have CAN busses easily accessible or at all)

First, you’ll need a CAN sniffing device and software to go with it. While the information in this post is generally not device or software specific, we will of course plug our own DauntlessOBD dongle for typical OBD port connections, or our CAN 2.0B to USB Interface Board when directly connecting to CAN wires, both of which work with the popular open source SavvyCAN software.

How do I Know if I Want to Connect via the OBD Port or Directly to CAN wires? The answer depends on what you want to do or see, and if your car has an OBD gateway module…


A gateway is commonly utilized by vehicle manufacturers to manage multiple CAN busses and relay certain traffic between them. This is done for load management, overall reliability / fault protection, and also security to some extent. It’s typical to find an OBD gateway in use on most late-2010s and newer vehicles, and certain manufacturers had them starting well before that (eg most VW/Audi/Porsche and some FCA).

Many other mid-2000s through mid-2010s vehicles had commonly exposed CAN traffic directly on the standard CAN pins of the OBD port. This would typically be the Powertrain CAN, which would also serve OBD requests, making it an easy and attractive place to access CAN traffic via an OBD dongle based CAN sniffer. It can also lead to some more problems if a poor quality, or nefarious, OBD device is plugged in.

Gateway Cons: When a vehicle uses an OBD gateway, you will see little to no CAN traffic via the OBD port, unless another OBD device is talking. This means you cannot use the OBD port to sniff, decode, or inject raw CAN broadcast messages between modules. Gateways are also commonly known to restrict access to certain modules or services, such as Service 27 for Security Access, unless you unlock the gateway and send it a proprietary command to allow your desired access. Sometimes this is for good reason, and other times it adds additional hurdles just to do a simple task.

Gateway Pros: Being that most other CAN traffic is filtered out, that makes it super easy to see what any other OBD devices are sending / receiving via the standard CAN pins of the OBD port. We’ve also found that in many cases, a gateway is actually helpful in gaining data stream and diagnostic access to modules that may exist on various different CANs, with the caveats that you may need to know manufacturer-specific info/methods to do this, and the gateway may also impose some restrictions on your ability to access more sensitive modules or functions.

Choosing the right connection for what you want to do

1) I Want to See What Another OBD Device is Doing: Connecting at the OBD port is an easy choice when combined with a Y-cable or other OBD splitter.

2) I Want to See Module-to-Module and Broadcast CAN Traffic: If your vehicle does not have an OBD gateway, and you want to see Powertrain CAN traffic, then the OBD port could be an easy choice. When a gateway is involved, or you want to see a non-Powetrain CAN, then you’ll likely need to connect directly to the wires of the specific CAN you want.

3) I Want to Communicate With a Module: In most cases you can do this via the OBD port… Certainly the OBD-compliant Powertrain modules can be accessed that way, but also in many cases other modules can be accessed there either directly (ie if your Powertrain CAN is connected to the port) or even via a gateway. When dealing with a gateway, many are cooperative in helping you talk to modules that may exist on various different CAN busses, but you’ll need to know how to do that for your specific vehicle/manufacturer and it may block or impose additional requirements on certain requests (such as Service 27 for Security Access).

Can I Sniff CAN With an “ELM327”? Maybe, but not well, and even less so on the low-quality clones that flood the market. We’ve seen that some of these clones do support the ELM327 CAN filtering and monitoring commands, while others don’t because they’re not often used by OBD apps. Typically, you’d set your filters and use “AT MA” or similar, restarting it whenever the buffer overflowed, which can be very frequent (and indicates that you’ve missed frames). Although our own DauntlessOBD dongle and CAN sniffer both offer compatibility with ELM327 commands, while offering a larger buffer and some additional capabilities, we typically recommend utilizing our compatibility with SavvyCAN for full CAN sniffing via USB, as that setup is more suited for the task.

Where Can I Find Other CAN Wires to Tap Into? Sometimes there will be additional CAN busses exposed on the optional pins of the OBD port (such as pins 3/11 for Ford). Otherwise, the wires going into a gateway module tend to have most everything available in one place. If that’s not easy to get to, then we’d usually look for the most accessible module on whatever CAN we’re targeting. Sometimes twisted-pair wiring can be a clue that it’s CAN, but not all manufacturers use this. Obtain a reliable wiring diagram for your vehicle to be sure about what you’re tapping into.

Use great care when connecting to CAN wiring, as improper connections or settings may cause damage and faults.

We strongly also recommend using Listen-Only / Receive-Only mode whenever possible, so that you won’t crash the CAN bus if you connect at the wrong rate, etc.

How Do I Get SavvyCAN Up and Running? Once you have a compatible device, check out our SavvyCAN Quick Start post.

What does CAN and OBD Traffic Look Like? For classic CAN (ie CAN 2.0B and older), it will be a frame ID and then up to 8 bytes of data. It is common for frames to be padded to a full 8 bytes even if not all of them are actually used. Typically padding values are 0x00, 0x55, 0xAA, less commonly 0xFF. And sometimes the excess bytes are just “random” or whatever was left over in the transmitting module’s buffer from a previous operation.

1) For scantool and server/client type communications, such as OBD or UDS (ISO-14229) or ISO-14230 requests and responses, it should be encoded using ISO-15765. This means the first byte will be the PCI byte, which will indicate the frame type and following data length. These may serve large payloads (up to 4KB) that span multiple frames. Read up on ISO-15765 for more information, as we’ll only touch on the basics here.

For example, a typical OBD request for engine RPM will be sent to an address like 0x7DF or 0x7E0 (if CAN-11) and have these bytes:

02 01 0C 00 00 00 00 00

The PCI byte is 0x02, which indicates that it is a single frame message (0x0 high nybble) and 2 bytes follow (0x2 low nybble), then you have the Service ID (0x01 – PID request), the desired PID (0x0C – Engine RPM), and the rest are 0x00 padding bytes.

The response to that example would come from an ID like 0x7E8 (typical CAN-11 ECM response ID) and have bytes that look something like:

04 41 0C 12 34 00 00 00

The PCI byte is 0x04, which is a single frame message with 4 bytes that follow. 0x41 is your Service Response ID (0x01 from the request, XOR’ed by 0x40), 0x0C is the PID you’re getting data for (Engine RPM), and then the value is 0x1234 which is 1165 RPM (scaling on this PID is 0.25 RPM).

When the high-nybble of that first PCI byte is 0x1, then you have the first frame of a multi-frame payload and the other side is expected to send a flow-control frame (0x3 for the high nybble), then you’ll see a series of frames with 0x2 for the PCI high nybble, which are the remaining multi-frame payloads. ISO-15765 explains how each of these work.

Service IDs of 0x0A and below will typically be OBD requests, and anything higher will be an ISO-14229, ISO-14230, or manufacturer-specific service. Despite having a higher ISO number, ISO-14230 is generally only used in older vehicles, falling out of favor for UDS / ISO-14229 which is increasingly commonplace.

2) For CAN broadcasts and some module-to-module communications, you’ll typically have raw CAN frames that use the manufacturer’s own encoding, rather than any ISO-15765 or other common standard. As such, we really can’t offer a one-size-fits-all explanation here like we can for OBD or UDS services.

You’ll have to know (or learn) how to decode these CAN broadcasts for your specific vehicle, and in many cases there will be some commonality shared across vehicle models of the same manufacturer and era. Typically, you would find parameters encoded in this CAN data by manipulating one of the vehicle’s controls or sensors, and trying to observe that change in the CAN data. You might also notice that some bytes/bits are always changing on every frame… It is fairly common for these frames to contain counters and checksums, as these add another layer of data integrity, and is another hurdle for any message injection or replay attempts.

If you have a GM Global A vehicle (mid-2000’s through late 2010’s), it can be very useful to purchase access to GMW8762 from a legitimate source, which provides a detailed explanation of most CAN signals found on the High-Speed CANs of these vehicles. Note that the Low-Speed / Single-Wire CAN (aka GMLAN) is different, and some insights into that may be found in the open source “GMLAN Bible”.

What does each OBD or UDS Service ID do? This only applies to request/response messages, and not CAN broadcasts. You want to look at SAE J1979, ISO-14229, or maybe ISO-14230, for a complete list and details, depending on what you’re working with. There may also be additional manufacturer-specific services being used by certain scantools. Here is a brief summary that is not all-inclusive:

Service	ISO-15031-5 / SAE J1979 (OBD)
01	Request Diagnostic Data
02	Request Freeze Frame Data
03	Request Trouble Codes
04	Clear Diagnostic Information
05	Request O2 Monitor Results
06	Request Monitor Test Results
07	Request Pending Trouble Codes
08	Request Control
09	Request Vehicle Information
0A	Request Permanent Trouble Codes
Service	ISO-14230-3 (KWP2000)
10	StartDiagnosticSession
11	ECUReset
14	ClearDiagnosticInfo
17	ReadStatusOfDTC
18	ReadDTCByStatus
1A	ReadECUIdentification
21	ReadDataByLocalIdentifier
22	ReadDataByIdentifier
23	ReadMemoryByAddress
27	SecurityAccess
28	DisableNormalMsgTransmission
29	EnableNormalMsgTransmission
2C	DynamicallyDefineDataIdentifier
2E	WriteDataByIdentifier
2F	IoctlByCommonIdentifier
30	IoctlByLocalIdentifier
31	StartRoutineByLocalIdentifier
32	StopRoutineByLocalIdentifier
33	RequestRoutineResultsByLocalIdentifier
34	RequestDownload
35	RequestUpload
36	TransferData
37	RequestTransferExit
3B	WriteDataByLocalIdentifier
3D	WriteMemoryByAddress
3E	TesterPresent
85	ControlDTCSetting
86	ResponseOnEvent
Service	ISO-14229-1 (UDS)
10	DiagnosticSessionControl
11	ECUReset
14	ClearDiagnosticInfo
19	ReadDTCInformation
22	ReadDataByIdentifier
23	ReadMemoryByAddress
24	ReadScalingDataByIdentifier
27	SecurityAccess
28	CommunicationControl
2A	ReadDataByPeriodicIdentifier
2C	DynamicallyDefineDataIdentifier
2E	WriteDataByIdentifier
2F	IoctlByIdentifier
31	RoutineControl
34	RequestDownload
35	RequestUpload
36	TransferData
37	RequestTransferExit
38	RequestFileTransfer
3D	WriteMemoryByAddress
3E	TesterPresent
83	AccessTimingParameter
84	SecuredDataTransmission
85	ControlDTCSetting
86	ResponseOnEvent
87	LinkControl

How Do I Request Data Parameters via OBD / UDS? Services 01 and 22 are most common (see below). Some older vehicles also used Service 21, however the meaning the those PIDs changed much more between vehicle models and years, while Service 01 is standardized, and Service 22 contains a mix of standardized and manufacturer PIDs (reasonably stable between models, in many cases).

What are the Standard Data PIDs for Services 01 and 22? There’s a really good list in SAE J1979-DA, but many can also be found on Wikipedia. Most Service 22 PIDs are manufacturer-specific, but there is standardized stuff up in the 0xFxxx range that is explained in ISO-14229 and SAE J1979-DA. Some manufacturers will also provide Service 01 PID data via Service 22 when you send requests in the 0x0000 – 0x00FF range, however with newer UDS stuff it is becoming more common to find these PIDs served by the 0xF400 – 0xF4FF range instead.

How Do OBD Module CAN IDs Work? Although CAN broadcast IDs can be all over the place, and a manufacturer’s non-OBD modules might be too, the use of CAN IDs for OBD modules is largely standardized. You may have noticed that you most commonly see OBD requests sent to 0x7DF or 0x7E0, and then get responses from 0x7E8.

On CAN-11, the Functional OBD request address is 0x7DF, and may result in responses from multiple modules that implement that particular request. This will typically only get responses from OBD-compliant modules, which will use response addresses in the range of 0x7E8-0x7EF. There is an offset of 0x8 between the OBD Request and Response ID… To address a specific OBD module individually, use the 0x7E0-0x7E7 range, and it will respond using the corresponding 0x7E8-0x7EF address. 0x7E0 is commonly the ECM or PCM, and it will respond using 0x7E8. Other non-OBD modules may also be accessible, but the ID’s used for them, and their relationship between Request and Response ID, will depend on the manufacturer. Several manufacturers tend to put their non-OBD modules somewhere in the 0x700-0x7DE range, but not all do (eg GM Global A uses 0x2xx for requests, with responses in 0x6xx).

CAN-29 is used less frequently (mainly Honda, Volvo, and GM Global B vehicles), but offers some useful benefits. When you see an address like 0x18DA10F1, that can be broken down into 0x18DA (OBD Physical addressing mode), 0x10 (Destination module ID; 0x10 and 0x11 are commonly used for the ECM/PCM), and 0xF1 (Source module ID; 0xF1 is the scantool). To send a Functional request to all modules, the ID of 0x18DB33F1 is used, and the responses will come back using addresses like 0x18DAF1xx, where the xx byte is the ID of the responding module. To send a request to a specific module, you would use 0x18DAxxF1.

Posted on

SavvyCAN Quick Start

Quick start for the DauntlessOBD device and our CAN Interface board, for using SavvyCAN via a USB connection. If you wish to use serial terminal commands, please see DauntlessOBD Developer & API Info.

SavvyCAN is a great open source project for monitoring and reverse engineering CAN traffic on Windows, Mac, and Linux. We are not affiliated with this project, just a huge fan, and we’ve added support for it to our products. The current SavvyCAN release can be obtained on GitHub.

Please note that if you are connected to the vehicle’s OBD port, or the OBD CAN wires, many recent vehicles will not have CAN broadcast traffic visible here, due to their use of a gateway device. As such, you may only see the CAN traffic to/from other OBD devices that are plugged in, which is useful for inspecting what they are doing, but you may not see anything unless said device is actively talking. To get more interesting CAN data on these newer vehicles, users typically connect a CAN Interface to the wires of a different CAN bus on the other side of the gateway.

Many mid-2000’s to mid-2010’s vehicles, most notably excluding VW/Audi/Porsche, will however have CAN broadcast traffic visible via the OBD port, so it’s usually still worth giving that a try first because it’s the easiest option.

SavvyCAN Quick Start for DauntlessOBD and CAN Interface

Connect your device to the vehicle’s OBD port (DauntlessOBD) or CAN wires (CAN Interface). If connecting directly to CAN wiring, be sure to use appropriate connectors and procedures, as well as setting the correct CAN termination jumpers, to avoid causing bus faults or damage.

Connect your device to your computer via a USB-C cable.

Start the SavvyCAN program.

Navigate the menu to Connection -> “Open Connection Window”.

Click the “Add New Device Connection” button.

Select “Serial Connection (GVRET)”, then set the Serial Port to the port your device is on.

Windows: it will be a COMx: port, and you can tell which one by opening Device Manager and going to Ports “(COM & LPT)”, then looking for “USB Serial Device”.

macOS: it will typically be /dev/tty.usbmodemXXXX

Linux: it will typically be /dev/ttyACM0 (Ubuntu and others; make sure your user account has permission to access it)

Click “Create New Connection”.

It should now appear in the list. Wait for it to show “Connected” status, and then double-click on it to view and change the Bus Details.

IMPORTANT: The Bus Details section may not be correct unless you first double-clicked on the device in the list.

In the Bus Details section at the bottom, you can choose the CAN Bus Speed, Listen Only Mode, and Enable.

A speed of 500000 is typical for OBD-II CAN, 250000 or 125000 for many comfort or body CANs, 33333 for General Motors Single-Wire CAN (aka GMLAN). We recommend using “Listen Only” mode to avoid disrupting the bus in case you have the Speed set incorrectly.

Click “Save Bus Settings” when done.

Exit the “Connection Settings” window. Any CAN traffic should be appearing on the main screen, assuming that there is traffic and the CAN bus speed is set correctly.

If the USB cable gets disconnected or the the connection is otherwise interrupted, you’ll need to return to the Connection Settings window to reestablish it.

Posted on

The Difference Between OBD and CAN

The terms OBD and CAN are sometimes used interchangeably and conflated, but they are separate protocols that exist in different layers of the communications stack.

OBD-II and similar protocols, such as Unified Diagnostic Services (UDS), define the actual command and parameter data when communicating with your vehicle. In order to send or receive that data, we need a low-level communications protocol to manage encoding / decoding it on the physical wires. That’s where the CAN bus comes in.

Most Vehicles use CAN for OBD

In the US market, most 2008 and newer vehicles are required to use CAN as the underlying protocol for their OBD implementation, and several manufacturers even started doing this a few years earlier. This is much faster and more capable than the older protocols it replaced, and greatly simplifies compatibility. Further reading: Which Vehicles Support CAN for OBD?

CAN May Also Exist Without OBD

OBD is just one of many uses for CAN. Even within a vehicle, there are commonly multiple CAN busses used to exchange data between different modules, and most of them have no requirement to implement OBD services. Typically, only the engine control module (ECM) and transmission control module (TCM) will respond to OBD requests. Sometimes hybrid, chassis, and body modules will as well. All of these modules will commonly exchange non-OBD data via CAN too, although that traffic may not be visible via the OBD port due to the use of gateways and/or different CAN busses.

CAN in itself does not define what the data means, or which commands or services will be available, as that is up to whatever higher-layer protocol is using it. As such, if someone asks a question like “What is CAN Frame 0x610?”, you can’t accurately answer that without more information on the make / model of vehicle, because that is not an ID defined by OBD standards, so it’s up to the manufacturer.

Similarly, if you have a non-OBD vehicle (such as a 100% Electric Vehicle), the presence of an OBD port does not mean that it will respond to OBD requests, although some raw non-OBD CAN traffic may be accessible this way.

OBD May Exist Without CAN in Older Vehicles

The presence of an OBD port does not mean that the vehicle supports OBD over CAN, or even CAN at all. Most vehicles since 1996 had the same OBD port, but prior to the auto industry fully adopting CAN, they used an assortment of different protocols to implement OBD, such as J1850 VPW (GM), J1850 PWM (Ford), and K-Line ISO-9141 / ISO-14230 / KWP2000 (mostly Imports).

In some cases, a vehicle of this vintage may use CAN for certain functionality and may even expose it via the normal CAN pins on the OBD port, but not actually provide OBD services over CAN. An example of this is the early Nissan 350z models, which have CAN traffic visible via the OBD port, but only services OBD requests via K-Line ISO-9141.

CAN-based products may still work on vehicles like that if they have decoders for the CAN data that is visible via the OBD port, but any attempt to use actual OBD services would fail without the product having support for the older low-level communications protocol. That’s how we support the 350z for our sequential shift light; although this car doesn’t talk OBD via CAN, we’ve figured out how to decode the manufacturer’s CAN data that is visible via the OBD port.

Posted on

D-Shift Enhanced CAN Decoding

The D-Shift Sequential Shift Light is enhanced with the ability to passively monitor and decode CAN data that is normally broadcast within many vehicles, enabling maximum performance with minimal lag or risk of interference with OBD tools. In the event that supported CAN broadcast data is not available, it will automatically fall back to requesting data via standardized OBD-II CAN communications, ensuring seamless coverage for virtually all 2009+ cars, plus certain models back as far as 2004.

CAN broadcast data is readily accessible via the OBD port CAN on many mid-2000’s to late-2010’s vehicles, enabling this enhancement to automatically work with an OBD Plug & Play installation, as well as the CAN Direct Wire option.

Most late-2010’s and newer vehicles, most VW/Audi/Porsche of all years, and some others, use a gateway module or otherwise do not have CAN traffic visible on the OBD port. As such, D-Shift OBD installations would simply fall back to using standard OBD-II communications. If you desire the benefits of enhanced CAN decoding on these vehicles, you would need to do a Direct Wire installation to a specific CAN (typically the Powertrain CAN).

Below is a list of included CAN decoders, which are covered by the default Auto Detect option, or may be manually selected using the D-Shift Mobile App. Information is based on D-Shift firmware v1.0.13.

  • Auto Detect
  • OBD-II – Standard OBD via CAN
  • OBD-II Alternate – Backup option for troubleshooting
  • Custom Decoder – Enter your own decoder in DBC Signal format (mobile app)
  • AIM
  • BMW/Mini 1 (early 2000’s; E46, E39)
  • BMW/Mini 2 (mid-2000s to mid-2010s; E8x, E9x)
  • BMW/Mini 3 (2010s to 2020s; F2x, F3x, F8x)
  • BMW/Mini 4 (2010s to 2020s; incl Toyota Supra Mk5)
  • Dodge/Chrysler/Jeep 1
  • Dodge/Chrysler/Jeep 2
  • Dodge/Chrysler/Jeep 3
  • Dodge/Chrysler/Jeep 4 (Dart)
  • Dodge/Chrysler/Jeep 5
  • Dodge/Chrysler/Jeep 6 (also some Fiat)
  • Dodge/Chrysler/Jeep 7
  • Dodge/Chrysler/Jeep 8 (Wrangler JL)
  • Ferrari
  • Fiat 1 (500)
  • Ford/Lincoln 1 (2000s to mid-2010s)
  • Ford/Lincoln 2 (late-2010s)
  • Ford/Lincoln 3
  • Ford/Lincoln 4
  • General Motors A (2000s to late-2010s)
  • Haltech
  • Honda/Acura 1 (Common)
  • Honda/Acura 2
  • Honda/Acura 3 (S2000 AP2)
  • Honda/Acura 4
  • Hondata
  • Hyundai/Kia 1
  • Hyundai/Kia 2
  • Hyundai/Kia 3
  • Hyundai/Kia 4
  • Lotus 1
  • Lotus 2
  • Mazda 1 (2000s to mid-2010s; NC MX-5, RX-8)
  • Mazda 2 (mid-2010s to 2020s; ND MX-5)
  • McLaren
  • Mercedes 1 (late-2000s to mid-2010s)
  • Mercedes 2 (late-2010s to 2020s)
  • Mercedes 3
  • Mitsubishi
  • Nissan/Infiniti 1 (Common; GT-R, 370z, G37)
  • Nissan/Infiniti 2 (350z, G35)
  • Nissan/Infiniti 3
  • Porsche 1 (996)
  • Porsche 2 (997, 987)
  • Porsche 3 (991)
  • Porsche 4 (991, 981, 982)
  • Porsche 5 (992)
  • Porsche 6 (991.2, 982)
  • Subaru 1 (2010s to early-2020s; incl 1st gen BRZ & Toyota 86/FRS)
  • Subaru 2 (late-2010s to 2020s; incl 2nd gen BRZ & Toyota GR86)
  • Subaru 3 (2000s to early-2010s)
  • Toyota/Lexus 1
  • Toyota/Lexus 2
  • Volvo
  • Volkswagen/Audi 1 (2000s to mid-2010s; TT, Golf Mk4/Mk5)
  • Volkswagen/Audi 2 (2000s to mid-2010s)
  • Volkswagen/Audi 3 (late-2010s; Golf Mk7)
  • Volkswagen/Audi 4

Dauntless Devices LLC claims no affiliation with, or endorsement by, any listed manufacturer or brand, unless explicitly stated. List is provided as general compatibility guidance and may not cover all models, trim levels, or options. This may change with different firmware versions. Firmware can be updated using the mobile app.

Posted on

CAN Direct Wire Installation Info

Details for directly wiring D-Shift to the vehicle’s CAN bus.

Where supported, the OBD Plug and Play cable will provide a much faster and simpler installation experience. We recommend that option wherever suitable. The option described in this document, to directly wire to the CAN bus, is a more involved and advanced installation option, useful when the OBD port doesn’t provide CAN data broadcasts.

CAUTION: Incorrect CAN bus connection, or any wiring damage caused during installation, may cause improper vehicle operation and/or damage. Dauntless Devices LLC is not liable for any consequences of improper wiring, incompatible configuration, or damage. This type of installation should only be attempted by properly trained and qualified installers who are willing to accept the risks. The information herein is provided as-is, without any guarantee of any kind, and is intended only as general guidance. All wiring locations, colors, and functions must first be verified for the specific vehicle. Installations must be verified and tested in a safe environment.

Disconnect vehicle power before unplugging modules or making connections, and do not reconnect power with any modules disconnected, as they may provide important vehicle functionality.

Please scroll further down for information on specific vehicles, where available.

How to Identify CAN Wires

  • Wiring diagrams will often refer to them as CAN High and CAN Low, or an abbreviation thereof
  • These will typically be two wires twisted together, but some manufacturers don’t do this.
  • Voltage levels should be no more than 5 volts when measured between CAN High and CAN Low, no more than 3.5 volts when measured between CAN High and Ground, and no more than 2.5 volts when measured between Ground and CAN Low.
  • With the vehicle powered off, a multimeter should measure about 60 ohms of resistance, as 120 ohm termination resistors are supposed to be installed on the two ends of the bus. This may not function properly if certain modules are not plugged in (especially the gateway), as a termination resistor is sometimes contained within a module.

Common CAN Wire Locations

  • OBD-II Port under driver side dashboard. Sometimes Pins 6/14 will have useful broadcast data on it, sometimes it’s only used for OBD requests, and sometimes (older vehicles, pre-2008) we don’t get anything useful on it at all. There may also be additional CAN busses exposed via other pins of the OBD port.
  • Gateway Module: This is typically a nexus that connects to multiple CAN busses and routes data between them as appropriate.
  • Engine Control Module (ECM): Being that RPM is the main data we want here, the engine computer is the most likely module to transmit that.
  • Other Powertrain Modules: If the Engine Control Module and Gateway Module aren’t easily accessible, consider others that likely receive the data we’re looking for.
  • Instrument Gauge Cluster: This unit will typically be receiving RPM data via a CAN bus, however some vehicles may do this via a separate CAN bus and with different encodings than the Powertrain CAN that our decoders are typically setup for.
  • Steering Angle Sensor: These are commonly a straightforward connection with just CAN High, CAN Low, Power, and Ground, however some vehicles may have this on a non-Powertrain CAN that might not contain RPM data.

Please note that there are often multiple CAN busses on a vehicle, each containing different data. For this product, we’ll typically need one that services the Powertrain modules and/or OBD, so that we can get RPM.

CAUTION: Avoid connecting to, modifying, or disturbing any wiring related to Airbags / SRS or other safety systems. These will sometimes use yellow or orange connectors or cabling, but not always. Again, you are responsible for knowing the correct wiring information for the vehicle and making appropriate connections. If you’re not sure about something, don’t do it.

2022+ Subaru BRZ / Toyota GR86

This information was developed during our R&D with a 2024 Toyota GR86 Trueno. Other years, models / trims, or configurations may differ.

Although the OBD Plug & Play option supports this vehicle well, you may desire a simpler and more compact CAN Direct Wire install, which will also free up your OBD port.

There are multiple CAN busses on this vehicle, and multiple places to tap into them. We found that the Steering Angle Sensor is connected to a CAN bus with compatible signals and provides power. It is easily accessible on the bottom of the steering column, once you remove the plastic steering column cover. Use care to avoid airbag and other wiring, which uses similar wire colors into different connectors.

Optimal CAN Settings (in D-Shift app):

  • CAN Type: Subaru 2
  • Allow OBD Query: Off

Connections at GR86 Steering Angle Sensor:

  • +12V Power: White (Pin 4 on connector; switched ignition power)
  • CAN-High: Green (Pin 3 on connector)
  • CAN-Low: Pink (Pin 2 on connector)
  • Ground: Black (Pin 1 on connector)

Volkswagen Golf / GTI (Mk4 – Mk6 generations)

While this information was developed during our R&D with a 2002 GTI 1.8L Turbo, we believe it is generally applicable to the Mk4 through Mk6 generation VW Golf, spanning approximately 1999 through 2012 model years. Other years, models / trims, or configurations may differ.

There are multiple CAN busses on this vehicle, and you will need to tap into the Powertrain CAN that connects the ECM (aka DME) and the Instrument Cluster, which is different from the CAN wires on the OBD port. Behind the Instrument Cluster is likely the most suitable location, as the ECM’s wires are on the engine side of the firewall, and other modules may be less easily accessible.

Known Locations (Mk4): Instrument Cluster, ECM, TCM (if automatic), Airbag Control Module, ABS Module, Steering Angle Sensor

Wire Colors: Orange/Black (CAN-High), Orange/Brown (CAN-Low)

Note: These CAN colors are not unique. The Mk4 Instrument Cluster can also have these same wire colors on pins 27/28, and the OBD-II port on pins 6/14. We did not find either of those to be functional for this product on the 2002 GTI (Mk4) we tested on, however they likely serve OBD requests on the Mk5 and Mk6. When connecting at the Mk4 Instrument Cluster, make sure you are using the pair connected to Pins 19 and 20. For Mk5 and Mk6, look at your wiring diagram to get the correct pin numbers and make sure you’re tapping into the pair that connects to the ECM.

If you encounter an Orange/Green and Orange/Brown pair, that is likely the Comfort/Body CAN, which does not contain the data we need for this product.

Optimal CAN Settings (in D-Shift app):

  • CAN Type: Volkswagen/Audi 1
  • Allow OBD Query: Off

Connections at Mk4 GTI Instrument Cluster:

  • CAN-High: Orange/Black (Pin 19 on green connector)
  • CAN-Low: Orange/Brown (Pin 20 on green connector)
  • +12V Power: Black/Violet (Pin 1 on blue connector; switched 5A power)
  • Ground: Brown (Pins 9 and 24 on blue connector)

Porsche 911 (991 generation)

This information was developed during our R&D with a 2014 Porsche 911 GT3 (991.1). Other years, models / trims, or configurations may differ.

Although the OBD Plug & Play option supports this vehicle, you may have a more optimal experience with a CAN Direct Wire install, as the 991.1’s OBD port access is under the fuse box cover, and its OBD data is not refreshed as often as we’d prefer (only 5 Hz actual change rate on the 991.1 GT3, versus up to 100 Hz with this CAN Direct Wire).

There are multiple CAN busses on this vehicle, and you will need to tap into the Powertrain CAN that connects the ECM (aka DME) and the Gateway module, which is different from the CAN wires on the OBD port. The gateway module (driver side footwell, above fuse box) is likely the most suitable location. If you unplug the connector from the module, you’ll be able to more easily access the wires.

Wire Colors: Orange/Red (CAN-High), Orange/Brown (CAN-Low)

Optimal CAN Settings (in D-Shift app):

  • CAN Type: Porsche 4 (for 991.1 GT3, others will vary)
  • Allow OBD Query: Off

Connections at 991.1 GT3 Gateway Module:

  • CAN-High: Orange/Red (Pin 20 on connector)
  • CAN-Low: Orange/Brown (Pin 10 on connector)
  • +12V Power: Red/Yellow (Pin 1 on connector; constant power)
  • Ground: Brown or Brown/White (Pin 11 on connector)
Posted on

Which Vehicles Support CAN for OBD?

Our automotive products that utilize vehicle data communications are typically based on the industry-standard CAN protocol. This is found in virtually all 2009 and newer US-market gasoline and diesel cars, light trucks, and SUVs, along with many others dating back as early as 2004.

For US-market passenger automobiles, CAN was mandated for OBD-II starting with the 2008 model year. A small number of manufacturers were allowed to delay this, meanwhile many others had already implemented CAN for several years in certain vehicle models and trims.

While this is not all-inclusive, here is a list of popular US-market automobiles we’re aware of that typically support OBD over CAN:

  • 2009+ BMW
  • 2009+ Lamborghini
  • 2009+ Mercedes
  • 2009+ Porsche
  • 2008+ for All Other Manufacturers and Models

Pre-2008 Vehicles that also support OBD via CAN:

  • 2007+ Chrysler / Dodge / Jeep – Most Models
  • 2007+ Honda / Acura – Most Models (including Civic Si)
  • 2007+ Toyota / Lexus – Most Models
  • 2006+ Audi / Volkswagen – Most Models
  • 2006+ Dodge Charger
  • 2006+ Dodge RAM
  • 2006+ General Motors (Chevrolet / GMC / Cadillac / Pontiac) – Most Models
  • 2006+ Honda S2000
  • 2006+ Mazda – Most Models
  • 2006+ Volvo – Most Models
  • 2005+ Chevrolet Corvette (C6)
  • 2005+ Dodge Durango, Dakota
  • 2005+ Ford – Most Models (including Mustang)
  • 2005+ Pontiac GTO
  • 2004+ Ford F150, F250
  • 2004+ Mazda RX8

Please note that this covers most cases for each of the listed groups. There may still be some models, trim levels, or options within these that are not supported prior to the 2008 (or later) model year. Similarly, there may also be some configurations supported in earlier model years than listed.

This applies to road-legal US-market passenger automobiles with an internal combustion engine. 100% electric vehicles, motorcycles, off-road vehicles, heavy trucks, busses, custom / kit vehicles, etc., may lack this type of OBD-II support entirely. The J1939 protocol commonly used by heavy trucks, busses, and similar vehicles, is not included in this support.

While many vehicles use CAN, an important distinction here is for them to support OBD-II via CAN. That’s what this list is based on. As such, OBD-exempt 100% electric vehicles like Tesla are unlikely to work, even though they may use CAN for their own purposes.

Vehicles manufactured for non-US markets will have different OBD requirements and implementation dates.