When the Line Is Gone

It started with a pretty typical trip out to the bomber.

You know this dive. You prep for 150 feet in Lake Washington. Cold. Dark. A stack of expensive gear, a bunch of helium, and years of training, all so you can go look at a four-engine bomber the Navy dropped in the lake seventy years ago.

And then, for whatever reason, you don’t find the line. It’s supposed to be here, but … it’s not.

In the dive I remember so well, we searched for a while. No luck. Well — here we are. May as well look around.

So we did. Half an hour at 120-140ish feet, wandering more or less at random across the bottom of the lake. We found a lot of interesting objects. We did not find the bomber.

We got back to the beach — by pure chance, the same beach we’d entered from — and I said the thing that turned into this project:

“Gosh. I wonder where we went?”

I went looking for a hobbyist-grade digital compass and dead-reckoning setup. I assumed there would be something I could at least duct tape inside the scooter housing to keep track of heading over time. There wasn’t one. Nothing viable for the hobbyist. There are commercial applications, so I found units listed as “Contact us for a quote,” but nothing sane between “nothing” and “commercial.” At the time I didn’t have the hours to build the middle option myself.

Fast forward a few years, add AI-assisted coding to the mix, and the calculus changed. A one-person hardware-and-firmware-and-web-app project stopped being absurd.

Three goals

1. Find the wreck. The obvious one. When the line to the wreck is gone, how do you find it?

2. Reconstruct the dive. The less obvious one, and the one I’ve come to think is more interesting: where did we actually go, and what did we see along the way? (More on why this is interesting in a moment!)

3. Make it something a diver can actually build. This one is a hard constraint, not an aspiration. I am making design and architecture decisions for affordability and manufacturability, and I am making compromises to hold that line.

The current bill of materials runs about $800. I’m working to cut that by 20% in the next iteration. To build one, you’ll need to order custom PCBs, 3D print some parts, drill a few holes in some plastic, solder some wires, and flash firmware to an ESP32. Speaking purely from the perspective of the Seattle area cold-water technical diving community: if you’re diving in this region and you’re the diver who doesn’t have most of those skills already, I guarantee you that you know people who have these skills.

The big asterisk on that $800 price tag is that it’s just the parts, not the assembly. If you’re good, and my directions are excellent, you won’t solder the wrong thing into the wrong slot on the board and need to start over, or drill a hole the wrong diameter and lose a $30 part for a dumb mistake. It also doesn’t include a lot of incidental materials that I tend to have sitting around — heat shrink tubing in various sizes, wires in a bunch of different gauges, and so on.

The goal is that any cold-water technical diver can afford to build and deploy one. It’s not free or easy, but it’s straightforward and cheaper than a dive computer or good light.

How it works

The formal term is dead reckoning: estimating your current position from a known previous position plus a known change. The term shows up in the early 17th century, and “dead” probably refers to a stationary object used to measure speed — typically a log tossed overboard, which floats dead in the water while the boat drifts past it. Incidentally, that’s where we get the phrase “speed by log,” still in use in some nautical circles.

This iteration is only slightly more modern than that. It’s a digital compass and a flow meter.

1. Anchor an initial position with GPS at the shore, and perhaps get another fix before you descend.
2. Track heading — carefully aligned with the direction the scooter is pointing — and speed, from a calibrated flow meter.
3. Continuously update an estimated position.

After the dive, the unit uploads its logs to the website, where the track gets reconstructed against any known points you encountered along the way. You annotate the landmarks you saw, and that knowledge goes into the shared map.

The part where I tell you it doesn’t work yet

Any error in speed or heading calibration compounds. From reading other people’s work in this area, 10% is considered a normal error rate: for every 100m you travel, your position uncertainty grows by about 10m. Run 500m and you’ve got a 50m-radius circle on the chart that you’re probably somewhere inside.

Note the shape of that assumption. Error growing linearly with distance is what you get when the underlying error is a systematic bias — a compass reading consistently 8° off, a flow meter consistently under-reporting — rather than random noise, which would grow more slowly. What I’m finding so far is primarily systematic errors, rather than random noise.

That’s the bad news and the good news. Bad, because bias is unforgiving over distance. Good, because bias is fixable, and random noise mostly isn’t.

Results so far vary enormously with calibration quality. I’ve had runs come in under 5m of error. I’ve also had a run where I surfaced so thoroughly lost that I had to ask a stranger for directions to the beach.

Here’s what’s actually eating the accuracy:

Magnetic interference from the scooter. The compass is bolted to a tube containing a large motor and a gigantic battery, which is basically a giant magnetic field. Figuring out how to calibrate around that — in a way which is convenient and intuitive — is the single hardest problem in the system. Getting compass error under 2° means holding the motor-and-battery magnetic contribution to roughly 1.7 µT against Earth’s ~50 µT field. Static bench calibrations leave a lot to be desired here.

Calibration that reports itself as good when it isn’t. I spent real time chasing a heading error in one sector while my calibration quality metric said everything was fine. It turns out RMS error is an in-sample number — it tells you how well your solution fits the data you fed it, and a systematic angular error that averages out across the circle will hide inside a perfectly respectable RMS. I now look at per-sector residuals and hold out points from the fit. That change alone found the bug that a clean RMS was covering for.

Magnetic versus true. Local declination here is about 15° east. Every heading in this post is magnetic; every position on the map is true. Getting that conversion wrong — or applying it twice, or in the wrong direction, which I have absolutely done - ends up giving directions that are hilariously bad.

