An eclipse photography script normally starts with a simple assumption: your camera stays at the location used to calculate the eclipse. On a cruise ship, that assumption can quietly stop being true.
The ship may keep cruising, turn to avoid weather, slow down, or stop before totality. Even if your tripod never moves on the deck, your observing coordinates do. The eclipse is still governed by the same Sun, Moon, and Earth—but the times at which you experience its contacts can change.
eclipseClick’s Moving platform (ship) mode connects execution to validated GPS navigation. Instead of treating the location chosen before the run as permanent, it updates contact predictions using the ship’s measured movement and adjusts eligible future actions to follow accepted predictions.
There is no planned route to enter. The feature does not require you to know what the captain will do next.
Why a moving location matters
Eclipse contacts are local events. C1 marks the beginning of the partial eclipse, C2 the beginning of totality, C3 its end, and C4 the end of the partial eclipse. Maximum eclipse falls between the inner contacts for a total eclipse.
Move the observer, and those times can move too. The duration of totality, the predicted position at each contact, and the Sun’s altitude can also change. Near the edge of the path, a relatively small displacement can matter much more than it does near the centerline.
Consider a ship cruising at 20 knots. That is about 10.3 meters per second, or roughly 56 kilometers over 90 minutes. A location captured early in the partial phase may therefore be a poor representation of where the cameras will be at totality.
That distance does not translate into one universal timing correction. Its effect depends on the ship’s direction relative to the shadow, its position within the eclipse path, and the eclipse geometry. Traveling along the shadow’s direction can shift the encounter and slightly lengthen totality; moving across the path can shorten it or take the observer outside totality altogether.
The practical point is simpler: ship speeds are slow compared with the eclipse shadow, but they are not zero. Over an eclipse run, the accumulated displacement deserves attention.
Measured movement, not a promised course
A GPS receiver tells eclipseClick where the ship is. Depending on the receiver’s output, it may also supply speed over ground and course over ground. When those motion fields are unavailable, eclipseClick uses a history of position measurements to estimate movement.
Course over ground describes actual movement across the Earth—not the direction the bow points, and not the ship’s itinerary.
For upcoming contacts, the calculation projects that measured movement forward, with a ten-minute projection limit. Contacts farther away are provisional: the application is not pretending to know where an independently maneuvering ship will be an hour later.
As fresh navigation arrives, the prediction is recalculated. A turn, slowdown, or stop can therefore change the next prediction. No user-entered course change is needed during a live GPS run.
There is still a real limitation: a maneuver cannot influence the calculation until navigation reveals it. GPS delay, measurement quality, and the time needed to validate a new prediction remain relevant. This is adaptive tracking, not knowledge of the future.
How to enable cruise-ship tracking
1. Connect GPS on Equipment
Connect your GPS receiver through the Equipment page and wait for a usable navigation fix. The execution interface identifies GPS connectivity as a Pro capability.
Moving-platform execution needs usable navigation, not merely an open connection. If the receiver does not provide speed and course, allow time for position history to establish movement. A receiver with a clear view of the sky is preferable to one obstructed by the ship’s metal structure.
2. Load a script linked to the eclipse
Choose the eclipse photography script you intend to run. Moving-platform tracking requires a script linked to an eclipse, because execution needs the eclipse’s calculation data—not just a list of absolute timestamps.
Review camera connections, capture methods, and your normal execution checks before arming.
3. Select Moving platform (ship)
On the execution page, find Observer setup and select Moving platform (ship) instead of Fixed location.
For a live run, the source reads Connected GPS. This is different from choosing a one-time GPS position snapshot in fixed-location mode: a snapshot sets a location once; moving-platform mode keeps following navigation.
4. Check the height source
Open Advanced — height used for contact calculations if needed. eclipseClick uses GPS ellipsoidal height when available. Otherwise, you must provide an explicit fallback ellipsoidal height before arming.
Ellipsoidal height is not the same as height above sea level. Your deck’s height above the water is not an interchangeable input, and this field does not perform a geoid conversion. Resolve that distinction during preparation, rather than guessing during the eclipse.
If GPS supplies a valid ellipsoidal height at Arm and no manual fallback is entered, that validated height is retained as the fallback if height data later becomes unavailable.
5. Arm, review, then start
Arming validates navigation and the moving-platform prediction. The prediction is refreshed again before execution starts. Treat a validation failure as a preparation issue to resolve—not something to bypass because the receiver appears connected.
Observer setup is locked once armed. To change platform or navigation source, stop or disarm and re-arm with the intended configuration.
What you will see while tracking
The status display distinguishes a new prediction from a prediction actually adopted by execution. Watch the schedule state, not just whether a calculated contact time appears to have changed.
Typical headlines include:
- Tracking — schedule updated: execution accepted a timing update.
- Tracking — no timing change needed: tracking is working, but no schedule adjustment was necessary.
- GPS unavailable — schedule held: navigation is not currently usable; the last accepted schedule remains in effect.
- Schedule held: a prediction or its adoption did not pass the relevant checks.
- Tracking disabled: live tracking is no longer active.
The reason matters. A held schedule does not mean the ship stopped, and an unchanged schedule does not mean GPS is broken. Small or stationary movement may genuinely require no timing change.
Predictions refresh more frequently as contacts approach. The current implementation normally uses a slower cadence far from contacts, about 20 seconds within half an hour, and about one second within five minutes of an upcoming contact and during totality. Detected maneuvers can trigger earlier recalculation. Those are recalculation cadences—not guarantees that a timing update will be accepted every second.
Contact tracking continues through totality
There is no automatic contact-time freeze at C2 minus two minutes. Validated predictions can continue to update execution after that point and through totality.
This matters even when a cruise ship is expected to slow down or remain stationary. The application follows measured navigation rather than assuming the expected stop happened—or that the ship will remain stopped.
However, contact-time tracking and rebuilding a capture plan are different operations.
Before the final approach to totality, eligible scripts with the required planning information can have their totality layout recalculated for the accepted eclipse geometry. Structural replanning freezes within five minutes of C2. That protects the shape of the capture sequence as the most time-sensitive part of the run approaches.
The freeze does not stop validated timing tracking. The existing layout can continue following accepted contact-time changes without being rebuilt at the last moment. Where available, the interface also allows a replanned layout to be reverted before this structural freeze; that is a layout operation, not a return to fixed-location tracking.
Protecting execution when a prediction changes
Updating a prediction is not permission to disrupt every action already underway.
Captures that are already preparing retain their committed timing. Eligible future actions can be retimed, while completed captures are not replayed. Prediction work runs separately from the main execution thread, reducing interference between eclipse calculations and camera scheduling.
The application also checks whether a prediction has become stale or whether the ship’s measured motion changed while it was being calculated. Near contacts, the freshness checks are tighter. A result that no longer represents current navigation is held rather than blindly adopted.
These protections have a trade-off. Suppose a correction moves a brief phenomenon’s scheduled exposure into the past. eclipseClick cannot recover that moment by firing late, and it should not replay an already completed capture. Actions that become past due may be skipped, with the skip surfaced in the execution console and logs.
This preserves an understandable execution history, but it is not a promise to capture every phenomenon after every timing change. Fresh GPS, a rehearsed setup, and adequate photographic coverage around contacts remain important.
If GPS reception is lost
During an active run, invalid navigation or a fix older than the freshness limit causes execution timing to be held at the last accepted schedule. In the current implementation, the navigation freshness limit is three seconds.
The capture schedule continues. A short GPS interruption does not, by itself, cancel the photography run. When usable navigation returns, tracking can attempt fresh predictions again.
Holding the schedule is a continuity safeguard, not evidence that the held prediction is still accurate. If the ship maneuvers during an outage, its actual contact times may depart from the last accepted ones.
A stopped prediction worker is a different failure. The application reports that tracking has stopped while the existing capture schedule continues, and indicates that fresh navigation and re-arming are needed to restore tracking. Do not assume every degraded condition will recover automatically—or interrupt a critical exposure sequence without considering the consequences.
Rehearse on land before sailing
You do not need a moving ship to understand this workflow. There are two useful rehearsals, each testing something different.
Virtual ship: test movement and failures
Enable Simulated Realtime in Settings → Advanced, then return to execution and select the moving platform again. Changing clock context requires reviewing observer and camera setup.
The source becomes Virtual ship, and every camera slot must use Simulation. This rehearsal uses a simulated clock and navigation; it does not take hardware photographs.
Configure the starting coordinates and explicit ellipsoidal height. The available parameter presets include Stationary, Steady cruise, Turn, Stop, Restart, and GPS outage. You can also configure speed, course, a later change in motion, and a navigation dropout.
Use these scenarios to learn what an accepted update looks like, how a held schedule is reported, and what happens when motion resumes. Start sufficiently early if you want to observe structural replanning before its five-minute freeze.
The simulated course is only an input to the test generator. It is not something you must supply for a live cruise.
Live GPS with simulated cameras: test your receiver
With Simulated Realtime off, select the moving platform and use Simulation for every camera slot. This exercises real GPS navigation without hardware captures. The interface identifies it as Live GPS / simulated cameras — no hardware captures.
This is useful for checking receiver connection, reception, height data, and navigation readiness on the ground. A stationary receiver is a valid practical test, but do not expect it to demonstrate every moving-track behavior or a historical eclipse encounter. Use the virtual ship for controlled turns, stops, outages, and eclipse-time scenarios.
Neither rehearsal replaces a separate camera and capture-method test. Confirm actual camera operation using your normal safe test workflow before the trip.
What cruise-ship support does not do
Moving-platform support addresses eclipse geometry and execution timing. It does not steer the ship, forecast its route, choose a weather diversion, or ensure it remains inside the totality path.
It also does not stabilize a tripod, compensate for pitch and roll, or automatically keep the Sun centered. A correctly timed shutter can still produce an unusable frame if ship motion moves the subject out of view.
GPS position tracking is not a substitute for clock synchronization or camera-latency preparation. Check those independently, along with power, cable security, camera settings, storage, and your physical solar-filter procedure. Timing software does not make unsafe solar viewing or unfiltered equipment safe.
Finally, a numerical prediction is not a guarantee of visibility. The Sun’s altitude, obstructions, weather, navigation quality, and your actual position all matter. Edge-of-path and grazing encounters deserve particular caution.
A practical pre-departure checklist
- Confirm the installed eclipseClick version includes moving-platform support and the GPS capability you need.
- Prepare a script linked to the correct eclipse and review the intended phenomenon coverage.
- Test the actual GPS receiver, connection, reception, and ellipsoidal-height source.
- Rehearse a steady cruise, a turn, a stop, and a GPS outage with the virtual ship.
- Recognize the difference between accepted timing updates, held schedules, and frozen structural replanning.
- Test the real cameras separately, including clock and latency preparation.
- Plan mounting, framing, power, cable retention, and filter handling for a moving deck.
- Know where to read execution messages and skipped-action logs.
Follow the eclipse from where you actually are
Cruise-ship photography changes the meaning of “my location.” It is no longer a coordinate chosen once during planning; it is a stream of measurements that continues while the eclipse unfolds.
eclipseClick’s moving-platform workflow reflects that reality: measure the movement, limit assumptions about the future, validate predictions, and update eligible execution timing without casually disrupting committed captures.
The goal is not to make a moving deck behave like solid ground. It is to remove one avoidable source of error—the assumption that your eclipse location stayed fixed—so you can prepare confidently and spend more of totality looking at the sky.