Using AI to Compare Circuit Boards: A Claude Experiment

An iterative exploration of AI-assisted PCB variance analysis using Claude

Overview

As part of my ongoing ‘mad scientist’ automotive reverse engineering/hacking work, I recently needed to compare two somewhat similar circuit board — to identify any component-level differences between them. Rather than doing this purely by eye, I decided to try leveraging Claude (Anthropic’s AI assistant) to assist with the analysis.

What followed was an iterative back-and-forth process that tested the boundaries of what AI can and can’t do well with image-based circuit board analysis. This post documents each attempt, what worked, what didn’t, and what ultimately proved most useful.

The two boards under comparison are:

  • Board 1 — Reference board, used in various General Motors (GM) vehicles to control certain interior components
  • Board 2 — Comparison board, which is also commonly used in General Motors (GM) vehicles for other interior components.

Figure 1 — Reference Board

Figure 2 — Board 2: Comparison Module (top side)

Attempt 1: Initial Board Identification & Component Inventory

The Ask

The first step was simply to see how well Claude could identify what was on the board from a single high-resolution photo. I uploaded Board 1 and asked for a general analysis.

What Claude Got Right

Claude did a solid job of identifying the major, clearly visible components:

  • Correctly identified all four TAIKO HTB2-160 12VDC relays and their 2×2 arrangement
  • Identified the large QFP main MCU (noting the conformal coating made the markings unreadable)
  • Correctly identified the two primary connectors — a white multi-pin harness connector and a smaller black blade connector
  • Noted the board manufacturer and decoded the date code (week 34, 2005)
  • Correctly assessed the board’s general condition as good with no visible damage
  • Provided some useful insight on the general uses for some of the identified components.
  • For some of the larger items that are not clearly marked, it was able to correctly infer what they were. For instance, in the upper right hand quadrant is a Motorola HC08 microcontroller, which it correctly guessed.
  • Finally, using the information on the board, it was able to give some insight as to what this board may be used for, etc.

What Needed Improvement

The initial component list significantly under-counted the number of distinct components on the board. Many smaller SMD discretes, resistor networks, and secondary ICs were either missed entirely or lumped together without individual callouts. The markup image created at this stage was too sparse — labeling only the most obvious components rather than cataloguing everything.

Figure 3 — First annotated image attempt. Captured major components but missed significant detail.

Attempt 2: Automated Pixel-Difference Comparison

The Ask

With both board images in hand, the next logical step was to ask Claude to perform a difference analysis — essentially treating the two images as raw pixel data and highlighting regions where they diverge. The goal was to quickly flag all areas of variance without manual review.

The Approach

Claude computed a per-pixel absolute difference across all RGB channels, applied Gaussian smoothing to reduce JPEG compression noise, thresholded the result, and then used connected-component labeling to identify distinct “blobs” of difference. These regions were then drawn as numbered bounding boxes on both boards in a side-by-side comparison image, and also shown as a red heat-map overlay.

Figure 4 — Heatmap overlay showing pixel-level differences (red intensity = degree of difference).

Figure 5 — Side-by-side comparison with 39 flagged difference regions.

Why It Didn’t Work

The automated approach flagged 39 distinct regions — but after manual review, the vast majority were false positives caused by:

  • Slight differences in camera angle and zoom between the two shots
  • Lighting and shadow variation across the board surface
  • The conformal coating creating different specular reflections
  • Minor parallax shifts making the same components appear in slightly different pixel positions

Of the 39 flagged regions, only 2 were actually valid differences (regions 10 & 11). More critically, Claude’s automated approach missed some obvious real differences that a human eye catches immediately — such as a resistor populated at position 3 on Board 2 that is absent on Board 1.

NOTE: This is a known limitation of naive pixel-diff approaches for real-world photos. They work well for identical imaging conditions (same camera, tripod, lighting) but fall apart with hand-held photos under variable conditions.

Attempt 3: Zone-by-Zone Manual Walkthrough

The Ask

After the automated approach proved unreliable, the decision was made to switch to a more methodical, human-guided approach. Rather than asking Claude to find differences algorithmically, the board would be divided into a systematic grid of zones, and tight side-by-side crops of each zone would be generated for manual human review.

