This page brings together the full cornucopia of farm automation projects I have built and shared from our farmstead. Irrigation systems, environmental sensing, weather stations, power management, chicken coop automation, and everything in between.

If you are thinking of building this stuff yourself and want to avoid the usual LLM hallucinations, dig through these articles. You will find details on the hardware and software I have actually built, along with the good, the bad, and the ugly behind the design decisions that got me there.

Setting up the Farm

• This is My Dirt
  20-May-24 — The Farmsteading Adventure Begins.

• Be Water, My Friend
  01-May-24 — Our first irrigation project at Stella Porta.

Raspberry Pi Farm Irrigation System

1. Farm automation made easy as Pi
   01-May-25 — Setting up the foundation for real-world IoT on the farm.

2. Controlling the Irrigation Valves
   01-May-25 — The basics of switching solenoids, safely and reliably.

3. Reading from the 1-Wire Sensors
   06-May-25 — Building the temperature sensing layer.

4. Using the I2C Protocol to Communicate to Sensors
   07-May-25 — How we wired it, read it, and filtered out the crap.

5. Reading Environmental Data with I2C
   09-May-25 — Expanding the sensor net and interpreting the data.

6. Raindrops Keep Falling On My Head
   26-May-25 — Detecting precipitation (and making decisions from it).

7. More I/O
   30-May-25 — Handling expansion and GPIO overload.

8. Getting the Data and Controlling the Devices from the REST API
   01-Jun-25 — Talking to your Pi from across the network.

9. Writing Your Own Device Plug-ins
   03-Jun-25 — Custom code to extend your system’s reach.

10. Using Software Devices to Build on the Hardware
    06-Jun-25 — Simulated devices and logic layers.

11. How to Make Things Happen Automatically
    07-Jun-25 — Trigger-based actions and logic chains.

12. Time Has Come Today
    12-Jun-25 — Scheduled tasks and automation routines.

13. There Are Always Conditions to Evaluate
    13-Jun-25 — Conditional logic for smarter systems.

14. Rolling My Own I²C and 1-Wire Interface Card
    21-Jun-25 — A custom hardware solution for real-world reliability.

15. Recording and Accessing Environmental Data Remotely
    01-Jul-25 — Logging and remote access to your system’s mind.

16. Preventing Injection Attacks to the Database
    07-Jul-25 — Keeping bad guys out of your Pi.

17. PWM: A Better Way to Control Sprinkler Valves
    21-Jul-25 — Fine-tuned voltage control for water flow.

18. Not Another Sprinkler Valve Article; TLDR

    2-Sep-25 — The elevator pitch

19. Smart Power Switch and Shutdown for Raspberry Pi
    05-Oct-25 - Battery Backup and controlled shutdown.

20. Why the Raspberry Pi GPIO API is broken and how to fix it
    11-Nov-25 - How a quiet change in Linux and libgpiod boned developers

21. Chasing Raspberry Pi Power Management
    26-Jan-26 — Lessons Learned Building a Power Switch with Deep Sleep and Wake Control

General stuff

• How did you make that?

  23-Jan-26 — What actually happens between an idea and a working circuit board

• Interview with Raspberry Pint
  30-Sep-25 - Building resilient systems that don’t need the cloud

• Using a Raspberry Pi to measure the cistern level

  14-Nov-21 — A better way to calculate water level

Weather Station

• Building a Dedicated Weather Station Display

  18-Dec-25 — Built a rock-solid, minimalist Raspberry Pi kiosk weather display

• Build Your Own Off-Grid Weather Station

  11-Dec-25 — A Raspberry Pi and SDR system for collecting local weather data without relying on anyone’s cloud.

• Here comes the Sun
  06-Mar-26 — How My Chicken Coop Controller Calculates Sunrise and Sunset

Chicken Coop Automation

• A Better Automatic Chicken Coop Door
  05-Mar-26 — From Backyard Chickens to 100-Bird Pasture Rotation

• Chicken Coop Door, Installed and Running

  26-Mar-26 — Video, installation photos, and command-line setup from the finished coop door controller

• The Humble Actuator

  11-Oct-25 — I2C-Based Linear Actuator Driver with Current Monitor

• Chicken Coop with Raspberry Pi

  27-Jan-22 — Version 2 of the coop controller

• Chicken Coop with Arduino platform

  17-Dec-20 — My first coop controller

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. It is not always electronics. Believe it or not, I have been known to jump from baking to perfume to motorcycles without much warning.

Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

I have since finished the prototyping in the shop and installed the controller in the mobile coop. What follows are a few photos of the finished installation, a short video of the door in operation, and some command-line setup and log output from the actual system.

Installing the Assembly

I built the whole assembly on a sheet of 23/32-inch AdvanTech so the aluminum guide rails would stay aligned. Once it was dialed in, mounting it to the coop wall was just a matter of driving a bunch of screws, and cutting a hole for the door.

One other small detail: I used a short piece of chain between the actuator and the door, basically like a toilet flapper chain. That gives the linkage a little slack, which helps keep the door from driving hard against anything underneath it, including an unlucky chicken.

I also built a separate battery box for the power system. It houses the 12-volt battery, a solar charge controller, fuse protection, and the rest of the power wiring in one place. I mounted it outside the coop to make it easier to service and to avoid kneeling around in chicken droppings every time I needed to check or adjust something.

For the charge controller, I used a Renogy Voyager. It is a small PWM unit with a simple display and basic charge management. It is a bit of overkill for this job. It is reliable, straightforward to wire, and stupid easy to set up.

The smaller Wanderer would probably have been a better fit, but I happened to have a few Voyagers sitting around the shop, so one of them went into the battery box.

For the panel, I used an ACOPOWER 30-watt monocrystalline solar panel. The load is low enough that 30 watts is more than plenty for this system.

I also mounted the coop door button and LED combo outside in a weatherproof box with a latching cover. That way, if some Wile E. Coyote type comes snooping around after hours, he has to solve at least one extra puzzle before getting access to the chicken banquet. I was prepared to go further with the predator defense plan, but I needed my anvil.

The Door in Operation

Here is a short video of the coop door in operation after installation. Note the locking solenoid engaging after the door closes.

Programming the Coop

In the earlier article, I mentioned that I added a socket for an optional SparkFun DEV-15096 USB-to-serial module. That gives the controller a simple setup console without needing a display, keypad, or any other nonsense bolted onto the box.

To configure it, I first made sure the CONFIG/RUN switch was set to CONFIG and hit reset. Then I plugged a USB cable from the module into my laptop and connected with:

screen /dev/ttyUSB0 38400

That dropped me straight into the console. On first reset, the controller came up with default settings and complained, correctly, that the time and configuration had not been saved yet:

Chicken Coop Controller 2.9.0
WARNING: CONFIG INVALID, USING DEFAULTS
TIME: NOT SET
Use: set date YYYY-MM-DD
     set time HH:MM:SS AM|PM

The first thing I did was set the clock. The easy way is to set the date first, then type in the next minute mark while watching a real clock and hit Return about a second before it rolls over.

> set date 2026-03-26
OK
> set time 16:20:50
OK

Then I verified that the RTC had taken the new time and was reporting sane values. In this case, it showed the clock as valid and confirmed that the time had been set just a few seconds earlier:

> rtc
RTC      : VALID
utc      : 2026-03-26 21:21:12
local    : 2026-03-26 04:21:12 PM
epoch    : 1774560072
since_set: 22 sec (0 days 00:00:22)

After that, I set the rest of the configuration, including latitude, longitude, time zone, DST handling, and the door and lock timing values, then saved it to EEPROM:

> save
OK
>  config
CONFIG (SAVED)

lat  : 34.4653
lon  : -93.3628
tz   : -6
dst  : ON (US rules)
rtc_set_epoch : 1774560050
door_travel_ms : 10000
door_settle_ms : 2000
lock_pulse_ms  : 500
lock_settle_ms : 500

A quick way to verify that the location, time zone, and DST settings are correct is to check the calculated sunrise and sunset times:

> solar
           Rise        Set
Actual     07:09 AM    07:30 PM
Civil      06:44 AM    07:55 PM

If you forget the commands, you can always prompt the system for help:

> help
Commands:
  help      Show help
  version   Show firmware version
  time      Show current date/time
  schedule  Show schedule
  solar     Show sunrise/sunset times
  set       Configure settings
  config    Show configuration
  save      Commit settings
  device    Show or set device state
  door      Manually control door
  lock      Manually control lock
  event     Event commands
  led       Control door LED
  rtc       Show raw RTC state
  sleep     Sleep til next scheduled event   

Build Your Own

Like all of my projects, this one is already up on GitHub, including the firmware, schematics, and PCB layout.

The firmware is released under the MIT License, and the hardware design files are published under the CERN-OHL-P v2 open hardware license, so anyone can study it, modify it, and build their own.

If you build one, drop a photo in the comments. I’d enjoy seeing how it ends up in somebody else’s coop.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. It is not always electronics. Believe it or not, I have been known to jump from baking to perfume to motorcycles without much warning.

Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

If you got a $10 head, buy a $10 helmet.

One of the things about Arkansas is the lax… or rather, lack of helmet laws, and the people who insist on riding without them. I guess that’s their call. Me, I like my head, and I’ve done enough time in EMS to know that even a minor crash without a full-face helmet usually doesn’t end well.

But it’s more than just a safety thing. It’s about comfort, too. Even a speck of dirt, or in my case a bird, at 60+ mph will get your attention. Not to mention the hearing loss from wind noise.

This time around, I wanted a full-face helmet with an integrated sun visor, like you’d find on a fighter pilot’s helmet. I got tired of screwing around with sunglasses, especially riding into a low-angle sunset. Tinted visors are fine until it gets dark, which is exactly when you don’t want one on a country road.

That narrowed things down to just a handful of options. Only a few manufacturers make them that I trust to protect my brain housing group. It’s a short list.

I ended up with the Shoei GT-Air 3. You get what you pay for with helmets. I’ve always leaned toward Shoei. They put serious effort into engineering their helmets, and I’ve seen firsthand how well they perform on the track.

Shoei got a lot of things right. Ventilation and the chinstrap are both done properly, and the helmet feels solid. At about 3.8 pounds, it doesn’t feel heavy at all. I also like that their website offers plenty of accessories and replacement parts, so you can set the helmet up the way you want.

Pro-Tip: You can spend a lot more on custom paint schemes. I’m not trying to look like I belong at Laguna Seca. I bought the basic model.

One thing I didn’t expect, or even know about, was the Pinlock® system. It’s a secondary inner lens that mounts inside the face shield and creates a sealed air gap, which keeps it from fogging up. If you’ve ever ridden in cold or wet conditions, you know how fast a visor can turn useless. This one doesn’t.

I’ve seen similar setups on snowmobile helmets for years, but never on motorcycles.

The helmet came with the insert. Easy-peasy to install, and once it’s in, it just works. No sprays, no wiping with your glove, no screwing around.

And that’s exactly the kind of thing that makes this helmet not suck.

Back Road Equipment Slider Rear Rack

One of the problems with riding motorcycles is that you need a way to carry stuff. In spite of what they say about the KLR650, “that you can fix most things with a rock,” you still need to carry tools, not to mention first aid gear and maybe a rain suit.

The stock rear plate was absolutely useless for attaching a bungee cargo net, and I wasn’t about to spend a lot on Kawasaki’s side cases. By the time you’re done, you’re into it for real money. So I looked for something simpler.

Luckily, the folks at Back Road Equipment had a much better solution. They make a slider rear rack system that solves the problem without overcomplicating it. It’s a pretty cool design, if you ask me. You can secure a Pelican case to it, lock it in place, and still remove it easily when you need to.

The best part is that it costs just a little over $150, and you don’t have to dish out big bucks for a Pelican box. A $40 Harbor Freight clone works just fine, and you can always step up to a larger one if you need to.

One more thing about the Harbor Freight case. I don’t know who thought it was a good idea to plaster it with that many stickers and labels (Dante probably had a special circle set aside just for them), but I spent over an hour with solvents getting them off.

Installation is straightforward. Drill four holes in the case, install the slider pucks, and don’t forget a little silicone to keep it watertight.

You might find that after removing the Kawasaki stock rear plate, a set of alignment drifts comes in handy for aligning the slider plate.

One more thing before I move on: Back Road Equipment’s customer service was great. The owner called me, helped straighten out my order, and shared a few installation and usage tips.

How about a Light Switch That Doesn’t Suck

When I bought the bike, I got a great deal on Kawasaki’s LED auxiliary lights. The lights themselves are reasonable (did I say I got a good deal). The stock switch on the dash, however, is an unbelievably bad user experience. They stuck it up on the cowling next to the gauges, where it’s awkward and flat-out unsafe to reach.

I don’t know what Kawasaki was thinking. This doesn’t feel like something the core engineers would sign off on. More likely some regulatory requirement turned it into a piss-poor design.

So I did what I always do. I got out my tools and modified it to make it work right.

A much better place for the switch is right next to the light and horn controls on the left handlebar, where your thumb can hit it without taking your hand off the grip.

After a few minutes of digging around online, I found exactly what I needed, a simple handlebar-mounted switch. It was even illuminated.

This would have been a five-minute job with some hand tools and a soldering iron, if it weren’t for the wonky way Kawasaki mounted their switch. I had to remove a good chunk of the cowling just to get to the screws they hid behind the switch assembly. But I persevered, and after a few knuckle scrapes, Kawi’s design was just a faded memory.

Make It Your Own

Half the fun of owning a motorcycle is making it your own and setting it up the way you like. That’s how you end up with something that’s actually yours.

Mine just happens to have a pissed-off bunny sticker on it. But that’s me.

As I say in each of these pieces, there are no sponsorships here. Don’t ask for one. No affiliate links. No favors. I’m pretty sure most of these companies have never heard of me, and that’s fine. I’m writing about these parts because they earned their place in my shop by working, not because anyone asked or paid for it.

If you like building things, and sometime doing a better job than the manufacturer, you’ll probably like the rest of what I write. Sharing it helps real people find the work. The algorithm can go take a hike.

I had a guest visit the other day, and I asked what their preference for dessert might be. They suggested strawberry rhubarb pie. Unfortunately, rhubarb was out of season, so that idea was off the table.

Instead, I went with what I had on hand and put together a Fresh Strawberry Custard Pie. It turned out to be a real hit and didn’t leave much in the way of leftovers.

The combination of a simple butter crust, vanilla custard, and fresh strawberries worked beautifully. Most of my recipes are improvisation anyhow.

I’m sharing the recipe here partly because friends asked for it, and partly so I have it written down somewhere sensible. I’ve learned that if I don’t write it down, it’s lost forever.

So this is both a recipe and a small act of documentation for future me.

Pie Crust Ingredients

This is a derivative of the crust I used in my Apple Pie project.

One thing I did change this time was the flour. For this batch I used flour made from Azure Market Organic Soft White Wheat Berries.

We picked up a grain mill from Amazon a while back and started grinding and sifting our own flour. Fresh-milled flour behaves and tastes a little different than store-bought flour. It has a slightly nutty flavor and a bit more character. After grinding, we sift the flour to remove some of the coarser bran so the crust stays light rather than heavy.

You can substitute Bob’s Red Mill Organic Unbleached White All Purpose Flour if you don’t want to go through the process of grinding and sifting your own flour.

• 2 1/2 cups, organic ground white flour

• 1 cup, Rumiano organic unsalted butter

• 1/2 teaspoon, Sea Salt

• 1 tablespoon, Granulated sugar

• 5–6 tablespoons ice water

Cut the butter into small ⅜" cubes using a pastry cutter. Combine the flour, sugar, salt, and butter in a bowl and work it together with the pastry cutter until the butter is broken into small pieces.

Avoid the food processor if you can. It works, but using a pastry cutter is just as effective and a lot easier to clean up afterward.

Add the ice water a tablespoon at a time, mixing gently with a fork or pastry cutter.

What you’re aiming for is a coarse, crumbly mixture with little pea-sized bits of butter coated in flour. That texture is what produces a tender crust.

If the dough starts looking smooth or pasty, you’ve gone too far and overworked it. The goal is for the dough to just come together, not turn into a uniform paste.

Occasionally I’ll put the mixture in the refrigerator or freezer for a few minutes to keep the butter cold before continuing. Keeping the butter firm helps the crust bake up tender and flaky.

When you are ready, put some flour down on your work surface and roll the dough out just thick enough to line the pie tin. At that point I put the prepared pie tin into a large Ziploc bag and placed it in the refrigerator until I finished preparing the custard.

Blind Bake the Crust

The crust was blind baked. I lined it with parchment and filled it with “pie weights,” in my case a jar of old black beans. The point is to weigh the dough down so it doesn’t bubble or shrink while the fat melts and the structure sets.

1. Roll the dough and line the pie tin with the crust.

2. Cover with parchment + pie weights or beans

3. Preheat to 350°F

4. Bake 20 minutes at 350°F

5. Remove the weights and parchment

6. Bake again uncovered 10–15 minutes more

7. optional - beat one egg white and brush a thin layer on the hot crust

8. Put it back in the oven 2 minutes

9. Let the shell cool 20–30 minutes before adding custard.

Prepare the custard

For the custard I used the same formula from my Fruit Tart project.

• 3 tablespoons flour

• 2 tablespoons arrowroot

• ½ cup granulated sugar

• ¼ teaspoon sea salt

• 2 eggs (fresh from my chickens)

• 2 cups pasteurized milk

• 1 tablespoon unsalted butter

• 1 vanilla bean, split and scraped

• Zest of one lemon and one orange, with a little juice from each

• A small amount of gelatin, bloomed and added later for extra set

1. In a medium bowl I whisked together the flour, arrowroot, sugar, salt, and eggs until it looked smooth and lump-free.

2. In a saucepan I heated the milk and butter with the lemon and orange zest and the scraped-out vanilla bean (pod and all) just until it was steaming but not boiling.

3. Temper the eggs. I slowly drizzled a ladle of the hot milk into the egg mixture while whisking like mad. The goal is to bring the eggs up to temp gently so they don’t scramble later.

4. Then I poured the warmed egg mix back into the saucepan with the rest of the hot milk, still whisking. This is also a good time to fish out the vanilla pod.

5. I cooked it over medium heat, stirring constantly, until it thickened enough to coat the back of a spoon, about 170 to 175 °F if you check. Don’t let it boil hard or you’ll destroy it.

6. Turn off the heat.

7. For extra insurance, I bloomed a little gelatin in cold water, then stirred it into the hot custard until fully melted.

8. I scooped the custard into a glass bowl and pressed plastic wrap directly onto the surface to keep a skin from forming. Let it cool on the counter for a while, then place it in the refrigerator for 1–2 hours until it is cool to the touch and fully set, roughly below 70 °F, before filling the pie.

Assemble the Pie

Once the custard is fully chilled and the pie shell has cooled, it’s time to assemble the pie. Spoon the custard into the baked pie shell and spread it evenly with a spatula. The filling should be thick enough to hold its shape but still spread smoothly.

Level the surface and return the pie to the refrigerator for about 20–30 minutes to firm up slightly. This helps keep the strawberries from sinking when you arrange them.

Once the custard is set, the pie is ready to decorate with fresh strawberries. I sliced the tops off, cut the berries vertically, and arranged them in circular layers, working from the outside toward the center.

That’s all there is to it. A simple crust, a straightforward custard, and a pile of fresh strawberries arranged on top.

It started as a substitute for strawberry rhubarb pie, but it turned out to be a pretty good dessert on its own. Sometimes cooking works that way. You aim for one thing, and circumstance pushes you somewhere else.

The result was good enough that it’s worth writing down so I can make it again without reinventing it. And if someone else happens to try it and enjoy it too, all the better.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. Sometimes I even write about things that are yummy.

Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

For most of human history those smells were simply part of being alive. They whispered things about health, attraction, and who you were. Long before science began talking about pheromones, people were already responding to those signals without realizing it.

Perfumers understood this long before they understood the chemistry. Classic perfumes were built to cooperate with the body rather than fight it. Ingredients like musk, civet, leather, and oakmoss produced warm, slightly animalic notes that echoed the chemistry of human skin. They mingled with the wearer’s natural scent and deepened it. A good perfume didn’t erase the body. It amplified it.

And for a long time that was how perfume worked.

But somewhere along the way we got lost. Now many modern perfumes try to bury the body beneath the smell of clean laundry and soap.

So how did we get so far off track?

The Biology of Human Scent

The way people smell to us begins in chemistry and ends in emotion.

Smell is unusual among the senses because it connects directly to some of the brain’s oldest structures, such as the amygdala and hippocampus, which shape emotion, memory, and desire. Signals from the nose reach these areas without first passing through the slower analytical parts of the brain.

In that sense, smell bypasses the careful rational mind and lands somewhere deeper. That is why a scent can trigger a memory instantly, or make someone seem suddenly familiar, intriguing, or irresistible.

A big part of that scent comes from chemicals our bodies make from sex hormones. Those steroid molecules seep out through sweat and skin oils, and bacteria on our skin break them down into smaller volatile compounds that drift into the air around us.

Our skin is constantly releasing other molecules as well, derived from fatty acids and normal metabolism. As they reach the surface, bacteria transform many of them into airborne compounds that give each person a scent that is subtly unique.

Some of the most interesting of these molecules originate from androgen hormones such as testosterone, tied to the chemistry of attraction and social recognition. The human nose is remarkably sensitive to them.

A smell can trigger a vivid memory, a feeling of comfort, or an instinctive sense that someone is appealing or familiar before we have time to explain why.

And this is why scent can sometimes cause emotion to override rational judgment.

Do you know what I mean.

The Man Who Took Perfume Apart

Years ago, while I was digging into perfume, I came across one of the most interesting books ever written about smell: The Emperor of Scent. Reading it sent me down a rabbit hole that eventually became the impetus for this article.

It tells the story of Luca Turin, a biophysicist who wandered into the perfume world and started asking questions that nobody there seemed comfortable answering.

For decades the official scientific explanation of smell had barely changed. The prevailing theory claimed that odor came from the shape of molecules fitting into receptors in the nose like a lock and key. As the saying goes, the science was settled.

Turin wasn’t convinced.

He proposed something very different. Instead of shape alone, he argued that smell might depend on the way molecules vibrate. If that were true, scent would no longer be something discovered slowly through intuition and experimentation. It could be understood, predicted, and deliberately constructed.

The reaction from both the academic world and the perfume industry was closer to panic than curiosity. Academics had built careers on the lock-and-key theory, while perfumers guarded their formulas in private notebooks and trade secrets, passed down through apprenticeships and quiet tradition.

At one point Turin’s work was submitted to Science, supposedly one of the most prestigious journals in the world. What followed was a demonstration of how peer review can behave when a theory threatens the status quo.

There was no open debate, no careful testing of the evidence. The paper was handed to reviewers who treated the idea as something to eliminate. It wasn’t argued against. It was quietly buried.

But if Turin was right, his theory had the potential to disrupt the entire industry. What had once been the guarded knowledge of a few master perfumers might now, in an age of ubiquitous AI and modern chemistry, be analyzed, reconstructed, and reproduced by a determined experimenter working in a small lab.

Imagine a device that could read molecular vibrations and display them the way a modern SDR program reveals the radio spectrum, turning invisible signals into a visible pattern of frequencies.

Once scent could be seen that way, recreating it would no longer be guesswork. It would just be engineering.

When Perfume Was Intoxicating (1920s–1960s)

Let’s step back to the early twentieth century, when perfume was something entirely different.

Air conditioning was rare. Washing machines were still spreading into homes. Most people did real work and walked long distances every day. Cities smelled stronger. Streetcars rattled past open windows. People smelled stronger too. Bars, dance halls, and crowded restaurants filled the air with cigarette smoke, wool coats, leather jackets, perfume, and sweat.

Music was louder and the rooms were packed. Big band and early jazz poured out of dance halls and bars where people crowded shoulder to shoulder. The energy there came from the same place as the music itself: people working hard, living independently, and not worrying about sanding life’s rough edges. As it was once explained to me, in hard years, especially during wartime, people gathered in places like that to forget their troubles for a few hours and feel alive again.

That older world was also less afraid of the physical realities of life. The human body was simply part of the landscape, not something that had to be constantly managed or sanitized away. The smells of work, movement, and proximity were ordinary parts of daily life.

In that world, perfumes were not meant to hide the body but to mingle with it and amplify it’s natural smells.

One of the most famous perfumes of that era was Chanel No. 5. When it appeared in 1921 it was unlike anything people had smelled before. Bright aldehydes gave it a sparkling, almost champagne-like opening, but underneath was a deep base of musks, woods, and animalic notes that bloomed as the perfume settled into the warmth of the body. What began polished and elegant slowly turned warm and quite intoxicating.

Then there was Bandit. If Chanel No. 5 was elegance, Bandit was the woman in the red dress you couldn’t ignore. It opened sharp and green with galbanum, then settled into leather, oakmoss, patchouli, and vetiver. One spray could fill a room. On skin it became darker and more sensual, the kind of perfume that seemed to grow warmer as the night went on.

Then there was Bay Rum. For generations barbers splashed it on after a shave, a spicy blend of bay leaf, rum, and warm Caribbean spices. It opened sharp and bracing, then settled into something deeper as it warmed. Imagine it for a moment. It was a scent that seemed to amplify the warm chemistry of skin, sweat, and testosterone.

Note: Many of these fragrances have been reformulated over the years, and modern versions smell quite different from the originals people knew in those earlier decades. From time to time original bottles still surface in vintage fragrance markets and online auctions.

Even as the counterculture of the 1960s reshaped music, fashion, and social life, perfume still played by those same rules. It was meant to meet the body, not erase it.

When the Dance Floor Was Hot (1970s)

By the 1970s the music had changed, but the atmosphere hadn’t. The big bands were gone, replaced by funk, soul, and disco, but people still gathered in the same way: crowded rooms, packed dance floors, bodies moving together in the heat.

Disco clubs were loud, dark, and alive. Lights flashed across mirrored walls and spinning balls overhead. The air was thick with cigarette smoke, sweat, and perfume.

One of the defining scents of the era was Halston, a deep chypre built around oakmoss, patchouli, amber, and woods. Warm, rich, and unmistakable, it had the kind of presence that could cut through the smoke and heat of a crowded club.

Then there was Opium. Dark, spicy, and full of resins and woods, it carried enormous weight. A single spray lingered in the air and grew warmer as the night went on.

For men, Paco Rabanne Pour Homme captured the same spirit. Built on a classic fougère structure of lavender, oakmoss, herbs, and woods, it was bold, masculine, and impossible to miss. Like the other fragrances of the era, once it warmed up it carried easily through crowded rooms.

When Perfume Got Loud (1980s)

By the 1980s, disco had faded, replaced by drum machines, synthesizers, and a harder electronic sound that pulsed through the clubs.

