Behind the Scenes of the Galvanic Voice

It started with fancy ideas — and the fancy ideas are not dead yet. I went looking for tools that would genuinely make my own boat safer. The more I dug into it, the more I realised that the problem was not where I thought it was. The Galvanic Voice is what came of looking, and of finally asking a different question.

It Started With Fancy Ideas (and Some of Them Are Not Dead Yet)

I have sailed enough to have an opinion about what I would want a thoughtful piece of safety equipment to do for me. The list was long, and ambitious, and full of the kinds of features the people who sell marine electronics will gladly write into a brochure. Better sensing. Smarter alerts. Cleverer integration with the autopilot. A screen that adapts to what is happening. I started where most product designers in this space start — at the question “what else could I put on the boat?”

Some of those ideas are still in my notebook. I have not given them up. I have, however, given up the assumption that they were the important ones.

We Already Live in the World of Autonomous Cars

The thing that stopped me in my tracks was a quiet observation about the wider technology landscape. We live, by 2026, in the world of autonomous cars. Vehicles built by half a dozen serious teams routinely find their way through dense urban traffic on the strength of radar, lidar, cameras, GPS and sensor fusion that would have been science fiction twenty years ago. In other words, the sensing problem — the problem of measuring the environment around a moving vehicle accurately enough to make safe decisions — is, broadly speaking, solved. Not perfectly, not in every edge case, but solved well enough that the limiting factor is no longer the sensor.

Marine sailing is generously inside that envelope. The boat moves slowly compared with a car; the obstacles are largely cooperative (other vessels run AIS); the chart is well-mapped; the weather is forecast to within a few hours. Accelerometers, GPS receivers, AIS engines, depth sounders, anemometers, magnetometers — none of these components is the hard problem any more. I could put more of them on the boat, better calibrated than what is sold today, and it would not change the outcome that actually matters.

Because the hard problem is somewhere else. The hard problem is that none of those sensors have any way of actually telling me what they have noticed. They sit silently, blinking on a screen I might or might not be looking at, generating data I might or might not consult.

I Refused to Add Another Thing to Watch

Knowing this, I also knew, very early, what I did not want to do. I did not want to invent yet another instrument that would require the skipper to keep an eye on it. The whole point of sailing — the part that draws me back to the boat year after year — is the time on the water. Adding a new screen, a new dashboard, a new app, a new beeping panel that demands a piece of the watch’s attention is not a solution. It is, by definition, the problem made worse.

I had a half-joke about it that crystallised the position. I did not want to be the inventor of “rule 21” of the COLREGs: “every vessel shall at all times maintain a proper look-out on the safety tool fitted by Galvanic Works, even when this entails ignoring the horizon, the wind, the chart, and the company of the people aboard.” If the thing I was building required the sailor to spend more time monitoring it, I had made the problem worse, not better. Full stop.

And Then the Question Changed

At some point I stopped asking “what should the boat sense?” and started asking “how does the boat speak to me, so that I do not have to watch it?”

That is a much smaller question than the one I had been carrying around, and a much harder one to answer well. Speaking is not just a feature you bolt onto a chartplotter. It involves deciding what is worth speaking about, and what is not. It involves deciding what the sentence should sound like — calm or urgent, brief or detailed, sharp consonants in noise or smooth syllables in fair conditions. It involves deciding when to interrupt the crew and when not to. It involves the IMO’s two decades of accumulated thinking on Bridge Alert Management (Resolution MSC.302(87)) and a fair amount of cognitive psychology on what humans actually retain under stress. It involves — once you are committed to it — a hardware platform that can deliver intelligible speech reliably, at a usable volume, in a marine environment, without drowning the boat’s electrical budget.

Everything else that followed — the alarm grammar, the contextual awareness, the polar diagrams, the bracelet on the wrist — was a consequence of the moment that question changed. Once you accept that the boat’s job is to tell the crew what is happening, and not just to sense it, every other design decision falls out of that.

Then the Next Question: Why Wasn’t It Already There?

Once I had convinced myself that voice was the right channel, the next question was an obvious one. If voice is so clearly the right answer to safety information on a boat, why was nobody already shipping it? The marine-electronics industry is not young. Somebody should have figured this out a long time ago. So I spent a stretch of time working out what had stopped them.

A phone is the obvious place — and not the right one

A smartphone has a speaker, a screen, a radio link and a GPS. Every sailor already carries one. It looks like the natural answer. It is not, for two structural reasons. First, the audio output: a phone’s speaker is designed for a video call in a quiet room, not for an alert that has to cut through a Force 6 on the wheel and a diesel running below. The peak sound pressure is comfortably below what a marine alert needs. Second, the monitoring suitability: battery management, background-task throttling, OS sleep states — every reason a phone is a poor primary monitoring device is laid out in The Screen That Doesn’t Save You. The short version: phones were designed to suppress the kind of always-on listening this system requires.

A NMEA 2000 device cannot draw enough power

My next thought was the obvious one for any marine engineer: build it as a NMEA 2000 instrument, powered from the network backbone the way the wind display and the depth sounder are. The NMEA 2000 standard has a strict power budget per device — each unit is allowed roughly 1 LEN (50 mA) up to a maximum of about 6 LEN (around 300 mA at 12 V, or 3.6 W). That is simply not enough power to drive clear, audible voice in marine conditions. The amplifier alone wants more than that. The NMEA 2000 envelope is the right place for the data path — not for the audio path.

A MFD does not have a speaker — and adding one is not free

