Your CubeSat Link Budget Isn’t Flight Data

You have a CubeSat radio, an antenna, and a link budget that closes on paper. What you may not yet have is measured, end-to-end evidence that the integrated communications system closes a link in flight: your radio, installed antenna, harness, structure, protocol, ground station, and operations workflow working together over defined range and geometry.

Bench, chamber, and RF-emulator testing remain essential. A stratospheric flight adds something different: an operational test of the flight article and ground segment together, with measured packet delivery, received signal strength, flight geometry, and environmental data before you commit the hardware to orbit.

This article explains what a balloon flight can validate, what it cannot, and what StratoStar's Flight Data Package provides to turn a flight into an engineering record.

A link budget is a model

A link budget is an analytical prediction. It combines transmit power, antenna gain, cable and integration losses, free-space path loss, receiver sensitivity, modulation, coding, polarization, and margin. It is indispensable — but it depends on inputs and assumptions.

A bench test can validate conducted radio performance. An anechoic chamber can characterize an antenna or an installed antenna pattern. An RF channel emulator can apply controlled delay, fading, and Doppler scenarios. Each test answers an important question.

The remaining question is whether the complete operational chain works when the actual flight hardware is airborne:

• The radio is installed in its actual payload configuration.
• The antenna is mounted near the actual structure, batteries, harnesses, payload electronics, and other radiating or reflective surfaces.
• The flight computer, radio firmware, packet format, command handling, telemetry pipeline, and ground-station software operate as a system.
• The link is exercised over changing slant range, elevation angle, payload orientation, and line-of-sight geometry.
• The receive chain records signal strength, link quality, and packet delivery with the actual ground equipment.

That is why a link budget should be treated as a prediction to test — not the final evidence that a communications subsystem will operate as intended.

Why a balloon flight helps

A high-altitude balloon provides a real stratospheric flight environment for the payload and a long line-of-sight path to one or more customer ground stations. At typical flight altitudes of roughly 80,000–100,000 ft, the payload can be visible across hundreds of miles, depending on altitude, terrain, station elevation mask, antenna placement, and the required link margin.

The value is not that a balloon duplicates orbit. It does not.

The value is that it can exercise the exact communication chain you intend to fly:

• Your payload transmits telemetry to your ground station.
• Your ground station can transmit commands or acknowledgments back to the payload.
• Your team measures downlink packet delivery, RSSI or calibrated received power, SNR where available, and command success.
• The flight produces time-correlated location, altitude, and environmental data so RF performance can be evaluated against range and geometry.
• The payload is recovered for post-flight inspection and functional testing.

A balloon flight is not a replacement for conducted RF testing, anechoic measurements, thermal-vacuum, vibration, radiation, or orbital Doppler validation. It is a complementary test that can retire a high-value integration and operations risk: does the real flight article close the intended link using the real ground segment?

How far can a radio at 100,000 ft actually be heard?

Most engineers have never had a reason to work out what a balloon can do, so it is worth being concrete before looking at any numbers. A payload at 80,000–100,000 ft sits above 97–99% of the atmosphere by mass. It is not in space, and it is not moving fast. What it has is height, and height buys geometry.

Those are geometric horizons for a ground station at sea level; atmospheric refraction extends them, and terrain, elevation mask and link margin pull the usable figure back in. The last of those is the one that bites. On the flight described below, a payload at 98,737 ft used only about two-thirds of the horizon available to it before it ran out of link margin — and was still heard by stations in five states. A link budget that closes at 50 km on the bench is being asked to do something very different at 400.

The other half is time. A ground station watching a satellite in low Earth orbit gets roughly ten minutes per pass, a handful of times a day, with the geometry changing quickly throughout. A stratospheric flight inverts that: two to three hours aloft on a flight qualification mission, or a three-to-six-hour sustained float on an integrated flight, with the range and elevation angle changing slowly enough that you can sweep a parameter, repeat a measurement, or watch a link degrade and recover.