The Grid

The board was divided into a 4-column × 3-row grid, yielding 12 zones labeled A1–A4 (top row), B1–B4 (middle row), and C1–C4 (bottom row). Each zone was exported as a side-by-side comparison image showing both boards at matched zoom levels, with a 40-pixel overlap between zones to avoid missing anything at the boundaries.

Figure 6 — Zone grid overlay showing the 12 analysis areas on Board 1.

Narrowing the Focus

After reviewing all 12 zones, most showed no material differences. Attention was focused on four zones that warranted closer scrutiny: A3, A4, B3, and B4. Tighter crops were generated for each of these at higher resolution.

Zone B3 — Mid Center-Right (Resistor Ladder / Cap Area)

This zone contained the most significant confirmed differences. The board silkscreen labels a row of resistor positions as 0, 1, 2, 3.

Figure 7 — Zone B3 focused comparison. Left: Board 1 (Good Module). Right: Board 2 (Comparison).

Confirmed difference: Board 1 has resistors populated at positions 1 and 2 only. Board 2 has resistors at positions 1, 2, and 3. Position 0 is unpopulated on both boards. The additional resistor at position 3 on Board 2 represents a deliberate configuration difference between the two modules.

Zone B4 — Mid Right

Figure 8 — Zone B4 focused comparison.

A potential difference was noted in the stacked IC pair visible in this zone. The component marking reads 2432/1003 on Board 1 versus 2432/E001 on Board 2 — the lower IC marking differs. This may represent a different component variant or could be a conformal coating / angle artifact. Worth physical verification.

The resistor ladder (positions 0–3) continues into this zone from B3, showing the same population pattern — Board 2 has a resistor at position 3 where Board 1 does not.

Zone A3 — Upper Center-Right (MCU Area Top)

Figure 9 — Zone A3 focused comparison. Both boards appear identical in this zone.

No differences identified. Component count, placement, and types all match between both boards in this zone.

Zone A4 — Upper Right (IC / MCU Area)

Figure 10 — Zone A4 focused comparison. Cosmetic difference only.

No component-level differences identified. Board 2’s main MCU has a prominent scratch through its conformal coating (visible as a white diagonal line across the IC body), but this is a cosmetic/handling mark and not a component or configuration difference.

Conclusions & Takeaways

Confirmed Differences Between the Two Boards

  • Resistor ladder positions 0–3 (Zone B3/B4): Board 1 populated at positions 1 & 2 only. Board 2 populated at positions 1, 2, & 3.
  • Stacked IC marking (Zone B4): Board 1 shows 2432/1003; Board 2 shows 2432/E001 — requires physical verification.
  • Main connector (Zone C4): Board 1 has a white connector housing; Board 2 has a red connector housing. (Functional equivalent, cosmetic difference.)
  • Date codes on relays differ: Board 1 date code 053262 vs Board 2 date code 064362 — consistent with the different board manufacturing dates.

What Worked Well

  • Claude was excellent at initial board identification — decoding silkscreen text, identifying major components, and providing context about the board’s likely function.
  • The zone-by-zone grid approach was the most productive method — generating structured, human-reviewable comparison crops that made real differences obvious.
  • Having Claude generate the comparison image infrastructure (cropping, labeling, side-by-side layout) saved significant manual work.

What Didn’t Work

  • Automated pixel-difference analysis was not reliable for hand-held photos taken under variable conditions. It produced far too many false positives while still missing real differences.
  • The initial component inventory was too conservative — Claude under-counted the number of discrete SMD components on the board.
  • Even with the zone approach, some items were missed. For example, in Zone B4 there is a resistor difference in the ladder to the lower left of the MCU

AI as a Tool, Not a Solution

The key insight from this experiment is that AI assistance works best when paired with human domain knowledge directing the process. Claude was most valuable as an infrastructure tool — handling the image processing, crop generation, and layout work — while the human provided the judgment calls about what to look at and whether a flagged difference was real or a false positive.

A fully autonomous “just find all the differences” approach failed, but a collaborative human-AI workflow where the human guides the analysis zone-by-zone proved genuinely useful for this type of PCB comparison task.

