Asevident from the illustration, the two types share similar OBD2 pinouts, but provide two differentpower supply outputs (12V for type A and 24V for type B). Often the baud rate will differ as well, withcars typically using 500K, while most heavy duty vehicles use 250K (more recently with support for500K).
To help physically distinguish between the two types of OBD2 sockets, note that the type B OBD2 connectorhas an interrupted groove in the middle. As a result, a type B OBD2 adapter cablewill be compatible with both types A and B, while a type A will not fit into a type B socket.
In particular, ISO 15765-4 describes the physical, data link layer and network layers, seeking to standardizethe CAN bus interface for external test equipment. ISO 15765-2 in turn describes the transport layer (ISOTP) for sending CAN frames with payloads that exceed 8 bytes. This sub standard is also sometimes referredto as Diagnostic Communication over CAN (or DoCAN). See also the 7layer OSI model illustration.
However, if you're inspecting an older car (pre 2008), it is useful to know the other four protocols thathave been used as basis for OBD2. Note also the pinouts, which can be used to determine which protocol maybe used in your car.
SAE J1962: This standarddefindes the physical connector used for the OBD2 interfacing, i.e. the OBD2 connector. The standard describesboth the vehicle OBD2 connector and the connector used by the external test equipment (e.g. an OBD2 scanner orOBD2 data logger). In particular, the standard dictates thelocation and access to the OBD2 connector.
SAE J1979: The SAE J1979standard describes the methods for requesting diagnostic information via the OBD2 protocol. It also includes alist of standardized public OBD2 parameter IDs(OBD2 PIDs) that automotive OEMs mayimplement in cars (though they are not required to do so). Vehicle OEMs may also decide to implement additionalproprietary OBD2 PIDs beyond those outlined by the SAE J1979 standard.
SAE J1939: The J1939 standard describes the data protocol used for heavy-duty vehicle communication. While OBD2PID information is only available on-request by OBD2 test equipment, the J1939 protocol is used in mostheavy-duty vehicles as the basic means for communicating CAN traffic -meaning data is broadcast continuously.
ISO15765-2: The ISO-TP standard describes the 'Transport Layer', i.e. how to send data packetsexceeding 8 bytes via CAN bus. This standard is important as it forms the basis for UnifiedDiagnostic Services (UDS) communication, which relies on sending multiframe CAN data packets.
OBD2 is generally focused on emission control, while UDS is focused on diagnostics and read/write access to ECUs- primarily for production-stage vehicles. CCP and XCP are focused on measurement and calibration of ECUs withinprototype vehicle ECUs and they are less oriented towards diagnostics.
Basically, OBD3 adds a small radio transponder (as in e.g. bridge tolls) to all cars. Using this, the carvehicleidentification number (VIN) and DTCs can be sent via WiFi to a central server forchecks.
The proposal is to "turn off" the OBD2 functionality while driving - and instead collect the data in acentral server. This would effectively put the manufacturers in control of the 'automotive bigdata'.
The argumentation is based in security (e.g. removing the risk of carhacking), though many seeit as a commercial move. Whether this becomes a real trend is to be seen - but it may trulydisrupt the market for OBD2 3rd partyservices.
In principle it is simple to log the raw CAN frames from your car. If you e.g. connect a CAN logger to the OBD2 connector, you'll start loggingbroadcasted CAN bus data out-the-box. However, the raw CAN messages need to be decoded via a database of conversion rules(DBC) and a suitable CAN software that supports DBC decoding (like e.g. asammdf). The challenge isthat these CAN DBC files are typically proprietary, making the raw CAN data unreadable unless you're theautomotive OEM.
Car hackers may try to reverse engineerthe rules, though this can be difficult. CAN is, however, still the only method to get "full access" toyour car data - while OBD2 only provides access to a limited subset of data.
The CANedge lets you easily logOBD2 data to an 8-32 GB SD card. Simply specify what OBD2 PIDs you wish to request, then connect it to yourcar via an OBD2 adapter tostart logging. Process the data via free software/APIs and our OBD2 DBC.
PID: For each mode, a list of standard OBD2 PIDs exist - e.g. in Mode 01, PID 0D is VehicleSpeed. For the full list, check out our OBD2 PID overview.Each PID has a description and some have a specified min/max and conversion formula.
A, B, C, D: These are the data bytes in HEX, which need to be converted to decimal form beforethey are used in the PID formula calculations. Note that the last data byte (after Dh) is not used.
There are 10 OBD2 diagnostic services (or modes) as described in the SAE J1979 OBD2 standard. Mode 1 showsCurrent Data and is used for looking at real-time parameters like vehicle speed, RPM, throttle position etc.Other modes are e.g. used to show/clear diagnostic trouble codes (DTCs) and show freeze frame data.
OBD2 scanners: Used as car diagnostic tools in static reading/clearingof DTCs by e.g. mechanics. An OBD2 scan tool is typically used in diagnosing vehicle issues e.g.indicated by an activated MIL. Varioustypes exist and some private persons use low costvariants as simple car code readers for self-diagnosing their car health.
Bluetooth OBD2 dongles: Many OBD2 bluetooth dongles exist, which letyou view car data directly on your smartphone via an app. Typically OBDII bluetooth dongles are low costand easy-to-use, though also limited in terms of their usability outside the bluetooth-to-appvisualization purpose. The purpose of an OBD2 bluetooth dongle is typically to monitorpersonal driving behavior and vehicle health.
OBD2 interfaces: Provide real-time OBD2 data to a PC via USBstreaming. OBD2 interfaces are typically used in advanced car diagnostics and OEM vehicle development.Further, CAN interfaces that support OBD2 requests can be useful as part of reverseengineeringproprietary CAN bus parameters.
OBD2 loggers: Used to log OBD2 datafrom a car to an SD card - ideal for e.g. blackbox use cases or prototype field tests by automotiveOEMs. As an example, the CANedge1 lets you log CANbusdata, as well as request OBD2 data by sending custom frame requests to the CAN bus.
WiFi OBD2 logger: WiFi OBD2loggers and WiFi OBD2 dongles enable the automated transfer of OBD2 data via WiFi to aserver/cloud. WiFi OBD2 loggers are typically used for OBD2 telematicsuse cases, where car fleet data needs to be collected automatically and visualized via OBD2 datadashboards. For example, the CANedge2 letsyou log CAN/OBD2 data and auto-push it via a WiFi accces pointto your own server. The data can be processed in free software tools ande.g. visualized in Grafana dashboards.
3G/4G OBD2 logger: Similar to the WiFi OBD2 loggers, LTE OBD2 loggerslet you collect OBD2 data to an SD card and offload it to your own server. But instead of supportingWiFi connectivity, these devices directly connect via 3G/4G - see for example the CANedge3.
I have a cel code after reinstalling my ecu....I am told it will likely clear itself after running the bike a bit...seesm when flashing the ecu disconnected from the bike it doesnt see all its sensors and Shet so throws codes.
So, any reader will work to read codes, but you're IMHO way better off getting a better bluetooth reader and using that, because it can do MUCH more than just read codes. You can monitor engine data *while riding* with the Torque app (or many other apps) and a bluetooth reader, even charting data live.
The $5-10 Amazon blue bluetooth dongles work fine, but there's a danger: They'll continue drawing power when the bike is turned off to power their radios, and this can result in a dead battery after a week or so. So if you go this way, don't leave them connected 24/7.
As it will go to sleep when the bike is turned off and not drain power. It comes with great smartphone apps too, not as good as Torque but very easy to use. I keep this installed on my Tracer all the time, as it's fun to have an additional display on my phone showing top 0-60 times, top speeds, and other fun stuff while screwing around.
I find the phone app versions are SO MUCH EASIER to use, too. Torque, for example, will not just tell you "It's showing code 108", it'll tell you what that means and provide a web site link to more information about it. The hand held code readers are limited and often not super helpful if you don't know what the code numbers mean.
in 1996 a federal law took effect requiring most new consumer vehicles in the US to have standards-based On Board Diagnostics, called OBD-II. the OBD regulations were put in place by the EPA for monitoring emissions related components, but the systems have evolved to be much more capable.
the good thing about OBD-II was it defined a limited set of network types that a car maker could implement for the emissions related diagnostics. this meant that tools to interface with those networks could also become standardized and inexpensive. called scan-tools, they come in full-featured versions with built-in software/display/buttons, and dumb versions that must be connected to a PC/Mac/tablet/phone to be useful.
the challenge: OBD-II standards only apply to the emissions related portions of a vehicle bus. other systems often operate on an entirely different bus which may or may not use the same protocol as the OBD-II diagnostic bus. even worse, the non-emissions-related bus data is proprietary manufacturer info that can vary for each make/model/year.
the good news is that for simplicity and cost-savings, most manufactures only implement a single network type during certain year ranges. since they have to use one of the standard OBD-II protocols for the diagnostic bus, they might as well use the same protocol (or a slight variation) on the other buses. this is why we are sometimes able to use a scan-tool to interface with a non-OBD bus.
3a8082e126