Frequently Asked Questions

Please reference this document to view more information.

SBAS provide orbit and clock corrections for the GPS satellites and an Ionospheric model. These were initially developed for civil aviation use to augment L1 Coarse Acquisition Code receivers, but have since been developed for alternate markets such as offshore and agriculture. Correctional data are transmitted on the GPS L1 frequency from Geo-stationary communication satellites. Examples include the Wide Area Augmentation System (WAAS) for USA and Puerto Rico, the European Geostationary Navigation Overlay Service (EGNOS) for Europe, the Multi-Function Satellite Augmentation System (MSAS) and the Satellite Navigation Augmentation System (SNAS) for China. Corrections can be received outside their network but should only be used within their designated operational area due to accuracy and reliability measures. All NavCom / Deere receivers are capable of receiving and using WAAS/EGNOS signals. NavCom has also developed a commercial SBAS system known as StarFire that is available globally and is more accurate.

SBAS signals can be seen from multiple satellites, with two dedicated channels, NavCom has the ability to lose lock on one and still track the other without a new search. Having dedicated channels means you never give up a GPS channel to access WAAS, EGNOS or other L1 based SBAS signal.

A global leap-second time change will occur at 0:00:00 on January 1^st. GNSS broadcast, reference, and rover systems need to apply this change at exactly the same moment in order to function properly. Unfortunately, GPS and GLONASS broadcasters handle the time change differently. More information is available at this link.

Here is how NavCom products are impacted:

• No software update for discontinued products. All discontinued products operate on GPS only and there is no performance impact as the GPS leap second functions correctly
  
  Multi-hertz NMEA data will have a 1-second timing change at the time of transition and will revert back 1-second to December 31, 23:59:59.x at the next fractional epoch reporting UTC time (i.e. for 10Hz data this will 59.1 seconds).

• Sapphire, SF-3040 and SF-3050 products
  • New software is available (v3.6.9 or later) which has a fix for the GLONASS leap second under most conditions as described below:
    • RTK
    • NavCom or 3rd –Party Base providing RTCM 3 (1001 to 1012msgs) and proprietary (x5B and 5E) formats operate correctly for GPS and GLONASS with the new firmware. RTCM 3 messages provide specific data related to the leap second event.
    • CMR/CMR+, RTCM 2.2, and 2.3 (Type 18/19 and 20/21) do NOT operate correctly for GLONASS. These public RTK correction protocols do not specifically address the leap second transition and are subject to each manufacturer’s interpretation of the transition. Internal testing demonstrates issues with a number of competitive receivers.
      • Customers need to turn GLONASS off prior (23:59:00 or earlier) to the UTC date change from 6/30 to 7/1. GLONASS may be turned on again after 00:00:01 UTC on July 1st. If after turning GLONASS on the receiver does not use GLONASS in RTK, cycle power to the receiver.
      • If the receiver is operated in GPS only mode, it is not impacted by the leap second change in any RTK format.
    • StarFire and SBAS modes are not impacted
  • Fielded software performance (v3.5.8)
    • RTK
      • Proprietary (x5B and 5E) formats operate correctly for GPS and GLONASS
      • With RTCM2.2/RTCM2.3/CMR/CMR+/RTCM3 the rover may lose GLONASS ambiguity for seconds or even longer.
        • Customers need to turn GLONASS off prior (23:59:00 or earlier) to the UTC date change from 6/30 to 7/1. GLONASS may be turned on again after 00:00:01 UTC on January 1st. If after turning GLONASS on the receiver does not use GLONASS in RTK, cycle power to the receiver.
        • If the customer is using both a NavCom base and rover and RTCM 3 (1001 to 1012) correction formats, rovers are expected to function correctly.
    • If the receiver is operated in GPS only mode, it is not impacted by the leap second change in any RTK format.
  • StarFire and SBAS modes are not impacted

