AltOS Telemetry

X-Git-Url: https://git.gag.com/?a=blobdiff_plain;f=AltOS%2Fdoc%2Ftelemetry.html;h=185642e8842f7674364e5a2f1082156087c34c34;hb=47038a0ffc6e5211517885d091a392f77818c51a;hp=dc7c6069c4ff47a5cd5bca8e749ae3090c9ab57a;hpb=77f6661cd893dadf422376a7302be97105f4a9a8;p=web%2Faltusmetrum diff --git a/AltOS/doc/telemetry.html b/AltOS/doc/telemetry.html index dc7c606..185642e 100644 --- a/AltOS/doc/telemetry.html +++ b/AltOS/doc/telemetry.html @@ -1,136 +1,1600 @@ -AltOS Telemetry

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.1	01 July 2011
Initial content

Table of Contents

1. Packet Format Design

2. Packet Formats

2.1. Packet Header
2.2. Sensor Data
2.3. Configuration Data
2.4. GPS Location
2.5. GPS Satellite 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

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. -

2.2. 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 -

Table 2. Sensor Packet Contents

Offset	Data Type	Name	Description
5	uint8_t	state	Flight state
6	int16_t	accel	accelerometer (TM only)
8	int16_t	pres	pressure sensor
10	int16_t	temp	temperature sensor
12	int16_t	v_batt	battery voltage
14	int16_t	sense_d	drogue continuity sense (TM/Tm)
16	int16_t	sense_m	main continuity sense (TM/Tm)
18	int16_t	acceleration	m/s² * 16
20	int16_t	speed	m/s * 16
22	int16_t	height	m
24	int16_t	ground_pres	Average barometer reading on ground
26	int16_t	ground_accel	TM
28	int16_t	accel_plus_g	TM
30	int16_t	accel_minus_g	TM
32

2.3. 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 -

Table 3. Sensor Packet Contents

Offset	Data Type	Name	Description
5	uint8_t	type	Device type
6	uint16_t	flight	Flight number
8	uint8_t	config_major	Config major version
9	uint8_t	config_minor	Config minor version
10	uint16_t	apogee_delay	Apogee deploy delay in seconds
12	uint16_t	main_deploy	Main deploy alt in meters
14	uint16_t	flight_log_max	Maximum flight log size (kB)
16	char	callsign[8]	Radio operator identifier
24	char	version[8]	Software version identifier
32

2.4. 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 -

Table 4. GPS Location Packet Contents

