GNSS Receiver Required Features and Options

Observables

• We require a multi-frequency GNSS (Global Navigation Satellite System) receiver able to simultaneously track all openly available signals, on all available frequencies, from all satellites in view, for the following GNSS: GPS, GLONASS, and SBAS. The capability to track and log all other GNSS, such as Galileo and BeiDou, and the regional QZSS and IRNSS signals, is desired.

• Unsmoothed pseudo-range, signal-to-noise, Doppler, and carrier phase observables must be recoverable from the receiver. The ability to purchase receivers with specific constellation tracking disabled (i.e. GPS-only or GPS-GLONASS only) at a reduced price is also of interest.

• Receiver must provide a sample rate of 10 Hz or higher (pseudo range, carrier phase, signal-to-noise).

• Receiver must be able to simultaneously track all openly available signals on all in-view satellites, even if the SV is unhealthy, to an elevation angle of 0°. Receivers must allow simultaneous logging of multiple sessions with different length files at 15 samples/sec and 10 Hz sampling rates and must allow real-time streaming of 1 Hz observables.

• L1, L2, and L5 SNR in dB*Hz referenced to a 1 Hz (or better) bandwidth SNR (amplitude) discretization should be better than 0.5% of full scale. Signal to noise observations should be measured and stored at a resolution of 0.1 dB*Hz or better. The phase observations should be measured and stored at a resolution of 0.001 cycle or better.

Pseudo-range observations should be measured and stored at a resolution of 0.001 meter or better.

Input accepted and output produced

• The receiver must provide optional on-board (or in-the-box) Precise Point Positioning with Ambiguity Resolution (PPP-AR). The USGS strongly prefers to pay a one-time fee for this capability, rather than annual per unit and recurring fees for the necessary clock and orbit corrections stream needed for PPP-AR processing.

• Receiver is required to provide an “archival quality” stream protocol in BINEX format.

• Receiver must output 1 PPS with 5 ns or better timing accuracy and RTCM SC104 version 3.0 base station corrections.

• Receiver must support the input and output of MET, tilt, or accelerometer measurements:

a) As a serial/IP pipe using an NMEA string or in documented Vendors format and b) Recorded in receiver data file in BINEX format. Receiver must be capable of logging 8 independent sessions, each with multiple formats; the logging shall be independent of the GNSS satellite tracking and at user-selected intervals (e.g., every 5 minutes).

File formats

• Receiver must be capable of producing data streams and downloadable logged data files in BINEX format, containing all GNSS observables, navigation messages, attached MET, tilt, and other ancillary serial devices, site metadata, and system status records. Minimum requirement is BINEX 0x7f---05 with support for all GNSS observables, 0x00 for metadata and comments, and 0x01 for GNSS navigation messages. BINEX 0x7d for receiver state information is preferred but not required.

• Receiver must be capable of producing data streams in RTCM3 format with support for IGS standard Multi-System Messages (MSM), using the protocols noted above.

• Full support for translation of data files to RINEX v3.02 format must be provided. This may be either onboard the receiver, in which case a data file is written in RINEX v3.02 format or files are translated on-the-fly when downloaded by a user, or in the form of software that will convert a native binary to RINEX v3.02 after downloading. All software executables must be compatible with LINUX operating systems.

• RINEX output must be compatible with teqc and include all available observables including L1, L2, and L5 SNR as described above.

• Proprietary (manufacturer’s) data formats used in data streams and logged files must be thoroughly documented so that USGS can update software to translate all pertinent contents and messages, including metadata. Modifications to proprietary formats that occur within the lifetime of the equipment must be documented and made available to USGS at the time of firmware release.

File storage and memory

• Receiver must have a minimum of 16 Gb of industrial-grade internal memory.

• Receiver must stream and log to internal memory the GNSS observables at 10 Hz or greater. Streaming and logging rates must be configurable to 10Hz, 5Hz, 1 Hz, and 5, 10, 15, 30, 60, and 300 sec intervals.

• Receiver must provide internal data logging (with capacity equivalent to a minimum of 3 months at 10 Hz) or properly functioning continuous data streaming to external memory.

• Data storage for each logging session must be independently managed in partitions of user-configurable size using ring buffers or memory pools (i.e. automatic deletion of older data files will occur while newer files of lower sample rates are preserved). The option to stop logging a particular session when its memory pool has reached designated capacity instead of overwriting older files is required.

