Two systems that maximize mission success.
CubeSat33 is a next-generation 3U CubeSat bus built around two core systems that work together: dual-mode green propulsion — a single propellant that switches between fast chemical thrust and efficient electrospray mode — and high-speed laser communications with active beam steering. Together they give a small satellite the agility to go where a mission needs it and the data throughput to make the trip worthwhile.
Dual-mode green propulsion
One propellant, two jobs — so a small satellite can be both nimble and patient.
CubeSat33 carries a single tank of a green, non-toxic propellant that feeds two thrusters. In chemical mode it delivers fast, powerful thrust for quick maneuvers — changing orbit, dodging debris, or repositioning to catch a target. In electrospray mode the same propellant is accelerated electrically for ultra-efficient, fuel-sipping thrust that keeps the satellite on station for the long haul. One tank, two behaviors — far less overhead mass than carrying two separate propulsion systems.
The payoff is agility and endurance from a compact, low-mass package: the satellite can go where the mission needs it, when it needs to, without burning through its fuel budget. (Background on the underlying thruster families is in the propulsion deep-dive.)
Fig. 1 — One green propellant, switched between fast chemical thrust and efficient electrospray thrust.
High-speed laser comms with active beam steering
An optical downlink that empties the satellite's memory fast — on every pass it gets.
Radio is the traditional bottleneck: a CubeSat can gather gigabytes but trickle only a fraction of it home before a ground station drops below the horizon. CubeSat33 carries an optical (laser) communications terminal that moves far more data per second than radio — paired with active beam steering that keeps the narrow laser locked onto the ground station as the satellite races overhead at 7.5 km/s. The result is a high-rate downlink that rapidly empties the onboard recorder during every available pass.
Fig. 2 — Active beam steering keeps the laser locked on the station as the satellite crosses, emptying the recorder fast.
Redundant, autonomous, and lossless by design
The two core systems don't just make the satellite more capable — the bus is engineered so a single fault degrades the mission gracefully instead of ending it, and so the spacecraft can run its mission without waiting on the ground.
Mechanical failsafes: fail-operational, not fail-stop
Propulsion and communications are built as mechanically independent sides of the bus, each with its own failsafes. If either side fails, the other continues to operate at its full designed capacity — and the bus automatically makes the shared energy budget available to the operational side, so the surviving system runs with the power headroom it needs. A failure anywhere becomes a reduction in scope, never a dead satellite.
Autonomous commissioning on deployment
The bus confirms it has been released into space by an unambiguous physical signature: a negative oxygen-sensor reading sustained for 9 seconds, indicating it has left the deployer and is in vacuum. On that trigger — and only that trigger — the spacecraft enters an autonomous sequence in accordance with the mission objective: it powers up, detumbles, orients itself, and begins operations, with no ground command required to come alive.
Data pipeline: efficient onboard, lossless to Earth
Data is packetized into blocks as it is collected, which minimizes onboard processing and promotes energy efficiency — the spacecraft spends its power observing, not crunching. Those blocks are batched to servers on Earth quickly and without loss of data using zstd compression, which appends a 32-bit content checksum (the low 32 bits of an XXH64 hash) to the end of each frame. On decompression, the ground servers validate that checksum by default, so any corrupted frame is caught automatically — data integrity is guaranteed end to end.
Fig. 3 — Collected data is packetized, compressed with zstd (32-bit XXH64 frame checksum) and batched to Earth, where every frame is checksum-validated on decompression.
Where the laser link could lead: the relay vision
The two core systems above are the current, featured CubeSat33 design. What follows is a forward-looking concept that builds on the laser-comms capability — published here for discussion. It is not part of the baseline mission.
Recall the core problem from Earth-to-orbit comms: a LEO satellite sees a professional ground station for only minutes per orbit, and over remote regions it sees none at all. CubeSat33's optical terminal already gives it a fast link whenever a station is in view — but the same beam-steering, high-rate capability hints at something bigger.
Those "empty" regions are no longer empty of connectivity. A modern satellite communications system — Starlink being the clearest example, though the approach fits any similar network — already has terminals scattered across exactly these places and already operates every link those terminals depend on. A future version of CubeSat33 could relay through such a network — handing its data to a nearby terminal so the network carries it the rest of the way home, near-real time, even over the deep blackout zones. Doing so would require the operator's cooperation; no such arrangement exists today.
A temporary VPN stitched across space
There is a deeper capability hiding inside a network like this. A modern satellite communications system — Starlink, again, as the clearest example, though the principle holds for any operator with a meshed constellation and a large terminal base — already routes traffic dynamically across thousands of moving nodes. In theory, that same routing fabric could spin up a temporary, encrypted overlay — effectively a short-lived VPN — for the duration of a CubeSat's overhead pass.
The tunnel would be assembled on demand from whatever nodes happen to be in the right place at the right moment: the participating consumer devices beneath the satellite's track, the satellites currently serving those devices, and the orbiting CubeSat itself carrying mission-critical, real-time research data. For the minutes the geometry holds, those three elements form one secure, authenticated path; when the pass ends, the overlay tears down and its nodes return to ordinary traffic. The research data never touches the public internet until it has already crossed the operator's trusted network.
Where the blackout lives — and how relays close it
Left: a satellite over a remote region with no ground station in range stores its data and waits. Right: a positioned consumer Starlink terminal in that same region gives the satellite an immediate path home.
How a pass would work, end to end
Satellite tracks toward a remote region
The ion bus has biased the ground track so the CubeSat passes over a target zone — somewhere with no professional ground station but a Starlink-class terminal active below.
Handshake on a licensed link
As the region comes into view, the satellite connects to a participating terminal over a licensed satellite-to-ground link the operator would need to enable — a camp, expedition base or remote site on a network such as Starlink.
The network carries it the rest of the way
The terminal passes the data into the operator's network, which carries it across its inter-satellite laser mesh to a gateway and onward to the mission over the internet — every leg on infrastructure that network already runs.
Blackout window collapses
Instead of waiting up to ~150 minutes for a professional station pass, the data reaches the mission within the duration of the over-flight — turning a dead zone into a live downlink.
A volunteer relay network
The most ambitious version of the concept makes the ground segment intentional rather than purely opportunistic: a volunteer program in which, after a CubeSat is deployed and its ground track is known, opted-in users travel to strategically chosen remote locations — a stretch of coastline, a high plateau, a polar approach — and camp there with their own Starlink-class terminals during the satellite's overhead windows, specifically to provide a relay where the satellite would otherwise go dark.
It reframes the ground station from a fixed, expensive installation into something closer to a citizen-science expedition: enthusiasts contributing coverage with hardware they already own, positioned by the same orbital mechanics the mission already computes. A handful of well-placed volunteers along an orbit could meaningfully shrink the blackout — though, like the rest of the concept, this would still depend on a satellite operator enabling the relay link.
Placed by orbit, not by chance
The satellite's predicted ground track tells volunteers exactly where and when a relay would help most.
Hardware people already own
No custom ground station — a consumer terminal and a willingness to travel are the contribution.
Coverage grows with the crowd
Every additional volunteer node closes another gap. The network strengthens as participation grows.
Who would handle which leg of the tunnel
The concept works only if one satellite communications network operates the whole chain. Here is the division of responsibility it assumes — and what an operator such as Starlink would need to agree to enable.
The mission would supply the space segment: the CubeSat, its ion-propulsion bus, the onboard radio, and the orbit and ground-track planning that puts the satellite over high-value regions. A satellite communications operator (such as Starlink, or a similar system) would supply the ground and relay segment: the licensed satellite-to-terminal link, the terminals already deployed across remote areas, the inter-satellite laser mesh, the gateways, and the final hop to the internet. Because those legs already belong to that network, there would be no fragile, unofficial interface to maintain — the new work would be a sanctioned link between the CubeSat and the network's terminals, defined and licensed jointly.
The central ask is exactly that agreement: today, consumer terminals are designed to talk only to their own constellation, not to accept an uplink from a third-party CubeSat. An operator would have to choose to support it — exposing a relay mode on cooperating terminals, allocating spectrum for the satellite link, and setting the authentication and data-integrity rules for the service. Remaining engineering items — link budget and pointing during a fast over-flight, terminal firmware support, and the logistics of any volunteer program — would sit naturally within an operator that already runs a global network at scale.
Explore the rest of the site
Sources: NTIA — Overview of LEO Satellite Systems · Starlink Direct-to-Cell coverage (2025) · Direct Satellite-to-Device RAN measurements (2025) · MIT News — dual-mode propulsion (2026) · NASA State of the Art — Propulsion