Tesla Reverse Engineering: MCU Teardown

Overview

When reverse engineering an important, and rather fun, step is disassembly. Digging into the internals of hardware & software typically provides many clues as to how you can exploit a system. If you know what technologies are being utilized, this will make it easier to understand how the product works and how to exploit it. Additionally, by knowing what key components / technologies are in use will give you a starting point for finding attack vectors. (E.g. known vulnerabilities) Additionally, in many cases, an analysis of the hardware will result in the discovery of diagnostic/debug access to the system. This is especially true for the Tesla Media Control Unit (MCU)

The MCU, which has numerous implementations, is a complex device which is critical to the operation of the Tesla vehicle. The MCU serves as the primary user interface for vehicle control/configuration, navigation, radio, entertainment, communication & coordination w/ other vehicle modules, diagnostics, and remote communication w/ Tesla HQ. Given the complexity of this unit, any/all clues to its operation will be extremely helpful in understanding how it operates. A full tear down & inventory of key components is ONE method to increase our knowledge.

The MCU consists of the key sub-assemblies:

  • Bonded Display – For most people, this is the only assembly that matters as it collects user input and provides visual feedback.
  • Amplifier Assembly – Audio amplifier module which drives speakers, etc.
  • Cellular Communications – This sub-assembly is responsible for cellular communications. Early MCUs supported 3G while newer sub-assemblies support 4G/5G.
  • Infotainment Processor – This sub-assembly provides the main processing power for the MCU. For the MCU 1, this is powered by NVidia while MCU 2 utilizes Intel Atom, and MCU 3 contains an AMD Ryzen processor.
  • Main Board – This is the largest assembly and serves as the hub for all of the other sub-assemblies.

Bonded Display

From a reverse engineering perspective, this is probably the least interesting sub-assembly. The electronics are relatively minimal and single purposed. I don’t expect there to be much value in focusing on this assembly. With that said, there is a USB port on the control board. I suspect this is probably used for pushing firmware in the factory.

Amplifier Assembly

Similar to the display, this assembly is also very single purposed and I don’t see any obvious value in focusing too much time here. A quick review of the circuit board does not find anything remarkably useful for reverse engineering purposes.

Cellular Communications

This module is far more interesting as it is responsible for remote communication, which is quite valuable. There are multiple prominently displayed components on this board of note. Additionally, you’ll see that this contains a removable SIM card. As the older modules came with “unlimited data”, perhaps you can repurpose this? ☺ It would additionally be curious to see if any data is on this card.

Infotainment Processor

The infotainment process assembly is another “high value target” as this is the primary “brains” of the MCU. In addition to the NVIDIA processor, this board contains SDRAM, e-NAND Flash Drive*, a USB Hub, Ethernet controller, and an IC flash device. In additional to the components, on the board, there are a couple of unpopulated pads. Perhaps these pads are simply for optional components or perhaps they are for diagnostic purposes. More investigation is required to determine if they are of any value.

* – Due to how the Flash Drive has been utilized by Tesla, these devices are beginning to fail in older MCU 1 vehicles. When they fail, the MCU will operate erratically eventually resulting in the “black screen of death”. There is a recall and Tesla will replace these sub-assemblies with a newer/higher capacity flash memory. If you are skilled, you can repair this yourself. ☺

Main Board

Given the size of the main board, it shouldn’t be surprising that there are many components of interest here. On this board, there are numerous communications chips: Switched gigabit Ethernet, multi-media serial links, CAN, and LIN. As I know the MCU plays “gatekeeper” for both Ethernet and CAN communications, reviewing these components for weaknesses will be a high priority.

Aside from the communication ICs, this board also contains Micro SD & SD data cards, a hidden USB port, and multiple JTAG/TI diagnostic connectors. While I’m not going to “spill the beans” (yet) on the contents of the data cards, I will say there are both very useful for reverse engineering purposes. I will point out that NEITHER card is automotive/harsh environment grade. Because of this, they will fail much sooner due to the temperature extremes in a vehicle. If either of these cards fail, you are in for a very bad time!

C:\Users\317FX6~1\AppData\Local\Temp\SNAGHTMLa00f8bd0.PNG

“Ports of Interest”

