Space systems engineering: setting up a budget exam

Space Systems Engineering is the most different exam from all the others in the aerospace engineering course, and for that reason the most disorienting when it arrives. There is no single equation to apply: there is a whole satellite to size, one subsystem at a time, and every number you write must stand up against the others (if the power budget does not cover the consumption of the transponder, the link budget you calculated is useless). I work in space systems, and this is exactly the kind of reasoning I use every day: here I show you how to set up the exam, where marks are lost, and we solve together two numerical exercises — a complete power budget with eclipse and panel degradation, and a step-by-step link budget with the final margin.

What the exam really asks

The syllabus follows the life cycle of a mission: from the requirements (what the satellite must do, with what accuracy, for how long) you arrive at a mass, power and link budget for each subsystem, checking that the numbers fit the launch and mission constraints. The subsystems the exam almost always asks you to know, with their function in one sentence:

• EPS (Electrical Power System): generates, stores and distributes electrical energy — solar panels, batteries, regulators.
• ADCS (Attitude Determination and Control System): determines and controls orientation — sensors (sun sensor, star tracker) and actuators (reaction wheels, magnetorquers, thrusters).
• TT&C (Telemetry, Tracking and Command): the radio link with Earth — telemetry in downlink, commands in uplink.
• OBC (On-Board Computer): on-board processing, manages all the other subsystems.
• Thermal subsystem: keeps each component within its operating temperature range, with radiating surfaces, multilayer insulation (MLI) and sometimes active heaters.
• Structure: the mechanical frame that carries the launch loads and supports everything else.
• Propulsion: when you need to correct the orbit or de-orbit at end of life.

On this skeleton, the exam almost always builds two quantitative calculations, which are the heart of the numerical part:

Power budget. The satellite consumes energy both in eclipse (powered only by the batteries) and in sunlight (powered by the panels, which must also recharge the batteries). The energy balance over one orbit is written, for the power the panels must supply in the sunlit phase, as

where $P_e,T_e$ are power and duration in eclipse, $P_d,T_d$ power and duration in sunlight, and ${\eta }_e,{\eta }_d$ the efficiencies of the two energy paths (panel $\to$ battery $\to$ load in eclipse; panel $\to$ load directly in sunlight). The result must then be corrected for the degradation of the panels over time, because solar cells lose efficiency with exposure to radiation and thermal cycling.

Link budget. The radio link must guarantee a signal-to-noise ratio sufficient to decode the data at the required error rate. The typical calculation chain:

where $EIRP$ is the equivalent isotropic radiated power of the transmitter, $L_{tot}$ the total path losses, $G/T$ the sensitivity of the receiver, $k$ the Boltzmann constant, and $R_b$ the bit rate. The result is compared with the $E_b/N_0$ required for the design BER (bit error rate): the difference is the link margin, the number that every professor wants to see written out and commented on explicitly.

Where marks are lost

1. Forgetting the eclipse in the power budget. A budget that considers only the sunlit phase drastically overestimates the available power: in low orbit a satellite typically spends a third of the period in shadow, and in that phase the panels produce nothing.

2. Confusing conversion efficiency with design margin. ${\eta }_e$ and ${\eta }_d$ are the real physical losses of the energy path (regulators, cabling, battery charge/discharge cycle); the design margin (typically an extra 20-30%) is a separate engineering choice, to be added afterwards, not built into $\eta$.

3. Forgetting panel degradation in the area calculation. A panel sized on the power required at the beginning of life (BOL) will be insufficient at end of life (EOL): you must size the area on the EOL power required, brought back to BOL by dividing by the cumulative degradation factor.

4. Working in linear scale instead of dB in the link budget. The whole EIRP/losses/G-T chain is designed to be added in decibels: mixing linear watts with dB halfway through the chain is the most common mistake, and the quickest way to get a number with no physical sense.

5. Handing in the calculated $E_b/N_0$ without comparing it with the requirement. The number alone is worth nothing: the exam wants the margin, that is the available $E_b/N_0$ minus the $E_b/N_0$ required for the design BER, with a comment on what happens if the margin is too tight (increase the antenna gain? Reduce the bit rate? Change the coding?).

The method I use