That is the trade in one sentence. A balloon flight is the wrong environment for exercising fast handover and Doppler tracking, and the right one for characterizing a link. You get hours of continuous, real, long-range RF in a space-like channel, with the payload recovered by the StratoStar team the same day and back in your hands within 72 hours.

What the data actually looks like

Here is what that geometry produces in practice. On a StratoStar flight from Jeffrey City, Wyoming in August 2026, the payload carried a 915 MHz ISM-band LoRaWAN tracking radio (US915 channel plan), alternating a beacon packet at SF10 with a science packet at SF9. It climbed to 98,737 ft. Every packet the network received is logged with the receiving gateway's identity and position and with the spreading factor it was sent at — so each reception yields a measured slant range and a measured margin, not a modeled one.

Not one of those 36 stations belongs to StratoStar, and none is within 138 km of the launch site. There was no home-field advantage on this flight and no station placed to make the numbers look good — the payload was heard by whoever happened to be listening. The first reception does not occur until 15,374 ft for the same reason: below that altitude nothing was above the payload's horizon.

What altitude actually buys

Median range grows by a factor of 2.2 from the bottom of the profile to the top. Median received power moves one decibel. Median margin moves 1.3 dB, and not in one direction.

Altitude did not make the link stronger. It enlarged the set of ground stations that could close it at the same signal strength. That distinction is invisible from the ground and obvious in flight, and it is the difference between a link budget that assumes a station and a flight that finds out how many there really are.

Margin, measured

Because the spreading factor is recorded per packet, every reception can be compared against its own demodulation threshold — −15.0 dB SNR at SF10, −12.5 dB at SF9.

The link ran with about 2 dB in hand for the whole flight. That is a thin margin, and it is a real number rather than an assumed one.

It is also worth noticing what the last column says: roughly one reception in four arrived at or below the nominal threshold for its spreading factor, and decoded anyway. The farthest reception of the entire flight — 448 km, from 98,737 ft — came in at −16.5 dB SNR, 1.5 dB below the SF10 threshold. In a link budget the threshold is a single hard value in a spreadsheet cell. In flight it is a distribution, and the tail of that distribution is where the interesting packets live.

The median signal-to-noise ratio is worth its own sentence. This link spent the entire flight below the noise floor and decoded regardless — LoRa's processing gain buying roughly 20 dB that a conventional narrowband receiver would not have. Modulation choice is not a paper variable.

It never ran out of horizon

At 98,737 ft the payload had 689 km of line of sight available and used 448 km of it. The link ran out of margin before it ran out of horizon, at every altitude on the profile.

This is the practical answer to a question a link budget cannot settle: whether the binding constraint on a stratospheric link is geometry or power. On this flight, above about 30,000 ft, it was never geometry.

Read this as a template, not as a result

None of these numbers are your radio's. They belong to a platform tracking link on one flight, received by a public network whose gateways have unknown antenna gain, unknown feedline loss, unknown noise floor and unknown height. Slant range here is genuinely measured, because gateway positions are known — when they are correct. Margin is genuinely measured, because the spreading factor is recorded. But nothing in this dataset is calibrated, and no honest reading of it pretends otherwise: fitting received power against range across all 313 receptions gives a slope of −3.7 dB per decade where free space requires −20, because the difference between a good gateway and a poor one is larger than the difference between 130 km and 448 km.

What transfers is the method. Every reception logged with a real station identity and position, so range is measured rather than modeled. Time-correlated altitude and geometry, so a link result can be read against the conditions that produced it. And a recorded modulation setting, so “it worked” becomes a number in decibels above a known threshold.

What does not transfer is the argument for your own ground station. Everything this dataset cannot tell you — real margin against a receive chain whose gain and noise floor you know — is exactly what a customer gets by flying their own radio to their own characterized station. Thirty-six strangers' gateways can prove the geometry. Only your own station can prove the link.

The Flight Data Package

A useful flight test does more than put hardware at altitude. It provides an engineering data record that connects payload behavior, environment, and link performance.

