RFC1 Comments and Responses
Comment ID Submission Date Feedback Type Topic Comment Suggested Change Rationale WG Response Preferred additional programming language (other than C++) for next revision, if any Reason for not yet using the C++ code Thread support (multi-thread safe) required for C++ code
1 2017-09-15 16:37:22 Critical Standard Document While I deeply understand the need for GNSS-processing specifics, I strongly suggest you begin with VITA Radio Transport format (VITA 49.2). Many software radio systems are being developed around this transport/storage format. You can then perhaps add a data model for certain needed fields on top of that. VITA 49.2 is the standard that SDR frameworks like GNU and REDHAWK are already embracing. You need strong rationale to not start there. VITA 49 was evaluated by this committee prior to the commencement of this standard development process. While it is true that VITA 49 very aptly addresses the transport and storage format for SDRs, it does not support describing metadata for the various sample packing formats that are already in use by the GNSS SDR community. The goal of this standard is not to prescribe a universal sample transport and storage format for GNSS SDRs (which VITA 49 supports) but rather to describe, through a universally applicable set of schema, the metadata associated with existing packed sample formats, including necessary and sufficient information to describe how to decode said samples. The standard also supports describing metadata for binary files that are stored in the packet-based VITA 49 VRT format. An example of this will be included in the ION example file repository (http://sdr.ion.org/api-sample-data.html) before this standard development efforts are finalized. N/A
2 2017-09-18 02:39:18 Proposal Standard Document I'm wondering if there's need for knowing more about the gain set in the recording device prior to quantization. Of course, its value changes over time, therefore it cannot be included into the meta-data. But the meta-data could describe the format of the "gain-file". After the recording the user might be interested in knowing if the recording hardware was working properly and if the input signal wasn't too weak or too strong. Just examining the sample distribution does not offer the full answer. Adding support for dynamically-changing gain settings is indeed useful for inclusion in the standard. However, it has been decided to wait for sufficient adoption of the first official version of the standard before this enhanced capability is considered. Multiple solutions exist within the current framework to add this capability – some that may be more efficient and/or optimal than others given various use cases. Hence, sufficient adoption and experience with the initial specification would allow adopters to weigh in on how best to include this capability, at which time an acceptable solution can be arrived at through consensus. The working group has noted the inclusion of dynamic gain setting metadata to be taken under consideration for the next formal revision of the standard. It is emphasized that the current framework allows for custom metadata objects to be included by users. Hence, not having formal support for dynamic gain settings in the initial version of the standard does not preclude one from adding this capability on their own. Neither would adding custom fields break conformance with the standard since unrecognized fields are simply ignored by a standard-compliant parser.
3 2017-09-23 16:59:35 Administrative Standard Document Object : headers style
The headers, sub-headers and sub-sub-headers all have the same style (font, font size, spacing). Usually they differ, for a better reading.
Moreoever, page 25, the font size of "7 Appendix:" is smaller than the other headers, and the colon at the end should be removed.
Your comments 3-13 have been addressed and incorporated to the latest version of the standard document. The latest version of the standard is available in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
4 2017-09-23 17:15:41 Administrative Standard Document Object : acronyms
Page 5, the list of acronyms is not completely in alphabetic order : UML and URI should appear after SDR; and XML should appear before XSD.
Moreover :
- The following acronyms could be added to the list of acronyms : LHCP, RHCP (used in Table 5), URL (used in section 6.3.1), MSB (used in appendix). Maybe toa (time of applicability) could also be added.
- Page 11, the acronym URI is not defined at his first use (it is defined only on page 22, section 6.3.1).
Refer to Comment Reference 3
5 2017-09-24 10:50:17 Administrative Standard Document Object : acronyms Maybe the acronyms DCS (used in Figure 1) and BPF (used in Figure 6) should be defined. Refer to Comment Reference 3
6 2017-09-24 10:56:44 Administrative Standard Document Object : figures
1. All the figures are raster graphics with low quality (pixelated and blurred). Vector graphics would give perfect quality graphics.
2. It would be more coherent if the font in the figures was the same as the text of the document.
3. In Figures 3 and 4 :
- The text in the boxes is not well centered (horizontally and vertically).
- The 1..*, 0..*, 0..1, 1, may be explained in the text before, because here the meaning is let to be understood by the reader (which is not what a standard document is supposed to do).
- It is not very clear why in Id appear in the box metadata element, whereas artifact and comment are outside, because in the text they are presented in a similar way and they are all required (as written in Table 1).
- According to me, the figures would look more professional if all the boxes had the same width and there was no shadow.
4. In Figure 4, Id should be written id, like it is written in the rest of the document.
5. In Figure 5, the number in the subscripts should not be in italic.
6. In Figure 6 :
- N should be in italic, since it is a variable.
- Usually, the three dots indicating replications are filled dots.
- The number in the subscripts should not be in italic.
- * should not be used for multiplication. ×, ·, space or nothing should be used. See http://www.bipm.org/en/publications/si-brochure/section5-3-6.html
7. In Figure 7 :
- N should be in italic, since it is a variable.
- SF should be in italic, since it is a variable.
- * should not be used for multiplication.
- The number in the subscripts should not be in italic.
- Usually, the three dots indicating replications are filled dots.
8. In Figure 8 :
- We can see uint8 and UINT8. It should be uint8 everywhere.
- Usually, the three dots indicating replications are filled dots.
Refer to Comment Reference 3
7 2017-09-24 11:52:35 Administrative Standard Document Object : figures
The caption of the figures sometimes uses uppercase for every word (Figures 1, 2, 5, 6), and sometimes not (Figures 3, 4, 7, 8). The caption of the tables does not uppercase every word.
Therefore, the caption of Figures 1, 2, 5 and 6 could be un-uppercased.
Refer to Comment Reference 3
8 2017-09-24 11:58:59 Administrative Standard Document Object : tables
1. Some table numbers are incorrect (although appearing correctly in the list of tables) :
- Page 18, Table 10 is named Table 1011.
- Page 20, Table 11 is named Table 1213.
- Page 20, Table 12 is named Table 14.
- Page 21, Table 13 is named Table 1516.
- Later tables have shifted numbers (17 instead of 14, 18 instead of 15, ...).
2. The column width varies from one table to another one, and the width is not always coherent. For example in Table 2, the width of the Attribute column is unnecessary big, whereas the Description and Default columns are too small.
Therefore, the column width could be harmonized and made consistent for all the tables.
3. The font size of table captions is bigger than the font size of figure captions. Usually they are the same.
4. The quote signs are not coherent within all the tables, they should be harmonized :
- In Table 1, “” are used.
- In Table 5, both “” and "" are used.
- In Table 6, “” are used.
- In Table 7, both “” and "" are used.
- In Table 8, “” are used.
- In Table 9, “” are used.
- In Table 10, both “” and "" are used. They are even mixed on the last column : “None".
- In Table 18, “” are used.
- In Table 20, “” are used.
5. In Table 2, in the Attribute column, last rows, Campaign and Scenario start with an uppercase whereas the others start with a lowercase.
6. In Table 3, in the Description column, first row, there is a period at the end, whereas the others do not have.
7. In Table 5, in the Description column, first row, "cluster that this..." should start with an uppercase.
8. In Table 6 :
- In the Attribute column, last row, bandwidth is bottom aligned instead of top aligned.
- In the Description column, penultimate row, there is a period at the end, whereas the other do not have.
9. In Table 7 :
- In the Description column, bits can be replaced by bit (there is no need to use the plural when giving the unit of a quantity)
- in the Enumeration column, the single quotes around 'n' have different styles.
- in the Enumeration column, replacing "signifies" by "means" may allow winning one line.
- There is an empty line in the rows ratefactor and alignment.
10. In Table 8, compliment should be replaced by complement (two times).
11. In Table 9, in the Description column, for both rows, there is a period at the end, whereas there is no period in the other tables.
12. In Table 1011 :
- In the Required column, last row, yes should be replaced by Yes.
- In the Enumeration column, second row, (Corresponds ... should not start with an uppercase.
13. In Table 1213, in the Attribute column, Sizeheader. should be replaced by sizeheader (lowercase and no period at the end).
14. In Table 1516, in the Description column, first row, the ? at the end is strange.
15. In Tables 18 and 19, in the Description column, the unit must be indicated for lat, lon and height. Even if it is relatively obvious that it should be degree and meter, a standard document must not leave any ambiguity.
16. In Table 20 :
- In the Description column, first row, there is a period at the end, whereas there is no period in the other tables.
- In the Description column, second row, to be more professional and specific, (0,360) could be replaced by (range : [0,360[)
- In the Class column, second row, x should be replaced by ×.
17. In Table 24, a row is missing for the binary 11111.
Refer to Comment Reference 3
9 2017-09-24 12:24:30 Administrative Standard Document Object : typos and formatting
1. Page 8, Section 4.5, second line : "MB/sec" should be replaced by MB/s, because the unit symbol of the second is s, not sec. This is a very common mistake, it is thus very important that a standard document does not propagate it. See the details here : http://www.bipm.org/en/publications/si-brochure/section5-1.html ("It is not permissible to use abbreviations for unit symbols or unit names, such as sec (for either s or second). The use of the correct symbols for SI units ... is mandatory.")
2. Page 11, line 2 : One after the colon starts with an uppercase, whereas on lines 3 and 4, it's a lowercase.
3. Page 11, paragraph before Table 1, it is written "Table 1describes the attributes". A space is missing between 1 and describes.
4. Page 14, Section 6.2.5, lines 6 to 8, F_RF, F_IF, F_RF+dF should be written in italic since they are math symbols.
5. Page 17, second paragraph, first line, ts=1/fs and N should be written in italic since they are math symbols.
6. In the examples given in Sections 6.3.3, 6.3.4, and 6.3.5, the quotes symbols such as in "format = ”Hz”" are incorrect, they are both closing quotes.
7. Page 22, Section 6.3.3, penultimate line, 1227600000Hz should be written 1 227 600 000 Hz. Indeed, the SI recommend to group digits by groups of three, and there is always a space between a quantity and a unit symbol. See : http://www.bipm.org/en/publications/si-brochure/section5-3-3.html and http://www.bipm.org/en/publications/si-brochure/section5-3-4.html.
8. Page 22, Section 6.3.3, last line, 1.2276GHz should be written 1.2276 GHz.
9. Page 22, Section 6.3.4, first line : it is written "Units include ns, us, ms, sec". However, the symbol for microsecond is µs, and the symbol for second is s. These are common mistakes and it is important that a standard document does not propagate them. See http://www.bipm.org/en/publications/si-brochure/section5-1.html.
10. Page 24, Section 6.3.7, second line, [3 x 1] should be replaced by [3 × 1]. x should not be used as product symbol.
11. Page 25 , second line, in 'encoding', the quotes have different styles.
12. In the title of Sections 6.2.4 and 6.2.12, Object start with an uppercase, whereas on all the other titles of this section, object does not have an uppercase.
Refer to Comment Reference 3
10 2017-09-24 12:39:06 Administrative Standard Document Object : tables
1. In Table 9, in the Required column, required is bottom aligned instead of top aligned.
2. In Table 17, in the penultimate column, Requires is written instead of Required.
Refer to Comment Reference 3
11 2017-09-24 12:41:39 Administrative Standard Document Object : PDF document
1. Currently the table of contents, the list of figures, and the list of tables do not have dynamic links. It would be good to add this, this is a big advantage of digital documents.
2. The PDF file has no bookmarks. Bookmarks are quite useful to navigate within documents. If the document has been produced by Microsoft Word, here are the guidelines to create automatically bookmarks in the PDF from the headers : https://superuser.com/questions/95222/from-word-to-pdf-including-bookmarks
3. Maybe the list of figures and the list of tables could be put on the same page, to have a shorter document.
Refer to Comment Reference 3
12 2017-09-24 13:21:21 Substantive Standard Document Object : Definition of string class
In the tables describing the classes, the string class is included, but it is not clearly defined. Is it ASCII ? UTF-8 ?
Since this is a standard document, no ambiguity should be left, and thus the format of the strings should be clearly indicated.
If the format considered is ASCII, then I find personally that it would not be a very international standard. Not being able to use accent or other letters than Latin ones in 2017 is a pity.
Refer to Comment Reference 3
13 2017-09-24 13:32:12 Substantive Standard Document Object : Class enumerator
In some tables (e.g. 5, 7...), a class enumerate is mentioned. However, these parameters are string, with a limited choice of possibility.
It is not clearly specified that these enumerated values are string. Even if one may think they should be strings because of the "" in the Enumerate column, it is not clearly written, whereas a standard should not leave any ambiguity.
Moreover :
- enumerate is not a class itself, because the enumerated values can take different values, as shown in Table 5 or 1011.
- In Table 1011, the sizeword has a limited choice of possibility too, however the class is uint8_t. This makes sense for me, but this is inconsistent with the other parameters enumerated.
- In Table 18, the parameter datum is a string with limited choice, and the class indicated is string.
- In Table 20, the parameter type is a string with limited choice, and the class indicated is enumeration.
In conclusion, there is currently an incoherency regarding the parameters with limited choices. I think the class enumerator should be removed from the document, and the class that should appear should be the actual type of what the parameter, i.e. uint8_t or string here. This would leave no ambiguity and would be coherent.
Refer to Comment Reference 3
14 2017-09-24 13:36:00 Substantive Standard Document Object : datum
In Table 18, the only datum enumerated is WGS-84 ?
What about other datum, such as NZ-90, GTRF ?
I guess this list should be completed (I am not a specialist about all the formats used, but they are surely others that are widely used).
Support for additional datum types may be useful for inclusion in the standard. However, it has been decided to wait for sufficient adoption of the first version of the standard before this enhanced capability is considered. The working group has noted the inclusion of additional datum types to be taken under consideration for the next formal revision of the standard.
15 2017-09-24 22:32:50 Proposal Standard Document The document text and image formatting is not consistent. Figure quality and font type/size varies throughout. It might be better not to require the use of proprietary software (Microsoft Word). Use LaTeX and TikZ for writing/generating the standard document and associated figures. LaTeX and TikZ would allow the use of consistent font across the text and images, it would ensure vector graphics. The use of LaTeX and TikZ has been evaluated by this committee after the comment was received. While is true that with LaTeX and TikZ would allow the use of a consistent font across text and images, it has been decided to continue using Microsoft Word for the time being. The issue regarding the inconsistency of the font in the text and images has been solved by updating the figures with a consistent font in the text. The changes are available in the latest version of the standard in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
16 2017-10-04 09:27:42 Proposal Standard Document In the attribute tables the "undefined" value can be assigned. It may be redundant because if the parameter is not defined, this value will be anyway assigned to the attribute. In addition, in the starndard document, when the "undefined" value is given, it is not defined which value is in fact assigned in the software. This can be a problem, mainly with the attributes wordshift (chunk attribute), and alignment and shift (stream attributes). If these three attributes are not correctly defined, it will lead to a wrog reading of the samples. I suggest to remove the "undefined" value option from the attribute tables. Also it might be interesting to throw an exception if the parameters have an "undefined" value or if they are not defined. The ION GNSS SDR Metadata Standard Working Group have discussed this comment with interest. This point will be addressed in future revisions of the standard document.
17 2017-10-04 14:01:37 Proposal Other I would like to comment on how to best handle floating point values from the conversion tool. Right now the tool provides a direct conversion of the integer based value to floating point (128=128.0). I would suggest considering normalizing these to [-1,1] for floating point values. So for example if an 8 bit integer value is used as the input, divide the result by 128 to get the normalized value.
As an additional note, should floating point values be allowed on the input side? I'm not aware of any current device that does this but it might be nice to have something in the standard for "future proofing".
While I haven't found any standard for floating point samples, it appears to be at least the defacto standard Ettus and GNU Radio are using. The ION GNSS SDR Metadata Standard Working Group have discussed this comment with interest. To address your comment, a new optional function has been included to the API. When this new function, SetNormalize(), is selected, the output scale is normalized on the interval of +/- 1.0. It can only be used when the output type is float or double. This option does not incorporate an AGC so the scaling is w.r.t. the minimum and maximum values that the packed data can support. For example, if samples are packed to 4-bit in two's compliment or two's compliment adjusted format, then the scale-factor used for normalization would be 1/8 (i.e., all samples are divided by 8 during the cast to float/double). python
18 2017-10-04 20:08:39 Substantive Standard Document Please be explicit when you call out "double" as a number format, whether you mean exponential notation only or also allow fixed-point notation. For example, on pg. 23 in "6.3.5 Position", double is shown in fixed-point notation, i.e., latitude = 48.17154012. On pg. 22, in "6.3.3 Frequency", double is shown in exponential notation, i.e., center frequency = 1227600000e+000. However, Frequency also could be specified as "a ratio of the form 'xxxx.yyyy' where frequency = xxxx/yyyy". In this case, if the intent was to specify Frequency as a fixed-point value, such as 1575.000, then this might be interpreted as a ratio, i.e., 1575/000 - which not only is wrong but could cause a divide-by-zero error. All numeric data shall in fixed-point or exponential notation unless accompanied by a "ratio" modifier in the parameter definition, e.g., <centerfreq format="MHz">1575.42</centerfreq> At the present the provided API can support three types of formats when reading frequency foundation class from the XML-based configuration file: fixed point double number format, exponential format, and ratio format. In essence, the API will read these formats as a string and will convert them into double. Afterwards, within the code, the corresponding parameters will be handled as a double type parameter. Considering the way the API has been developed, there will be no problem to handle any of the three types of formats, and the divide-by-zero error is also handled. The changes are available in the latest version of the standard document, which can be found in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation
Python, MATLAB
19 2017-10-04 20:10:34 Substantive Standard Document Please be explicit, in "6.3.5 Position" and "6.3.6 Origin" - latitude and longitude are in decimal degrees, latitude range -90 to +90 and longitude range -180 to +180, and height is in meters (with respect to the datum for Position and with respect to the parent reference frame for Origin). Latitude and longitude shall be in decimal degrees, with latitude range from -90 to +90 and longitude range from -180 to +180. Height shall be in meters, with respect to the datum for Position and with respect to the parent reference frame for Origin. The Latitude and Longitude files have been updated in the standard document and the limits of these parameters have been set. Also it has been specified that the height must be written in meters. This changes are available in the latest version of the standard document in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
Python, MATLAB
20 2017-10-04 20:11:51 Administrative Standard Document Can the time interval specified by pg. 22 "6.3.4 Duration" be negative? The only place the "Duration" class seems to be used is in the "delaybias" attribute in the Band object - could this bias (with respect to 'toa') be negative for a band? The attribute “delaybias” is a double type parameter, which means that the value can be both positive and negative. This has been specified in the latest version of the standard document, which can be found in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
Python, MATLAB
21 2017-10-04 20:12:46 Substantive Standard Document On pg. 24 in "6.3.7 Orientation", you have Euler angles, but not which rotation sequence nor whether extrinsic or intrinsic axes.
Also, support for direction cosine matrix and quaternions might be useful.
As suggested, a default rotation sequence and the intrinsic axes have been defined. The standard now follows by default the 3-2-1 intrinsic Tait-Bryan angles, also known as yaw, pitch, and roll sequence. This has been specified in the latest version of the standard document, in the section “6.3.7 Orientation”. The document can be found in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
Python, MATLAB
22 2017-10-09 05:24:20 Critical Other First of all, great standard!
However, here is my comment:
The markup language XML is overly complex. Due to that, it is not easy to read, difficult to parse (even though there are some implemented parser already) and error prone (e.g. what should be an attribute and what should be a value of a node?)
There are three other markup languages, that come to my mind, that would be a good replacement: JSON, YAML, TOML JSON:
+ easy to read
+ easy to parse
+ widely used
+ a lot of already implemented parser (even MATLAB has a native implementation)
- does not allow for comments
YAML:
+ easy to read
+ widely used
+ a lot of already implemented parser (However, there is none for MATLAB)
+ allows comments
- Difficult to parse
TOML:
+ easy to read
+ easy to parse
+ some implemented parser
+ allows comments
- not so widely used, yet (It is relative new)
https://github.com/toml-lang/toml
With all those markup languages, it would also be much easier to write any sort of vector or matrices than in XML.
The ION GNSS SDR Metadata Standard Working Group have discussed this comment and determined that for the moment the XML format will be maintained. The parser of the XML files that follow the standard is included within the provided API in the Github repository. The link to the Github repository can also be found at http://sdr.ion.org/api-sample-data.html. The link to the API is as follows: https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master. The use of other markup languages will be considered for future revisions of the standard based on community need and interest. N/A
23 2017-10-16 11:53:37 Proposal Other Hello,
A suggestion for "a nice to have" feature on the website:
The capability to generate the metadata XML file via a web form.
The webform can be generated dynamically from the metadata.xsd, e.g. https://github.com/MichielCM/xsd2html2xml
An example of xsd2html:
https://htmlpreview.github.io/?https://github.com/MichielCM/xsd2html2xml/blob/master/examples/complex-sample/form.html
The suggested capability has been evaluated with interest by the chairs of the working group. Adding a webpage that generates a standard-compliant metadata file based on manual user input on a web form is an excellent idea and has also been previously brought up by members of our working group. Thank you for pointing us to the open source software projects that could be used to implement this capability. We will bring this up at the next working group meeting held in conjunction with the ION GNSS+ meeting in September 2018. Since this standard development work is being done on a voluntary basis, we hope to find one or more members from the community to help us implement this capability.
24 2017-10-26 08:21:58 Proposal Standard Document The standards document has good graphical examples of how lumps and chunks can be organized. The same should be done for chunks in a block, blocks in a lane and lanes in a file.
(It would also help to enable the bug tracker on github).
Graphical representation is easier to get a basic understanding than formal text. The ION GNSS SDR Metadata Standard Working Group have discussed your comment and decided that it will be really helpful for the users. In the new revision three new figures have been included in the standard document to represent the encoding of the chunks within a block, the blocks within a lane, and the lanes within a file. The three new figures can be found in the following sections:
· 6.2.9 Block object
· 6.2.10 Lane object
· 6.2.11 File object
This figures are available in the latest version of the standard document, which can be found in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
Python I'm already using the code. Proper usage of C++11 would be nice. No
25 2017-11-03 12:23:41 Substantive Standard Document the document says position is specified with respect to the Geoid. I think you mean ellipsoid, the geoid is the irregular surface defined by the earth's gravity field/mean sea level. GNSS coordinate systems are all ellipsoidal. Change geoid to ellipsoid GNSS positioning is done in ellipsoidal coordinates rather on the geoid. They can be different by more than 100 m in height and there's no efficient way to convert between the two. The comment have been addressed and the modification has been done, the position now is given in ellipsoid coordinates. This modification can be seen in the latest version of the standard document, available in the following URL: https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
26 2017-11-09 08:04:56 Critical Standard Document Figure 3 shows the UML diagram for the metadata. It says a lane has 0 or 1 sessions and a session has an arbitrary amount of systems. This can't work as the system defines the base frequency for the lane. A lane must be associated with exactly one system. If there are multiple systems per lane the association is not unique. The suggested comments have been implemented in the latest revision of the standard document. The explanation of the UML diagram has been added. Further, support for floating point format has been added. These revisions are reflected in the latest version of the standard, which is available in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
No
27 2017-12-06 14:52:59 Proposal Standard Document Add floating point sample representation Include in table 8 an IEEE floating point format which can be used for 32 or 64 bit samples. Provide for the GNU Radio floating point format and a possible future double precision version IEEE 754 32-bit and 64-bit floating point support for sample representation has been added. This update is available in the latest revision of the standard document, which can be found in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
Yes
28 2017-12-06 14:55:17 Proposal Standard Document Add ECEF coordinates option In the position attributes in table 18 allow initial position to be expressed in LLH or Cartesian ECEF format. Allow the ECEF format to be used for initial position The ION GNSS SDR Metadata Standard Working Group have discussed your comments. Specifying 3D position in ECEF format in addition to LLH is scheduled to be added in the next revision of the standard. This is identified in Appendix II: Future Extensions in the current version of the document. Yes
29 2017-12-06 14:57:00 Proposal Standard Document Add initial platform velocity Change: Add a velocity foundation class attribute expressed in Cartesian ECEF format. Allow possible initial dynamics to be known for receiver acquisition. The ION GNSS SDR Metadata Standard Working Group has discussed your comment. The idea of introducing the initial platform velocity has been determined to be useful and hence it has been decided to be included in a future revision of the standard. This is identified in Appendix II: Future Extensions in the current version of the document. Yes
30 2017-12-06 14:58:53 Proposal Standard Document Sample rate frequency error In table 7 add a known sample rate frequency error in ppm (parts per million) or sec/sec format. Allow possible large sample frequency errors to be known for receiver acquisition The ION GNSS SDR Metadata Standard Working Group has discussed your comment. Specifying sample rate frequency error is scheduled to be added in the next revision of the standard. This is identified in Appendix II: Future Extensions in the current version of the document. Yes
31 2017-12-28 12:40:45 Critical Exemplary C++ Code I have been testing the code with some sample files with a chunk of 4 streams. Each stream is composed of 2 bits each and the inverse SMA encoding (i.e., instead of using the bit one for the sign and the bit zero for the magnitude, it uses the bit one for the magnitude and the bit zero for the sign).
For that I checked the different "shift" attribute values and combinations of the different "shift" attributes, but I had not been able to make the test file work. By hard-coding it I got successful in the testing of the file.
A new attribute should be added to the standard to indicate this bit inversion at the stream level. The comment has successfully been addressed. Two new encoding formats have been added to Table 8, MS (Magnitude-Sign) and MSA (Magnitude-Sign Adjusted). With this two new formats, there is no need to add a new parameter that would flip the order of the samples, and it gives a solution to your comment in a very simple way. This update is available in the latest revision of the standard document, which can be found in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
32 2017-12-29 13:08:43 Proposal Exemplary C++ Code As an SDR-based GNSS receiver developer, I'm relieved to know that a metadata standard format for raw GPS signals has been formulated.
The much needed standard would definitely ease identification of various data formats and conditions they were collected under. The fact that this document accommodates both hardware and software description is commendable.
The detailed description and explanation of the API architecture and classes will make it easy to incorporate it into our own software receiver. Plenty of examples using metadata standard have been published on the website which I think provide a good platform for reference.
I look forward to incorporating it into York University's very own software GNSS receiver.
I do notice however that the C++ files are collectively large (size-wise) and might not be suitable for an FPGA platform/microprocessor.
Suggestion - Make the files more compact
This can be either done
- By allowing the user to choose which files/details they want to keep/discard
- By optimising the code
- By using a lower-level language
York University is building a software GNSS receiver for satellite applications and hence the memory available on board is very limited. For the standard to occupy a significant amount of memory might be a hindrance.
I was hoping the on-board processor can be capable of sorting data according to the metdata standard but for now it seems like that can be carried out only by a computer.
The ION GNSS SDR Metadata Standard Working Group have discussed your comment and have decided that the code optimization will be done incrementally in future revisions of the normative reference software that is being developed in conjunction with the standard. C Yes
33 2017-12-31 12:29:54 Substantive Standard Document From Figure 1 I'm not sure if it supports single antenna, multi-band, multi-file (Figures a to d imply not, but g implies it might) Clarify whether Figure 1 g supports this Used on GNSS Rf Recorders/Replayers such as Spirent GSS6450 The group have addressed your comment in the latest release of the standard document in the section 4.2. The recording system will always depend in the SDR that has been used and not in the standard (i.e. the standard does not impose a particular data format). The document was revised to clarify that the recording of several bands with a single antenna may also be written in several files by the SDR, as depicted Figure 1.b. This is available in the latest revision of the standard document, which can be found in the following URL:
https://github.com/IonMetadataWorkingGroup/GNSS-Metadata-Standard/tree/master/Specifications/documentation.
N/A