Users are encouraged to provide comments to the PDS Imaging Node if errors are found either in data or in documentation in this archive. Please send comments by e-mail or U.S. mail to the Imaging Node: PDS Imaging Node California Institute of Technology Jet Propulsion Laboratory 4800 Oak Grove Drive Pasadena, CA 91109 Web: http://img.pds.nasa.gov/index.html This file, ERRATA_XXXX.TXT, contains release notes and errata identified in the MSL MAHLI raw and calibrated archives in volumes volume_0XXX_raw and volume_0XXX_calibrated, respectively. During the course of the MSL mission the MAHLI science team may update previously released data products or documentation; for example, updates may occur due to changes in calibration data or procedures. Updates will be reported in this file. Older versions of data and documentation will not be retained in the archive. Section A of this file contains an entry for each MSL release with general information about the contents of the release. Updates to previously released files are reported in these entries, along with any known errata. Section B of this file contains general notes, if any, concerning the volume as a whole. ******** SECTION A ******** RELEASE NUMBER: 3 RELEASE DATE: 2013-08-30 DATA COVERAGE: 2013-02-06 to 2013-05-08 (Sols 180-269) PRODUCT TYPES RELEASED FOR THIS ARCHIVE: MAHLI EDR & RDR PRODUCT TYPES UPDATED FOR THIS ARCHIVE: None 1. The following products failed to compress resulting in a different product type being downlinked than was originally commanded and a mismatch in compression values between the thumbnail and corresponding image: PICNO CDPID ------------------------- ----- 0058MH0000250010100440B00 440 Reason: On sol 18 an issue was discovered with the MMM compression algorithm. The algorithm assumes the uncompressed image size is the largest data volume size the image can be. However, after compressing the images, the resulting image ended up being larger in data volume size than the original, uncompressed image size (due to scene activity). Consequently, a warning was issued from the DEA and an error report was filed, and no image was received. As a result these products had to be recovered uncompressed by a separate sequence. This creates a discrepancy between what type of image was originally commanded versus what type of image is downlinked. For the above image, a type C (lossless) image was commanded; however, the recovered image is a type B (raster 8-bit) image. This can also be seen in the thumbnail, type I, (which states compression = -101) and the recovered image, type B, (which states compression = 0). 2. The following onboard products failed to compress. They were originally commanded as JPEGs and received as such. The PI decided that he wanted these products returned as lossless images. They were commanded to be downlinked again with compression = -101 however they failed to compress due to the issue with the MMM compression algorithm explained above. As a result, they were commanded once again, however, this time with compression = 0. PICNO CDPID ------------------------- ----- 0058MH0000260010100379B00 379 0058MH0000260020100380B00 380 0058MH0000260020100381B00 381 0058MH0000260020100382B00 382 0058MH0000260020100383B00 383 0058MH0000260010100389B00 389 0058MH0000260020100390B00 390 0058MH0000260020100391B00 391 0058MH0000260020100392B00 392 0058MH0000260020100393B00 393 0058MH0000270010100399B00 399 0058MH0000270020100404B00 404 0058MH0000280030100415B00 415 0058MH0000240020100435B00 435 0058MH0000250020100441B00 441 0058MH0000250030100446B00 446 0060MH0000350010100548B00 548 0060MH0000360020100555B00 555 0074MH0000350010100811B00 811 3. The following products were created with incorrect PICNOs for the following reason: sequence:mhli00196, sol:162 Assigned PICNO range Expected PICNO range -------------------------- -------------------------- 0162MH0000000000101952C00- 0162MH0019600100101952C00- 0162MH0000000000101958C00 0162MH0019601000101958C00 Reason: The sequence, mhli00196, was mistakenly commanded with tracking ID 0. The result is that neither the sequence ID nor the sequence line (command counter) were included in the PICNO, which is why the PICNO is populated with zeros. The original thumbnails were downlinked as type "I" products in RELEASE 0002. These were commanded to be returned as lossless and thus the "C" product type designation. **************************************************************** **************************************************************** ******** SECTION B ******** This section is provided for general notes concerning the archive as a whole. 1. When acquiring video products, the product for the first frame captures values for the current state of the rover. However, all subsequent frames within that video retain the rover state values from the first frame. As a result, some values are not accurate after the first frame. The following values within the xml and INDEX files for video products will be set to nil: xml --------------------------------- Under the attribute: Product_Observational:Observation_Area: Discipline_Area:Imaging:Instrument_State: Device_Temperatures:Device_Temperature: device_name for DEA HEAD_FPA ELECTRONICS ELECTRONICS_A ELECTRONICS_B the keywords: temperature_value temperature_status Under the attribute: Product_Observational:Observation_Area: Discipline_Area:geom Geometry: geom Geometry_Lander: geom Derived_Geometry the keywords: geom solar_azimuth geom solar_elevation INDEX ----------------------------- Under the attribute: Product_Observational:Observation_Area: File_Area_Observational:Table_Delimited: Record_Delimited:Field_Delimited:name INSTRUMENT_TEMPERATURE:FPA INSTRUMENT_TEMPERATURE:OPTICS SOLAR_AZIMUTH SOLAR_ELEVATION 2. Clarification of the "sequence_id" in the data product .xml file versus the "Sequence ID" in the Product Identifier described in the MMM PDS Data Product Software Interface Specification (SIS) As stated in the File Naming Convention section of the SIS, the first six digits of the product identifier (Sequence ID) are reflected in the sequence_id keyword value in the data product label file (.xml). This is the case when the Mastcam data are downlinked via the original sequence that acquired the data as recorded in the product identifier. Occasionally, the data are requested to be downlinked differently than acquired (e.g., a different compression); this is done by sending a new sequence, which is recorded in the sequence_id. In this case, the FSW inserts the new sequence information into the sequence_id keyword value. As a result, the first six digits of the product identifier (as originally acquired) and the sequence_id keyword value (as downlinked) are not the same. 3. In Releases 0001-0011, the version ID in the PICNO (see section 3.4.1 of MSL_MMM_EDR_RDR_DPSIS.PDF) does not necessarily match the daily, operational version of the same product. Due to the fact that there can be multiple versions of a product (e.g., partials) received during operations, this value is incremented for each version of a product received. However, for PDS archiving, when applicable, only the full and complete version of a product is archived which will receive the lowest version ID possible for that type of product. In most cases, this is a value of 1. As a result, the PDS products archived in Releases 0001-0011 do not necessarily reflect the same version ID seen in the corresponding final, complete version of a daily, operations-received product. To account for this, lookup tables which correlate the operational PICNO to the PDS PICNO for Releases 0001-0011 have been provided in the miscellaneous_MSLMHL directory. There is one table for EDR and one table for RDR products. Starting with Release 0012, all full versions of every operationally- produced product will be available in the MAHLI PDS volume, and partial products will be taken into consideration when assigning the PICNO version number. This will ensure that all PICNOs in the PDS volume match with the corresponding daily, operational version of the same product. 4. For each frame of a GOP, various keywords within the INDEX and xml files are only partially accurate due to the way the camera hardware operates. The camera only returns the coarse SCLK and not the fine SCLK, and as a result, the fine SCLKs need to be estimated with software. This estimate will not necessarily reflect the actual time in which the frames were acquired.