As noted in the sections above, there are some connection points of interest. The following tables is a consolidated list for reference.

Next Post: Navigation Repair

In the next installment, we’ll dig into my Navigation Issue and how the information learned during this disassembly allowed me to ultimately resolve the issue.

Tesla Reverse Engineering: Creating a Bench Setup (MCU)

Overview

After growing up surrounded by cars, I’ve grown accustomed to doing my own maintenance and repairs where possible. When I transitioned to EVs a couple years back, I expected that some repairs may require more manufacturer involvement than I was accustomed to. Unfortunately, due to Tesla being DIY Repair unfriendly, the situation was worse than I expected.

Even more unfortunate, the local service center has struggled to provide consistent quality service trapping me in between a rock and hard place. One prime example was when my 2014 Model S’ navigation stopped functioning properly. After almost nine months of back and forth & no resolution from Tesla, I decided that this would be a good opportunity to dig into the computer system to see if I could resolve the issue myself.

As I didn’t want to tear my car apart (yet) and I prefer to be comfortable while experimenting, my first order of business was to setup a test bench in my “mad scientist lair”. Having this would allow me to analyze the hardware and the physical & software interactions between the various modules used in the vehicle.

While there are numerous modules in the vehicle, my primary point of interest is the Media Control Unit. (MCU). The MCU is the main unit in the Model S and is the obvious analysis point for my navigation issue. The goal of this post will be to simply get the MCU up and running on your bench. In later posts, we’ll dive into more thoroughly analyzing it and other modules.

Step 1 – Getting Parts

In order to run the MCU on your test bench, we’re going to need a few things:

  • An MCU! As it is unlikely you will have a spare laying around, acquiring this will be first on your shopping list. Acquiring directly from Tesla isn’t realistic, so you will be relegated to acquiring a used unit:
    • eBay – For the older MCU 1 units, you should be able to find a good number of them here
    • Car-Part.com – This site links you with salvage yards across the United States, Canada, and Mexico.
    • Facebook / Social Media sites – There are multiple “Salvage / Part” groups where individuals are selling parts.


Tesla Premium MCU 1 Part No

IMPORTANT: If at all possible, try to get the cabling/connects that plug into the back of the MCU. This will make life INFINITELY easier for you. At a minimum, you would want the connectors shown below for the “Premium” MCU 1 device:

Figure 2 – Minimum Required Connectors

  • Power – The MCU will require a steady 12V source that is capable of providing ~3 Amps.
  • Soldering Iron – While not absolutely necessary, having a good soldering station will allow for a cleaner setup. I use the Hakko 936 which is a reliable entry level choice.
  • Ethernet cable – A small Ethernet cable, that you won’t mind cutting up.
  • Speaker – A small automotive speaker for connecting to the MCU to enable audio playback. This isn’t absolutely necessary, but it is a nice to have.
  • Misc. Electronic Project cables / Jumper Cables – These will be used to create the Ethernet to Tesla MCU “Fakra” cable.

Step 2 – MCU Wiring

In order to get the MCU running on our bench, there are 3 three main items that we need to wire up:

  1. MCU Power & Ground : Required to provide power to the unit so that we can interact with it.
  2. MCU Speaker : Optionally recommended so that you can hear audio chimes and/or listen to music while you work. ☺
  3. Ethernet aka Fakra connection : Require so that we can startup the unit, access OS via telnet, or execute REST API commands.

MCU Power & Ground

Wiring up the MCU for power is actually very straight forward and only requires a few positive (12V) and negative connections spread across two of the connectors. The two connectors are located on the lower portion of the MCU and are commonly referred to as X425 (Black) and X426. (Grey)

NOTE: In order to keep your wiring to the Power Supply clean, I recommend using a distribution block for + and – connections.

Close-up of necessary MCU power wiring connections.

MCU Speaker

While you can wire up as many speakers as you would like, we only need the center speaker so that we can hear alert tones, etc. This speaker is also located on the X425 (Black) connector.

The easiest way to connect the speaker to these cables is to simply strip off the ends and use alligator clips:

Ethernet aka Fakra HSD connection

