Getting started

TART turns a raw telemetry export into an understanding of how your spacecraft behaved. It analyses files you upload. It never commands, never schedules, and never connects to a spacecraft.

You need three things. Only the first is mandatory to see something useful.

Start with the file. Add the other two when you want more.

Step 1 — Import your telemetry file

Upload the export exactly as your ground segment produced it. Do not clean it first: the gaps, duplicates and out-of-order rows are information about your ground station, and TART counts every one rather than quietly discarding it.

One hard requirement: every reading needs a timestamp. TART is built around time, and a file without it cannot be analysed. If your export carries only sample indices, it will not work here.

Three timestamps, not one. TART distinguishes:

• receipt — when the ground station received it
• onboard — when the spacecraft's own clock recorded it
• measure — when the measurement was actually taken

These are rarely the same. A reading buffered before downlink arrives labelled later than the moment it describes. TART never assumes they agree, and every analysis declares which axis it read. If your file only has receipt time — most do — TART says so on every result rather than letting you forget.

What you get immediately

The overview appears the moment the import finishes, before you configure anything:

• How many samples, over how many days, in how many contacts
• Every parameter name, how much data each carries, and what type it looks like
• Which days delivered nothing at all
• Everything the reader excluded, and why

Nothing here is guessed. If TART has not been told what a parameter means, it says so instead of inventing a unit.

Step 2 — The dictionary

This is the part that makes TART yours. It is a spreadsheet with one row per parameter, keyed by the parameter name exactly as it appears in your file.

There is no alias list and no hidden mapping table. The dictionary is the mapping, and you own it.

Get a draft, do not start blank

TART reads your file and writes a draft dictionary with one row per parameter, ordered by how much data each carries. name and data_type are already filled in from observation. Everything else is yours.

Fill in the top rows first — in most exports a small number of parameters account for nearly all the data.

The columns

Required

Optional, and each one buys something

Conditional

Three kinds of boundary, and they are not interchangeable

This is the single most misunderstood part, and getting it wrong makes TART lie to you.

valid_min / valid_max — physically impossible. A reading outside these is corrupt. TART excludes it from every average and counts it. Use these for sentinel values and sensor faults: a battery reporting 65535 mV is not a high reading, it is 0xFFFF meaning "no data".

nominal — normal operation. Drawn as a band behind the data. Outside it is interesting, not wrong.

alarm — genuinely bad, but a real reading. The value happened. It is included in every calculation and flagged.

A corrupt reading is excluded. A bad reading is kept and reported. Confusing the two either hides real faults or poisons your averages with sentinels.

Where your limits came from matters

limit_source is required whenever you fill in a limit, because TART renders them differently.

A limit marked observed — derived from watching the data — is drawn dashed and labelled provisional, never as a red alarm line. The widest value you have seen is not the widest value possible, and a month of observation during an unusual period would otherwise bless abnormal behaviour as normal.

Limits from a datasheet or a specification are drawn as real limits.

TART will never fill these in for you from observed data. That is deliberate.

`standard_id` — what unlocks the prebuilt analyses

TART ships analyses that work on any spacecraft. They can, because they never name your parameters — they name a standard id, and you say once which of your parameters that is.

your name                        standard_id
Pcu.Battery1.VTotalPcuSide   ->  BAT1_VOLTAGE

Pick from the dropdown in the template. Filling it in is optional: a parameter without one still ingests, still plots, and can still drive an analysis you write yourself. It simply does not unlock the prebuilt ones.

The mapping view shows how far you have got, which analyses are ready, and which single parameter would unlock the most if you mapped it next. It also suggests candidates from your own file — as suggestions only. TART never writes a mapping. Where several parameters match equally well, it says so and chooses none, because a wrong mapping is worse than no mapping.

Status values

For enum parameters, use the second sheet to say what each value means, and which values are valid. A value your dictionary does not declare is treated as corrupt, not as an unknown state.

Step 3 — Satellite configuration

Supply orbital elements (a TLE file) and TART computes its own reference:

• Ground track, altitude, latitude and longitude
• Sun vector
• Eclipse entry and exit, with both cylindrical and conical shadow models

This is what separates TART from a plotting tool. It does not read your spacecraft's reported position and believe it — it works out where the spacecraft actually was and compares.

Two things to know.

Accuracy is bounded by the elements, not by the code. A TLE gives roughly a kilometre of error at its epoch, growing one to three kilometres per day. Every result records how stale the element set was, so you can judge a disagreement rather than guess at it.

Eclipse and display sampling are separate concerns. The penumbra on a low orbit lasts under ten seconds. If you sample eclipse state on a one-minute grid you will step straight over it. TART detects transitions on its own fine grid, independent of how you choose to plot.

Running analyses

Choose analyses from the catalog and run them. Each is a declarative spec, not code, which is why adding one is a configuration change.

Every analysis is one of five archetypes:

An analysis whose inputs are not in your file is reported as not applicable — not as a failure, and not silently dropped. Nothing is broken; that analysis simply describes telemetry your spacecraft does not send.

Reading a result

Every result carries four things.

Findings — statements in plain language, at three levels: info, notable, concern. A plot without a statement is a plotting tool.

Counts — every sample that went in, was used, was excluded and why. These always reconcile. If 8,000 samples went in and 7,200 were used, the result tells you where the other 800 went.

Caveats — anything about the data itself that bears on this analysis. The receipt-time limitation, corrupt readings, coverage gaps. Attached automatically to any analysis that read an affected parameter, at the top where they cannot be missed.

Provenance — dataset identity and checksum, adapter version, dictionary source, spec version, physical core version, and the element-set epoch distance where a reference was used. Enough to reproduce the number exactly, or to explain why a rerun differs.

Data quality

TART assesses your data before running any analysis, and only for parameters you have described — a row with a name and nothing else supplies no standard to judge by.

Per parameter: sample count, corrupt readings, unreadable values, type consistency, distinct values, cadence, and either gaps or coverage.

The distinction matters. TART reports a gap only against a sampling_interval_s you declared. Without one it reports coverage — contacts, longest silence, covered fraction — and states that the gap count is not assessable. Measuring gaps against an inferred cadence would report every contact boundary as a fault, which is noise dressed as diagnosis.

Custom analysis

Pick parameters, plot them, choose the axes. X defaults to time but does not have to be.

A custom analysis is a spec through the same engines as everything else — not a second code path — so it carries the same counts, caveats and provenance as a prebuilt one.

Export

Any result exports as a self-contained HTML file: no network, no external assets, opens anywhere. Provenance travels with it, so a report forwarded to a colleague still says exactly what produced it.

What TART will not do

Worth knowing up front, because each is deliberate.

• It will not guess a parameter name. A name that does not match your dictionary character for character is reported as unmapped, never matched to something similar.
• It will not invent limits. Not from observed range, not from a similar parameter, not from a datasheet it has not been shown.
• It will not silently drop data. Every exclusion, coercion, deduplication and interpolation is counted and reported. Missing data is information about your spacecraft.
• It will not present a guess as a measurement. Where several answers fit equally well, it shows them all and chooses none.
• It will not command your spacecraft. TART analyses files. It has no path to a vehicle.