Writing It Down

By Bill


I need an entrance panel for my antenna feeds. Snaking them through a partially open basement window isn’t working out so well. I look over the ready-made options and decide to design and build my own. What I come up with will work electrically but I have a problem: I have no idea how to bolt it all together.

Figuring that out involves a notebook, one 6×12 inch sheet of aluminum and a pile of lightning suppressors, all of which are on my desk, next to the keyboard. I’ve been doing this for a while; it’s a hard problem. A bigger piece of aluminum would be better but won’t fit in the space I have, the components are oddly shaped and the whole thing has to go together in a way that allows me to easily attach and route cables. Every once in a while, I re-arrange the pile, make a quick sketch and write another note.

The notebook is a product of Mr. Sivak, my junior high school science teacher. To get a passing grade, our notebooks had to formatted in a certain way and include certain stuff: the hypothesis, lab setup, initial conditions, experiment protocol, and results. There was, being high school, a lot of grumbling in the ranks. More writing? More rules? More stuff that I will never use again? Me? My resistance faded when I figured out that keeping records of my experiments enabled me to understand why things worked the way they did.

In science class, the notebook trained me to capture information in a way that made it useful. It also taught me cause-and-effect: I did this and that happened. As a vo-tech student, it cut down on the number of times I made the same mistake.

Later when I was learning electronics on a tube trainer rack made up of a pre-built plug-ins – power supplies, amplifiers, oscillators and such – I used a lab notebook to keep track of my choices. Recording what I did mattered because passing the class involved (a) developing a  design by the deadline and (b) not letting the smoke out of the same type of plug-in twice while doing so.

In the years that followed I filled a lot more notebooks. I stopped doing engineering bench work, but I kept using lab notebooks. Whatever name I used for them, the essential components – initial conditions, hypothesis, setup, protocol and results – that made up my high school lab notebook didn’t change. Whether I was building or managing or monitoring, whether it was a new product or a new company, using this format to guide my decisions simply made whatever I was doing turn out better. The notebooks of my professional career helped me develop, test and, most importantly, assess and tune good solutions to complex problems, which is what I got paid to do.

Today, I am on the eleventh arrangement of the panel. I have solved a couple of problems that I didn’t know I had when I started. I notice that the difference between the tenth and eleventh versions is pretty small, so I probably have a design that meets my goals. But if I build it and find a new problem, the next version can skip past all the designs I have already tried and rejected. The sketching and note taking added about an hour to the process. From past experience, I am certain that hour will save me from having a, “wish I had thought of that before I started drilling” moment, and rework or starting over, later.

I decide to try one more arrangement of the panel. It looks familiar. Reviewing my notes, I see it’s a repeat. But flipping one of the components around solves a spacing problem that’s stumped me until now.

Finished! I make one last sketch. Later I will use some LMR400 coax I have (my worst case scenario) to make sure my cabling assumptions are okay. Finally, I will dimension the components and make a drawing that will serve as the panel’s drilling template.

After measuring each of the components and making the drill template, I make a final parts list so I know what I need from the hardware store. It will take just an hour or two to drill the aluminum and assemble the panel. With all the arranging and sketching, I am confident that my cabling problem is solved, I’ve addressed the lightning and static charge problems, and I have a way to review my design choices if I want to make changes. Not a bad day’s work.

Why should hams bother with lab notebooks? It’s a hobby. Diplomas, promotions and stock certificates do not hang in the balance. An hour writing is an hour not devoted to making contacts. But anyone who has invested days in building an improvised piece of gear that doesn’t work or fit or last knows my answer: I suck at making things up on the fly. Every hour of designing, paper testing and documenting saves me two or four or more hours of rework later. And six months later, when I don’t remember why I made the choices I made – whether it is an antenna setup or homebrew balun or the way I configured my radio – my notebook has me covered.

Ground Bars and Bolts

By Bill

The ground bar is bolted down on the shelf. The grounding straps of tinned copper braid, between the bar and my rig, power supply and tuner, are done and installed. I am holding the last one, which will connect to the case of the filtered AC outlet box, in my hand. The filter is on the floor near the wall outlet, as planned. But it is not going to work. If I follow my original plan, the strap will be a four-foot long invitation to a ground loop. I set it on the floor and look around for my notebook.

Other design choices I made aren’t working out either. I start making a list. For example, to work behind my rig, I have to move the desk. To move the desk I have to get out a quarter-inch socket driver and unhook the copper strap that ties the ground bar to the rod outside. Inevitably I drop the bolt holding the strap and end up crawling under the desk to retrieve it. When I am done, I have to reverse the procedure. I try to skip over the dropping-the-bolt step. It is not, as they say, an optimized process. Or as I say, this is a drag, gotta fix it.

