← Projects
electronics intermediate 47 min ago ◯ 5 min read

Build a DIY Continuity and Pinout Cable Tester for USB-C, Ethernet, and Custom Wiring Harnesses

Build time: A weekend (4-8 hours)
Tools needed: Soldering iron, multimeter, wire strippers, small screwdrivers, computer with Arduino IDE, drill for enclosure panel cutouts
Parts List
electronicscable testercontinuity testerusb-cethernetesp32diy tool

Every shop accumulates a drawer of unlabeled cables and a box of custom wiring harnesses built for machines, sensors, and one-off projects — and sooner or later, something stops working and the question is whether the cable is actually the problem. A commercial cable tester that covers USB-C, Ethernet, and arbitrary custom pinouts runs anywhere from $30 for a basic continuity beeper to hundreds for a full network certification tool. This project builds a tester that maps continuity and pinout across all three, using an Arduino or ESP32 to scan and report results rather than relying on a row of LEDs you have to interpret yourself.

What This Tester Actually Checks

This isn't a signal-integrity or cable-certification tool — it won't tell you a Cat6 run passes gigabit specifications or that a USB-C cable supports 100W power delivery. What it will do reliably: confirm continuity pin-for-pin across a cable or harness, catch swapped or miswired pins, detect shorts between adjacent conductors, and map an unknown or undocumented harness's pinout by testing every possible pin pair. For shop use — verifying a custom sensor harness before you plug it into an expensive controller board, or confirming a suspect Ethernet cable actually has continuity on all eight conductors — that coverage is exactly what you need most often, and it costs a fraction of a certification-grade tester.

How the Scanning Works

The core technique is the same regardless of connector type: one microcontroller GPIO drives each pin high in turn while all other pins are read as inputs with pull-downs enabled, and any pin that reads high besides the one being driven indicates continuity (or a short) between those two pins. Scanning every pin against every other pin across a full connector maps the entire cable's pinout automatically — you don't need to already know what the cable should look like, which is exactly the point when you're testing an undocumented or homemade harness.

Build Steps

  1. Wire an RJ45 jack's 8 pins to 8 GPIO-capable pins on your microcontroller (an ESP32 has plenty of spare GPIOs for this without a multiplexer).
  2. Wire a USB-C receptacle breakout board's 24 pins through two 16-channel multiplexers, with the multiplexer select lines and common output/input pin going to the microcontroller.
  3. Add a bank of pin headers for custom harness testing, wired through additional multiplexer channels or directly to spare GPIOs if you have enough.
  4. Write firmware that cycles through each connector type, driving one pin high at a time (with a brief settle delay) and reading all others, logging any pin that reads high as a detected connection back to the driven pin.
  5. Output results over serial to a connected computer, or to a small OLED display mounted in the enclosure for standalone use without a laptop nearby — useful for testing cables at a workbench that isn't near your main computer.
  6. House the multiplexers, connectors, and microcontroller in a project enclosure with the RJ45 jack, USB-C receptacle, and header block all panel-mounted and clearly labeled.

Firmware Logic

for (int drivePin = 0; drivePin < numPins; drivePin++) { setAllPinsInput_PullDown(); setPinOutput_High(drivePin); delay(2); // let the pin settle for (int readPin = 0; readPin < numPins; readPin++) { if (readPin == drivePin) continue; if (digitalRead(readPin) == HIGH) { reportConnection(drivePin, readPin); } } }

For the USB-C and custom-harness sections routed through multiplexers, the same loop structure applies — you're just setting multiplexer select lines to choose which physical pin the shared GPIO is currently connected to, rather than addressing 24 separate GPIOs directly. Keep the settle delay in place; multiplexer switching and long test leads both introduce enough capacitance that reading immediately after switching can produce false negatives on genuinely continuous connections.

Reading Results on an Undocumented Harness

When you don't know a harness's pinout going in, run the full scan and log every detected pin-to-pin connection, then compare that map against the device or connector it's meant to plug into (checking against a datasheet pinout, or against a second, known-good cable of the same type if you have one). This is the exact workflow that turns "some mystery harness in a parts drawer" into "confirmed pinout, safe to use" before you risk plugging it into a board that won't tolerate a wiring mistake gracefully — the same caution this site's guides on ESP32 GPIO wiring and PCB design already emphasize, just automated instead of done with a multimeter one pin pair at a time.

Limitations Worth Knowing

Continuity testing at DC doesn't catch every real-world cable fault: a marginal high-speed data cable can pass every continuity check here and still fail at USB 3.x or gigabit Ethernet speeds due to impedance mismatches, crosstalk, or shield issues that only show up at the actual signal frequencies involved. If you're troubleshooting a flaky high-speed connection rather than a dead one, this tester will tell you the cable isn't simply broken or miswired, but it won't rule out a signal-integrity problem — for that you're back to swapping in a known-good cable or reaching for actual certification test equipment.