• The receiver shall support a user-specified data directory structure that allows for: 1) separate directories for each calendar month; 2) user-specified naming of the directories;

and 3) user-specified structure of the directories. At a minimum, each data logging session should be stored in a unique directory. This is critical in order to facilitate data flow strategies that commonly involve directory content queries.

• File names must include either the ordinal date (e.g. YYYYDDD) or the Gregorian date (e.g. YYYYMMDD) from the time of creation of the file. A user-specified station name must also be included in the file name or must default to some known token such as the receiver serial number or some portion thereof. File names must also include characters to distinguish when multiple files are created on the same day.

Interaction with receiver

• A command-line API for uploading and application of receiver configuration files and firmware updates is required over TCP/IP and serial interfaces.

• A command-line API for gathering receiver state of health (e.g. temperature, voltage, and uptime) is required.

• Receiver must allow enabling or disabling any vendor defined code and carrier multipath rejection technology using a serial/IP command. In addition, vendor should provide a list of other features capable of being modified by serial/IP command, such as switching between satellite and IP acquired clock and orbit corrections, opening or limiting RF bandwidth on the front-end, and any other functions modifiable through serial/IP commands.

• The ability to save the configuration of the receiver in a downloadable file and upload it to other receivers remotely is required. Configuration files should have the option of retaining network IP configuration or applying new user-specified IP settings.

• Network firewall or IP filtering scheme to protect the receiver from on-line attacks or unwanted access is required.

• User-accessible activity log files are required to aid in system troubleshooting that records system reboots, boot sequences, voltages, low voltage shutdown activity, temperature and shutdown sequences. The log file directory must be able to record the last 180 days of activity.

• Receiver must support FTP Push, Anonymous FTP support, Rsync, and SFTP (SSH) Support as well as FTP (TCP port configurable, REST support, MDTM support, Delete support).

• Streaming protocols supported should include TCP/IP, UDP, and NTRIP.

• Wifi that can be enabled/disabled externally (without logging into the receiver)

• Web browser interface (http/https) for interacting with the receiver

• Web interface should be configurable for use in a low-bandwidth environment.

• Receiver must be capable of differencing logged files and transferring only missing data segments rather than full files to minimize bandwidth usage.

• In order to facilitate the use of GNSS data in earthquake early warning, it is desired that the receiver output the real-time data stream in either GeoJSON or tracebuf2 formats or both.

• Receiver interface should include a spectrum analyzer tool available for diagnosing interference.

Ports

• Receiver must have at least 1 USB 2.0 (or better) and at least 2 serial ports with standard DB9 connector or 2 serial ports with custom connector and connector to DB9 cable.

• Receiver must have 2 power ports (one standard power input and one for battery backup) with power port logic.

• Receiver must have 1 Ethernet enabled port allowing for TCP/IP configuration of all receiver features, data files, and data streams. Port does not have to be in same enclosure as GNSS receiver. If it is an external serial to Ethernet adapter, the receiver must have a total of 3 serial ports.

• Receiver must have serial port support for connection of at least 4 RS---232 meteorological devices, tilt meters, or other sensors (i.e. accelerometers) with data output integrated into both logged and streamed data. (4 ports, met support)

Power

• Maximum power consumption must be less than 5 watts with all available options utilized and must be capable of operating with less than 2 watts of power in a minimal configuration to preserve basic logging functions in situations where available power is extremely limited. These capabilities must be documented clearly in the proposal or product spec sheet. Receivers with lower power consumption are preferred.

• Receiver must automatically restart after loss of power and must power up in same configuration when powered down (or loss of power). The receiver must power-on at 11.85-12.0V and power off at 11.0-11.15V. Voltage range: Unit should operate properly if external DC voltage of greater than 10.8 and less than 28 volts is applied. Wider operational power specifications are preferred.

• User-programmable reboot timer or other “watchdog” system is required that provides for automated system restarts without active user interaction (i.e. auto restart following power interruption and showing power-on voltage).

• User-programmable low-voltage behavior customization

• On-board battery or UPS is not required, and if present, should be removable at user option or must include user- configurable settings to control the circumstances under which power is used to maintain its charge. If a battery backup is present, the receiver must function properly if it loses its ability to maintain a full or partial charge to the backup system.

Physical requirements

