Radio Science Liens =================== Documentation ============= file: document/rss_sis.pdf --> Page 2 Table 1-1. Recommend adding DSN SIS documents (TRK-2-34, TRK-2-24, TRK-2-25) --> Are the antenna phase center locations avaiable (Table 2-4)? --> Was the transponder delay measured or have a requirement (Section 2.1.3.1)? --> 2.3.2 The skyfreq files are not a standard DSN product and thus aren't documented in the radio science documentation bundle. Some description of how they are produced would be helpful. Similary, TRK-2-34 files as delivered by the DSN are not really PDS compliant as the radio science documentation bundle points out. Recommend a statement for pre-processing before archival stating the records were sorted by data type to improve PDS4 labeling. These are all stated below in Section 3 but a brief statement here would be helpful, or at least refer the reader to Section 3. --> 2.3.2.1 Calibrated Data product generation. this seems like a leftover section from a template since there are no calibrated data products. Remove? --> 2.3.3 Data flow. This section is empty, is it intended to be removed or have some content? --> 3.2.2 Small Forces. Text states there is a SIS provided in the documentation bundle, but it is missing. The collection refers to OREX SFF SIS. This SIS does not mention Lucy in it, and that SIS has multiple formats depending on the spacecraft. The data labels themselves specify that the format is the same as ORX and the labels appear to properly describe the data. However, the Lucy files have 31 columns yet the ORX SFF SIS specifies 47 columns and ORX data have 47 columns. This should be explained somehow. --> Section 2.4.4 states that ASCII files generally end in line feed. SFF and ION files, which do not have the .TAB extension, actually end in in new-line. Perhaps call this out more clearly. --> Section 3.2.1 correct the link to https://pds-geosciences.wustl.edu/radiosciencedocs/urn-nasa-pds-jpl_dsn_mmm/ (missing a hyphen at “pdsjpl”. (Ideally, we do not want URLs in archival products. Is there a more permanent reference to this page?) --> The newly posted SIS, 22668.07-RSS-SIS-01 R0 C1, no longer contains the sky frequency data format description table, which is good to have. --> 3.2.3 Columns 6 and 7 are declared as not used in closed loop mode. However, the data files contain values other than 0000-00-00T00:00:00.000 or -999999999.999999, respectively. Perhaps the data were collected in “open loop” mode? Please clarify. [kahan@chiron data_dinkinesh_skyfreq]$ head L14TNFXL02_DPX_233051830_00.TAB 00000001 2023-11-01T18:30:06.497 305.77090853 752135475.680000 2.264122 2023-11-01T17:36:27.801 7188358000.631005 -999.999999 8445908395.101487 8445908394.902000 0.002762 0.199487 -126.0 0.000000 -99999.999999 -999.9 -999.9 00000002 2023-11-01T18:30:07.497 305.77092010 752135476.680000 2.264122 2023-11-01T17:36:28.801 7188358001.192585 -999.999999 8445908394.358078 8445908394.229759 0.002762 0.128319 49.0 0.000000 -99999.999999 -999.9 -999.9 --> 3.2.3 Column 8 designated as -99999.999999 but data files contain -999.999999 --> 3.2.3 Column 14 designated as -999.999999 but data files contain 0.000000 --> Acronym List contains several entries that don’t appear in the document. --> Some entries that should be included in the acronym list are TNF and SFF Minor editorial corrections (correct version appears): --> (2.1) Lucy will encounter a Main Belt asteroid in 2025, visit its first Trojan asteroid in 2027, and accomplish its remarkable succession of encounters by 2033, --> (2.1.1.1) For SPE angle less than 14 degrees --> (2.1.1.1) For SPE angles between 14 and 53 degrees --> (2.1.1.1) The LGA is used for SPE angles greater than 53 degrees. --> (2.1.1.1) when SPE angle is less than 60 degrees --> (2.1.2) Note that the Lucy project has been approved to use the uplink and downlink X-band frequencies/channels assigned to the OSIRIS-REx and MAVEN projects. --> (2.3.4.1) Each of the radio science data products has a unique naming convention --> (2.3.4.1) The naming convention for the tracking data products (trk-2-34) products is --> Naming Conventions. Please clarify the use of “TNF” throughout the document. It is the extension for TRK-2-34 files, assumed to mean “Tracking and Navigation File” (though that is not stated). It is also included in the naming for sky frequency files, presumably meaning the same thing. However, if so, how is it known from “TNFX” that the data are two-way? “rrrr = receiver system; TNFX = Trac-2-34 two-way single X-band.” Perhaps only 2-way data were used in the creation of the sky frequency files. If so, no need to mention 2-way in the naming convention. Just reserve discussion for section 3.2.3 describing the sky frequency files. file: data_dinkinesh_trk234/collection_overview.txt --> refers to .tnf text files but trk-2-34 files are not text. Data ==== data_dinkinesh_ion/ --> there are multiple files that cover the same months, but with updated data. I don't see a strong reason to have archived multiple versions of the same coverage window, only the latest ones should be archived. Leaving all versions in would lead to confusion. If data providers want to archive multiple of the same data coverage window I would recommend adding a statement into the SIS to only use the latest delivery date file. data_dinkinesh_skyfreq/ --> labels contain internal reference to small forces. i think this is an oversight and actually belongs in the SFF labels. urn:nasa:pds:orex.radioscience:document:naf018 data_to_document Although this document does not explicitly pertain to Lucy, its content is still applicable. Until a new version of this document is created for Lucy, this reference will have to suffice. --> label makes reference to a SOURCE_PRODUCT_ID but I can't find that anywhere else in the label. the description also makes reference to S-band which Lucy is not capable of. Can the description be updated? --> column DISTANCE doesn't seem correct (2.26 km?) --> column DIFFERENTIAL DOPPLER states that if invalid it will be -999.999999 yet the value is actually zero in the files Labels ====== file: data_dinkinesh_trk234/collection_inventory.csv --> Collection CSV has a typo - P,urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collectin_inventory::1.0. (This should probably refer to the collection_overview product.) file: data_dinkinesh_skyfreq/L14TNFXL02_DPX_233051830_00.xml --> 1. “The SOURCE_PRODUCT_ID mentioned in the label header above links to the different data files used for processing of the DOPPLER output file. …” Where is this? file: data_dinkinesh_sff/lcy_r_230829_230904_v01.xml --> 1. DMASS – it isn’t defined what this variable actually is. Like the missions listed, will it always be zero for Lucy? issue: Lucy RSS name inconsistency --> Sometimes this instrument is called "Lucy's Radio Science instrument" or "Lucy Radio Science Subsystem" or "Lucy Radio Science System" or etc. Please consider trying to be more consistent, where appropriate. I saw these inconsistencies in collection descriptions, titles, names, etc., within the labels. I did not look thru any other text to see there. Please double check the value in the lucy.rss context object is correct. issue: Primary_Result_Summary --> Sanity check the value: --> --> All ion and sff products say "Calibration" but the collection.xml says "Science". I would not expect this mismatch. --> --> Are the TRK234 products supposed to be Science? --> --> Note here is a good list of possible values and their definition per the PDS: https://pds.nasa.gov/datastandards/documents/dd/v1/PDS4_PDS_DD_1K00/webhelp/all/#ch05s714.html#N760331470 files: '*/collection.xml' --> Sanity check: is the Identification_Area.Citation_Information.description for skyfreq collection supposed to be "calibrated data products" and for ion collection supposed to be "raw data products". --> The following Identification_Area.title values differ from what was submitted in the past. The new values do not make sense. I recommend combining the two values (old/new). Note three of them are now exactly the same, which should never be the case. [collection: OLD => CURRENT] --> --> ion collection: "Lucy Radio Science Mission Dependent Ionosphere Data Collection" ==> "Lucy Radio Science Dinkinesh Raw Data Collection" --> --> sff collection: "Lucy Radio Science Small Forces File Data Collection" ==> "Lucy Radio Science Dinkinesh Raw Data Collection" --> --> skyfreq collection: "Lucy Radio Science Sky Frequency Data Collection" ==> "Lucy Radio Science Dinkinesh Calibrated Data Collection" --> --> trk234 collection: "Lucy Radio Science Tracking Data Collection" ==> "Lucy Radio Science Dinkinesh Raw Data Collection" --> Is "(152830) Dinkinesh" really the target of these data collections or correctly reflecting the target? What should the target really be, what would be useful for the user looking for this data? The data files reflect the following as the target: --> --> ion collection: "Earth" --> --> sff collection: "Lucy Spacecraft" --> --> skyfreq collection: "Lucy Spacecraft" --> --> trk234 collection: "Lucy RSS" file: 'data_dinkinesh_ion/collection.xml' --> The authors of this collection are listed as "Pätzold, M.; Hahn, M.", but all of the data products list the author as "NASA Deep Space Network". Who should get authorship for this collection? files: 'data_dinkinesh_ion/gimacl*xml' --> These describe the CSP files as streamed text only. Is this a problem, or only thing possible? --> Should any of these data objects have units? I don't see any specified. file: 'data_dinkinesh_sff/collection.xml' --> If this collection was produced by NAIF, as the Identification_Area.Citation_Information.description and all of the data product labels states, than shouldn't they be one of the authors, if not the only author? --> The Identification_Area.Citation_Information.description typo: "NAvigation" vs "Navigation" files: 'data_dinkinesh_skyfreq/L*.xml' --> The values used should be updated to conform to PDS standards. Ex: "DAY" => "day" or "HERTZ PER SECOND" => "Hz/s" --> --> Here is a quick reference: https://sbnwiki.asteroiddata.org/Units_of_Measure.html file: 'data_dinkinesh_trk234/collection.xml' --> The authors of this collection are listed as "Pätzold, M.; Hahn, M.", but all of the data products list the author as "NASA Deep Space Network". Who should get authorship for this collection? --> The Identification_Area.Citation_Information.description states that the data products were produced by the Lucy's Radio Science team, but the data labels say "NASA Deep Space Network" is the author, and Lucy SOC members are the editors. Please resolve this discrepancy. files: 'data_dinkinesh_trk234/lucy*xml' --> The Identification_Area.Citation_Information.description of the collection.xml states that these data products were produced by the Lucy's Radio Science team, but these labels say "NASA Deep Space Network" is the author, and Lucy SOC members are the editors. --> Should any of these data objects have units? I don't see any specified. EN Review ========= lucy.rss:data_dinkinesh_ion *.xml - Suggestion: to match the context products, change Lucy Mission NASA Deep Space Network Media Calibration Global Positioning System to Lucy DSN Media Calibration Deep Space Station Media Calibration Subsystem - Suggestion: add lid_reference to DSN facility urn:nasa:pds:context:facility:observatory.dsn collection*.xml - Suggestion: to match the context products, change Lucy Spacecraft to Lucy - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:target:planet.earth Should that replace urn:nasa:pds:context:target:asteroid.152830_dinkinesh, which no child product has. collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:instrument:dsn.media urn:nasa:pds:context:investigation:other_investigation.media.dsn urn:nasa:pds:context:target:planet.earth lucy.rss:data_dinkinesh_sff *.xml - Suggestion: for Target_Identification, though the spacecraft acts as equipment here, still try to match the context product, so change Lucy Spacecraft Equipment to Lucy Spacecraft - Suggestion: for Observing_System_Component and Investigation_Area, to match the context products, change Lucy Mission Lucy Spacecraft to Lucy Lucy collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo collection_inventory.csv - Typo on line 1: P,urn:nasa:pds:lucy.rss:data_dinkinesh_sff:colection_overview::1.0 should be P,urn:nasa:pds:lucy.rss:data_dinkinesh_sff:collection_overview::1.0 lucy.rss:data_dinkinesh_skyfreq *.xml - Suggestion: use a calibrator target instead of the spacecraft, e.g. one of urn:nasa:pds:context:target:calibrator.flat_field urn:nasa:pds:context:target:calibrator.internal_source urn:nasa:pds:context:target:calibrator.non_science urn:nasa:pds:context:target:calibrator.spacecraft_deck ... If you stay with the spacecraft, still match the context product's name and type, so change Lucy Spacecraft Equipment to Lucy Spacecraft - Suggestion: for Observing_System_Component and Investigation_Area, to match the context products, change Lucy Mission Lucy Spacecraft Lucy Radio Science System NASA Deep Space Network to Lucy Lucy Lucy Radio Science Deep Space Network collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:facility:observatory.dsn L*.xml - Many fields' descriptions describe special values. Add Special_Constants to those fields to allow automated handling of those. Examples: TRANSMIT FREQUENCY - CONSTANT TERM: -999999999.999999 TRANSMIT FREQUENCY - LINEAR TERM: -99999.999999 OBSERVED X-BAND ANTENNA FREQUENCY: -999999999.999999 SIGNAL LEVEL: -999.9 DIFFERENTIAL DOPPLER: -999.999999 SIGMA OBSERVED ANTENNA FREQUENCY: -99999.999999 SIGNAL QUALITY: -999.9 SIGMA SIGNAL LEVEL: -999.9 lucy.rss:data_dinkinesh_trk234 *.xml - Suggestion: use a calibrator target instead of the instrument, e.g. one of urn:nasa:pds:context:target:calibrator.flat_field urn:nasa:pds:context:target:calibrator.internal_source urn:nasa:pds:context:target:calibrator.non_science urn:nasa:pds:context:target:calibrator.spacecraft_deck ... If not, use the spacecraft as the RSS skyfreq bundle does, i.e. change Lucy RSS urn:nasa:pds:context:instrument:lucy.rss to Lucy Spacecraft urn:nasa:pds:context:instrument_host:spacecraft.lucy If not, then match the context product's name, i.e. change Lucy RSS to Lucy Radio Science System - Suggestion: add lid_reference to DSN facility urn:nasa:pds:context:facility:observatory.dsn - Suggestion: for Observing_System_Component and Investigation_Area, to match the context products, change Lucy Mission Lucy Telecom System to Lucy Lucy Radio Science collection*.xml - Suggestion: to match the context products, change Lucy Spacecraft Lucy Mission Radio Science to Lucy Lucy Lucy Radio Science collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo - Suggestion: add the union of the children lid_references, i.e. add urn:nasa:pds:context:instrument:dsn.rss collection_inventory.csv - the LID of the Product_Collection itself does not go in this file, plus it's mistyped. collection_overview is missing. So change line 1 from P,urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collectin_inventory::1.0 to P,urn:nasa:pds:lucy.rss:data_dinkinesh_trk234:collection_overview::1.0 lucy_2023_*.xml - The descriptions for fields ul_zheight_corr and dl_zheight_corr in many tables describe -99.0 as a special value. Add Special_Constants to those fields to allow automated handling of those. lucy.rss:document collection*.xml - Suggestion: to match the context products, change Lucy Spacecraft Lucy Mission Lucy Radio Science Subsystem to Lucy Lucy Lucy Radio Science collection.xml - The product in this lid_reference isn't given here. Verify the LID is correct urn:nasa:pds:lucy.mission:document:lucy_mission_info In the 2023.05 review, many collection.xml had a lid_reference to urn:nasa:pds:lucy.mission:document:lucymissioninfo rss.pdf - section 2.3.4.1, typo: Where: gimcal = always gimcal gc = spacecraft number, for Lucy always 49 The last line should be "sc =", not "gc ="