1. Always start from the mission requirements, not from the subsystems: altitude, inclination, operational life and type of payload determine almost all the downstream numbers.
2. Keep a single balance table for each budget (power, mass, link), with a row for each contribution and the total at the bottom: it is the same format you will use in a real preliminary design, and it is what the professor expects to see on the page.
3. Always work in decibels in the link budget, from start to finish, and check the units of every term (dBW, dB, dB/K, dBHz) before adding them.
4. Always separate physical efficiency, degradation over time and design margin: they are three conceptually different corrections, even if they end up in the same final number.
5. Close every exercise with an explicit margin, positive or negative, and a comment on what you would change if it were not enough.

Two numerical exercises solved

Exercise 1 — Power budget with eclipse and panel degradation

A small satellite in low orbit has a period of 95 minutes, of which 35 minutes in eclipse and 60 in sunlight. The average consumption is $P_e=15$ W in eclipse and $P_d=20$ W in sunlight (payload more active). The efficiencies are ${\eta }_e=0.6$ (panel-battery-load path) and ${\eta }_d=0.8$ (direct panel-load path). Calculate the power required from the panels at end of life and the area needed, knowing that the cells degrade by 3.75% a year over a 5-year mission, with panels of 200 W/m² at beginning of life.

Power required from the panels (this is the requirement at end of life, after degradation):

Cumulative degradation factor over 5 years:

Power to guarantee at beginning of life in order to have $39.6$ W available at end of life:

Panel area, with specific power 200 W/m² at BOL:

A quarter of a square metre is a reasonable number for a small satellite with deployable panels: if your exercise gave an implausible area (a few square metres for a CubeSat, for example), it is the first sign that something in the balance has gone wrong — usually the forgotten eclipse or the degradation applied the wrong way round.

Exercise 2 — Downlink link budget with final margin

S-band downlink ($f=2.2$ GHz) from a satellite in LEO, slant range $d=2000$ km (worst case, low elevation). Transmitter: $P_t=2$ W, antenna gain $G_t=3$ dBi. Ground station: antenna gain $G_r=30$ dBi, system temperature $T_{sys}=300$ K. Additional losses (atmospheric, pointing, implementation) $2$ dB. Bit rate $R_b=1$ Mbps. Required: BER $10^{-5}$ with uncoded BPSK ($E_b/N_0\approx 9.6$ dB needed) plus $2$ dB of implementation margin.

EIRP:

Free-space loss (practical formula with $d$ in km and $f$ in GHz):

With the additional losses, $L_{tot}\approx 167.32$ dB.

Receiver figure of merit:

Carrier-to-noise-density ratio:

(the Boltzmann constant, $k=1.38\times 10^{-23}$ J/K, is $-228.6$ dBW/Hz/K in decibels).

Available $E_b/N_0$, subtracting the bit rate in dBHz ($10{\log }_{10}(10^6)=60$ dBHz):

Link margin:

Less than 1 dB of margin is a design at the limit: a pointing error slightly larger than expected is enough, or a day of heavy rain if there were a more absorbing atmospheric stretch, and the link no longer closes at the required BER. In an exam, the right comment at this point is to say what you would do to widen the margin: a larger ground antenna (more $G_r$), a lower data rate, or moving to channel coding (which lowers the $E_b/N_0$ required for the same BER) are the three levers the professor expects you to name.

The numbers that go into the budgets come from two other exams: the $\Delta v$ and the propellant from orbital mechanics, the pointing requirements from attitude dynamics. If the course asks you to simulate the subsystems, you also need MATLAB and Simulink. To get used to the format you will find the university exam practice tests.

How we work in lessons

With Space Systems Engineering we almost always work from a concrete case — a real satellite or an exam project from past years — and we build the budget line by line, from the mission requirement to the final number, exactly as you will have to do at the exam or, later, at work. It is the exam in which I see the sharpest jump between those who have only studied the formulas and those who have understood the systems reasoning: the second type of student solves an exercise even when the data are not in the exact form seen in lectures.

If you are also preparing Orbital Mechanics or Attitude Dynamics in the same semester, look at the page of university tutoring with all the practice tests by course, or the one on physics for the rest of the basic syllabus. And if a budget does not add up, book a free 30-minute introductory call via the contact page: send me the exercise data and we will find the point where the balance broke.