Your Satellite's Battery Is the Scheduler's Problem
Two papers this month make the same point from different directions: in-orbit compute is paid for in battery cycles, and the schedule decides how many.
Two papers landed on arXiv this month that we have been passing around the team.
The first, with the title “Renewables Power the Orbit?”, starts from an observation that anyone who has run a power budget for a small satellite will recognise: the more computation you do on board, the faster the battery wears out. The authors propose pushing work down to ground data centers sited next to renewable generation, with an offloading scheme that accounts for the fact that the satellite can only talk to the ground during contact windows and that electricity budgets on the ground change by the hour.
The second is a broad survey called “Energy-Aware Computing in the Year 2026”. Most of it is about terrestrial systems. There is a section on low Earth orbit, and the sentence that stuck with us is that schedulers in this setting have to adapt to intermittent solar and radio availability. Which is a polite way of saying that in orbit, energy is a schedule, not a supply.
We agree with both papers. We also think they understate how much of this is a planning problem rather than an infrastructure one.
The physics is simple and unforgiving
A satellite in low Earth orbit goes around the planet roughly every 90 to 95 minutes. For a large fraction of each orbit, often around a third, it is in the Earth’s shadow. No sun means no solar power, and everything that runs during that interval runs on the battery.
That is fine for the bus. Satellites have always done it. The avionics draw a few tens of watts and the battery is sized for that, with margin, over a design life of thousands of cycles.
Compute changes the arithmetic. A capable edge processor can draw more than the rest of the spacecraft put together. Run it through eclipse and you are pulling the battery down much further on every cycle than the bus alone would. Battery cycle life is strongly dependent on depth of discharge. A pack cycled to a shallow depth lasts many times longer than the same pack cycled deep. A low Earth orbit satellite sees about fifteen eclipses a day, so a habit of computing through the dark is a habit you repeat something like five thousand times a year.
This is what the first paper measures, and it is why they reach for offloading. If the satellite does less, the battery lasts longer.
One orbit. Running the bus alone through eclipse takes the battery down a little. Running compute as well takes it down a lot, fifteen times a day. The bottom row is the alternative: put the work where the sun is.
The other answer: place work in time
Offloading is one answer. Scheduling is the other, and they are not in competition.
If the eclipse is predictable, and it is, to the second, from the published orbital elements, then compute does not have to run through it. It can run in the sunlit part of the orbit, where the arrays carry the load and the battery is charging rather than draining. The eclipse becomes an interval the planner avoids rather than an event the battery absorbs.
This is the thing we have found ourselves saying in every conversation about orbital compute this year. The constraints are not surprises. They are a schedule. Power follows illumination, contact follows geometry, both are computable ahead of time from the same two lines of orbital elements everyone already has. A planner that treats them as inputs produces a plan that simply does not ask the battery to do the hard thing.
Concretely, when you ask our planner for a plan, the response includes the eclipse fraction for the satellite’s current orbit and the windows the planner used. Each step of the workload sits in a window where the power it needs is actually available. If a step cannot be placed anywhere without running on battery beyond what the budget allows, the plan says so. That is a deliberate refusal, not an oversight. We would rather return no plan than a plan that quietly spends battery life the operator did not agree to.
Why this matters more than it looks
The reason we keep coming back to this is that battery life is the consumable in an orbital compute node. The chip can be radiation tolerant, the radiator can be sized for the worst case, but the battery is a chemical system with a finite number of deep cycles in it, and every one you spend on compute in the dark is one you cannot get back. For a satellite with a five year design life, the schedule you run in year one decides whether you get year five.
The first paper is right that offloading to the ground is sometimes the correct call. The survey is right that schedulers have to live with intermittent energy. We would add one thing. If the energy is intermittent on a known schedule, then the scheduler’s job is to use the schedule, and the battery should be the last thing it reaches for rather than the first.