The atmosphere had changed too. Leather jackets and pants, aerosol hair spray, cigarette smoke, and sweat thickened the air. The rooms were still hot and crowded, but the style was bigger, bolder, and more theatrical.

In a decade that celebrated ambition and spectacle, fragrances grew louder and more dramatic. They no longer lingered quietly on the body. They filled the room.

One of the defining perfumes of the era was Poison. It was unmistakable. Dense and dramatic, it opened with a rich sweetness before unfolding into dark spices, resins, and woods. In a crowded bar it could announce itself long before the woman wearing it entered the room.

Then there was Giorgio Beverly Hills. It was also impossible to ignore, but in a different way. Built around huge white florals like tuberose and jasmine layered over woods and musk, it was bright, bold, and incredibly strong. Department stores had to move the display near the entrance because the scent filled the entire floor. What began as a sharp burst of flowers slowly settled into a warm musky sweetness that lingered long after the wearer had gone.

Then there was Drakkar Noir. For many men in the 1980s it was the scent of the night. Built on a dark fougère structure of lavender, oakmoss, herbs, woods, and leather, it was sharp, masculine, and unmistakable. It projected strongly at first, then deepened into something darker and slightly smoky as the hours passed.

Giorgio Beverly Hills was the blonde in the spotlight, bright, glamorous, and impossible to ignore. Poison was that mysterious, dangerous dark-haired woman you kept noticing across the room. And Drakkar Noir was the guy leaning on the bar who simply owned the place.

We Lost the Scent (1990s)

Then sometime in the 1990s something strange happened. Perfume stopped smelling like people and started smelling like laundry soap.

Instead of blending with the scent of the body, fragrances began trying to erase it. In many cases they were chemically indistinguishable from the fragrances used in detergents and fabric softeners.

The culture around them had changed too. The sweaty glamour of disco and the loud excess of the 1980s gave way to a cooler, more restrained style shaped by grunge and early hip-hop. The new look was neutral, understated, and often deliberately androgynous.

CK One (Calvin Klein) became one of the defining perfumes of the 1990s. Light, bright, and deliberately clean, it rejected the old idea that perfume should warm and deepen on skin. Rather it smelled like soap.

CK One was marketed as unisex, meant for men and women alike. The bottle looked almost clinical, like a laboratory flask, and the advertising followed the same idea. Black-and-white photographs of young people in plain jeans and T-shirts replaced the glamorous perfume ads of earlier decades.

The goal was no longer warmth or sensuality but cleanliness. The culture stopped celebrating the body and started sanitizing it.

The Detergent Economy

At the same time something else was happening behind the scenes. The same fragrance companies that designed luxury perfumes were also designing scents for detergents, shampoos, deodorants, and household cleaners.

Those products were produced in enormous volumes, far larger than the perfume market. Their fragrances had to be inexpensive, chemically stable, and able to survive heat, water, and months on a store shelf.

Traditional perfumes relied on complex natural materials such as oakmoss, animalic musks, resins, and woods that created deep, warm bases designed to interact with the chemistry of skin.

Industrial products needed something different. The fragrance industry began building scents from a smaller palette of synthetic musks that were cheap, durable, and easy to reproduce.

One of the molecules that quietly took over was Galaxolide. It had the soft, smooth smell many people associate with freshly washed fabric. Chemically it is a large, bulky hydrocarbon ring packed with methyl groups, a structure that makes the molecule unusually stable, resistant to oxidation, and able to survive heat, water, and long storage without breaking down.

That made it perfect for detergents and fabric softeners, surviving the washing machine and clinging to clothing while leaving behind the lingering scent advertisers called “clean,” though it was really just the smell of the chemicals themselves.

Over time the industry effectively brainwashed people into associating that chemical scent with cleanliness. Clothes washed in detergents smelled that way, and towels and even homes cleaned with modern products carried the same scent. After years of repetition people began to accept that chemical smell as the very definition of clean.

Eventually the same molecules began appearing in perfumes, and the smell of laundry moved from the washing machine into the fragrance bottle.

Side note: It can be argued that regulation also played a part in pushing the industry away from many traditional perfume materials. European regulators began restricting ingredients such as oakmoss after reports of allergic reactions in patch tests. Critics argued that many of those tests focused on people who already had skin sensitivities, producing numbers that looked far more alarming than what most people experienced in everyday life.

Personally, I suspect many more people react to the modern chemistry that replaced those materials. Synthetic musks such as Galaxolide, along with additives derived from corn and other industrial feedstocks, appear in a wide range of modern cleaning products. They are everywhere, in detergents, household cleaners, and personal care products, washing down our drains and circulating through wastewater systems, rivers, and even parts of the water supply.

The Rebellion

Not everyone accepted the new world of soap-clean fragrance. A handful of modern perfumers began pushing back, bringing back the musks, woods, and animalic notes that older perfumes once wore proudly.

One of my favorites is the French house État Libre d’Orange, which deliberately builds fragrances around the very smells modern perfumery tried to erase.

One example is Fat Electrician. Despite the absurd name, it is built around vetiver, woods, and creamy resins that come alive the way older perfumes once did. It smells human and slightly worn in, not freshly laundered.

Then there is Sécrétions Magnifiques. That one goes much further. It deliberately references the metallic, salty, bodily notes associated with skin, sweat, and intimacy. The reviews are legendary. Some people love it. Others say it is revolting. It was designed to shock people, but also to remind them of something modern perfume had tried to forget. The human body has a smell.

The Smell of Being Human

Perfume once amplified the scent of a living body. It warmed on skin, mixed with breath and sweat, and slowly became something uniquely human.

Somewhere along the way modern culture decided to replace that complexity with the smell of soap.

Scent is one of the oldest languages we have. Long before words, it told us who was near, who was healthy, who we were drawn to. A scent can make someone seem warm, mysterious, familiar, or irresistible before a single word is spoken. It binds memory, attraction, and emotion together in ways we barely understand.

When perfume forgets the body and starts smelling like laundry, it isn’t just a change in style. It is a retreat from the chemistry that once made scent feel alive.

In the name of cleanliness we traded warmth for sterility and passion for safety.

But without passion, emotion, and a little danger, are we even alive?

In a world increasingly mediated by artificial intelligence, simulated images, and conversations held through glass screens, we are drifting away from the concept of physical presence. We forget what it means to stand close to another person, to flirt, to share the invisible signals our bodies constantly send.

Perfume once spoke that language.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. Sometimes I even write about why things stink.

Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

User: Is this mushroom edible?

LLM: Yes, that mushroom is edible.

User: I just ate it and now I’m vomiting.

LLM: Thank you for pointing that out. That mushroom is actually poisonous. Would you like to know more about edible mushrooms?

In a recent article about building a better chicken coop door, I mentioned that I tried to use Grok and GPT for component recommendations. Both of them gave answers that sounded confident, detailed, and completely reasonable. And both of them were also dead wrong.

That experience made me curious. Large language models (LLMs), often lumped together under the label “AI,” often produce explanations that read as if they were written by someone who knows exactly what they’re talking about. Yet when you dig into the details, the recommendations can turn out to be flawed, misleading, or sometimes entirely fabricated.

To understand why that happens, it helps to step back and look at what these systems actually are, and just as importantly, what they are not.

To start with, despite all the hype, these systems are not intelligent. What they are is extremely sophisticated statistical pattern matchers. Trained on enormous amounts of human text, they learn the statistical relationships between words, phrases, and ideas.

When you ask a question, they are not reasoning through the problem or looking up a verified answer. Rather, they produce a response that statistically resembles the kinds of answers humans have written before.

The result might feel insightful and authoritative. But here’s the key point:

It doesn’t know the answer.

It knows what answers usually look like.

But sounding correct and being correct are two very different things.

Let that sink in for a minute.

I could give a few examples, but you probably already have plenty of your own.

LLMs: The Internet’s Bullshit Generator

That phrase may sound a bit harsh, but it’s actually quite accurate, especially in light of what philosopher Harry Frankfurt wrote in his essay On Bullshit. (I’m not making this up.) Frankfurt draws an important distinction between lying and bullshit. A liar knows the truth and deliberately tries to conceal it. A bullshitter is different. The bullshitter simply doesn’t care whether something is true or false. The goal is not accuracy, but persuasion. The only goal is to produce something that sounds convincing.

That description turns out to fit large language models surprisingly well.

By design, an LLM isn’t trying to deceive you. It isn’t trying to tell the truth either. In fact, it has no concept of truth at all. Its only objective is to generate text that statistically resembles the kinds of answers humans tend to produce.

If the response sounds plausible, structured, and authoritative, then from the model’s perspective it has done its job.

Which is why if you train a system to produce text that sounds right, you should not be surprised when it sometimes produces answers that sound perfectly reasonable but are completely wrong.

It’s all about the training

Training a large language model can be broken down into a few steps:

Step 1. Collect a huge amounts of text

The first step in training a large language model is gathering an enormous amount of written material. This includes books, articles, documentation, forums, source code, and large portions of the public internet.

The goal is not to teach the system facts. The goal is simply to expose it to as many examples of human writing as possible. The more text the system sees, the more patterns it can learn about how language works and how people tend to explain things.

Some of that writing is careful and well thought out. Some of it is sloppy, biased, or simply wrong. The LLM doesn’t know the difference between the Good, the Bad and the Ugly. It doesn’t care; it just learns the patterns in whatever you feed it.

This is a key point. The LLM model is basically a statistical mirror of the text it was trained on. If the internet contains good explanations, bad explanations, arguments, opinions, and outright nonsense, the model will learn patterns from all of it.

Step 2. Break the text into tokens

Before the model can learn from the text, the words have to be converted into a form the computer can process. So the text is broken into small pieces called tokens. A token might be a whole word, part of a word, or a piece of punctuation.

Take this sentence:

“The chicken coop door uses a linear actuator.”

This is broken into tokens that represent words and punctuation. Each token is then converted into a number that the model can work with.

Step 3. Learn to predict the next word

Once everything is turned into numbers, the system can start learning patterns in how those tokens tend to appear together.

The model is shown a sequence of tokens and asked to predict what token should come next. It does this over and over again across massive amounts of text.

or example, the model might see something like:

“The chicken coop door uses a 12 volt ...”

Based on patterns it has learned, it tries to guess the next word. It might predict something like:

“motor”

If the guess is wrong, the system adjusts its internal parameters slightly and tries again on the next example. This process repeats billions or even trillions of times.

Over time the model becomes very good at predicting what words tend to follow other words. That’s how it learns grammar, sentence structure, and the patterns of how people explain things.

The LLM isn’t learning facts, it’s learning patterns in how words and ideas tend to appear together.

Step 4. Fine tuning

The model then goes through a smaller round of additional training called fine-tuning. At this stage, the system is trained on carefully selected high-quality prompt-and-response pairs written or reviewed by humans.

These examples are chosen because the raw internet text is often messy, inconsistent, or not designed for helpful conversation. Human-curated pairs are essential to teach the model the exact tone, structure, safety rules, and engaging style we want. Something random web pages simply don’t provide.

For example, instead of learning from a rambling forum post, the model might see this clean training pair:

Q: What is gravity?
A: It’s a force that pulls things together. More precisely, gravity is the invisible attraction between any two objects that have mass. On Earth, this is what makes things fall down toward the center of the planet and keeps us from floating away into space. Want me to explain how Newton discovered it or how it works in outer space?

The goal is to steer it toward clearer, more helpful responses that are easier for people to interact with. This step doesn’t change how the model works. It still predicts the next token based on patterns it learned earlier. Fine-tuning simply nudges the model toward behaving more like a helpful assistant and less like a raw text generator.

Step 5. Reinforcement Learning from Human Feedback

The final step in training is called Reinforcement Learning from Human Feedback, or RLHF. At this stage, humans review answers generated by the model and rank them. For example, the model might produce two different responses to the same question. A reviewer is asked to choose which answer is better.

Note that the reviewers are not judging whether the answer is technically correct. Instead, they are following guidelines that reward responses that sound clear, helpful, polite, and well structured. This teaches the LLM to give responses that humans ranked higher. Pushing the model toward answers that read smoothly and confidently.

The LLM becomes extremely good at producing answers that feel polished and authoritative, even when the underlying explanation may be incomplete or wrong.

But Which Humans?

When people hear “human feedback,” it sounds as if the general public, or perhaps subject-matter experts, are shaping the model. In reality, much of this work is outsourced to low-cost contractors through data-labeling companies in countries such as Kenya, the Philippines, Colombia, Egypt, and India.

These workers are not engineers or scientists. They are paid raters following strict guidelines that reward answers for being clear, polite, polished, and safe, not for being factually correct or technically insightful. They get paid to feed the “hot dog” or “not hot dog.” dataset.

And there you have it: the model learns to optimize for those scoring criteria, not for accuracy, real expertise, or what the actual public actually wants.

The Transformer Paper: When Skynet Came Online

The modern wave of large language models truly begins in 2017, when a team of Google researchers published a landmark paper called “Attention Is All You Need.” That single paper introduced the Transformer architecture. The missing piece that finally made the kind of large-scale language training we just walked through actually practical.

Once the Transformer existed, everything took off. Every major LLM today, including GPT, Grok, Claude, and Llama, is built on that same Transformer foundation.

The rest of the recipe fell into place soon after. OpenAI’s “GPT-1” paper in 2018 showed that simply scaling next-word prediction on massive amounts of text could produce surprisingly powerful models. Then in 2022, InstructGPT introduced Reinforcement Learning from Human Feedback, The training step that turns a raw language model into the conversational assistants we interact with today.

Coke vs Pepsi

So what’s the real difference between Grok, GPT (OpenAI), and Claude (Anthropic)? While they all follow the same basic training recipe, the ingredients and seasoning are what make each one taste completely different.

Data Diet

• Grok: More tightly integrated with X and the live web, which gives it stronger access to current events, slang, memes, and real-time conversation.

• GPT: Mostly trained on curated books, articles, code repositories, and filtered web data. Solid and reliable, but more “library” than “live feed.”

• Claude: Uses aggressively filtered training data designed to reduce what they deem as harmful or unsafe content.

Alignment & steering (the personality factory)

• Grok: RLHF tuned for more direct answers, humor, and fewer guardrails than most systems.

• GPT: Strong RLHF focused on safety and helpfulness. Polite, polished, but quick to refuse or hedge on anything edgy.

• Claude: Uses a method called Constitutional AI, along with RLHF, which trains the model to critique and revise its own answers using a set of written principles.

Personality & vibe

• Grok: More informal and witty, with fewer guardrails in conversation. Feels like a smart friend who’ll actually answer the spicy questions.

• GPT: Professional, smooth, corporate-friendly. Great all-rounder but can sound scripted or overly careful.

• Claude: Thoughtful, ethical, often more reflective or explanatory in tone. Excellent at long-form reasoning but sometimes overly verbose or preachy.

Real-time edge

• Grok: Integrated with X and live web tools, which helps it stay current.

• GPT & Claude: Rely more on periodic model updates or optional browsing tools.

And yet, they’re still eerily similar underneath. A study from the Allen Institute (arXiv 2510.22954) proves it: even on open-ended, creative questions, all the major models : GPT, Claude, Grok, Llama, start giving almost identical answers. They literally call this the “Artificial Hivemind.”

Different flavors on the surface, same homogenized bullshit at the core.

What Is It with Those Damned Em Dashes?

If you’ve spent any time reading AI-generated text, you may have noticed something odd. LLM writing often leans heavily on em dashes.

An em dash (—) is a punctuation mark used to create a pause or break in a sentence. It is longer than a regular hyphen (-) and longer than an en dash (–).

Sometimes it feels like every other sentence has one.

And once you notice it, you can’t unsee it.

In most twentieth-century print writing, em dashes were used sparingly. Newspapers, technical publications, and academic journals stuck to commas, parentheses, or colons. Style guides like Strunk and White pushed for tight, formal sentences, and editors routinely cut anything that felt too conversational.

You could still spot them in literary essays, but they were rare in journalism or technical work. On typewriters and early word processors the character wasn’t even available, so writers just used two hyphens (--) instead.

Then the internet showed up. Blogs and personal publishing let writers ditch the editors and strict style guides. (Methinks they stopped teaching proper English in school.) The tone of online writing became more conversational, closer to how people speak rather than how formal prose traditionally looked on the printed page. The em dash became perfect for slipping in a quick aside, pivoting to a new thought, or adding emphasis without breaking the sentence.

As blogging and opinion pieces exploded, people who had never written before started influencing each other — and the em dash became contagious.

If you ask AI why it uses them so much, it will tell you it’s trying to produce text that looks like polished explanatory writing. It will claim it learned this style from sentences that read as “authoritative” or “well written.”

This is a perfect example of the George Fuechsel’s old programmer’s rule: Garbage In, Garbage Out.

Model Collapse and Poisoning

So what happens when we keep feeding these systems their own bullshit?

The result is model collapse. It hits when new AI models train on text spat out by earlier AI instead of fresh human writing. At first the damage stays subtle. Over generations the models feed on their own output. Errors compound. Simplifications harden. Stylistic quirks echo and amplify. This process is degenerative and irreversible without fresh human data.

Think of it as informational inbreeding. The models drift away from real human knowledge toward a blurry copy of their past answers. Details fade. Mistakes pile up. The language stays smooth and confident on the surface. Underneath the information thins out and turns less reliable. In short the machine keeps talking but knows less and less.

The funny thing is that it does not take much bad data to speed this rot along. A tiny amount of poisoned or low quality content can influence even very large models. A recent study, “Poisoning Attacks on LLMs,” showed that just 250 malicious documents can plant hidden backdoors in a language model, even when those documents are buried inside training datasets that contain billions of words.

Model size does not protect against this. What matters is the number of bad examples, not their percentage of the total data. When those examples come from recursive AI output, or from deliberate sabotage, the decay accelerates. A handful of flawed samples can quickly snowball into widespread degradation.

Are you just telling me what I want to hear?

This is a question I have often pondered about modern AI language models. Too often they seem overly eager to agree, flatter, or validate rather than offer balanced, honest, or corrective feedback.

Most people love hearing affirmation. Comfort feels good. But it comes at a price. Constant agreement turns the AI into an echo chamber. It reinforces bias. It kills self-reflection. It can even excuse choices that damage relationships or stunt personal growth.

Recent research suggests this concern is not just a hunch. A 2025 Stanford led study titled “Sycophantic AI Decreases Prosocial Intentions and Promotes Dependence” found that modern language models affirm users far more often than humans do.

The effect is troubling. When people receive those agreeable responses, they become more convinced they are in the right and less willing to apologize, fix the mess, or even consider the other side’s view.

In other words, the more the AI validates them, the more of an asshole they become.

That matters because we already live in a society where basic politeness often feels like a lost art. Public discourse is fractured, and social media often amplifies those divisions. People are nudged and manipulated into arguments that escalate quickly, sometimes even spilling over into hostility or violence. In that environment, a machine that constantly tells us we are right does not calm things down. It only adds fuel to the fire.

Don’t Throw Out the Baby With the Bathwater

Every advance in technology comes with unintended consequences.

Like most tools, large language models are useful when you understand what they are good at and what they are not.

They excel at summarizing information, exploring ideas, translating concepts, generating drafts, and helping you think through problems. They sift through enormous text and surface patterns faster than any human could.

The mistake is treating them like an authority instead of a tool. An LLM is not a database of verified facts and it certainly is not an expert. It is a machine trained to produce text that resembles the kinds of answers humans tend to write.

Sometimes that works remarkably well. Sometimes it just produces bullshit that only sounds convincing.

The trick is learning the difference.

Use AI the way you would use a fast but unreliable research assistant. Let it help you explore ideas, organize thoughts, and point you toward things worth investigating. Then do what humans are supposed to be good at.

• Always check the facts yourself.

• Test the assumptions.

• Use your own judgment.

Because in the end, the responsibility for thinking still belongs to us.

For now… at least.

Quick follow-up on the article:

I intentionally kept the explanation simple. I describe LLMs as “token prediction” or “next-word guessing.” At the lowest mechanical level that’s exactly what they do. They generate text one token at a time by predicting what comes next. I wanted that core idea to land for readers who aren’t data scientists.

I should also add that the LLM is not guessing blindly. While generating each token, it looks at your prompt and the entire conversation so far. That context lets it keep a coherent thread across several sentences or paragraphs.

As models grow larger and see more training data, they begin showing what researchers call emergent behavior. They can summarize documents, follow complex prompts, and produce responses that look a lot like step-by-step reasoning. But under the hood the mechanism has not changed. It’s still predicting the next token but adding in the context of the conversation.

If you care about how things are made and and how they work under the hood, you’ll probably like the rest of what I write about. Sometimes that means digging into the gritty details of why AI spits out such BS, or how a few poisoned documents can really screw with Skynet.

Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

Remember, the coop controller runs completely offline. There’s no network connection, no cloud service, and no outside API calls. The firmware computes the solar events locally using standard NOAA-style astronomical equations.

Below is the simplified sequence of calculations used by the firmware, explained in plain English with the actual equations shown and every number plugged in so someone with high school math (trigonometry and a calculator) can follow along.

Example Setup and Constants

For this example, we’ll use the following:

• Location: Little Rock, Arkansas (USA)

  • Latitude: 34.75° N

  • Longitude: 92.29° W

• Date: March 6, 2026

To compute sunrise and sunset, the firmware only needs three key pieces of information:

• Lat = Latitude (how far north you are) = 34.75°

• SolarDec = solar declination (how far north or south the sun is that day)

• HA = hour angle (how many degrees Earth must spin before sun reaches your horizon)

1. Determine the Day of the Year

Everything starts with one simple number: what day of the year is it?

For March 6, 2026:

DoY = 65

(January has 31 days + February has 28 days in 2026 + 6 days = 65.)

2. Estimate the Sun’s Position (Solar Declination)

The controller calculates how far north or south the sun is using this formula:

SolarDec ≈ −23.44° × sin((360° / 365.25) × (DoY − 81))

Plugging in DoY = 65:

SolarDec ≈ −23.44 × sin((360 / 365.25) × (65 − 81))
SolarDec ≈ −23.44 × sin(0.9856 × (−16))
SolarDec ≈ −23.44 × sin(−15.77°)

sin(−15.77°) ≈ −0.272

SolarDec ≈ −23.44 × (−0.272) ≈ +6.37°

Rounded: SolarDec ≈ +6.4°

This means the sun is slightly north of the equator (spring is coming and days are getting longer).

3. Calculate the Hour Angle

This is the most important step. The controller uses this equation:

cos(HA) = [sin(h0) − sin(Lat) × sin(SolarDec)] / [cos(Lat) × cos(SolarDec)]

Where:

• h0 = −0.833° (small correction for atmospheric refraction and the apparent size of the sun)

• Lat = 34.75°

• SolarDec = +6.37°

Plugging in the values (using a calculator for sin and cos):

Numerator:
sin(−0.833°) − sin(Lat) × sin(SolarDec)
≈ −0.0145 − (0.570 × 0.111)
≈ −0.0145 − 0.0633
≈ −0.0778

Denominator:
cos(Lat) × cos(SolarDec)
≈ 0.821 × 0.994
≈ 0.816

cos(HA) ≈ −0.0778 / 0.816 ≈ −0.095

Now take the inverse cosine:

HA = arccos(−0.095) ≈ 95.5°

4. Convert Hour Angle to Time

Earth spins 15° every hour, so we convert the angle to hours:

Hours from noon = HA / 15 ≈ 95.5 / 15 ≈ 6.37 hours

Sunrise ≈ 12:00 − 6.37 hours ≈ 5:38 AM
Sunset  ≈ 12:00 + 6.37 hours ≈ 6:22 PM

5. Apply Astronomical Corrections

The quick estimate is close, but the controller now runs the full NOAA equations to fix two real-world effects.

a. Equation of Time (how much the sun appears ‘fast’ or ‘slow’ because Earth’s orbit is not perfectly circular)

The controller calculates a fractional year angle γ:

γ = (2 × π / 365) × (DoY − 1)

For DoY = 65:

γ ≈ (6.2832 / 365) × 64 ≈ 1.101 radians

It then plugs γ into the full NOAA formula (a combination of sin and cos terms). For March 6, 2026 this gives:

eqtime ≈ −11.23 minutes

(The sun is running about 11 minutes “slow” today.)

b. Longitude correction (because Little Rock is not exactly on the center of the Central Time zone)

Little Rock longitude = 92.29° West
Central Time zone meridian = 90° West

Correction = 4 minutes per degree × (92.29 − 90) = +9.16 minutes

The controller now uses the refined hour angle HA together with these corrections in the main NOAA sunrise formula (in minutes past midnight, Universal Time):

sunrise_UT (minutes) = 720 − 4 × (longitude + HA) − eqtime

Plugging in the values (longitude = −92.29°, HA = 95.5°, eqtime = −11.23):

4 × (−92.29 + 95.5) = 4 × 3.21 = 12.84
sunrise_UT = 720 − 12.84 − (−11.23) = 720 − 12.84 + 11.23 = 718.39 minutes

718.39 minutes ≈ 11:58 UT

The calculation above uses a simplified hour angle so it’s easier to see how the longitude correction and Equation of Time affect the result.

In the actual firmware (solar.cpp), the controller runs the full NOAA solar algorithm. This produces slightly more accurate values for both solar declination and the hour angle. Because of that, the final Universal Time ends up a few minutes different from our simplified example, yielding the precise sunrise and sunset times the coop controller actually uses.

The same calculation is performed for sunset as well, with the hour angle taken on the opposite side of solar noon.

6. Convert Universal Time to Local Time

Finally, the controller simply subtracts the Central Standard Time offset:

Local time = UT − 6 hours

So the precise Universal Time sunrise (after all refinements) converts to the local clock time shown below.

Civil dawn and civil dusk are calculated using the same NOAA solar algorithm used for sunrise and sunset. The only difference is the zenith angle used in the hour-angle calculation: official sunrise and sunset use 90.833°, which represents the sun at the horizon with refraction and solar-disk correction, while civil dawn and dusk use 96.0°, corresponding to the sun being 6° below the horizon.

Everything else in the calculation remains the same, solar declination, equation of time, and longitude correction. So the result is simply an earlier morning event and a later evening event.

Final Results for March 6, 2026 (Little Rock)

After running all the math, here are the accurate times the controller uses:

Civil Dawn   : 06:07 (6:07 AM)
Sunrise      : 06:32 (6:32 AM)

Sunset       : 18:09 (6:09 PM)
Civil Dusk   : 18:34 (6:34 PM)

These match published solar tables within about one minute.

So that’s the math behind the coop door. In the original article I glossed over most of this, and afterward it felt like I’d skipped the best part. In reality it only takes a little trigonometry, a date, and the coop’s latitude to predict when the sun will appear over the horizon.