Offset	Data Type	Name	Description
5	uint8_t	flags	See GPS Flags table below
6	int16_t	altitude	m
8	int32_t	latitude	degrees * 10⁷
12	int32_t	longitude	degrees * 10⁷
16	uint8_t	year
17	uint8_t	month
18	uint8_t	day
19	uint8_t	hour
20	uint8_t	minute
21	uint8_t	second
22	uint8_t	pdop	* 5
23	uint8_t	hdop	* 5
24	uint8_t	vdop	* 5
25	uint8_t	mode	See GPS Mode table below
26	uint16_t	ground_speed	cm/s
28	int16_t	climb_rate	cm/s
30	uint8_t	course	/ 2
31	uint8_t	unused[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. -

Table 5. 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. -

Table 6. 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

2.5. 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. -

Table 7. GPS Satellite Data Contents

Offset	Data Type	Name	Description
5	uint8_t	channels	Number of reported satellite information
6	sat_info_t	sats[12]	See Per-Satellite data table below
30	uint8_t	unused[2]
32

Table 8. GPS Per-Satellite data (sat_info_t)

Offset	Data Type	Name	Description
0	uint8_t	svid	Space Vehicle Identifier
1	uint8_t	c_n_1	C/N1 signal quality indicator
2

3. 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. -

3.1. 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: -

Table 9.

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

3.2. 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. -

Table 10.

Parameter	Value	Description
Error Correction	Convolutional coding FEC	1/2 code, 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

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 11.

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

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. -

+ + + + + + + + + +AltOS Telemetry + + + + +

License

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

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
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

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 v1.0 and TeleNano Sensor Data

+ + ++++ + + + + + + + + + + + + + + + + + + +

Table 2. Sensor Packet Type
Type	Description
0x01	TeleMetrum v1.x Sensor Data
0x02	TeleMini v1.0 Sensor Data
0x03	TeleNano Sensor Data

TeleMetrum v1.x, TeleMini v1.0 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 3. Sensor Packet Contents
Offset	Data Type	Name	Description
5	uint8_t	state	Flight state
6	int16_t	accel	accelerometer (TM only)
8	int16_t	pres	pressure sensor
10	int16_t	temp	temperature sensor
12	int16_t	v_batt	battery voltage
14	int16_t	sense_d	drogue continuity sense (TM/Tm)
16	int16_t	sense_m	main continuity sense (TM/Tm)
18	int16_t	acceleration	m/sÂ² * 16
20	int16_t	speed	m/s * 16
22	int16_t	height	m
24	int16_t	ground_pres	Average barometer reading on ground
26	int16_t	ground_accel	TM
28	int16_t	accel_plus_g	TM
30	int16_t	accel_minus_g	TM

2.3. TeleMega Sensor Data

+ + ++++ + + + + + + + + + + + + + + +

Table 4. TeleMega Packet Type
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.

+ + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 5. TeleMega IMU Sensor Packet Contents
Offset	Data Type	Name	Description
5	uint8_t	orient	Angle from vertical in degrees
6	int16_t	accel	High G accelerometer
8	int32_t	pres	pressure (Pa * 10)
12	int16_t	temp	temperature (Â°C * 100)
14	int16_t	accel_x	X axis acceleration (across)
16	int16_t	accel_y	Y axis acceleration (along)
18	int16_t	accel_z	Z axis acceleration (through)
20	int16_t	gyro_x	X axis rotation (across)
22	int16_t	gyro_y	Y axis rotation (along)
24	int16_t	gyro_z	Z axis rotation (through)
26	int16_t	mag_x	X field strength (across)
28	int16_t	mag_y	Y field strength (along)
30	int16_t	mag_z	Z field strength (through)

+ + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 6. TeleMega Kalman and Voltage Data Packet Contents
Offset	Data Type	Name	Description
5	uint8_t	state	Flight state
6	int16_t	v_batt	battery voltage
8	int16_t	v_pyro	pyro battery voltage
10	int8_t[6]	sense	pyro continuity sense
16	int32_t	ground_pres	Average barometer reading on ground
20	int16_t	ground_accel	Average accelerometer reading on ground
22	int16_t	accel_plus_g	Accel calibration at +1g
24	int16_t	accel_minus_g	Accel calibration at -1g
26	int16_t	acceleration	m/sÂ² * 16
28	int16_t	speed	m/s * 16
30	int16_t	height	m

2.4. TeleMetrum v2 and newer Sensor Data

+ + ++++ + + + + + + + + + + + + + + +

Table 7. TeleMetrum v2 Packet Type
Type	Description
0x0A	TeleMetrum v2 Sensor Data
0x0B	TeleMetrum v2 Calibration Data

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

TeleMetrum v2 and newer 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 and newer Calibration Data packets are always transmitted once per second.

+ + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 8. TeleMetrum v2 and newer Sensor Packet Contents
Offset	Data Type	Name	Description
5	uint8_t	state	Flight state
6	int16_t	accel	accelerometer
8	int32_t	pres	pressure sensor (Pa * 10)
12	int16_t	temp	temperature sensor (Â°C * 100)
14	int16_t	acceleration	m/sÂ² * 16
16	int16_t	speed	m/s * 16
18	int16_t	height	m
20	int16_t	v_batt	battery voltage
22	int16_t	sense_d	drogue continuity sense
24	int16_t	sense_m	main continuity sense
26	pad[6]	pad bytes

+ + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 9. TeleMetrum v2 and newer Calibration Data Packet Contents
Offset	Data Type	Name	Description
5	pad[3]	pad bytes
8	int32_t	ground_pres	Average barometer reading on ground
12	int16_t	ground_accel	Average accelerometer reading on ground
14	int16_t	accel_plus_g	Accel calibration at +1g
16	int16_t	accel_minus_g	Accel calibration at -1g
18	pad[14]	pad bytes

2.5. TeleMini v3.0 Sensor Data

+ + ++++ + + + + + + + + + + +

Table 10. Sensor Packet Type
Type	Description
0x11	TeleMini v3.0 Sensor Data

TeleMini v3.0 uses this +packet format for sensor data.

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 11. Sensor Packet Contents
Offset	Data Type	Name	Description
5	uint8_t	state	Flight state
6	int16_t	v_batt	battery voltage
8	int16_t	sense_a	apogee continuity sense
10	int16_t	sense_m	main continuity sense
12	int32_t	pres	pressure sensor (Pa * 10)
16	int16_t	temp	temperature sensor (Â°C * 100)
18	int16_t	acceleration	m/sÂ² * 16
20	int16_t	speed	m/s * 16
22	int16_t	height	m
24	int16_t	ground_pres	Average barometer reading on ground
28	pad[4]	pad bytes

2.6. Configuration Data

+ + ++++ + + + + + + + + + + +

Table 12. Configuration Packet Type
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

+ + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 13. Configuration Packet Contents
Offset	Data Type	Name	Description
5	uint8_t	type	Device type
6	uint16_t	flight	Flight number
8	uint8_t	config_major	Config major version
9	uint8_t	config_minor	Config minor version
10	uint16_t	apogee_delay	Apogee deploy delay in seconds
12	uint16_t	main_deploy	Main deploy alt in meters
14	uint16_t	flight_log_max	Maximum flight log size (kB)
16	char	callsign[8]	Radio operator identifier
24	char	version[8]	Software version identifier

2.7. GPS Location

+ + ++++ + + + + + + + + + + +

Table 14. GPS Packet Type
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

+ + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 15. GPS Location Packet Contents
Offset	Data Type	Name	Description
5	uint8_t	flags	See GPS Flags table below
6	int16_t	altitude	m
8	int32_t	latitude	degrees * 107
12	int32_t	longitude	degrees * 107
16	uint8_t	year
17	uint8_t	month
18	uint8_t	day
19	uint8_t	hour
20	uint8_t	minute
21	uint8_t	second
22	uint8_t	pdop	* 5
23	uint8_t	hdop	* 5
24	uint8_t	vdop	* 5
25	uint8_t	mode	See GPS Mode table below
26	uint16_t	ground_speed	cm/s
28	int16_t	climb_rate	cm/s
30	uint8_t	course	/ 2
31	uint8_t	unused[1]

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 16. 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.

+ + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 17. GPS Mode
Mode	Name	Description
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

2.8. GPS Satellite Data

+ + ++++ + + + + + + + + + + +

Table 18. GPS Satellite Data Packet Type
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.

+ + ++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +

Table 19. GPS Satellite Data Contents
Offset	Data Type	Name	Description
5	uint8_t	channels	Number of reported satellite information
6	sat_info_t	sats[12]	See Per-Satellite data table below
30	uint8_t	unused[2]

+ + ++++++ + + + + + + + + + + + + + + + + + + + + +

Table 20. GPS Per-Satellite data (sat_info_t)
Offset	Data Type	Name	Description
0	uint8_t	svid	Space Vehicle Identifier
1	uint8_t	c_n_1	C/N1 signal quality indicator

2.9. Companion Data

+ + ++++ + + + + + + + + + + +

Table 21. Companion Data Packet Type
Type	Description
0x07	Companion 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 22. Companion Data Contents
Offset	Data Type	Name	Description
5	uint8_t	board_id	Type of companion board attached
6	uint8_t	update_period	How often telemetry is sent, in 1/100ths of a second
7	uint8_t	channels	Number of data channels supplied
8	uint16_t[12]	companion_data	Up 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 23. Altus Metrum Radio Parts
Part Number	Description	Used in
CC1111	10mW transceiver with integrated SoC	TeleDongle v0.2, TeleBT v1.0, TeleMetrum v1.x, TeleMini v1
CC1120	35mW transceiver with SW FEC	TeleMetrum v2, TeleMega v1
CC1200	35mW transceiver with HW FEC	TeleMetrum v3, TeleMega v2, TeleDongle v3.0, TeleMini v3, TeleBT v3.0, TeleGPS v2
CC115L	14mW transmitter with SW FEC	TeleGPS v1

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 24. Modulation Scheme
Rate	Deviation	Receiver Bandwidth
38.4kBaud	20.5kHz	100kHz
9.6kBaud	5.125kHz	25kHz
2.4kBaud	1.5kHz	5kHz

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 25. 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

4. TeleDongle serial 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 26. TeleDongle serial 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

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.

+ + + \ No newline at end of file