Net 2 of the StarFire system underwent a frequency change in late 2014. No new software was made available at that time and customers with recent software realized an automatic transition to the new frequencies from the over-the-air StarFire almanac for current generation products (legacy products require manual tuning). The Net 1 frequencies take place in June 2015. Similarly, automatic transition to the new frequencies from the over-the-air StarFire almanac will take place. With all the new StarFire frequencies reassigned, new software (v3.5.4 or later) for current generation products contains an updated default frequency table (legacy products require manual tuning). Customer Support has produced a detailed Troubleshooting Guide for customer who choose to remain on older firmware. The old frequencies are scheduled to terminate in mid-July 2015.

StarFire is the World's first commercial Global Satellite Based Augmentation System (GSBAS). StarFire uses a global tracking network of approximately 60 reference stations and software developed by NavCom to calculate very precise and accurate real-time orbits and clocks for all the GPS and GLONASS satellites. These are transmitted via Geo-Stationary communication satellites to StarFire receivers who use the corrections with NavCom's geodetic quality multi-frequency engine measurements and proprietary StarFire positioning algorithm. Real-time positioning accuracy is typically a sub-decimeter horizontally and sub-two decimeters vertical. Performance may be better depending upon the local conditions and convergence period.

NavCom manufactures dual frequency GPS receivers. The GPS frequency measurements on both L1 and L2 allow the ionospheric errors to be corrected prior to navigation. This technique is much more accurate than using the WAAS or EGNOS ionospheric models. NavCom's rover positioning algorithm for StarFire has been adapted to work with WAAS and EGNOS corrections providing greatly enhanced positioning performance. NavCom has also implemented a patented method which allows for the repression of high-frequency noise associated with these types systems, named Refraction Corrected Phrase (RCP). In addition, NavCom's patented multi-path suppression and high quality of measurements result in superior position accuracy.

Upon power-up, a StarFire receiver initializes, locks on to the available GPS satellites, the local StarFire communication satellite and starts NavCom's proprietary StarFire positioning algorithm. Positioning accuracy will typically be sub-meter with decimeter accuracy performance available within 30-45 minutes. This is a function of the tropospheric conditions, number of GPS satellites available and inter channel calibration of the receiver.

NavCom offers the unique feature called QuickStart where an accurately known ITRF05 position can be used to initialize StarFire navigation and eliminate the convergence period. This is typically a position previously surveyed and converted to ITRF05 prior to initialization. For example, vehicular installations can be initialized using the last position from when it was parked and powered down

RTK Extend uses StarFire to provide RTK-quality positioning when the RTK communication link has been temporarily lost. This can mean greater survey efficiency by eliminating the need to stop the survey or relocate the RTK base station for better communication coverage.

A StarFire-licensed receiver with the RTK option enabled is equipped with an RTK communication link and placed in the 'RTK Extend Base' mode. Both RTK corrections and the offset between the StarFire and RTK solutions are transmitted to multiple roving StarFire receivers (the base will be navigating at the same time as it is computing corrections). When the RTK communication link is blocked at the StarFire rover, the unit initializes the StarFire positioning algorithm based upon the last good RTK-based position along with the last StarFire position offset at the base station. This offset is computed by taking a delta between the locked RTK base coordinate and the StarFire navigation result. Its best performance is after steady-state navigation is achieved at the base. RTK-quality positions are maintained for up to and beyond 15 minutes after a RTK communication dropout. If the RTK data link is not restored, the StarFire rover accuracy will migrate to its typical decimeter performance.

No. StarFire receivers are receive-only. This reduces their power consumption and the network costs, savings of which are passed to the end user.

Every StarFire user must complete a StarFire End User License Agreement (EULA) and subscribe to one of the flexible licensing plans via their local NavCom distributor. Once confirmed, a license file is provided for upload into the StarFire receiver via the supplied control software. The license and expiration date can be confirmed using the same software program.

