Power Budget

The Power tab answers one question: can my satellite generate enough energy and store enough of it to survive its orbit, given its solar-panel layout, payload duty cycles, and battery?

It depends on a propagated orbit (for sunlit/eclipse geometry and the sun direction in the body frame) and, optionally, on completed access computations (for payloads that activate only during ground-station contact). Both Earth- and Moon-centered orbits are supported.

Overview

A power run re-propagates the selected satellite’s orbit over a per-satellite Power Simulation Interval (a sub-range of the scenario timeline), then computes four things at every timestep:

1. Power generation — how much electrical power each solar-panel surface produces, given the sun angle, eclipse state, and self-shadowing.
2. Power consumption — base bus load plus the sum of payload loads, each resolved from its activation schedule.
3. Power balance — generation minus consumption, the energy surplus or deficit at each instant.
4. Battery state — the integrated energy in the battery over time, with charge/discharge efficiency losses and clamping at full/empty.

Results render as time-series plots, a summary card, a downloadable CSV, and an animated 3D satellite viewer showing the sun vector and body axes.

Inputs

Satellite & timeline

• Select Satellite — the spacecraft to analyze. Must already have a propagated orbit.
• Power Simulation Interval — a start/end UTC pair, per satellite. It can be shorter than the scenario timeline to save credits during trade studies. Set via the Power Simulation Interval modal.

Base consumption power (W)

The always-on bus/avionics draw (e.g. 3–8 W for a 6 U CubeSat). Added to the consumption total at every timestep regardless of illumination or access.

Payloads

Each payload has:

Field	Unit	Notes
Name	—	Free text
Active Power	W (0–1000)	Drawn when the payload is active
Inactive Power	W (0–1000)	Drawn when the payload is inactive (e.g. standby)
Activation Schedule	—	One of three types (below)

Activation schedule types:

• Illumination Based — active when the satellite is sunlit, or when it is in eclipse. Uses the orbit’s per-timestep sunlit/eclipse state.
• Access Based — active during or not during a chosen access window. Requires a completed access run for the selected satellite; the dropdown lists only completed accesses. Lets you model a payload that only draws power during downlink passes.
• Deactivated — consumes 0 W and is excluded from the computation entirely.

The inactive-power condition is the logical opposite of the active condition and is shown read-only in the form.

Battery settings

Field	Unit	Default	Meaning
Capacity	Wh	15	Maximum stored energy
Initial Charge	% (0–100)	100	Battery state of charge at the start of the interval
Charge Efficiency	% (0–100)	90	Fraction of surplus energy that actually enters the battery
Discharge Efficiency	% (0–100)	90	Round-trip loss when drawing from the battery
Depth of Discharge	% (0–100)	30	Used by the summary card to flag a “critical” discharge

Self-shadowing

A toggle. When on, the per-face illuminated fraction is computed geometrically (body faces and deployable panels occluding each other) and multiplies each surface’s generated power. When off, surfaces are assumed unoccluded — faster but optimistic for compact satellites with deployed panels.

Solar-panel geometry (from the Model tab)

Power generation reads the satellite’s 3D model, defined in the Model tab. There is no solar-panel input inside the Power sidebar itself. The relevant per-face fields are:

• Material — Solar Panel (generates power) or Aluminum (does not).
• Face area — derived from the bus dimensions (in U; 1 U = 0.1 m).
• Cell efficiency — fraction of incident solar flux converted to electricity (e.g. 0.28 for 28%).
• Packing factor — fraction of the face area actually covered by cells (e.g. 0.6).
• Deployable panels — per wing: hinge face, deployment angle, trackable flag, flip flag, deployable area, and their own efficiency/packing. Two-sided non-solar deployables use the absolute value of the cosine term.

Computation scope

The steps below run at every propagation timestep.

1. Orbit re-propagation

The orbit is re-propagated with the numerical propagator over the power interval to obtain position, velocity, and a per-timestep sunlit/eclipse flag (true when the satellite is not in Earth/Moon umbra). For Moon orbits, the sun direction is computed consistently with the satellite’s orbit around the Moon.

2. Sun vector in the body frame

The sun direction is transformed from the inertial frame into the satellite body frame. The default attitude is LVLH (nadir/ram): the body axes are built from the nadir direction (toward the central body) and the velocity direction, mapped to the configured nadir and ram faces (e.g. nadir on −Y, ram on +Z).

When target pointing is configured, the body frame is overridden during the resolved pointing intervals using the Spotlight/StripScan convention — the target direction becomes the body −Y axis and the velocity vector defines the rotation about it. Pointing intervals are resolved from saved target-pointing entries that reference access computations; the power run waits for those accesses to finish before starting.

3. Power generation

For each body face and each deployable panel wing, the incident solar power is:

P_incident = S · A · cos(θ) · f_shadow

where:

• S = 1361 W/m² (solar constant, fixed)
• A = surface area (m²)
• θ = angle between the surface normal and the sun vector in the body frame
• f_shadow = illuminated fraction (0–1) from self-shadowing, or 1 when self-shadowing is off

For two-sided non-solar deployables, cos(θ) is replaced by |cos(θ)|.

The generated electrical power is:

P_gen = P_incident · packing_factor · cell_efficiency (only when sunlit and material is Solar Panel)

When the satellite is in eclipse, P_incident = 0 and therefore P_gen = 0 for every surface. The total generation is the sum over all body faces and all deployable wings.

4. Power consumption

At each timestep:

P_cons = P_base + Σ_payload P_payload

where each payload contributes its active or inactive power depending on whether the timestep satisfies its activation schedule:

