[cssm] D-DOR FRM definition

Wed May 12 14:33:45 UTC 2021

Hi John,

The mail is there, but no attachment....

Marcin

From: SMWG <smwg-bounces at mailman.ccsds.org> On Behalf Of John Pietras
Sent: Mittwoch, 12. Mai 2021 16:32
To: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Subject: Re: [cssm] D-DOR FRM definition

Resend - my apologie!

From: John Pietras
Sent: Tuesday, April 27, 2021 6:29 PM
To: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>>
Subject: D-DOR FRM definition

CSSMWG colleagues ---
Attached is the FRM HTML DOCX file that contains the "approved" Tier-1 FRM definitions and the draft Tier-2 FRM definitions. The Tier-2 definitions include the DdorRawDataCollection FR. On the first page, the link can be found on the Physical Channel: Delta-DOR Raw Data Collection line. This FR performs the reception of the radio waveform through the generation of the D-DOR Raw Data file.

As I said in today's WG meeting, I have not yet reviewed this FR definition. However, Wolfgang has told me that he organized it around the information that appears in the Delta Raw Data Files that the FR produces.

As with all of the FRs, the parameters that are proposed as configuration parameters have the Configured attribute set to 'true'.

NOTE - there are some issues with the limits and data types used by the D-DOR file format with respect to the data that's available in the SANA Service Sites and Apertures registry. Ideally, the D-DOR files would be able to use those SANA values directly. The email below summarizes the issues that Wolfgang and I uncovered regarding this.

Best regards,
John

From: Wolfgang Hell [mailto:wo_._he at t-online.de]
Sent: Friday, March 5, 2021 9:55 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>; Shames, Peter M (313B) (peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; Border, James S (335D) (james.s.border at jpl.nasa.gov<mailto:james.s.border at jpl.nasa.gov>) <james.s.border at jpl.nasa.gov<mailto:james.s.border at jpl.nasa.gov>>
Cc: Erik.J.Barkley at jpl.nasa.gov<mailto:Erik.J.Barkley at jpl.nasa.gov>; Holger.Dreihahn at esa.int<mailto:Holger.Dreihahn at esa.int>; Pham, Timothy T (3300) (timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>) <timothy.t.pham at jpl.nasa.gov<mailto:timothy.t.pham at jpl.nasa.gov>>
Subject: Re: SANA Service Sites and Aperture registry and Delta-DOR raw data files

Dear John, Peter, and Jim,

This is to thank John for his concise description of the issues that we have uncovered. In addition to what he has addressed in his email below, I would like to mention that CCSDS 506.1-B-1 needs to identify the observed objects which are either a spacecraft or a quasar. For the spacecraft ID we have the same constraint as for the station ID (four ASCII characters) and as a consequence the pertinent SANA registry cannot be used as source for this ID. If an update of CCSDS 506.1 is envisaged, this issue could be resolved on that occasion as well as the station ID problem.

The quasar IDs are those of the JPL maintained quasar catalog and as far as I can tell any agency acquiring DDOR raw data is using that catalog. In other words for that point we do not have a problem in CCSDS 506.1, but I'm wondering if it would not be better (if acceptable to JPL) to have this catalog under the auspices of a standardization body such as CCSDS for instance by converting this catalog to a SANA registry.

Best regards,

Wolfgang
Am 04.03.2021 um 16:41 schrieb John Pietras:
Peter and Jim,
As a consequence of Wolfgang Hell's development of the definition of the functional resource representing the reception and processing of D-DOR data into raw data files, Wolfgang and I have uncovered several issues regarding the SANA Service Sites and Apertures (SS&A) registry, some of which relate to information in D-DOR raw data file headers.

Let's start with the D-DOR-specific issues first. CCSDS 506.1-B-1 stipulates (a) that the Observation Header of the Observation File contains two "STATION" (transmit and receive), each of which contains "4 ASCII characters", and (b) the Header of the Product File contains a 16-bit unsigned integer "STATION ID" field. Currently, it appears that the values that are used to populate these fields are bilaterally agreed, although the SANA Considerations paragraph (B2) states "Conventions for Spacecraft and Station IDs may be collected in a future SANA registry."

The SANA SS&A would seem to be the logical registry to cover the "Station ID" aspects. Currently the SANA SS&A registry specifies/registers:

  1.  A "Name" for each site. These names are geographical in nature, e.g., the name of the (closest) town, or the island on which the site resides. These names *are not unique* - e.g., there are 3 sites name "Kiruna" - one each owned by CNES,ESA, and JAXA;
  2.  An "Abbreviation" for the Name. As currently used in the SS&A registry, these really aren't abbreviations at all - most are longer than the corresponding name. But they *are* unique. For the 3 sites named Kiruna, CNES site has the abbreviation "Kiruna", ESA has "Kiruna0", and JAXA has "Kiruna01". So rather than "Abbreviation" this attribute would more properly be called something like "Distinguished Name" or "Globally-Unique Name";
  3.  An Object Identifier (OID) for the site under the CCSDS Service Sites and Apertures node (1.3.112.4.9). The "label" for the OID is the so-called "abbreviation" for the site name. E.g., for the JAXA Kiruna site named "Kiruna", the abbreviation "Kiruna01" is the label for the OID for the JAXA Kiruna site;
  4.  Under each site, one or more apertures, each of which has
1)         A name
2)         A so-called Abbreviation
3)         An OID. As with the site-level OIDs, the labels for the OIDs are the Abbreviations.

