Disassembling an OBD-II scanner

What’s an OBD-II (sometimes alternatively referred to as OBD-2, and other times in either form absent the interstitial hyphen) scanner? Answering that question first requires an understanding of what OBD is. The acronym stands for on-board diagnostics; here’s the introductory summary from Wikipedia’s entry:

On-board diagnostics (OBD) is a term referring to a vehicle’s self-diagnostic and reporting capability. OBD systems give the vehicle owner or repair technician access to the status of the various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely since its introduction in the early 1980s versions of on-board vehicle computers. Early versions of OBD would simply illuminate a malfunction indicator light (MIL) or “idiot light” if a problem was detected, but would not provide any information as to the nature of the problem. Modern OBD implementations use a standardized digital communications port to provide real-time data in addition to a standardized series of diagnostic trouble codes, or DTCs, which allow a person to rapidly identify and remedy malfunctions within the vehicle.

Interestingly, I learned while researching this piece, the term “OBD-I” was retroactively applied to an earlier California Air Resources Board (CARB)-initiated on-board diagnostics approach, after the standardization and rollout of OBD-II roughly a decade later. OBD-I first:

The regulatory intent of OBD-I was to encourage auto manufacturers to design reliable emission control systems that remain effective for the vehicle’s “useful life”. The hope was that by forcing annual emissions testing for California starting in 1988, and denying registration to vehicles that did not pass, drivers would tend to purchase vehicles that would more reliably pass the test. OBD-I was largely unsuccessful, as the means of reporting emissions-specific diagnostic information was not standardized. Technical difficulties with obtaining standardized and reliable emissions information from all vehicles led to an inability to implement the annual testing program effectively.

Now for OBD-II, which was mandatory for all cars sold in the United States beginning in 1996, again quoting straight from Wikipedia:

OBD-II is an improvement over OBD-I in both capability and standardization. The OBD-II standard specifies the type of diagnostic connector and its pinout, the electrical signaling protocols available, and the messaging format. It also provides a candidate list of vehicle parameters to monitor along with how to encode the data for each. There is a pin in the connector that provides power for the scan tool from the vehicle battery, which eliminates the need to connect a scan tool to a power source separately. However, some technicians might still connect the scan tool to an auxiliary power source to protect data in the unusual event that a vehicle experiences a loss of electrical power due to a malfunction. Finally, the OBD-II standard provides an extensible list of DTCs. As a result of this standardization, a single device can query the on-board computer(s) in any vehicle.

Wikipedia’s entire on-board diagnostics entry, which also covers a General Motors-proprietary diagnostics scheme called Assembly Line Diagnostic Link (ALDL) along with various OBD-II successors, is well worth a read. And in case you’re not aware of what the connector is that’s referred to earlier, here’s a pic:

Back in the non-standardized OBD days, diagnostics connectors were not only implemented in various shapes, sizes, and pinouts, they were also scattered in various locations around the vehicle, including under the hood. Nowadays they’re required to be within 2 feet of the steering wheel; most often they’re found underneath the dashboard.

One key benefit of such standardization (which, by the way, interestingly does NOT extend to a common signal protocol in all implementations; five options are supported. More on that in a bit…) is that manufacturers can develop data “readers” not only for repair shop use but also for average vehicle owner utilization, at minimum so consumers can get some idea of the vehicle’s status and, if they’re “wrenches”, can also tackle any necessary work themselves. That said, type “OBD-II” into the Amazon website search bar and you’ll be presented with a lengthy and otherwise bewildering list of results spanning multiple pages, for diagnostics scanners ranging in price from less than $10 to several hundred dollars. A list of their differences (albeit off the top of my head, therefore likely not comprehensive) encompasses factors such as:

How well known (or not) the equipment supplier’s “brand” is.
The breadth of vehicles (both manufacturer, model, and model years) supported.
If the scanner firmware is regularly updated both to squash bugs and support new vehicles, and if so, how (via USB connection to a computer, Bluetooth download from a mobile device, direct Wi-Fi download, etc.) and how often updates are made available.
If the scanner is simply a diagnostic data reader or if it also supports data reset or even more elaborate specific-data configuration programming.
Which vehicle system(s) are supported, and to what degree in each case: engine, transmission, brakes, steering, charging, and more general electrical, etc.
User input schemes: buttons, touchscreen, etc.
Data output schemes: LEDs, an LCD display, support for data upload to a connected computer, smartphone, tablet, etc.
Connectivity between the male OBD-II connector (and its associated circuitry) and the main reader: wired, Bluetooth, etc. Some Bluetooth-based units, in fact, offer sufficient in-connector “smarts” that the remainder of the reader consists solely of software running on a wirelessly tethered computer or mobile device!

The OBD-II scanner that I currently own (for reasons that I’ll save for another blog post another day) is an Autel AutoLink AL519, which I bought last November from an eBay retailer for $59.98:

