How do you translate satellite telemetry, ground-station logs and mission records without changing what happened to the spacecraft? Treat space-operations language as evidence about a specific spacecraft, subsystem, contact pass, command, telemetry stream, ground resource and timeline. Accurate satellite translation must preserve spacecraft identity, mission phase, telemetry parameter, event time, ground-station identifier, commanding status, received versus validated data, anomaly classifications and report revisions. A target statement can be fluent but technically wrong if it makes an uplinked command sound executed, confuses observed battery voltage with an engineering limit, or turns a scheduled ground contact into a completed pass.
Readers searching for satellite telemetry translation, space mission translation, ground station log translation, spacecraft operations translation, TT&C translation, mission control documentation translation, space packet terminology and satellite technical manual translation are handling a structured technical record. The Consultative Committee for Space Data Systems (CCSDS) published Cross Support Service Package Data Formats in September 2026, describing scheduled service packages for telemetry, telecommand and tracking ground or relay resources. A good translation respects those separate services and their recorded states rather than turning every communication into a generic “satellite signal.”
This guide explains how to translate spacecraft and ground-system records while preserving mission identity, technical meaning and evidence. It covers spacecraft/catalogue identifiers, telemetry packets, subsystem parameters, uplink/telecommand status, downlink, tracking, contact-pass scheduling, ground-station allocation, antennas, time systems, modes, anomalies, payload data, spacecraft software, engineering reviews, incident reports, version control and final QA. It is an educational translation guide, not flight software, a spacecraft command sequence, ground-station operating manual or mission assurance approval.
The Central Principle: Message Reception Is Not Spacecraft Action
A planned contact, successful radio link, received uplink, command acknowledgement, command execution, telemetry response and verified mission outcome are different. Translation must keep them separate. A ground system might confirm a transmitted message while mission engineers still await evidence of spacecraft action. The target should preserve who observed what, when, through which channel and with what confidence, without making communication success equal operational success.
1. Identify the Spacecraft and Mission Phase
Record mission name, spacecraft ID, programme, orbit context if relevant, source system, mission phase, source revision and intended recipient. A spacecraft can move through assembly, launch, early orbit, commissioning, normal operations, anomaly response and end-of-mission stages. The same term “active” can describe different subsystem or phase states, so translation must retain mission context.
2. Preserve Spacecraft Identifiers
Names, internal vehicle IDs, NORAD catalogue numbers, COSPAR international designators, fleet indices and payload IDs can coexist. Protect every formal code. Do not substitute a popular satellite name for a structured identifier when the source depends on the code. The existing NORAD and COSPAR identifier guide explains that identity-preservation problem in more detail.
3. Separate Spacecraft, Payload and Ground Segment
A mission consists of the spacecraft bus, payload instruments, communications interfaces, mission-control systems and ground stations or relay services. Translate the affected segment precisely. A payload observation does not automatically describe the whole vehicle, and a ground-station fault does not necessarily indicate a spacecraft fault.
4. Protect Subsystem Names and Codes
Electrical power, attitude determination and control, thermal control, command/data handling, propulsion, communications and payload systems may have approved acronyms and object IDs. Use the mission glossary. Do not expand an acronym from general aerospace vocabulary without confirming how the project defines it. One term should map to one specific system or subsystem.
5. Preserve Telemetry Versus Telecommand
Telemetry reports information from spacecraft or another monitored system. Telecommand carries instructions toward the spacecraft through a defined service. They are distinct. Translate uplink, downlink, telemetry, telecommand and tracking consistently. Do not describe a received telemetry packet as a command or an uplinked command as a measured spacecraft state.
6. Preserve TT&C Terminology
Telemetry, tracking and command (TT&C) encompasses several services. A ground-station document may describe only one of them during a contact. Translate the actual service type and allocation. Do not replace a scheduled tracking service with a confirmed telemetry download or treat availability of one service as evidence that all services functioned.
7. Distinguish Planned Pass From Completed Pass
Pass scheduled, resource allocated, contact established, data acquired, contact lost and pass closed are different states. Translate each as recorded. A schedule entry does not prove the spacecraft was visible or a link established. The source’s contact-event log provides that evidence separately.
8. Preserve Ground Station and Antenna Identity
Ground station codes, geographic sites, antenna IDs, receiver chains and relay resources are controlled identifiers. Protect them. A target log should refer to the same antenna and contact window. Do not generalise a site-specific outage to every ground station merely because they serve the same spacecraft.
9. Preserve Contact Window Times
Acquisition-of-signal predictions, loss-of-signal predictions, scheduled service windows, actual contact times and handover times can differ. Translate timestamp, time basis and whether the value is planned or observed. A predicted time should never become an actual event merely because it is listed beside a station name.
10. Preserve UTC and Mission Time References
Ground logs can use UTC, local station time, spacecraft event time, mission elapsed time or onboard clocks. Translate the time-system label but keep value and reference frame. Do not convert silently. Even one wrong timezone can distort chronology across multiple ground contacts and telemetry records.
11. Preserve Clock Correlation and Synchronisation States
Time correlation between onboard and ground clocks can be estimated, verified, unavailable or updated. Translate the stated status and uncertainty. Do not make an approximate time correlation look exact. A timestamp may be a computed conversion rather than the spacecraft’s direct source time, and that provenance should remain visible.
12. Preserve Orbit and Ephemeris Terminology
Orbit determination, predicted ephemeris, observed tracking data, state vector, orbital elements and manoeuvre plan are different products. Translate each according to mission context without calculating or modifying orbital data. A predicted position is not the same as a verified measured position. Preserve the source model and applicable epoch.
13. Protect Units and Reference Frames
Altitude, range, range rate, velocity, angle and position can use different units and coordinate frames. Translate the field while protecting number, unit and sign. Do not convert Earth-centred coordinates into latitude/longitude as part of language translation. Such changes require a separate geospatial or flight-dynamics workflow.
14. Preserve Reference Epochs
Orbital elements and predicted data often depend on an epoch or validity interval. Translate the field meaning while retaining the timestamp and time system. A dataset labelled “current” without its epoch can mislead readers. Do not make an old prediction appear applicable to later contacts.
15. Preserve Telemetry Packet Identifiers
Space packets can contain application process identifiers, sequence counters, packet type and other structured fields. Protect formal codes and values. Translate readable field descriptions, not their machine representation. A changed APID-like identifier could point to another telemetry application even if the surrounding English remains plausible.
16. Preserve Frame, Packet and File Distinctions
A received radio frame, decoded packet, assembled product and transferred file are different representations. Translate the source processing stage precisely. “Frame received” should not become “complete dataset received.” Evidence of a lower-layer communication event does not establish higher-layer data completeness.
17. Distinguish Raw, Decoded and Calibrated Telemetry
Raw counts, decoded engineering units, calibrated measurements and derived parameters can coexist. Translate the exact data state. An uncalibrated sensor count should not be labelled as final temperature or voltage unless the source reports that conversion. Processing method and version should remain attached to the data.
18. Preserve Telemetry Parameter Names
Battery voltage, bus current, component temperature, wheel speed, actuator status and payload parameters are different quantities. Use the mission termbase, including subsystem prefix and channel ID when present. Avoid replacing a formal parameter with a broad English label such as “power level” if it erases the actual measurement.
19. Preserve Engineering Units and Quantities
Volts, amperes, watts, watt-hours, newtons, degrees, radians, Kelvin and timestamps are not interchangeable. Protect SI prefixes and numerical precision. Translate power and energy separately. One target error confusing battery charge or energy with instantaneous power can change the apparent spacecraft condition.
20. Preserve Valid, Invalid and Missing Telemetry States
Telemetry values can be valid, out of range, stale, missing, estimated, substituted or affected by decoding errors. Translate the recorded data-quality flag. A missing field must not become zero, and an invalid reading must not be reported as a confirmed physical condition. The quality state belongs with the value.
21. Preserve Limit and Alarm Categories
Telemetry monitoring may use caution, warning, critical, out-of-limit and information categories. Translate each according to the mission system. A high reading is not automatically critical, and a limit exceedance does not automatically identify a failed component. Keep measured value, applicable limit, alarm severity and review status separate.
22. Preserve Onboard Mode and State Names
Spacecraft can use safe, nominal, standby, science, commissioning or mission-specific modes. Translate approved names without inventing another state hierarchy. A spacecraft in safe mode is not automatically lost or failed; a payload in standby need not mean the vehicle is inactive. Preserve the object that owns the mode.
23. Distinguish Mode Transition Requested and Confirmed
A mission operator may request a mode change, a ground system may transmit a command, and subsequent telemetry may confirm the new mode. Translate each event. A request is not the same as an actual transition. The target should not advance mission status beyond the available evidence.
24. Preserve Command Identification
Telecommand records can contain command IDs, sequence numbers, time tags, target subsystem and source authority. Protect codes and field relationships. Do not translate executable command syntax, add parameters or generate new spacecraft instructions. The goal is faithful documentation of a recorded command lifecycle, not a usable command uplink.
25. Preserve Acknowledgement Versus Execution
Received, accepted, queued, transmitted, acknowledged, executed, rejected and timed out can be separate states depending on system design. Translate the source state exactly. A ground acknowledgement may prove transport or acceptance but not physical action on the spacecraft. Verification can depend on later telemetry and mission-specific evidence.
26. Preserve Command Verification Evidence
Some mission records contain expected telemetry, confirmation criteria and observed results after a command. Translate each category distinctly. Do not make an expected result the actual observed result. If verification is pending, preserve that status even if the transmission log already shows success. The target should reflect the mission’s evidence-based command lifecycle, not an assumed outcome.
27. Preserve Command Rejection and Timeout Reasons
Telecommand systems can record malformed, rejected, not accepted, timed out, cancelled or superseded states. Translate the actual source reason and status code. Do not infer whether the problem was onboard or on the ground unless the source says so. Preserve identifiers linking rejection reports to the original command record.
28. Distinguish Ground Processing From Onboard Processing
A command can be prepared, validated and queued at mission control without ever being uplinked. Spacecraft acceptance, execution and resulting telemetry are separate events. Translate the system that performed each step. A target incident report should not label ground validation failure as an onboard spacecraft fault.
29. Preserve Uplink and Downlink Direction
Uplink usually points from ground toward space; downlink from spacecraft toward ground, within the relevant link context. Translate direction carefully. Do not swap it because a sentence describes a station “receiving” a service reservation. Data and command flow should remain traceable across logs and interfaces.
30. Preserve Signal Acquisition and Loss States
Acquisition of signal, loss of signal, scheduled link, link established and link unavailable are different. Translate planned and observed states separately. A predicted contact start is not evidence of signal acquisition, and a ground receiver outage is not necessarily proof the spacecraft transmitter stopped operating.
31. Preserve Signal Strength and Link-Quality Metrics
Received power, signal-to-noise ratio, bit error rate, frame loss and similar measures have different meanings. Translate the source metric and unit, not a generic “connection quality” label if the technical detail matters. The target should retain whether the value is observed, estimated, averaged or limited by test conditions.
32. Preserve Frequencies and Channel Names
Frequency assignments, bands, channels and modulation references may be listed in ground logs. Protect symbols, numeric values and units. Do not generate new transmission settings or operational link instructions. The translation should retain existing documented references while leaving radio configuration decisions to authorised engineers.
33. Preserve Antenna and Tracking Resource States
A ground station may report resource available, allocated, configured, tracking, idle, unavailable or under maintenance. Translate these states distinctly. An allocated antenna is not necessarily currently tracking a spacecraft. Resource state and actual link status are different layers that should not be merged.
34. Preserve Service Package and Cross-Support Meaning
CCSDS Cross Support Service Management describes packages of services and resource scheduling between providers and mission users. Translate service package, reservation, allocation, configuration and delivery status according to the source. A scheduled cross-support service does not itself demonstrate successful telemetry or telecommand activity during the pass.
35. Preserve Mission User and Provider Roles
Cross-support records can name a mission user, service provider, ground resource operator and spacecraft operator. Translate each role faithfully. Do not make the ground-station provider responsible for spacecraft mission decisions or make a receiving agency appear to own the vehicle. Contracts and service logs may distinguish operational responsibility precisely.
36. Preserve Confirmed, Tentative and Cancelled Reservations
Contact reservations can be requested, tentative, accepted, confirmed, modified, cancelled or completed. Translate each lifecycle stage. A booking confirmed by the provider is still a scheduled service, not proof of successful contact. Keep requested time, allocated resource and final pass outcome attached to separate fields.
37. Preserve Planned Versus Actual Service Duration
Mission plans can state expected contact length while station logs record actual link availability. Translate the measure and time basis. Do not treat the scheduled window as observed usable link time. Delayed acquisition or early loss of signal may reduce actual service without changing the booking record.
38. Protect Ground Station Geographic Identifiers
Ground sites, station names, coordinates, antenna IDs and relay resources are structured identifiers. Use official place names, but do not translate site codes or reproject coordinates as part of linguistic work. A station can share a city or operator with another station while having different technical resources.
39. Preserve Resource Handover and Relay Status
Some missions use direct ground passes or relay-spacecraft services. Translate the source service architecture. A relay-resource booking is not necessarily direct contact with the final ground destination. Keep each resource, scheduled package and actual delivery event distinguishable in the target records.
40. Preserve Data Receipt Versus Complete Delivery
Received frame, decoded packet, archived segment, acknowledged file and validated dataset describe different points in the flow. Translate the exact processing stage. Do not say a scientific dataset was fully delivered merely because the link carried some frames. Completeness, integrity and acceptance may be verified later by a separate workflow.
41. Preserve Missing, Duplicate and Out-of-Order Packets
Telemetry processing can report gaps, duplicates, sequence anomalies and missing segments. Translate the recorded condition without inferring data loss across an entire mission. A packet gap in one instrument stream may not affect other products. Maintain packet identifiers, time spans and affected channels for traceability.
42. Preserve Data Quality and Validity Flags
Processed mission data can carry quality flags, uncertainty, calibration state and missing-data indicators. Translate their definitions, but protect codes. A quality flag should not be described as a physical measurement, and a value marked invalid must not become a trusted engineering reading because the numeric format looks plausible.
43. Preserve Raw Data and Derived Product Distinctions
Instrument raw data, calibrated measurements, georeferenced images, scientific products and published datasets can have different processing levels. Translate source status and algorithm/version names. Do not present an initial raw downlink as a validated climate, navigation or scientific result. Derived interpretation belongs to the relevant mission science/data pipeline.
44. Preserve Payload and Platform Telemetry Separately
Payload instruments can have their own power, temperature, modes and data streams alongside the spacecraft platform. Translate which subsystem produced a reading. A science instrument in standby is not proof the entire spacecraft entered safe mode. A platform thermal warning does not necessarily invalidate every payload data product.
45. Preserve Attitude and Orientation Terminology
Attitude, pointing, orientation, roll, pitch, yaw, quaternion and reference frame can describe different aspects of spacecraft pointing. Use approved project terminology. Do not simplify all into “direction” where the record distinguishes them. Protect units and frame identifiers without attempting to calculate or correct attitude solutions.
46. Preserve Reaction-Wheel and Actuator Status
Telemetry records can list wheel speeds, actuator states and subsystem alarms. Translate the measured parameter and state as reported. Do not infer a mechanical failure from an unexpected reading without investigation evidence. A command to change a state and telemetry confirming the resulting state are separate documents.
47. Preserve Power Subsystem Measurements
Battery voltage, state of charge, bus voltage, solar-array current and power consumption have distinct meanings. Translate each measurement and unit. Do not confuse watts with watt-hours or measured voltage with a low-battery conclusion. Technical limits and actual readings should remain in separate fields.
48. Preserve Thermal and Environmental Measurements
Spacecraft sensor logs can report component temperatures, heater states, thermal limits and gradients. Translate the specific sensor and measurement condition. An indicated high temperature is not proof of a failed thermal component. Keep whether the value is raw, calibrated, warning-threshold or confirmed out-of-limit.
49. Preserve Propulsion and Manoeuvre-Record Status
Mission records can contain manoeuvre proposed, approved, commanded, observed or verified states. Translate the source lifecycle without creating manoeuvre instructions or numerical guidance. A planned orbital correction is not an executed manoeuvre, and a telemetry acknowledgement is not necessarily evidence of the intended orbital outcome.
50. Preserve Mission Mode and Safing Terminology
Safe mode, survival mode, nominal operations, payload standby and emergency procedures may be mission-specific categories. Use the controlled glossary, not colloquial words such as “offline.” A protective transition does not necessarily imply permanent spacecraft failure. Mode state should be paired with timestamps and source evidence.
51. Preserve Health Monitoring and Alarm Acknowledgement
Onboard and ground monitoring can classify alarms as active, latched, acknowledged, suppressed, cleared, under investigation or closed. Translate each state accurately. An acknowledged alarm may remain active; a cleared signal may still have an open investigation. Preserve status in both telemetry and incident management records.
52. Preserve Anomaly Event Identity
Anomaly IDs, occurrence times, affected subsystems and source reports are structured records. Protect them exactly. Do not invent a new anomaly because several alarms occurred together, and do not merge separate events into one if the mission database retains distinct IDs. The target should support later evidence and corrective-action review.
53. Separate Observation, Hypothesis and Root Cause
Mission anomalies can begin with lost packets, unusual voltage or missing acknowledgements. Engineers may investigate several possible causes. Translate “suspected,” “consistent with,” “under investigation” and “confirmed” precisely. Converting a candidate explanation into a final cause can distort both technical history and external mission reporting.
54. Preserve Severity and Mission Impact Separately
An alert may be technically high priority but have no confirmed impact on mission science or service. Conversely, a modest subsystem issue may delay an important product. Translate severity, affected function and documented mission impact separately. Do not assume that one alarm status establishes the full mission consequence.
55. Preserve Recovery, Restoration and Closure States
Telemetry can return to normal before engineers confirm stability and close the anomaly review. Translate restored communication, subsystem nominal, monitoring continued, root-cause analysis open and issue closed as distinct milestones. A successful recovery should not erase the incident investigation or prove all related data were complete.
56. Preserve Software Image and Configuration Version
Spacecraft and ground systems use versioned flight software, database tables, configurations and ground processing tools. Protect exact names, hashes and revision identifiers. A target status report should not present a future planned upload as the currently installed flight-software version or silently replace historical configuration references.
57. Preserve Change and Release-Control Status
Software or ground-operations changes can be requested, reviewed, approved, scheduled, installed, validated or rolled back. Translate each stage. A proposal may have been accepted in a change-control meeting without being applied to the spacecraft. The target should not advance the timeline by using a stronger verb.
58. Preserve Ground Test Versus Flight Event
Simulation, bench testing, hardware-in-the-loop, rehearsal and live mission operation are different contexts. Translate the environment clearly. A command exercised in a ground simulator should not be described as uplinked to the actual spacecraft. Source environment labels are crucial to avoid misleading incident, training and test reports.
59. Preserve Payload Data Rights and Release Status
Payload products may be preliminary, validated, embargoed, restricted, public or superseded. Translate status and owner accurately. A received dataset is not necessarily approved for publication, and a public data product should not be confused with unrestricted access to underlying command or engineering files.
60. Preserve Tracking and Navigation Evidence Boundaries
Ranging measurements, Doppler observations, orbit determination solutions and navigation predictions have different evidence states. Translate observed, processed, estimated and approved separately. Do not produce new orbit predictions or change reference epochs during translation. Flight-dynamics teams, not translators, own calculations and validation.
61. Preserve External Provider and Mission Agency Roles
Missions can involve launch agencies, mission operators, ground networks, science organisations and spacecraft manufacturers. Translate contractual and operational titles accurately. A ground provider confirming resource availability does not mean the mission operator approved a spacecraft action. Institutional roles should remain stable across log, contract and incident documentation.
62. Preserve Archive and Retention Identity
Telemetry archives, command histories, ground pass files and anomaly records may be versioned or subject to retention/security controls. Translate the archive label while protecting file IDs, dates and provenance. A cleaned public summary should not replace the original flight log as evidence, and a target translation should remain traceable to the retained source.
63. Build a Mission Terminology Register by Subsystem
Create entries for each spacecraft subsystem, payload, ground resource, time system, data pipeline and operational role. Record source definitions, approved target terms, acronyms, identifiers and prohibited alternatives. An acronym in telemetry processing might mean something different in spacecraft engineering. Subsystem context should travel with each reusable translation segment.
64. Protect Mission Identifiers Before Translation
Lock spacecraft code, station/antenna ID, pass number, command reference, packet ID, telemetry parameter ID, anomaly number, checksum and software version. Human-facing explanations may change language; these identifiers must not. Verify every repetition independently rather than relying on visual similarity.
65. Treat Timelines as Source Evidence
Compare UTC, onboard time, predicted contact and actual event timestamps. Preserve their stated time systems and order. Do not convert times or rearrange events during language editing. An incorrect chronology can imply a different root cause or outcome even when every isolated sentence sounds reasonable.
66. Use Three Layers to Verify Command Events
Layer one is what the ground system prepared or transmitted. Layer two is what the spacecraft or link acknowledged. Layer three is what later telemetry or mission analysis verified. Translate them separately. Success at one layer must not be described as completion of every later layer.
67. Check Telemetry Values in Context
Verify parameter name, sensor, reference frame, unit, value, timestamp, processing level and validity flag. A numerical match by itself is insufficient. Bus voltage is not automatically battery voltage; derived temperature is not raw sensor count. Preserve both data origin and processing status.
68. Compare Planned and Actual Ground Services
Review service package requested, resource allocated, scheduled window, actual signal acquisition, data receipt, processing status and final handover. A reservation does not prove successful contact. CCSDS cross-support terminology helps retain the separation between service planning and observed delivery.
69. Review Mission Anomalies as an Evidence Ladder
Keep detected event, initial report, suspected cause, tests, confirmed finding, corrective action, verification and closure as distinct stages. Do not overwrite early uncertainty with a later conclusion. Historical accuracy requires preserving what was known at the time and which decision established each subsequent state.
70. Preserve Scientific Product Provenance
Payload data can move through raw acquisition, downlink, processing, calibration, validation and public release. Translate processing level, algorithm/version, product ID and uncertainty. A received image is not automatically a validated scientific result. Each stage has its own evidence and authority.
71. Apply a Seven-Pass Mission Translation Review
Pass one: spacecraft and mission identity. Pass two: time systems and chronology. Pass three: telemetry parameters and validity. Pass four: command and acknowledgement lifecycle. Pass five: ground service and actual contact. Pass six: anomaly/software/data-product status. Pass seven: diagrams, tables, packet labels and revision history. Qualified mission specialists retain technical sign-off.
72. Review Mission Diagrams and Tables Visually
Ground-contact schedules, timelines, orbit diagrams, telemetry tables and spacecraft block diagrams depend on spatial association. Target-language expansion can move labels to the wrong antenna, subsystem or time window. Inspect rendered output, not only the translated text export.
73. Preserve Security and Distribution Restrictions
Mission logs, ground configurations, flight software and technical data can be proprietary or restricted. Translate confidentiality and distribution markings while retaining existing access controls. Do not disclose protected command strings or system identifiers to uncontrolled services for the sake of fluency.
74. Separate Public Stories From Engineering Logs
A public story may say the satellite recovered communication, while the engineering record identifies several partial recovery stages and open checks. Such a summary cannot replace the controlled log. Translate documents for their audiences without making the evidence stronger or more final than the source permits.
75. Separate Translation From Mission Control
Translators should not command spacecraft, configure ground links, change frequencies, determine orbits, modify flight software, calculate manoeuvres, diagnose faults or approve recovery. Ambiguous source terms or conflicting timestamps should go to authorised mission engineers. Translation preserves documented evidence rather than inventing spacecraft decisions.
Worked Example 1: A Scheduled Contact Without Confirmed Signal
Fictional source: “Ground Station GS-04 reserved 10:00–10:12 UTC; antenna allocated; actual signal acquisition not recorded.” The target must preserve a completed scheduling decision but absent contact evidence. “Successful 12-minute communication established” invents a mission event. The resource booking and actual link log provide different facts, even when they share the same time window.
Worked Example 2: An Acknowledged Command
Fictional source: “Command C-718 transmitted; link-level acknowledgement received; onboard execution status pending.” Translate all three states. “Spacecraft executed Command C-718” misrepresents the evidence. A later telemetry packet may or may not establish execution; the target must not assume it. The command reference should stay unchanged throughout the translation.
Worked Example 3: Telemetry Caution
Fictional source: “Power-bus voltage below caution threshold; reading valid; spacecraft remains in nominal mode; cause under review.” Preserve parameter, alert category, valid reading, mode and unresolved cause. “Satellite battery failed and entered safe mode” invents an unrelated component failure and a mode change not documented in the source.
Worked Example 4: A Missing Payload Segment
Fictional source: “Packets 120–124 missing from Payload P1 during Ground Pass G-21; platform housekeeping telemetry complete.” The target should not say the spacecraft lost all telemetry. It should preserve the missing packet range, affected payload, pass and unaffected platform stream. This distinction matters when the incident is later reconciled with archived data.
Worked Example 5: Ground Receiver Unavailable
Fictional source: “Ground Antenna GS-2 receiver chain unavailable; spacecraft state unknown during attempted contact; alternate service requested.” The target must not report a failed spacecraft transmitter. Only the ground receiver condition is documented. Unknown spacecraft state remains unknown until another source of evidence arrives, and a requested alternate service is not yet a completed contact.
Worked Example 6: A Science Image Under Review
Fictional source: “Image IMG-004 received; initial calibration applied; geolocation validation pending; public release not authorised.” Translate the source product ID and separate processing/approval states. “Validated public image” would advance the dataset beyond the recorded evidence. The correct target shows data receipt and partial processing alongside unresolved validation and release decisions.
Worked Example 7: Flight Software Versions
Fictional source: “Flight Software 3.2 installed; update to 3.3 approved for later uplink; ground simulator tests completed.” The target must not say 3.3 is currently running on the spacecraft. Approved change, completed ground testing and installed flight version are different milestones. Preserve each version string and its correct environment.
Satellite Translation Quality Matrix
| Dimension | Protected record | Common failure |
|---|---|---|
| Identity | Spacecraft, payload, station, pass IDs | Wrong vehicle or ground resource |
| Time | UTC, onboard time, epoch, duration | False event chronology |
| Communication | Scheduled, acquired, received, processed | Contact invented from booking |
| Telecommand | Queued, sent, acknowledged, executed | Acknowledgement called execution |
| Telemetry | Parameter, unit, validity, source | Wrong measured spacecraft state |
| Investigation | Observation, hypothesis, finding, closure | Suspected cause presented as confirmed |
| Data product | Raw, calibrated, validated, released | Unreleased data shown as final |
Frequently Asked Questions
What is satellite telemetry translation?
It is the controlled translation of spacecraft engineering data, subsystem-state descriptions, ground-station logs, contact schedules, mission events and related documentation while preserving identity and evidence.
Is telemetry the same as telecommand?
No. Telemetry reports information from the system; telecommand refers to instructions directed toward the spacecraft through a command service. Their structures and recorded states must remain separate.
Does a command acknowledgement prove execution?
Not necessarily. Acknowledgements can occur at different levels. The mission’s documented verification method and subsequent evidence determine which event has been confirmed.
Should NORAD and COSPAR codes be translated?
No. Preserve structured identifiers exactly. Translate only the explanatory labels or surrounding descriptions.
Is a scheduled ground contact proof that telemetry was received?
No. A reservation documents planned resource allocation. Actual link acquisition and verified data receipt are separately recorded events.
Can AI translate mission-control logs?
AI can assist terminology, code comparison and draft review in authorised secure environments. It should not send commands, change mission software, calculate manoeuvres, determine spacecraft health or assert results beyond source evidence.
Where This Guide Sits in the Translation Architecture
This guide owns the satellite telemetry and ground-operations record translation job within Master Art of Translation. It complements the existing satellite identifiers guide, technical manual translation and terminology and quality checks. The CCSDS standards publications provide current source context for cross-support service packages and telemetry/command data formats.
The Principle to Keep
A satellite translation is correct when the target preserves the same spacecraft, ground resource, contact plan, actual event, telemetry parameter, command status, software revision, anomaly and scientific-data state as the source. Translate the record of the mission, not an imagined mission. Every assertion must remain no stronger, no earlier and no broader than the documented evidence permits.