Everywhere. StarFire corrections are valid for anywhere in the world. NavCom distributes these via three Inmarsat geo-stationary communication satellites which provide near-global coverage. Reception of these L-Band signals is through the tri-band antenna of the StarFire receivers No other equipment is necessary. The two Polar Regions are not visible from the Inmarsat satellites and for these regions, dedicated satellite phones have been used as data links for StarFire corrections. For StarFire users operating in high latitudes or on a dynamic platform with antenna sway, NavCom offers a separate, low elevation L-Band antenna coupled with a dual RF input receiver which yields enhanced performance in these regions.

Unlike conventional Ground Based Augmentation Systems (GBAS) which determine highly temporal signal corrections, StarFire corrections are derived for satellite key parameters of orbit and clock. This is a more fundamental method of correction and as a result the accuracy degrades much more slowly with time. Excluding any sudden GPS satellite anomalies, the last set of valid corrections will provide decimeter accuracies for up to and beyond 10 minutes. This is a setting made allowable to the user, which permits many accuracy tolerances dependant upon the application.

The StarFire network transitioned from ITRF-2008 to ITRF-2014 on March 31, 2017 for StarFire GNSS and April 1, 2017 for StarFire GPS. Transformation parameters and methodologies are provided here. Furthermore, NavCom product interfaces no longer display the specific ITRF reference year as the network will continually update to more recent realizations as the years progress. Instead, the products will simply indicate either ‘ITR’ or ‘ITRF’ for the datum when in StarFire mode, with the understanding that the reference frame is the current date of the data sample. These changes are indicated in Sapphire firmware version 3.6.11 and StarUtil-3000 software version 1.2.38. The StarFire network was originally formed on the ITRF-2000 datum (WGS-84 G1150) and transitioned to ITRF-2008 (WGS-84 G1674) on January 21, 2014. Users may need to transition through ITRF-2005 to get from ITRF-2000 to ITRF-2008. To receive updated firmware/software, please contact your dealer or NavCom’s customer support center.

The latest realization of the WGS84 (G1762) Datum, as used by the GPS satellites, is based upon ITRF2014 at a different epoch from StarFire. The difference is sub-centimeter. It is important to understand that ITRF differs from WGS84, and one should never assume that they are equivalent in terms of truth reference.

The WGS84 Datum has undergone a number of revisions and realizations. A bias may be seen between WGS84 (G1762) positions and StarFire (ITRF14) positions depending on the equipment, methodology and time when the known WGS84 position was determined. For example, early WGS84 positions were based on Transit Doppler receivers, which had an accuracy of about 10m (depending on observation time). It should be noted that the original WGS84 Datum definition DMA TR8350 defined the Datum with an accuracy of +/- 1.5m. Accurate ITRF coordinates for a static location can be determined by recording several hours of L1 and L2 GPS data and processing these at the SOPAC SCOUT site for global locations or the NGS OPUS site for USA only.

http://sopac.ucsd.edu/

http://www.ngs.noaa.gov/OPUS/

StarFire is an absolute space-based positioning system. The Earth's crust flexes during the day with sea, solar and lunar gravity induced tides resulting in the distance from the earth's surface to the center varying. These variations are well known, principally affecting the height and can be corrected for by the Sinko model which is within the StarFire positioning algorithm.

With so many navigation choices available within NavCom receivers, we produced the SureNav concept. Multiple sources of correction data including StarFire corrections can be input into a receiver at the same time. With SureNav, you can be Sure that the output navigation position will be the best available, coupled with NavCom’s robust confidence statistics which are based upon the navigation inputs to depict the performance level at any moment in time.

This feature allows users to access StarFire corrections over the Internet, giving them access to the same reliable five centimeter global positioning accuracy without the need for a base station. Users are now also able to access StarFire corrections even in those situations when satellite delivery might be unavailable, such as deep urban canyons or very high latitude locations. Furthermore, the automatic failover capabilities in our StarFire enabled products allow the user to switch seamlessly from satellite to internet delivery of StarFire service and thereby maintain the maximum possible uptime. 

