urn:nasa:pds:mess_mla_raw:data_edr:mlasta0809270801_dat 1.0 1.10.1.0 Product_Observational 2018-06-08 1.0 PDS4 migrated product. 2008-09-27T08:01:54Z 2008-09-27T08:51:54Z MESSENGER Mission urn:nasa:pds:context:investigation:mission.messenger data_to_investigation MESSENGER Spacecraft urn:nasa:pds:context:instrument_host:spacecraft.mess is_instrument_host Mercury Laser Altimeter Instrument urn:nasa:pds:context:instrument:mla.mess is_instrument Mercury Planet urn:nasa:pds:context:target:planet.mercury data_to_target Mercury 2 Flyby 1/130989958 1/130992958 mlastatus pipe-mla2edr 1.0 mlasta0809270801.dat 2008-09-28T10:21:24Z 0 6 This table contains one set of instrument engineering data as reported by the MESSENGER Mercury Laser Altimeter (MLA) status packets. Additional details are contained in the EDR SIS document. 91 0 102 met 1 1 UnsignedMSB4 4 Mission elapsed time in seconds. rmu_data_size 2 5 UnsignedByte 1 RMU supports two interfaces in reading the RMU shot data after every RUPT: byte mode and nibble mode. Nibble mode not supported by flight software, therefore this telemetry point should always read 0 (byte mode). rmu_test_pattern 3 6 UnsignedByte 1 Test pattern used to fill RMU shot data. 0,6,7: real data, 1: LFSR, 2: 0xAA, 3: 0x55, 4: Counter, 5: ~Counter. rmu_data_type 4 7 UnsignedByte 1 Identifies shot data as real or test data. =0 real data, =1 test data. rmu_rate_select 5 8 UnsignedByte 1 RMU Rate selected. =0, 1Hz, =1 6Hz, =2 8Hz, =3, 10Hz canned_data 6 9 UnsignedByte 1 Designates whether flight software is using collection of RMU shot data or fake data as input to the science algorithms. =0 Real Data, =1 Fake Data spare 7 10 UnsignedByte 1 Spare column. rmu_1pps_sync 8 11 UnsignedByte 1 RMU synchronized with 1PPS flag. =0, not synchronized, =1 synchronized rmu_transfer_mode 9 12 UnsignedByte 1 Data Transfer mode commanded to RMU. Does not reflect the state of the RMU but rather the state of the software and how the software is reading the RMU. It is possible after an RMU reset to have this telemetry point not coincide with RMU_DATA_SIZE. =0 byte mode, =1 low nibble, =2 high nibble detector_ch3 10 13 UnsignedByte 1 Status of detector channel 3. =0 enabled, =1 disabled detector_ch2 11 14 UnsignedByte 1 Status of detector channel 2. =0 enabled, =1 disabled detector_ch1lo 12 15 UnsignedByte 1 Status of detector channel 1 low. =0 enabled, =1 disabled detector_ch1hi 13 16 UnsignedByte 1 Status of detector channel 1 high. =0 enabled,=1 disabled dump_active 14 17 UnsignedByte 1 Designates whether software is performing a memory dump. =0 not performing memory dump =1 currently performing memory dump rmu_clock_select 15 18 UnsignedByte 1 Clock configuration for the RMU. This drives the entire operation of the RMU. RMU has 4 different 5MHz clocks available to it, two internal to the RMU board and two external from the spacecraft. =0 Oscillator A, =1 Internal 40%, =2 Internal 50%, =3 Oscillator B rmu_cycle_reset_tof 16 19 UnsignedByte 1 RMU uses TOF chips to measure in fine detail the return pulses coming back from a laser fire. The chips are prone to lockup if flooded with input. If the flight software detects that they are locked up, it will automatically configure the RMU to reset the TOF chips for one shot. Unfortunately the rate at which this telemetry point is monitored means that it is very unlikely that this event will ever be reflected in this telemetry point. =0 TOF chips are not reset after each shot. =1 TOF chips are reset after each shot. rmu_cal_select 17 20 UnsignedByte 1 Indicates which calibration setting was applied to the RMU during ground testing, if enabled: 00=0ns, 01=200ns, 10=400ns, 11=200ns rmu_cal_enable 18 21 UnsignedByte 1 Indicates whether RMU will output a fixed test pattern during ground testing as selected by RMU_CAL_SELECT: 00,01,10=Real Data from instrument, 11=TOF-A calibration data ovr_threshold_ch3 19 22 UnsignedByte 1 Indicates whether the science task has overridden (via command) the channel 3 threshold value written as a DAC to the hardware. =0 not overridden, =1 overridden ovr_threshold_ch2 20 23 UnsignedByte 1 Indicates whether the science task has overridden (via command) the channel 2 threshold value written as a DAC to the hardware. =0 not overridden, =1 overridden ovr_threshold_ch1lo 21 24 UnsignedByte 1 Indicates whether the science task has overridden (via command) the channel 1 low threshold value written as a DAC to the hardware. =0 not overridden, =1 overridden ovr_threshold_ch1hi 22 25 UnsignedByte 1 Indicates whether the science task has overridden (via command) the channel 1 high threshold value written as a DAC to the hardware. =0 not overridden, =1 overridden. ovr_chan_disables 23 26 UnsignedByte 1 Indicates whether channel disables mask used by science algorithms has been overridden. This mask is used to enable and disable the return channels (1hi, 1low, 2, 3). =0 not overridden, =1 overridden. ovr_gain 24 27 UnsignedByte 1 Indicates whether the science task has overridden (via command) the gain value written as a DAC to the hardware. =0 not overridden, =1 overridden. ovr_range_window 25 28 UnsignedByte 1 Indicates whether the science task has overridden (via command) the range window value used to write the RMU range gate start and stop. =0 not overridden, =1 overridden. ovr_range_delay 26 29 UnsignedByte 1 Indicates whether the science task has overridden (via command) the range delay value used to write the RMU range gate start and stop. =0 not overridden, =1 overridden. v2dot5_mon 27 30 UnsignedByte 1 The ADC of the +2.5 volt monitor. v5_mon 28 31 UnsignedByte 1 The ADC of the +5 volt monitor. v5neg_mon 29 32 UnsignedByte 1 The ADC of the -5 volt monitor. v12_mon 30 33 UnsignedByte 1 The ADC of the +12 volt monitor. v32dot5_mon 31 34 UnsignedByte 1 The ADC of the +32.5 volt monitor. v550_mon 32 35 UnsignedByte 1 The ADC of the +550 volt monitor. laser_tx_threshold 33 36 UnsignedByte 1 The ADC of the laser Tx threshold which is commanded by the science task automatically every shot, via a DAC write, using a table value. aem_latchup_ctr 34 37 UnsignedByte 1 Count of the number of times the flight software responds to an AEM latch-up. It is important to note that this counter does not reflect the number of AEM latch-ups, but rather the number of times the software responds to a latch-up. Because the AEM is not able to remove the latch-up condition fast enough, the software will attempt to acknoweldge the same latch-up multiple times. Because of this, the software limits the number of latch-up acknowledgements a second to 2. In practice, for every AEM latch-up this counter will increment by two. detector_board_temp 35 38 UnsignedByte 1 The ADC of the detector board temperature. altimeter_det_temp 36 39 UnsignedByte 1 The ADC of the altimeter detector temperature. analog_board_temp 37 40 UnsignedByte 1 The ADC of the analog board temperature. rmu_board_temp 38 41 UnsignedByte 1 The ADC of the RMU board temperature. xtal_oscillator_temp 39 42 UnsignedByte 1 The ADC of the crystal oscillator temperature. cpu_board_temp 40 43 UnsignedByte 1 The ADC of the CPU board temperature. laser_elec_temp 41 44 UnsignedByte 1 The ADC of the laser electronics temperature. laser_amp_temp 42 45 UnsignedByte 1 The ADC of the laser amplifier temperature. laser_oscillator_temp 43 46 UnsignedByte 1 The ADC of the laser oscillator temperature. pca_temp 44 47 UnsignedByte 1 The ADC of the PCA temperature. beam_xpand_top_temp 45 48 UnsignedByte 1 The ADC of the beam expander top temperature. beam_xpand_base_temp 46 49 UnsignedByte 1 The ADC of the beam expander base temperature. rx_tubelens_top_temp 47 50 UnsignedByte 1 The ADC of the receiver tube lens temperature. mla_housing_temp 48 51 UnsignedByte 1 The ADC of the MLA housing temperature. cal_lo_temp 49 52 UnsignedByte 1 The ADC of the low calibration temperature. cal_hi_temp 50 53 UnsignedByte 1 The ADC of the high calibration temperature. telemetry_volume 51 54 UnsignedMSB2 2 Telemetry volume counter. Increments by 1 for every 1KB of data output by the telemetry framer task since the last software boot. checksum_enabled 52 56 UnsignedMSB2 2 An integer representation of the 16-bit mask that shows which tables in memory are being checksummed. Each bit in the mask corresponds to the table ID of the same number (bit 4 in the mask corresponds to table 4). Convert back to binary notation before evaluating the checksum enabled mask: =0 table is not being checksummed, =1 table is being checksummed. checksum_status 53 58 UnsignedMSB2 2 An integer representation of the 16-bit mask that shows whether the checksum of a table in memory is correct or incorrect. Each bit in the mask corresponds to the table ID of the same number (bit 4 in the mask corresponds to table 4). Convert back to binary notation before evaluating the checksum status mask: =0 Checksum is correct, =1 checksum is incorrect. tof_lockup_cntr 54 60 UnsignedByte 1 There are 6 TOF chips in the RMU. The RMU uses them to time stamp the Tx pulse, the high return, and the low returns. Every 16 shots the software analyzes the state of the TOFs. If during the past 16 shots the fine time (least significant 10 bits) on a RMU time stamp has not changed at all, and the coarse time has changed at least once, then a TOF lockup is detected and this telemetry point is incremented, and for the next shot, the TOF chips are configured to be reset. The software will immediately begin monitoring for the next 16 shots. The software only monitors the TOF lockups in Standby and Science modes. telem_rate_config 55 61 UnsignedByte 1 Indicates whether the TELEMETRY_VOLUME counter is derived from the FSW or from a test source: 0=Oper, 1=Test. sdhwdiag_liteswitch 56 62 UnsignedByte 1 =0 The MLA_HWDiagLite packet is off. =1 The MLA_HwDiagLite packet is on. si_timing_valid 57 63 UnsignedByte 1 Check of timing integrity at rate of once per second. Three checks are performed: 1. Has MET message from S/C been received 2. Has the 1PPS signal from the S/C been received 3. Is the phase lock to the 1PPS off by more than 5 us If any of the checks fail then the timing integrity is in question. =0 Timing integrity fine, =1 Timing integrity under question. checksum_en_flag 58 64 UnsignedByte 1 =0 checksumming of tables is disabled. =1 checksumming of tables is enabled. one_pps_occurred 59 65 UnsignedByte 1 Each second the spacecraft sends a 1PPS signal to the MLA instrument. The flight software uses this signal to synchronize. =0 1PPS did not occur, =1 1PPS occured. sdhwdiag_fullswitch 60 66 UnsignedByte 1 =0 MLA_Hw Diagnostic packet is off. =1 MLA_Hw Diagnostic packet is on. os_eprom_version 61 67 UnsignedByte 1 There are two banks of EEPROM that the software is stored in. When the instrument is turned on, or any time the CPU board is rebooted, the code stored in EEPROM is copied out of one of the two banks, into RAM and executed there. This telemetry point says which bank of EEPROM the code was copied out of. =0 EEPROM Bank 0 - Non Write-Protected; =1 EEPROM Bank 1 - Write-Protected. sidirect_thres_ovr 62 68 UnsignedByte 1 The science task allows the thresholds applied to each of the channels to be overridden. The science algorithms specify that the value commanded for them to be overridden with must be scaled by a function of the gain, and range window. For testing purposes, it was necessary to have the ability to directly apply the threshold given in the threshold override command. =0 thresholds are scaled as prescribed in science algorithm. =1 thresholds are directly applied. idle_checkin 63 69 UnsignedByte 1 By default, the flight software requires certain critical tasks to 'check in' in order for the watchdog to be kicked. In diagnosing a problem it might be necessary to disable that behavior. =0 critical tasks do NOT have to check in. =1 critical tasks DO have to check in. idle_met_checkin 64 70 UnsignedByte 1 By default, the software checks that the MET is being received while in Science mode. If the MET is missing for a preset amount of time, then the software will execute the Mla_Safe script that will transition the software to Keep Alive mode. This telemetry point reflects whether or not the software is actively checking if the MET is being received. =0 MET not being checked. =1 MET being checked. sisc_time_bias 65 71 UnsignedMSB2 2 The difference between the s/c ranging data alignment to the value of the MET, used in Science algorithm mode 1. Value is a B8 fraction. sisc_range_bias 66 73 UnsignedMSB2 2 The difference between the s/c ranging data alignment to the range value, used in Science algorithm mode 1 to account for orbital error and other biases. Value is a signed integer number of counts. si_transmit_threshold 67 75 UnsignedMSB2 2 The transmit start detector threshold value (currently defaults to 15 counts). sd_aem_error_count 68 77 UnsignedMSB2 2 Once a second, the flight software performs a series of ADCs on the temperatures and voltages. After every RUPT, the flight software performs a series of ADCs on all the items that can be written to via a DAC. If any ADC fails, due to a time out (the software pends on the AEM asserting that it is finished the ADC), then this counter is incremented. si_rmu_error_count 69 79 UnsignedMSB2 2 Every shot when the software is in Science mode, the science task writes the values of the range gates (start and stop). At that time it also reads the values back and compares them to the values it wrote. If those two values do not agree then the science task increments this counter. cmd_accept_ctr 70 81 UnsignedByte 1 Counter increments every time a command is sent and the software executes that command to completion without any errors. cmd_opcode 71 82 UnsignedByte 1 The opcode of the last command that was processed. cmd_resultcode 72 83 UnsignedByte 1 The error code generated by the last command executed. If the last command executed did not generate an error, then this value is zero. alarm_id 73 84 UnsignedByte 1 The ID of the last alarm issued by the flight software. alarm_count 74 85 UnsignedByte 1 Counter is incremented every time an alarm is issued by the flight software. The flight software treats the reset message as an alarm, therefore value is one at boot up. However the actual integer range of values will be from 129 to 255 because the most significant bit of the telemetry point is used as a flag that is always set to 1. cmd_reject_count 75 86 UnsignedByte 1 Counter increments every time the flight software fails to execute a command. itf_reject_count 76 87 UnsignedByte 1 Counter is incremented every time the flight software receives an ITF and the ITF is either invalid or unable to be processed. The four cases for which this counter increments are: Not enough memory available to allocate a software bus packet; Invalid command format; Incorrect checksum; Synch pattern incorrect. watchdog_count 77 88 UnsignedByte 1 Increments on every reset of the flight software watchdog. cpureset_count 78 89 UnsignedByte 1 Increments on every reset of the flight software CPU. A CPU reset can occur one of two ways: Software was directly commanded to reset; Software erroneously branched to an unused memory address and executed a 0xFF instruction. reset_cause 79 90 UnsignedByte 1 Every time the flight software reboots, registers in the CPU board FPGA are examined in order to determine the cause of the reboot: =0 Power On, =1 CPU Reset, =2 Watchdog, =3 Invalid. mla_mode 80 91 UnsignedByte 1 Flight software mode: =0 Keep Alive, =1 Standby, =2 Science dpu_selection 81 92 UnsignedByte 1 The spacecraft has two DPUs that can interface to the MLA instrument. Only one of them can be active at a time. =0 DPU A, =1 DPU B. watchdog_enabled 82 93 UnsignedByte 1 1 Watchdog enabled. =0 Watchdog disabled. Flight software will still continue to service the watchdog but it will have no affect, nor will there be any effect if the software fails to service the watchdog. pca_power_mode 83 94 UnsignedByte 1 The PCA controls the power on the MLA instrument. There are two power modes. Under normal operation, Keep Alive software mode configures the PCA to low power mode. Standby and Science software modes configure the PCA to high power mode. =0 low power mode, =1 high power mode. pca_laser_enabled 84 95 UnsignedByte 1 The laser on the MLA instrument can be directly turned on and off. Under normal operations the laser is automatically configured to be on in Science mode and automatically configured to be off in all other modes. =0 laser is OFF, =1 laser is ON. algorithm_mode 85 96 UnsignedByte 1 The currently designated science algorithm mode. Only modes 0 and 1 were implemented in FSW at launch. =0 Mode 0 or Fixed, =1 Mode 1 or Spacecraft Range, =2 Closed Loop. range_mode 86 97 UnsignedByte 1 The currently designated range tracking mode: 0= Don't use the spacecraft range data 1= Use spacecraft range in tracking algorithm 2= Reserved for future use in Algorithm Mode 2. hwdiag_tlm_config 87 98 UnsignedByte 1 =0 neither MLA_HwDiagnostic nor MLA_HwDiagLite is on. =1, one of the hardware diagnostic packets is on. swdiag_tlm_config 88 99 UnsignedByte 1 =0 The Mla_SwDiagnostic packet is OFF =1 The Mla_SwDiagnostic packet is ON. met_free_run 89 100 UnsignedByte 1 Every second the flight software checks to see if it has received a MET message from the spacecraft. If it did not receive the MET message it will free run off an internal clock until the MET message is received again. When using GSEOS build 4 or lower, the MET message is not consistently issued, and therefore this telemetry point will show the software free running often; this is fine. There is one known error condition for this telemetry point and that is when the science task overruns and delays the telemetry framer task for a considerable period of time (over 50ms). It is possible in that case that the MET was received, but because the task that monitors the MET was delayed, the software believes it is free running and will flag this telemetry point. =0 the flight software did receive a MET message =1 the flight software did NOT receive an MET message. mem_write_enable 90 101 UnsignedByte 1 =0 memory is not write enabled =1 memory is write enabled. sd_parity_error 91 102 UnsignedByte 1 Every time the RUPT is generated, the flight software reads 166 bytes from the RMU (the shot data). The last byte of the data read from the RMU is a parity byte (XOR over entire block). The flight software also computes a parity for the data read from the RMU. If the two parities do not equal each other this telemetry point increments. This value should never be anything but 0. mlasta0809270801.lbl 0 PDS3 Original PDS3 label Carriage-Return Line-Feed