Why Toroidal Transformers Hate Long Cables (and Kettles!) - Subwoofer Death 1.0

If you mess around with DIY audio long enough, you're eventually going to let the magic smoke out of something expensive. Recently, my trusty Intimidation SUB-15A active subwoofer decided to give up the ghost mid-session, letting out that unmistakable, gut-wrenching smell of burning electronics.

What followed was a deep dive into pulling amplifiers apart, the brutal reality of voltage drops, and figuring out how to fix the problem so you don't have to waste time or money doing the same thing.

The Autopsy: Melted Copper and Silent Assassins

I cracked open the back plate of the sub, hoping for an easy fix like a blown fuse. No such luck. Instead, I found the massive, heavy toroidal transformer completely melted. The copper wires were charred black and the whole thing looked like a total bag of spanners.

But transformers rarely just commit suicide for no reason. Usually, they melt because something else downstream has gone wrong and is pulling crazy amounts of current. The real culprit? The IRFB4227 power MOSFETs. Even though they looked absolutely pristine on the outside, they had likely failed silently, melting internally and creating a dead short to ground. The transformer tried its best to push massive current into that short, overheated, and literally roasted itself to death in the process.

Unrelated Environmental Consultancy Services: 

Flood Risk Assessment 

Lux Contour Map 

The Eureka Moment: The 50-Meter Voltage Drop

I was scratching my head as to why the MOSFETs shorted in the first place. Then I took a hard look at my power setup. I was running a 2000W peak audio rig (two 500W subs and four of my usual TPA3116 2.1 boards) over a single 50-meter, 1.5mm² extension cable. Oh, and someone occasionally switching on a 3000W kettle on the exact same circuit.

Here is the brutal math:

• Running that much current over a 50m cable (100m of total copper wire) creates about 1.33 ohms of resistance.
• During heavy bass drops, the system pulls almost 9 Amps.
• When the kettle clicks on, the total draw spikes to over 21 Amps.

That massive current draw over a thin, long cable results in a severe voltage drop. The 230V mains power from the wall was likely falling into the 190V range by the time it actually reached the gear. Not good. . .  and something I had never even considered. 