• Not available on Sapphire-integrated systems which do not support an IP interface with Ntrip 2.0 (or later) protocol)
• SF-3040 requires software development by 3rd party
• SF-3040 in a LAND-PAK System requires either NavCom FieldGenius v6.0.3.1 or later, or NavCom SurvCE software (available in early 2013 with this specific feature)

How it works:
The receiver acts as an Ntrip client and initiates an Ntrip session including automatic authentication (no user parameters required).

• Requires the unit be licensed for StarFire operation
• Requires the unit to be optioned for StarFire over IP and StarFire Enabled
• Ntrip mountpoint and IP address is only provided to customers who are activated for this service. This information is provided at the time the software option is provided to the customer or from Customer Support  
•  NavCom FieldGenius and NavCom SurvCE are preconfigured to connect to the correct IP address
• The method that the GNSS receiver is connected to the internet is the customer’s responsibility. The connection can be made through a 3G modem, VSAT, Iridium, direct connection to the internet, etc. The connection can be made using StarUtil 3000 and the command line interface (Input Terminal). An Application Note is available to detail the mechanics of making the connection.

Data management

• Packet size is currently at 787Bytes max with GPS and GLONASS corrections
• The service is offered with three different delivery modes to help customers manage their data costs: 1-second (streaming); 15-seconds; 60-seconds
• Packet size for different rates are the same size
• Convergence time and accuracy is the same for all delivery rates, whether over the air or via IP

How do I get StarFire Over IP? StarFire Over IP Licensing

• Receiver needs StarFire over IP and StarFire Enable options
• Standard receiver StarFire license authenticates both services

Since 1996, NavCom has developed six different GPS ASIC chips within the Touchstone family. Such enhancements on existing architecture proves both NavCom and Deere's commitment to ongoing GNSS technology development.

NavCom has patents for multipath mitigation, L2 carrier tracking and signal interference suppression. IntuiTrak combines these techniques to provide signal quality that allows innovations such as NavCom's StarFire 5cm-level positioning performance, RTK and RTK Extend.

NavCom's proprietary binary language is exceptionally compact without compromising the resolution of the measurements. This results in very low bandwidth for the RTK communication link without loss of accuracy and precision. It also allows additional information, not included in the RTCM messages, to be transmitted to the rover, providing additional robustness and quicker ambiguity resolution.

The current generation of NavCom GPS/GNSS products uses a table of geoid-ellipsoid separation values to convert the computed GPS/GNSS height (relative to the WGS84 ellipsoid) to height relative to mean sea level. The grid points of the table are spaced at 0.5 degrees of latitude and 0.25 longitude and a resolution of cm. A four point interpolation is performed to predict the geoid-ellipsoid separation for the current navigation solution latitude and longitude. Geoid Model derived from Grace Geoid Model data. Grid table data uses combined data from GGM02C and EGM96.  Because of the resolution of the grid table and statistical properties of the EGM96 model, there may be a few meters of error in the predicted geoid-ellipsoid separation value for a specific latitude and longitude. Typical errors are on the order of one meter.

Sapphire, SF-3040, and SF-3050 support GPS and GLONASS constellations with a 67 channel receiver. 1-channel is reserved for StarFire signal tracking, 2-channels support public SBAS signal tracking, 12-channels support either GLONASS G2 (default) or GPS L5 signal tracking, and the remaining 52-channels support GPS L1, L2, L2C, and GLONASS G1 signal tracking. For all-in-view tracking of these two constellations: GPS L1/L2 (24 channels), GLONASS G1/G2 (14 channels), and StarFire, 39 channels are all that is needed. The receiver can also track L2C, but those are not used in navigation and would bring the count up to a maximum of 51 (53 if including SBAS).

StarUtil 3000 - engineering and service utility to configure, monitor and troubleshoot receiver performance.