StratoStar's Flight Data Package, delivered from every Flight Qualification Service (FQS) and Integrated Flight Service (IFS) mission, includes:

• Payload video and photographs. Flight imagery documents the payload's physical configuration, mounting, antenna deployment or orientation where visible, flight conditions, and recovery state. It also provides material for program reviews, sponsors, investors, and flight-heritage documentation.
• 3D flight-location data. GPS and pressure-sensor data provide time-correlated latitude, longitude, altitude, and trajectory information. This allows the customer to reconstruct payload-to-ground-station geometry rather than treating the RF result as an isolated packet log.
• Environmental data for cold-soak validation. Flight environmental sensors record the low-temperature exposure experienced by the payload. This gives teams data to compare against component operating limits, battery performance, enclosure design, thermal assumptions, and post-flight functional results.
• RF link testing with one or more ground stations. Customers can operate their own receive-only station, uplink/downlink station, or multiple stations. The mission can be structured to test downlink telemetry, uplink commands, command acknowledgments, packet retransmission behavior, and station-to-station coverage differences.
• Packet-loss and signal-strength measurements. With appropriately instrumented payload and ground equipment, the test can record transmitted packets, received packets, sequence gaps, packet-delivery ratio, RSSI or received power, SNR/link-quality metrics where supported, and command success rate.
• Range- and geometry-correlated analysis. When RF logs are time-aligned with flight position, altitude, and ground-station coordinates, the customer can compare expected link-budget performance with observed performance across a documented test profile.

For an RF campaign, the most useful preflight test plan specifies the radio frequency, bandwidth, modulation, coding, data rate, transmit power/EIRP, antenna configuration and polarization, packet interval, expected ground stations, station antenna gain, receive-chain configuration, and success criteria. A result is only as useful as the configuration record that accompanies it.

What RF customers can test

The test plan should define the intended claim before launch. For example: "Demonstrate at least 99% downlink packet delivery at the selected packet rate while the payload is above a defined altitude and the ground station is within a defined elevation mask." That is more defensible than an undifferentiated claim of "long-range RF success."

Where the telemetry actually goes

The flight above used a public LoRaWAN network, which raises a fair question for anyone flying something sensitive: who can read the data?

In LoRaWAN the answer is structural. The payload is encrypted end to end. The device holds an application session key, the customer's application server holds the matching key, and nothing in between holds either. A gateway — Helium or otherwise — is a radio relay: it receives an encrypted frame and forwards it to the network server. It cannot decrypt the payload, and neither can the network operator.

What a public network does expose is metadata. A gateway sees that a device transmitted, when it transmitted, the signal strength it arrived at, and the device address it came from. Contents are protected; pattern of life is not. For most flight-test programs that distinction is immaterial. For some it is the whole question, and it should be settled before launch rather than after.

It is also not the only option. A customer flying an RF payload to their own ground station is not using a public network at all — the link is theirs end to end. Missions with sensitive payloads fly under a Sensitive Payload Addendum, and StratoStar operations are US-based and US-person only.

What the flight does not prove

Engineers should be clear about the limits of a stratospheric communications test.

A balloon flight does not duplicate a LEO mission:

• It does not reproduce an orbital spacecraft's rapid range-rate and Doppler profile. A LEO satellite moves at roughly 7.5 km/s, while a balloon drifts with the wind and has much slower relative motion.
• It does not reproduce orbital attitude dynamics, a spacecraft's full pass geometry, or handover between an operational ground-station network.
• It does not reproduce hard vacuum, radiation exposure, atomic oxygen, or the full thermal cycling of an orbital mission.
• It does not replace launch-vibration, shock, thermal-vacuum, EMC/EMI, radiation, or specialized RF qualification campaigns.
• It does not automatically establish a Technology Readiness Level on its own. It can provide evidence relevant to a program's readiness assessment when the test article, requirements, environment, documentation, and results match the customer's maturity plan.

What a flight can demonstrate is narrower and valuable: that a defined, integrated communications configuration performed over documented range, geometry, and environmental conditions using real flight and ground hardware.

