Data Budget

The Data tab answers: how much data can my satellite collect, downlink, and store given my payload data rates, ground station access windows, and onboard storage?

It depends on a propagated orbit (for sunlit/eclipse conditions) and, for access-driven collection or downlink, on completed access computations.

Overview

A data budget run computes, at every timestep:

1. Data collection — how much data each payload generates, based on its collection rate and activation rules.
2. Data download — how much data is downlinked, based on each downlink’s rate and activation rules.
3. Storage usage — the cumulative data stored onboard, accounting for collection minus downloads and the storage capacity limit.

Results render as time-series plots, a summary card, and a downloadable CSV.

Inputs

Satellite & timeline

• Select Satellite — the spacecraft to analyze. Must already have a propagated orbit.
• Data Budget Simulation Interval — a per-satellite UTC start and end date/time (YYYY-MM-DD HH:mm UTC) within the scenario bounds, from 15 minutes up to 90 days. In the interval modal you can check Use scenario interval, pick an explicit end date/time, or enter a duration in days (d), hours (h), and minutes (m).

Data payloads

Each payload is defined by a Default Data Rate (Mbps) (generated when no rule matches), a Compression Ratio (1:1, 2:1, 4:1, 8:1 — scales the effective rate written to storage), and an ordered list of activation rules:

Field	Unit	Notes
Name	—	Free text (e.g. Imager, SAR, AIS receiver)
Default Data Rate	Mbps	Generated whenever no rule is active (e.g. standby housekeeping data, or 0)
Compression Ratio	—	Multiplier applied between the rule rate and the data written to storage
Rule Data Rate	Mbps	Generated while the rule is active
Max Continuous On	s (optional)	Caps how long the rule can stay continuously active before falling back to the default rate
Conditions	—	Any combination (AND) of Sunlit, Eclipse, Access, Link (closed-link windows), and Coverage (IDs within a condition are OR’d)

Data downlinks

Data downlinks use the same rule model as payloads (minus compression). Each downlink has a Name, a Default Downlink Rate (Mbps) applied when no rule matches, and an ordered list of rules, each with its own Downlink Rate and conditions (Sunlit, Eclipse, Access, Link, Coverage, optional Max Continuous On cap).

This replaces the older one-access-one-rate model: a single downlink (e.g. your X-band transmitter) can now downlink at different rates over different ground stations, gate downlinks on illumination, or cap continuous transmission time — without creating a separate entry per access. Legacy per-access download configurations are still loaded and remain editable.

Storage capacity

Onboard storage capacity in GB, configured in the sidebar’s Storage Settings section. Storage integrates collection minus download over the interval and is clamped at 0 and at the capacity.

Schedule preview

Both the payload and downlink modals show a live Computed Schedule table: every resolved active/idle segment with start, stop, duration, the Access / Target that won (the ground station or AOI coverage driving that segment), the applied rate, and a Capped marker when the max-continuous-on limit cut a segment short. Header stats show active-time percentage, average rate, and estimated total data. Use it to sanity-check rules before running the full computation.

Activation rules

Rules are shared with the Power Budget model:

• Rules are evaluated top-to-bottom at each timestep; array order is priority. The first rule whose conditions all hold wins and sets the rate.
• Conditions within a rule are AND’d — e.g. Access + Sunlit means “during a pass AND in sunlight”.
• Multiple IDs inside one Access, Link, or Coverage condition are OR’d — the condition is true inside the union of all their windows.
• If no rule matches, the default rate applies.
• Max Continuous On resets each time the rule’s conditions go false → true (e.g. the next pass). Once exceeded, the item falls back to its default rate for the rest of that continuous window — other rules are not re-checked.

Link (closed-link) conditions

An Access condition uses the raw visibility window — when the satellite is above the ground station’s elevation mask. A Link condition uses the actual closed-link window from Link Budget: the sub-intervals of each access window where the RF link closes, i.e. where the computed link margin is ≥ 0 dB. A pass can have several minutes of visibility where the link is open (margin < 0) — a Link condition only activates during the parts that can actually carry data.

• Each Link condition selects one or more of the satellite’s Link Budget definitions (OR’d within the condition). Each entry shows its direction, configured data rate, and how many closed windows it produces — links whose geometry is still pending or that never close are flagged in the list.
• Closed windows are extracted from the link’s stored pass geometry evaluated against its current RF configuration; the exact margin = 0 dB crossing time is interpolated, so open→close transitions inside a pass are cut at the precise instant.
• Use link data rate — instead of the rule’s manual rate, the segment runs at the winning Link Definition’s configured data rate. When several selected links are closed at once, the highest rate wins.
• Resolve overlapping / close links — the same de-confliction model as accesses (First link / Longest link + minimum time separation), applied to closed-link windows rather than raw access windows. Use it when two radios or stations can’t transmit at once.
• A Link condition requires a completed link-budget geometry for that definition; a link with no closed windows simply never matches.

The Access / Target column in the schedule preview shows the winning link (with its data rate) for each active segment.

Resolving overlapping / close accesses

Selecting several accesses in one Access condition is an OR — and without de-confliction, overlapping passes silently merge. If Svalbard covers 10:00–10:12 and Troll covers 10:08–10:22, the condition is simply active 10:00–10:22 as one continuous window. Splitting the stations into two separate rules does not help either: rule priority only picks which rate applies at each instant, so when the first pass ends the second rule picks up mid-pass with zero handover gap.

Inside each Access condition, the Resolve overlapping / close accesses checkbox enables window-level de-confliction before rule evaluation. Two passes conflict when they overlap, or when the gap between them is smaller than the configured separation. Conflicting windows are dropped whole — never trimmed or stitched.

