AltOS Telemetry
Packet Definitions
Keith
Packard
2011
Keith Packard
This document is released under the terms of the
Creative Commons ShareAlike 3.0
license.
0.1
01 July 2011
Initial content
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.
Packet Formats
This section first defines the packet header common to all packets
and then the per-packet data layout.
Packet Header
Telemetry Packet Header
Offset
Data Type
Name
Description
0
uint16_t
serial
Device serial Number
2
uint16_t
tick
Device time in 100ths of a second
4
uint8_t
type
Packet type
5
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.
TeleMetrum v1.x, TeleMini and TeleNano Sensor Data
Type
Description
0x01
TeleMetrum v1.x Sensor Data
0x02
TeleMini Sensor Data
0x03
TeleNano 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
Sensor Packet Contents
Offset
Data Type
Name
Description
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
22int16_theightm
24int16_tground_presAverage barometer reading on ground
26int16_tground_accelTM
28int16_taccel_plus_gTM
30int16_taccel_minus_gTM
32
TeleMega Sensor Data
Type
Description
0x08
TeleMega IMU Sensor Data
0x09
TeleMega 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.
TeleMega IMU Sensor Packet Contents
Offset
Data Type
Name
Description
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)
32
TeleMega Kalman and Voltage Data Packet Contents
Offset
Data Type
Name
Description
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
30int16_theightm
32
TeleMetrum v2 Sensor Data
Type
Description
0x0A
TeleMetrum v2 Sensor Data
0x0B
TeleMetrum 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.
TeleMetrum v2 Sensor Packet Contents
Offset
Data Type
Name
Description
5uint8_tstateFlight state
6int16_taccelaccelerometer
8int32_tprespressure sensor (Pa * 10)
12int16_ttemptemperature sensor (°C * 100)
14int16_taccelerationm/s² * 16
16int16_tspeedm/s * 16
18int16_theightm
20int16_tv_battbattery voltage
22int16_tsense_ddrogue continuity sense
24int16_tsense_mmain continuity sense
26pad[6]pad bytes
32
TeleMetrum v2 Calibration Data Packet Contents
Offset
Data Type
Name
Description
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
32
Configuration Data
Type
Description
0x04
Configuration 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
Sensor Packet Contents
Offset
Data Type
Name
Description
5uint8_ttypeDevice type
6uint16_tflightFlight number
8uint8_tconfig_majorConfig major version
9uint8_tconfig_minorConfig minor version
10uint16_tapogee_delay
Apogee deploy delay in seconds
12uint16_tmain_deployMain deploy alt in meters
14uint16_tflight_log_max
Maximum flight log size (kB)
16charcallsign[8]Radio operator identifier
24charversion[8]Software version identifier
32
GPS Location
Type
Description
0x05
GPS 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
GPS Location Packet Contents
Offset
Data Type
Name
Description
5uint8_tflags
See GPS Flags table below
6int16_taltitudem
8int32_tlatitudedegrees * 107
12int32_tlongitudedegrees * 107
16uint8_tyear
17uint8_tmonth
18uint8_tday
19uint8_thour
20uint8_tminute
21uint8_tsecond
22uint8_tpdop* 5
23uint8_thdop* 5
24uint8_tvdop* 5
25uint8_tmode
See GPS Mode table below
26uint16_tground_speedcm/s
28int16_tclimb_ratecm/s
30uint8_tcourse/ 2
31uint8_tunused[1]
32
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.
GPS Flags
Bits
Name
Description
0-3
nsats
Number of satellites in solution
4
valid
GPS solution is valid
5
running
GPS receiver is operational
6
date_valid
Reported date is valid
7
course_valid
ground 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.
GPS Mode
Mode
Name
Decsription
N
Not Valid
All data are invalid
A
Autonomous mode
Data are derived from satellite data
D
Differential Mode
Data are augmented with differential data from a
known ground station. The SkyTraq unit in TeleMetrum
does not support this mode
E
Estimated
Data are estimated using dead reckoning from the
last known data
M
Manual
Data were entered manually
S
Simulated
GPS receiver testing mode
GPS Satellite Data
Type
Description
0x06
GPS 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.
GPS Satellite Data Contents
Offset
Data Type
Name
Description
5uint8_tchannels
Number of reported satellite information
6sat_info_tsats[12]
See Per-Satellite data table below
30uint8_tunused[2]
32
GPS Per-Satellite data (sat_info_t)
Offset
Data Type
Name
Description
0uint8_tsvid
Space Vehicle Identifier
1uint8_tc_n_1
C/N1 signal quality indicator
2
Companion Data Data
Type
Description
0x07
Companion 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.
Companion Data Contents
Offset
Data Type
Name
Description
5uint8_tboard_id
Type of companion board attached
6uint8_tupdate_period
How often telemetry is sent, in 1/100ths of a second
7uint8_tchannels
Number of data channels supplied
8uint16_t[12]companion_data
Up to 12 channels of 16-bit companion data
32
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.
Altus Metrum Radio Parts
Part Number
Description
Used in
CC111110mW transceiver with integrated SoC
TeleDongle v0.2, TeleBT v1.0, TeleMetrum v1.x, TeleMini
CC112035mW transceiver with SW FEC
TeleMetrum v2, TeleMega
CC120035mW transceiver with HW FEC
TeleDongle v3.0, TeleBT v3.0
CC115L14mW transmitter with SW FEC
TeleGPS
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:
Modulation Scheme
Rate
Deviation
Receiver Bandwidth
38.4kBaud
20.5kHz
100kHz
9.6kBaud
5.125kHz
25kHz
2.4kBaud
1.5kHz
5kHz
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.
Error Correction
Parameter
Value
Description
Error Correction
Convolutional coding
1/2 rate, constraint length m=4
Interleaving
4 x 4
Reduce effect of noise burst
Data Whitening
XOR with 9-bit PNR
Rotate right with bit 8 = bit 0 xor bit 5, initial
value 111111111
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.
Packet Format
Offset
Name
Example
Description
0
length
22
Total length of data bytes in the line. Note that
this includes the added RSSI and status bytes
1 ·· length-3
packet
4f ·· 00
Bytes of actual packet data
length-2
rssi
3f
Received signal strength. dBm = rssi / 2 - 74
length-1
lqi
a9
Link Quality Indicator and CRC status. Bit 7
is set when the CRC is correct
length
checksum
88
(0x5a + sum(bytes 1 ·· length-1)) % 256
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.