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…

Gateways

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

OBD Device Triggering Alarm on BMW and Mini Cooper

Recent BMW and Mini Cooper vehicles have an “OBD Alarm” feature that will trigger if any device sends an OBD request while the alarm is armed. This has been problematic for many OBD-based devices on the market, as it is fairly common to at least send a periodic OBD request to detect if the engine has been started so that the device can awake from sleep mode.

Fortunately, our D-Shift Sequential Shift Light offers a setting that will help with this: In the D-Shift app, go to the Settings screen, scroll down to the “Wake via OBD” setting and change it to Off. That will prevent it from sending any OBD requests when it is in sleep mode. In D-Shift firmware version 1.2.5 and newer, it will also enter sleep mode even sooner when this setting is turned off, so that it should be asleep by the time you exit the vehicle and lock the doors.

Please note that when the “Wake via OBD” setting is turned off, the device will rely on only passive methods to determine if the engine has been started. While this has worked very well for us, every car is different, so if you find that it’s not responsive after you start the engine, you can always manually wake it up by simply pressing the button on the device.

Posted on

Standard vs Enhanced OBD-II Code Scanning

What’s the difference between Standard and Enhanced code scanning? Which modules do these cover?

Standard OBD-II Code Scanning

The OBD-II specification provides a standard way to scan and reset Diagnostic Trouble Codes (DTCs), commonly also known as a Check Engine Light or CEL codes.

This works universally across all OBD-II compliant vehicles, however is it typically limited to modules related to the powertrain and/or vehicle emissions, such as the Engine Control Module (ECM), Transmission Control Module (TCM; usually only for automatic transmissions), and sometimes certain other modules such as Hybrid systems.

These modules are the main causes of engine or service lights that may appear on the dashboard, and very importantly, trouble codes that may impact emissions readiness. DauntlessOBD supports these, as well as emissions readiness monitors, Mode 06 test data, live OBD-II data streams, and the possibility of enhanced code scanning on certain vehicles (see below).

Enhanced Code Scanning (additional modules)

Most modern vehicles have far more modules than just the engine or powertrain, and it’s very useful to scan codes from those as well. These can include the Brakes (ABS / EBCM), Airbags (SRS), Body Control Module (BCM), Infotainment / Navigation, Instrument Cluster, and many more.

Although these modules are typically accessed via the OBD connector, they are not actually a standardized part of the OBD-II specification, and different manufacturers implement them in various different ways. That means that scantools, OBD apps, and other code readers will have varying levels of support for these modules, if they are even supported at all. You may also find that different tools (or apps) cover different modules than each other, or some seem to pull more codes from the same module.

DauntlessOBD can scan codes from many of these additional modules on supported manufacturers and models, where practical. The catch is that while we do support this for many vehicles and hope to keep expanding on that, each manufacturer or model does take time and resources to develop, and it can change by vehicle model and year, so ultimately we can’t cover everything. What’s available with our device and app can vary by manufacturer, vehicle model and year, and even trim level.

While we provide a free app for this with DauntlessOBD, we’ve also designed it so that you are not limited to just our apps, and have the flexibility to choose from other compatible apps, some of which might offer different or more code scanning capabilities.

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

Just How Fast is DauntlessOBD?

In addition to providing basic and some enhanced diagnostics capabilities, plus various enhancements for app developers, we specifically designed DauntlessOBD to provide super fast OBD2 data streams to several popular apps so that you can more effectively view and analyze your data.

The 3rd party app we get asked the most about is TrackAddict, and here’s what our own performance testing showed for it on both iOS and Android, versus several other popular ELM327-compatible OBD interfaces:

DauntlessOBD Info

Yes, that’s right… For some vehicles, we did find that certain other devices that use “Classic” BT can match or even out-perform us on Android. It is what it is. We’re not here to BS you. We’re often the fastest, and in the few cases where we don’t lead in raw performance, we aim to win on price and features.

Tests were conducted in early 2024, with DauntlessOBD firmware version 1.3.0. Charts indicate typical sustained group sample rate (Hz) as observed on the “Raw Data” live monitor after being connected for 1 minute. Channels selected: Engine Speed, Vehicle Speed, Throttle Position. As such, a reported rate of 5 Hz for these 3 data channels would indicate an average of 15 data points per second, which other apps might report as a 15 Hz sample rate.

On Android, higher performance is generally possible than on iOS, and the use of Classic BT mode is typically a performance advantage as well. We’ve tested in that mode for devices that support both.

In the event of spikes, the lower and more sustained rate was used. For consistency, tests were performed with ignition on and engine not running. These may be impacted by variables related to vehicle, smartphone device, wireless signal conditions, and other factors. Typically, different smart phone devices and vehicle models / configurations will have different results, and different apps or app settings will have different results as well. Your results may vary. Not all apps are compatible. Future product and firmware revisions may have different results.

We are not affiliated with, or endorsed by, any product or brand listed here.

Posted on

Using D-Shift with an OBD Splitter / Y-Cable

We’ve designed the D-Shift Sequential Shift Light to operate as passively as practical, and with smart active / passive OBD functionality, to maximize compatibility when you are using an OBD splitter or y-cable with another OBD device. How well that works will depend somewhat on the other OBD device that’s in use and what it’s doing.

For example, if you also have an OBD dongle, such as our DauntlessOBD or another, you might want to use a track day app or a dashboard gauges app while driving on the track and also using your shift light.

First, many mid 2000s to late 2010 cars often have manufacturer CAN data visible via the OBD port that we know how to decode to get the RPM reading, which allows us to operate entirely passively and eliminate our need to send OBD requests at all. That’s our best option when available, as it gets us fast data with minimal lag, and does not impact any other OBD devices you may be using. Newer vehicles, and all VW/Audi/Porsche, tend to have a gateway that excludes this data from being visible to us via the port (although it can usually be obtained via a Direct Wire installation). When this manufacturer CAN data is not available or understood, we automatically fall back to using OBD requests to get the RPM reading.