Field	Options	Effect
Selection criteria	First access / Longest access	Which pass wins each conflicting cluster: the earliest-starting one, or the longest-duration one
Min time separation	seconds (≥ 0)	Required gap between accepted passes. 0 blocks only true overlaps; > 0 also drops passes that are merely close (handover, slew, or transmitter-cooldown gap)

With First access, passes are walked chronologically; each pass is kept only if it starts at least the minimum separation after the end of the last kept pass. With Longest access, passes are considered longest-first; each is kept only if it does not conflict with any already-kept pass. The setting is per condition, per rule — different rules can use different strategies.

Example

One Access condition selects four station passes:

Station	Pass (UTC)	Duration	Notes
Svalbard	10:00–10:12	12 min	Overlaps Troll (10:08–10:12)
Troll	10:08–10:22	14 min	Longest of the cluster
Punta Arenas	10:24–10:30	6 min	Starts only 2 min after Troll ends
Kiruna	10:45–10:55	10 min	Well separated from everything

Setting	Kept passes	Active spans
Unchecked	all four	10:00–10:22 (merged), 10:24–10:30, 10:45–10:55
First access, 0 s	Svalbard, Punta Arenas, Kiruna	10:00–10:12, 10:24–10:30, 10:45–10:55
Longest access, 0 s	Troll, Punta Arenas, Kiruna	10:08–10:22, 10:24–10:30, 10:45–10:55
Longest access, 300 s	Troll, Kiruna	10:08–10:22, 10:45–10:55

• Unchecked: Svalbard + Troll fuse into a single 22-minute active span.
• First access: Svalbard wins the cluster; Troll is dropped entirely — no 10:12–10:22 tail is kept.
• Longest access, 0 s: Troll (14 min) beats Svalbard (12 min). Punta Arenas doesn’t overlap Troll, so it survives.
• Longest access, 300 s: Punta Arenas starts only 2 min after Troll ends — inside the required 5-minute gap — so it is dropped too, even though it never overlapped anything.

The Access / Target column in the schedule preview shows which station survived for each active segment, so you can verify de-confliction at a glance.

Computation

Data Budget runs as an event-driven simulation directly in the browser — not on a fixed timestep grid. Collection and download rates are piecewise-constant between window boundaries, so the integrator:

1. Resolves every payload and downlink schedule into exact active/idle segments (same code as the live preview).
2. Walks the union of all segment boundaries, integrating storage continuously.
3. When storage would cross 0 or the capacity inside a segment, it splits the segment at the exact crossing time — collection stops at full storage (excess is lost) and downloads are limited to buffered data.
4. Emits a compact set of boundary points (typically a few hundred per run instead of ~130,000 per-minute documents for 90 days) and persists them on Save & Run.

• Collection — each active payload stores rate ÷ compression_ratio × Δt.
• Download — each active downlink removes rate × Δt from storage, limited to what’s buffered.
• Storage — clamped to [0, capacity]; the 3D viewer interpolates storage and cumulative values between boundary points so playback stays smooth.

Outputs

Plots

One plot per type per satellite, added and toggled from the sidebar’s Plot Selection section:

Plot	Unit	Shows
Data Collection	GB	Per-payload data collected — accumulated within each active window (sawtooth) plus cumulative totals
Data Download	GB	Per-downlink data downloaded — accumulated within each pass (sawtooth) plus cumulative totals
Storage Usage	GB	Onboard stored data over time

Results summary card

Metric	How it’s computed
Data collection (per payload + Total)	Cumulative GB generated by each payload over the interval
Data downlink (per downlink + Total)	Cumulative GB downlinked by each downlink
Current Usage	Stored GB at the end of the interval
Peak Usage	Highest storage utilization reached (% of capacity; orange >70%, red >90%)
Total data loss	GB that could not be collected because storage was full (shown only if >0)
Data balance	Collected minus downloaded (net GB accumulated)
Download efficiency	Downloaded ÷ collected (%)

CSV export

The Download Output CSV button writes all time series joined on timestamp: per-payload collection, per-downlink download, totals, and storage usage.

Limitations & assumptions

• Access windows ≠ link closure — Access conditions transfer data for the full visibility window regardless of link quality. Use a Link condition to restrict activity to intervals where the link actually closes (margin ≥ 0 dB).
• Link conditions need computed geometry — closed-link windows come from the stored link-budget pass geometry. If the geometry is stale or pending, that link contributes no windows.
• Instantaneous storage — collection stops when storage is full (excess is lost) and download is limited to what is buffered; there is no queuing or packet-level modeling.
• Dropped passes are dropped whole — de-confliction removes an entire conflicting window; it does not partially use the non-overlapping tail. Model a partial pass by defining a second rule on the remaining target instead.

Tips

• Run a single orbit first and check the schedule preview — it shows exactly which passes survive your rules before you pay for a long run.
• Use First access when a contact already in progress should not be interrupted by a later station; use Longest access when you want the best pass of a cluster.
• Set Min time separation to your real handover/cooldown time (e.g. 60–300 s) so back-to-back passes on different stations don’t merge into an unrealistic continuous downlink.
• Prefer a Link condition + Use link data rate for realistic downlinks: it respects the parts of each pass where the link is actually closed and keeps the rate in sync with the Link Definition.
• If Peak Usage hits 100%, either downlink earlier in the orbit or add passes — the card reports the lost GB explicitly.
• Access-activated conditions require a completed access computation for the satellite; coverage conditions require an AOI coverage entry; link conditions require a computed Link Budget geometry.

Next steps

• Access — access windows drive downlink opportunities
• Link Budget — RF link margin for your downlinks
• Power Budget — the same rule model applied to power loads