How Satellites Communicate
If you've only worked with terrestrial infrastructure, there's one thing you don't usually think about: uptime. If you can't reach a service, that's because your connection is down, or more rarely, the service is down.
With satellites, there's a third possibility: the satellite is just not in range. The mental model shift here is significant. Cloud servers are always on, always reachable, and round-trip times are measured in milliseconds. Satellites in low Earth orbit are none of those things.
So, understanding the connectivity model is essential because it shapes how every orbital service works, including the ones you'll integrate through Orbitport, which, fortunately, attempts to abstract that away from you as a developer.
Low Earth Orbit: the basics
The satellites that power SpaceComputer's services orbit at roughly 500-2000 km altitude. This is called Low Earth Orbit, a very fast orbit that is not so far away to make latency unbearable, but also not so close that it decays easily. For example, the ISS operates at ~400km and Starlink satellites at ~500km. At that height, orbital mechanics dictate a period of about 90 minutes per revolution around the Earth. The satellite is moving very fast, around 7.5 km/s relative to Earth's surface, which poses some interesting challenges.
First of all, the range. If you're taking off on an airplane, maybe only half the city sees you. If you're 10km away, then maybe a small country sees you. If you're 500km away, then maybe the whole Europe sees you. This is why you can literally see the ISS flying above you at night. Here's a graphic of the CUTE satellite passing over Europe:
Anyway, from any given ground station's perspective, the satellite rises above the horizon, crosses the sky, and sets again in about 5 to 15 minutes. That's your communication window. Once it drops below the horizon, you're done until the next pass, which could be hours later depending on the orbit geometry and how many ground stations you have.
This is nothing like a data center. There is no persistent TCP connection. There is no always-available endpoint. The satellite is reachable in short bursts, and everything about the system has to be designed around that constraint.
Why LEO specifically?
Higher orbits are great for their own reasons. For example, geostationary earth orbit (GEO) satellites are so far away that they move at the same speed as the Earth spins around itself. From an earth standpoint, they're stationary and theoretically accessible 24/7 from basically half the globe, making them very useful for weather, surveillance, and communication. Unfortunately that means they orbit very far away, like ~36000km away. This means that placing a GEO satellite is incredibly expensive and latency is unbearable for synchronous communication, and radiation wants to fry their electronics like a breakfast egg. These electronics need to be so heavily shielded from cosmic radiation, they aren't as fast as we wanted to and have less "computational density".
LEO, however, has compelling advantages for compute workloads. The lower altitude means lower launch costs, lower radiation exposure for electronics, and lower signal latency during passes. The tradeoff is the short pass windows, but for services like cTRNG, where data is generated continuously and downloaded in batches, LEO is the right choice.
Most of the new space economy operates in LEO. The satellites are smaller, cheaper to build and launch, and can be replaced more frequently as hardware improves. This is the orbit that makes commercial space computing economically viable.
Orbital geometry and pass frequency
A satellite's orbit isn't random. It follows a precise, predictable path determined by its altitude, inclination (the angle of the orbital plane relative to the equator), and other parameters. This means you can predict exactly when a satellite will be visible from a given location, weeks or months in advance.
For a typical LEO satellite in a polar or near-polar orbit, a ground station near the equator might see the satellite 4-6 times per day, with each pass lasting 5-15 minutes. A ground station at higher latitudes sees more passes from polar-orbiting satellites, because the orbital tracks converge near the poles.
This predictability is both a constraint and an advantage. You know exactly when data will arrive, which lets you plan around it. But you also know exactly when you won't have connectivity, which your system has to handle gracefully.
Ground stations: the intermediary
A ground station is the physical link between terrestrial networks and the satellite. It has an antenna (often a tracking dish that follows the satellite across the sky), a radio transceiver, and networking equipment to bridge into the internet. If it sounds easy, that's because it is, and you can run your own DIY ground station for less than $100. Of course, it won't be reliable enough for commercial usage, but it follows the same principle as the ground stations we use at SpaceComputer.
When a satellite passes over a ground station, the two establish a link and exchange data as fast as they can before the pass ends. This creates a store-and-forward model:
- The satellite collects or generates data while in orbit (e.g., cTRNG values from cosmic radiation detection).
- It stores that data onboard until a ground station is in range.
- During the pass window, it dumps the buffered data to the ground station.
- The ground station forwards the data to terrestrial servers (like Orbitport).
The more ground stations you have, the more frequently you can download data. A single station might get 4-6 passes per day from a given satellite. A network of stations spread across different latitudes can increase that substantially, potentially getting a download opportunity every orbit.
Ground stations connect to one satellite at a time, dealing with every detail like pointing, encrypting, encoding, dealing with delay, transmission errors, and all the other environmental factors. Optimizing for these windows makes talking to satellites its own business, although some ground stations are used to talk exclusively to some satellites (ex. your neighbour's Starlink dish). Others are used for research purposes but they'll be happy to help you communicate if you schedule communication windows in advance. If this sounds "analog", that's because it often is: just like you'd schedule a few minutes in your university's supercomputer in 1960, you often need to arrange your comm slot via e-mail with some person working 9-5 on the other side.
Pass scheduling
Scheduling matters. Each pass has to be planned: which satellite talks to which station, what data gets prioritized, how much bandwidth is available in the window. When multiple satellites share a ground station network, passes can conflict. Two satellites might be visible simultaneously, but the antenna can only track one at a time.
Ground station operators maintain detailed schedules, allocating pass time across their customer base. For SpaceComputer, this means the rate at which new data arrives on the ground (ex. cTRNG) depends not just on how fast the satellite generates it, but on how much ground station time is available and how it's prioritized.
This is an operational layer that terrestrial developers never have to think about, but directly affects the freshness and availability of the data you consume through Orbitport.
Ground station networks
Individual ground stations have limited coverage. A station in Norway sees different passes than one in Chile. To maximize contact time with a satellite, operators distribute stations across multiple latitudes and longitudes.
Several commercial ground station networks (like AWS Ground Station, KSAT, and Leaf Space) offer ground-station-as-a-service by operating multiple, geographically distributed ground stations. Satellite operators can rent time on antennas around the world rather than building and maintaining their own stations, which dramatically lowers the barrier to operating a satellite.
Communication bands
Satellites communicate with ground stations using radio frequencies. Two approaches are relevant here:
S-Band (traditional)
S-Band (2-4 GHz) is the workhorse of small satellite communications. It's reliable and well-understood, but bandwidth is limited: typically a few Mbps at best. For SpaceComputer's workloads (random number data, attestation payloads, signed messages), this is more than sufficient.
The constraint isn't bandwidth per se, it's the combination of limited bandwidth and limited pass windows. You get a few megabits per second which is okay but... only for a few minutes. That puts a ceiling on how much data you can move per pass.
To put this in perspective, a single cTRNG value is 32 bytes. At even 1 Mbps, you can transfer tens of thousands of random values in a single pass, so it's clear that the bottleneck for randomness delivery isn't bandwidth but it's the generation rate of the onboard hardware and the frequency of ground station contacts.
LEO constellation relays
Services like Iridium and Starlink have changed the game by building satellite-to-satellite links. Instead of waiting for your satellite to pass over a ground station, it can relay data through a constellation of interconnected satellites that always have at least one node in contact with the ground.
This provides near-continuous connectivity. The tradeoff is cost and complexity: you need compatible hardware on your satellite and a commercial agreement with the constellation operator. But it eliminates the store-and-forward model entirely for satellites that support it.
Iridium's network covers the entire Earth's surface, including the poles and oceans. Starlink's inter-satellite laser links offer high-bandwidth relay capability. For orbital compute services that need lower latency and higher availability, constellation relay is increasingly attractive.
SpaceComputer's infrastructure can work with both models. Some satellites rely on direct ground station passes, others may use constellation relay links for lower-latency data delivery. The Orbitport abstraction layer aims to handle both transparently and abstract these complexities away from you.
What about latency?
Some back-of-the-napkin math tells us that speed of light to LEO and back adds about 3-10 ms of propagation delay depending on altitude. That's negligible compared to terrestrial internet latency, which is often higher and using much more complex infrastructure. But again, for most use-cases the real latency challenge isn't signal propagation: it's waiting for the satellite to be reachable.
If you're using direct ground station passes, "latency" isn't really the right concept. It's more like "data age": how long ago was this data generated onboard? It could be minutes or hours, depending on when the last pass occurred.
With constellation relay, you get closer to traditional latency semantics. The satellite relays data through the constellation in near-real-time, and the total path might add a few hundred milliseconds. Meaningful, but workable for most applications.
Comparing communication models
It helps to see these approaches side by side, especially if you're deciding how much latency and freshness variability your application can tolerate.
Direct ground station passes only
This is the simplest and cheapest model. The satellite stores data onboard, downloads it during passes, and the data makes its way to Orbitport. You'll see data freshness ranging from a few minutes to a few hours depending on how recently a pass occurred. Orbitport's IPFS beacon and derived randomness source smooth over the gaps.
For cTRNG consumers, this model works well. Randomness doesn't have a shelf life: a random number generated two hours ago is exactly as random as one generated two seconds ago.
Constellation relay (Iridium, Starlink)
With relay, data can reach the ground within seconds of generation. The satellite sends data to the nearest constellation node, which hops it through the mesh to a ground-connected node. Freshness drops from hours to seconds.
The cost is higher: relay bandwidth isn't free, and the satellite needs compatible hardware. But for services where near-real-time delivery matters (think SpaceTEE computation results, or time-sensitive attestations), relay is the enabling technology.
Hybrid
In practice, many satellite missions use both. Bulk data (large cTRNG batches, telemetry, diagnostics) goes through ground station passes when bandwidth is plentiful and free. Time-sensitive data (attestation results, SpaceTEE outputs, alerts) routes through constellation relay for immediate delivery.
Orbitport's architecture supports this hybrid model natively. The source selection logic and fallback chain don't care how the data reached the ground. They care about what data is available and how fresh it is.
A note on security of the communication link
Satellite-to-ground communication travels through open space. Anyone with the right antenna and receiver tuned to the correct frequency could, in principle, intercept the signal. This is true for S-Band, constellation relay, and any other radio-based link.
This is why cryptographic signing onboard the satellite matters so much. Even if someone intercepts the data in transit, they can't modify it without invalidating the signature. And since cTRNG values are meant to be public (or at least not secret), interception of the raw data doesn't compromise security.
For SpaceTEE workloads where the computation output might be sensitive, the data would be encrypted onboard before transmission, using keys established through the remote attestation process. The communication link is treated as untrusted, and the cryptographic protocols handle the rest.
This is the same philosophy as TLS on the internet: assume the network is hostile, and protect data at the application layer.
The bigger picture
Satellite communication is evolving fast. More ground stations, more constellation relay options, and eventually on-orbit networking between compute satellites will keep pushing latency down and availability up. The store-and-forward model that dominates today is a transitional state, not an endpoint.
But even as connectivity improves, the fundamental character of orbital services remains: they're physically remote, they follow orbital mechanics, and they offer properties (like physical isolation) that no terrestrial infrastructure can replicate. Understanding the communication layer helps you appreciate both the constraints and the guarantees that make orbital services worth using in the first place.
What this means for you (spoiler alert: not much)
Everything above — the pass windows, the batching, the variable data freshness — is real, but it's not your problem. Orbitport abstracts all of it. You call an API or use the SDK, and you get randomness. Whether that value arrived from a satellite ten minutes ago or was derived from a cosmic seed is handled by the source selection and fallback chain behind the scenes.
The reason this page exists isn't to give you things to worry about, but background information on why the IPFS beacon publishes on a 60-second cycle, why there's a derived randomness fallback, why source selection exists at all. The communication constraints explain the architecture. If you want the details on how Orbitport handles all of this, that's covered in the Orbitport architecture page.