Skip to Content
GuidesAnalyzingMoving-platform access

Moving-platform access

What you will accomplish

An access analysis for a platform that moves along a route, and a demonstration of why the usual shortcut cannot be trusted even when it appears to agree.

Prerequisites

Steps

Describe the route as timed waypoints

Times are offsets in seconds from the scenario start. Legs are great circles between consecutive waypoints.

{ "id": "flight-001", "name": "JFK to LHR", "min_elevation_deg": 10.0, "trajectory": { "geodetic_waypoints": { "waypoints": [ { "t_offset_s": 0.0, "lat_deg": 40.64, "lon_deg": -73.78, "alt_km": 0.004 }, { "t_offset_s": 1800.0, "lat_deg": 43.5, "lon_deg": -68.0, "alt_km": 11.0 }, { "t_offset_s": 12600.0, "lat_deg": 53.0, "lon_deg": -30.0, "alt_km": 11.6 }, { "t_offset_s": 23400.0, "lat_deg": 53.2, "lon_deg": -8.0, "alt_km": 11.6 }, { "t_offset_s": 25200.0, "lat_deg": 51.47, "lon_deg": -0.45, "alt_km": 0.025 } ] } } }

Include climb and descent waypoints if altitude matters to you. At 11.6 km the horizon is meaningfully further away than at sea level, though as the results below show, that is not the dominant effect.

Run it

orbitforge platform-access \ --constellation ph1.json \ --platform flight-ba112.json \ --duration-hours 7 --step-seconds 60
Platform `JFK to LHR`: 60 satellites analyzed over 7.0 h, 90 passes above 10 deg. ph1-s0-p00-sat00: 3 passes, visible 5.7%, best peak elevation 54.7 deg ph1-s0-p00-sat01: 3 passes, visible 5.9%, best peak elevation 56.0 deg ph1-s0-p00-sat02: 2 passes, visible 4.0%, best peak elevation 57.8 deg

Motion is not a small correction

Run the departure airport as a fixed platform over the identical window:

Platform `JFK ramp`: 60 satellites analyzed over 7.0 h, 107 passes above 10 deg. ph1-s0-p00-sat00: 5 passes, visible 7.8%, best peak elevation 45.9 deg
PlatformTotal passessat00 passessat00 visiblesat00 best peak
Fixed at JFK10757.8%45.9 deg
Flying JFK to LHR9035.7%54.7 deg

Analyzing at the departure point overstates passes by 19 percent, in the optimistic direction, for a connectivity requirement.

Note that peak elevations went up while pass counts went down. The aircraft moves east under the pattern, so it spends less time within reach of any single satellite but meets some of them closer to overhead. Fewer, better passes is a different scheduling problem from more, worse ones, and neither summary alone tells you which you have.

The midpoint shortcut agrees, and is still wrong

The obvious refinement is to analyze at a fixed point in the middle of the route, at cruise altitude. Mid-Atlantic, 53.0 N, 30.0 W, 11.6 km:

Platform `Mid-Atlantic midpoint`: 60 satellites analyzed over 7.0 h, 90 passes above 10 deg.

90 passes, exactly matching the moving platform. A check that stopped at the summary line would conclude the approximation is sound.

Compare per satellite and the agreement disappears.

  • 24 of 60 satellites have a different pass count.
  • Per-satellite visible time differs by -2.85 to +2.14 percentage points.
  • The mean of those differences is +0.13 points.

The errors are large individually and cancel in aggregate. Only 18 of 60 satellites match exactly.

That cancellation is the trap, and it is not a coincidence to be relied on. It happens because the route is roughly symmetric about the midpoint, so satellites favored in the first half are penalized in the second. The total is preserved and the assignment is scrambled.

Which is fine if your question is “how many contact opportunities exist” and useless if it is any of:

  • Which satellite serves the aircraft at 03:15?
  • Is there a handover gap over the mid-Atlantic?
  • Which spacecraft need capacity allocated on this route?

Those are the questions people actually ask about a moving platform, and every one of them is answered per satellite.

Validity of the waypoint model

Legs are great-circle interpolations between waypoints. Real routes are not great circles: they follow tracks, jet streams, and airways.

Two consequences. Between sparse waypoints the modeled position drifts from the real one, so use enough waypoints to follow the intended track. Outside the waypoint span the endpoint holds with zero velocity, so a window longer than the route silently analyzes a stationary platform sitting at the destination.

The tool validates that waypoint times strictly increase and rejects any leg implying more than 3 km/s of ground speed, which catches a wrong time unit. It cannot tell you the route is unrealistic, only that it is impossible.

Check the window against the route span. The 7-hour analysis above uses a 25200-second route, so the final 1800 seconds analyze a parked aircraft at Heathrow. That is deliberate here and would be a defect if unnoticed.

Ships, vehicles, and anything else

The same structure covers any surface or airborne platform. A ship is slower and needs fewer waypoints; a vehicle needs more because it turns. Set alt_km to the real altitude, since the horizon depends on it.

There is no separate ground-station concept: a station is a platform with a fixed trajectory, which is why the comparison in this guide is a like-for-like one.

Checklist

  1. Does the route span cover the analysis window?
  2. Are there enough waypoints that great-circle legs follow the intended track?
  3. Are altitudes real, including climb and descent?
  4. Did you compare per satellite, not just the total?
  5. If you approximated with a fixed point, did you verify per satellite that the approximation holds?

Point 5 is the one this guide exists for. The aggregate agreed exactly and the approximation was still wrong.

Next steps

Question? Give us feedbackDocuments Varaha Constellation Designer main (pre-release)
Last updated on