• Illumination — active when the satellite’s sunlit state matches the chosen condition (sunlit or eclipse).
• Access — active when the timestep falls inside (or outside) one of the chosen access computation’s intervals.
• Deactivated — always inactive, contributes 0.

5. Battery state

The net power is:

P_net = P_gen − P_cons

The battery energy is integrated per timestep (Δt in hours):

• Charging (P_net > 0): ΔE = P_net · Δt · charge_efficiency
• Discharging (P_net < 0): ΔE = P_net · Δt / discharge_efficiency

The stored energy is then clamped to [0, C] (C = capacity). Energy that would be added above full is reported as rejected power; the model does not redirect it. Charge and discharge losses are tracked separately. The battery is flagged full at ≥99% of capacity and critical at ≤110% of the DoD floor.

6. Deployable conflict detection

After geometry is built, the computation checks for physical conflicts between deployable panels and the bus or each other (e.g. two panels that would occupy the same space). Conflicts are returned as advisory warnings — power is still computed because the geometry is well-defined, but you are alerted to fix the model.

Outputs

Plots

One plot per type, per satellite. Add and toggle visibility from the sidebar’s Plot Selection section. Each plot requires a completed power run to display data.

Plot	Unit	Shows
Power Generation	W	Total solar power generated over time (sum of all faces + wings)
Power Consumption	W	Base + payload consumption over time
Power Balance	W	Generation minus consumption; positive = surplus, negative = deficit
Battery Discharge	Wh	Stored battery energy over time, with charge/discharge cycles and rejected power
Shadow Factor	0–1	Per-face / per-wing illuminated fraction from self-shadowing

Plots are zoomable floating windows that can be pinned, expanded, and repositioned. Clicking a point syncs the 3D viewer and timeline slider to that timestamp.

Results summary card

Shown in the sidebar after a run completes:

Metric	Unit	How it’s computed
Avg Power Generation	W	Mean generation over all timesteps
Avg Power Consumption	W	Mean consumption over all timesteps
Avg Power Balance	W	Mean of generation minus consumption; red if negative
Battery Max Discharge	%	(E_max − E_min) / E_max × 100; red if it exceeds the configured DoD
Charging Status	—	Good if recent avg balance > 5 W, moderate if > 0, else critical

CSV export

The Download Output CSV button writes all time series joined on timestamp: power generation (W), consumption (W), balance (W), battery discharge (Wh), and shadow factor (fraction) per series.

3D satellite viewer

A floating, pinnable window showing the satellite 3D model with optional annotations: body axes, sun vector, and overlays from completed power/data/link computations. The viewer animates with the timeline slider so you can see the sun angle and shadowing evolve over the orbit.

Limitations & assumptions

• Solar constant is fixed at 1361 W/m². No variation over the solar cycle, no distance-to-sun correction.
• No solar-cell degradation — efficiency is constant over the mission; no radiation or end-of-life derating.
• No temperature derating — cell efficiency does not change with temperature.
• Simple energy-integrator battery — no Peukert effect, no internal resistance, no voltage curves, no self-discharge. The model is a first-order energy balance.
• Geometric self-shadowing only — body/panel occlusion. No Earth-albedo contribution, no multi-bounce reflections.
• Timestep-limited transients — power is evaluated at the propagation timestep; sub-timestep spikes (e.g. short payload bursts) are averaged out. Use a shorter interval or finer timestep for high-duty-cycle payloads.
• Default attitude is LVLH (nadir/ram). Target pointing overrides it only during resolved access intervals; outside those the satellite returns to LVLH.
• No pointing-loss model for solar — the sun vector is used directly; misalignment is captured only through the cosine term.
• Eclipses use the central-body umbra — Earth penumbra is accounted for; for Moon orbits the Moon’s shadow is used.

Worked example

A typical power trade study:

1. Design the satellite in the Model tab — assign Solar Panel material to the +Y/−Y faces, add two deployable panels on the +X face, set cell efficiency 28% and packing 60%.
2. Propagate the orbit (e.g. 550 km SSO) in the Orbit tab.
3. (Optional) Run access to a ground station if you want an access-activated payload.
4. Open the Power tab, select the satellite, and set the Power Simulation Interval to one orbit (≈95 min) for a quick sanity check.
5. Set base power to your bus load (e.g. 5 W).
6. Add payloads — e.g. an imager at 12 W active / 0.5 W standby, illumination-based, active when sunlit.
7. Set battery — e.g. 20 Wh, 30% DoD.
8. Enable self-shadowing if your panels could shade the body.
9. Run. Inspect the Power Balance plot: if it goes negative for long, the Battery Discharge plot will show how deep the discharge gets and whether it breaches DoD.
10. Iterate — widen the interval to a full day, add more panels, or trim payload duty cycle until the battery stays above the DoD floor.

Tips

• Start with a single orbit to sanity-check generation/consumption magnitudes before paying credits for a multi-day run.
• The Shadow Factor plot is the fastest way to see whether your deployables are shading each other — if a wing’s factor drops to 0 near eclipse entry, it’s being occluded.
• Access-activated payloads only appear in the schedule dropdown after an access computation completes for that satellite. Run access first.
• The summary card’s Battery Max Discharge turns red when it exceeds your DoD — that’s the single most useful pass/fail signal for a power budget.
• Keep the Power Simulation Interval inside the scenario timeline; the timeline slider constrains playback to the power range automatically.

Next steps

• Data Budget — turn access windows and payload data rates into a storage-fill forecast.
• Link Budget — compute RF link margin per pass with antenna gain models.
• Access — the access windows that drive access-activated payloads.