The StarUtil 3000 program embeds a RINEX conversion utility to convert NCT (NavCom Technology) binary raw data (MEAS1B, PVT1B, and EPHEM1B messages) to RINEX v2.1 format. Converting NCT raw data to RINEX provides a means to post-process the raw data where third party software packages do not support the NCT Binary format, but do possess the ability to import RINEX Standard measurement data. 

For more information, please refer to the StarUtil 3000 User Manual.

The user must ensure adherence to all local and national regulations and licensing requirements pertaining to radio transmit frequencies and power output levels prior to commencing transmission.

400 MHz Radio in the SF-3040

The operating frequency of the radio is user programmable from 403.000 to 473.000 MHz in 0.025 or 0.0125 MHz steps. The factory setting allows the user to modify the power level between 10 mw and 1 watt.

In most cases, the user must obtain a license to operate the radio in a specified location, frequency and power level. The user must ensure adherence to all local and national regulations and licensing requirements pertaining to transmit frequencies and power output levels prior to commencing transmission.

Specifications are based on the following: PDOP <4, 1-sigma (65%), 24-hour averaged set of data. Further, performance is dependent upon, but not limited to location, satellite geometry, atmospheric conditions (i.e., solar storm activity), local interference, DoD signal degradation (i.e., Selective Availability or similar techniques), satellite messaging or timing errors, and augmentation correction messages. Equipment operated on a single-frequency (i.e., L1/G1) is more susceptible to atmospheric and solar storm activity than multi-frequency operated equipment.

Local conditions may have an impact on accuracy. Interference, such as harmonics from collocated transmitting antennas, and multipath, induced by reflective surfaces in the proximity of the antenna, can be harmful to the quality of the measurements used within navigation. Local obstructions, such as bridges and large structures, can also inhibit performance as they impact the receiver’s ability to track signals in the direction being blocked.

Ionosphere is another concern. The single frequency operation relies on two ionospheric models to navigate with StarFire precision; the Klobuchar Model – which is broadcast by the GPS satellites, and the WAAS Model – which is broadcast within the SBAS corrections. The latter model provides the greatest accuracy (~50cm horizontal), but only within the SBAS operational areas. The Klobuchar Model is less resolute, so the navigation accuracy is less accurate, (~80cm horizontal), but can be used worldwide.

WAAS Ionosphere correction availability is contingent upon the ability of the receiver to decode the WAAS correction stream and compute a valid Ionosphere correction for each satellite used in Navigation. Should the receiver be tracking WAAS but operating out of the WAAS Ionospheric coverage area, the Klobuchar model is used.

Sapphire based products are capable of receiving and using the following RTCM message types: 3, 18-22, 1001-1012, 1019-1020, and 1033.

The basic environmental and electrical testing called out by RTCA DO 160 and RTCA DO 228 are the same for TSO-C144 and ETSO-C144.

When documents are submitted for EASA ETSO by NavCom's supplier, they use the same qualification test reports that are submitted to FAA ACO to get TSO approval. That is in addition of filing a few other EASA required general forms. These additional forms are a formality and do not add additional testing. Though this paperwork has not been officially filed within Europe, the antenna does conform to the European standards by associated testing conducted against the FAA requirement.

The cable delays, internal filtering delays and the delays due to clocking of samples inside the ASIC and the difference between GPS time and UTC are common to all of the GPS satellites. This common term appears as a receiver clock error in the Kalman filter solution. The receiver steers the timing of the UTC pulse-per-second output pulse and the timing of the periodic position solutions to offset the delays. The position solution should give the time the signals reach the satellite antenna and the altitude should be the altitude of the antenna.

To create a super accurate timing of the 1PPS, lengths of the 1PPS cables, delays in 1PPS output buffers, etc. must be compensated. There is a control in the 1PPS control software (0x16 in the SF-2050 and [1PPS] in the SF-3050) that allows the operator to slew the 1PPS and measurement timing so that the 1PPS at the end of its cable is precisely synched.

