Motorcycle Wiring Looms Suck: Ideas for improvements

Lets look at something a little different: considerations when designing a motorcycle wiring harness/loom. I’m quite ashamed to admit that this is something I’ve spent a surprising amount of time thinking (and scribbling.) about - but having spent far too much time troubleshooting a spider’s web of wiring, I’ve wanted to distill a few thoughts on the topic as I aim to build my own.

Originally this post was intended to be a notepad of technical points - a la “this is how we calculate wire gauge” - but in actual fact it’s a mixture of rants and ideas. Beware though: I’m likely coming at this from the point of view as a software engineer: so excuse the overuse of (a) the word “system”, (b) cringey analogies to debugging software, and (c) any overall cluelessness!

Observation: Over-complication Sucks.#

Looking at Haynes manuals and wiring diagrams online, it looks as though a lot of manufacturers have a base wiring design that is amended through different models and their various iterations… and considering that manufacturers are businesses, you can’t blame them for keeping internal processes simple and minimising design time.

Alas, this is a recipe for convulation… not to mention some interesting problems; where seemingly unrelated components lead to open circuits affecting entirely different systems. Not cool.

Idea One: Modular Wiring#

Enter the concept of a modular harness: with modules being grouped around either the placement of the components on the chassis - i.e. a “switchgear module” routed to the handlebar, a “rear lighting module” module routed to the tail indicator and brake lights - or the functionality of a set of components - i.e a “lighting module”, or an “engine control module”.

This in itself poses a few issues though: namely (a) routing by proximity means that there’s still an overlap of unrelated components affecting eachother, whilst (b) routing by functionality causes actual design issues, and may introduce additional wiring that wouldn’t otherwise be needed - increasing costs and the effort required for effective cable management. So this is definitely one for the drawing board…1

Observation: Troubleshooting sucks.#

Troubleshooting wiring is like troubleshooting code, with the primary difference that a multimeter and a wiring diagram replaces the obligatory printf calls and debugger breakpoints. The process as a whole is actually surprisingly similar though: tracing the movement and flow within a system, whereby the flow of execution in a circuit is the current, and code paths are circuit branches.

Alas, this leads to the point where you - whether you want to admit it or not! - may find yourself removing small amounts of insulation so as to apply the test leads of a multimeter to the underlying conductor. Applying some electrical tape over the resulting hole - in addition to a good ol’ “out of sight, out of mind” mindset - is usually enough enough of a post-troubleshooting tidy up.

Idea Two: Specific Test Points and Distribution#

Building on the idea of a modular wiring loom, at the core of the system there would need to be some form of distribution unit; a place for the modules to interact with eachother. At it’s simplest this unit could simply be something akin to a terminal block housed in an IP rated enclosure, whilst a more elaborate design may utilise automotive connectors, and include things like inline fuses or status LEDs.

Opting to have distribution managed centrally also provides a convenient way for isolating parts of the system for troubleshooting and diagnostics. Providing a convenient centralised point to test continuity and probe the status of circuit.2

Note: Mechanical Protection and Electrical Reliability#

Some things are a given: wire sizing/gauge must be calculated with load and voltage drop in mind, solid core wire isn’t suitable when compared to stranded, and ideally wiring should be afforded some form of protection from the elements.

Wiring is often wrapped with “cloth tape” to provide some protection; it’s easy to use, is resilient, and can be removed by cutting/unpeeling. And honestly, as much as I’d like to say “it makes the wires sticky and horrible - and replacing damaged wires becomes a pain”… it does work pretty well.

Whilst much of the mechanical protection needs to be focused around splices and connections and - in software development parlance - that’s “implementation specific”; various connectors and splicing/terminal options are available. Some may require more protection than others.

One of the biggest issues is actually the wiring quality of third party lighting and other devices; having ordered some via Amazon for testing/tinkering, wire quality is often poor and of an inappropriate diameter3 - even when the overall build quality seems solid.

It’s pointless having a kick-ass wiring loom if it’s powering peripherals with sub-par connections, or ones prone to burning out. Sadly this isn’t something that is covered by the wiring harness/loom itself, but is a considering when overhauling the electrics nonetheless!

  1. The current “drawing board plan” revolves around adopting a proximity based architecture for the seperation of modules; having a 12V backbone running to the modules, and - where required - additional control wires that can be “mapped” at a centralised controlling/distribution unit. Theoretically this shouldn’t introduce more cabling requirements, keeps all cables following set routes, and also provides more options for troubleshooting. ↩︎

  2. I envision the actual build of a controller/distribution unit to be an IP rated enclosure, mounted in a secondary enclosure - built with sheet metal - also housing the battery; but I’ve yet to mock anything up in FreeCAD or do any real measurements yet. ↩︎

  3. This is something I’d like to actually post about, or do a video rundown over, as I see a lot of people on Amazon reviews simply throwing various lights on their bikes and then leaving them; when some of the design flaws (easily mitigated flaws at that) provoke questions over safety/reliability. ↩︎