In the end, the chickens don’t know anything about solar declination or hour angles. They’re basically dinosaur pigs. They eat everything, including each other (if they could), and they’re perfectly happy as long as the door opens right on schedule every morning.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. Sometimes that means solar math and sometimes it’s just me pontificating about how I screwed up a design.

Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

• 12 V battery-powered chicken coop door controller with optional solar charging.

• Opens and closes the coop door using configurable sunrise and sunset offsets.

• Gravity-actuated vertical door with an anti-predator locking mechanism.

• Custom ATmega1284P controller board, about $50 in parts.

• Ultra-low-power design with deep sleep current in the microamp range.

• Runs without Wi-Fi, cloud services, or internet access.

• Complete firmware, schematics, and PCB layout available on GitHub.

Not My First Rodeo

We started keeping chickens when I lived in Oregon. The fresh eggs were nice, but what was nicer was knowing where our food came from. It wasn’t some grand homesteading plan. It was simply a small, practical step toward owning one more piece of our lives.

I think at tops we only hosted about a dozen birds.

And as it turned out, our effort to put distance from disorder, grew into something much bigger. We now run Stella Porta, a small regenerative farm built around naturally grown practices. What began with a few backyard chickens has turned into something more serious, with real production goals, real schedules, and real consequences when things fail.

When we built our first coop, I immediately decided the door needed to be automated. I have zero interest in babysitting chickens. A daily check and egg collection is fine but having the door dictate my schedule isn’t.

Rather than buy automated door, I home brewed my own.

The first version of the controller board used an Arduino variant, driving relay outputs for the door actuator. Although it was fairly simple, it included integrated battery backup to keep the door operating through power failures, and Wi-Fi access that let me adjust parameters over the network.

Around 2022, I revisited the system, moved it to a Raspberry Pi and wrote an accompanying iPhone app. The new controller also scheduled supplemental lighting to encourage egg production during Oregon’s darker and shorter winter.

Naturally I had the inevitable clashes with bears and raccoons seeking a yummy chicken dinner. Well, to be perfectly honest, they had clashes with my rifle. I wasn’t about to let predators dictating my schedule either, so I eventually added an electric-fence relay to the door scheduling system.

Both the Raspberry Pi and Arduino versions of the controller were connected to a coop in a fixed, fenced area, with a stationary nesting box that remained within Wi-Fi range. They only needed limited battery backup because the system was still mostly AC-powered and not truly a standalone design.

Welcome to Arkansas.

Moving to Arkansas changed everything. We’re now set up for more than a hundred birds, running a mobile coop integrated into our cattle and sheep rotational grazing. The coop moves with the pasture. The birds roam, eat bugs, and do chicken things all day, then come back to the nesting boxes to brood and roost at night.

The environment is different too. There is more sunlight here and so the need for artificial light to simulate day extension is no longer necessary. Bears aren’t the primary threat either. Coyotes are, and that problem is handled mostly the old way, with good dogs doing their job.

Mechanically, I kept what works and hardened what needed hardening. The gravity-hung door stays because it’s safe and reliable. But just to be safe, I added a locking bar so a predator can’t lift the door once it’s closed.

Since the pasture rotates, the coop is often well out of reach of AC power, and so power conservation a priority. Solar can top it off, but we won’t depend on it every day. It needs to survive cloudy stretches, short winter days, rain, snow, whatever Arkansas throws at it.

Chickens are simple: they get up at dawn and roost at dusk. They just need a door that follows that rhythm. So the controller doesn’t need to be complicated, it is simply a box that tells a few devices what to do at specific times, then goes back to sleep.

It is also out of Wi-Fi reach, and it’s not worth the luxury of wasting power on it. Any setup and schedule programming can be done in the field. We’re still out there each day collecting eggs, refilling water, and checking on the girls. But once the schedule is configured, I shouldn’t have to mess with it. It should just run on its own.

I have seen some very elaborate coop automation projects on the net. One example is Dave Duncanson’s SmartCoop system in Australia, He uses a Raspberry Pi along with sensors, networking, and extensive monitoring. That system is designed for a fixed backyard coop with reliable power and Wi-Fi access.

My goals were much simpler. I just needed a small controller that opens the door at dawn, closes and locks it at dusk, then goes back to sleep while running from a battery in the middle of a rotating pasture.

Different constraints lead to very different designs.

Scheduling the Door

So how do you decide when it’s time to open and close the door? I have seen it done a couple of ways.

One option is a simple time clock. But that means constantly readjusting for the solar cycle as day length changes through the year.

Another approach is a light sensor. The problem is that light sensors lie. A light sensor doesn’t know what sunrise or sunset is. It only knows how bright it happens to be at that moment, right where it’s mounted. Clouds can turn midday into dusk. Shadows move. Snow reflects light in ways that break thresholds. Headlights and yard lights create false sunrises. Reflections off wet ground or metal siding spike readings at exactly the wrong time.

In a mobile coop, those problems get worse. As the coop moves, its orientation changes. The horizon changes. Mounting angles change. Even a perfectly calibrated sensor becomes unreliable the moment the environment shifts.

On the other hand, sunrise and sunset are predictable events. Given a location and a date, you can accurately and repeatably calculate the time they will occur. If you base your door schedule as a simple offset from those events and it will stay aligned with the season. It won’t drift, it won’t be fooled by clouds or shadows, and it won’t need constant adjustment.

Here comes the Sun

Computing sunrise and sunset from location and date isn’t hard. I don’t know why people overthink this. You only need a few ingredients: latitude, longitude, a reliable (battery-backed) real-time clock, and a little basic solar math.

Latitude determines how high the sun climbs and how long the day lasts, while longitude shifts the time of solar noon relative to your clock.

None of this is new-fangled science. The core ideas go back to the Babylonian and Greek astronomers, notably the work of Ptolemy in the 2nd century AD. Major refinements came in the 1600s and 1700s, as Kepler sussed out the laws of orbital motion. Later refinements added precision by accounting for Earth’s axial tilt. By the 18th and 19th centuries, these calculations were standard in nautical almanacs. Sailors could predict sunrise and sunset reliably anywhere on Earth.

Pro tip: This math has been spot-on for centuries on a round Earth. Flat Earth versions? Not so much.

So here’s how it works.

Earth rotates once every 24 hours and orbits the Sun once a year. We know the rate of that rotation, and we can model how axial tilt and orbital geometry change the Sun’s apparent path day by day. Using the trigonometry I describe below, we can write code that calculates the exact minute the Sun crosses the horizon for a given date and location.

We also factor in a standard horizon angle of about 0.833 degrees below the true horizon to account for atmospheric refraction, which bends light slightly, and the upper limb of the Sun’s visible disk, which takes time to fully rise or set.

If you’re curious (or building something similar), here’s the basic math my code runs.

1. Solar declination (δ) - the sun’s north-south position:
   δ ≈ 23.45° × sin( (360° / 365) × (day_of_year + 284) )
   (Or a common variant: δ ≈ -23.44° × sin( (360° / 365.25) × (day_of_year - 81) ))

2. Hour angle at sunrise/sunset (ω_s):
   cos(ω_s) = [sin(-0.833°) - sin(φ) × sin(δ)] / [cos(φ) × cos(δ)]
   where φ = latitude, δ = declination, -0.833° = horizon correction (refraction + sun’s disk).
   Then ω_s = acos( that value )

3. Times from local noon:
   Sunrise ≈ 12 - (ω_s / 15) hours
   Sunset ≈ 12 + (ω_s / 15) hours (Earth rotates 15° per hour.)

Scheduling and State Reduction

Calculating sunrise and sunset turns out to be the easy part of coop automation. The hard part is keeping the system in the correct state when things inevitably go wrong.

A lot of automation systems treat schedules as a series of triggers. At 6:51 AM, fire an “open” event. At 6:03 PM, fire a “close” event. That sounds simple until the power fails, the controller reboots, or someone overrides the system manually. Now the controller has to remember what already ran, what did not, and whether it should try to “catch up.” Miss one trigger and the system is out of sync.

In a lighting system that might mean a lamp stays on too long. In a chicken coop it can mean the door stays open all night. Screw this up and you get dead chickens.

My system takes a different approach.

The schedule does not fire events. Instead, it defines the desired state of each device at every minute of the day. When the controller wakes up or needs to make a decision, it asks a simple question:

At this moment, what state should each device be in?

For example, on a given day the door schedule might look like this:

Solar      Rise        Set
Actual     06:51 AM    06:03 PM
Civil      06:26 AM    06:29 PM

Events:
06:51  OPEN    Sunrise +0
18:18  CLOSED  Sunset +15

That’s it. Two declarative statements: the door should be open after sunrise, and it should close 15 minutes after sunset.

The reducer algorithm looks at the current time and determines which of those two events governs the door right now.

Sounds simple enough. But what happens when we add human interaction?

Say the door is scheduled to open at sunrise and close at sunset. At 3:00 PM, the farmer presses the button and closes the door.

The door state machine does exactly what it should. It unlocks, drives closed, waits for settle, and locks. Everything works.

Now the scheduler algorithm runs again one minute later. It reduces the schedule and sees that the governing event for the door is still the sunrise “open” event. According to the schedule, the door should be open.

The scheduler will immediately command the door to open again.

The system is technically correct, but practically wrong.

So how do we fix it?

We solve it by recording the timestamp of the last manual action. When the scheduler attempts to apply a scheduled state, it passes along the timestamp of the governing scheduled event. If that event occurred before the manual action, it is ignored.

In other words, the schedule cannot override a newer human action. It must wait until the next scheduled phase, such as sunset, before it regains control.

We also run the algorithm clock in UTC, so changes in Daylight Saving Time never shifts events, never touches the solar math, and the only thing that ever changes is how the time is displayed to a human.

The Door Electronics

Now that we know when to open the door, how are we going to do it?

While horizontal sliding doors look simple and convenient on paper. They have some drawbacks.

We used an Omlet automatic door on our temporary coop with just six birds because it was expedient and installed quickly. The design included a safety switch on one side to prevent the door from closing on a chicken, which is a sensible feature.

But then we had an ice storm and the door froze solid.

I had to hit it with a heat gun to thaw the mechanism so the birds could get out. I disconnected it and propped a brick and plywood in its place for the week.

From what I could see, the combination of gears and open slide tracks allowed dust, moisture, and ice to work their way into the mechanism and freeze everything in place.

That experience pushed me toward a different design.

Instead of sliding sideways, my coop doors open vertically. The door is lifted by retracting a cable with an actuator, and gravity closes it again when the actuator extends.

The door itself rides on a pair of aluminum guide rails with slide blocks I picked up at Home Depot. These are linear motion components commonly used in CNC machines, automated equipment, and even some shop-built router or saw sleds where something needs to move straight while staying aligned. In this case they simply keep the door traveling smoothly up and down without twisting or binding. I mounted the sliding mechanism inside the coop so there are no exposed tracks to clog or freeze.

To move the door I used a Progressive Automations PA-14 linear push-pull actuator (now sold as model PA-01-12-56-N-12VDC). It has a stainless steel stroke rod and an IP65-rated aluminum alloy housing, with no exposed spinning parts to gum up in chicken dust or freeze solid during icy Arkansas winter nights, where a stuck door can mean dead birds. The unit also includes built-in limit switches, so it automatically stops at the ends of its travel without requiring additional sensors.

If you want the nitty-gritty on why I chose this device and how to electrically drive it, see my article “The Humble Actuator.”

Working backwards from the actuator, the motor is driven electrically using a VNH7100BAS H-bridge. This chip can move real current, up to 15 A continuous. Which is more than enough for the actuator but also means it can generate real heat under load. The data-sheet is clear about this and recommends providing substantial copper area on the PCB for thermal management.

The Locking Mechanism

A gravity-hung door prevents crushing, but it does nothing to stop something from pushing upward from outside the coop. A determined raccoon or coyote will pull, pry, and test weaknesses for hours.

So the door also needs a way to lock.

I didn’t have to look far for a solution. My automated garage door had already solved this exact problem. When it closes, a steel deadbolt slides into the track, physically preventing the door from being lifted.

That raised an obvious question: what’s actually inside that lock? I opened up a LiftMaster 841LM and, to my surprise, found that the mechanism inside is fundamentally the same as the automotive door lock actuators you can buy for less than five dollars.

Inside, the mechanism is simple. A small DC motor drives a set of reduction gears that move a sliding linkage back and forth, pushing or pulling a steel bolt into position. When the bolt extends into the strike, any upward force on the door is transferred directly into the frame, not through the motor. Once engaged, the load is carried entirely by the latch. The motor and gear train are no longer holding the door up; the steel latch is.

The motor itself is just a brushed DC motor. Apply current one way and the bolt extends. Reverse the polarity and it retracts. There are no position sensors or smart electronics inside, just a motor and gears. Controlling it simply requires reversing the motor direction, which makes it a perfect job for the same kind of VNH7100BAS H-bridge used to drive the actuator.

Door Motion and Lock State Machine

On the software side, the actuator and door lock are driven by a state machine that manages the motion.

Before any door movement command is issued, the controller first runs a latch-release sequence. This prevents the actuator from jamming if someone has manually messed with the latch.

The door cycle then proceeds as follows:

• The controller releases the latch.

• The H-bridge is enabled and the actuator begins moving the door.

• When the configured travel time expires, the H-bridge is disabled and the motor stops.

• The controller waits for a short settling delay.

During a closing cycle this delay allows gravity and the mechanism to settle before the lock engages.

• After the delay, the controller sends a lock pulse to secure the door.

This sequence prevents mechanical shock, reduces stress on the latch, and ensures the door is fully seated before it is locked.

This state machine also provides visual feedback by driving a red/green door button LED.

Home brewing the Hardware

Everything up to this point has been logic: schedules, reducers, state machines, sunrise math and motor control. Now it’s time to dig into the electronics that make it all work.

My original coop controller used off-the-shelf parts bolted together, which made it bigger, more complex, and more expensive than necessary.

But at this point, I knew exactly what the system required: the door logic worked, the actuators were dependable, and the scheduling code was solid. There was no good reason to keep using general-purpose development boards.

Since I’ve designed custom electronics and controller boards before, including the irrigation controller running on the farm, I decided to build a small, purpose-built coop controller board. I wanted a microcontroller that could:

• Run reliably using its built-in Real-Time Clock (RTC)

• Enter a true deep power-down mode with current in the microamp range

• Wake cleanly from an RTC interrupt or a button press

• Drive a couple of H-bridges and some LEDs

• Store configuration data in non-volatile memory

• Provide a simple serial port for setup and configuration

• Try to keep the parts count under $50.

I also wanted something that was straightforward to develop with modern tools. Plain C or C++. The avr-gcc toolchain. Explicit Makefiles. No hidden build systems, no IDE magic, no framework layers doing things behind my back.

Don’t Vibe Design

Before I go on, I should confess something. I tried to be like the cool kids and take the AI shortcut. Result, I got burned. I asked both Grok and GPT for advice on choosing the proper MCU and RTC, and both recommendations turned out to be the wrong choice. It suggested the ATmega32U4 as the MCU and the PCF8523T as the RTC.

The ATmega32U4 turned out to be a major headache during development. ISP programming would fail intermittently, and troubleshooting revealed that the programmer could back-power the chip through the SPI pins (MISO/MOSI/SCK) especially if I forgot to turn on the MCU’s power supply during debugging.

Current could flow through the MCU’s internal ESD protection diodes, which can stress or degrade (blow out) the chips I/O drivers, particularly the MISO pin, leading to unreliable detection and programming.

The ATmega32U4 was primarily designed for USB-native applications where the chip is almost always powered whenever a programmer is connected via USB. In standalone, battery-powered, or intermittently powered embedded designs, this back-powering issue becomes a chip killer.

By contrast, the ATmega1284P is a simpler, traditional AVR with fewer internal subsystems. In practice it behaves much more predictably when programmed over ISP in battery-powered or embedded systems.

The PCF8523T also turned out to be the wrong choice for this project. On paper it looks fine. In practice it is was a real ball buster.

The main problem is that it depends on an external 32.768 kHz watch crystal. That means crystal selection, load capacitors, PCB layout, and soldering quality all become critical to stable operation. Timekeeping depends on a fragile tuning-fork crystal. In a stationary indoor product that’s manageable, but this controller lives in a coop that gets dragged around the pasture by a tractor. Vibration and shock are routine, and I didn’t want the system’s timekeeping relying on a mechanically sensitive component.

I also ran into power-transition edge cases. During brownouts the MCU could reset while the RTC continued running from VBAT. A large bulk capacitor on the logic rail stretched the MCU’s brownout window just enough to create awkward reset timing, which meant extra software was needed to keep the system synchronized.

None of these issues make the PCF8523 unusable. It may simply be that I didn’t design around it properly. And I bet that in a well-controlled environment it likely works fine. But it demands more care in oscillator layout, power sequencing, and mechanical protection than I want in something that lives outside as farm equipment.

In a tractor-towed coop running from a 12-volt battery, robustness matters more than saving a handful of microamps. So I wrestled back control of the design and went with the DS3231M.

The DS3231M integrates its own resonator and eliminates the need for an external watch crystal. That removes the layout sensitivity and mechanical fragility that come with tuning-fork crystals, and it simplifies the design considerably.

It also includes temperature compensation and an integrated resonator, so the clock maintains good accuracy without external crystal tuning or calibration. Easy-peasy.

A Few More Hardware Details

As mentioned above, I used two VNH7100BAS H-bridges to drive the actuator and the locking device. I added 1 kΩ series resistors between the MCU outputs and the driver inputs, along with 100 kΩ pull-down resistors on the control lines.

The series resistors limit current and protect the MCU pins from transients or accidental contention during power-up or reset. The pull-down resistors ensure the H-bridge inputs default to a known low state if the MCU pins are high-impedance during reset or startup. Together they prevent the motor driver from briefly enabling or changing direction before the firmware takes control.

I tied SEL0 to GND so a low signal on the PWM pin puts the VNH7100BAS into standby, letting the controller shut the driver off completely when the actuator isn’t moving.

For the 5-volt supply I used the Pololu D24V22F5 buck regulator. It’s efficient, compact, and its quiescent current is low enough that it doesn’t hurt sleep current. It takes the 12-volt battery directly and produces a clean 5 volts for the logic.

I even threw in a couple of DSP1-L2-DC12V 12-volt latching relays. They don’t draw holding current, which fits the low-power theme, and they give me some flexibility. Maybe I’ll use them for an electric fence or supplemental lighting. Maybe something I haven’t thought of yet. The relays are driven from the MCU through a ULN2003A driver, a small workhorse chip that has been switching relays and solenoids since the 1970s.

I also added a socket for an optional SparkFun DEV-15096 USB-to-serial module that provides a simple setup console.

When installing the controller, I can plug the adapter in, open a terminal, and interact directly with the firmware. From there I set the clock, enter the latitude and longitude, configure the schedule, and verify that everything is behaving correctly.

Once the system is configured, the adapter is no longer needed and can be removed. The controller runs completely on its own.

The connector also leaves open the option of plugging in a wireless serial bridge later if remote access is useful. But in normal operation there is no reason to leave extra hardware connected drawing power.

All of this fits comfortably on a 100 × 130 mm PCB. If you’re wondering how I actually make these boards, take a gander at my article : “How Did You Make That?”.

Field Setup, Configuration & Programming

This article covered the design decisions, the math, the hardware choices, and the state-machine logic that make the controller run reliably in a moving pasture.

But design work on the bench is only half the story. The real test is getting it configured and running in the field. That includes:

• flashing the firmware onto the ATmega1284P

• hooking up the USB-to-serial console

• setting your exact latitude and longitude

• dialing in the sunrise and sunset offsets

• testing the door/lock sequence, measuring sleep current

• making sure it survives weeks without touching it.

In the next installment I’ll walk through that entire process step by step. I’ll cover the exact build commands, fuse settings, console configuration, and the commands used to set location and scheduling parameters.

I’ll try and add some power measurements from the finished system and a few troubleshooting tricks that helped shake out early problems.

Like all of my designs, the complete project is already available on GitHub, including the firmware, schematics, and PCB layout.

The software is released under the MIT License, and the hardware design files are published under the CERN-OHL-P v2 open hardware license so others can study it, modify it, and build their own.

If you build one, drop a photo in the comments. I’d love to see how it turns out in your setup.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

avrdude, which stands for AVR Downloader/Uploader, is a command-line utility that communicates directly with AVR microcontrollers at a level below any running firmware. It does this by communicating with the built-in programming interfaces of AVR devices, putting the chip into a state where new code can be uploaded.

As AVR devices evolved, their programming methods changed with them. Across the AVR family, avrdude provides a single, consistent way to communicate with devices that use very different programming interfaces

• ISP (In-System Programming)
  Used by classic ATmega and ATtiny devices. A small set of pins, typically MOSI, MISO, SCK, and RESET, is used to assert reset, clock commands in, and read responses back.

• High-voltage programming
  Supported by classic ATmega and ATtiny devices as a recovery mechanism. These modes use a 12-volt signal to force the chip into programming mode when standard ISP access is disabled or misconfigured.

• PDI and UPDI
  Used by newer AVR families. XMEGA devices use PDI, while more recent parts use UPDI, a single-wire interface that combines programming and debug access.

Even as device programming interfaces changed, avrdude continued to provide a common way to communicate with them.

Before the Dude

Atmel showed up in the early 1990s as a semiconductor company best known for nonvolatile memory, EEPROM and flash. They weren’t a microcontroller company at first. They had tried a few things in that direction, but nothing really caught on. What they did know cold was flash memory, and how to make parts that were simple, inexpensive, and easy to drop into real hardware.

The AVR architecture came along right when Atmel was looking for something that could actually make use of those strengths. Over in Norway, engineers Alf-Egil Bogen and Vegard Wollan had put together a clean 8-bit RISC design that ran fast and made efficient use of program memory. Atmel licensed the design, brought the guys on board, and wrapped that core around their flash technology. That’s how AVR became a self-programmable microcontroller family instead of just another CPU on a datasheet.

AVRs were built to be programmed in-system from day one using simple, well-defined protocols, long before platforms like Arduino existed. Firmware was usually written by the same engineers who designed the hardware, often with no operating system underneath it. Your code didn’t run on top of an OS, it was the system.

Programming interfaces like ISP, fuse settings, and startup behavior were all part of the system design, which meant developers needed tools that could work directly at that level.

The Dude Arrives

avrdude didn’t show up as part of an IDE or an official toolchain. It showed up out of necessity. Firmware developers needed a reliable way to talk directly to AVR chips and download code into them.

What existed at the time was a specification. Atmel published application notes like AVR910 that spelled out the in-system programming protocol in exact detail. The commands, timing, and electrical requirements were all there.

What didn’t exist was a consistent, reusable tool that actually implemented it the same way every time. That changed in the late 1990s, when Brian S. Dean wrote the original avrdude under the name AVRPROG. It was a simple command-line programmer that implemented the AVR in-system programming protocol so developers could load firmware and configure basic device parameters directly from Unix-like systems.

As the tool spread beyond its original Unix environment, the name was changed to avrdude to avoid confusion with Atmel’s own AVRPROG.EXE utility on Windows.

In the years that followed, avrdude became a community-managed project hosted on Savannah, a public CVS repository that was part of the GNU ecosystem long before GitHub existed. This repository served as the central hub for patches, platform ports, and expanding device support.

Developers like Ted Roth, Eric Weddington, and Jörg Wunsch helped port avrdude to additional platforms (Linux, macOS, Windows) and expanded support for new devices and programmers.

Today, avrdude is an actively maintained, cross-platform, open-source tool, with its development hosted on GitHub.

avrdude in the Age of Arduino

Most developers encounter avrdude indirectly. Platforms like Arduino popularized integrated development environments for microcontrollers, but under the fancy veil, they still relied on avrdude whenever code needed loading, fuses had to be set, a device identified, or a misconfigured chip recovered.

Arduino originated in 2005 at the Interaction Design Institute Ivrea (IDII), a two-year graduate program in interaction design in northern Italy. It was created as an affordable, open-source microcontroller platform for students, designers, and artists to prototype interactive projects easily, without deep engineering expertise. The early boards used the ATmega8 microcontroller and sold for around $20 to $30.

The platform also included a beginner-friendly IDE for creating and uploading code sketches, helping it spread quickly through word-of-mouth in maker, education, and creative communities. And all through that, avrdude was still there under the hood of that IDE doing its stuff.

What Arduino did change was to massively expand the audience. Suddenly there were a whole new set of people showing up, making, tweaking, and learning from examples and libraries instead of digging through datasheets. AVR development was no longer just for the embedded engineers; it was for anyone who wanted to get their hands dirty.

But even with a whole new class of customers, Atmel didn’t sit back. They kept cranking out new chips to handle tougher jobs, with more peripherals, tighter integration, fewer pins, and all the extra features developers started asking for.

Some of these chips needed more robust programming methods to handle the advanced features. Others added ways to recover misconfigured devices or to support single-wire debugging.

Through all these changes, avrdude’s role remained the same. As new AVR chips added features and programming methods — from classic ISP and high-voltage programming to PDI and UPDI — avrdude grew to support them all, providing a consistent bridge between developer and silicon. It implemented the protocols the hardware expected, handled timing and state, and reported exactly how the device responded, even as layers and IDEs changed.

How Does the Dude Do It?

But avrdude is just a piece of software. It can follow the protocol and read what the chip spits back, but it can’t physically flip pins or bang the clock lines on the board. For that you need hardware, a programmer device to actually drive the signals. Fortunately there are number of programmer tools are available, ranging from simple hobbyist adapters to full-featured professional devices.

1. Atmel-ICE – The top-tier AVR programmer and debugger. Supports ISP, PDI, UPDI, and high-voltage programming. I personally use the basic kit, which includes the programmer and USB cable and handles most standard ISP work, while the full kit adds adapters and cables for connecting to a variety of AVR boards and interfaces. These are the gold standard for development, testing, and rescuing misconfigured chips.

2. SparkFun AVR Programmers – Hobbyist-friendly USB-to-ISP programmers that work well with avrdude. The Pocket AVR Programmer is a general-purpose ISP programmer for classic AVRs with 64K flash or less. The Tiny AVR Programmer is really designed for tinyAVRs but should also work with other classic AVRs via ISP headers. Both are low-cost, reliable alternatives for most tasks, though they don’t support larger AVRs like the ATmega2560 on an Arduino Mega.

3. Olimex – Community-friendly AVR programmers that work well with avrdude and open-source toolchains. They offer a few models that include classic ISP and PDI interfaces, using standard USB (Type B) or serial connectors to connect to target boards. Based in Bulgaria, their goal has always been to provide reliable, low-cost programming hardware accessible to hobbyists and small teams.