The Slant range (or Height when a tripod is not in use; input message x4B, W3 – range: -32768 – 32767mm for the SF-2050 and [ANTENNAHEIGHT] in the SF-3050) of a 10-foot offset to the ARP (antenna reference point, which is usually the base of the antenna) of our antenna would be 3048mm. Post-processing software will also need to know the phase center offset for this antenna, which is calibrated and published on the NGS website. The SF-2050M Airborne receiver antenna is defined here. Our altitude or height calculation is the slant range above the surface of interest to the ARP + the antenna phase center offset. When used in an RTK system, the Base and Rover need to use the NGS antenna offset calculation in order to achieve the most accurate results. As an alternative, the L1 or L2 (choose one or the other across all platforms) phase center offset printed on the antenna bottom label (with proper orientation to ARP) may be applied for relative antenna position accuracy.

The SanDisk Cruzer Titanium Plus 4GB USB drive provides excellent data retention.

SATELLINE EPIC PRO 35W is specified to operate within frequency range of 400 – 770 MHz (4 MHz Field Selectable).

The available antenna on the price list supports the frequency range of 450 – 470 MHz. If for some reason the users wish to operate at a lower frequency range (e.g. 406 – 430 MHz) then the appropriate antenna can be ordered directly from the manufacturer. The product and manufacturer/distributor information are as follows:

Manufacturer: Laird

Distributor: Arcadian; Part Number: CW4065C

My screen is not refreshing, how do I recover from this? This is caused by a random memory allocation problem. To recover from this, you must perform a Hard Reset by power cycling the Handheld and rerun FieldGenius software. Note: No Project data will be corrupted if this problem occurs, the worst case may require restoring the last surveyed point.

Software locked up or is unresponsive, how do I recover from this? To recover from this, you must perform a Hard Reset by power cycling the Handheld and rerun FieldGenius software. Note: No Project data will be corrupted if this problem occurs, the worst case may require restoring the last surveyed point.

What version of Handheld OS (Operating System) and FieldGenius should I be running for optimum performance? Handheld OS v78.06 or newer and FieldGenius v8.2 or newer.

The Event Latch Interface module will support triggering rates of up to one frame/ pulse per second.

The event pulse output by many cameras and other aerial survey sensors does not have sufficient power to trigger the GPS event latch circuitry. The even latch interface conditions and amplifies the pulse so that it can be successfully integrated with the GPS receiver. It eliminates the requirement of 3-6V DC with 50 Ohm load input impedance.

Leica RC-30 cameras have been successfully tested with this module.

Connect the LEMO connector to the EVT MKR/CAN connector located at the back panel of your SF-2050M GPS Receiver. Input is through a female BNC connector, where the center pin is the signal and outer shell is ground.

Logging the 0xB4 binary message at a rate of “On Trigger” will output a message containing the time mark of when the trigger occurred. The position in the B1 records on both sides of the event must be interpolated by post mission software to obtain the exact position of the event NavCom’s StarPac is available for such a purpose.

The event latch interface is powered from the GPS receiver. There is no input or need to power it from an external source.

The event latch triggers on the falling edge of the pulse. However, use of the Event Latch Interface will condition the pulse appropriately, so is able to accept either rising or falling edge configurations (a.k.a. active high or active low).

The minimum pulse width is 10usec with input voltage logic high 4-5.5V DC and logic low 0-0.4V DC with minimum 4mA sink current.

This information is also in the SF-3050 User Guide, and downloadable from our web site. The minimum pulse width is 100nsec with input voltage 3-6V DC for high and 0 to 1.2V DC for low.

The precision time of an event is 1µsec, but hardware delays (12µsec) are also associated with this precision, accumulating to a total system delay of ~13µsec. The precision will be incumbent upon the velocities experienced, but typically cancel out due to the consistency of the total delay.

