| Comment ID | Submission Date | Feedback Type | Topic | Comment | Suggested Change | Rationale | WG Response |
|---|---|---|---|---|---|---|---|
| 101 | 2018-10-03 02:31:01 | Critical | Standard Document | On the section 4 SDR Data Collection Topologies, based on state of the art of RF front-end, it is possible to have the following topology: One DCS (so one localized antenna), multi-band recording, multi-stream and thus splitted SDR files. The File splitting is then done by frequency (no spatial or temporal). this topology is important because it allows to record only the signal of interest and not recording the full L band (with may lead to storage issue). | adding this new topology | The mentioned topology is supported and shown in Fig. 1b. Clarification text was added to section 4.1 (see changes in Revision 0.4 of the document). Furthermore, the topologies shown in Figure 1 represent basic types and combinations of these are also possible. | |
| 102 | 2018-10-03 08:08:28 | Administrative | Standard Document | Figure 4 says "Comprized of". | Replace with "Comprised of". | Typographical error. | The typographical error has been fixed in revision 0.4 of the document. |
| 103 | 2018-10-03 08:17:48 | Substantive | Standard Document | Section 6.1 uses "core class" to refer to instances of the class (e.g. "possible number of core classes contained inside the previous core class"), which makes the term ambiguous to many software developers. | Use "object [of a core class]" (as in the section titles for sections 6.2.n) or "instance [of a core class]" when referring to a particular record or data item, and use "core class" to refer only to the abstract data type. Other terms like "[data] item" could also resolve the ambiguity, but "object" and "instance" are most strongly associated with software classes. | Consistency with common software development usage; remove ambiguity. | Instead of "core class" the naming "instance of core class" is used in section 6.1. Document has been updated and checked for consistency. Revision 0.4 includes these changes. |
| 104 | 2018-10-03 08:22:47 | Substantive | Standard Document | Figure 3 shows multiplicity of 0..* for "lane" within "file", which means a file within a fileSet might contain no readable data. | Change that multiplicity to 1..*, or include a rationale for allowing a file within a fileSet that contains no readable data. | A file with no readable data is not of interest to a consumer of the fileSet. | Comment is agreed and the multiplicity has been corrected in revision 0.4 of the document. |
| 105 | 2018-10-13 11:18:19 | Critical | Standard Document | The position definition for Section 6.3.5 and 6.3.6 needs to be more versatile. There are widely known limitations in characterization of position as "LLH" (Latitude, longitude, height). Longitude loses meaning at the poles. | Either a 3-parameter (ECEF vector) or a 4-parameter set (quaternion elements corresponding to a transformation between earth and nav-reference coordinates) would work. If the latter, then the azimuth orientation in the representation for attitude will need to be in conformance to that nav-reference frame. This step may necessitate handling the datum issue in another way. | Desire for characterization that covers any location needing no qualifications or caveats. | See response to comment ID 106. For the purpose of describing geographical coordinates the current position definition will be maintained and the intention of this element will be clarified. |
| 106 | 2018-10-13 11:25:31 | Critical | Standard Document | Characterizing orientation in terms of Euler angles (roll, pitch, and "yaw") as in Section 6.3.7 has widely known limitations. Even the terminology is incorrect. The axis for rotation about 'z' is definitely not the yaw axis unless both roll and pitch angles are zero. "Yaw angle" is a misnomer; that z-axis rotation angle is heading (which loses meaning at the poles just as longitude does). Also it is widely realized that Euler angles have an "Achilles' heel" gimbal lock for +/- 90-degree pitch. | A 4-parameter parametrization for attitude (quaternion elements enabling transformation between nav-reference and vehicle axes) would remove the singularity. | Unambiguous all-attitude representation with no conceptual, analytical, or computational pitfalls. | The comment is appreciated and will be considered. Concerning the fact that the geometry of the data collection system is only a side aspect of the standard and since the normative software does currently not support reading of the position or orientation elements, any suggestion on how to represent orientation or positions in a body coordinate frame will be removed from the document. Instead, an XML comment shall describe, on a case-per-case basis, how possibly present origin and orientation attributes of the respective frames of the cluster and source objects have to be interpreted. |
| 107 | 2018-10-13 11:29:47 | Proposal | Standard Document | Never missing a chance to advocate availability of individual SV measurement data, I nevertheless acknowledge the challenge of reconciling that goal with the SDR metadata standard. | With a primary objective of enabling transfer of basic RF front-end parameters to SDR processors (thanks to Sanjeev for that clarification), my desire for measurement data in this context is presently limited to a simple recommendation for possible future consideration. | The present initial version of the standard prioritizes front-end and sample formatting information since that addresses the greatest need for the GNSS SDR community. However, given sufficient adoption and the need to support additional domain-specific data (of which raw observables represent a part), these may be considered in future revisions of the standard. | |
| 108 | 2018-10-18 04:17:44 | Proposal | Standard Document | For streamer in which bandwidth, sampling rate and sample resolution are independently programmable, having a fixed data structure over time becomes inefficient and forces Front-End (DCS) designers to adopt complex and unneeded stream composition schemes.
In several fields (not only GNSS) this type of streams have a quantum "packetization" in which the quantum header or footer itself includes the source identifier. In this case each stream is producing a fixed quantum of structured data (eventually optimized for the physical characteristic of the storage media ore the composite stream transport channel), the packet. This block of structured data is complemented by a header or a footer which allows "the consumer" to identify the source stream. The temporal position of a packet in a stream is based on a "availability" basis. The frequency of a packet from a particular stream depends on various factors such as resolution, sampling frequency. The packet ordering isn’t mandatorily strict which means that the exact position of a packet in the composite stream isn't guaranteed (over a short period). This approach is, in our opinion, more suitable for real-time streaming GNSS RF digitizer (or DCS as ION are calling them) especially if they have are interfaced in real time to a SW receiver. Unfortunately the standard ION is proposing in "Software Defined Radio Sampled Data Metadata Standard Revision 0.3" do not allows to describe such an approach. |
Not just discard the block header but extend the standard in order to make the ""consumer"" able to interpret in and use it to identify the stream source. | In our opinion it would be a plus if the ION standard would allow to describe multi stream fixed and common packet size DCS in which the block stream source must be actively read by the "consumer" by interpreting the block header. | The concept and support for dynamic packets for sampled data are addressed in other standards such as VITA standard 49 (VITA 49). VITA 49 prescribes a model/format for new and evolving systems. The goals for the ION metadata standard are significantly different from VITA 49 in that it serves to describe existing GNSS SDR sampled data formats in a consistent manner such that compliant GNSS SDRs can decode and consume the data. The formats of existing DCSs used for GNSS SDR applications cannot be conveniently described by VITA 49 or any other existing standard. Further, GNSS SDR applications typically require domain-specific information that is not typically considered by other SDR groups (e.g. antenna phase center locations relative to a reference location, group delays between data streams, reference oscillator parameters). Finally, unlike in applications such as multimode comminications systems, GNSS applications do not have a use case for dynamically changing sampling formats where the parameters are changing over short intervals that would warrant dynamic decoding and interpretation of parameters and formats on a per-packet basis.
Nevertheless, the idea of having a "quantum" header and more flexibility in interpreting the block header (instead of just discarding it) to identify the position of the block within the stream or the source of the block is clearly an intereting concept. The proposed extension will thus be discussed in future revisions of the standard. See also comment ID 1 of RFC1. |