Why the Top Speakers Survived (And the Sub Didn't)

So why did my top speakers (powered by those cheap TPA3116 boards) survive just fine, while the heavy-duty subwoofer died?

The TPA3116 boards run on recycled laptop power bricks. These are Switch Mode Power Supplies (SMPS) designed to accept anywhere from 100V to 240V. When the kettle kicked on and the voltage dropped to 190V, the laptop bricks actively regulated themselves and kept pushing a perfectly stable 24V DC to the boards. They didn't even notice.

The Intimidation subwoofer, on the other hand, relied on that old-school toroidal transformer. A toroid is basically just a dumb coil of wire. When the mains voltage sagged, the internal amplifier voltage sagged right along with it. The amp was starved of power, started violently clipping the audio signal into square waves, and forced the MOSFETs to overheat until they shorted out and took the transformer down with them.

The Fix: Bodging in a TPA3255 Plate Amplifier

I could have dropped £100+ on a replacement toroidal transformer, but there was a 99% chance the shorted board would just blow the new one up instantly. Instead, I decided to abandon the burnt board entirely.

The solution? A drop-in TPA3255 Active Plate Amplifier. Here is why this £40–£50 upgrade is a much better option for a DIY mobile rig:

• Built-in SMPS: Just like the laptop bricks, this plate amp has a digital Switch Mode Power Supply. It can handle voltage sags on long cable runs and won't completely melt down if someone fancies a cup of tea.
• Perfect Power Match: It's rated for 600W at 2 ohms, or 300W at 4 ohms. Because my 15" driver is 8 ohms, it naturally scales down to deliver about 150W of clean Class D power. Perfect for keeping up with the rest of my setup without blowing anything up.
• Plug and Play: It has XLR inputs and an adjustable low-pass filter, so it’s basically ready to go out of the box.
• Lighter: Ditching the massive iron transformer makes the whole thing way easier to lug around.

All I need to do is cut a bit of plywood, do some frighteningly ugly woodwork with a jigsaw to make it fit the back of the box, and wire it straight to the speaker cone.

The Takeaway: If you are running long extension leads at DIY gigs, keep an eye on voltage drops, and maybe reconsider heavy iron transformers. Modern Class D chips and SMPS are much better at handling sketchy power. And for the love of god, plug the kettle in somewhere else!

---

More Questionable DIY from Dorky Thorpy

• Check out more of my DIY Audio and PA hacks
• Smoke and Sparks: More Electronics Autopsies
• Want to see some sketchy welding? Check out my Long Tail Cargo Bike Builds!

Why Dependencies Make or Break the OpenClaw gog Skill

The Hidden Traps of AI Automation: Why Dependencies Make or Break the OpenClaw gog Skill

Setting up an AI agent like OpenClaw to autonomously read spreadsheets, draft invoices, and send emails sounds like magic. When configured correctly, tools like the gog skill allow your agent to seamlessly integrate with Google Workspace. However, building this bridge requires a very specific stack of software dependencies and security permissions.

If you miss a single dependency or misconfigure a background environment, your AI assistant will crash before it even reads its first email. Based on real-world troubleshooting logs, here are three case studies that highlight exactly why nailing your dependencies and environment setups is critical for the gog skill.

Case Study 1: The Python Package Wall (PEP 668)

To allow OpenClaw to speak to Google services, you must install the official Google Client Libraries for Python, such as google-api-python-client and google-auth-oauthlib. This seems like a simple task until you hit the operating system's safety rails.

• The Problem: On a fresh Linux installation, the Python package manager (pip) might be entirely missing, halting the setup immediately.

• The Trap: Even after installing pip via sudo apt install python3-pip , modern Linux distributions enforce a safety feature called PEP 668. This feature actively blocks you from using pip to install packages system-wide to prevent accidental damage to core OS files.

• The Solution: You cannot simply force the installation. You must build an isolated sandbox by installing python3-venv and creating a Virtual Environment (python3 -m venv ai_env). Only inside this activated environment can you safely install the Google dependencies required by the gog skill without breaking your Linux distribution.

Case Study 2: The Locked OS Keyring and Sandboxed Agents

Authentication is the most delicate part of giving an AI access to your inbox. The gog tool relies on a refresh token to maintain a persistent connection to Google.

• The Problem: By default, the gog tool attempts to save your Google authentication token into the Linux OS Keyring (the "Secret Service"). If your server reboots, this OS Keyring locks itself.

• The Trap: When OpenClaw wakes up and tries to send an email, it hits a locked door. Because the AI agent often relies on a raw terminal sandbox (the exec tool) to run commands, it operates in a "non-interactive" environment. It physically cannot prompt you for a graphical password, resulting in a "Secret not found" or "no TTY available" error.

• The Solution: You must configure gog to bypass the OS lock by using a dedicated file-based keyring (gog auth keyring file). Furthermore, you must inject the GOG_KEYRING_PASSWORD directly into OpenClaw's private .env file. This ensures the sandboxed agent inherits the password automatically and can silently decrypt the credentials in the background without needing a terminal prompt.

Case Study 3: The "Chicken and Egg" Credentials Bug

Fixing one dependency issue can sometimes inadvertently break another, as seen when modifying the keyring architecture.

• The Problem: When you switch from the default OS Keyring to a new file-based keyring to solve the locking issue, you create a completely blank slate.

• The Trap: Because the new file keyring is entirely empty, it "forgets" the master Google Client Credentials (credentials.json) that you set up previously. If you try to run the gog auth add command to link your email, the tool trips over its own feet and fails instantly because it no longer knows how to communicate with Google's login servers.

• The Solution: You must manually feed the master credentials back into the new file keyring using the command gog auth credentials /path/to/credentials.json before attempting to authenticate the email account. Only after this dependency is linked will the tool properly generate the Google login link and save the refresh token.

The Takeaway

Building local AI agents isn't just about downloading a smart language model. The plumbing matters just as much as the brain.

Pro Tip: Always isolate your Python packages in virtual environments, thoroughly map out how your agent will access encrypted passwords in non-interactive shells, and verify your API credentials every time you alter your authentication architecture.

When your dependencies are perfectly aligned, your OpenClaw agent transforms from a frustrating troubleshooting puzzle into a seamless, highly capable automated assistant. 

Lux Contour Plans 

How Much VRAM for Local Openclaw

The VRAM Reality Check: Running OpenClaw Locally

If you are building a local AI agent using OpenClaw, there is a massive misconception in the community that you need to be aware of: Just because a model's file size is 4.9GB does not mean you can effectively run it on a 6GB graphics card. While it is technically possible to squeeze an 8-billion parameter model onto a 6GB GPU, the moment you ask your agent to do actual automated work, the system will crash. Here is the brutal hardware math behind why this happens and what you actually need.

The 6GB Illusion (Running Without Tools)

When you run a compressed (4-bit quantized) 8B model like Ministral 8B, the physical "brain" of the model takes up roughly 4.5 GB to 4.9 GB of VRAM. On a 6GB GPU, like an older Nvidia GTX 1060, this leaves about 1.1 GB to 1.5 GB of free space.

If you are running the model strictly as a basic chatbot with zero external tools, this actually works.

• By default, AI engines like Ollama cap the context window (the model's short-term memory, or "KV Cache") at 4,096 tokens for GPUs under 24GB.

• At 4,096 tokens, the KV Cache only takes up a few hundred megabytes.

• This fits perfectly inside your leftover VRAM, allowing the model to chat with you without crashing.

The Context Explosion (Why Tools Break the System)

The illusion shatters the second you try to turn your chatbot into a functional agent. When you turn on an advanced tool in OpenClaw, like the gog integration for Google Workspace, the system has to explain to the AI exactly how to use it.

OpenClaw secretly generates a massive, hidden "System Prompt" filled with JSON schemas, rules, and API instructions.

• The 5,000-Token Wall: Because you have the gog integration enabled, that hidden instruction manual is likely over 5,000 tokens long before you even type the word "hi".

• The 4k Crash: If your context window is restricted to 4,000 tokens to keep your 6GB card safe, OpenClaw realizes the 5,000-token manual won't fit in the box and instantly throws an error: "Prompt too large for the model".

• The 12k Crash: If you try to bypass this by bumping the context window up to 12,000 tokens to hold the instructions, the engine attempts to create a massive 12,000-token memory buffer inside your remaining 1.5 GB of VRAM. Your 6GB card physically runs out of memory and violently crashes.

You simply cannot run a 4.9GB model and a massive tool-calling context window simultaneously on a 6GB card.

The True Minimum VRAM for OpenClaw Agents

Agentic workflows—like scraping websites or reading heavy Google API JSON payloads—require a context window of 32,000 to 64,000 tokens to prevent the AI from "forgetting" its instructions. As the context window scales up, the KV Cache balloons in size.

Here is the actual minimum VRAM required to run an 8B model with advanced OpenClaw tools:

Component	VRAM Required
Ministral 8B Weights	4.9 GB
Runtime Overhead	~1.0 GB
KV Cache (32k - 64k Context)	2.5 GB to 5.0 GB
Total Minimum VRAM Needed	8.4 GB to 10.9 GB

The Bottom Line: To reliably run an 8B model with the massive context window required for OpenClaw's automated workflows, you need a GPU with 12GB to 16GB of VRAM. A 12GB card (like the RTX 3060) allows for a comfortable 32,000-token window, while a 16GB card (like the RTX 4060 Ti) gives you the headroom to push past 64,000 tokens.

Lighting Assessment For Bats

Downwash Analysis

BRE 365 Soakaway

Building Your First "Agent": Automating Invoices with OpenClaw

The "Display vs. Compute" Hack for Linux AI Servers

If you are building a local AI server, you quickly learn the golden rule: VRAM is everything. Large Language Models (LLMs) are massive, and every single megabyte of your graphics card memory matters. But there is a silent thief running in the background of your machine that is actively stealing that precious memory before you even load your first model: your operating system.

The actual size of the model is only part of the argument, you also need to leave room for the context window  this can be small for python based system, but massive if you intend to use openclaw. 

Here is the ultimate Linux software setup and the brilliant hardware workaround to permanently isolate your AI and maximize your VRAM.

The VRAM Thieves: Desktop Environment Choices

When you install Linux, you have to choose a Desktop Environment (DE)—the graphical interface, windows, and menus you click around in. Not all desktops are created equal, and choosing the wrong one will cripple your AI server.

• The Heavyweights (Ubuntu GNOME / KDE Plasma): Standard Ubuntu defaults to the GNOME desktop. While it is beautiful, it actively hogs hardware resources. It can easily eat up 1 to 2 GB of your system RAM just sitting idle. Worse, it frequently initializes background graphics processes that nibble away at your GPU's primary VRAM pool.

• The Budget Sweet Spot (Lubuntu / Xubuntu): These use lightweight environments like LXQt or XFCE. They use a fraction of your system RAM (often under 500 MB total) and keep their hands entirely off your GPU's VRAM. This leaves the maximum amount of hardware juice available for your AI.

• The Ultimate Business Move (Headless): A "headless" server has no visual desktop interface at all; it boots straight into a black text terminal. This guarantees 0% VRAM waste and the absolute minimum system RAM usage.

Pro Tip: If you are new to Linux, start with Lubuntu or Xubuntu. It keeps the system incredibly lightweight but still gives you a browser and file manager while you build your agent. Once your automated workflows are set, you can turn the desktop off and run it headless.

The Dual-GPU Cheat Code

If you want a physical monitor plugged into your server without sacrificing your AI's memory, you need to use a dual-GPU setup. This physically separates the "thinking" brain from the "display" brain.

By using a separate, cheap graphics card exclusively for the monitor, your desktop environment will only use the memory of that small display card. This leaves every single byte of your primary compute GPU (like your Nvidia Tesla or RTX card) strictly dedicated to your AI models.

But there is a massive Linux secret to pulling this off without crashing your system: Do not buy a cheap Nvidia card for your display; buy a cheap AMD card.

Complete Isolation: Escaping Driver Hell

Mixing two vastly different generations of Nvidia cards on a single Linux machine is a recipe for disaster. The Linux package manager will fight over whether to install the legacy drivers for the old display card or the modern proprietary drivers (like the Nvidia 535 branch) for your compute card, often breaking both.

Here is why a cheap, old AMD card (like the Radeon HD 5450) is the ultimate cheat code:

• Plug-and-Play Open Source: Linux has open-source AMD drivers baked directly into the core of the operating system. You just plug the card in, turn on the machine, and the monitor wakes up flawlessly without you having to install a single thing.

• Zero Interference: Because the AMD card uses the built-in Linux kernel drivers, it completely ignores the proprietary Nvidia drivers you install later.

• 100% VRAM Dedication: The AMD card handles all the desktop compositing, windows, and web browsers. This leaves your proprietary Nvidia drivers strictly isolated and dedicated to your compute GPU.

By offloading your lightweight Linux desktop to a £15 AMD card, you create a perfectly isolated, highly stable environment where your primary Nvidia GPU can use 100% of its VRAM exclusively for AI inference.

Lighting Assessment For Bats

Downwash Analysis

BRE 365 Soakaway