X-Git-Url: https://git.gag.com/?p=fw%2Faltos;a=blobdiff_plain;f=doc%2Ftelemetry.xsl;h=e410150742b5caf9d6935e8b17de69885a3b2bfc;hp=8f0c3ff0a3081d0b60ca437385bfa5980181d11a;hb=d212d782bff977d609a9da1b805de4a2615fb474;hpb=06e82bd2c2a5eea153a053e542df9bc3537e9a01 diff --git a/doc/telemetry.xsl b/doc/telemetry.xsl index 8f0c3ff0..e4101507 100644 --- a/doc/telemetry.xsl +++ b/doc/telemetry.xsl @@ -1,5 +1,5 @@ -
@@ -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 @@ -88,14 +57,16 @@
Packet Formats - This section first defines the packet header common to all packets - and then the per-packet data layout. + + This section first defines the packet header common to all packets + and then the per-packet data layout. +
Packet Header Telemetry Packet Header - + @@ -172,10 +143,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 +186,7 @@ 16int16_tsense_mmain continuity sense (TM/Tm) - 18int16_taccelm/s² * 16 + 18int16_taccelerationm/s² * 16 20int16_tspeedm/s * 16 @@ -219,10 +195,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 +233,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 +270,15 @@ 9uint8_tconfig_minorConfig minor version - 10uint16_tmain_deployMain deploy alt in meters + 10uint16_tapogee_delay + Apogee deploy delay in seconds - 12uint32_tflight_log_maxMaximum flight log size (B) + 12uint16_tmain_deployMain deploy alt in meters + + + 14uint16_tflight_log_max + Maximum flight log size (kB) 16charcallsign[8]Radio operator identifier @@ -324,10 +313,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 +339,8 @@ - 5uint8_tflagsGPS Flags (see below) + 5uint8_tflags + See GPS Flags table below 6int16_taltitudem @@ -380,16 +379,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 - 29uint8_tunused[2] + 30uint8_tcourse/ 2 + + + 31uint8_tunused[1] 32 @@ -397,6 +400,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 +531,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 +558,254 @@ 5uint8_tchannels + Number of reported satellite information - 6uint8_tsat_0_id + 6sat_info_tsats[12] + See Per-Satellite data table below - 7uint8_tsat_0_c_n_1 + 30uint8_tunused[2] - 8uint8_tsat_1_id - - - 9uint8_tsat_1_c_n_1 - - - 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: + + + Modulation Scheme + + + + + - 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 + + +
+
+
+ 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 + + + + + - 29uint8_tsat_11_c_n_1 + Parameter + Value + Description + + - 30uin8_tunused30 + Error Correction + Convolutional coding + 1/2 rate, 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. + + + 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. + +
- - \ No newline at end of file