Could the alert come out of an external loudspeaker bolted onto a MFD? In principle, yes — with an external amplifier and a cable run you can certainly arrange it. The problem is that the configuration is dependent on the chartplotter being powered up. The moment the sailor switches the MFD off — at anchor, overnight, to save the battery — the alert path goes off with it. And the external amplifier itself adds another non-trivial recurring load to the boat’s electrical budget. That is exactly the kind of cost The Price of a Watt describes, and exactly the kind of cost a sailing boat cannot afford to carry for a safety function that has to be on twenty-four hours a day.

A marine music speaker is the wrong shape and the wrong physics

I have very good loudspeakers on my own boat for music. They sound excellent. They are also large, structurally fragile to salt water and splash, mounted in places that are awkward to interact with, and — most importantly — they are one-way devices. There is no way for the sailor to acknowledge an alert through a music speaker, no way for the speaker to know it has reached the person it was meant to reach. The form factor is wrong for the job, and adding all the intelligence and interactivity you’d need around a music speaker is not the right place to start the design.

So the conclusion was the one I had been resisting: it had to be designed from scratch.

Designing a Speaker Is Easy. Designing an Intelligent One Is the Hard Part.

Designing a loudspeaker for a boat is not, on its own, a difficult engineering exercise. Designing an intelligent loudspeaker — one that knows when to speak, when to stop, when it has been heard, and when not to bother — is something else entirely. This is the situation where being technology-savvy pays off.

The first piece was the realisation that the frequencies humans use for alerting each other live in a relatively narrow, well-defined band. Attention-grabbing audio (a couple of hundred Hz to a couple of kilohertz, roughly) does not need a full hi-fi loudspeaker to be reproduced clearly. A sheet of glass of the right thickness, driven by a compact transducer, can carry that band beautifully — and at dimensions that fit on a helm console rather than a cabin bulkhead. Gorilla-grade glass of suitable thickness, which marine displays already use as their cover material, turns out to be an excellent acoustic radiator for exactly the frequencies a marine alert needs to carry. (The full story of why glass beats a cone is told separately in OK, a Voice. But Why a Glass Speaker?)

Around that core, the rest of the design fell into place — each piece chosen because it solved a specific problem the loudspeaker on its own does not:

• An embedded computer running the alert logic, the TTS engine, the NMEA 2000 stack, the AIS stack, and the link to the wrist bracelet.
• A Class D audio amplifier driving the glass transducer. Class D was the only topology that fit the 1 W average power budget described in The Price of a Watt; no other amplifier class would let the boat keep the alert path on twenty-four hours a day without paying for it twice in generation and storage.
• Focused, directional LEDs behind the glass for visual indication — placed where the eye is already looking when the alert speaks.
• An ambient-light sensor so the LED intensity matches the conditions automatically, with no day/night toggle for the sailor to remember.
• A gesture sensor so the sailor can acknowledge an alert without taking a hand off the wheel — turning the loudspeaker, finally, into a two-way device.

What that combination delivers is a loudspeaker that lives in the sailor’s field of view, draws attention only when there is a reason, recognises when it has been heard, and consumes — at the level of the numbers in The Price of a Watt — roughly twenty times less power than a typical chartplotter. Which means it can stay on, twenty-four hours a day, without ever entering the nightly negotiation about which instrument to switch off.

The rest is the Galvanic Voice.

And — Since It Comes Up Constantly — a Note on the Word “Intelligent”

The word intelligent has become, in this corner of the market, a label that gets pasted on almost any product that ships with a microcontroller. Right next to it, often on the same line of the same press release, sit the two letters AI. Both words get claimed, indiscriminately. The marketing department, in particular, is fond of them — even when the device underneath the sticker is the same beeping panel it always was.

We do build an intelligent device, and we are not shy about saying so. But the intelligence sits in the substance, not in the slogan. We do not claim AI. We use it. We use AI on the boat, where it is useful to the sailor, and we integrate it with our algorithms and our software inside the same device, all for the benefit of the user. We simply do not turn that into a marketing line, because what makes a boat safer is what the device actually does, not what the box is labelled.

What is actually inside the Galvanic Voice, as of April 2026, sits at the frontier of what marine technology can do today — and we would rather describe it in concrete terms than in slogans. It is, simply put, a substantial body of software, designed and built around the problem the device is solving.

Some figures, since they tell the story better than the adjective ever could. As of April 2026:

• 116,946 lines of software.
• 2,225 tests, totalling 35,704 lines of test material — each one written so that the next change does not silently break the last one.

In industry-average terms — software that ships, that has been reviewed, and that is tested — that is on the order of twenty years of one developer’s effort. Give or take fifty percent, depending on which productivity figure you prefer to use. Twenty years of one person doing nothing else, or four years of five people doing nothing else, take your pick. All of it built for one purpose, which is to make sailing safer and more reliable.

And beyond AI, beyond intelligence, beyond any of the words the marketing department of the industry has currently bought into, there is a more fundamental ingredient at the bottom of every Galvanic Voice design. We rely on physics. Believe it or not, even if they have a soul, boats obey physics. The sea obeys physics. The wind obeys physics. The catenary in your chain obeys physics. And — though they try valiantly to bend the rules, particularly after dinner — the crew and the captain obey physics too. Every design decision in this device begins with what the physical world will and will not allow, and ends with a system that respects the answer.

We do call the Galvanic Voice an intelligent device — because that is what it is. We simply use AI for the benefit of the user, not for the benefit of the press release. The difference matters.

Why Voice Was Never a Feature Decision

I am sometimes asked why I chose to build a voice product, as if voice were a stylistic preference I picked off the shelf. It was not. Voice was not a feature decision. It was the only honest answer to a question I kept asking myself on my own boat: how does this thing reach you without taking your sailing away from you?

The fancy ideas are not dead. Some of them are still on the roadmap. But everything that ships now passes through the same filter that this story records — does it speak to the sailor without requiring the sailor to look at it? — because that is the filter the boat itself needs to apply, every night, on every passage.