While the Tesla MCU utilizes Ethernet for certain actions, it does not provide you a convenient RJ45 port. The Ethernet connections utilize a “Fakra HSD” connector.

While you can buy these cables pre-made for ~$50, you can make one relatively easily once you know how to map out the HSD pins to the Ethernet cable wire.

The HSD cable consists of 4 pins consisting of two diagonal wire pairs where D+ / D- & Vcc / GND are pairs.

While a standard Ethernet cable consists of 8 wires / 4 twisted pairs, only 2 pairs are typically needed and these two pairs will be matched up to the HSD pinout as follows:

If making your own cable, the jumper wires I recommended at the start of this blog fit perfectly into the Fakra connector. I simply soldered one end to the Ethernet cable, inserted the other into the Fakra connector, and then taped it to ensure it doesn’t come loose.

C:\Users\317FX6~1\AppData\Local\Temp\SNAGHTML20204360.PNG

Step 3 – MCU Startup

Once you have completed all of the wiring in the previous step, you are ready to start the MCU! Next, perform the following actions:

  1. Ensure that you have connected your positive and negative wires to your power supply and that the power supply is set to a 12V output voltage.
  2. Ensure that your speaker is connected.
  3. IMPORTANT: Plug the Fakra/Ethernet cable into the back of the MCU and into either a network device (Hub/Switch) or to a laptop. Even if the MCU has power, it may not fully start unless it sees network traffic. [There are other ways to force it to start, but this is the easiest]
  4. Turn on your power supply – You will notice that at first, it is drawing a relatively low amount of amps, but once it fully starts, you will see the draw increase.
  5. Verify that MCU has power – If you look at the right side of the unit, you should see multiple LED status lights. Initially some will be Yellow/Red. Some will turn green as unit boots, etc.
  6. Wait…. Wait…. Wait… It should take ~20 – 30 seconds to full boot up. If you have the speaker connected, you SHOULD hear a series of chimes around the same time the Tesla ‘T’ appears.
  7. Wait… Wait… Wait some more and then you should finally see the MCU come to life
    Congrats! You now have a functional MCU on your test bench!

EPM Automate – State Management “Public Safety Announcement”

Overview

EPM Automate is an Oracle provided command line interface which is used for interfacing with Oracle Cloud EPM applications. These applications expose REST API endpoints for consumption to accomplish a wide variety of activities. (data loading, user management, maintenance, rules execution, etc., etc., etc.) The EPM Automate utility allows users to consume the REST API endpoints without having to write writing code. This is useful for application administrators and power users who wish to perform certain activities without having to navigate the applications graphical user interface. The utility can also be utilized by automation processes to reduce technical debt/maintenance overhead since it abstracts the API details.

Using EPM Automate is relatively simple as you just download/install the utility, on a Windows or Linux system, and issues commands via the command line. Commands are issued one after another in the necessary sequence to perform a particular task. In the example below, I am connecting to an EPM Cloud application, requesting the value of a substitution variable, and then logging out of the application.

After logging into the application, you can run as many individual commands as you would like and you can leave you ‘session’ open for some time w/o having to provide authenticate again. Even though the underlying API calls are executed separately, and you are not providing credentials for each command issue, the EPM Automate utility is maintaining state behind the scenes.

While this approach is convenient for the user, it is important to understand how this is being accomplished as misuse can result in potentially serious issues! The purpose of this post is to educate you on how EPM Automate State Management behaves and how to avoid any serious issues based on its design. Additionally, I’ll provide some future update thoughts which could address the concern raised here.

State Management

State Management is accomplished through a text file called .prefs. This file contains all of the relevant information that EPM Automate requires to communicate & authenticate with the REST API. The file is created after you successfully execute a ‘login’ command in EPM Automate.

In the early releases of the utility, Oracle stated that you should not run more than one instance of this utility at the same time. While they didn’t elaborate as to why, the issue revolved around the .prefs file. While they have made updates to the application to help address the issue, there are still some gaps which could lead to undesirable consequences.

The (mostly resolved) Issue

