Easy Obdii

[Brian]

Thecompany suggests that you test their software prior to purchasing as they do not offer refunds. They offer 1 year email support service packages at additional cost. This support package covers the software only, not any scan tool issues. Previous versions of the software are available as free downloads (Open Source). The current software version is 3.4 and they have been required to make several changes to the software for the Scan Tool LLC ELM Scan 5 product.

One of their latest improvements to v3.4 was to increase the communication speeds achievable to 115,000 baud. This was included in the free versions as well. They are currently suggesting a version 4 may be coming soon.

To obtain any version of the software, even the latest free version (2.4) you must create an account and supply complete contact information. The company web site has one fluke, when you try to check out you must be using Internet Explorer. The web site has information that it will be updated soon; hopefully the check out quirk can be eliminated.

This software appears to have been created with the distribution focused on one scan tool distributor only and that focus is still visible today. The software attempts to identify if the scan tool is a Scan Tool LLC. If it is not then you must tell it what scan tool you are using. It probably uses the header info in the tool IC programming to discern this. The software is easy to use and connects to com ports above 9.

The software connected easily with both of our test scan tools and maintained good connections to the vehicle. It connected at 38,400 baud with both scan tools on our test vehicle, a 9141-2 protocol with a communication speed specification of 10,400 baud.

The software interface is a little cluttered in design, but can be navigated easily emough. The free version tested does have the diagnostic monitors available. The on screen controls for non supported testing are grayed out. The data is not all contained on one screen, thus you must navigate from screen to screen to obtain the data. The data does not display certain sensor data (PIDs) immediately. It appears this restriction is there until some time factor has been achieved or until the vehicle achieves closed loop operation (fuel control is present). It will not present data for certain sensors and switches for Key On Engine Off (KOEO) baseline testing.

A professional wants to check the data in many states such as Key On Engine Off (KOEO), Key On Engine Running (KOER) testing would also include cold in open loop and in closed loop operation. It has no graphing capability in the test version perhaps that will be available in version 4.

This software is very similar to many other free or low priced software programs and as such is not acceptable to a professional. However the typical home user or hobbyist would probably not find this a problem. It is not recommended for professionals or enthusiasts.

As evident 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.

3a8082e126