This feature allows users to receive StarFire corrections over the Internet, giving them access to the same reliable five centimeter global positioning accuracy without the need for a base station. Users can access StarFire corrections in environments where StarFire satellite delivery might be unavailable, such as deep urban canyons or very high latitude locations.Furthermore, the automatic failover capabilities allow the user to switch seamlessly from satellite to internet delivery of StarFire service, thereby maintaining maximum uptime in otherwise challenging locations. 

• A LAND-PAK System requires either NavCom FieldGenius v6.0.3.1 or later, or NavCom SurvCE software (available later in 2013 with support for this  feature)
• LAND-PAK Systems delivered prior to February 2013 will require software and software options updates
• SF-3050 products operating on software version 3.2.11 or later are capable of using StarFire Over IP with the purchase of appropriate options and licenses
• Availability on Sapphire-integrated systems requires the integrator to provide an IP interface with Ntrip 2.0 (or later) protocol with the purchase of appropriate options and licenses and the means to access the service is determined by the integrator’s user interface program
• Usage of SFoIP for the SF-3040 receiver requires 3^rd party developed controller software to support the feature in addition to the receiver operating on software version 3.2.11 or later with the purchase of appropriate options and licenses

StarFire corrections function over IP in exactly the same way as in traditional StarFire correction satellite delivery.

The receiver (SF-3050) or data collector (for LAND-PAK with Nautiz X7 and NavCom supplied data collection software) acts as an Ntrip client and initiates an Ntrip session including automatic authentication (no user parameters required).

• Requires the unit be licensed for StarFire operation
• Requires the unit to be optioned for StarFire over IP and StarFire Enabled
• Ntrip mountpoint and IP address is only provided to customers who are activated for this service. This information is provided at the time the software option is provided to the customer or from Customer Support  
•  NavCom FieldGenius and NavCom SurvCE (available later in 2013 with support for this feature) are preconfigured to connect to the correct IP address
• The method that the GNSS receiver or data collector is connected to the internet is the customer’s responsibility. The connection can be made through a 3G modem, VSAT, Iridium, direct connection to the internet, etc. The connection can be made using StarUtil 3000 and the command line interface (Input Terminal). An Application Note is available to detail the mechanics of making the connection.

The automatic failover capabilities in StarFire over IP allow the user to switch seamlessly from satellite to internet delivery of StarFire service. This feature is built-in to our NavCom FieldGenius and NavCom SurvCE software, allowing LAND-PAK users to seamlessly switch between StarFire corrections delivered via satellite to internet delivery when satellite delivery is interrupted. This feature, however, is not built-in to our SF-3050, SF-3040, and Sapphire board products and requires development of third party integrators to achieve the same functionality.

• Packet size is currently at 787Bytes max with GPS and GLONASS corrections
• The service is offered with three different delivery modes to help customers manage their data costs: 1-second (streaming); 15-seconds; 60-seconds
• Packet size is the same whatever the streaming rate selected
• Convergence time and accuracy is the same for all delivery rates, whether over the air or via IP

To be licensed for StarFire Over IP

• Receiver needs StarFire over IP and StarFire Enable options
• The receiver needs an active StarFire license. The standard receiver StarFire license authenticates both correction delivery services

An Application Note is available to detail the mechanics of making the connection.

Yes, delivery will follow the same process as outlined in the manual for OTA StarFire license renewal:

• The customer selects the date and time in GMT for the Over the Air broadcast of the StarFire License.
• The scheduled broadcast must occur at least 3 business days after a valid P.O. is received by NavCom Sales.
• Specify broadcast date and time in GMT on the P.O.
• NavCom confirms the date & time of broadcast via email.

About Over the Air Broadcast

• The StarFire license is broadcast at the scheduled time and 5 minutes later as a backup.
• To ensure reception, turn on the receiver before the specified broadcast time. Do not turn off the receiver until verifying that the license is saved.
• The receiver must be tracking StarFire satellites at the broadcast times, though the receiver is not required to be operating in StarFire mode during the broadcasts.

