Your telemetry, your orbit and your plan, in the formats your tools already export. This page is the whole integration guide.
Bring the file your ground software already exports. Apsia finds time, voltage, current and temperature, with their units, and shows you what it found before anything runs.
Recognised as they come: Yamcs, OpenC3 COSMOS, Grafana, InfluxDB and SatNOGS exports; CSV or TSV with a decimal point or comma; Excel, Parquet, JSON, or a ZIP of any of them.
All it needs is battery voltage and current over time. Temperature and the array current make the answer better.
Minimum useful length: a few hours. Best: weeks to months, at any cadence between 1 s and 4 min. Gaps are fine and are reported. Up to 8 MB without an account, 24 MB with a workspace key; zip large files.
One row per sample, in the file your ground segment already exports. Recognised as they come: Yamcs parameter exports (qualified names, raw and monitoring columns, tab-separated), OpenC3 COSMOS Data Extractor files (full or short item headers, Matlab comment header), Grafana CSV downloads, InfluxDB annotated CSV, SatNOGS exports, and plain CSV or TSV with a decimal point or comma; also xlsx, Parquet, JSON and a zip of any of these. Column names are matched to their role, so vbatt, batt_v, /EPS/HK/BatteryVoltage and EPS HK BATT_V all work; a separate charge and discharge current, or several panel currents, are combined. Units are checked by magnitude and can be set by hand: millivolts, milliamps, kelvin. Timestamps may be ISO 8601, Unix seconds, milliseconds, microseconds or nanoseconds, Excel serial days, or seconds from an epoch you give. Before anything runs you see every column, what we think it is and why, the unit, the time base, the sign convention of the current and a 24-hour preview, and you can correct any of it. The corrected mapping is remembered for the next file with the same columns.
| Column | Required | Notes |
|---|---|---|
timestamp | yes | ISO 8601 (UTC), Unix seconds/ms/µs/ns, Excel serial days, or seconds from a stated epoch. |
battery_voltage | yes | Pack voltage, V or mV. |
battery_current | yes | A or mA, or a charge current and a discharge current as two columns. Sign convention is detected from the eclipse pattern or the voltage slope; you can also state it. |
battery_temp | optional | °C, K or m°C. Improves aging estimates a lot. |
array_current | optional | Total array current, A or mA, or one column per panel (they are summed). Enables array health and shadow detection. |
soc | optional | Onboard state-of-charge estimate, % or fraction. Used for comparison only. |
eclipse | optional | 1 in shadow, 0 in sunlight (or a sunlit flag). Pins the current sign. |
mppt_*, bus_*, *_count | optional | Power-electronics channels as your board names them: converter input voltage and current per channel (and its output voltage), regulated rail voltages and currents (3.3 V, 5 V, 12 V, distribution bus), boot / watchdog / latch-up / power-cycle counters. Recognised by name; enables the electronics check. |
Channel names that say nothing? Add your mission database beside the file: XTCE, an OpenC3 COSMOS target definition, a SCOS-2000 MIB parameter table, or a channel list with names, descriptions and units. Each column is then recognised by what your team wrote of it, in the unit declared there, with the battery current's sign and the eclipse flag's states when the database states them. It is read for that request and never kept.
The pack is learned from the file itself: its resistance and its state of charge in flight, and its real capacity when the file holds discharges deep enough to measure it (a capacity test, or discharges that start from rest). The rated capacity and the bench resistance are the starting point, not the answer. When the file carries an on-board state of charge, the pack Apsia learned is scored against it on a part of the file it did not learn from, and that error is printed next to the nominal pack's. If your charger stops short of a full charge on purpose, give its voltage a cell and the battery is judged against it.
GEO and MEO buses: send one current per solar-array string or section and the shunt regulator's current. A regulator hides the array behind the load; with them you get what each string can still give, a lost string named on its date, and the array's remaining life: the years it keeps covering the base load on the worst day of the year. Give the launch date (or the NORAD id: the year comes from its designator) and, if you are weighing one, the extension in years.
Pass telemetry works too. Give the NORAD id (or your own element-set history) and every sample is placed on its orbit: you get the battery's health trend with its range and a verdict — the trend a ground station can measure from a few samples per pass, months of passes being the only requirement. A fall or a rise is called only over a full year of passes; with less, the seasons and the first months of a mission can look like a trend, so it is shown as provisional.
The report leaves as a PDF made on the server from the same numbers you see on screen — verdict, figures with their ranges, findings with their physical reason, charts, method — with the file, its hash, the date and the engine version on the page, so what you forward is exactly what was computed.
It also says how much power the battery can give right now for as long as a load lasts, down to your bus minimum; how well today's discharges read the capacity and which discharge would read it; and it issues a battery health certificate with a number anyone can check on apsia.space/verify.
With the orbit in hand the report also looks ahead: the end-of-eclipse voltage the station will see in 7 and in 30 days, orbit by orbit, with a band checked against how the same forecast did in the past.
The forecast needs the orbit and a short description of the power system. The orbit is altitude, inclination and the node; a two-line element set; a CCSDS Orbit Mean-Elements Message (OMM, as JSON, KVN or XML, exactly as CelesTrak serves it); or a CCSDS Orbit Ephemeris Message (OEM) from your flight dynamics, in an inertial or Earth-fixed frame. An OEM centred on the Moon or another planet, or on the Sun for a cruise, is read too: the forecast then uses that body's eclipses and the spacecraft's real distance from the Sun. On a geostationary orbit the longitude is enough, and a forecast can span a whole eclipse season. Presets exist for common battery packs and platform classes; every value can be overwritten.
Checking a plan needs more than the average energy per orbit: it needs to know where the satellite is, so it can tell which task falls in sunlight and which in eclipse. A two-line element set, OMM or OEM carries that; altitude and inclination alone do not, unless you also state the time and the satellite's position along the orbit at that time.
Your ground-station pass schedule as it comes (.ics), or your plan as a CSV or JSON with a start, an end or a duration, and the activity.
CSV or JSON, one row per activity, or an iCalendar (.ics) pass schedule from your ground-station network: each event becomes an activity, passes and contacts are treated as committed downlinks, and the event summary sets the type. In CSV the first four columns and an end or a duration are required.
| Column | Notes |
|---|---|
activity_id | Your identifier for the task. |
satellite_id | Your identifier for the satellite; it must match the name given in the forecast. |
type | IMAGING, DOWNLINK, CALIBRATION, MAINTENANCE, MANEUVER, or your own. Downlinks are treated as committed: never moved or dropped. |
start_utc | ISO 8601 UTC, with end_utc or duration_s. |
power_w | Average power during the task, in watts. |
priority, value | Optional. Priority 1 is highest. Value in euros is what the task is worth; it drives cost-versus-value decisions. |
earliest_utc, latest_utc | Optional. The window inside which the optimiser may move the task. Without a window the task stays where it is. |
Give the end-of-mission date, the rule (FCC 5-year, ESA Zero Debris, 25-year, the GEO graveyard orbit or your own) and the disposal plan as a short list of activities: power, minutes, how many times, how far apart. Templates cover a drag sail, electric manoeuvres and passivation. Battery, array and orbit are taken from steps 2 and 3; safe-mode load and attitude in disposal are yours to set.
The answer is a table by year to the deadline: projected state of health with its range, effective array power, energy generated and needed per orbit in the worst eclipse, usable energy against the deepest draw, and the share of projected cases with margin. From it: the last safe start date, the passivation time, and the energy share of the disposal probability. It is printable as a “power at disposal” page, and the dossier (PDF) adds the extension you would request: the same check on the battery measured in flight and on the extended end, the date to file it, and where each requirement of ESA Zero Debris, the EU Space Act proposal and ISO 24113 is answered.
The validation figures behind every number on this site, each with its control arm and its held-out test, are in the white paper.
From your own server, the simplest way: a command run once a night sends the latest export with your workspace key, and Apsia reads it with the satellite's saved column mapping, analyses it, saves it and runs your alert rules. You open nothing and hand over no credential: only an outbound HTTPS call leaves your network. In the app, “My satellites” gives you the command ready to copy, with your satellite already in it, and shows the first arrival.
A connector reads telemetry where it already lives, so the analysis repeats itself without anyone exporting a file. Three sources today: Yamcs (the parameter archive of one instance), OpenC3 COSMOS (decommutated items over its streaming API) and Grafana (any datasource behind it, with your own query). You name the channel for each role — battery voltage, current, temperature, array or panel currents — test it, and choose a window and a cadence.
Each pull fetches the last window, runs the battery analysis with the satellite's pack and threshold, saves the summary to the satellite and raises alerts. Nothing raw is stored: the telemetry is read, analysed and dropped. Scheduled pulls are started by a scheduler you control, with your key, so Apsia never holds an open session into your ground segment. Tokens stay on the server and are never returned.
Grafana can also read Apsia: health history, forecasts and alerts arrive as rows with your workspace key, so state of health and open alerts sit on the dashboards your operators already watch. Connectors are read-only. Recommendations go back as files in your formats, through the API, or on those dashboards.
The free analysis needs no account. A workspace key adds memory: each analysis is saved to its satellite, with the column mapping and the power sheet. The fleet view lists every satellite with its latest health, fade, months to end of life, array status and open alerts; each satellite keeps a history of health with ranges, resistance and the trend across analyses.
Alerts fire when a saved analysis crosses a rule: health below the end-of-life threshold, a knee in the fade, a dead panel, a step loss of array current, a forecast that breaches the reserve, resistance growth, a rail out of regulation, a confirmed step in the power electronics, bursts of resets or latch-ups, or no analysis for N days. Rules can be fleet-wide or per satellite, with an e-mail address.
Two ways to work with others. A read-only link shares one saved analysis with a colleague or a customer: the numbers and the report, never the telemetry; it expires and can be revoked. A colleague key opens the same workspace, satellites, analyses and alerts; the owner key adds and revokes it.
The same key gives programmatic access to everything on this page — analysis, forecast, plan check and proposal, certificates, end of life and its dossier, your server's nightly export, sharing — in JSON, with CSV and JSON exports. Keys come with a pilot or subscription and can be rotated or revoked.
Enterprise customers run Apsia as a container inside their own infrastructure. It exposes the same operations on your network. Give it the orbit as element sets (TLE or OMM) and it needs no outbound connection: nothing leaves your perimeter. Updates arrive as a new container image.
Housekeeping telemetry only: voltages, currents, temperatures. Never payload data, never commands. Processing in the European Union. The free analysis keeps neither your file nor your telemetry; workspaces store summaries and reports, not raw telemetry. Full note on the security page.