PDS_VERSION_ID = PDS3 RECORD_TYPE = STREAM PRODUCT_ID = "ERRATA.TXT" DATA_SET_ID = "RL-C-ROMAP-3-RBD-SPM-V1.0" OBJECT = TEXT NOTE = "ERRATA file for RL-C-ROMAP-3-RBD-SPM-V1.0" PUBLICATION_DATE = 2020-09-23 END_OBJECT = TEXT END This data set was not fixed after the last review. Below are the remaining known issues. Is it ok for hk's value to have 5 digits at the end vs. 2 for mag? The data files include 5 digits to the right of the decimal place. The label described the units of the column as "seconds". The LOBT (lander on board time) format is sssssssss.dd where the "s" are close to seconds with drift, and the dd are 1/32 of a second (0.03125 seconds) so it takes 5 digits to give sclk in decimal seconds. However, if the value is really still an LOBT and not a time from some epoch, the value of the decimal seconds will be (0, 0.03125, 0.06250, ...) and no other values are allowed. When you look in the data files, you find values of the decimal seconds that are not in the allowable set for LOBT. If the data files have been created correctly with the appropriate time tags (both UTC and LOBT), then the reason for the components of the LOBT not being in either the set (0,1,2, ..., 31) or the set (0.0, 0.03125, 0.06250, ..., 0.96875) has not been adequately explained. If the LOBT has been "drift corrected" into seconds, then it is improper to refer to is as LOBT and user would need to know the drift kernel used in the correction in order to have a complete description of the time provided. The issue with the LOBT times is one of concern. This is the only real time stamp associated with the data and it should be left in it’s unadulterated form (integer.integer) and not converted into decimal seconds. This applies to labels and most especially to the data files themselves (and the -2- files in particular). All of the data files in all of the -3- datasets have LOBT values to the right of the decimal point that converts back to an integer in the range of 0-31 when multiplied by 32. The documentation (dataset.cat’s) should be updated to address this reformatting of the LOBT. The HSK files for all of these data do not meet the standard above and should be corrected but I don’t believe that this impacts the usability of the data. All of the -2- datasets remain uncertified due to this LOBT issue. While I believe that all of these files should preserve LOBT in it’s integer form, I would be minimally satisfied if the HSK and SC data were self-consistent and the fractional part of the LOBT could be converted back to an integer when multiplied by 32.