Please contact customer support to update your LAND-PAK.

This feature allows users of the SF-3050 to view receiver performance and configure their receiver with a web browser (Chrome, FireFox, Safari, or Windows Explorer).  This has the same functionality as StarUtil-3000.

The web server has a sub-set of the available functions in StarUtil-3000. The features that are not present in the web server are those that require desktop computer support. These include (but are not limited to): data parsing, RINEX conversion, and playback simulation.

This feature has three separate access levels which are setup using StarUtil-3000: User, Technician, and Administrator. Each level requires a user name and password. Users have the ability to observe the receiver performance and make minor software changes. Technicians have access to configure and input command / control features. Administrators can create User and Technician accounts. These access controls help to protect the receiver against unauthorized usage if the receiver is accessible via an open WAN interface.

The receiver needs to operate on production software version 3.3 or later. Please contact Customer Support for the correct software update

3rd-Party GLONASS RTK (limited implementation to known competitive receivers)

• GLONASS employs a different technique of frequency use and modulation as compared to GPS. Without an industry standard to follow, each manufacturer applies a different frequency bias to track and demodulate the GLONASS signal. While each manufacturer can easily use GLONASS signals for RTK within their own product line, doing the same with a mixture of competitive equipment has proven to be an obstacle. NavCom software (v3.3 and later) helps to bridge this gap for the most popular manufacturer receiver families and allows NavCom receivers to be used with a wide variety of deployed competitive equipment.

NavCom utilizes a lookup table of calibration values based on tested competitive products. The receivers provide a user command which allows the receiver to be updated for a new product if the new product is not in the calibration table.

The receiver needs to operate on production software version 3.3 or later. Please contact Customer Support for the correct software update

StarFire Rapid Recovery is a proprietary technique which allows NavCom’s GNSS receivers to resume StarFire level of accuracy (5cm) after a GNSS signal outage. Before the introduction of Rapid Recovery, the GNSS receiver had to allow the StarFire solution to re-converge, after re-acquiring the GNSS satellites which could take in excess of half an hour to accomplish. The new Rapid Recovery technique provides 5cm level accuracy within two minutes after resuming GNSS navigation in StarFire mode.

The receiver applies a technique of StarFire re-initialization from previously resolved ambiguities. If a StarFire receiver mounted on a vehicle passes under a bridge, the receiver will lose lock on all GNSS satellites and the navigation flag becomes invalid. When the vehicle is in the open again, the receiver begins to track satellites again. It will enter Standalone GNSS mode, then potentially SBAS and StarFire Single modes. Once it attains StarFire Multi-frequency mode, the Rapid Recovery initialization is enacted and the receiver resumes normal StarFire converged performance in a matter of seconds. The entire process includes the: time of outage + reacquisition + navigation + transition to StarFire + Rapid Recovery initialization. The timing of the process varies based on the environment encountered and the PDOP value once navigation is resumed.

All Sapphire and newer generation products are capable of StarFire Rapid Recovery. This currently includes the Sapphire board, SF-3040,  SF-3050, and LAND-PAK.

3 minutes

10km

Because the ionosphere and troposphere are not changing dramatically during the outage, acceleration is not a factor for StarFire Rapid Recovery.

StarFire Rapid Recovery will work at velocities up to the COCOM limit of 515m²/sec.

PDOP < 4 and HDOP <3.

No. RTK Extend is an augmentation mode to RTK. However, if the receiver transitions from RTK Extend to StarFire mode, then StarFire Rapid Recovery will serve to augment StarFire mode.

Not under normal operating conditions (i.e. open sky). The performance differences between GPS-Only and GPS+GLONASS are based on the DOP and overall geometry of satellites tracked and used in the navigation algorithm.

Not under normal operating conditions (i.e. open sky). The performance differences between GPS-Only and GPS+GLONASS are based on the DOP and overall geometry of satellites tracked and used in the navigation algorithm.