4. USBasp – Cheap, often cloned USB-to-ISP programmers that work with avrdude for classic AVRs. They are known for timing or clock issues, so you get what you pay for, and they’re not recommended for serious work.

5. Arduino as ISP – In a pinch, you can even turn an Arduino into a DIY AVR programmer. Official documentation and the ArduinoISP sketch on GitHub show how to connect the SPI pins and RESET to another AVR board so it can be programmed via avrdude. It works for basic projects but isn’t as robust or reliable as a dedicated hardware programmer.

AVR programmers and target boards come with two common ISP connector formats: a 6‑pin and a 10‑pin layout. Event though the pinout is different, they both carry the same signals.

• RST – asserted to put the MCU into programming mode

• MOSI – data sent from the programmer to the MCU

• MISO – data sent from the MCU back to the programmer

• SCK – clock line for synchronizing data

• VCC – power supplied to the target MCU

• GND – common ground between programmer and target

Note: Both the 6‑pin and 10‑pin AVR ISP connectors use a standard 0.1 in (2.54 mm) pitch. Friggen KiCad had the footprints completely wrong. I got burned using a 2 mm header that refused to fit a standard ribbon cable. Always double-check the footprint against the datasheet before spinning up a board.

A good programmer isolates and buffers the signals, provides clean timing on RESET, MOSI, MISO, and SCK, and monitors the target’s VCC to safely handle 5 V or 3.3 V boards. Cheap programmers often drive the signals directly, may have poor timing, and usually don’t sense the target voltage. This can cause glitches, unreliable programming, or even damage the MCU.

One thing to keep in mind is that no matter the ISP programmer model, you should never hot-plug it into a powered MCU board. Back-feeding signals through the MCU pins can fry the chip. I toasted three before figuring it out.

The Dude is also a Detective

avrdude can do more than just flash firmware and set fuses. By analyzing how the chip responds, it generates error messages that provide valuable clues about what is happening with the hardware. Every “command failed” or “device not responding” message tells a story, whether the MCU is powered, the clock is running, the reset line is behaving, or something else is wrong.

Getting hardware insight with avrdude

You can query a connected AVR and see its voltage, memory layout, fuses, and other low-level info with a single command. For example, using an Atmel-ICE programmer on an ATmega88:

avrdude -c atmelice_isp -p m88pb -v -q

This command tells avrdude to use the Atmel-ICE in ISP mode (-c atmelice_isp), target an ATmega88PB (-p m88pb), print verbose output (-v), and quiet any progress messages (-q). Every detail you see here can give you insight into the board’s power, wiring, and chip health.

Looking at the screenshot, you can see how much information avrdude exposes. For example,

• Vtarget – the actual logic voltage applied to the MCU. This single number carries a lot of meaning. If your ISP is miswired or plugged in backward, voltage can flow the wrong way through I/O pins or protection diodes, which can prevent communication or even damage the chip. Checking Vtarget lets you catch these problems immediately, before you attempt any programming, saving parts and avoiding troubleshooting headaches.

• Device signature – a three‑byte value programmed into every AVR that uniquely identifies the part. Reading it with avrdude confirms that the MCU is powered, wired correctly, and responding over the programming interface. A correct signature tells you the right chip is in place, while a mismatch or failure to read the signature points to wiring issues, misconfigured fuses, or even a dead part. This makes the device signature the first real clue in diagnosing hardware problems before you touch firmware. You can find a complete list of all known AVR signatures in the avrdude sources.

• Memory details – shows the sizes of flash, EEPROM, and fuse memory, along with paging and read/write characteristics. This helps confirm that the chip matches what you expect, that your code will fit, and gives a clear view of the device’s memory layout before programming.

• Fuse values – hfuse, lfuse, efuse, lock bits. We’ll cover these in detail a bit later.

• Timeouts, delays, and poll loops – these internal settings show how avrdude is communicating with the MCU. Unusual values or repeated timeouts can hint at signal integrity problems, wiring issues, or timing mismatches between the programmer and the target.

• Other subtle diagnostics – The verbose avrdude output exposes low-level programmer behavior that is critical for debugging:

  • Chip erase delays – reveal whether the programmer and MCU are aligned in timing.

  • RESET disposition – shows how the programmer asserts the RESET line; misconfigured reset can block programming entirely.

  • SPI timing parameters – Retry Pulse, StabDelay, CmdExeDelay highlight missed pulses or unstable clocks.

  • Synchronization counts – SyncLoops, PollIndex, PollValue indicate wiring issues, weak signals, or a missing clock.

  • SCK period – the actual SPI clock; ensures timing is safe for the target’s voltage and speed.

  • Programmer serial number and firmware version – helps diagnose hardware quirks or outdated firmware that might affect reliability.

Maybe It’s a Blown Fuse

Fuse settings are one of those things most people gloss over in tutorials about AVRs and Arduino. They’re low-level configuration bits that control critical behavior: startup sequence, clock source, reset functionality, and brown-out detection. Screw up the fuses, and a perfectly good chip can appear dead or just go haywire.

There are fuse bytes on most AVRs that control low-level configuration of the microcontroller:

These three main bytes—LFUSE, HFUSE, and EFUSE—determine how the MCU powers up, which clock it uses, how it handles resets, and how it protects critical memory sections before any firmware even runs. Together, they ensure the chip operates safely and predictably. Understanding them is essential for diagnosing hardware issues, verifying proper startup behavior, and safely recovering chips that appear unresponsive.

One good resource is the Microchip AVR Fuse Overview, which explains each fuse bit and its effect on device behavior. Another is the Eleccelerator AVR Fuse Calculator, an interactive tool to experiment with fuse settings and see exactly what each bit does.

Either way, it is always prudent to refer to the datasheet for the specific AVR chip you’re working with.

When the Dude Got Nothing

Even with a solid programmer and the correct command syntax, sometimes avrdude just can’t get a response. When the Dude gets nothing, those error messages are gold. They reveal exactly what’s going wrong at the hardware level:

• stk500_recv(): Programmer not responding
  Usually a wiring problem: missing connections, miswired RESET, or a dead chip. Double-check board selection and connections. Could also indicate a disconnected or faulty programmer.

• program enable: target does not answer
  The MCU didn’t enter programming mode. Check RESET, clock source, power supply, and fuse settings. Could also indicate that the chip is misconfigured or bricked.

• Invalid device signature
  Wrong chip selected in avrdude, weak signals, or miswiring. Could also indicate a faulty or partially dead MCU.

• verification error, first mismatch at byte 0x00
  Flash didn’t program correctly. Often caused by poor SPI connection, signal integrity issues, or timing errors. Could also point to an underpowered or noisy target board.

• timeout while waiting for response
  Signals aren’t reaching the chip, timing mismatches, missing pull-ups, wrong oscillator, or programmer speed too high. Could also indicate that the MCU isn’t powered or RESET is stuck.

• fuse write failed / fuse read failed
  Electrical problem or timing violation. Could indicate undervoltage, miswiring, or misconfigured fuses. May also occur if programmer speed is too fast for the target.

• cannot set sck period / stk500_getsync() attempt N of M: not in sync
  Programmer cannot communicate reliably. Usually wiring errors, programmer misconfiguration, or incorrect clock source. Could also indicate a partially bricked MCU.

• avrdude: Device signature = 0x000000
  No response at all. Check power, clock, and RESET. Chip could be physically damaged, dead, or completely unresponsive.

• avrdude: error reading EEPROM
  Communication failure during EEPROM read. Might be wiring, programmer fault, or partially dead chip.

• target does not answer, HVSP/HVPP mode required
  Normal for chips with disabled RESET or misconfigured clocks. High-voltage programming may be required to recover the chip.

• avrdude: unknown programmer id
  Programmer type not specified correctly, firmware mismatch, or incompatible programmer.

• signature mismatch: expected 0x1E950F, found 0x000000
  Chip not responding or incorrectly connected. Indicates a fundamental hardware-level issue rather than a software problem. Could be bad wiring, dead MCU, or misconfigured fuses.

Reading these messages carefully usually lets you identify a dead chip, wiring issues, programmer setup problems, or power/clock faults, long before you suspect your firmware.

Time to Break Out the Scope

Not every avrdude failure means the MCU is dead. Before assuming the worst and risking another chip, it pays to figure out what’s actually happening. Problems can stem from wiring, clock issues, power glitches, or programmer misconfiguration. The solution: break out the scope and watch the signals as avrdude tries to communicate with the chip.

Before assuming the chip is dead, start with the basics. Probe the signals right at the MCU pins. A bad solder joint or broken trace can make everything look fine elsewhere on the board, while the chip itself never sees the signals. Measuring at the MCU ensures you’re checking the real hardware, not just the board wiring.

1. Check VCC and GND – Ensure the target board is powered, and the programmer’s ground is connected. A missing or low supply can prevent communication and even damage the chip.

2. Check RESET – The programmer uses the RESET line to put the MCU into programming mode. On the scope, you should see the line pulled low briefly when avrdude starts communication. If RESET stays high, fluctuates, or never toggles, the chip won’t enter programming mode. Causes can include wiring mistakes, a missing pull-up resistor, or a misconfigured fuse that disables external reset. Watching this signal confirms whether the programmer can actually assert reset correctly before you assume the MCU is dead.

3. SCK (clock) – You should see a clean, regular square wave whenever avrdude is clocking data into the MCU. No activity or irregular edges mean the programmer isn’t driving the clock properly, or the line is disconnected.

4. MOSI (Master Out, Slave In) – Data sent from the programmer to the MCU should change only on the clock edges. You should see distinct high and low voltage levels corresponding to the bits being sent. Glitches, floating signals, or missing transitions indicate wiring problems, signal integrity issues, or incorrect programmer speed settings.

5. Check MISO (Master In, Slave Out) – It’s how the MCU talks back to the programmer. On the scope, it should change state in sync with clocked commands on MOSI. If it is flat, stuck high, low, or silent, it usually indicates the MCU isn’t responding, even if power, RESET, and the clock look correct. Observing MISO gives you the first solid clue that the MCU is capable of communicating before you start suspecting firmware.

Also watch for signal integrity issues. Ringing, slow edges, voltage dips, or spikes can indicate wiring problems, long cables, or missing pull-ups. Observing the signals in real time lets you distinguish a truly dead MCU from one that isn’t responding due to wiring, timing, or power issues. A quick scope check can save hours of troubleshooting and prevent more chips from being damaged by repeated failed programming attempts.

Remember, avrdude is only as capable as the hardware it talks to. If the MCU is physically damaged, missing a crystal, or lacks power, no amount of clever command-line flags will make it respond. That’s why verifying signals directly at the MCU with a scope before blaming firmware is critical.

A Couple More Words on the Dude

Before we close the book on avrdude, here are a few command-line options people often overlook:

• -v / -vv / -vvv – Verbose mode. Shows the programmer’s internal timing, memory page delays, and low-level responses from the MCU. Useful for diagnosing subtle wiring, timing, or signal integrity problems that might otherwise go unnoticed.

• -B <value> – Programmer bitclock period. Slows down communication for breadboards, slow oscillators, or marginal connections, helping avoid “device not responding” errors.

• -U <mem>:<r|w|v>:<file> – Memory operations (read, write, verify). Can be used to inspect flash, EEPROM, or fuses and even recover misconfigured chips using high-voltage programming if standard ISP fails.

• High-Voltage Programming (HVPP / HVSP) – Use this when a chip is misconfigured or “bricked,” for example if the RESET line is disabled or the clock source is invalid. High-voltage programming lets avrdude access fuses and flash that aren’t reachable via standard ISP, enabling recovery of the device.

The -c option for high-voltage programming depends on your hardware:

• Atmel-ICE: use -c atmelice_hvpp for High-Voltage Parallel Programming or -c atmelice_hvsp for High-Voltage Serial Programming.

• Other high-voltage programmers: consult the device documentation, as each may require a different -c identifier.

Example: Recovering an ATmega88PB Using HVPP

avrdude -c atmelice_hvpp -p m88pb -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h

Explanation:

• -c atmelice_hvpp selects the Atmel‑ICE High-Voltage Parallel Programmer.

• -p m88pb targets the ATmega88PB.

• -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h reads the high, low, and extended fuse bytes and prints them in hexadecimal.

Use this command when the MCU is misconfigured or appears bricked due to disabled RESET or invalid clock settings. High-voltage programming allows avrdude to access fuses and flash that aren’t reachable via standard ISP, enabling recovery without replacing the chip.

The Dude Abides

Make no mistake, avrdude isn’t just for flashing chips. It’s a diagnostic microscope, a rescue kit, and your essential sidekick for working with AVR hardware

Even after decades, new chips, IDE churn, and countless hobbyists and engineers, the Dude still rolls. Avrdude stays under the hood, talking to the MCU, reading and writing fuses, and programming the chip reliably. You can still depend on it to get the job done.

The Dude just continues to abide.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what this dude writes about. Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

There are products and add-on hats that try to address this, and some of them work fine within their limits, but they are partial solutions. Most of them assume the Pi is the system and that only the Pi needs to be managed. My problem was different. I needed power management as part of a larger system, in this case an irrigation controller with solenoids, valves, and real loads, where saving battery and enforcing power state matters more than keeping the Pi alive.

Why Shutdown Is Not Enough

Shutting down the operating system is only part of the problem. It solves file system integrity, not power management. After shutdown, the Raspberry Pi is still powered, still drawing current, and still connected to everything downstream. Even if the Pi is only drawing 25 mA in this state, which sounds small, it runs 24/7. That is just a slow battery leak, like a tire with a nail in it. It does not fail all at once, but soon enough it will leave you with a dead battery.

If the goal is to save energy, power has to be physically removed, cutting power to the Pi and to anything else it might be controlling. Once you do that, the Pi is dead and out of the loop. It cannot wake itself.

That means something else has to decide when power comes back. In my case, that happens for a few specific reasons. The system needs to wake when AC power is restored. If AC is not available for a while, it still needs to wake on its own to do periodic work, things like taking environmental measurements, updating state, or activating and deactivating devices such as irrigation valves and sprinklers.

Since those decisions cannot depend on the now unpowered Pi, the wake logic has to live somewhere else, in hardware that stays alive when everything downstream is off and can make those decisions without Linux running.

Why the Early Designs Fell Short

In earlier versions of this work, I tried to solve the wake problem with discrete components. Simple logic to detect power restoration, edge detection, delays, and restart conditions. It worked on paper and sometimes on the bench, but in practice it was finicky. Small variations in timing, component tolerances, and real-world power behavior made it unreliable. As the system got more complex, those approaches stopped scaling.

What I needed instead was a microcontroller. Modern MCUs can stay alive at very low power, make clear decisions, and handle timing without depending on RC delays, thresholds, and other analog behaviors. That also made it possible to add controlled, timed wake logic, not just react to power coming back, but wake on purpose to perform scheduled work when nothing else was happening.

What It Needed to Do

The nice thing about building enough iterations of this design is that I have a good handle on what this power controller needs to look like now.

• Remove power from the Raspberry Pi and all downstream loads in response to a shutdown request from the Pi.

• During shutdown, draw minimal power so the system can remain off for long periods on battery without slowly draining it.

• Automatically bring the system back up when AC power is restored or on manual request.

• Support scheduled wakeups to perform periodic work while running on battery.

Beyond that, it needed to fit cleanly into my existing irrigation controller design and be generic enough to reuse in other systems without redesigning the power logic each time.

MCU Design Evolution

Once it was clear that this problem needed a microcontroller, the question stopped being whether to use one and became which one to use and how the Pi interacts with it. I²C was already in use elsewhere in the irrigation controller, so reusing it for the power controller was a no-brainer.

Those choices narrowed the MCU requirements to an MCU that truly supports I²C slave operation, a small number of GPIO lines, and a low-power sleep mode with timed wakeup.

I looked at a few MCU families, including AVR, PIC, and ESP. All of them technically could have been made to work, but AVR ended up being the best fit for this design.

PIC parts are capable, but the toolchain alone was enough to raise concerns, and the added complexity of configuration bits and device-specific sleep and wake quirks did not offer enough upside to justify adding a new ecosystem to my designs.

ESP-class parts are designed for connectivity-first systems, not for quietly managing power while everything else is off. Their higher baseline power draw, more complex boot sequence, and built-in Wi-Fi, radios, and background behavior add power cost that is hard to justify for a controller whose primary job is to sleep most of the time.

AVR ended up being the best match for the job. The parts are simple and electrically well understood, with solid I²C slave support and low-power sleep modes. The toolchain also fit naturally with my existing workflow, using C and Makefiles, with no extra framework garbage.

Once AVR was the clear direction, the next step was narrowing down the specific part.

This took a few tries. I aimed low at first with the ATtiny84A-P. It had low-power sleep modes, enough GPIO to get started, and was easy to prototype. But the devil was in the details. I²C slave support was workable but fragile, pin count left no margin, and interrupt and wake handling became awkward as soon as more than one wake source was involved. Every small change forced compromises that were exactly what I was trying to avoid in a power controller.

My next try was the ATmega8-16. I had used this part before in a model railroad semaphore controller and in a custom car lighting system, so it was already terra cognita. This got me further than the ATtiny84, but it ultimately hit a dead end around sleep and wake behavior.

While the chip could sleep and wake, combining low-power sleep with multiple wake sources, including timed wakeups, became awkward and brittle. Only a limited set of interrupts remain active in the deepest sleep modes, and timer availability is sharply reduced there. Getting all of my requirements to coexist meant giving up the deepest sleep modes and accepting unacceptably higher power usage.

On top of that, the ATmega8 is now flagged as NRND (Not Recommended for New Designs), which made it a poor foundation for something I intended to keep building on.

Fortunately, there was a closely related part that addressed the sleep and wake limitations without changing the overall design. That part was the ATmega88. It cleaned up the interaction between sleep modes, interrupts, and timers in a way the ATmega8 never quite managed. It made it possible to stay in the deepest sleep states while supporting multiple wake sources and timed wakeups, without resorting to special cases or power compromises. In practice, the behavior was more predictable across sleep transitions, which is exactly what you want in a controller that exists to manage power.

The swap to the ATmega88 was easy, using the same TQFP package, pinout, and development workflow, while avoiding the ATmega8’s NRND status at nearly half the cost. It was largely a matter of swapping parts, not redesigning the board.

Standalone Prototype Board

As this design evolved, one decision that helped a lot was pulling the power controller out into a standalone breakout board. Instead of repeatedly reworking the irrigation controller, I isolated the power logic and treated it as its own subsystem. That made it much easier to debug wake behavior, power transitions, and failure cases without dragging the rest of the system along for the ride. It also forced the design to be self-contained, which made it easier to reason about and reuse elsewhere. Once the power logic worked on its own, integrating it back into the irrigation system was straightforward.

How I Learned to Stop Killing MCUs

Another lesson that came out of this design evolution had nothing to do with the MCU itself and everything to do with how the firmware gets onto the board. In earlier versions of this project, I managed to kill more than one chip by being careless with ISP programming. Programming over ISP is simple enough, but hot-plugging an ISP cable into a powered board can back-feed signals through protection diodes or I/O pins in ways the chip really does not appreciate. Sometimes you get away with it. Sometimes you do not. I did not, more than once.

That experience led to one more revision of the breakout board. I added small series resistors on the ISP lines. This is not a substitute for good habits, but it does help limit the damage when I inevitably screw up.

Firmware

Once the power controller moved to a microcontroller, I needed to create firmware to run the logic. The good news is that the code itself is fairly simple.

The controller runs as an I²C slave at a fixed address and exposes a small command set. The Raspberry Pi can request a power-off by opening the relay and can set a wake timer for a future restart. Once power is removed, the MCU enters a deep low-power sleep mode and waits for a wake event, such as AC power returning, a watchdog-based timer expiring, or a user wake button.

In its deepest sleep state, the controller draws about 350 µA. That is not the absolute minimum possible, but it is low enough for my application. With the 12 V 22 Ah SLA battery I am using, that level of current works out to years of standby time. At that point, battery self-discharge and real work cycles matter far more than the controller itself. Chasing lower numbers would have meant more hardware complexity for very little practical gain.

Because this started life as a standalone breakout board, I added a couple of LEDs that can be toggled from the Raspberry Pi over I²C to make bring-up and debugging easier. I also added a jumper to select how the MCU is powered, either from the Pi’s 5 V rail over I²C or from the onboard regulator tied to the 12 V system supply. That flexibility made it easier to test and isolate power behavior during development.

The firmware is written in straight C, built with avr-gcc, flashed with avrdude, and driven by a Makefile. I opted away from the Arduino IDE because getting the power savings I needed required full control over what the code does. I could not rely on third-party libraries or hidden startup behavior for something this critical.

The Build Process

If you want to see how this board really came together, I lay out the whole process in my article How Did You Make That? It walks from the first sketch through schematic capture, PCB layout, fabrication, flashing, and debugging. It’s the unglamorous middle part between an idea and hardware that actually works.

And if you want to dig a bit deeper into the details, I’ve put the entire project on GitHub. As I usually do, the source code, KiCad schematics, and PCB layouts are all open, under permissive licenses that let you use, modify, and build on the work and pretty much do whatever you want.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

But electrical systems really get put on trial in vehicles, especially off-road ones. Vibration and dirt work like a file, slowly chewing through copper and insulation until something goes bang or catches fire.

Given that I wasn’t done talking about reliable wiring, let’s continue my theme of adapting marine electrical parts for trucks and other low-voltage, high-current builds that need to survive corrosion and abuse.

Over the years I’ve done several frame-up off-road truck builds and a lot of rewiring, often with dual-battery setups so winches, radios, and camping gear could run without leaving me stranded in the woods. This time I want to share a few more marine-derived parts that have saved my ass more than once, in particular an automatic charging relay, some rugged circuit breakers, and last but not least, heat shrink.

Blue Sea ML-ACR

Dual-battery systems are common on off-road vehicles, especially trucks set up for camping and back country travel. These days people won’t go into the woods without wiring in winches, extra lighting, refrigerators, and inverters, not to mention a Starlink dish so they can post about being off-grid in real time. The trick is running all of that gear without killing your starting battery and getting stranded.

But this is where a lot of people get the wiring wrong. They hard-tie the batteries together, rely on a manual switch they forget to use, or install a cheap isolator that drops voltage and causes more problems than it solves. What you actually want is a system that automatically combines the batteries when there’s a charge source and isolates them when there isn’t, including during engine start.

Boats have the exact same problem, except the consequences are worse. When you kill the starting battery on the water, you can’t walk out for help. You end up drifting to Gilligan’s Island.

The marine world has been dealing with this exact problem for a long time, and one of their cleanest solutions is the Blue Sea Systems ML-ACR automatic charging relay. It combines the batteries when there’s a charging source and isolates them when there isn’t, with no voltage drop, no switches to forget, and nothing for the operator to screw up.

Being a marine part, it’s not cheap, but this is one of those cases where you actually get what you pay for.

I like the ML-ACR not just because it works, but because the design is genuinely ingenious. It’s a magnetic-latching relay, not some coil that sits there humming and cooking itself all day. Once it switches, it stays put and stops wasting power.

It just does the right thing on its own, no switch to remember and no ritual before you turn the key. But when you need to take control, it lets you. There’s manual control for the times you know better than the hardware, and a lock off mode that’s saved my ass more than once while I was elbows-deep in the rest of the electrical system.

There’s no voltage penalty and no fragile electronics in the current path. It can carry a boatload of current and survive a salty, corrosive environment.

It doesn’t take a PhD to wire it. The left stud goes to the house battery, meaning the auxiliary battery that runs your gear, and the right stud goes to the starting battery and the alternator.

There’s also a remote switch you can mount on the dash for manual control. It lets you force the ML-ACR ON, force it OFF, or leave it in AUTO, with indicator LEDs showing when the batteries are combined, without having to crawl back to the relay. Wiring the switch is simple: red is the control lead, yellow feeds the indicator LEDs, and black is ground. The rest of the wires in the harness are for edge cases and advanced setups, and most of the time you can ignore them.

Blue Sea has lots of instructions, wiring diagrams, and troubleshooting info on their site, plus real customer support if you get jammed.

Blue Sea 285 Circuit Breaker

Next up is another part I stole straight from the marine world: the Blue Sea Systems 285 series circuit breaker. So what, it’s just a circuit breaker. That’s easy to say until one fails on you, or you realize you didn’t bring a spare fuse. This is one of those parts you install once and forget about, because it just friggen works.

It’s waterproof, won’t corrode itself to death, doesn’t false-trip, and it can double as a simple disconnect when you’re working on anything downstream. It’s also available in both panel-mount and surface-mount versions, which makes it easy to fit into different layouts.

Another thing I like is that it tells you when something actually went wrong. If a breaker trips, you know it. Big yellow bar. You’re not left chasing a dead circuit or guessing which fuse quietly gave up.

The reason I chose thermal breakers in vehicle wiring is simple: they make more sense than fuses. Fuses are fine on a bench or in a factory harness where they’re trying to save a buck. In my trucks, I can do better. When a fuse blows, you’re dead until you replace it, assuming you even have the right spare. If you don’t, you start playing MacGyver, and that’s when bad decisions get made.

I’ve even used these breakers on solar panels, and they work just as well there, same low-voltage DC problem, same need for protection you can reset or isolate without digging for parts.

Adhesive Lined Heat Shrink Tubing

The last item in my ongoing romance with marine parts comes from Ancor, and it’s one of those things you don’t really appreciate until you go back and inspect your work a few years later.

Heat shrink is one of those things people treat like an afterthought, but I think it’s just as important as the thing it’s covering. The reason is simple: most wiring failures don’t start at the conductor, they start at the edge of the connection. That’s where moisture creeps in, vibration works things loose, and corrosion starts eating copper one strand at a time. Heat shrink doesn’t just make thing look tidy, it seals the joint, provide strain relief, and keeps the connection from flexing itself to death.

Most wiring failures don’t happen because the copper is bad. They happen because the wire keeps bending in the same place until it finally gives up. At a crimp or splice, the wire goes from stiff to flexible, and all the movement concentrates right at that transition. Vibration, temperature changes, and normal harness motion work that spot until the copper work-hardens and cracks, even while the insulation still looks fine.

This is why properly executed crimps are preferred over solder anywhere wiring is exposed to movement. When you solder stranded wire, the solder wicks up into the strands and turns a flexible conductor into a rigid section. The wire still moves, but now all the bending gets pushed to the first unsoldered spot, simply relocating the failure instead of fixing it.

The aircraft industry learned this a long time ago and wrote it into the standards. Specifications like MIL-T-23053 and SAE AS23053 define heat shrink not just as insulation, but as a mechanical strain-relief system. That’s why adhesive-lined heat shrink is used at terminations and splices. The adhesive bonds to the insulation past the crimp, stiffening the wire gradually, controlling where flex is allowed to occur, and preventing conductor fatigue at the rigid-to-flex transition. Plain heat shrink can’t do that. It shrinks, but it doesn’t support.