Where this fits

This type of flight test is most valuable when the open risk is no longer "does the radio turn on?" but "does the integrated system work when we operate it as a mission?"

It is a strong fit for:

• CubeSat and SmallSat teams integrating a new radio, antenna, waveform, protocol, or flight-computer-to-radio interface.
• Payload teams that need to validate a long-range downlink, command channel, telemetry architecture, or ground-station workflow.
• Programs preparing for design review, customer demonstration, SBIR Phase II milestones, or a future Phase III/mission-readiness case.
• Teams comparing multiple antenna placements, configurations, firmware revisions, packet rates, coding schemes, or ground-station designs.
• Organizations that need a documented flight record — including video, imagery, location, environmental, RF, and post-recovery data — rather than a lab-only test report.

It is less valuable when the only open question is a single conducted RF parameter that a calibrated bench setup can answer more directly and less expensively.

The bottom line

A link budget predicts performance. Bench, chamber, and emulator tests characterize the system. A Flight Data Package adds measured end-to-end evidence from a stratospheric flight: your payload, your antenna, your radio configuration, and your ground station operating together over documented range and geometry.

Before committing a radio to orbit, fly the configuration you intend to operate. Measure packet delivery, signal strength, command success, environmental exposure, and flight geometry. Then compare the observed result to the model — and enter review with a test record, not only a spreadsheet.

Real flight test. Real data.

StratoStar Systems flies space hardware and stratospheric UAS payloads on a published Flight Test Calendar. Every FQS and IFS mission returns the Flight Data Package: flight imagery, time-correlated 3D location data, environmental data, and your recovered hardware for post-flight evaluation.

For RF customers, the flight can include testing with one or more customer ground stations to exercise receive and transmit functions, measure packet loss and signal performance, validate commanding workflows, and evaluate the communications system across large, documented flight distances.

A high-altitude balloon flight is not orbital qualification. It is one of the most accessible ways to obtain flight-relevant, end-to-end communications evidence before orbital launch.

StratoStar flight test service levels

FQS and IFS are StratoStar's two flight test service levels for customer payloads. Both fly on the published Flight Test Calendar, both return the Flight Data Package, and both return your hardware within 72 hours of landing.

For an RF campaign the choice usually comes down to duration and commanding: FQS gives you a two-to-three-hour profile through the full altitude band, while IFS holds a sustained float with real-time telemetry and uplink, so you can command the payload, change a parameter and watch the link respond while it is still airborne.

Sources and technical notes

1. Lay, J., Li, A., & Okutsu, M. (2022). High altitude balloon testing of Arduino and environmental sensors for CubeSat prototype. HardwareX, 12, e00329. https://www.sciencedirect.com/science/article/pii/S2468067222000748
2. NASA Small Spacecraft Systems Virtual Institute. State of the Art of Small Spacecraft Technology: Ground Data Systems and Mission Operations. https://www.nasa.gov/smallsat-institute/sst-soa/ground-data-systems-and-mission-operations/
3. NASA. Technology Readiness Assessment (TRA) Guidance. https://ntrs.nasa.gov/api/citations/20170005794/downloads/20170005794.pdf
4. StratoStar Systems. Space Flight Test. https://stratostar.com/space — source for current service descriptions, flight-test options, recovery-performance statements, flight calendar information, and payload-return timeline. Accessed August 22, 2026.
5. StratoStar Systems. First-party flight telemetry, 4 August 2026 flight from Jeffrey City, Wyoming (mission 6a84ab833c8d631c7bbc5f71). Internal flight record. Helium LoRaWAN on the US915 channel plan (902–928 MHz ISM band), uplinks observed on 903.9–905.3 MHz, SF9 and SF10, apogee 98,737 ft. Source for all reception counts, gateway counts, slant ranges, signal-strength, signal-to-noise and link-margin figures quoted above, and for the ground-station reception map. 153 receptions from a gateway whose registered position did not match its actual location were excluded.