The flow meter measures water, not ground. It reports distance through the water, not distance across the chart. Crab into a bit of current, or mount the unit poorly enough to allow yaw in the sensor, or drift 120m while ascending and doing deco, and the number is honest and wrong at the same time.

None of these are exotic. They’re just all live at once, on a device that has to work while you’re cold, task-loaded, and 140 feet from the surface.

The fun part: landmarks

Getting within 50m of a wreck in Lake Washington, where visibility rarely exceeds 5m, is decidedly not good enough.

But here’s the thing I didn’t expect when I started: goal #2 turns out to solve goal #1. Dive reconstruction is what makes wreck-finding work.

If you find a known point, you can reset your position uncertainty. And that changes the whole geometry of the problem, because it means you don’t have to make the trip in one leg.

It’s 370m from the speed limit buoy to the Dawn. Scoot that straight, reasonably well calibrated, and you’re within 37m. In Lake Washington, 37m may as well be a different lake.

But halfway out there’s a “scattered barge” — actually two small boats, one resting on the other. At 180m, with 10% error, you’re inside 18m. That’s potentially findable. And once you find it, you know where you are again. Uncertainty resets. Then it’s one more 190m hop to the real target, arriving within about 20m. The Dawn is big enough that a 20m circle is a sane spiral search.

Same trick for the bomber. At 80 feet there’s a landmark we call “the three stakes.” There are something like five of them now, but we’ve kept the legacy name. It’s the head of the deep line that runs to the wreck, it sits 200m from the bomber, and it’s about 250m from shore on a steep contour. Knowing that, you can shoot 103° magnetic from the beach, search 25m each direction along the 85-foot contour, find the landmark, and turn for the bomber. Even with the line blown out, getting within 20m of an airplane with a 30m wingspan is a viable dive.

There are two intermediate wrecks on the path out to the Harpoon. The Valiant is close enough to a buoy anchor, and on enough of a contour, that it’s probably findable without any intermediate landmarks. The Scout is only a hundred-odd meters from the SS Insurance Claim, with a lot of smaller landmarks scattered along the way.

With enough exploration and documentation, the lake becomes a much more navigable place.

Where the landmark idea breaks down

Two problems I want to name rather than paper over.

The uncertainty problem. Landmark positions come from dead-reckoned tracks. So a landmark logged on a mediocre run inherits that run’s error, and then hands it to everyone who navigates from it. “Reset uncertainty to zero” is a convenient fiction — you actually reset to the landmark’s uncertainty, which is not zero and which you can’t see. This gets better with repeated independent observations from different directions, and there’s real work ahead in weighting and reconciling those observations. It gets better by diligent work, not by hoping.

Failed hops have a real cost. Every search leg you fly is bottom time and gas at depth. Miss the second wreck on the way to the Harpoon and you’ve spent five minutes of a deco dive learning nothing, with a bigger error circle than when you started. The multi-hop strategy is elegant on a map and expensive underwater. It has to be planned as part of the dive, with its own turn criteria, not improvised at depth.

What’s next

Initially this was just navigation. Build a basic dead-reckoning tool, see if it’s good enough to find the wrecks. The short answer is “it sometimes is — but wait, there’s more.”

I added a simple mapping application to visualize the dives. That’s grown into a wreck-and-line-tracking app, and more valuably, a way to track landmarks. Landmarks are the key. They’re what enables hopping from known point to known point. As more people build these and log what they see, everybody’s navigation gets better. That’s the actual long game here, and it’s the part that doesn’t work with a user base of one.

The next useful step is to make this a thing that other people can build, and to start getting more navigators in the wild. I’m working on what I hope is the final refinement of both PCBs, which will simplify the wiring diagrams. I’m refining the BOM to reduce cost, targeting a $500 build (plus incidentals like solder and heat shrink tubing). And I’m working on the documentation to allow any shade-tree builder to hack one of these things together on the workbench in their garage.

Then there’s the aspirational step: a compact mobile sonar package, with intent to localize wrecks once you’re close (but not close enough). The goal is simple: make it so the 38m search circle becomes a no-brainer scoot in a clearly obvious direction. I’ve laid out a concept design.

I should be careful about how much I promise there. It does not need to be a $70,000 side-scan rig that resolves a wreck with sub-millimeter precision at 500m. It needs to tell me which direction to go when I’m already close. That’s a dramatically easier requirement — but “easier than a professional survey system” and “achievable in a garage” are different claims. I’m optimistic that the problem has a viable solution, but my experience with underwater acoustics is that it punishes optimism. Transducer sourcing, mounting, dealing with electronics and water, power management, and a cluttered silty bottom with absolutely unknown acoustic properties are all real problems I have not yet explored, let alone solved.

Non-trivial. Which is not the same as impossible. Ask me again in a few months.

If you want in

This is source-available, and it’s meant to be built by other people. The most useful thing you can do right now, even if you never touch a soldering iron, is log landmarks. Positions, descriptions, photos. The map gets better with every one.

If you want to build a unit, follow along — I’ll be posting the build guide, the calibration work, the PCB designs, and the failures as they happen. Especially the failures. The bad runs are more informative than the good ones, and I’m publishing both.

A necessary word about safety

This is a homemade navigation tool built by one fallible human and tested by that same demonstrably fallible person. It is not life-support equipment and it is not a primary navigation system. Every dive you do with it should be a dive you could complete safely without it — with your compass, your line, your training, and your plan intact.

Do not extend a dive, skip a reel, or push a penetration because a box on your scooter says it knows where you are. Sometimes it does, but sometimes it doesn’t.