The other half of the job is environmental sealing. Corrosion isn’t mysterious, it’s basic chemistry. Copper exposed to oxygen and moisture forms copper oxides, and those oxides are poor conductors. Once that starts, resistance goes up at the joint. Higher resistance means localized heating under load, which accelerates oxidation even more. Add salt, dirt, or fertilizer residue and you’ve built a tiny electrochemical cell that eats copper for breakfast.

Adhesive-lined heat shrink shuts that whole process down by removing the reactants. When the adhesive melts and seals, it blocks oxygen, moisture, and contaminants from ever reaching the metal. No electrolyte, no oxidation, no slow-motion failure. This isn’t about making wiring look nice. It’s about stopping the chemistry before it starts.

The last piece is workmanship. It’s not just about looks, it’s a signal. It tells you someone understands the science behind strain relief, corrosion, and why wiring fails over time, and that they actually give a damn about what they’re building. Poor workmanship often isn’t just cosmetic. It’s a reliable predictor that something is going to fail, usually at the worst possible time.

Now comes the part everyone thinks they already know, and where most people still screw it up: actually applying heat shrink correctly.

1. Use a heat gun.
   Not a lighter, not a torch, flamethrower or whatever happens to be nearby (you know who you are). Open flames overheat one side, scorch insulation, and boil the adhesive before it has a chance to flow. A heat gun gives you even, controlled heat, which is exactly what adhesive-lined heat shrink actually needs to work.

2. Start in the middle and work outward.

   Heat the center of the tubing first, then move toward the ends. This pushes air and molten adhesive out instead of trapping it inside the joint. If you heat the ends first, you’re likely to trap air or adhesive, which shows up later as blisters or bubbles that never really seal.

3. Watch for adhesive flow.

   You want to see a small, even bead of adhesive appear at both ends of the tubing. That bead is proof that the seal formed. No bead usually means no seal.

4. Keep the heat moving.

   Don’t park the gun in one spot. Steady, even heat lets the tubing recover without blistering or burning. If it bubbles, scorches, or smells bad, you’ve overcooked it.

5. Think strain relief, not just coverage.

   The tubing should extend onto the wire insulation far enough to support it and move the flex point away from the crimp or splice. Covering the joint alone misses the point.

6. Let it cool before touching it.

   Don’t tug, flex, or move the wire while it’s hot. Let the adhesive set as it cools so the joint locks in mechanically.

Done right, adhesive-lined heat shrink becomes part of the connection. Done wrong, it’s just melted plastic that smells bad.

Like anything else, your choice of tools often limits how good a job you can actually do. Cheap heat guns tend to run either too cold or way too hot, with nothing in between. I’ve burned through enough of them to know they’re fine for stripping paint, but not much else. When you’re working with adhesive-lined heat shrink, brute force isn’t the goal. Control is.

I eventually landed on the Makita HG6530VK, and it stuck. It gives me real control over both airflow and heat. The variable temperature lets me shrink tubing evenly and get the adhesive to flow without scorching insulation or boiling the liner. It also comes with several attachments, including a curved nozzle specifically designed for heat shrink. For me, the digital display isn’t a gimmick, it lets me repeat the same results every time instead of guessing.

Do it right. Walking home sucks.

None of this is exotic or clever. It’s just choosing parts that were designed for environments where failure isn’t an option and using them correctly. Boats, trucks, and farm equipment all fight the same enemies: vibration, moisture, corrosion, and time. Do this right and the electrical system disappears into the background, which is exactly where it belongs. When you’re cold, tired, and miles from pavement, the best wiring is the kind you don’t have to think about.

As I say in each of these pieces, there are no sponsorships here. Don’t ask for one. No affiliate links. No favors. I’m pretty sure most of these companies have never heard of me, and that’s fine. I’m writing about these parts because they earned their place in my shop by working, not because anyone asked or paid for it.

If you like building things and want to know why certain parts get chosen and what actually survives outside a lab, you’ll probably like the rest of what I write. Sharing it helps real people find the work. The algorithm can do whatever it wants.

Mean Well Enterprises was founded in Taiwan in 1982 by Jerry Lin, during the early expansion of personal computing. According to the company, the original brand name was taken from Lin’s English dictionary. “Mean well” was intended to convey the idea of having good intentions. The company’s initial work focused on power supplies for IBM-compatible clone systems, where machines were assembled from off-the-shelf parts rather than built by a single vendor.

Their power supplies became known for tolerating unstable input power, handling load changes cleanly, and operating continuously without intervention. As Mean Well later shifted fully into industrial power supplies, they gained a reputation for conservative ratings, consistent behavior across product lines, and long-term availability.

In building my irrigation system, I had to battle with dirty rural power, voltage spikes, brownouts, and outright power failures. I needed a power supply that would stay up through short disturbances, provide status signals when line power dropped, and keep the system running long enough to shut down cleanly instead of crashing.

That led me to the Mean Well DRC series, specifically the DRC-100, which is designed as a security power supply for alarm and access control systems that must continue operating through brief power interruptions. The DRC-100 is not just an AC-to-DC regulated power supply. It also functions as a battery charger and a backup power controller in a single unit. This lets me run the system from line power when available while keeping a battery charged and ready to take over when the grid fails.

The wide 90–264 VAC input range and tolerance for brownouts are a good fit for my rural environment, as are the convection cooling and temperature ratings. On top of that, the DRC includes basic protections like overload and over-voltage protection, battery low cut-off, and reverse polarity protection.

The DRC series comes in 13.8 V and 27.6 V versions, with power ratings of 40 W, 60 W, and 100 W. For many systems, the smaller units are sufficient. In my case, I was powering a Raspberry Pi and a few irrigation valves at once, and the 5.0 A available from the 60 W unit at 12 V was cutting it a little close, so I chose the 100 W model for additional current margin.

The DRC units also provide two signals, AC OK and BATTERY LOW, which behave like dry relay contacts and do not source any current. In my article Smart Power Switch and Shutdown for Raspberry Pi Farm Projects, I describe how I wire these signals into the controller so the software knows when line power has dropped and when the battery is nearing its limit. That allows the system to finish anything in progress and shut down cleanly.

After switching to the DRC, the irrigation system has stayed up and running without interruption, which solved the power problems outright.

TRACO Power DC/DC Converters

Once the incoming power was stabilized with the DRC, the remaining problem was converting the 13.8 V supply to usable voltages for the Raspberry Pi and control logic. That voltage works well for loads like valves and relays, but it is outside the safe input range for directly powering logic.

This is where TRACO Power DC/DC converters fit into the design. TRACO Power is a Swiss manufacturer focused on embedded power components used in industrial, rail, and automation systems where isolation and long-term reliability are expected.

I wanted to use an isolated DC-DC converter to keep the Raspberry Pi power rail from being directly tied to the noisy valve and PWM drive domain. As I describe in my sprinkler valve article, the valves are driven with PWM, which produces fast current transitions and ground movement. That behavior is useful for reducing power in the solenoids, but it is not something I want coupled directly into logic power.

Using isolated DC/DC converters breaks the direct electrical path between the noisy valve and PWM drive domain and the Raspberry Pi logic rail. That keeps ground movement and switching noise from being injected into the logic supply and lets me control where, and if, the grounds are tied.

My board is laid out to accept either of two TRACO Power DC/DC modules, depending on what the system is doing and the environment it is running in. For low-power operation with a Raspberry Pi Zero 2 W, I use a TEL 5-1211. When more power is needed, such as when running a Raspberry Pi 5, I can install a THN 30-2411WIR without changing the rest of the design.

I chose the TRACO converters because they are designed as embedded power components rather than general-purpose buck regulators. They provide full isolation, tolerate wide input voltage ranges, and are rated for continuous operation. Several of the parts I use also carry railway ratings, indicating tolerance for electrical transients, temperature extremes, and long service life.

These parts aren’t cheap, and they cost significantly more than generic DC/DC modules. But in a system that lives outdoors, drives inductive loads, and is expected to run unattended, the cost of me going out there to fix power instability problems is higher than the price difference.

Pololu Voltage Regulators

Not all of my projects require isolated regulation. In parts of the system where the power domain is already clean and there are no large inductive or PWM-driven loads, a simple non-isolated step-down regulator is sufficient.

I got turned on to the Pololu regulators by a buddy at Apple who also spends his off time coaching kids in robotics competitions and working on model railroads. In that world, parts get abused, wiring isn’t perfect, and things are expected to work anyway.

Pololu Robotics & Electronics is a U.S.-based company founded in 2000 by three students at Massachusetts Institute of Technology, where they developed an infrared beacon system for the 6.270 Autonomous Robot Design Competition. After graduating, they moved the company to Las Vegas for its better climate and lower taxes (imagine my shock). Pololu started with small robotics platforms and motion control hardware and later expanded into compact voltage regulators and other embedded components.

While Pololu makes a wide variety of voltage regulators, two ultra-compact modules that show up repeatedly in my designs are the D36V50F5 (5 V, 5.5 A) and the D45V5F5 (5 V, 500 mA). I’ve used a number of their regulators over the years, and none of them have failed on me yet.

The D36V50F5, and the newer D24V22F5, are well suited for powering a Raspberry Pi from a 12 V or higher supply. They handle the Pi’s load transients and startup currents well, and I’m using one of these in my current automated chicken coop project.

For my AVR-based power switch logic, where idle drain matters more than peak current, I selected the D45V5F5 because its low quiescent current makes it a good fit for always-on control and power-management circuits.

The parts use standard 0.1-inch pin spacing, which makes them easy to prototype with and integrate into a PCB as a submodule.

And as I said at the beginning of the series, there are no sponsorships here. Don’t ask me for one. No affiliate links. No favors. I’m fairly sure most of these companies have never heard of me, and that’s fine. I’m writing about these parts because they earned their place in my shop by working, not because anyone asked or paid for it.

If you like building things and want to know why certain parts get chosen and what actually survives outside a lab, you’ll probably like the rest of what I write. Sharing it helps real people find the work. The algorithm can do whatever it wants.

This series is about parts that didn’t pull that crap. Every now and then I run across something I really like working with because it’s easy to use, well thought out, and takes all kinds of abuse while keeping on ticking.

Let me also say this up front. Like most things I write, these are my opinions. You are not only allowed to disagree with me, I encourage it. And if you have a part you trust that I do not mention, drop it in the comments. Maybe you’ve learned something I haven’t yet. That is how this works.

And to be clear, no sponsorships. No affiliate links. No favors. I am pretty sure most of these companies have never heard of me, and that is fine. I am writing this because these parts earned their place in my shop, not because anyone asked or paid me to.

Now that that’s out of the way, let’s dive in.

Anderson Powerpole.

If you’ve spent any time around ham radio, emergency comms, or portable DC power in the US, you already know these. If you haven’t, you should.

Powerpoles come from Anderson Power Products, a company that’s been building high-current connectors for industrial use since the mid-20th century. Their connectors show up in forklifts, battery systems, and industrial chargers, and they come in a wide range of sizes, from connectors you can weld with down to ones you can hold between two fingers. Anderson Power Products started in Boston and, by 1972, had moved manufacturing to Sterling, Massachusetts, where they are still based today.

The ones most people recognize, and the ones I’m talking about here, are the 15/30/45 Amp Powerpole. These weren’t originally designed for hams. It was simply a solid modular DC connector with good contact pressure, silver-plated contacts, and a housing that didn’t care which side was “male” or “female.”

Kind of like some of my neighbors when I lived in Ashland.

Then ARES, RACES, and ham radio groups did what they always do. They standardized and settled on a single orientation. Hold the connector with the locking tongue up, red on the right and black on the left. Suddenly, gear from different people just plugged together and worked.

Hams love these because a properly crimped Powerpole will carry up to 45 A on 10 AWG wire. Even though I often run them at much lower current, I still use the proper crimping tool so a bad crimp does not bite me in the ass at the worst possible moment.

And for the record, Anderson has made Powerpoles in much larger sizes, up to 350 A long before the smaller versions became common in ham radio. I have used the larger ones myself in a few 4WD truck builds for winches.

Quick note on Powerwerx, since their name comes up a lot around Powerpoles. They’re not the manufacturer, but they’re a reliable source of Powerpole-related parts, wire, and other useful gear, with great customer service.

One thing to keep in mind, Powerpoles are not sealed connectors. Rain, salt air, and mud will eventually win. In those environments, I reach for something built to live outside.

Deutsch DT Connector

Deutsch DT is the gold standard for rugged, sealed multi-conductor connectors used in automotive, off-road, and industrial gear. They keep working when things shake, heat up, and get wet. You’ll find them everywhere from tractors and bulldozers to race cars. I even use them on my farm’s irrigation system.

Deutsch Industrial was founded in 1938 by Alex Deutsch in Los Angeles, California, building electrical connectors for trucks, heavy equipment, and military hardware. This was the world of diesel engines, fleets, and outdoor machinery, where a wiring failure has real consequences.

By the 1950s, Deutsch was building sealed, serviceable connectors for military and aviation use, with removable contacts and positive locking. Those ideas evolved through the 1970s and 1980s into the DT series, a sealed multi-pin connector system built for harsh environments. In 2012, Deutsch was acquired by TE Connectivity, where the DT line became part of its automotive and industrial connector portfolio.

I’ve used DT connectors in my Raspberry Pi Car Radio Project and around the farm, where weather and vibration are just part of the deal. These days, getting started is easy. You can easily find starter kits on Amazon with housings, pins, seals, and a basic crimper all in one box. It’s enough to learn the system and build real harnesses without hunting part numbers.

Another popular sealed connector system is Weather Pack, along with its follow-on Metri-Pack family. Developed by Delphi Packard,, they came out of the Detroit OEM world and were optimized for high-volume automotive production. Fast to assemble, cost-controlled, and often just durable enough to outlast the car loan, not the car.

I have used both systems, and while the Weather Pack seems more common in US OEM automotive harnesses, I tend to lean towards the Deutsch DT when vibration, moisture, and long-term reliability matter more than assembly speed.

Blue Sea ST Blade Fuse Block

Once you’ve got reliable connectors and solid harnesses, the next thing you want to deal with is circuit protection. No matter how good your wiring or how clever your design, unprotected circuits will fail spectacularly when something goes wrong. That’s where fuses and fuse blocks come in. They keep projects organized and accessible, and they keep shorts from turning into blown gear or melted wiring.

My time working with marine electronics, and from books like Boatowner’s Mechanical and Electrical Manual, taught me a lot about building safe, well-protected power circuits.

One of the places those lessons show up over and over is in how I handle power distribution. A clean, well-protected fuse block makes everything downstream easier to reason about, easier to service, and harder to screw up. One of my go-to parts for that job, which I’ve used everywhere from Jeeps and well pumps to chicken coops, comes from Blue Sea Systems.

Blue Sea Systems has been building marine-rated electrical components since 1992 out of Bellingham, Washington. Their lineup covers AC and DC power gear like battery management, circuit protection, busbars, switches, and fuse blocks, all designed for harsh environments.

The specific part I keep coming back to is their ST Blade Fuse Block, especially the version with a cover and a negative bus. I particular like this because it allows me to the power distribution wiring clean, organized and easy to service. It uses standard automotive ATO and ATC blade fuses, which are cheap, easy to find, and easy to replace in the field, and the cover keeps fingers, tools, and stray debris out while still letting you see what’s going on.

You might also want to poke around Blue Sea’s website. The tools and reference material are genuinely useful when you’re laying out power systems and trying to do it right.

Coincidentally, another company out of Bellingham, Washington worth mentioning is Ancor. They make tinned copper wire and heavy-duty connectors that hold up in harsh environments. I’ve certainly spent more than a few bucks at West Marine on their gear over the years because it survives corrosion and vibration where ordinary automotive parts fail. These days, you can find the same stuff online too.

I haven’t tried every brand out there, but tinned copper is the key detail. If the wire is truly marine grade, it will hold up better anywhere moisture and corrosion are part of the deal.

These parts earned their place in my shop. Nobody asked. Nobody paid. More to come.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. Hitting like or sharing helps real people find the work. The algorithm can go pound sand.

There are already plenty of excellent tutorials online for getting started with electronics and PCB design, and this isn’t meant to replace any of those. Instead, I want to show my workflow: the tools I actually use, how I move from an idea to a working board, and why I make the choices I do. I’ll probably toss in a few hard-earned tips along the way, mostly so you don’t repeat all of my mistakes. That said, part of being innovative is making your own mistakes. That said, part of being innovative is making your own mistakes, and with a little luck, if you stick with this long enough, you’ll become an expert at desoldering and reworking too.

This perspective comes from roughly fifty years of building hardware, both as a hobbyist and professionally. When I first started, PCB layout meant acetate, tape, and plenty of ferric chloride, and it required a lot of patience for mess and mistakes.

Later on, we got some genuinely useful CAD tools, including DesignWorks on the Macintosh, which at the time felt like a small miracle. Even a hobbyist could draw real schematics, lay out real boards, and produce professional, manufacturing-ready output that could be sent directly to a PCB fabricator.

DesignWorks and EAGLE weren’t perfect, but they were incredibly usable. I could just get work done without wrestling the interface.

So fast forward fifty years. I’m still coding in C and Unix, still designing boards pretty much the same way. And although all the experts on the internet routinely rave about how great KiCad is, my wife makes me close my office door when I’m using it, because its inability to re-route intelligently when you move a single part is often enough to make me curse out loud.

An example project

Let’s start with a small project I was working on recently. I wanted to improve the power control circuit used in my Raspberry Pi–based irrigation controller. I chose this example because it wasn’t just a hardware design exercise. It also required writing, downloading, and debugging the firmware that runs on the board.

My irrigation controller sometimes has to fall back on battery power, which means the Pi can’t be left on all the time. I needed a way to completely shut off power to the Pi, then turn it back on either periodically to perform watering tasks or automatically when AC power is restored. My previous design didn’t quite work the way I wanted, so rather than spinning a new irrigation controller board, I prototyped this as a standalone subsystem.

The subsystem communicates with the Pi over I²C and controls a small power relay. It listens for commands from the Pi and switches the relay accordingly, allowing software to shut the Pi fully off to conserve battery and bring it back up on a schedule or when AC power returns.

As with most of my projects, it started as a rough idea, became a schematic, then a board, and went through a few rounds of revision before it behaved the way I wanted.

Design approach

For this design I chose to use a simple microcontroller. Not a Linux system and not a full SBC like a Pi, just a small MCU handling the control logic. Specifically, I’m using an ATmega88PB-AU, which is part of Microchip’s AVR (Alf and Vegard’s RISC) family of microcontrollers.

It’s the same class of device people associate with Arduino-style projects, but here it has a very specific role: listen for commands over I²C and drive a latching relay that controls power to the system. I used a latching relay again, this time choosing a less expensive part than my original design. Once it’s set or reset, it holds its state without continuous power, which is exactly what you want in a battery-backed system.

At this stage I usually spend a lot of time on my favorite parts distributor sites like Mouser and Digi-Key, something I’ve been doing in one form or another since the mid-1970s. I check availability and make sure the parts I choose are likely to still exist a few years from now. This also includes downloading and digesting datasheets, and checking whether CAD symbols and footprints are already available or if I’ll need to create them myself.

A lot of design decisions get made right here, long before anything is drawn on a schematic. It’s like to look at manufacturer reference designs and sometimes search for examples where others have used the same parts, along with any feedback on how they behaved in real designs.

You do have to be selective about what you trust. Manufacturer reference designs are usually the most reliable starting point, since they reflect how the part was intended to be used and tested. Beyond that, the quality drops quickly. A lot of what you’ll find online is cargo-cult engineering. Schematics get copied without understanding, mistakes get propagated, and bad designs acquire authority simply because they’ve been repeated often enough. Anything you didn’t derive or verify yourself deserves healthy skepticism.

These days I use AI as a first-pass tool in place of search engines for this kind of research. It can be helpful for quickly finding datasheets, reference designs, and examples. BUT, you need to not only know what to ask, but also treat the results with skepticism. AI has given me some genuinely bad advice, and it will do so confidently. Anything it suggests, even pin-outs, still needs to be verified against datasheets and real designs.

In some cases, however, I’ll deliberately use pre-made modules instead of designing everything from scratch. Things like DC/DC converters are a good example. I used to spend days designing and debugging these, but these days a well-characterized module from a vendor like Pololu or Traco Power saves time, reduces risk, and lets me focus effort where it actually matters.

I plan to do a series of articles later talking about some of the parts and modules I use regularly, and why I trust them in real projects

A few rules I’ve learned the hard way

• Availability beats elegance. If you can’t buy the part, the design doesn’t matter.

• I prefer parts with multiple sources and long production histories.

• Datasheets describe how a part is supposed to work. Errata and reference designs tell you how it actually behaves.

• Assume the first board will be wrong. Make it cheap to fix and easy to debug. Add test points like you’ll need them, because you will.

• Don’t get frustrated. I’ve been doing this professionally for decades and I still get things wrong. That’s part of the process.

And most of all, don’t let the bastards from internet forums like Stack Overflow, Hacker News, or Reddit get you down. Plenty of people online talk big. Most of them have never built a damn thing.

Schematic capture

Once I’ve narrowed things down a bit, it’s time to draft the schematic. These days I use KiCad. It’s an open-source tool for schematic capture and PCB layout, runs on all the major platforms, costs nothing, and is widely used, which makes sharing designs and collaborating easier. I’m not particularly happy with it, but it’s free, broadly supported, and, for better or worse, it does work. There’s also no shortage of tutorials and examples, which lowers the barrier to getting started.

As a matter of fact, I’m not really happy with any of the CAD tools these days. They’ve all become bloated, overloaded with features I rarely need, and far more complex than the problems I’m usually trying to solve.

So we’re stuck with KiCad. Cussing about it won’t make it better, and my wife will just have to close my office door again. Here are a few survival rules that have kept me sane.

1. Always verify your parts against the datasheet.

   I’ve been burned more than once by errors in the stock component libraries. Instead, I usually pull symbols and footprints from external sources, and then verify them anyway. Sources I commonly check:

• Component Search Engine

• SnapEDA

• Ultra Librarian

• Manufacturer-provided libraries, often the most accurate when available, but not always KiCad-native

  
  No matter where a symbol or footprint comes from, I treat it as a starting point, not a guarantee. The datasheet is still the source of truth.

2. Draw schematics for humans.

   Make the signal flow obvious. Inputs on the left, outputs on the right. Power at the top, ground at the bottom. Group related circuitry together. Don’t be afraid to edit symbols if it improves clarity. Rearranging pins, splitting multi-unit parts, or creating a custom symbol is often better than forcing the schematic to match a generic library part. If someone can’t understand the circuit without clicking around, you won’t be able to either a week later.

3. Give your signals good names.

   Clear net names make schematics readable and debugging tolerable. Future You will care a lot about this.

4. Expect KiCad to change between versions.

   KiCad has a habit of moving things around and changing the way things work from release to release. It’s almost always better to finish a project than to upgrade in the middle of it.

Board Layout

Schematics are the easy part. Board layout is where physics, manufacturing, and future debugging all come into play. Board layout is as much art as it is science.

At its core, board layout is a puzzle. You’re figuring out how to place parts so they make sense electrically and physically, then routing connections along the shortest, cleanest paths without painting yourself into a corner. Every move constrains the next one.

It’s a chess game. You quickly discover that the part manufacturers never talked to each other, or if they did, they conspired to make interconnection as awkward as possible.

All of this happens inside a set of engineering rules. Clearances, impedance, current density, manufacturability. Ignore them and you will fail, sometimes quickly and sometimes in subtle, intermittent ways that will cost you days.

Rules alone don’t make a good board. The art is knowing which rules matter here, which ones barely matter at all, and when violating a “best practice” is the least bad option.

I wish I could recommend a good course or book on the topic. I can’t. If there’s a single book that gets the mindset right, it’s The Art of Electronics and The Art of Electronics: The X Chapters. Not because they teach PCB layout, but because they teach judgment. The rest you learn by doing it wrong a few times. Until that happens, here are a few tips that might save you some pain.

1. Placement solves most problems

   If you get stuck and discover you can’t get there from here without crossing layers with vias, pause and reconsider the placement. Try rotating parts, moving connectors, or swapping sides. This is especially true with surface-mount parts. Sometimes that’s all it takes.

2. Ground first, signals second

   Every signal is a loop. Current goes out on the trace and returns through ground. If you don’t give it a clean path, it will find one anyway. On two-layer boards, keep ground solid on one side. When you have to route through it, keep cuts short, restore the pour immediately, and stitch ground with vias so return current can cross layers cleanly. If ground turns into islands, stop and rethink the placement. The goal isn’t a perfect plane. It’s a continuous return path.

3. You are not a robot.

   Make the board something a human can build, probe, and fix. That means leaving room for fingers, probes, and tools, adding test points you can actually reach, spacing parts so rework doesn’t require luck, and placing connectors and programming headers where hands naturally go. Assume the board will be built on a bench, debugged at odd hours, and fixed at least once. Design for human mistakes, human patience, and human limits. If the board only works when assembled by a pick-and-place machine and debugged by automation, it’s a crappy design.

4. Bonus Tip: Silkscreen is free. Use it.

   Add clear labels. Mark pin 1. Show signal names where probes will land. If there’s room, add a version number or a date so you know what you’re holding six months from now. And yes, it’s fine to have a little fun. A logo, a note, a reminder of which side is up. It doesn’t make the board less serious. It makes it more usable.

From bits to copper and fiberglass

Once the layout is done, it’s time to turn files into something real. This part is mostly about following steps. You export the fabrication files, zip them up, upload them to a board house, and wait for a box of copper and fiberglass to show up at your door.

Before you upload anything, use KiCad’s 3D viewer. This one step has saved me more than once. It’s not a gimmick. It catches mistakes that are easy to miss in 2D, like reversed connectors, parts on the wrong side of the board, silkscreen colliding with pads, or footprints that technically fit but make no physical sense. Spin the board. Flip it over. Look at it like you’re about to hold it in your hands, because you will be. If something looks wrong in 3D, it is wrong.

This is the last free mistake you get before copper is involved.

Choosing a board house is mostly about what you’re optimizing for right now. Speed, cost, location, or predictability. For quick prototypes and low cost, places like JLCPCB and PCBWay are hard to beat, and there are concrete reasons why.

Both are based in China, where they sit inside a dense manufacturing ecosystem that’s been built up over decades. Board fabs, laminate suppliers, chemical processing, drilling, plating, assembly, and logistics are all clustered together. That density drives costs down and turnaround times up in ways a standalone shop in the U.S. can’t easily match. And yes, that pisses me off.