As an engineer, I learned quickly that paper designs failed in unexpected ways in the real world of voltage, screws, panels, and cable. As in what could have possibly been thinking when you designed that? Mostly, the stuff I built fails to work in small ways: screws that hard to reach, transistors pushed a little too close their specs, current requirements not quite met. I am not alone in this, for it is practically impossible to figure out beforehand how exactly the thing we are designing is going to be used until someone actually uses it.

A ground bar. A piece of gear can’t get much simpler than a copper bar with holes drilled in it, a couple of standoffs, and a fistful of 4-20 nuts, lockwashers, and bolts. Bolt the bar to the desk, secure each ground strap with a bolt, lockwasher, and nut. Easy, right? Not so much. The way I designed it, unbolting the main ground to get behind the desk is a giant hassle. The ground strap to the AC line filter is way too long for comfort. And with a single bolt, nut and washer per strap it takes two hands and two tools to work on a connection. This stuff clearly needs to be fixed. Should be easy.

My first inclination is to fix it now! But giving into this inclination almost always turns out, even in the simplest cases, to be a bad idea. Like most people, my first unvarnished solution to a problem is usually (never) my best one. It is rarely even my second or third best one. I don’t automatically trash the first thing that comes to mind, I just make it the first item in a list of possible fixes.

Bench engineers know all about engineering change orders. Even the best product designs don’t get through the design-build-ship cycle without them. ECOs are another version of my lab notebook: what is the problem, what is the fix, what does it affect, how much does it cost? An engineer that has to fill out an ECO form and get it approved by the people who have to live with the change – manufacturing, marketing, testing – is an engineer that has to think through the problem he or she is trying to solve. Whether I was the designer or the design team manager, ECOs were my antidote for the spontaneous fix.

I don’t have a marketing department and I manage all the manufacturing and testing around here. The only person that needs to sign off on what I do is me. If I end up spending a lot of time fixing the damage one of my fixes causes, I am pretty sure I know who screwed up. Since I don’t enjoy fixing my own mistakes, I’ve adopted the spirit if not the form of the engineering change order process.

In my case, I start by looking at my original design. What was I trying to do? I want to be sure I understand my original design goals. Then I make a list of the problems in the current design and I ask myself if any of the problems are a result of the original goals. If they are, and I can’t come up with a fix, I either live with the problem or I change the goal. If I start fixing stuff before this work is done I am pretty sure I am going to have another oh yeah I forgot I needed it do to this! moment sometime soon.

I start listing possible solutions once this work is done. And when the list is done, I set it aside for a bit, and on returning, try to improve the solutions. The list rarely has more than three or four choices; I just don’t have that many good ideas. A little work here and the best answer starts to stand out. Yes, I write all this stuff down. Why? Because I don’t like having the same bad idea more than once. This is my version of the ECO: a detailed lab notebook record of what I am fixing and why, without all the check boxes and signature blocks.

Sometimes I discover that I actually don’t know what to do next. When that happens, I set my list aside and go do the research I need to do. Better not to fix something than to try something, hoping things will turn out okay. Addressing the issues with the ground bar was straight forward but I decided to do a little research anyway. That research validated my ideas. I was good to go.

I worked through my fix list. The bolts are installed from the bottom of the bar with a lock washer and nut on the top side. Now they don’t need to be removed when I have to disconnect a ground strap. The ground that runs outside has a wing nut instead of a nut, so I don’t need a wrench or nut driver to take it off. I mount the AC line filter to the underside of the desk. Now its ground strap is six inches, rather than four feet, long. I can’t do much about disconnecting the outside ground every time I need to get behind the desk. That strap has to be as short as possible and unless I put the desk in the middle of the room, I will continue to need to move it to get to the back side of my gear.

After the fact, the fixes seem pretty simple and might hardly worth all the writing stuff down. Bill, that sure seems like a lot of work for a small problem. Couldn’t you just try something and see how it worked? Perhaps. But experience suggests that simple fixes are simple because they are thought through and thinking it through requires a record of what one is doing and why. Honestly? It took me longer to write about this piece about documenting the design process than it did to actually do it. That isn’t always the case. The chance of getting something wrong in a design goes up as the square (or worse) of the complexity. Building time into the process for making, testing and documenting changes at the front end saves a lot of confusion and frustration later.
I disconnect one of the ground connections to re-route it so it won’t block access to one of the antenna feeds. After I check everything against my wiring diagram, I plug gear into the new AC filter and the filter to the mains before pushing the desk back against the wall. Getting behind the rig is a lot easier than it was two hours ago, which was the goal. And three months from now when I am trying to remember why I did what I did, I have my notes. It works.