Manufacturing Automation · Working prototype
Universal Cable Tester
A configurable production-floor tester for continuity, pin mapping, intentional opens, branched cables, Ethernet, and generator/stator harnesses.

Problem
Production cable verification had become a repetitive pin-by-pin task. A simple continuity beep was not enough: some harnesses included intentional opens, branches, Ethernet mappings, or specialized generator and stator connections.
Description
What I built or investigated
I built a profile-driven test fixture around an Arduino Uno, four CD74HC4067 multiplexers, an OLED, and purpose-built connectors. The tester drives one conductor at a time, senses the far side, compares the measured map with the selected profile, and reports opens, crosses, unexpected connections, or a pass.
Iterations
The work did not happen in one jump.
- 01
Started with direct one-to-one DB9 testing and a minimal menu.
- 02
Expanded the channel plan to cover DB9, RJ45, generator sense points, spring terminals, and stator posts.
- 03
Added profiles for intentional opens and branched Y-cables instead of treating every unconnected pin as a fault.
- 04
Removed duplicate Ethernet profiles after confirming that continuity sees pin numbers, not T568A/T568B colors.
- 05
Reworked physical channel mappings after real fixture wiring exposed assumptions that were correct in code but wrong at the connector.
- 06
Reduced flash use on the ATmega328P and simplified navigation so the full feature set fit on an Uno.
Result
Where the project landed
A working production-floor prototype that guides connector setup, tests the selected cable profile, and reports specific opens, wrong destinations, and shorts instead of reducing every defect to a continuity beep.
Lessons
What carried forward
- The fixture, connector labeling, and operator flow matter as much as the scan algorithm.
- Expected opens must be modeled explicitly or a correct cable looks defective.
- A profile database is more scalable than writing separate test logic for every cable.
- Public documentation should show the architecture without exposing employer pinouts or proprietary harness names.
- Specific fault reporting is what turns a tester into a useful production tool.
Employer names, proprietary identifiers, exact pinouts, and confidential production details are intentionally omitted.
Images & evidence
Work in context
Documentation status
This is a living case study. New photos, measurements, diagrams, source files, and exact outcomes can be added without changing the permanent project URL.
Continue exploring
Every catalog entry has a permanent page.
Use the archive to move between embedded systems, software, research, fabrication, networking, manufacturing tools, and field repairs.