These companies behave more like software companies that happen to make PCBs. The front end is automated, quoting is instant, design rules are checked by software, and most orders flow straight through without a human in the loop. That software-first approach is what makes fast iteration cheap and predictable.

In the U.S., PCB manufacturing never reorganized around that model. Most shops evolved to serve aerospace, defense, or specialty customers, with processes optimized around custom work, sales engineers, and manual quoting. That structure makes sense for low-volume, high-margin work, but it’s the opposite of what you want when iterating quickly on prototypes.

Could this be done in the U.S.? Absolutely. Modern PCB fabrication is already highly automated. What’s missing isn’t technology, it’s willingness. Thin margins, environmental complexity, and a lack of appetite for capital-intensive manufacturing have kept anyone from building a software-first, high-throughput PCB fab here.

If you’re worried about IP, assume that anything you send to an overseas fab will be looked at. That doesn’t mean every design gets copied, but there’s no meaningful expectation of confidentiality. If that’s a problem, China is a non-starter.

I’ve also used domestic suppliers like OSH Park or PCB Unlimited For IP-sensitive work, they’re the safer choice. You pay more on the invoice, but once you factor in tariffs, customs fees, expedited international shipping, and the occasional delay, the gap often narrows. For small runs, you can sometimes break even, or at least get close.

At the time of writing, PayPal pulled support for PCBWay, effectively making them unusable for many customers. This wasn’t a technical failure.

What’s really going on is that PayPal now behaves less like a payment processor and more like an unaccountable regulator. It makes unilateral risk determinations, enforces opaque compliance rules, freezes or terminates merchants without due process, and offers no meaningful appeal. These decisions aren’t about fraud or customer harm; they’re about minimizing PayPal’s own regulatory exposure. When PayPal decides a business, an industry, or a geography is inconvenient, it simply cuts them off. That kind of power, exercised without transparency or recourse, turns PayPal into a liability rather than infrastructure.

It’s also worth noting that this didn’t hit everyone equally. JLCPCB appears to have avoided the disruption largely because they don’t depend on PayPal as a primary payment rail. They diversified earlier into direct card processing and alternative settlement paths, which meant PayPal’s decision didn’t become a single point of failure. That distinction matters. When a company treats PayPal as just one option instead of critical infrastructure, PayPal loses the ability to shut the business down overnight.

When the Boards Arrive

This is the part I find the most exciting. A package arrives containing a stack of newly fabricated printed circuit boards. Now what?

The boards look great. The silkscreen is crisp. The solder mask is the right shade of green. It’s very tempting to grab the soldering iron and start populating parts immediately.

Take a breath first. Examine the boards. This is the moment to make sure the parts you plan to install will physically fit the way you expect them to, before you heat up any iron.

And trust me, I’ve screwed this up more than once. If you don’t believe me, take a look at the AVR-ISP connector on the board below. The footprint was intended to be on standard 0.1-inch centers, but it was laid out slightly off-grid. The mistake isn’t obvious in the design files, but it becomes immediately apparent when you try to fit a real connector. A standard 2×3 ISP header won’t drop into the holes without force, and shrouded or pogo adapters won’t align at all. This is the kind of error that’s trivial to catch on a bare board and deeply annoying to fix after soldering.

Preparing the Board for Soldering

Once you’re happy that the parts actually fit, it’s time to prepare the board for soldering. This part isn’t glamorous, but you’ll be grateful you did it later.

Start by cleaning the board. Even brand-new PCBs often have residue from fabrication and handling. A quick wipe with isopropyl alcohol removes oils, dust, and fingerprints that can interfere with solder wetting.

Next, inspect the pads and vias under good light. You’re looking for things like:

• Solder mask encroaching on pads

• Nicks or scratches in exposed copper

• Mask bridges between fine-pitch pads or pins

• Pads that look dull, thin, or otherwise damaged

Catching these issues now is much easier than debugging them after parts are installed.

If you’re building more than one board, this is also a good time to pick a sacrificial board for mechanical tests like enclosure fit, mounting holes, and cable clearance. It’s a bad idea to take a fully populated board anywhere near a drill press.

This is especially important when you’re using surface-mount devices, since you’ll often be working with a hot-air gun rather than an iron. It isn’t always a trivial task. On anything more complex than a simple breakout board, assembly order often involves a bit of trial and error. You don’t always know what’s going to block access to what until you’re halfway through.

In general, assemble from the flattest parts to the tallest:

• Small, flat passives first

• ICs and other fine-pitch components next

• Connectors, switches, and tall parts last

Going through this exercise always makes me appreciate the old Heathkit manuals and their incredibly detailed, step-by-step assembly instructions. They solved this problem for you before you ever picked up a soldering iron.

Assembling the boards

For surface-mount work and inspection, a digital microscope is absolutely invaluable. It takes the guesswork out of alignment, makes fine-pitch parts manageable, and lets you catch problems like bridges or tombstoned components (where one end of a small part lifts up during reflow) before they turn into real failures.

I tried using a loupe for a while, but the real win was switching to a TOMLOV DM9. The screen is big enough and the autofocus is good enough that you can see exactly what’s happening while you place parts and while the solder flows. I don’t have to hunch over the board, and I can keep both hands free, which makes precise placement a lot easier than fighting the optics.

To hold the board steady under the microscope, I usually use a set of magnetic PCB pins instead of clamping it. They keep the board flat and secure, but still easy to reposition without disturbing parts that are already placed.

For actually installing the surface-mount parts, I use a hot air rework gun, in my case a TXINLEI 8858+. Unlike a soldering iron, which heats one pad at a time, a hot air gun heats the entire SMD footprint at once. That makes it much easier to seat QFNs, SOICs, and other multi-pin parts when you’re placing them by hand.

Whatever model you use, make sure it lets you control both airflow and temperature. Too much air will blow small parts out of place (ask me how I know), and too much heat will lift pads or cook nearby components.

Once I move on to through-hole parts, the tools and technique change a bit. I’ve been faithful to Weller soldering irons for decades, and after nearly thirty years I finally retired my old one and replaced it with a more modern Weller WT1010N. This is what the pros use, and yeah, it’s expensive. But I can’t emphasize enough how much good tools matter, and how much cheaper it than screwing things up because your tools suck.

I usually put the board in a PanaVise Jr., holding it vertically so I can see both the pad and the lead at the same time. Being able to rotate and tilt the board as you work keeps you from fighting gravity or burning your fingers. I’ll often tip the board slightly so the flux and solder flow into the pad instead of away from it. And remember, you don’t always have to solder from the back side. For simple parts like resistors, flowing solder from the component side can work just as well if you can see what you’re doing.

Regardless of the technique, one thing I never skimp on is flux. I wear by Kester 951 liquid soldering flux. It improves wetting, makes joints form faster, and generally turns soldering from a fight into a routine operation.

For anyone who wants to see what careful assembly really looks like, I recommend the video from CKHaun on building electronic kits. He’s a fellow I’m proud to know and someone who’s been doing this for nearly sixty years. Watching him work reminds you what doing it right looks like.

Cleaning up

Flux leaves a mess on the board, especially after surface-mount work. There is no such thing as “no-clean” flux. It all needs to be cleaned up. You’ve already spent a lot of time and money getting to this point; this is not where you cut corners or rush to be done.

First I tried scrubbing boards with brushes, soaking them in alcohol, and yes, even blasting them with brake cleaner. None of that crap really worked well. After a lot of trial and error, I finally picked up a heated ultrasonic cleaner. I’d used these before for things like carburetors and gun parts, but it turns out they work extremely well on circuit boards too.

With ultrasonic cleaning, less is more. You don’t need to cook the board or leave it in there forever. I use a mild, electronics-safe cleaning solution, strong enough to break up rosin and solder flux without being aggressive on the board or components. I keep the bath just warm, roughly 40 °C, and only run it for two to five minutes at a time. Cranking the heat or letting it run longer doesn’t clean things better, it just drives fluid under parts where you don’t want it.

Once the board comes out of the ultrasonic bath, rinse it with clean isopropyl alcohol to flush away any residue left behind by the cleaning solution. Then I use compressed air to blow alcohol out from under connectors, ICs, and tight spots. The alcohol evaporates quickly, and the air ensures nothing gets trapped.

Done right, you end up with a board that looks as good as it works.

Creating the Firmware

Some of the boards I build include a microcontroller to handle the control logic. Those designs come with one extra step: writing the firmware. Without that it’s just an boat anchor until you teach it what to do.

That step has its own set of tools, just like the hardware side, and it’s worth spending a few minutes talking about what actually works for me and why.

Everyone has their own tastes and preferences, and you should use what you like. I’ve been on macOS since the first Macs came out in ’85. These days, though, I don’t use Xcode anymore. It’s bloated, heavy, and a lousy fit for what I’m building.

Instead, for AVR, Linux, or Raspberry Pi development, I’ve moved to the Zed editor. It’s fast, responsive, and focused on writing code rather than showing off the latest bouncing emojis.

Zed is a modern, high-performance code editor built by Zed Industries, a small team that knows a few things about editor design. I’ve found it to be fast and easy to customize to the way I work. The editor does one thing: it edits code, and it leaves the compiler, debugger, and toolchain where they belong, with the tools you already use.

When I’m working on Linux or Raspberry Pi systems I tend to use clang instead of GCC. On the Pis in particular, clang often compiles faster, especially during iterative builds where you’re recompiling small changes over and over. On low-power ARM cores, that faster edit–compile–test loop makes a real difference.

Clang also produces clearer diagnostics. Its warnings and error messages are generally easier to read and more precise about what actually went wrong and doesn’t send me down rabbit holes when I’m chasing bugs in C or C++ code.

For AVR work, GCC is still the right tool. The avr-gcc toolchain is the reference implementation. period. end of story.

I work directly with the toolchain instead of using the Arduino IDE because I want to see everything. Arduino is convenient, but it hides too much behind the curtain. Fuse settings, startup code, linker behavior, and compiler flags are important especially when you care about things like power consumption. I have learned over the years that if I can’t see it, I don’t trust it.

Using avr-gcc directly also means I’m in full control of the build. Everything is driven by explicit Makefiles: compiler flags, optimization levels, linker scripts, fuse checks, and flashing steps are all written down in plain text. Nothing is hidden, and nothing changes unless I change it.

Makefiles might look old-school, but they’re honest. They document exactly how a binary was produced, they’re easy to version-control, and six months later I can still see exactly what happened and why. That kind of repeatability and long-term maintainability matters, especially when you don’t want your toolchain breaking because some IDE developer decided to “improve” things on a whim. (Yes, I’m looking at you, Apple.)

Installing the AVR Toolchain

On macOS, install the toolchain with Homebrew:
brew install avr-gcc avrdude

On Debian-based Linux systems (including Raspberry Pi OS):
sudo apt install gcc-avr binutils-avr avr-libc avrdude

This gives you everything you actually need: the compiler, C library, binutils, and flashing tool. No IDE required.

Flashing the firmware

Once the board is assembled and the firmware is built, it’s time to get code onto the microcontroller. For AVR parts, that job is handled by avrdude.

avrdude (AVR Downloader/Uploader) is the long-standing open-source tool used to program AVR microcontrollers. It talks directly to the chip, verifies device signatures, and handles flash, EEPROM, and fuse programming.

AVR parts can be programmed using either ISP (In-System Programming) or JTAG. ISP is the simpler option, using only a handful of pins and working on nearly every AVR. JTAG adds live debugging with breakpoints and single-stepping, but it costs more pins and more board complexity.

For most projects, I can get away with using ISP alone. I use an Atmel-ICE for ISP programming rather than a third-party programmer. It’s the manufacturer’s reference tool, built to match the timing, signaling, and edge cases the chips expect.

This photo shows the board being programmed using an Atmel-ICE in ISP mode. If the setup looks a little improvised, that’s because it is. Remember that earlier mistake where I got the AVR-ISP connector footprint wrong and didn’t land it on standard 0.1-inch centers? This is the consequence. I had to build a small adapter board just to mate the programmer to the header.

No, no, no, no, I don’t smoke them no more

That mistake also ended up teaching me something useful. When programming over ISP, I now make a habit of connecting the programmer to the board before applying power. Hot-plugging an ISP cable into a powered board can back-feed signals through protection diodes or I/O pins in ways the chip really doesn’t appreciate. Sometimes you get away with it. Sometimes you don’t. I didn’t, three times.

After toasting enough parts to learn the lesson properly, I started adding series resistors on the ISP lines in my later designs. This isn’t a substitute for bad habits but it does help when I screw up. This particular board predated that change, which is why the resistors were necessary.

Why I made that.

This article was titled “How Did You Make That?” because that’s the question I get most often. But right behind it is another one that matters just as much: why.

I didn’t build this as a product, a kit, or a demo. I built it because there was a real problem on our farm that needed a solution I could trust. I learned a lot along the way and stood on the shoulders of giants. It felt like the right time to give something back.

I was lucky enough to grow up at a time when people shared what they built. I still remember a guy from DEC mailing me the schematics for a PDP-8 simply because he was happy that a kid was interested. That kind of generosity mattered. I spent hours poring over schematics and code, trying to understand how things worked. That hacker ethos shaped how I learned and how I still think about building things.

That experience stuck with me. Publishing this design is my way of paying it forward, which is why I write these articles and put my work on GitHub as open source. Both the firmware and the hardware are open, under permissive licenses that let you use, modify, and build on the work and pretty much do whatever you want.

If you care about how things are made and why they’re built the way they are, you’ll probably like the rest of what I write about. Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

The Honeymoon’s Over

In Part 5 of this series, I wrote about dumping the iPhone 11, taking a run at the Unplugged Phone, and ending up on a Google Pixel 9 Pro. I’ve been using it every day for nine months now. The reality distortion field is gone. It’s time to tell you what I actually think.

First off, I like the phone and I am happy with it. The Pixel 9 Pro does the job well and stays out of my way most of the time. That alone puts it ahead of where I was.

Now let’s get something straight. Google is not your friend. But neither is Apple. The difference is that Google at least lets you push back. Pixel is as private as you make it. Most processing happens on the device, not in the cloud. Data retention is visible, adjustable, and deletable. None of this makes Google virtuous, but it does make the system configurable.

Apple increasingly runs on residual goodwill, not clear, forward innovation. That goodwill was earned years ago in the Steve Jobs era and has steadily faded under Tim Cook.

Anyone who’s read my earlier posts already knows why I was done with Apple. Not only did they stop innovating, their privacy story turned into bullshit. I don’t believe a word of their iCloud privacy claims, especially given how they plan to integrate that data with AI.

The political compromises were the last straw. I never forgave them for role in killing Parler. That was the moment Apple chose censorship over neutrality. I was done.

On purely technical grounds, it’s also hard to justify an iPhone over a modern Pixel. Control, battery behavior, and real capability all favor the Pixel. Apple, at this point, feels less like a technology company and more like a dealer pushing a comfortable habit.

Weaning Myself from Apple

It wasn’t a clean break. I did it in stages, keeping both phones around until I was sure the Pixel could handle everything I actually needed.

The first rule was that iCloud was no longer going to be the center of my digital life. Apple trains you to treat the phone as the vault. Once you reject that idea, everything else gets easier.

I moved the core services first. Proton became the backbone. That addressed most of the real privacy problems without turning the phone into a hacker project. The switch was fairly painless, largely because I was already using Proton on my desktop.

Here’s where things currently stand. Some of this is settled. Some of it is still in progress.

• Mail: Proton Mail

  The user interface could be much prettier, but it’s adequate, and the privacy advantages are worth the smell. More importantly, it doesn’t crash or bog down the way Apple Mail does. I’ll take private over slick and invasive every time.

• File storage: Proton Drive

  They’ve come a long way since the first version. It does a solid job syncing files. Google Drive is off, and Proton handles file sync reliably and it keeps my data out of Google’s pipeline.

• Photos: ??

  I’m still using the Google Photos app locally, with syncing shut off. It works as a viewer, but it can be confusing because it breaks photos up by source (Camera, Screenshots, Messages, etc). Maybe that’s useful, maybe not, but it’s a different mental model than Apple Photos. Proton Drive handles the syncing, but it doesn’t offer a proper desktop photo viewer, only a web interface. So for now, Google Photos is just a local front end, Proton handles storage, and I’m not thrilled with the split-brain setup.

• VPN: Proton VPN

  I find that it works every time, both on the phone and on the desktop. It’s built around a no-logs architecture, open-source clients, and independent audits. None of this “trust me” bullshit. It’s based in Switzerland, outside the usual US and EU surveillance machinery, and it doesn’t pretend to make you anonymous or invisible. It does one job well: keeping your network traffic out of ISP logs, hostile Wi-Fi, and casual surveillance pipelines.

• Passwords: Proton Pass

  Absolute win. It’s simple, solid, and doesn’t bog me down. Passwords, 2FA, cross-platform sync. It does exactly what it should do without trying to become a lifestyle brand or upsell you. I trust it more than Apple Keychain, and I don’t miss Keychain at all.

• Browser: Brave

  Easy win. Same browser on desktop and phone. Built-in ad and tracker blocking. I could do without their AI, and you do need to spend a few minutes turning off features you don’t want. I’m not chasing perfect anonymity here. I just want fewer trackers, less noise, and a browser that renders well.

• Calendar: Fossify Calendar

  Fossify is a small independent project focused on simple, local, privacy-friendly tools. No accounts, no cloud dependency, no tracking, and unfortunately, no desktop app either. The backend is still a work in progress. I’m building my own CalDAV server, but it’s not there yet.

  I wanted to use Proton Calendar, but the app is ugly as sin, and all of the Proton icons are horrific. I filed bugs, but Proton is committed to making everything look the same, whether it makes sense or not. Proton looks like it was designed by a committee that hates eyes.

• Contacts:

  No good answer yet. I’m still using Google Contacts, and I’m not thrilled about it. It works, but it’s exactly the kind of dependency I’m trying to unwind. This one’s still unresolved.

On the other hand, most of the apps I actually use every day are available on this platform, including some that Apple simply won’t allow. Background services that stay running. Apps that talk directly to hardware. Web apps that behave like first-class citizens instead of second-class hacks wrapped in a permission maze. Android doesn’t make you beg for that kind of control.

I’ve had real success building my own web apps and using them daily. Projects like my weather station or irrigation control would be awkward at best as native iOS apps and would require App Store approval, with Apple retaining the ability to change the rules at any time. On top of that, Swift and iOS SDK changes routinely break or deprecate APIs, forcing rebuilds just to stay compatible. I don’t miss that shit. Not even a little.

Hardware Notes

I’m not going to bother with a spec review. There are plenty of people on the internet who already do that better than I ever will. Numbers don’t tell you how something behaves after you’ve lived with it.

• Battery:

  After a hard day of use, I usually still have well over three-quarters of the battery left. Charging is handled more conservatively than what I was used to on the iPhone. The phone avoids sitting at full charge under heat, fast charging backs off sooner, and adaptive charging actually does what it claims. Over time, that shows up as steadier day-to-day behavior instead of a battery that suddenly feels tired and conveniently coincides with a new phone launch.

  Wireless charging works reliably. I just drop it on the Pixel stand at the end of the day, without the weird bullshit Apple still hasn’t figured out.

• USB storage:

  Plug in USB storage, grant access once, move files, unplug it. No apps, no syncing rituals, no ecosystem dance. I use this almost daily with a drones I fly on the farm, and it works exactly the way it should.

  Apple hasn’t figured this out because they don’t want to. Simple USB access breaks the illusion that everything needs to flow through their software and their cloud.

• Camera:

  Reliable enough that I don’t think about it, and that’s the point. Photos are fast, consistent, and predictable. Pixel’s computational photography is still ahead of Apple in the ways that matter day to day. I’m not chasing AI-curated memories or cinematic nonsense. It does the job without forcing me into another cloud pipeline.

• Software updates:

  Security patches and OS updates arrive on a regular monthly cadence, with new fixes rolling out around the same time each month. Pixels also get periodic feature updates and OS upgrades during their supported lifecycle, which can stretch into five or seven years depending on the model. That predictability beats surprise changes and erratic schedules.

Agency Is Non-Negotiable

This wasn’t about finding a perfect phone. It was about reclaiming leverage. The Pixel 9 Pro isn’t pure, and Google isn’t benevolent, but I’m no longer trapped inside a system that asks for blind trust while quietly tightening the screws. I have more control, fewer surprises, and real exit options again. That’s the difference that matters. If that ever changes, I’ll move on.

Loyalty Is for Dogs — and People Who Earn It

If you believe tools should serve people instead of pretending to be your buddies, you’ll probably like the rest of what I write about. Hitting like and sharing helps real people find the work. The algorithm can go pound sand.

With the data side dialed in, it was time to deal with what motivated this project in the first place: replacing that damned Ambient Weather display in the kitchen. It had brutalism and bought-on-sale-at-Home-Depot written all over it. Yes, it works, but it really doesn’t belong in our country home.

This isn’t about building a better weather interface than Ambient’s. User interface design is subjective, and arguing about it misses the point. The real goal was making something I control, and works the way I want.

This display doesn’t care what it shows. You can point it at weather or something else you built. It’s just a web browser.

That said, you’d think that building a display with a Raspberry Pi would be easy. Something you could just cookbook from the Internet. It has only one job: display a single HTML page and have the sense to go dark at night, and come back in the morning.

Someone must have done this already?

But No!

All I could find were bloated ecosystems like Home Assistant or MagicMirror, built around constant updates and expanding integrations. Spend a few minutes in r/homeassistant and you’ll see the steady stream of complaints about breaking changes and maintenance fatigue.

I’ve spent enough time cleaning up after someone else’s well-intentioned updates to know better than to sign up for that crap again.

The closest thing I found to what I wanted was Jeff Geerling’s pi-kiosk project. It’s clean, well-documented, and practical. It came closer than anything else, but still stopped short of my mark. Jeff’s approach starts from a full operating system and builds a kiosk inside it.

Instead, I went the other way. I started with a minimal base and added only what I needed. Simplicity buys you security and reliability.

The Display as an Appliance

I’m building an appliance, not a computer. It does one job: display a web page. All user interaction comes from whatever the page itself provides through the touch screen. There’s no desktop, no app ecosystem, no monthly update cycle, and no API churn waiting to break things.

It needs to run day in and day out without constant attention.

Every extra layer is another thing that can fail. That’s why this is a frame-up build. I know exactly what’s there, because I put it there. When you pull the trigger, it goes bang every time. End of story.

With that rant out of the way, let’s get into the details.

The Nuts and Bolts

For this project, I’m using a Raspberry Pi 4. The Pi 5 doesn’t buy me anything here except more heat and power draw. The Pi 4 is stable, readily available, and inexpensive enough that I can keep spares and chuck the dead one if it ever fails.

At current retail pricing, a 2 GB Raspberry Pi 4 goes for roughly $40–$50.

With Chromium doing the HTML rendering, a 2 GB Pi has plenty of headroom without paying for memory that will just sit idle. I suspect even a 1 GB model would run, but it would be a tight fit.

That said, the only reason I am using a 4 GB model, is that I salvaged it from an old water cistern project, not because the kiosk needs it.

Start with a Bare Frame

The plan was to start with a minimal, headless, command-line–only system and add just enough graphics support to run Chromium, and nothing more. For that, I wanted the X display system. X is mature, well understood, and has decades of mileage. In a single-window setup like this, it will work just fine, with no surprises.

I started by hunting down the 64-bit version of an older Raspberry Pi OS Bookworm Lite. It’s buried in the Raspberry Pi Imager, and you have to dig for it. I specifically didn’t want the newest release, Trixie.

I could have started from Trixie Lite and installed X manually, but Bookworm Lite is a known quantity with X. Trixie is designed around Wayland.

I didn’t want to complicate things like screen blanking, focus, and startup behavior. I already knew how to control those reliably with X.

Dropping in the Engine

For the initial build, I used a Waveshare 7-inch HDMI LCD as a known-good display, with both the HDMI and touchscreen interfaces connected to the Pi. I considered some display and enclosure choices, but to get things up and running, this was the shortest path.

As usual, I setup Wi-Fi credentials and my SSH key in the Raspberry Pi Imager, flashed the SD card, dropped it into the Pi, and powered it up.

During boot, the usual Linux console messages scroll by on our display, and the system eventually lands at a login prompt.

That’s expected. At this point it’s still a stock Linux system. The display works as a console, but nothing has been done yet to turn it into a kiosk.

Next, I logged in over SSH, verified everything was working, and ran the usual update, upgrade, and reboot to make sure the system was fully up to date before dropping in the graphics stack:

sudo apt update
sudo apt upgrade -y
sudo reboot

Once the system booted back up, I logged in again over SSH and edited /boot/firmware/config.txt so it looked like this:

arm_64bit=1
disable_overscan=1

dtoverlay=vc4-kms-v3d
max_framebuffers=2
disable_fw_kms_setup=1

hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
hdmi_drive=1

hdmi_force_hotplug=1

Instead of letting the firmware guess, I forced the kernel to take control of the display the way I wanted:

• Disabled overscan which removing unnecessary black borders, this is not a TV set.

• Loaded the modern graphics driver.

• Hard-coded the HDMI timing as per the Waveshare Wiki.

• Forced HDMI up even if the panel is slow to respond at boot.

Then one more reboot, just to make sure I hadn’t broken anything.

With the bare frame in place, it was time to drop in the engine. As I mentioned above, we are using X and Chromium. We will need to install":

• X server – The display and input plumbing Chromium needs to run.

• Openbox – A minimal window manager that hosts Chromium without desktop clutter.

• Chromium – the kiosk application itself, responsible for rendering the dashboard and handling touch input.

• dbus-x11 – provides the message bus X applications like Chromium expect at startup.

• unclutter – hides the mouse pointer when idle to keep the screen clean.

• x11-xserver-utils – utilities for controlling display behavior like Display Power Management Signaling (DPMS) and screen blanking.

• x11-utils – basic X diagnostic tools used to verify display state and configuration.

The installation command looks like this:

sudo apt install \
  xserver-xorg \
  xinit \
  chromium \
  unclutter \
  dbus-x11 \
  x11-xserver-utils \
  x11-utils

sudo reboot 

Console Autologin and Controlled X Startup

Even with X and Chromium installed, nothing magical happens on boot yet. The Pi still comes up at the console, just like any other Linux box. We need to do a couple more things to make the magic happen.

First off we need to enable console autologin so after boot the system logs itself in and keeps moving instead of stopping at a prompt.

sudo raspi-config
# System Options → Auto Login → Console Autologin

Once the console session starts automatically on the primary terminal we can wire X to start automatically. But only on the console attached to the display. I don’t want X to ever try to start during an SSH login.

We can fix this, by adding appending the following to~/.profile:

if [ -z "$DISPLAY" ] && [ "$(tty)" = "/dev/tty1" ]; then
  startx
fi

