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.
Sensor Data
Type
Description
0x01
TeleMetrum Sensor Data
0x02
TeleMini Sensor Data
0x03
TeleNano Sensor Data
TeleMetrum, 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
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
Venus SkyTraq 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
Data Transmission
Altus Metrum devices use the Texas Instruments CC1111
microcontroller which includes an integrated sub-GHz digital
transceiver. This transceiver is used to both transmit and
receive the telemetry packets. This section discusses what
modulation scheme is used and how this device is configured.
Modulation Scheme
Texas Instruments provides a tool for computing modulation
parameters given a desired modulation format and basic bit
rate. For AltOS, the basic bit rate was specified as 38 kBaud,
resulting in the following signal parmeters:
Modulation Scheme
Parameter
Value
Description
Modulation
GFSK
Gaussian Frequency Shift Keying
Deviation
20.507812 kHz
Frequency modulation
Data rate
38.360596 kBaud
Raw bit rate
RX Filter Bandwidth
93.75 kHz
Receiver Band pass filter bandwidth
IF Frequency
140.62 kHz
Receiver intermediate frequency
Error Correction
The cc1111 provides forward error correction in hardware,
which AltOS uses to improve reception of weak signals. The
overall effect of this is to halve the available bandwidth for
data from 38 kBaud to 19 kBaud.
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.