It’s an interesting and perhaps unanswerable question, whether governments ever truly listen to the voice of the people, and act accordingly. That premise gets another test in a GNSS setting, in Hawaii next month. An April 26 full-day session of the International Committee on GNSS (ICG) Interoperability Workshop will give those who design and build GNSS receivers a forum to offer their best advice to signal providers — BeiDou, Galileo, GLONASS, GPS, QZSS, and IRNSS are mentioned, as well as unspecified others — about how to achieve optimum interoperability benefits for their customers. “ Providers who have not finally decided on new signals will greatly appreciate your recommendations,” according to session organizer Tom Stansell, acting under the auspices of the ICG Working Group on GNSS Compatibility and Interoperability (WG-A).
The questions that candidate speakers are asked to address (given further on in this column) read like a primer on modern signal design, and suggest the complexity of issues dealt with at this very high technical level. The depth and level of detail at which the session organizers seek input reveal — what? That such issues are truly not yet determined by U.S., Chinese, Russian, and European system operators? This is impossible to know, outside government circles, and could easily be doubted by cynical minds. Yet the organization of such a workshop hints that at least some, if not many, such delicate matters remain in flux and under discussion.
The organizers seek three speakers each in four main topic areas. They emphasize that they are trying to involve only those who design GNSS receivers, not users, service providers, or product integrators.
High-Precision Code is for products with sub-decimeter accuracy that use wide area correction signals such as from OmniSTAR or StarFire.
High-Precision Phase is for products with sub-cm accuracy that use terrestrial correction signals to resolve carrier phase ambiguities.
Medium Precision is for products with sub-50 cm accuracy, which often are single-frequency receivers using local correction signals.
Consumer Applications are for chipsets embedded in consumer products.
If you want to participate, in person, by Internet, or by recorded PowerPoint presentation, you can contact the workshop organizers via GPS World magazine, by emailing firstname.lastname@example.org. Please indicate the topic that best fits your presentation. If you are not selected to speak, you are welcome to submit a paper or presentation that will be given to each signal provider.
Specific questions that candidate speakers are asked to address include:
Supported applications: What types of applications do your receivers (or receiver designs) support?
Increase in noise floor: Do you see a threat to GNSS receivers due to many more GNSS signals centered at 1575.42 MHz?
Whether you see a threat or not, do you prefer all new CDMA signals at L1 to be centered at 1575.42 MHz, or have some of them elsewhere, e.g., at 1602 MHz?
Given that most GNSS providers plan to eventually transmit a modernized signal at 1575.42 MHz, what is your long-term perspective on whether you will continue to use C/A? Why and How?
CDMA and FDMA: Once there are a large number of good CDMA signals, will there be continuing commercial interest in FDMA signals? Why or why not?
Compatibility: Do you prefer signals in different L1 frequency bands for interference mitigation rather than at one center frequency for interoperability? Why?
What to do about misbehaving signals: If a satellite’s signals do not meet quality standards, should they:
- Be set unhealthy?
- Transmit with a nonstandard code?
- Transmit with reduced signal power (reduce interference)?
- Be switched off?
- What combination of the above?
To assure only good signals, should GNSS providers agree on minimum international signal quality standards and agree to provide only signals meeting the standard?
E5a and E5b: Given that L5/E5a will be transmitted by most GNSS providers, do you intend to use the E5b signal? If so, for what purpose?
Frequency steps: For your applications, are small satellite frequency steps (Δf) a problem?
If so, what interval between frequency steps and what Δf magnitude would be excessive?
Interoperable use: Assuming signal quality is acceptable from every provider, would you limit the number signals used by provider or by other criteria? What criteria?
Is having more signals inherently better or do you think there should be a limit?
Will the marketplace force you to make use of every available signal?
For best interoperability, how important is a common center frequency? How important is a common signal spectrum?
Another common open-service signal: Will you provide tri-lane capability in the future? Why?
If so, do you prefer a common middle frequency or the combined use of L2 (1227.6), B3 (1268.52), and E6 (1278.75) if B3 and E6 open access is available?
Would you prefer a common open signal in S Band? In C Band? Why?
Precision code measurements: Does a wider satellite transmitter bandwidth help with multipath mitigation?
What minimum transmitter bandwidth would you recommend for future GNSS signals in order to achieve optimum code precision measurements?
Added GNSS or SBAS messages: Would you recommend GNSS or SBAS services provide interoperability parameters:
- System clock offsets
- Geodesy offsets
- ARAIM parameters
Should they be provided by other means so as not to compromise TTFF or other navigation capabilities?
Signal coherence: For your applications and for each signal, what amount of drift between code and carrier over what time frame would be excessive?
For your applications and for two or more signals in different frequency bands, e.g., L1 and L5 (when scaled properly), what amount of relative drift in code and carrier between the signals would be excessive?
Spectrum protection: Should the international community strive to protect all GNSS signal bands from terrestrial signal interference?
System geodesy: Do the current differences (~10 cm) in geodesy pose a problem for your users? Why or why not?
If geodesy differences are a problem, what is the preferred method of compensation:
- Published values (e.g., on websites)
- Satellite messages
System time: Do you want each system to cross-reference the other’s time (e.g., with a GGTO type of message) or compare itself to a common international GNSS ensemble time? To what precision?
Will your future receivers calculate a time offset between systems based on signal measurements or use only external time offset data?
What is the preferred method of receiving time offsets: Satellite messages, Internet messages, or internally calculated?
Further information and background on the April 26 session can be downloaded at http://www.mediafire.com/?cegvqb9l8ya1c.
The timed agenda for the April 26 meeting follows, showing both Hawaii Standard Time (HST) and Coordinated Universal Time (UTC), provided because some presenters will speak from remote locations using GoToMeeting over the Internet. Another option for presenters is to provide a PowerPoint file with embedded audio.
HST/UTC Topic Presenter
9:00/19:00 Welcome and Introduction Working Group Co-Chairs
9:25/19:25 Welcome and Introduction Xiaochun Lu
9:35/19:35 Framing the Presentations Tom Stansell
9:50/19:50 Certified Avionics TBD
10:15/20:15 High Precision Code #1 TBD
10:5520:55 High Precision Code #2 TBD
11:20/21:20 High Precision Code #3 TBD
11:45/21:45 High Precision Phase #1 TBD
12:10/22:10 High Precision Phase #2 TBD
13:35/23:35 High Precision Phase #3 TBD
14:00/0:00 Medium Precision (~GIS) #1 TBD
14:25/0:25 Medium Precision (~GIS) #2 TBD
14:50/0:50 Medium Precision (~GIS) #3 TBD
15:30/1:30 Consumer Applications #1 TBD
15:55/1:55 Consumer Applications #2 TBD
16:20/2:20 Consumer Applications #3 TBD
16:45/2:45 Summary Tom Stansell
16:55/2:55 Summary Xiaochun Lu
17:05/3:05 Conclusion Working Group Co-Chairs