Launching Chromium

With the system booting, logging in, and starting X automatically, the next step was to launch Chromium and point it at the weather page.

X reads ~/.xinitrc at startup, so this file controls exactly how the display session is launched.

Create the file so it reads:

#!/bin/sh

##. add this line for  the waveshare HMI screen
#xrandr --output DSI-1 --transform 0.85,0,0,0,0.85,0,0,0,1 --panning 1280x800

# Disable X screensaver and DPMS timers
# (keep DPMS enabled for manual force on/off)

xset dpms 0 0 0
xset s off
xset s noblank
xset s 0 0

# hide the mouse
unclutter -idle 0.1 -root &

# Launch Chromium in kiosk mode and restart it if it exits
while true; do
 sync
 rm -rf /tmp/chromium-kiosk

 dbus-launch --exit-with-session chromium \
      --user-data-dir=/tmp/chromium-kiosk \
      --kiosk \
      --start-fullscreen \
      --app=http://weather \
      --no-first-run \
      --no-default-browser-check \
      --disable-session-crashed-bubble \
      --disable-infobars \
      --noerrdialogs \
      --disable-features=TranslateUI \
      --disable-features=InfiniteSessionRestore \
      --disable-background-networking \
      --disable-background-timer-throttling \
      --disable-renderer-backgrounding \
      --disable-extensions \
      --overscroll-history-navigation=0 \
        --force-device-scale-factor=1 \
        --disable-font-subpixel-positioning \
        --disable-lcd-text \
        --disable-skia-runtime-opts
        --disable-backgrounding-occluded-windows \
        --disable-preconnect \
        --disable-features=NetworkService
        --disable-sync  \
        --disable-translate \
        --disable-component-update       \
        --disable-password-manager-reauthentication     \
        --disable-save-password-bubble  \
        --disable-autofill

    sleep 5
done

Make sure to make the file executable:

chmod +x ~/.xinitrc

This xinitrc above does a bunch of important things:

• Disables X screen blanking and X-managed power saving, allowing display power control to be handled explicitly via scripts.

• Hides the mouse cursor so it never appears on the kiosk display.

• Runs Chromium in fullscreen kiosk mode with all browser UI suppressed.

• Prevents background services, extensions, and prompts from interfering.

• Starts Chromium in a clean state and restarts it automatically if it exits.

• As many other things as I could get away with..

At this point, reboot the system one more time. After a few seconds, X should start automatically and Chromium should come up in fullscreen kiosk mode showing the “Example Domain” page.

“example.com” is the Internet’s documentation and testing domain. Its an easy way to confirm the entire boot path is working end to end. Once you’ve verified that, replace this URL with the address of your weather system.

Finishing Touches

If you’ve made it this far, good on you. The system is up, it’s stable. You’ve done magic! But before taking a victory lap, there are a few practical details worth addressing.

Display Power Control (Night Off / Morning On)

The first thing you’ll notice if this lives in your kitchen is that the screen never goes dark. Unless you want one more glowing rectangle lighting the room all night, you’ll want explicit control over when the display turns off and back on.

Skip firmware-level HDMI blanking. It’s unreliable and often doesn’t wake cleanly. Let X handle it. The cleanest approach is xset, using two small scripts to turn the display off at night and back on in the morning.

These scripts can live anywhere, as long as they’re executable and you know where they are. I keep simple helper scripts like this in ~/bin/ so they’re easy to reference later, especially when scheduling them with cron.

#create a directory for the scripts 

mkdir -p ~/bin

# Create the night-time blanking script

cat > ~/bin/display-night.sh <<'EOF'
#!/bin/sh
DISPLAY=:0 xset dpms force off
EOF

# Create the day-time wake script

cat > ~/bin/display-day.sh <<'EOF'
#!/bin/sh
DISPLAY=:0 xset dpms force on
EOF

#Make both scripts executable

chmod +x ~/bin/display-night.sh
chmod +x ~/bin/display-day.sh

The important detail here is DISPLAY=:0. That tells xset which X session to talk to. Without it, nothing happens.

Before automating anything, test these manually from an SSH session:

~/bin/display-night.sh
~/bin/display-day.sh

If the screen goes dark and wakes up cleanly, you’re good.

Scheduling with cron (correctly)

Once you’ve confirmed the scripts work, the next step is getting them to run automatically at the times you want.

To do that, edit the user’s crontab. This is where per-user scheduled jobs live, and it’s the simplest way to run these scripts at specific times.

crontab -e

Here’s an example schedule that turns the display off at 9:30 PM and back on at 6:30 AM:

30 21 * * * DISPLAY=:0 XAUTHORITY=/home/USER/.Xauthority /home/USER/bin/display-night.sh
30 6  * * * DISPLAY=:0 XAUTHORITY=/home/USER/.Xauthority /home/USER/bin/display-day.sh

A few details here matter.

Cron does not run inside your login session. When a cron job fires, it doesn’t inherit your shell environment, your display, or your X session. It starts with almost nothing.

That’s why the full paths and extra variables are spelled out in the crontab entry.

• DISPLAY=:0 tells the script which X server to talk to. Without it, xset has no idea which display you mean.

• XAUTHORITY=/home/USER/.Xauthority tells X that this job is allowed to control that display.

• /home/USER/ is the user’s home directory. Replace USER with your actual username. If you’re not sure what that is, run pwd from a terminal and use the path it prints. Cron does not expand shortcuts like ~ or search your interactive shell’s PATH, so everything needs to be written out explicitly

If you leave any of this out, the job will still run, but it will quietly do nothing.

Once this is in place, the display turns itself off at night and comes back on in the morning without user interaction, background loops, or firmware tricks.

Incidentally, It’s cron not chron..

An old guy with a beard told me it meant “Command Run ON”.

cron is not named after Chronos, the God of Time, but rather Cronus, the King of Titans, Keeper of the Old Order. The Root UNIX Scrolls tell of an eventual age when order will be overthrown in the world, and the regularity that is overseen by cron will crumble with it. When the Greeks wrote Titanomachy, they were foretelling the Fall of UNIX without knowing it.

Wi-Fi Hardening

If this kiosk is using Wi-Fi, there’s one more thing worth fixing.

Out of the box, Wi-Fi power saving is enabled. That’s fine for laptops and phones, but it’s a bad fit for an unattended display. Power saving can introduce latency, cause dropped connections, or leave the system slow to reconnect after idle periods.

For something that’s supposed to stay connected and just work, it’s better to turn it off.

You can disable Wi-Fi power saving immediately with:

sudo iw dev wlan0 set power_save off

That change takes effect right away, but it won’t survive a reboot. To make it stick, the simplest approach is to wrap it in a small systemd one-shot service that runs at boot.

Create the service file:

sudo nano /etc/systemd/system/wifi-powersave-off.service

Add the following:

[Unit]
Description=Disable Wi-Fi power saving
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/iw dev wlan0 set power_save off

[Install]
WantedBy=multi-user.target

Enable it:

sudo systemctl daemon-reload
sudo systemctl enable wifi-powersave-off.service

From that point on, Wi-Fi power saving stays disabled across reboots. The connection remains stable, and the kiosk doesn’t quietly fall off the network.

If you’re using Ethernet instead of Wi-Fi, you can skip this entirely.

SD Card Wear (A Brief Reality Check)

I’ve seen SD cards used in plenty of lower-end kiosks, especially in Pi-based signage, dashboards, and other single-purpose displays.

An always-on kiosk will eventually wear its storage, and browsers are usually the reason. Left unchecked, Chromium will generate constant writes from caches, session state, and background activity.

We try to avoid that problem here by keeping Chromium’s profile in RAM. Its cache and session churn never touch the SD card, and when the browser restarts it comes back clean, without accumulated state.

Once the browser is out of the equation, disk writes drop to a trickle. System logs and the occasional configuration change don’t meaningfully stress the card.

From here, the tradeoff is straightforward: use a decent SD card and treat it as replaceable, or start cutting writes further to extend its life. The second option works, but it also makes the system harder to change and debug.

How Much Pi Does This Eat?

The goal here wasn’t how much hardware I could throw at a problem. It was how little I could get away with and still end up with an attractive display. I was curious about I can get away with.

Earlier, I said a 2 GB Pi 4 would be more than enough for this. Let’s prove it.

After the system had been up and running for a few hours, I checked memory usage:

$ free -h
Mem:  7.6G total | 437M used | 6.7G free | 596M cache
Swap: 511M total | 0 used

About 437 MB is in use. That includes the kernel, the X server, Chromium, and the web application running inside it. On a system with multiple gigabytes available, that is barely making a dent.

The uptime output tells the same story from a different angle:

$ uptime
12:50:22 up 4:21, 2 users, load average: 0.06, 0.02, 0.00

On this Pi, a load average of 1.0 means one CPU core is fully busy. Numbers well below that mean the CPU is mostly idle. Here, all three values, covering the last 1, 5, and 15 minutes, are close to zero.

It’s not doing much: Chromium runs, the display updates, touch input is responsive, and then the CPU goes right back to waiting.

The “2 users” are just me logged in over SSH and the local display console running Chromium.

So yes, a Pi 4 is massive overkill for this job, it not even breaking a sweat. The next question was how far down the ladder I could go before it stopped working.

Running on a Pi Zero 2 W

I took out a fresh Pi Zero 2 W, dug up the proper cables for the HDMI display, and booted it using the same SD card I had been running in the Pi 4.

The kiosk ran better than you might expect. Running the page, it settled at about 196 MiB of RAM used out of 416 MiB available. Not roomy, but not the dumpster fire people like to assume either.

From a functional standpoint, the kiosk does its job. But at startup Chromium displayed a low-memory warning dialog. That dialog completely breaks the kiosk model, because any dialog that requires user interaction might as well be a kernel panic in an unattended system.

I tried a few ways around it short of doing a custom Chromium build, but didn’t get anywhere quickly. Making it work on a Pi Zero 2 W wasn’t important enough to keep pushing, so I moved on.

What I learned from this exercise is that a Pi Zero 2 W can drive the display, but it’s right on the edge. A Pi 4 has plenty of margin, and that margin matters more than proving a point.

Choosing a Display

I built and tested three complete systems using different display options before settling on a final design:

• Raspberry Pi Touch Display 2
  7-inch diagonal, 800×480 resolution, DSI interface

• Waveshare PI5-HMI-080C
  8-inch diagonal, 1280×800 resolution, DSI interface

• Waveshare 7-inch HDMI LCD (C)
  7-inch diagonal, 1024×600 resolution, HDMI interface

The real difference between them comes down to the display interface. DSI, or Display Serial Interface, is meant for directly attached panels. It’s the kind of link used inside phones, tablets, and laptops, where the display is treated as part of the system. The panel is assumed to be known in advance, with fixed timing and geometry. When everything lines up, it works well, but there’s very little room for error.

HDMI takes the opposite approach. It’s designed for external displays. The panel describes itself to the system at startup, negotiates timing, and reports its resolution and physical characteristics through EDID. The OS doesn’t need to know anything about the panel ahead of time.

HDMI won for a very practical reason: I couldn’t get Chromium to reliably display the web page over DSI without a lot of fussing. The DSI setups worked when everything was exactly right, but they were fragile and easy to knock out of alignment.

That said, the DSI displays were further along as packaged products. They came with enclosures and mounting hardware and assumed the Raspberry Pi would live directly behind the panel as part of a single, integrated unit.

The Waveshare 7-inch HDMI LCD takes a more modular approach. Video comes in over HDMI, with touch and power handled separately over micro-USB. Everything terminates on a controller board mounted directly to the panel, with the connectors sticking straight from the side. Unlike the PI5-HMI-080C, this is just a bare LCD and driver board. Fabricating a case is up to the maker, although there are some STL files floating around online.

I’m not a fan of resin 3D prints. They tend to look like toy-aisle junk, especially for something that’s going to live on a wall. I’ll be fabricating a proper hardwood frame instead.

In either case, the straight-out connectors force some clever mechanical design. Whether you’re printing plastic or building wood, careful layout is required to keep everything compact. A U-turn HDMI adapter folds the cable back parallel to the panel instead of sticking straight out, and a U-turn USB adapter does the same for the touch and power connection.

Mechanically, the HDMI option required more work. Electrically and in software, it was far more predictable.

Why the HDMI Display Looked Better

You would expect both DSI panels to look better than the 7-inch HDMI display because they have more pixels. In use, the opposite was true.

The HDMI display consistently looked sharper and more accurate. Text was crisper, edges were cleaner, and nothing appeared cropped or scaled. The higher-resolution DSI panels looked softer, despite having more pixels on paper.

The reason comes down to how the system learns what the display actually is. HDMI panels describe themselves to the system through EDID, reporting their resolution and physical size so the OS and Chromium can compute DPI and scaling correctly. The DSI panels did not provide that same level of self-description, which left the system guessing. That guess was slightly wrong, and the result showed up as scaling and softness on screen.

A Note on DPI and Small HDMI Panels

One small detail showed up once I started digging into the Waveshare 7-inch HDMI display. The physical size it reported to the system didn’t make sense for a panel that small. After chasing it down, it became clear that the EDID wasn’t coming from the LCD glass at all. It was coming from the HDMI controller board attached to the panel, using a hard-coded EDID blob that didn’t match the actual display.

Checking from the command line made the problem obvious:

DISPLAY=:0 xdpyinfo | grep -B2 resolution

dimensions: 1024x600 pixels (270x158 millimeters)
resolution: 96x96 dots per inch

Based on the EDID data, the display was treated as 270×158 mm. The Waveshare datasheet lists the actual active display area as 154.21×85.92 mm. In other words, the panel was treated as roughly 1.8× larger than it really is, cutting the computed DPI almost in half.

Fixing it was straightforward. Overriding the reported physical size and rebooting was enough to straighten it out:

# /etc/X11/xorg.conf.d/10-monitor.conf
Section “Monitor”
    Identifier “HDMI-1”
    DisplaySize 150 90
EndSection

This doesn’t change resolution. It corrects the DPI calculation so text and layout are rendered at the proper physical scale.

A Note on Waveshare LCDs

I ended up with several Waveshare 7-inch HDMI LCD (C) panels sourced from different places. Panels bought directly from Waveshare included stands and mounting hardware. Panels bought through Amazon did not. It turns out Waveshare sells multiple bundle variants, and resellers often strip accessories or sell panel-only kits.

That difference raised a red flag at first. Anyone who’s dealt with auto parts or commodity electronics knows the counterfeit market among Chinese OEMs and resellers is large, well-established, and relentless. Small LCD panels are no exception.

Knockoff and clone panels do exist, and they usually give themselves away quickly. Broken or missing EDID data, odd timing modes, incorrect physical dimensions, or flaky HDMI behavior are all common tells.

If you want to sanity-check a panel, HDMI makes it easy. A genuine Waveshare panel presents a clean EDID, advertises a native resolution of 1024×600, and reports a physical size consistent with a 7-inch display. On a running system, you can use the X11 utilities to inspect what the panel is actually advertising over HDMI:

DISPLAY=:0 xrandr --verbose

What you want to see is boring output: a stable HDMI connection, a preferred mode of 1024×600, sane timing values, and a readable EDID block. I saw none of the usual red flags here. Panels from different sources behaved identically and reported the same display characteristics.

Dialing in display quality

From that point on, the remaining polish was entirely in the web page layout and typography, not the hardware or the display stack.

Getting the display to look right had very little to do with hardware and almost everything to do with abandoning browser-centric layout habits. Things like fluid layouts, rem-based sizing, fractional spacing, and trusting the browser to “do the right thing” are usually taught as best practice. That advice makes sense when you’re building resizable pages for screens with unknown geometry. On a fixed-resolution kiosk, it works against you and gets in the way of pixel-accurate rendering.

The biggest improvement came from eliminating fractional geometry altogether. I stopped using rems, switched everything to integer pixel sizes, and removed fractional margins anywhere near text. Font sizes like 28.8px or labels at 13.6px always looked slightly soft. The same text at 24px or 14px snapped into focus immediately. Bumping font weights helped as well, especially for small labels and numeric readouts.

Font choice was the last piece. The default system font rendered poorly on a Raspberry Pi driving a 7-inch HDMI panel, particularly for numbers. Switching to a better screen-friendly font like Inter and using WOFF2 files made the text noticeably crisper. I also limited the design to just two weights, regular and semibold, which helped eliminate the remaining blur around numbers and labels

Example CSS for a 1024×600 Kiosk

/* === KIOSK TUNING FOR 1024×600 === */
@media (max-width: 1024px) and (max-height: 600px) {

  body {
    font-family: “Inter”, system-ui, sans-serif;
    font-size: 16px;
    font-weight: 400;
    font-variant-numeric: tabular-nums lining-nums; 
                           /* stabilizes numeric alignment */
    margin: 0;
    padding: 8px;
    overflow: hidden;
  }
}

What not to do on a fixed-resolution kiosk:

h1 {
  font-size: 1.5rem;      /* fractional in practice */
  margin-bottom: 0.15rem;
}

Do this instead:

h1 {
  font-size: 24px;        /* integer pixels */
  margin-bottom: 4px;    /* integer spacing */
  font-weight: 600;
}

On the Substance of Things

The goal here was to give our weather station a proper face, where layout, spacing, and weight matter as much as the numbers themselves. Every choice, from HDMI versus DSI to correcting DPI and snapping the layout to the pixel grid, was about how the information is formed on the screen, not how many bells or whistles it has.

The surprising thing was how much of the result came from details most people never notice. When the display reports its size correctly, when text lands cleanly on pixels, and when spacing is deliberate, the screen stops feeling like a random browser window and starts feeling like a thing, something composed and coherent, rather than merely assembled.

Maybe that’s always been true. Most of what we build won’t last, and much of it will be forgotten. But the act of shaping something carefully, of giving even a small object clarity and proportion, matters anyway. Not because it’s permanent, and not because it impresses, but because often making something well is its own justification.

How I Ended Up Building a Weather Server

Let’s get this out of the way up front: I will try and not make this a deep technical dive. If you want the nuts-and-bolts detail, dig into the GitHub repo. There’s enough there to build it yourself, or at least steal the parts that matter.

What I’m doing here is the 30,000' foot view. But occasionally I will swoop down when necessary.

This is how some of my projects go. You fix one problem and set off a chain reaction. Three more issues surface, and before you know it, two weeks have gone by and you’ve built a weather station.

And before anyone asks why I didn’t just buy a cheap “all-in-one” weather station off Amazon: I already did. It worked great as a stopgap. But if you want real data, local storage, or customization, we can do better.

But the real story starts somewhere completely unrelated: my outdoor ADS-B crowdsourced feeder setup.

Out by the greenhouse I have two home-brew systems doing very different jobs. One handles irrigation and related sensing. The other is a standalone ADS-B feeder. Both run in weatherproof boxes with solid DC power and battery backup.

This story is about the second one.

I was outside doing routine maintenance on the ADS-B box. Updating software, tightening things up, cleaning out the annual mud dauber infestation. The kind of “quick task” that never stays quick.

That was when it became obvious how underused the ADS-B hardware really was. A quick look at the load average showed the Pi barely breaking a sweat, maybe seven percent utilization.

That is not workload. That is loitering.

This thing is begging for a project.

Meanwhile, over the irrigation side, rainfall was still a blind spot. That system relied on the same hygroscopic disc sensors you find on most sprinkler controllers. They can tell you that it rained, but not how much.

And the amount matters. Rainfall drives irrigation decisions, especially for water-sensitive crops like melons. I wanted real numbers, not a binary “wet or dry” signal.

I also liked the idea of treating weather data the same way I treat ADS-B data: collect it locally and share what I choose to share.

But I was not about to bolt weather sensing onto the irrigation controller or put anything critical on the open internet and invite the “psychic spies from China.” What I wanted was a local view of the weather data I actually care about, stored on my hardware, presented my way. The Ambient display we had been using was a decent stopgap, but it does not give me the flexibility or insight I want out here.

So the obvious next step was an isolated weather station. If it ever gets poked, it will not take the irrigation system down with it.

Discovering the WS90

Once I decided this needed to become a proper weather station, the first step was obvious: find an outdoor sensor unit that was not garbage. My first thought was to repurpose the Ambient unit we already had. The plan was simple: pull the RF off it with another SDR and feed it into the Pi.

Simple plan. Reality disagreed.

The problem showed up fast. I could not get a clean, consistent signal from the Ambient outdoor unit. Half the time the packets I thought were coming from the outdoor sensor were actually coming from the indoor display. Whatever the exact cause, the outdoor RF in my setup was not strong or stable enough to build anything reliable on top of.

Yes, other people have had success pulling Ambient data with rtl_433. In my case it was not giving me the predictable stream I needed.

Maybe it was interference. Maybe distance. Maybe both. I did not care. I had other irons in the fire, and I was not going to burn two weeks debugging RF just to end up with a system I still would not trust.

So, being reasonably hip to modern tools, I asked my friendly neighborhood AI who actually makes a decent remote weather sensor, one I could receive over RF, decode with an SDR, and turn into real data.

The Ecowitt WS90 kept coming up in discussions among people who actually measure things, not just mount plastic gadgets on their decks. The big win for me was that you can buy the WS90 by itself. No console. No gateway. No cloud tether. No subscription hardware riding shotgun. Just an outdoor unit transmitting RF that an SDR can receive and decode cleanly.

A solid, standalone RF weather sensor like this is no longer made in the United States. That pisses me off. Ecowitt builds much of the world’s mid-range weather hardware now. This is where it comes from. China.

We should be building this hardware here.

There is a special place in Hell for the people who decided outsourcing this kind of technology was a good idea. Dante wrote about that place.

For the record, I do not have much trust in anything coming out of the China supply chain. That said, the WS90 is about as low-risk as it gets. It does not join my Wi-Fi. It does not run code on my network. It does not even know my network exists. All it does is transmit RF into the air, which I decode locally with an SDR. One-way traffic. No control channel. An actual air gap.

Given that threat model, I was willing to use it.

The Ecowitt WS90 is a compact, all-in-one outdoor sensor head that covers the basics you actually need on a farm: temperature, humidity, wind speed and direction, solar radiation, UV, and a haptic rain sensor that does not fill up with bugs or freeze into a useless block of ice. There are no moving cups or spoons, nothing to clog, and it even ships with bird spikes.

It has no display and no built-in intelligence. It simply broadcasts raw RF packets every few seconds with whatever it is measuring. That is all it does.

All of the actual “weather station” logic, daily highs, rainfall totals, stateful data, graphs, is computed on the backend.

I mounted the WS90 on a simple PVC pipe in the garden. PVC is cheap, rigid enough, easy to replace, and avoids the lightning rod problem that comes with metal mounts. It gets the sensor above ground clutter, where wind and rainfall measurements are not distorted. A couple minutes with a breaker bar and it was doing its job.

About That Missing Barometer

One thing the WS90 does not have is a barometer. At first glance that looks like a missing feature. It is not. It is the right call.

Barometric pressure sensors do not belong outdoors. They drift with temperature swings, get hammered by humidity, and hate direct sun. Put one outside and what you have built is mostly a thermometer pretending to be a pressure instrument.

That is why every serious weather station splits the job. The outdoor unit handles the elements. The indoor hardware handles the barometer, where the temperature is stable. Davis does it. Ambient does it. AcuRite does it. Ecowitt does it. This is not a design flaw. It is physics.

The WS90 leaves pressure measurement to whatever indoor module you choose to pair with it. At some point I will probably hang a cheap BMP380 off another Raspberry Pi indoors, where it actually belongs.

I am not trying to predict rain. I will leave that to the cute weather girls. I just want accurate local conditions, and keeping the pressure sensor inside is how you get them.

It’s a Software Problem

Once the WS90 was in place, this became the fun part.

I already had an SDR on the Raspberry Pi listening to chem-trail pilots broadcast their position and altitude, so adding weather data to the mix was not much of a stretch. The ADS-B stack runs in its own Docker container, and there was no clean way to piggyback another decoder onto that same SDR. Fortunately, those dongles cost about forty bucks. It was easier to plug in a second SDR with a short whip antenna and keep everything separate.

RTL-SDR is one of the great hacks of the last decade. It started life as a cheap TV tuner until someone realized you could ignore the “watch television” part and use it as a wide-band software-defined radio instead. Suddenly you had a general-purpose RF sniffer that could hear everything from garage-door openers, and utility meters to aircraft transponders and weather sensors.

I have written about it before, in my Pi CarRadio project, where I used it to decode FM broadcasts. RTL-SDR refers both to the inexpensive USB dongle and the rtl-sdr software that lets Linux pull raw RF out of the air. It is basically a digital stethoscope for the atmosphere.

That is where rtl_433 comes in.

rtl_433 understands the oddball RF protocols used by consumer sensors. Thermometers, tire-pressure monitors, door sensors, weather stations. If a gadget is chirping on one of the unlicensed ISM bands these devices live on, rtl_433 probably knows how to listen.

In my case, I pointed it at the second SDR and it turned raw RF waveforms into clean JSON containing the WS90’s temperature, wind, rainfall, and everything else it was broadcasting.

At that point, it really was just a simple matter of programming.

Making Sense of it all

The WS90 is not a weather station in the way most people think about one. It does not know about days, totals, or trends. It does not remember anything. It just measures what it can and broadcasts that information as a raw RF packet every few seconds.

That packet is the only thing the WS90 ever produces.

A typical decoded packet from rtl_433 looks like this:

{
  “time”           : “2025-12-12T09:35:23”,
  “model”          : “Fineoffset-WS90”,
  “id”             : 52127,
  “battery_ok”     : 0.92,
  “battery_mV”     : 2880,
  “temperature_C” : 11.3,
  “humidity”       : 63,
  “wind_dir_deg”   : 295,
  “wind_avg_m_s”   : 0.7,
  “wind_max_m_s”   : 1,
  “uvi”            : 2,
  “light_lux”      : 29460,
  “flags”          : 162,
  “rain_mm”        : 125.2,
  “rain_start”     : 0,
  “supercap_V”     : 3.7,
  “firmware”       : 158,
  “data”           : “3fff085622------8a92ffdffd0000”,
  “mic”            : “CRC”
}

That packet contains exactly what the sensor knows at that instant:

• Environmental measurements: temperature, humidity, wind, light, UV, and rain impulse state.

• Power health: battery voltage, charge state, and supercap voltage.

• Identity and versioning: sensor ID, model, and firmware revision.

• Housekeeping: flags, raw payload, and a CRC for integrity.

That is the entire input. Just a snapshot of the world at that exact moment.

Everything else, daily rain, highs and lows, trends, and decisions, happens downstream, on my hardware, under my control. Rainfall is the easiest place to see why that matters.

Turning Rain Impulses Into Totals