Now back to CCSDS 506.1-B-1.  "Station" is not defined, but from the context of the example in Annex E, where two STATION fields are populated with "DS24" and "DS25", I interpret "station" to most closely map to "aperture". From the current contents of the SS&A registry, it's clear that many of the aperture names/abbreviations are not strictly 4 characters: some are 3, and many are more than 4. So "out of the box" the aperture names/apertures can't be used directly in the Observation Header. One could consider changing the STATION fields in the Observation Header to be longer or variable length, but perhaps the simpler approach would be to add an (optional) attribute for those apertures that are used to support D-DOR operations. Similarly, an unsigned integer Station ID attribute could be added to register the values used in the Headers of the Product Files.

CCSDS 506.1-B-1 was published in 2013, and there is no indication on ccsds.org that it has been certified beyond its nominal 5-year "freshness" date. Before the book is updated or re-affirmed, the discrepancies between it and the SANA SS&A registry should be resolved so that that registry can be cited in the blue book (at least for matters concerning Station IDs).

The remainder of my comments on the SS&A registry are more general. As background, my plunge into this registry was motivated by the need to conform the presence of OIDs for the sites and apertures. CSS Area products, and CSTS products in particular, make use of the OIDs to identify these entities. I found that finding these OIDs wasn't as straightforward as I might have hoped.

When one goes to the Service Sites and Apertures registry page, one sees

[cid:image001.png at 01D7474C.90540130]

What I did initially was scroll down the list of sites to find the ESA site with the name "Kiruna"*, and hit the Details button. That resulted in multiple pages of data (includingthe OID for ESA), but no OIDs for the site itself or its aperture(s.)

However, if one clicks on the OID Tree at the top of the page, one *does* get the site and aperture OIDs:

[cid:image002.png at 01D7474C.90540130]

To get the "right" Kiruna (in this case, the ESA Kiruna), one has to use the "abbreviation" (which, as noted above, therefore should be more properly called something like "distinguished name") to know which site one is looking for. Of course, none of this is explained anywhere.

I think that for completeness the site and aperture OIDs should also be displayed in the Details for each site.

Finally,on the left side of each site entry in the main table is an arrow. If you click on that arrow you get another listing:

[cid:image003.png at 01D7474C.90540130]
[cid:image004.png at 01D7474C.90540130]

In this case, "Kiruna" is identified as/associated with a city. But If I look at the Wallops Island "arrow", it doesn't give a city but just a State/region (VA), even though it also has a "City " listing under the "Details" view. The logic of why different things are displayed for different sites in the "arrow" view are not at all obvious.

In summary, I would suggest that:

  1.  The Station identifiers that are used in the D-DOR raw data files be accommodated by the SS&A registry, either by changing the D-DOR raw data file blue book to use registry names and identifiers or by adding the D-DOR identifier to the SS&A registry as optional atrtributes;
  2.  The Details view should also display the site and aperture OIDs; and
  3.  The title "Abbreviation" be replaced with something that more accurately describes the contents, like "distinguished name" or "globally-unique name", and that they be more reader-friendly (e.g., "Kiruna_ESA", Kiruna_CNES", and "Kiruna-JAXA").

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210512/172e0bc8/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 30904 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210512/172e0bc8/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 29051 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210512/172e0bc8/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 18142 bytes
Desc: image003.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210512/172e0bc8/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 44707 bytes
Desc: image004.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20210512/172e0bc8/attachment-0007.png>