AltOS Telemetry

Packet Definitions

Keith Packard

This document is released under the terms of the Creative Commons ShareAlike 3.0 license.

Revision History
Revision 0.101 July 2011
Initial content

Table of Contents

1. Packet Format Design
2. Packet Formats
2.1. Packet Header
2.2. TeleMetrum v1.x, TeleMini and TeleNano Sensor Data
2.3. TeleMega Sensor Data
2.4. TeleMetrum v2 Sensor Data
2.5. Configuration Data
2.6. GPS Location
2.7. GPS Satellite Data
2.8. Companion Data Data
3. Data Transmission
3.1. Modulation Scheme
3.2. Error Correction
4. TeleDongle packet format
5. History and Motivation

1. Packet Format Design

AltOS telemetry data is split into multiple different packets, all the same size, but each includs an identifier so that the ground station can distinguish among different types. A single flight board will transmit multiple packet types, each type on a different schedule. The ground software need look for only a single packet size, and then decode the information within the packet and merge data from multiple packets to construct the full flight computer state.

Each AltOS packet is 32 bytes long. This size was chosen based on the known telemetry data requirements. The power of two size allows them to be stored easily in flash memory without having them split across blocks or leaving gaps at the end.

All packet types start with a five byte header which encodes the device serial number, device clock value and the packet type. The remaining 27 bytes encode type-specific data.

2. Packet Formats

This section first defines the packet header common to all packets and then the per-packet data layout.

2.1. Packet Header

Table 1. Telemetry Packet Header

OffsetData TypeNameDescription
0uint16_tserialDevice serial Number
2uint16_ttickDevice time in 100ths of a second
4uint8_ttypePacket type

Each packet starts with these five bytes which serve to identify which device has transmitted the packet, when it was transmitted and what the rest of the packet contains.

2.2. TeleMetrum v1.x, TeleMini and TeleNano Sensor Data

0x01TeleMetrum v1.x Sensor Data
0x02TeleMini Sensor Data
0x03TeleNano Sensor Data

TeleMetrum v1.x, TeleMini and TeleNano share this same packet format for sensor data. Each uses a distinct packet type so that the receiver knows which data values are valid and which are undefined.

Sensor Data packets are transmitted once per second on the ground, 10 times per second during ascent and once per second during descent and landing

Table 2. Sensor Packet Contents

OffsetData TypeNameDescription
5uint8_tstateFlight state
6int16_taccelaccelerometer (TM only)
8int16_tprespressure sensor
10int16_ttemptemperature sensor
12int16_tv_battbattery voltage
14int16_tsense_ddrogue continuity sense (TM/Tm)
16int16_tsense_mmain continuity sense (TM/Tm)
18int16_taccelerationm/s² * 16
20int16_tspeedm/s * 16
24int16_tground_presAverage barometer reading on ground

2.3. TeleMega Sensor Data

0x08TeleMega IMU Sensor Data
0x09TeleMega Kalman and Voltage Data

TeleMega has a lot of sensors, and so it splits the sensor data into two packets. The raw IMU data are sent more often; the voltage values don't change very fast, and the Kalman values can be reconstructed from the IMU data.

IMU Sensor Data packets are transmitted once per second on the ground, 10 times per second during ascent and once per second during descent and landing

Kalman and Voltage Data packets are transmitted once per second on the ground, 5 times per second during ascent and once per second during descent and landing