The issue with the .prefs file occurs when you have more than one instance of EPM Automate concurrently in use on the same machine. Originally, the .prefs file was placed in a fixed folder meaning that all instances would be reading/writing the same file and the last successful login attempt by any user on the machine would overwrite the others! If those sessions were working against the same application, not a big deal; however, if the sessions were interacting with different applications, this would be bad. The best movie analogy would be Ghostbusters’ “DON’T CROSS THE STREAMS!”

Since the original version of EPM Automate, they have adjusted this logic to allow for concurrent execution by different users. To accomplish this, the .prefs file is moved under a hidden subfolder which reflects the logged on user’s information.

By keying off of the username, this ensures that separate users will not have a collision and can operate safely.

But what happens if the same user wants to be super-efficient and do work on two different Cloud EPM applications concurrently? (it will depend, based on how careful you are!)

Crossing the Streams, for Science!

To demonstrate what could happen, we will open two separate Command Windows and just jump right into issue EPM Automate commands.

Before issuing EPM Automate commands, I’ve added a global substitution variable “ServiceInstanceName” which will hold the service instance name to two FCCS applications.

After creating the substitution variables, we will connect to one application at a time and query the substitution variable to see what we get

Next, let’s do the same thing for the second server:

Now, let’s go back to the first window and query the variable again.

As you can see above, running two concurrent processes as the same user can lead to some undesirable results. While my example is simply reading a variable, imagine what would happen if you logged into a second application and triggered a wipe/reset of the 1st? Oops!

Easy Workaround

Fortunately, there is an easy workaround. Before starting your EPM Automate sessions, ensure that you are working from different folders and all will be fine since the .prefs files will be created in different locations.

Future Update Thoughts

To fully prevent this issue from impacting interactive users, EPM Automate could append the Process ID (PID) to the folder name which houses the .prefs file. This would ensure that each & every command window has a distinct folder/file.

While this would be a quick/easy fix for interactive users, this would create a potential headache for anyone who is using EPM Automate in a non-interactive manner if EPM Automate commands are being issued in separate sessions. (e.g., AutoSys, Control-M, etc.). To address this, Oracle cloud add an optional command line parameter (“prefsfile”) to allow for explicitly setting the location of the .prefs file.

Retro Computer (Compaq SLT/286) “Steak Knife” Repair

Overview

Recently, I ran across someone looking to sell an “ancient” laptop that had been long forgotten in their closet for ~30 years. The laptop in question is a Compaq SLT/286. As I’m a sucker for very clean old tech, this was right up my alley! Since it was a Compaq machine, I was especially interested as I have a few of their previous ‘portable’ machines as well.

When I inquired about the machine, the owner state that it turns on perfectly fine; however, they were not able to do much else since it doesn’t ‘boot up’. The person stated that it was a work machine that was upgraded and prompt left, in its original bag, in their closet and was only recently discovered.

When I plugged in the machine, it did start up immediately; however, I was presented with a very familiar error message:

Issue

This error message is a clear indicator that the machine had “forgotten” certain configuration settings. In older computers, these Basic Input / Output Services (BIOS) settings are stored in a Complementary Metal-Oxide-Semiconductor. (aka CMOS) The CMOS requires a small amount of power to retain its memory. The earliest PCs typically had a small battery attached to the motherboard which would provide this power. Unfortunately, batteries do not last forever and will fail. In a best case scenario, the battery simply fails to produce enough power while in worst case scenarios, the battery loses integrity and acid can damage the motherboard.

Worst Case Example: Compaq Portable II w/ catastrophically failed battery

Fortunately, this Compaq model did not use a battery that could fail in such a manner and the motherboard was clean as a whistle. (see all the disassembly pics at the end to see just how clean this machine is!)

A quick scan of the motherboard also reveals that there isn’t a battery per se. For this computer, Compaq chose to use a Dallas Real Time Chip (RTC) module which stores the relevant information. This device, which is still used to this day in certain applications, performs multiple activities: “nonvolatile” RAM memory, supports certain Read Only Memory (ROM) operations, and Real-Time Clock (RTC) operations. The one “gotcha” to this device is that the RAM is non-volatile only because there is a battery hidden inside the module which provides power to the device. Once this internal battery is depleted, it is no longer a nonvolatile RAM device.

