

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Comprenda los datos de telemetría
<a name="telemetry.understanding-data"></a>

 Los datos de telemetría se envían como registros JSON codificados en Base64 a su transmisión de Kinesis Data Streams. Cada registro contiene información recopilada durante el contacto con el satélite, incluidos los metadatos sobre el contacto y las mediciones telemétricas muestreadas. 

## Información general sobre el formato de datos
<a name="telemetry.understanding-data.format"></a>

 Cada registro de telemetría contiene los siguientes componentes: 

Tipo y versión de telemetría  
 Identifica el tipo específico de datos de telemetría y su versión de esquema. Esto le permite analizar diferentes tipos de telemetría de forma adecuada. Para obtener más información sobre el control de versiones de esquemas, consulte. [Evolución y control de versiones del esquema](#telemetry.understanding-data.schema-evolution) 

ID de ámbito  
 Un identificador único para el alcance de la telemetría. Esto le permite correlacionar los datos de telemetría con contactos específicos. 

Metadatos  
 Información contextual sobre la telemetría. 

Datos  
 Las medidas de telemetría muestreadas específicas del tipo de telemetría. 

 **Clave de partición** 

 Los registros de telemetría se envían a la transmisión de Kinesis Data Streams con una clave de partición en el formato: 

```
SCOPE#{{scopeId}}#TELEMETRY_ID#{{telemetryId}}#TELEMETRY_VERSION#{{telemetryVersion}}
```

 Esta clave de partición garantiza que toda la telemetría de un tipo determinado para un solo contacto se entregue a la misma partición dentro de la transmisión de Kinesis Data Streams, lo que permite ordenar al máximo la transmisión de telemetría de ese contacto. 

## Telemetría de puntería
<a name="telemetry.understanding-data.pointing"></a>

 La telemetría de puntería proporciona información sobre la dirección de apuntamiento de la antena durante los contactos con el satélite. Este tipo de telemetría siempre se envía durante un contacto. 

 **Campos de datos** 

Ejemplo de marca de tiempo  
 Hora en que se muestrearon los datos de telemetría, en formato ISO-8601 en UTC con una precisión de milisegundos. 

azimut  
 Ángulo acimutal real de la antena en grados. 

elevación  
 Ángulo de elevación real de la antena en grados. 

Comandó Azimuth  
 Ángulo acimutal controlado en grados. Este es el ángulo acimutal objetivo que la antena intenta alcanzar. 

Elevación ordenada  
 Ángulo de elevación controlado en grados. Este es el ángulo de elevación objetivo que la antena intenta alcanzar. 

**nota**  
 La posición real de la antena puede diferir de la posición ordenada debido a limitaciones físicas o retrasos mecánicos durante el contacto. 

 **Campos de metadatos** 

Estación terrestre  
 Nombre de la estación terrestre (por ejemplo, «Ohio 1"). 

ID del satélite  
 Identificador del recurso satelital en. AWS Ground Station

contactId  
 Identificador del contacto. 

 **Ejemplo: JSON** 

```
{
  "telemetryTypeAndVersion": "POINTING#1.0.0",
  "telemetryType": "POINTING",
  "telemetryVersion": "1.0.0",
  "scopeId": "12345678-1234-1234-1234-123456789012",
  "metadata": {
    "groundStation": "Ohio 1",
    "satelliteId": "87654321-4321-4321-4321-210987654321",
    "contactId": "12345678-1234-1234-1234-123456789012"
  },
  "data": {
    "sampleTimestamp": "2025-12-08T12:00:00.123Z",
    "azimuth": 180.5,
    "elevation": 45.2,
    "commandedAzimuth": 180.0,
    "commandedElevation": 45.0
  }
}
```

## Telemetría de seguimiento
<a name="telemetry.understanding-data.tracking"></a>

 La telemetría de seguimiento proporciona información sobre el estado del seguimiento de la antena y los errores de seguimiento. Este tipo de telemetría se envía cuando el seguimiento automático está activado en la configuración de seguimiento y cuando la antena utiliza activamente el seguimiento automático. 

**nota**  
 Si tu `autotrack` parámetro TrackingConfig está establecido en, no se proporcionará ninguna `REMOVED` telemetría de rastreo. Para obtener más información sobre el seguimiento de las configuraciones, consulte. [Configuración de seguimiento](how-it-works.config.md#how-it-works.config-tracking) 

 **Campos de datos** 

Ejemplo de marca de tiempo  
 Hora en que se muestrearon los datos de telemetría, en formato ISO-8601 en UTC con una precisión de milisegundos. 

Estado de seguimiento  
 Estado de seguimiento actual de la antena. Los valores posibles son los que se indican a continuación.   
+  `TRACKING`— La antena ha captado correctamente una señal que coincide con el perfil de la misión y la sigue activamente por el cielo. Este es el estado operativo nominal durante un contacto. 
+  `ACQUIRING`— La antena está en proceso de localizar y bloquear la señal. Actualmente, el sistema utiliza el seguimiento programático, que apunta en función de los datos de las efemérides. 
+  `MASKED`— La posición prevista del satélite está detrás de una máscara de seguimiento automático, lo que significa que la antena no puede utilizar el seguimiento automático de forma fiable en esa dirección de apuntamiento específica. Esto suele ocurrir en áreas de alta interferencia de RF, como elevaciones bajas. 

trackingErrorAzimuth  
 Error de seguimiento en el eje acimutal, medido en grados. 

trackingErrorElevation  
 Error de rastreo en el eje de elevación, medido en grados. 

**nota**  
 Los valores de error de seguimiento representan ajustes del seguimiento del programa basado en efemérides que AWS Ground Station se aplica durante el seguimiento automático para maximizar la intensidad de la señal. 

 **Campos de metadatos** 

 La telemetría de seguimiento incluye los mismos campos de metadatos que la telemetría de puntería:`groundStation`, y. `satelliteId` `contactId` 

 **Ejemplo: JSON** 

```
{
  "telemetryTypeAndVersion": "TRACKING#1.0.0",
  "telemetryType": "TRACKING",
  "telemetryVersion": "1.0.0",
  "scopeId": "12345678-1234-1234-1234-123456789012",
  "metadata": {
    "groundStation": "Ohio 1",
    "satelliteId": "87654321-4321-4321-4321-210987654321",
    "contactId": "12345678-1234-1234-1234-123456789012"
  },
  "data": {
    "sampleTimestamp": "2025-12-08T12:00:00.123Z",
    "trackingStatus": "TRACKING",
    "trackingErrorAzimuth": 0.2,
    "trackingErrorElevation": 0.1
  }
}
```

## Lectura de datos de la transmisión de Kinesis Data Streams
<a name="telemetry.understanding-data.reading"></a>

 Los datos de telemetría se envían a la transmisión de Kinesis Data Streams y se pueden consumir mediante patrones de consumo de transmisión estándar. Al leer los datos de la transmisión, tenga en cuenta las siguientes consideraciones. 

 **Decodificación en Base64** 

 Los datos de la transmisión de Kinesis Data Streams están codificados en Base64. Debe decodificar los datos antes de analizarlos como JSON. Para obtener más información, consulte [Trabajar con Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/working-with-streams.html). 

 **Uso del visor de datos de Kinesis** 

 Para acceder rápidamente a los datos de telemetría, la consola de streaming de Kinesis Data Streams ofrece una función de visor de datos. Al utilizar esta función: 
+  La transmisión por telemetría se puede realizar en cualquier fragmento de la transmisión. 
+  La posición inicial predeterminada se basa en los registros más recientes del fragmento. 
+  Es posible que tenga que ajustar el fragmento seleccionado y utilizar la posición inicial «En la marca de tiempo» para ver los registros recibidos. 

 **Uso de la biblioteca de clientes de Kinesis** 

 La biblioteca de clientes de Kinesis (KCL) gestiona muchas de las complejidades asociadas al consumo de datos de la transmisión de Kinesis Data Streams, incluida la administración de fragmentos, los puntos de control y el equilibrio de carga. Recomendamos utilizar KCL para las aplicaciones de consumo de telemetría de producción. 

 Para obtener más información, consulte [Desarrollo de consumidores mediante la biblioteca de clientes de Kinesis](https://docs.aws.amazon.com/streams/latest/dev/kcl.html). 

 **Mejores prácticas de consumo** 
+  **Minimice la latencia**: utilice un ventilador de salida mejorado para leer la transmisión de Kinesis Data Streams con un rendimiento dedicado y una latencia más baja en comparación con el sondeo. Para obtener más información, consulte Cómo [desarrollar consumidores con canales de distribución ampliados mejorados](https://docs.aws.amazon.com/streams/latest/dev/enhanced-consumers.html). 
+  **Transmisión dedicada**: utilice una transmisión dedicada de Kinesis Data Streams para la integración de AWS Ground Station telemetría. Compartir una transmisión con otras aplicaciones puede provocar una saturación del rendimiento de escritura y fallos en la entrega de la telemetría. 
+  **Capacidad bajo demanda**: Implemente su transmisión de Kinesis Data Streams en el modo de aprovisionamiento bajo demanda para permitir el escalado automático de los fragmentos en función del rendimiento. 
+  **Supervise el rendimiento**: supervise su transmisión para detectar posibles limitaciones mediante métricas. CloudWatch Para obtener más información, consulte [Supervisión de Amazon Kinesis Data Streams](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html). 

## Evolución y control de versiones del esquema
<a name="telemetry.understanding-data.schema-evolution"></a>

 Los esquemas de telemetría están versionados para adaptarse a la evolución a lo largo del tiempo. El `telemetryVersion` campo de cada registro indica la versión del esquema. 

 **Gestionar los cambios de esquema** 
+  Es posible que en el futuro se introduzcan nuevos tipos de telemetría. 
+  Es posible que los tipos de telemetría existentes reciban nuevas versiones con cambios importantes. 
+  Sus aplicaciones deben tolerar tipos y versiones de telemetría desconocidos. 
+  Analice los `telemetryVersion` campos `telemetryTypeAndVersion``telemetryType`, y para determinar cómo procesar cada registro. 

 Recomendamos implementar una serialización de cargas útil que tenga en cuenta las versiones y que permita gestionar varias versiones del esquema sin problemas, lo que permitirá que las aplicaciones sigan funcionando cuando se introduzcan nuevas versiones. 