Exodus
Projects · logging

The ship's log
that writes itself.

Every day, without anybody remembering: where we were, what the place was called, how far we went, how hard it blew, and how fast we did it. Written down whether we felt like it or not.

Why automate it

Because the honest answer is you won't keep one

Everybody intends to keep a log. Most people keep one for about three weeks.

It isn't laziness. You keep a log best on calm days when nothing is happening, which are exactly the days with nothing to record. On the days actually worth writing down, you are busy, wet, tired, or frightened, and writing in a book is the last thing on the list.

So the log has the wrong data in it. Pages of pleasant afternoons and nothing at all about the night it got interesting.

A computer doesn't get tired. It logs the bad night exactly as carefully as the quiet Tuesday, because to it they're the same job.

How it works

Once a minute, forever

A small program runs continuously on the Raspberry Pi and wakes once a minute. It reads Signal K over HTTP and does three quiet jobs.

1. It runs an odometer

Each minute it takes the speed over ground and adds the distance covered in that minute to a running total in nautical miles.

There is no log sensor on this boat. No paddlewheel, nothing in the water. Distance run just builds itself out of GPS, one minute at a time, and by the end of the day it's correct.

2. It keeps averages that mean something

It sums wind speed and boat speed only while the boat is actually moving — above half a knot.

That detail matters more than it looks. Average the whole day and three hours of sailing gets diluted by twenty-one hours at anchor, and every day looks identical and useless. Averaging only the moving minutes gives you the average of the sailing, which is the thing you wanted to know.

3. Once a day it writes the entry

At the day boundary it appends one line to the log file and resets the counters. Each line holds:

FieldWhere it comes from
Date and timeThe boat's clock
Latitude and longitudeGPS, via Signal K
Place name Reverse-geocoded from the position when there's internet — last known when there isn't
Distance runThe odometer above
Average wind speedMasthead instrument, moving minutes only
Average boat speedGPS, moving minutes only

That place name is the bit that turns a spreadsheet into a logbook. "39.36 N 75.88 W" is data. Georgetown, Maryland is a memory. And because the last known place is kept, a day offshore with no internet still gets a sensible entry rather than a blank.

It can't break anything. The logger only reads Signal K over HTTP. It never writes to the bus, never talks to the engine, never touches a charger. The worst a bug in it can do is produce a bad line in a text file.

The maintenance side

A log is also a service record

The same tool tracks what needs doing and when it was last done. Because the two belong together: the question "when did I last change that impeller" is a logbook question.

Four commands, run from the boat's terminal or over a chat message:

CommandDoes
show The whole log — what's due, what's overdue, and the recent voyage entries
done <item> Records a service as done today, at the current position, optionally with engine hours and a note
note "..." Drops a dated note into the logbook — the human bit
add <item> Adds something new to track, by months, days or engine hours

Due dates are worked out from the interval and the last-done date, so the list maintains itself. Nothing needs re-entering.

Recording where a job was done turns out to be unexpectedly useful. "Last impeller: 340 hours, in Annapolis" tells you something that a date alone doesn't — particularly when you're trying to remember which yard did the work.

What's being added

Written down so you can hold us to it

Everything above is running now. These are the next pieces, and they're all just more sources feeding the same daily line.

Sea state

Significant wave height, biggest wave and mean period, straight off the boat's own motion sensor — so a passage entry records what the water was actually doing, not what the forecast guessed.

How that's measured →

Weather, described

Not a table of numbers — a sentence. Air and water temperature from the boat's own sensors, pressure and its trend, wind, and what the forecast said, turned into a line a human would actually write.

Engine hours

Logged automatically rather than read off a gauge and misremembered. Which then makes every hours-based maintenance interval self-maintaining.

Maintenance due, in the entry

The day's entry carrying what's coming up, so you see it while reading the log rather than having to go and ask.

Passage tracks

The GPS trail for the day, so the entry includes the route, not just the endpoints. Where from, where to, how far, how fast, and the shape of the course between them.

Reading it back

A page on the boat's own screens showing the log as a log — scrollable by day, with the track drawn on a chart and the day's conditions alongside it.

Build your own

The shape of it, if you want to copy it

You need surprisingly little:

  1. Signal K, with a GPS feeding it. That's the floor. Everything else is optional.
  2. A loop that wakes once a minute, reads position and speed over HTTP, and keeps a running state file.
  3. One line per day, appended to a file. Use JSON Lines — one JSON object per line. It's trivial to append, trivial to read back, and survives a power cut mid-write losing at most the last line.
  4. A separate state file for the counters, written atomically, so a sudden shutdown can't corrupt it.

Resist making it clever. The reason this one has run without intervention is that it does very little, reads only, and writes plain text. Every feature added since has been another field, not another moving part.

The source will be on GitHub. The recorder, the maintenance tool and the schedule format. It is a couple of hundred lines of Python and no dependencies worth the name.

Measuring the sea state → Driving it from a phone All projects