The image on the left is the module found on this Compaq’s motherboard. The ‘8849’ is the build date for the module which corresponds to the 49th week of 1988! The image on the right is an X-Ray of this type of module. The power source is the circular item near the middle of the module. (X-Ray image courtesy of https://ardent-tool.com/)

CMOS Repair

In order to get this PC up and running, we will need to address this failed module. There are a few options:

  • Replace the Dallas RTC module with a newer one
  • Carefully modify the existing Dallas module to power it from an external source

As with any repair, there are always trade-offs to consider. In this scenario, I chose to supply external power to the existing module for the following reasons:

  • The existing module is directly soldered to the motherboard. This would require me to desolder the existing module and then solder a new one to the board. While this is not overly difficult, it requires a bit more effort and care than the other option. (If Compaq had placed the module in a socket, I would have opted to replace the module)
  • Many suppliers of compatible Dallas RTC modules are selling “New Old Stock” (NOS) components. Because of this, the batteries may only last for a few years before requiring replacement again.
  • Accessing the module requires a complete disassembly of the unit. (disassembly pictures are in a later section)
    • If I’m going to have to replace a battery again, I’m strongly prefer to *NOT* have to disassemble the unit
    • NOTE: As you’ll see later, my repair allows for a 60 second battery replacement and requires no tools.
  • This approach is relatively low risk. If I make a mistake accessing the internal battery, I can always resort to replacing the module. If someone else acquires this machine and would rather replace the module, they can still do this.

The following steps were performed to implement the external battery solution:

  1. Carefully remove the top layers of the Dallas module’s epoxy to expose the battery
  2. Disconnect the battery from the module pins
  3. Solder new leads to the power pins
  4. Route wires to a convenient location
  5. Solder coin battery holder to other end of leads, add battery, and verify power

Module Modification

If you’ve read this far, you are probably wondering: “Why did Charles mention he used a steak knife to effect this repair”? If so, you don’t have to look any further! To cut into the module, I choose to use a nice and sharp steak knife! While a Dremel would have been more surgical, it was in the garage and I didn’t feel like trekking into the cold to fetch it. As the epoxy/resin material is relatively soft, I had no trouble using a knife to accomplish this task. Once the battery was exposed, a small wire cutter was used to disconnect the existing battery. Next I prepped some wires, soldered them to the appropriate pin outs, and sealed it with my glue gun. (Yes, I could definitely have made this cleaned, but I wanted to make sure it was working first…)

Wire Routing & External Battery

I gave myself plenty of extra wire so that I could route it to a spot where it wouldn’t impact the operation of the laptop *and* it could be easily accessible.

(Look how clean this unit is! Amazing)

I then put together the coin battery holder and verified that I was getting proper voltage.

Next, I soldered the coin battery holder to the module wires. (Always use heatshrink!)

Finally, I wrapped the holder in electrical tape and tucked this into the access port on the side of the laptop. This convenient location will allow a battery swap in seconds without the need for any tools. If I add the optional model, I will need to relocate this; however, it is a perfect location for now.

With the machine physically repaired, the only thing left to do is create the Compaq Diagnostic Disk and reconfigure the device.

Software Reconfiguration

After scouring the internet, I was able to locate the appropriate software and used it in yet another retro machine to create the necessary software:

I insert this newly created disk into the Compaq, turned it on, and the configuration utility started. The utility seemingly auto-detected everything auto-magically.

After saving the configuration, the machine started up w/o any error messages!

It Lives!

After exiting the configuration utility, the computer sprang to life and I was greeted with a DOS prompt. Looking around on this machine, I found some pretty standard late 1980’s business programs. Quite a trip down memory lane.

1-2-3

WordPerfect

PFS Write

Bonus Pics

Below are disassembly and other pictures that didn’t make the cut up above. Take a look at how clean this machine is. Amazing for the age. Also, if you made it this far, there is a hint for my next post. Something else running on that workbench is a bit out of place….. If you recognize it, feel free to point it out and take a guess what we’ll be doing with it!

Compaq Portable Family

The largest machine is only a couple years old. Amazing at how much they shrunk down the electronics! Another post is going to dig into that machine and you will be able to see the difference!

Disassembly

 

H:\4TB-Share\RetroComputers\Compaq SLT 286\20220402_165711.jpg