Ocean UTC Celestial Backup: Prototype Offline Celestial Navigation Module For Sailboats
I am building Ocean UTC Celestial Backup as a small standalone box for the day when normal onboard navigation is gone, damaged, or no longer something I want to trust blindly.
This is still a prototype, but I would like to know if other sailors see enough value in it that I should clean it up and publish it as open source later.
Work In Progress
This is a prototype, not a finished navigation instrument
I am building Ocean UTC Celestial Backup as a small standalone box for the day when normal onboard navigation is gone, damaged, or simply not something I want to trust blindly. The current unit is not pretty, and it is not finished, but it is already useful for testing the idea, the workflow and the small-screen UI.
A lot of verification, careful checking, edge-case testing, documentation cleanup and real boat practice still has to be done. So this is not a release announcement. It is me asking a simple question: is this useful enough that I should spend the time to clean it up and publish it as open source?
Why make a separate box at all?
I like modern navigation. GPS, plotter, AIS, radar, tablets, phones and routing apps have made sailing safer and easier. But I also know the weak point: many of these systems share power, antennas, chargers, cables, displays, software and the same wet navigation area.
A lightning strike, battery failure, water in the panel, a bad charger, a broken antenna system or a software problem can take away several helpful systems at the same time. GPS can also lie, especially around jamming or spoofing, and sometimes electronics simply fail without a dramatic reason.
The idea behind Ocean UTC is not to replace normal equipment. It is to keep one small independent path alive: accurate time, almanac, DR, sight logging, and enough calculation help that I can continue working in a calm order instead of starting from a blank page.
When the unit is powered up for charging and checking, for example every one to four weeks while stored, GPS time and the PPS pulse can discipline the internal clock module. A good GPS/PPS signal is normally far more accurate than celestial navigation needs. After that, the remaining time error depends on the RTC quality and how long the box has been stored since the last check.
What I want the box to keep alive
UTC: GPS/PPS can discipline the clock when available, and the RTC can keep running later.
Almanac data: yearly Sun, Moon, planet, Aries and navigational-star data are stored on the SD card.
Planning help: a suggestion page can show which Sun, Moon, planet or star sights should be observable, with rough direction and height in the sky.
Dead reckoning: GPS position is kept separate from the assumed DR position until the skipper accepts it.
Sights: raw observations can be timestamped, logged and reduced as part of a normal sight workflow.
Error checks: the firmware tries to catch human-entry mistakes, impossible values, wrong-body choices and sight results that do not make practical sense.
Evidence: logs on the SD card can be inspected later on a Mac.
For me, the value is not magic navigation. The value is removing much of the slow table lookup and arithmetic work from celestial navigation. The box can bring almanac data, corrections, sight reduction and simple checks into one place, and then nudge me toward the next sensible action.
It does not remove the need to understand navigation. I still have to plot on a real chart or plotting sheet, compare the result with DR, depth, visual bearings and sea room, and decide what the position means. That part should stay human.
What I do not want it to become
I do not want this to become a small chart plotter with too many clever menus. The point is a narrow backup tool that can still be understood when I am tired, wet, cold, and not thinking as clearly as I would like.
No Internet needed during emergency use.
No dependency on the boat network.
No touchscreen-only user interface.
No automatic blind trust in GPS position.
No hidden cloud account or external service.
Prototype Photo
The first pre-prototype setup
This is the current bench setup, not the finished enclosure. It looks like a prototype because it is a prototype. The important part is that the firmware is already running on the target hardware: ESP32-WROVER, small TFT display, rotary control, RTC, GPS/PPS input, SD card, battery monitoring, lithium charging controller and the first power-control hardware.
First Ocean UTC pre-prototype bench setup. It is not a product photo. It is the honest state of the workbench version.
The normal emergency workflow
I want the workflow to be boring and repeatable. That is not a bad thing. In a real problem, I do not want to remember a hidden menu or a long command sequence. I want to do the same small steps every time.
Power on the unit and check battery, UTC, SD and warnings.
Set or confirm the assumed DR position from the best available source.
Use the Plan screen to see useful Sun, Moon, planet or star targets.
Take a sight with the sextant and timestamp it.
Enter the sextant altitude, limb and correction values.
Reduce the sight and write the result in the paper logbook as well.
Use one or more LOPs, or a running fix, to improve the position estimate.
The box should help with arithmetic and structure, but it must not remove the skipper from the decision. Paper chart, compass, log, depth, visual bearings and common sense still matter.
Home
The Home screen is the first sanity check: time source, estimated time error, battery, GPS state, DR state, almanac state and warnings.
Sight
The Sight page is where the observation starts to become useful: body, limb, time and sextant altitude are kept together instead of being scattered across notes.
Plan
The Plan page is one of the helpers I like most. It answers the practical question: what can I actually shoot now, and roughly where should I look?
Dead Reckoning
The DR page keeps the assumed position visible and honest. GPS can be shown as a candidate position, but I have to accept it before it becomes the working position.
Log
The Log page is not exciting, but it is important. It tells me whether events, sights, Sun LOPs and GPS candidate positions are actually being written to the SD card.
Time
The Time page is where I can see whether the clock is being disciplined by GPS/PPS or running on its own RTC. For celestial work, that small detail matters.
Main Menu
The menu is deliberately plain: Sight, Plan, DR, Fix, Log, Time, Battery, Almanac, Settings and Self-test. I want it to work with a rotary encoder and a few soft keys, also when a touchscreen would be a bad idea.
Almanac
The Almanac page checks the boring but vital parts: SD card, manifest, fast packed data and the body tables. If these are not ready, the rest of the workflow should say so clearly.
Battery
The Battery page matters more than it may first look. A perfect backup idea is useless if the box is flat when I finally need it.
Settings
The Settings page holds the values I may need to change as a user: eye height, sextant index correction, position format, language and the optional local maintenance web page.
Self-test
Self-test is for the checks I should do before storage and before a longer trip: RTC, EEPROM, input, GPS, display, power hold and other service state.
Fix
The Fix page is where a line of position or later fix result can be reviewed before I decide what to write down and what to use as DR.
GPS is useful, but it is not silently trusted
The GPS receiver is useful when it works. It can provide UTC, PPS timing and a candidate position. But this is a backup navigation unit, so it should not quietly let GPS overwrite my assumed position. If GPS is jammed, spoofed, badly received, affected by multipath, or simply faulty, blind trust can make the situation worse.
Because of that, Ocean UTC treats GPS position as candidate information. I can compare it with the paper log, DR, visual information and common sense before accepting it. This is especially important if the reason for using the box is that the normal navigation system is already suspect.
Offline almanac on SD
The SD card carries the offline almanac data. In the current prototype I have generated data for the Sun, Moon, Venus, Mars, Jupiter, Saturn, GHA Aries and 57 navigational stars.
The Mac-side helper tools can grab and generate the almanac tables for any chosen year, then build a compact yearly pack for the SD card. The card can hold table packs for many years if wanted. At boot, the ESP32-WROVER loads the active pack into PSRAM, so lookups are fast while the readable CSV files remain available as source and fallback.
Stored like emergency gear
I think this unit should be stored like emergency gear: powered off, dry, disconnected from boat wiring and preferably inside a conductive metal box. A small manual compass and a short printed quick-use note should live with it.
The battery should be charged and the unit tested regularly, especially before a longer passage. About every two weeks feels sensible to me. A prepared spare SD card is also cheap insurance.
What still has to be done
The honest part is that the prototype is useful for testing the idea, but the project is not ready for a public release without cleanup.
Validate celestial calculations against trusted worked examples.
Test the hardware repeatedly after final soldering and enclosure work.
Separate the user manual from deeper technical documentation.
Decide what belongs in a public GitHub repository and what should be generated or distributed separately.
Add a license, clean build instructions, wiring diagrams and reproducible SD-card generation steps.
Decide how much translated UI text is worth doing in the first public version.
Use real sailing practice to find the awkward parts of the UI.
Could this become open source?
That is the reason for this page. I can continue building Ocean UTC only for my own boat, and that is already useful for me. But if other sailors see value in it, I may clean up the project and publish it as open source.
The feedback I am looking for is practical, not polite:
Would you carry a small standalone celestial backup box?
Would you prefer this as hardware, an app, or both?
Which functions are most important: UTC, almanac, sight logging, reductions, planning, DR, or documentation?
What would make you trust it enough to practice with it?
What should be removed because it adds complexity without real value?
Related SailingKSF pages
This prototype belongs beside the practical seamanship articles, not instead of them. The box is only useful if the sailor still understands the situation.
I would like to hear whether this kind of standalone celestial backup module is useful enough to publish as open source. Corrections, missing features, practical objections and safety concerns are all welcome.
No public comments yet. You can be the first to add feedback.
A prototype asking for honest feedback
If this idea is useful, the next step is not only more code. It is testing, documentation, repeatable checks and honest feedback from sailors who would actually carry something like this offshore.
No public comments yet. You can be the first to add feedback.