I’ve long wondered what its (and similar products’) insides looked like. To satisfy my curiosity via this teardown project, I went with a more modestly priced (albeit still mainstream-featured) device, the THINKOBD 100 from THINKCAR Tech, which set me back only $14.94 (on sale) from Amazon when I bought it in January. Here’s a stock photo:

And a promo video:

I’ll as usual begin the dissection with a series of outer packaging shots:

The THINKOBD 100 is self-powered by the supply voltage (and current) and ground feeds originating at the female OBD-II port it’s connected to, which is pretty slick:

I love the brutally honest, albeit grammatically and otherwise somewhat convoluted, wording on the backside:

What’s Cheaper than It is not a Good as It, what’s Better than It is not as Cheap as It

Although THINKCAR TECH is US-based, the THINKOBD 100 is China-manufactured; I’m guessing that imperfect translation to English is at the root of the clumsy wording. In a similar vein, I find it curious that as also noted on the backside, the included user guides provide instructions in seven different languages…none of them Chinese. Note, too, that the fine print indicates that the unit supports all five of the aforementioned OBD-II signal protocol options.

Onward to the remaining (and comparatively boring) box sides:

And now, let’s crack open the box’s top flap:

That’s a reassuring sticker!

Here’s what’s inside, as usual accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes.

The THINKOBD 100, not including its permanently connected cable, has dimensions of 4.72 x 2.55 x 0.79 inches, and the assemblage weighs 8 ounces. Note, too, the dual user guides; one has three languages’ worth of instructions, the other four. Here are the two panels’ worth of English-language tutorial prose:

The included (a nice touch!) USB cable is used to download and install updated software to the device. It’s predictably USB-A on one end, but archaic mini-USB on the other…apparently this product has been available for sale for a while.

Here’s the male OBD-II connector at the end of the 3.2 ft permanently attached cable:

And here’s what’s left once the scanner and USB cable are removed from their white plastic packaging surroundings:

Now for our patient. That’s a 1.77 in. (diagonal) 160×128 pixel color TFT LCD on the front:

At bottom is the mini-USB connector for updates, along with an information-filled sticker:

The sides are fairly bland, although I’ll note that the textured case is easy to grip:

At top is the other end of the cable that connects to the OBD-II port:

And finally, on the back we see the four screws that point to our pathway inside:

You know what comes next, right?

The PCB pops right out of the remaining half of the case:

Let’s look first at the comparatively unexciting PCB front side:

Now for the back side, containing the bulk of the circuitry:

Here’s a closeup of the comparatively circuitry-cluttered top half:

At the very top, obviously, is the connector that the OBD-II cable plugs into, with signals subsequently routing between there and the PCB. Below and to the left of it are two 2903 low-power dual-voltage comparators (manufacturer unknown; does anyone know what company that vertical-line logo is associated with? The second mark line says “AK2SF” if that helps).

Directly below the connector is an interesting chip, the SIT1044T, from a company called Silicon Internet of Things Technology. It’s a 5 Mbps high-speed CAN (controller area network) FD (flexible data rate) transceiver; I’m sure that at least some of you already also noticed the associated “CANL” and “CANH” markings on the PCB near the connector, right? To its right is the AMS1117, a linear regulator from Advanced Monolithic Systems. And to the right of that is another regulator, the 78M05 (manufacturer unknown).

The largest (and highest pin count) IC on the board is the system “brains”, the MM32F103RBT from another Chinese semiconductor company, MindMotion. It’s a 96 MHz Arm Cortex-M3 based SoC also containing (among other things) 128 KBytes of flash memory and 20 KBytes of SRAM. And speaking of flash memory, below the application processor is more of it, 64 Mbits of SPI NOR flash memory to be exact, in the chip with markings identifying it as GigaDevice Semiconductor’s GD25Q64E. No, I don’t know what those blue and green scribbles on the latter two ICs mean, either, although they were presumably added by whoever assembled and then tested the PCB containing them!

After all that upper-half excitement, the corresponding lower half of the backside of the PCB is boring in comparison, that is unless you’re into diodes and other passives…

At this point I’ll stop disassembling, because as regular readers of my teardowns already know, I always prefer to leave my “patients” in a condition where I can later reassemble them to a fully functional state for either my or a charity donation recipient’s subsequent use. That said, I’ll keep the OBD-II scanner in pieces until after this article is published, so I can answer any “what is that” or other questions you might have. Sound off in the comments! And stay tuned for that “why is OBD-II personally relevant to me” tale to follow sooner-or-later.

—Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

<!–
googletag.cmd.push(function() { googletag.display(‘div-gpt-ad-native’); });
–>

The post Disassembling an OBD-II scanner appeared first on EDN.

Become a member

Become a member

Become a subscriber

Become a sponsor