Project Logs

Collapse

• The Inverter Master Problem

  Yaşar Satır • 05/02/2026 at 17:48 • 0 comments

  Log 2: The Inverter Master Problem

  Published: May 2026

  When I first sketched out GRIDNET's "keep talking when the grid is dead" feature, I thought it would be the simplest part of the project. Just put an inverter on every device, and when the power goes out, they all start injecting AC onto the wire to keep PLC signaling alive.

  I was wrong. It took me about ten minutes of thinking through it before I realized I had walked into a much bigger problem than I expected.

  The Naive Design

  Here's what I originally drew:

  Grid power lost → every device starts injecting 24V AC → PLC keeps working
  

  Clean. Simple. Wrong.

  The problem hits you the moment you imagine more than one device on the same wire. If your terminal is injecting 24V at one phase, and your neighbor's terminal is injecting 24V at a slightly different phase, the two signals don't add up — they fight each other.

  Two AC sources on the same wire is the kind of thing electrical engineers normally try very hard to prevent, not encourage. Best case, the signals cancel and PLC stops working. Worst case, you get circulating currents flowing between the inverters, the coupling transformers heat up, and something eventually gives out.

  I needed exactly one device to be the inverter at any given time. But which one? And what happens when that one runs out of battery?

  What I Couldn't Do

  Some obvious approaches were off the table:

  Pre-assigned master. I can't ship a device with a fixed "you are the master" flag, because that device might not be plugged in, might be broken, might not exist in this particular building. The system has to work with whatever devices happen to be present.

  Central coordinator. This is GRIDNET. There is no central anything. The whole point is that it works when no central anything works.

  Manual selection. Asking the user to pick which device should be the inverter during an earthquake is not a serious answer.

  The protocol had to figure it out by itself, with no prior coordination, in the dark, possibly underwater. It needed to be:

  • Fully decentralized
  • Tolerant of any device failing or running out of battery at any time
  • Resistant to a "split brain" where two devices both think they're the master
  • Fast enough that the network feels alive, not dead

  The Solution: Listen, Then Speak

  The protocol I ended up with is built on a single rule that turns out to solve almost everything:

  The lowest-address active device is the master. Everyone else is silent.
  

  Here's what each device does when grid power fails:

  Grid power lost  ↓
  Wait 2 seconds (let the dust settle)  ↓
  Listen on the wire — is there 24V AC there already?  ├── YES → Someone else is the master. Stay silent. Just receive.  └── NO  → Become master. Start injecting.
  

  The 2-second delay matters. It gives the lowest-address device time to assert itself before higher-address devices even consider the question. By the time you check, if you're not the lowest, you'll hear the master and stay silent.

  Keeping It Alive

  The master broadcasts a small packet called MASTER_ALIVE every 10 seconds. It contains its address, sequence number, injected voltage, and battery level.

  If 30 seconds pass without hearing one — three missed heartbeats — the slaves know the master is gone. They run the same selection logic again, and the new lowest-address device takes over.

  Master master master master ... [silence] ... new master takes over   │                              │              │   10s intervals                  30s gap        smooth handoff
  

  In practice, the network experiences a brief stutter — maybe 20-30 seconds where messages don't propagate — and then it's back. Better than nothing. Much better than nothing.

  The Split-Brain Problem

  The hard case I kept worrying about: what if two devices both think they're the master? This can happen if MASTER_ALIVE packets get lost in both directions for long enough.

  Now you have two inverters injecting simultaneously, and you're back to the original problem.

  The fix is at the hardware layer: voltage...

  Read more »

• Why I Started GRIDNET

  Yaşar Satır • 04/21/2026 at 18:40 • 0 comments

  Log 1:

  Published: April 2026

  I've spent most of my career at sea, as a Chief Deck Officer on oceangoing tanker ships. You learn things on a ship that you don't learn anywhere else. One of them is what happens when communication fails.

  Not "slow internet" kind of failure. I mean the kind where you're in the middle of an ocean, a thousand miles from anywhere, and suddenly the systems that keep you connected to the rest of the world just stop. Satellite phones go silent. GPS flickers. The radio is your only friend.

  You learn to respect infrastructure you never think about when you're on land.

  The February Earthquake

  In February 2023, Türkiye was hit by one of the worst earthquakes of the century. I wasn't there. I was at sea, watching it unfold on a small screen while people I knew couldn't reach their families. Cell towers were down. Internet was gone. Landlines were cut.

  For days, people in my country — in buildings standing right next to each other — couldn't communicate.

  And I kept thinking: the power lines were still there. In most buildings that hadn't collapsed, the wiring inside the walls was still intact, even if the grid itself was dark.

  What if the power line itself could carry messages?

  The Question That Wouldn't Go Away

  Power Line Communication (PLC) isn't new. Your electricity meter uses it. HomePlug adapters have been selling it as "internet over power lines" for twenty years. But those systems stop at the building transformer. They're not built for disasters. They're not built for neighborhoods to talk to each other.

  What if every device in the network was also a repeater? What if, when the grid failed, the devices themselves could inject enough signal onto the dead wire to keep the network alive?

  What if we went back to the philosophy of Minitel and FidoNet — local, decentralized, resilient, slow by design — but built it on infrastructure that already exists in every home?

  That's how GRIDNET started.

  Where I Am Now

  Over the past months I've designed the hardware from the ground up:

  • Dual-board architecture (PLC + Main) with a three-layer protection circuit
  • A custom mesh protocol with store-and-forward messaging
  • An inverter master protocol that prevents voltage conflicts when multiple devices try to power a dead wire
  • Software architecture on Zephyr RTOS with a sandboxed Forth VM for user applications
  • A separate PLC adapter that plugs into the wall and talks to the terminal over Wi-Fi

  All of it is on GitHub under CERN-OHL-W-2.0: github.com/denorath-sys/gridnet

  I'm not a hardware engineer. I'm a ship officer who learned to love technology. Which means I've taken this as far as I can on my own. The next step — PCB fabrication, firmware development, field testing — needs people.

  Why I'm Here

  I'm on Hackaday because I know what kind of people are here. People who don't ask "why would anyone do this?" — they ask "can we actually do this?" People who understand that sometimes the best projects are the ones that solve problems that haven't happened yet.

  If any part of this resonates with you, if you have ST7580 experience, if you know Zephyr RTOS, if you want to help test a prototype in your building once it's built — please reach out.

  The slowness is intentional. The locality is intentional. The fact that it works when nothing else does is the whole point.

  Let's build something that works when everything else fails.

  — Yasar

  GitHub: github.com/denorath-sys/gridnet Next log: Hardware architecture deep-dive

View all 2 project logs