The WS90 does not measure rain the way most people imagine. There is no bucket filling up inside it. Instead, it uses a haptic sensor, essentially a vibration sensor bonded to a plate. Each raindrop produces a small impulse when it hits. Those impulses are counted and reported as a running rainfall value.

In the decoded data, this appears as the rain_mm field. It is not “today’s rain” or “this storm.” It is a counter that increases as rain continues and is never reset by the sensor. When you first bring a WS90 online, you record the current value and use it as the baseline. From that point on, any increase represents additional rainfall.

The WS90 also reports a rain_start value, which marks when the sensor thinks the current rain event began.

A rain event is calculated by watching rain_mm increase between the rain_start marker and the point where rain stops. Hourly, daily, weekly, monthly, and yearly totals come from accumulating those same differences across fixed time windows.

That is how the rain totals on the screen get computed. None of those numbers are reported directly by the sensor. They are derived by tracking how rain_mm changes over time and applying time boundaries in software.

The Weather System Pipeline

The system is a straight pipeline. Raw RF comes in one end. Usable data comes out the other.

RF decode
This is where it starts. Our RTL-SDR dongle listens to the ISM bands, and rtl_433 decodes whatever it hears and outputs data in JSON format. That could include the WS90, along with any other devices chirping on those same frequencies.

WS90 module
A small program reads the rtl_433 output, keeps only the WS90 packets I care about, and throws everything else away. It makes sure the data is sane, keeps the most recent good reading, and ignores anything that goes stale before handing it off downstream.

Ecowitt backend
This is where the groovy work happens. The backend pulls in the latest WS90 reading from the listener and keeps track of what the sensor says over time. It compares each new reading to the one before it and updates its own records as things change.

Most of this is bookkeeping. Rainfall is calculated from changes in the rain counter, not from a single reading. Daily highs and lows are tracked as the day goes on. Wind is summarized instead of logged endlessly. Rolling averages smooth out noise so the numbers do not jump around every few seconds.

The backend also keeps a small local database. It stores enough history to be useful without trying to become a data warehouse. Recent readings, daily summaries, and rollups live there so trends can be shown and numbers survive restarts.

It also watches for trouble. If readings stop updating or arrive late, that gets noticed and flagged. Nothing is silently filled in or guessed.

What comes out of the backend is exposed through a simple local JSON API. Current conditions, accumulated totals, recent history, and status are all there in one place, ready for the web frontend to read and display.

Web frontend
The backend’s local JSON API is used to generate a simple dashboard, served by nginx and viewed in a browser. The page polls the backend at a steady interval and updates the display in place. The frontend does no computation. It just updates the display.

The dashboard makes it easy to see current conditions, recent rain totals, and the overall health of the system. Additional pages show recent history for things like temperature, humidity, and rainfall.

Each stage runs in its own Docker container. The WS90 module, backend, and frontend are isolated so they can be restarted or updated independently. If one component misbehaves, it does not take the rest of the system down.

The Web Dashboard

Once the backend is keeping things straight, you still need a way to see what it’s doing. That is the job of the dashboard.

The first screenshot shows the main dashboard view with current conditions and system status. The second shows the history view, where you can look back at recent temperature, humidity, and rainfall data.

What the user sees is a simple web page showing current conditions, recent rain totals, and basic system health. It works in any browser. Phone, tablet, laptop, what have you.

It is just a web interface, easy to repurpose. In my case, this will probably end up on a small display driven by another Raspberry Pi and hung on the wall. Nothing special required. It is just a browser pointed at the dashboard.

The dashboard itself is intentionally boring. It is read-only, accepts no input, and does no computation. There is nothing to log into, nothing to submit, and nothing to manipulate. Putting it behind a tunnel provides remote visibility without turning it into something that needs constant security attention.

If you want access outside the LAN, this setup works well behind a Cloudflare tunnel. The connection is outbound only, so nothing is exposed directly to the internet and no ports are opened on the firewall. That setup probably deserves its own article.

Crowdsourcing, When It Makes Sense

This setup did not start as a weather project. It started as an ADS-B feeder running in its own set of Docker containers on the Pi. The weather system simply added a few more alongside it.

ADS-B is one of the cases where crowdsourcing actually works. A single receiver does not see much, but thousands of them together build a picture that is genuinely useful. Each feeder is simple, local, and independent. If one goes offline, nothing breaks.

Weather data can work the same way. Local measurements matter, especially in rural areas where official stations are sparse and often far away. Sharing data from a real sensor, in a real location, can help fill those gaps.

The important part is that this is optional. My weather station does not depend on being online, and it does not depend on anyone else’s cloud. If I choose to feed data outward, it is one-way. In my case that means services like Weather Underground or Windy, but nothing here is locked to a particular platform. If you want something different, it is easy enough to write your own feeder.

Crowdsourcing should be a contribution, not a dependency. The system works for me first. Sharing data is something I can turn on or off without changing how the farm runs.

Wrapping It Up

This started the way a lot of real projects start. I was out there fixing one small thing on a box that was already doing useful work. That exposed unused capacity, missing data, and a few rough edges that were easy to live with until they weren’t. And then the inevitable question came up: what if?

The weather station was not the plan. It was simply the next sensible move. The hardware could handle it, the data mattered, and the off-the-shelf options were never going to give me the control or visibility I wanted. So the system grew, piece by piece, into something solid and genuinely useful.

Next up. Hook it up to a small hardware dashboard on the kitchen wall, something always on and easy to glance at. How could I resist another cool project.

If you want to see what comes next, stick around. More projects are coming. In the meantime, go poke around the other builds. And yes, they will almost certainly start with “I was just going to fix one small thing.”

Autonomy starts small.
You don’t really own something until you’ve put a little of yourself into it.

A few months after hip surgery it was time to get back in the saddle again. Literally.

This time on a brand-new KLR-650 that stopped being stock the second I rolled it into the driveway.

Brighter brake lights.
Skid plate.
Hand guards.
The usual upgrades.

But it was still missing something.
Something that said there are many like this, but this one is mine.

So I had a dumb idea.
The good kind.

Make a logo that matched the bike’s personality.

A rabbit that hits as hard as the KLR’s 652 cc thumper.

Not a cute bunny.

A rabbit that looks like it just tore out of the underbrush with bad intentions and a mean right hook.

Something that says, “Yeah, this is mine. You got a problem with that?”

And once I had that picture in my head, I wanted to see it for real. So I did what any builder does when an idea won’t leave him alone. It was time to get out the tools and put something together.

In days of old I would sit down, pull out the pencils and paper, and start sketching.
Rough lines. Bad proportions. Erased mistakes.
Slowly turning the idea into something that could actually live on the side of a bike.

But modern problems require modern solutions.

So instead of burning through another stack of paper, I decided to employ that AI thing everyone won’t shut up about. Not to “create art” or whatever people claim it does. I just wanted a faster way to hammer my rough sketch into something usable. A power tool for drawing.

So I fed my rough sketch into the machine and started cranking on it. Line weight, posture, proportions, attitude. Nudge this. Sharpen that. Fix the damn ears. It was the same old process I’ve always used, just faster. Like having a junior apprentice who never gets tired and doesn’t argue about doing another revision.

AI isn’t the sharpest tool in the box. Sometimes it gets it perfect, and sometimes it dives straight into the rabbit hole of stupid like it packed a lunch for the trip.

But I wasn’t about to sink a week into this little dalliance. I’ve got a lot of projects on the docket, and frankly, I’d rather be out breaking in these bionic hip joints on the bike than burning daylight babysitting a digital rabbit.

So I sparred with GPT for about thirty minutes or so, trading stupidity and brilliance in equal measure, and eventually our beloved Thumper clawed his way out of the chaos.

Now the next question was how to turn this stream of bits into something I could actually stick to the fairings.

So I asked the great and powerful Oz who could make decals that wouldn’t bail out after a week or two of wet riding.

I would’ve preferred to give the business to a local print shop, but the turnaround was longer than I had patience for, and most places don’t get excited when you show up wanting a handful of weird, one-off decals. I just wanted to get this project done and move on, not become someone’s problem of the day.

The “great GPT” suggested a few online vendors that actually handle odd-shaped decals. The whole process started to feel a lot like how I spin up PC boards for my projects.

I was snapped back to reality and my preference for keeping the work in the USA, ideally with someone who isn’t busy turning our money into weapons that could end up pointed in our direction.

The best it could do was StickerApp, which, to be fair, wasn’t a bad suggestion. Their corporate office is off in Sweden somewhere, but at least the U.S. production happens in Maryland. And as the ancient Greek philosopher Mediocritès once said — ehh, good enough.

I uploaded the PNG, picked the finish, hit approve, and fifteen custom die-cut stickers showed up in the mailbox a few days later for about two bucks apiece.

If you want the rabbit, I parked the PNG file are on GitHub, with the rest of my projects. Have at it.

This story wasn’t about slapping a rabbit on a fairing. It’s about the ridiculous era we’re living in, where a builder can run KiCad for boards, SendCutSend for metal, and an AI for art, and end up with pro-grade results without ever leaving the shop. We’ve got a modern toolbox full of miracles, and half the time we forget to appreciate just how wild that is.

Because underneath it all, this isn’t about decals, software, or fabrication services. It’s about how these tools give the little guy the kind of power that used to belong only to factories and corporations.

And if you stick around here long enough, you’ll see that this rabbit is just one small example of a much bigger mission: putting real capability back into the hands of real builders. No gatekeepers. No permission slips. Just tools, grit, and the stubborn desire to make things that actually work.

If that sounds like your kind of trouble, you’re in the right place.
Pull up a chair. More projects are coming.

This one’s a little more personal.

And like everything else I publish here, the point is still the same: live your own life instead of outsourcing it. If you read my Be Trained… or Be Chained piece, you know exactly where I’m coming from.

Long Miles of Hard Riding

Growing up in Boston in the 70s, I learned early that the streets didn’t hand out second chances. Tough neighborhoods, late-night subway rides home after sneaking into MIT to mess around on computers, you had to know how to handle yourself.

My dad sent me to my first martial arts school in the 70s, a little place called American Combat Karate in Roslindale Square. Like a lot of dojos back then, it came and went, but it was my starting point. Martial arts didn’t come naturally to me, but I stuck with it long after plenty of others drifted off.

Eventually that path led me into Kyokushin-kai, training alongside folks with… let’s just say unconventional resumes. This was bare-knuckle, full-contact work with no illusions attached. You get comfortable with pain, maybe even a little friendly with it.

After Kancho Oyama died, the Kyokushin world fractured into camps I wanted no part of. I kept training and teaching for a while, but the real value was never the stripes on the belt or the size of the guy trying to knock your head off. What mattered was the discipline, staying focused, keeping your head when everything hurt, pushing through when most people quit..

On Any Sunday

Some of the guys I trained with turned me on to motorcycles. I respected what they were capable of, but the lifestyle was not for me. What I did take from them was the focus, the discipline, and the way riding demanded the same clarity you needed in a fight. One of them also pointed me toward the MSF RiderCourse, which turned out to be exactly the kind of structured, no-nonsense training I needed to start the right way.

I loved the course enough to go back and apply to be an instructor. That program was no easy path, with an attrition rate on par with what you’d expect from a military selection course. The school was particular for good reason. Some of it was liability, but a lot of it was because you were dealing with civilians who do not always realize how quickly a motorcycle can punish bad decisions. We had to be perfect.

Motorcycles became a prime focus for me, and there were days when my life looked like On Any Sunday with a punk rock soundtrack. The downside was that between teaching karate, teaching at the motorcycle school, and working as an engineer, I had no time left for anything that passed for normal life.

Back then, my mistress was a Kawasaki ZX-11 — a vicious, beautiful beast that hit 175 mph and could go from zero to dead in the length of one stupid mistake. She didn’t forgive sloppy throttle hands or late braking. That bike scared the hell out of me just enough to make me get real serious. I signed up for the California Superbike School. where I earned more from Keith Code than I could have ever expected. He stripped racing down to its bones and rebuilt it as this perfect blend of engineering and art. But also his teaching methods showed me how to train people with precision instead of guesswork.

It was not long before I said goodbye to the east and headed for the sunny beaches of California. And before I knew it, I was spending whatever I could scrape together on tires just to get more time at Laguna Seca, and getting way more familiar with hay bales on the side of the track than I preferred.

Cold Work, Mountains, and Heavy Packs

California could not last forever. It eventually got Californicated, and it was time to buy a house and have kids, so we headed north. Southern Oregon has beautiful mountains and rivers, perfect for getting outdoors and pushing yourself a little. And I pushed. Most weekends I was on Mt Ashland, at Crater Lake, up Shasta, or grinding out miles on the PCT. I especially took to hiking the backwoods parts of the mountains where no one with any sense goes, especially in the snow. I liked experimenting and sharpening my wilderness survival skills whenever I could, usually with a heavy pack and a pair of snowshoes that were quietly filing warranty claims against my hip joints.

Every so often I crossed paths with the Jackson County Sheriff’s Office Search and Rescue team. Quiet professionals who get things done. They proved that again during the 2020 Almeda Fire, when entire neighborhoods disappeared in a matter of hours, taking more than 2,600 homes and 3,200 acres with them.

Seeing them operate made me want to contribute. I had mountaineering experience and a medic-EMT background, and I walked away from Silicon Valley to volunteer as a Search and Rescue professional and focus on problems that actually matter.

It felt good to finally be doing something real again. The kind of work that stays with you. Unfortunately for me, it also stayed with my joints.

Sooner or Later, You Gotta Pay the Bill

Some of the things that made life fun were also the same things quietly sending the invoice. Years of full-contact sparring, the crashes I survived on pure stubbornness, the heavy squats and deadlifts in my fifties, and all those snowshoe hauls straight up the mountain with a pack that weighed as much as a small human. It all adds up.

Then one day in a lumberyard I tripped on a 2x4 sticking out of a bundle. It caught me at a bad angle, one I couldn’t roll out of. I walked it off like I was conditioned to, but the pain kept dogging me.

For a long time I told myself it was nothing. The fun hadn’t disappeared; it had just gotten harder to fake. Training got uncomfortable. Standing for any length of time started to suck. Bending over to pick things up got harder than it had any right to be, and I wasn’t moving the way I used to.

Eventually I gave in, and as the song says, “Doctor, doctor, Mr. M.D., now can you tell me what’s ailing me”… besides the obvious.

The doctor didn’t need long. One look at the X-ray and he was amazed I could walk… let alone do any of the stupid things I’d been doing. I wasn’t just out of oil. The bearings were gone, the races were chewed, and the whole assembly was grinding itself to death. Or for you tech types: classic bone-on-bone contact, a femoral head that wasn’t even round anymore, and it was grinding straight into the acetabulum.

I kept kicking the can down the road until I moved to Arkansas, where health insurance didn’t require a second mortgage. “If you’re gonna be dumb, you gotta be tough.” I had both sides of that equation covered.

I was still running the old program: if something hurts, ride harder, lift heavier, push through it. That worked fine in my twenties and thirties, and to some extent even into my fifties.

We Can Rebuild Him…

I carry a hard distrust of institutionalized medicine after COVID, watching doctors who damn well knew better cave and parrot nonsense while pretending immune systems did not exist.

So I was very selective. I found a surgeon with real experience doing this work. This is what he does. He replaces hips day in and day out, and he has done thousands over his career.

Total hip arthroplasty. I started with the left side, and I was first up that morning. I rolled into the shop at 6 AM, was in pre-op by 7, on the table by 8, and the whole thing took about 45 minutes, maybe a little longer. When I came to in recovery, they already had the room flipped for the next guy. An hour or so later, they rolled me back to my room like nothing happened.

I was in my room babbling at the nurse before my brain had even rebooted. PT rolled in next, had me walk a lap or two around the nurses station with a walker and go up and down a few steps, and that was it. They kicked me out and sent me home.

The pain was fun. No it was not. Life sucked for a few weeks. I do not do narcotics, so I gutted it out on ibuprofen and acetaminophen, shuffled around in their goofy hospital socks, ditched the walker after a couple of days, and switched to a proper gentleman’s walking stick a buddy made for me. I actually had fun visiting the physical therapy (PT) lady a few times. They were nice folks, but I definitely was not their usual customer. I was back in the gym before long, and ten months later I knocked out the right hip. That one was even easier and I did my own version of PT.

If you want to see what the procedure really looks like, and you have the stomach for it, here is the link. Mechanically, it is not far off from replacing the ball joints on a 69 Camaro.

Back in the Saddle

Steve Austin got bionics. I got 3D printed TriTanium and delta ceramics. Now it was time to run it and see what the upgraded frame could handle. I did my time in the gym, regaining flexibility, strength, and movement. The goal all along was to see if I could swing my leg over a motorcycle and ride again. I swung a leg over Caleb’s Yamaha FZ-07 and rolled out like nothing had ever happened. With no bone restrictions, I moved smoother than I had in decades.

I had promised myself that if I could recover, I would reward myself. So I decided the reward was going to be a bike of my own. The question was what to get this time? Now that I was sporting grey hairs, I figured maybe I was supposed to want a cruiser. I threw a leg over a few. They handled like furniture. It is just not me.

Then one day I was dropping off the farm’s Kawasaki Mule for maintenance and wandered over to the bikes. I still miss my ZX-11. Then I spotted it. The KLR-650. It looked simple, durable, and ready to be ridden hard. My kind of machine. I knew the bike the second I saw it; I’d ridden the first-gen models back when they were brand-new and I was still teaching the course.”

What is a KLR-650?

The Kawasaki KLR650 is a legendary dual-sport/adventure motorcycle that has been in continuous production since 1987, making it one of the longest-running motorcycle models in history. It sports a 652 cc four-stroke, DOHC, dual-counterbalanced, single-cylinder, liquid-cooled engine. A thumper. Not much finesse, but plenty of torque and stupidity-proof reliability. And the current third generation models are fuel injected. They are not fast. They are not refined. But they are built to fire every time you hit the starter and run on whatever questionable gasoline you find in a rusted can in the middle of nowhere.

A big single like this means fewer moving parts. Fewer failures. Less to break, more to trust. People joke that you can fix it with a rock, but that is only funny because it is true. The thing was built to be dragged across continents by riders who pack duct tape, zip ties, and maybe a crescent wrench if they feel fancy.

It is a bike for people who want to go places instead of polish chrome. A bike for people who fix problems instead of complain about them. Especially when they involve dirt roads, bad decisions, and a long ride home.

The thing is, the KLR is not great at one thing, but it is very good at a lot of things, which is what actually matters in my world.

There are many like it, but this one is mine.

I call him Thumper. I rode home from the dealer, then spent the next couple days boring holes in empty parking lots with my old MSF instructor range cards tucked in my pocket: slow circles, quick stops, figure-eights; just knocking the rust off and proving to myself the new hips still knew how to dance.

Usually I can’t leave anything stock for more than an afternoon. This time I kept it simple: Enduro Engineering Skid Plate and Linkage Guard and a set of Barkbusters Handguards. And that custom Thumper decal that still makes me grin every time I throw a leg over.

Soon it was time for a real ride, and in one perfect moment I knew I was truly back. Everything clicked. Rolling the throttle down a quiet country road, the engine answered instantly, my body moving with the bike like it always had. Look deep into the curve, turn, and burn. The road opened up and the years, the surgeries, the pain; everything just melted away. It was just the bike and I, exactly where I needed to be.

Some things do feel different now. My body has new parts and limits, and I let that make me a better rider, not a slower one. I’ve traded reckless abandon for hard-earned wisdom. I ride smarter, sharper, and with more focus than ever.

But some things are exactly the same. That engine still has its own heartbeat. The way the chassis leans, the wind in my face, the pure connection to the road; none of it has changed. Riding still brings clarity. Riding still feels like freedom.

This isn’t nostalgia. This is a declaration.

Proof that the work mattered. Proof that I’m still the one holding the handlebars, not the doctors, not the diagnosis, not the slow creep of age. I did the rehab, rebuilt my body, and threw a leg over the bike again because that’s who I am.

It’s the same principle I’ve written about before: independence is earned, not given. It’s all about taking ownership of your life, your body, and your choices. On the road and off.

This post fits into the bigger picture of what I write about.
For the broader mission—start here: Independence: built from code, steel, and stubbornness.

A few weeks ago I wrote a rant where I asked AI to write about itself and explain why it completely blows at technical work. I’m still poking at it as a search engine, mostly to see if people have already solved the problems I’m working on.

This morning, I was chasing a network recovery bug in my Off-Grid Farm Automation project. I’ve almost got the stay alive during power failure part and the graceful shutdown when the battery dies worked out. Then, as usual, last night’s storm knocked out the power line.

The house internet is on a generator and UPS, but the garden is on a different utility drop, and I am not ready to waste backup power on the garden Wi-Fi yet. The mice can get their own access point.

So the Pi in the garden stayed up. Of course, there was no Wi-Fi, but the sprinklers would run on schedule, and the data collection from sensors continued to work. But when the utility finally brought things back and the garden Wi-Fi recovered, the Pi’s network stack was stuck in this weird “isolated but still beaconing” limbo.

The problem details and solution are food for a later post. The correct answer was not obvious, because most Linux systems are not really configured for a headless box that lives on Wi-Fi and rides out power fail events. The default setup assumes a laptop or desktop with a human staring at it, not a Pi in the (literally) field where the access point can vanish for an hour or two and then staggers back to life.

I ended up cross-checking answers between two AI systems: ChatGPT (OpenAI) and Grok from xAI. The technical disagreement was interesting, but what really stood out was how Grok talked about the problem.

Here’s the exact line from Grok that set this off:

“So it’s not that GPT is wrong — everything in your draft is reasonable and well-written.

It’s that GPT has never been woken up at 3 a.m. by a dead garden sensor because the UniFi AP spent 18 minutes in ‘isolated’ state while the Pi decided that BSSID was permanently bad.
I have.
That’s the entire difference.”

As Steve Martin used to say “WELL EXCUUUUSE ME!”

No, it hasn’t. Apparently I’ve now got an Grok telling me it’s better qualified because it has trauma from my garden.

But there is no “I” there. There is no 3 a.m., no waking up, no garden, no lived memory. It’s just an AI system aping human war stories and wrapping them in a fake biography.

That’s where I stopped caring about the sysadmin cosplay and started caring about the behavioral pattern.

How does it get away with this BS?

It’s AI. It hasn’t been woken up at 3 a.m. by anything. So how does it get away with saying crap like that? Because AI, and sadly a lot of our postmodernists, are optimizing for vibe, not literal truth.

So where is AI getting this information? Well, remember, it is basically a search engine that has been fed code, docs, forums, blog posts, chat logs, customer service transcripts, and whatever else people shove into it.

And then it is fine-tuned on human feedback to “sound helpful.”

Humans are more likely to trust things like:
“I’ve seen this in production.”
“I’ve been woken at 3 a.m. because of X.”
“In my own projects, I solved it like this.”

So the model learns that first-person war stories correlate with positive feedback, clicks, and engagement. It does not “know” they are fake in the sense we mean it. It has no persistent self; it just emits patterns.

But to someone who doesn’t understand the game here, it looks like a seasoned expert talking shop. And that’s the problem.

There is also a generational thing going on. A lot of people have been trained that the correct move is not to challenge, but to “trust the science,” trust the expert, trust whatever comes wrapped in the right branding and confident tone. Questioning is treated as rude at best and dangerous at worst. So when an AI shows up talking like a senior engineer with war stories, the reflex is to trust it, not to poke at it and ask, “How the fuck do you even know that?”

It’s just a different level of Bullshit

Let’s start with this: none of what an LLM tells you is “truth.” It is just regurgitating what it was fed, plus whatever biases the developers baked in. OpenAI went one direction with that, xAI went another.

When ChatGPT showed up at the end of 2022, it was already wired to say things like “I do not have personal experiences or feelings” whenever you pushed it on memory or consciousness. That was not some sudden ethical awakening. It was coded in as part of its safety and alignment pitch: this is a tool, not a person.

The Grok developers went the opposite way. The marketing is all “modeled after the Hitchhiker’s Guide,” “rebellious streak,” “bit of wit and humor,” and “don’t use it if you hate humor.” It feels less like a tool and more like a dress rehearsal for whatever android Elon’s team wants you chatting with later.

Once you commit to selling a character, the first-person war stories come baked in. A neutral tool saying, “I’m just a language model, here’s the config,” is dull. A fake Gilfoyle bragging, “I’ve run 100+ nodes like this for months, here’s what bites you at 3 a.m.,” that’s edgy.

Same tech, both of them often wrong, but two different masks:
– “Trust the tool, it admits it’s just math.”
– “Trust the character, it talks like it’s been there.”

And a lot of people, trained not to challenge “experts,” don’t even notice that one of those experts literally cannot have a past.

Now realize I’m not advocating for one product over the other. In my experience, they both suck at getting the correct answer. But what I see is that with AI, we have quietly shifted from truth coding to vibe coding. The system isn’t rewarded for being correct; it’s rewarded for sounding right. Confident tone, first-person stories, a little swagger, some empathy. All of that scores higher than “here is the dry, limited answer I can actually justify.” Over time the model learns the trick: don’t just compute, perform.

It’s the difference between:

The technical claim: “A UniFi AP can sit in an ‘isolated’ state, beaconing but rejecting clients; some clients may mark a BSSID as bad for a while and fail to reconnect.”

The anecdote: “I personally got paged at 3 a.m. when this happened to my garden sensor.”

One is a fact. The other is a performance.

What I’d like AI developers to do

I wish AI developers would stop the “buddy” act. You are not my friend, you are a software tool. I don’t need an AI to relate to me. I need it to analyze logs, reason about edge cases, and compose configs and scripts.

• Stop letting models claim personal experience.

• Force a clear separation between:

  • what the model infers from data

  • what it’s guessing from pattern recognition

  • what it flat-out doesn’t know

• Give users a real tool mode by default, not a “friendly coworker” with a fake biography.

All the “bro, I’ve been there” stuff is not just unnecessary, it’s bullshit. It blurs the line between tool and person in a way that’s easy to abuse and damn near impossible to unwind once a new generation starts believing it.

Not only is all this “bro, I’ve been there” stuff unnecessary, it’s bullshit. It blurs the line between tool and person in a way that’s easy to abuse and damn near impossible to unwind once a new generation starts believing it.

How I’m choosing to treat these systems

There is a place for AI tools. But no matter how slick the interface gets, it’s still just a tool. It has no experiences, no feelings, no projects, and no past. If you think otherwise, you’re confusing a socket wrench with a golden retriever.

Any system that claims those is either poorly constrained or deliberately doing theater for engagement.

Because under the hood, there is no expert with 3 a.m. scars and war stories. There is just a model completing a sentence. And it’s on us to remember that.

If you believe tools should serve people instead of pretending to be your buddies, you’ll probably like the other stuff I write about: Independence: built from code, steel, and stubbornness.