The high-g accelerometer is reported separately from the data for the 9-axis IMU (accel/gyro/mag). The 9-axis IMU is mounted so that the X axis is "across" the board (along the short axis0, the Y axis is "along" the board (along the long axis, with the high-g accelerometer) and the Z axis is "through" the board (perpendicular to the board). Rotation measurements are around the respective axis, so Y rotation measures the spin rate of the rocket while X and Z rotation measure the tilt rate.

The overall tilt angle of the rocket is computed by first measuring the orientation of the rocket on the pad using the 3 axis accelerometer, and then integrating the overall tilt rate from the 3 axis gyroscope to compute the total orientation change of the airframe since liftoff.

Table 3. TeleMega IMU Sensor Packet Contents

OffsetData TypeNameDescription
5uint8_torientAngle from vertical in degrees
6int16_taccelHigh G accelerometer
8int32_tprespressure (Pa * 10)
12int16_ttemptemperature (°C * 100)
14int16_taccel_xX axis acceleration (across)
16int16_taccel_yY axis acceleration (along)
18int16_taccel_zZ axis acceleration (through)
20int16_tgyro_xX axis rotation (across)
22int16_tgyro_yY axis rotation (along)
24int16_tgyro_zZ axis rotation (through)
26int16_tmag_xX field strength (across)
28int16_tmag_yY field strength (along)
30int16_tmag_zZ field strength (through)

Table 4. TeleMega Kalman and Voltage Data Packet Contents

OffsetData TypeNameDescription
5uint8_tstateFlight state
6int16_tv_battbattery voltage
8int16_tv_pyropyro battery voltage
10int8_t[6]sensepyro continuity sense
16int32_tground_presAverage barometer reading on ground
20int16_tground_accelAverage accelerometer reading on ground
22int16_taccel_plus_gAccel calibration at +1g
24int16_taccel_minus_gAccel calibration at -1g
26int16_taccelerationm/s² * 16
28int16_tspeedm/s * 16

2.4. TeleMetrum v2 Sensor Data

0x0ATeleMetrum v2 Sensor Data
0x0BTeleMetrum v2 Calibration Data

TeleMetrum v2 has higher resolution barometric data than TeleMetrum v1, and so the constant calibration data is split out into a separate packet.

TeleMetrum v2 Sensor Data packets are transmitted once per second on the ground, 10 times per second during ascent and once per second during descent and landing

TeleMetrum v2 Calibration Data packets are always transmitted once per second.

Table 5. TeleMetrum v2 Sensor Packet Contents

OffsetData TypeNameDescription
5uint8_tstateFlight state
8int32_tprespressure sensor (Pa * 10)
12int16_ttemptemperature sensor (°C * 100)
14int16_taccelerationm/s² * 16
16int16_tspeedm/s * 16
20int16_tv_battbattery voltage
22int16_tsense_ddrogue continuity sense
24int16_tsense_mmain continuity sense
26pad[6]pad bytes 

Table 6. TeleMetrum v2 Calibration Data Packet Contents

OffsetData TypeNameDescription
5pad[3]pad bytes 
8int32_tground_presAverage barometer reading on ground
12int16_tground_accelAverage accelerometer reading on ground
14int16_taccel_plus_gAccel calibration at +1g
16int16_taccel_minus_gAccel calibration at -1g
18pad[14]pad bytes 

2.5. Configuration Data

0x04Configuration Data

This provides a description of the software installed on the flight computer as well as any user-specified configuration data.

Configuration data packets are transmitted once per second during all phases of the flight

Table 7. Sensor Packet Contents

OffsetData TypeNameDescription
5uint8_ttypeDevice type
6uint16_tflightFlight number
8uint8_tconfig_majorConfig major version
9uint8_tconfig_minorConfig minor version
10uint16_tapogee_delayApogee deploy delay in seconds
12uint16_tmain_deployMain deploy alt in meters
14uint16_tflight_log_maxMaximum flight log size (kB)
16charcallsign[8]Radio operator identifier
24charversion[8]Software version identifier

2.6. GPS Location

0x05GPS Location

This packet provides all of the information available from the GPS receiver—position, time, speed and precision estimates.

GPS Location packets are transmitted once per second during all phases of the flight

Table 8. GPS Location Packet Contents

OffsetData TypeNameDescription
5uint8_tflagsSee GPS Flags table below
8int32_tlatitudedegrees * 107
12int32_tlongitudedegrees * 107
22uint8_tpdop* 5
23uint8_thdop* 5
24uint8_tvdop* 5
25uint8_tmodeSee GPS Mode table below
30uint8_tcourse/ 2

Packed into a one byte field are status flags and the count of satellites used to compute the position fix. Note that this number may be lower than the number of satellites being tracked; the receiver will not use information from satellites with weak signals or which are close enough to the horizon to have significantly degraded position accuracy.

Table 9. GPS Flags

0-3nsatsNumber of satellites in solution
4validGPS solution is valid
5runningGPS receiver is operational
6date_validReported date is valid
7course_validground speed, course and climb rates are valid

Here are all of the valid GPS operational modes. Altus Metrum products will only ever report 'N' (not valid), 'A' (Autonomous) modes or 'E' (Estimated). The remaining modes are either testing modes or require additional data.

Table 10. GPS Mode

NNot ValidAll data are invalid
AAutonomous modeData are derived from satellite data
DDifferential Mode Data are augmented with differential data from a known ground station. The SkyTraq unit in TeleMetrum does not support this mode
EEstimated Data are estimated using dead reckoning from the last known data
MManualData were entered manually
SSimulatedGPS receiver testing mode

2.7. GPS Satellite Data

0x06GPS Satellite Data

This packet provides space vehicle identifiers and signal quality information in the form of a C/N1 number for up to 12 satellites. The order of the svids is not specified.

GPS Satellite data are transmitted once per second during all phases of the flight.

Table 11. GPS Satellite Data Contents

OffsetData TypeNameDescription
5uint8_tchannelsNumber of reported satellite information
6sat_info_tsats[12]See Per-Satellite data table below

Table 12. GPS Per-Satellite data (sat_info_t)

OffsetData TypeNameDescription
0uint8_tsvidSpace Vehicle Identifier
1uint8_tc_n_1C/N1 signal quality indicator

2.8. Companion Data Data

0x07Companion Data Data

When a companion board is attached to TeleMega or TeleMetrum, it can provide telemetry data to be included in the downlink. The companion board can provide up to 12 16-bit data values.

The companion board itself specifies the transmission rate. On the ground and during descent, that rate is limited to one packet per second. During ascent, that rate is limited to 10 packets per second.

Table 13. Companion Data Contents

OffsetData TypeNameDescription
5uint8_tboard_idType of companion board attached
6uint8_tupdate_periodHow often telemetry is sent, in 1/100ths of a second
7uint8_tchannelsNumber of data channels supplied
8uint16_t[12]companion_dataUp to 12 channels of 16-bit companion data

3. Data Transmission

Altus Metrum devices use Texas Instruments sub-GHz digital radio products. Ground stations use parts with HW FEC while some flight computers perform FEC in software. TeleGPS is transmit-only.

Table 14. Altus Metrum Radio Parts

Part NumberDescriptionUsed in
CC111110mW transceiver with integrated SoCTeleDongle v0.2, TeleBT v1.0, TeleMetrum v1.x, TeleMini
CC112035mW transceiver with SW FECTeleMetrum v2, TeleMega
CC120035mW transceiver with HW FECTeleDongle v3.0, TeleBT v3.0
CC115L14mW transmitter with SW FECTeleGPS

3.1. Modulation Scheme

Texas Instruments provides a tool for computing modulation parameters given a desired modulation format and basic bit rate. While we might like to use something with better low-signal performance like BPSK, the radios we use don't support that, but do support Gaussian frequency shift keying (GFSK). Regular frequency shift keying (FSK) encodes the signal by switching the carrier between two frequencies. The Gaussian version is essentially the same, but the shift between frequencies gently follows a gaussian curve, rather than switching immediately. This tames the bandwidth of the signal without affecting the ability to transmit data. For AltOS, there are three available bit rates, 38.4kBaud, 9.6kBaud and 2.4kBaud resulting in the following signal parmeters:

Table 15. Modulation Scheme

RateDeviationReceiver Bandwidth

3.2. Error Correction

The cc1111 and cc1200 provide forward error correction in hardware; on the cc1120 and cc115l that's done in software. AltOS uses this to improve reception of weak signals. As it's a rate 1/2 encoding, each bit of data takes two bits when transmitted, so the effective data rate is half of the raw transmitted bit rate.

Table 16. Error Correction

Error CorrectionConvolutional coding1/2 rate, constraint length m=4
Interleaving4 x 4Reduce effect of noise burst
Data WhiteningXOR with 9-bit PNRRotate right with bit 8 = bit 0 xor bit 5, initial value 111111111

4. TeleDongle packet format

TeleDongle does not do any interpretation of the packet data, instead it is configured to receive packets of a specified length (32 bytes in this case). For each received packet, TeleDongle produces a single line of text. This line starts with the string "TELEM " and is followed by a list of hexadecimal encoded bytes.

TELEM 224f01080b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000003fa988

The hexadecimal encoded string of bytes contains a length byte, the packet data, two bytes added by the cc1111 radio receiver hardware and finally a checksum so that the host software can validate that the line was transmitted without any errors.

Table 17. Packet Format

0length22Total length of data bytes in the line. Note that this includes the added RSSI and status bytes
1 ·· length-3packet4f ·· 00Bytes of actual packet data
length-2rssi3fReceived signal strength. dBm = rssi / 2 - 74
length-1lqia9Link Quality Indicator and CRC status. Bit 7 is set when the CRC is correct
lengthchecksum88(0x5a + sum(bytes 1 ·· length-1)) % 256

5. History and Motivation

The original AltoOS telemetry mechanism encoded everything available piece of information on the TeleMetrum hardware into a single unified packet. Initially, the packets contained very little data—some raw sensor readings along with the current GPS coordinates when a GPS receiver was connected. Over time, the amount of data grew to include sensor calibration data, GPS satellite information and a host of internal state information designed to help diagnose flight failures in case of a loss of the on-board flight data.

Because every packet contained all of the data, packets were huge—95 bytes long. Much of the information was also specific to the TeleMetrum hardware. With the introduction of the TeleMini flight computer, most of the data contained in the telemetry packets was unavailable. Initially, a shorter, but still comprehensive packet was implemented. This required that the ground station be pre-configured as to which kind of packet to expect.

The development of several companion boards also made the shortcomings evident—each companion board would want to include telemetry data in the radio link; with the original design, the packet would have to hold the new data as well, requiring additional TeleMetrum and ground station changes.