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
- A constellation.
- Access windows and pointing, which this guide extends.
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 60Platform `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 degMotion 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| Platform | Total passes | sat00 passes | sat00 visible | sat00 best peak |
|---|---|---|---|---|
| Fixed at JFK | 107 | 5 | 7.8% | 45.9 deg |
| Flying JFK to LHR | 90 | 3 | 5.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
- Does the route span cover the analysis window?
- Are there enough waypoints that great-circle legs follow the intended track?
- Are altitudes real, including climb and descent?
- Did you compare per satellite, not just the total?
- 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
- Access windows and pointing for the pointing series and step-size discipline.
platform-accessreference for the full platform schema.
main (pre-release)