When we’re the only device sending OBD requests, this typically works very well. But when there’s another OBD device in use (eg when using an OBD splitter or Y-cable), there is a potential for interference, and we’ve developed some logic to help with that. If the other device is not actively talking to OBD modules, then we’ll operate as normal. When we do detect that another device is talking to OBD modules, then our default Auto Passive Mode will make us go silent to avoid interfering until a little while after we stop detecting those communications.

In that case, we would be passively observing the OBD data that the other device is requesting, and getting our RPM reading by decoding the OBD responses containing RPM data. The catch here is that the other device needs to be actively requesting RPM data, doing it in a standardized OBD way, and doing it as often as possible. Our shift light performance would be dependent on what that other OBD device is doing. Typically, we’d want the RPM data to be requested at least 5 times a second, but preferably closer to 10 for best performance.

We have found that many OBD dongles for your phone are often not very fast, especially the cheap ones that have flooded that market, and would of course recommend our own DauntlessOBD, which was designed with performance in mind.

The D-Shift mobile app also gives you options to disable OBD Queries entirely (forces passive mode), and even to disable Auto Passive Mode (forces active mode).

Posted on

What is ELM327?

We’re not “ELM327”, and you shouldn’t trust anyone who falsely claims to be.

The real ELM327 was an automotive interface chip from the now-defunct Elm Electronics company, which offered a simple and powerful command set for computers and smartphones to communicate with OBD-II equipped automobiles. It became extremely popular, and the defacto standard for many OBD-enabled apps, leading various other OBD interface manufacturers to implement the ELM327 command set as well.

However, the bottom end of the OBD interface market has become absolutely flooded with cheap and problematic devices, often also misrepresenting themselves as simply being “ELM327”, as if that is their brand or model name. These tarnish the ELM327’s otherwise good name, and make it very important that buyers do their research. We have found such devices to be made up of various different components and quality, despite often appearing visually identical from the outside, making it hard to know if you’re getting a “good” one or total junk. While some of these even do seem to work, the performance has generally been quite poor, many misrepresent their capabilities and have broken or incomplete ELM327 command set implementations, typically have little to no wireless security, may drain your car’s battery if left plugged in, and reliability has been questionable at best.

We strongly recommend avoiding any complete device representing its brand or model name as “ELM327”, as these are almost certainly fakes. The real ELM327 chip did not have Bluetooth or WiFi in it, and would have instead been one of many components inside a quality device, which would have its own brand and product name. With Elm Electronics closed down, we wouldn’t even expect to find many of those anymore.

What you want to look for is a reputable OBD device that is “ELM327 Compatible”, that has its own brand name and identity, from a real company that you trust.

To that end, we designed DauntlessOBD to provide superior quality, performance, security, and innovation. We’re a US-based business that loves cars and motorsports, and have invested extensive time and effort into developing an extremely complete and compatible ELM327 command set implementation for today’s CAN-based vehicles, while also innovating beyond that, using quality components and designs, intelligent power saving logic, secured wireless pairing, offering our own app to get you started, and more.

When you get tired of gambling on low-end knock-offs claiming to be “ELM327”, we’d love to earn your business.

DauntlessOBD Info
Posted on

Where is My Car’s OBD-2 Port?

US market cars, pickup trucks, and SUVs since 1996 were required to have an OBD-II port for standardized diagnostics. This is also known as an SAE J1962 port or a Data Link Connector (DLC). However, 100% Electric Vehicles may not have this port at all, or it may not actually provide OBD services.

Although the OBD standards have evolved with significant improvements over the years, the physical connector shape has remained the same.

It is typically located under the driver’s side dashboard, and most often on the left side. Less commonly, some vehicles may place it more towards the center or right side under the driver’s side dashboard.

In most vehicles, the OBD-II port is readily accessible, however there are some vehicles that place it behind an easily removable panel. For example, the Porsche 991.1 and some others have it behind the fuse box cover on the left side footwell.

In cases where a device plugged into the OBD port may get bumped or interfere with the driver, we recommend using a quality 90-degree connector or an OBD extension cable to resolve the conflict. The OBD cable for the D-Shift Sequential Shift Light typically uses a right-angle OBD plug which may help with this.

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

Why Doesn’t Throttle Position Sensor (TPS) Show Full 0-100%?

A common question affecting DauntlessOBD users is why OBD-II Throttle Position Sensor data doesn’t show the full range of 0 to 100%. In most cases, it will show around 10 to 20% on the low end, and 80 to 90% on the high end. These limits tend to vary by vehicle model.

While this limited range is understandably confusing, it is what is being reported by your vehicle, which is conforming to the SAE standard for this parameter. SAE defines PID 11 (Absolute Throttle Position) as a reading of 0 to 100% relative to the reference voltage of the Throttle Position Sensor, which is typically 5.0 Volts. It is common for these sensors to have an actual working range of approximately 0.6 to 4.4 Volts, which would result in a reported range of 12 to 88%.

Other parameters, such as Relative Throttle Position, may be useful in reporting a normalized 0 – 100% range, depending what’s supported by your vehicle model.

Additionally, most vehicles use throttle-by-wire these days, which means that the ECM can control the throttle plate independently from how much you’re pressing on the accelerator pedal, so there may not always be a clear relationship between the two. While the throttle plate position can be what you want for engine diagnostics and data logging, if you want to know what the driver is doing, you should instead use the Accelerator Pedal Position or a similar data stream (if supported by your vehicle and app).

Dauntless OBD app showing example of Accelerator Pedal vs Absolute Throttle Position on a 2016 Toyota Tundra