• Receiver must meet the following environmental specifications: Operating temperature: - 40° C - + 65° C, IP Rating IP65 minimum. Preference for fully sealed IP68 and MIL- STD-810G shock rating (to survive a ~1m drop onto a hard surface).

• The receivers Mean Time Between Failure (MTBF) must be at least 57,500 hours according to the Bellcore “Ground Benign” specifications (quantifies the anticipated failure rate and is an "industry standard").

• The receiver must be compatible with existing USGS GPS antennas, (Topcon CR-G3, Ashtech choke ring, Septentrio/Tallysman VeraChoke, Trimble choke ring, and Trimble Zephyr Geodetic I, II, and III antennas).

• The selected receiver must have demonstrably low susceptibility to radio frequency interference at the primary GNSS frequencies, as well as side-band frequencies used for on-board PPP processing, including when using an existing USGS antenna.

• Receiver must have USB, SATA, or other IEEE external housing (hardware failure protection).

• Receiver dimensions not to exceed 11” L x 7” W x 4” H (27.94 cm x 17.78 cm x 10.16 cm). Weight not to exceed 4.4 lbs (2 kg).

Accessories

• Price quotes should be provided for purchase of receiver both with and without a GNSS-capable antenna. Antenna model options should be compatible with all features of offered by the receiver (including but not limited to multi-frequency, multi-constellation GNSS;

onboard positioning; and multipath/radio frequency interference reduction) and be suitable for permanent field deployments.

• System must include either a universal AC power supply or DC power cable with polarity indicated as requested at time or order.

• System must include one RS232 cable (receiver to DB9) and one Ethernet 10baseT cable (receiver port to RJ45)

Field Performance

• The specific receiver proposed by the vendor will have a minimum of one year service history exactly as built in the proposal. Equipment without at least one year of field deployment history will be rejected.

• Receiver performance will match or be better than performance of receivers tested by EarthScope for deployment as permanent stations for the Plate Boundary Observatory (https://kb.unavco.org/article/unavco-gnss-receiver-preferred-vendor-rfp-evaluation-report-830.html) o 1. Total Expected and Observed data—In the 90-10° elevation range receiver must have at least 99% observed to expected data with no more than 0.05% slips to observations. In the 10°- 5° elevation range receiver must have at least 90% observed to expected data with no more than 0.1% slips to observations. In the 5°- 0° elevation range receiver must have at least 30% observed to expected data with no more than 1.0% slips to observations.

o 2. MP1 and MP2 Tracking Statistics—In the elevation range 90-10°, 10°- 5° the receiver must have MP1 and MP2 values of less than 0.7 m. In the elevation range 5°- 0° the receiver must have MP1 and MP2 values of less than 1.0 m.

o 3. Observations per Slip—Over the elevation range 90°- 0° the receiver should have greater than 20,000 observations per slip (total number of observations recorded divided by the combined MP1/MP2 slips). In the 10°- 5° and 5°- 0° elevation ranges the receiver must have less than 1% IOD slips.

o 4. Carrier phase precision must be at < 1 mm L1 and L2 (zero difference) and < 3 mm L3 (zero difference) at 15 sec sampling. Non-smoothed Pseudo range precision < 30 cm on L1 and L2 (< 100 cm L3) at 15 sec sampling rate.

o 5. Short baseline (~2 m), 24-hour solution precision must be 0.2 mm or better in the north and east components and 0.4 mm or better in the vertical component for L1 and L2. Solution precision must be 0.4 mm or better in the north and east components and 0.8 mm or better in the vertical component.

o 6. Short baseline (~2 m) residual troposphere delay must be no larger than 1mm (based on tracking down to 0° elevation range).

Separately Priced Options and Recurring Costs:

• Strong preference will be given to proposals that include no ongoing costs for receiver options, error correction services, or firmware upgrades. Support of the product for the lifetime of the product is expected.

• Demonstration of the equipment’s ability to continue to track all signals through violent shaking, such as will occur during a large earthquake is desired. In the future, potential vendors may be required to report acceleration and jerk tolerances of their equipment acquired though repeatable “shake tests”.

• The capability for event-triggered data logging sessions (e.g. a high sampling rate session that would activate if an attached accelerometer detects strong ground motion at the site) is desired.

• On-board data compression is another capability that is very desirable. Smaller data files provide several benefits to USGS’s data flow operations. Vendor responses should clearly address tracking, logging, and streaming bandwidth and file size issues.