| Altitude (km) | Elevation (deg) | Hops | ISL (km) | Backhaul (km) | Term (ms) | Hop (ms) | Gateway (ms) | Queue (ms) | One-way (ms) | RTT (ms) |
|---|---|---|---|---|---|---|---|---|---|---|
| 550 | 30 | 2 | 1200 | 200 | 8 | 1 | 4 | 5 | 42.63 | 85.25 |
This calculator estimates a space path (uplink + downlink) and adds relay hops. It then converts distance to propagation delay and adds processing and transport overhead.
- Earth radius:
Re = 6371 km - Light speed:
c = 299792.458 km/s - Slant range (each ground leg):
r = √((Re+h)² − (Re·cos e)²) − Re·sin e - Space path:
Dspace = 2r + (hops · Disl) - Propagation delay:
tprop(ms) = (Dspace / c) · 1000 - Backhaul delay:
tbackhaul(ms) = (Dbackhaul / (c·factor)) · 1000 - Total one-way:
toneway = tprop + tbackhaul + tprocessing - Round-trip:
trtt = 2 · toneway
h altitude, e elevation angle,
Disl average relay distance, and factor is fiber speed fraction.
- Enter the satellite altitude and your expected minimum elevation angle.
- Set the number of relay hops and an average hop distance.
- Add terrestrial backhaul distance to your cloud region or headquarters.
- Include realistic processing and queuing overhead from equipment and traffic.
- Review one-way and round-trip latency, then download CSV or PDF.
Why latency matters on distributed construction sites
Remote projects depend on cloud-based drawings, inspection photos, IoT telemetry, and real-time safety systems. Latency directly affects voice clarity, video smoothness, and the responsiveness of field applications. When teams operate across multiple zones, small delays compound into slower approvals and rework risk. This calculator helps quantify expected delay so connectivity can be designed around the workflow.
Key drivers inside a LEO path
The biggest physics term is propagation distance. Lower elevation angles increase slant range, raising delay. Inter-satellite relays add distance and forwarding time when traffic must traverse the constellation to reach a gateway. Terrestrial backhaul then carries data from the gateway to your cloud region or headquarters, where fiber speed and distance matter.
Processing overhead and real-world variability
Modems, encryption, scheduling, and buffering introduce processing time beyond propagation. During peak hours, queuing adds jitter that impacts video meetings and remote equipment support. Using realistic terminal, hop, gateway, and queuing inputs produces a practical estimate for budgeting and service-level targets. Add a safety margin when the project has critical uptime or strict response requirements.
How to interpret results for design decisions
Compare the physics-only number to the total estimate. If the gap is large, optimization should focus on equipment settings, routing, and backhaul improvements. For mission-critical controls, prioritize higher elevation operation where possible, reduce relay hops, and keep backhaul close to the chosen cloud region. For general collaboration tools, a moderate RTT can still deliver strong productivity with proper traffic shaping.
Example data and recommended starting assumptions
Example: altitude 550 km, elevation 30°, 2 hops, 1200 km per hop, backhaul 200 km, terminal 8 ms per end, hop 1 ms, gateway 4 ms, and queuing 5 ms. This yields about 42.63 ms one-way and 85.25 ms RTT. Start with your minimum elevation angle, then adjust hops and overhead based on your provider and traffic profile.
1) What is “elevation angle” and why does it change latency?
Elevation angle is how high the satellite appears above the horizon. Lower angles increase slant distance through space, which increases propagation delay and often raises error rates.
2) How do satellite hops affect the calculation?
Each hop adds inter-satellite distance plus switching overhead. More hops can improve coverage to a gateway but usually increases delay, especially across long relayed routes.
3) Why include terrestrial backhaul if the link is satellite?
Traffic still must reach your cloud region, data center, or headquarters. Backhaul distance and fiber propagation speed can contribute several milliseconds to one-way delay.
4) What should I use for “fiber speed factor”?
A practical starting value is 0.67. It approximates signal propagation in typical fiber. Use higher factors only if you have confirmed low-latency routes and equipment.
5) What does “processing + overhead” represent?
It captures modem framing, encryption, scheduling, gateway routing, and queuing. These items often dominate when networks are busy or when equipment is heavily configured.
6) Is the “best-case physics-only” value realistic?
It is a lower bound based on propagation plus backhaul only. Real deployments add processing and queuing, so plan with the total estimate and a margin for variability.
7) How can a construction team reduce perceived latency?
Favor higher elevation operation, minimize relay hops, choose a nearby cloud region, and apply traffic shaping for voice and video. Reducing buffers and avoiding congestion also helps.