X-Git-Url: https://git.gag.com/?a=blobdiff_plain;f=doc%2Ftelemetry.xsl;h=fa66bff919bea61d80f9dc24c96a96fd9e7c2793;hb=3909fca0a3f918121888a415f9bf9bca99505366;hp=8f0c3ff0a3081d0b60ca437385bfa5980181d11a;hpb=06e82bd2c2a5eea153a053e542df9bc3537e9a01;p=fw%2Faltos
diff --git a/doc/telemetry.xsl b/doc/telemetry.xsl
index 8f0c3ff0..fa66bff9 100644
--- a/doc/telemetry.xsl
+++ b/doc/telemetry.xsl
@@ -31,37 +31,6 @@
-
- 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.
-
-
Packet Format Design
@@ -95,7 +64,7 @@
Telemetry Packet Header
-
+
@@ -172,10 +141,15 @@
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
-
+
@@ -210,7 +184,7 @@
16int16_tsense_mmain continuity sense (TM/Tm)
- 18int16_taccelm/s² * 16
+ 18int16_taccelerationm/s² * 16
20int16_tspeedm/s * 16
@@ -219,10 +193,10 @@
22int16_theightm
- 24int16_tground_accelTM
+ 24int16_tground_presAverage barometer reading on ground
- 26int16_tground_presAverage barometer reading on ground
+ 26int16_tground_accelTM
28int16_taccel_plus_gTM
@@ -257,10 +231,18 @@
+
+ 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
-
+
@@ -286,10 +268,15 @@
9uint8_tconfig_minorConfig minor version
- 10uint16_tmain_deployMain deploy alt in meters
+ 10uint16_tapogee_delay
+ Apogee deploy delay in seconds
+
+
+ 12uint16_tmain_deployMain deploy alt in meters
- 12uint32_tflight_log_maxMaximum flight log size (B)
+ 14uint16_tflight_log_max
+ Maximum flight log size (kB)
16charcallsign[8]Radio operator identifier
@@ -324,10 +311,19 @@
+
+ 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
-
+
@@ -341,7 +337,8 @@
- 5uint8_tflagsGPS Flags (see below)
+ 5uint8_tflags
+ See GPS Flags table below
6int16_taltitudem
@@ -380,16 +377,20 @@
24uint8_tvdop* 5
- 25uint8_tmodeN, A, D, E, M, S
+ 25uint8_tmode
+ See GPS Mode table below
26uint16_tground_speedcm/s
- 28uint8_tcourse/ 2
+ 28int16_tclimb_ratecm/s
+
+
+ 30uint8_tcourse/ 2
- 29uint8_tunused[2]
+ 31uint8_tunused[1]
32
@@ -397,6 +398,116 @@
+
+ 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
@@ -418,6 +529,15 @@
+
+ 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
@@ -436,137 +556,251 @@
5uint8_tchannels
+ Number of reported satellite information
- 6uint8_tsat_0_id
-
-
- 7uint8_tsat_0_c_n_1
-
-
- 8uint8_tsat_1_id
+ 6sat_info_tsats[12]
+ See Per-Satellite data table below
- 9uint8_tsat_1_c_n_1
+ 30uint8_tunused[2]
- 10uint8_tsat_2_id
-
-
- 11uint8_tsat_2_c_n_1
-
-
- 12uint8_tsat_3_id
-
-
- 13uint8_tsat_3_c_n_1
-
-
- 14uint8_tsat_4_id
-
-
- 15uint8_tsat_4_c_n_1
-
-
- 16uint8_tsat_5_id
-
-
- 17uint8_tsat_5_c_n_1
-
-
- 18uint8_tsat_6_id
+ 32
+
+
+
+
+ GPS Per-Satellite data (sat_info_t)
+
+
+
+
+
+
- 19uint8_tsat_6_c_n_1
+ Offset
+ Data Type
+ Name
+ Description
+
+
- 20uint8_tsat_7_id
+ 0uint8_tsvid
+ Space Vehicle Identifier
- 21uint8_tsat_7_c_n_1
+ 1uint8_tc_n_1
+ C/N1 signal quality indicator
- 22uint8_tsat_8_id
+ 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:
+
+
+
+
+
+
+
- 23uint8_tsat_8_c_n_1
+ Parameter
+ Value
+ Description
+
+
- 24uint8_tsat_9_id
+ Modulation
+ GFSK
+ Gaussian Frequency Shift Keying
- 25uint8_tsat_9_c_n_1
+ Deviation
+ 20.507812 kHz
+ Frequency modulation
- 26uint8_tsat_10_id
+ Data rate
+ 38.360596 kBaud
+ Raw bit rate
- 27uint8_tsat_10_c_n_1
+ RX Filter Bandwidth
+ 93.75 kHz
+ Receiver Band pass filter bandwidth
- 28uint8_tsat_11_id
+ IF Frequency
+ 140.62 kHz
+ Receiver intermediate frequency
+
+
+
+
+
+
+ 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
+
+
+
+
+
+
- 29uint8_tsat_11_c_n_1
+ Parameter
+ Value
+ Description
+
+
- 30uin8_tunused30
+ Error Correction
+ Convolutional coding FEC
+ 1/2 code, constraint length m=4
- 31uin8_tunused31
+ Interleaving
+ 4 x 4
+ Reduce effect of noise burst
- 32
+ 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.
+
+
+
+
+
+
+
+
+
+ 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.
+
+
-
-
\ No newline at end of file