a__PWS_1305M226Q0125.pdf

The National Geodetic Survey

Phase 2: Update Land Surveying Software Suite for the Modernized National Spatial Reference System

Page 1 of 25 Revised 5/18/2026

I. SCOPE

The National Geodetic Survey (NGS) is a program office under the National Ocean Service (NOS). NGS provides the framework for all positioning activities in the Nation. The foundational elements - latitude, longitude, elevation, shoreline information and their changes over time - contribute to informed decision making and impact a wide range of important activities including mapping and charting, navigation, flood risk determination, transportation, land use and ecosystem management. NGS' authoritative spatial data, models, and tools are vital for the protection and management of natural and manmade resources and support the economic prosperity and environmental health of the Nation.

NGS provides the public a suite of online and downloadable software to support land surveyors’ tools and services to allow them to calculate their survey results according to NOAA’s guidance and enabling the public access to reference these observations to the National Spatial Reference System (NSRS). Common land survey results include observations from differential leveling, total stations including Electronic Distance Measurement (EDM), and geodetic observations using Global Navigation Satellite Systems (GNSS) (Figure 1). In the first phase for updating the legacy surveying software suite for the Modernized NSRS, NGS invested efforts in developing an engine software, known as LASER, that is able to collect and share information about adjusting observations using least-squares adjustment in C++. This engine is based on Eigen libraries that allow rapid calculations of normal equations with least squares solution modules.

In the second phase for updating legacy surveying software suite for the Modernized NSRS, the following tasks have been identified:

Option Task - Updating the LASER engine to the latest Eigen libraries

Task 1- Improved GNSS Observation Adjustment with LASER

Task 2- Consolidating reading and reduction tools for differential leveling, total stations, and EDM observations.

Task 3- Updating Antcal source codes absolute and relative source codes to Python

Page 2 of 25 Revised 5/18/2026

Figure 1: Workflow diagram of updated land surveying software suite for the Modernized NSRS

The source codes for all three tasks shall be in Unix or Linux environments. For Tasks 2 and 3, executables shall be generated from the source codes in order to operate in a Windows environment.

II. OPTION TASK - UPDATING THE LASER ENGINE TO THE LATEST EIGEN

LIBRARIES

The NGS LASER (Least-Squares Adjustments: Statistics, Estimates, and Residuals) engine is a C++17 software suite designed to perform high-performance least-squares adjustments for the modernized National Spatial Reference System (NSRS). The least squares adjustment (LSA) library leverages C++ class inheritance to support five specific adjustment types—3D, leveling, and gravity networks, along with vertical-gravity and calibration-baseline adjustments—while offering seven different LEast-Squares Solution (LESS) types ranging from unconstrained to overly-constrained solutions with both fixed and stochastic parameters. For performance, LASER utilizes the Eigen library for matrix arithmetic and can process massive datasets, such as the national NSRS 2022 adjustment with nearly 1.5 million observations, in under four hours.

Beyond basic parameter estimation, the suite includes automated fragmented network detection, pre-adjustment blunder and loop-misclosure checks, post-adjustment outlier detection, and multiple variance component estimation.

The overall goal of this optional task is to update the LASER engine to the latest Eigen libraries that also include capabilities, such as inserting elements into sparse matrices. This optional task is in order to update LASER’s mathematical libraries with the new version 5.0.0 of the linear algebra library Eigen that was released on September 30, 2025. The updates to the shall be done in C++.

Page 3 of 25 Revised 5/18/2026

III. TASK 1- IMPROVED GNSS OBSERVATION ADJUSTMENT WITH LASER

3.1 Task description and expected improvements

In providing this service for the Nation, NGS routinely processes vast amounts of data from Global Navigation Satellite Systems (GNSS) to compute the positions of ground stations and GNSS satellite orbits. Historically, NGS has had capabilities to use only the U.S. Global Positioning System (GPS) data. Adding capability for multi-GNSS processing will allow NGS to utilize data from all available navigation constellations, increasing accuracy and precision of position solutions and enabling multi-GNSS orbit solutions. To add this crucial capability, NGS has developed its own multi-GNSS processing software suite, including libraries that can support precise orbit determination and positioning of ground stations. This software and its libraries, written in C++, referred to as M-PAGES, is a functional software suite already being used to compute coordinates for the national adjustment and will soon be incorporated into the modernized OPUS-Static public service.

The overall goal of the task is to improve the performance of a specific section of the M-PAGES software sub-suite, the normal equation and least squares solution module called SdSolve.

Currently, the LSA library is handled by a M-PAGES library called NgsLsq. The code and algorithms are currently inefficient for larger-scale systems of equations, leading to a nonlinear growth in runtime as data is added to the adjustment. Although improvements were made to the code and additional in-house development, the current M-PAGES implementation still cannot adequately handle large network adjustments (i.e., multiple station observations and satellite observables that may require parallel processing) and meet performance targets.

The new LSA library to be used in the contract performance is called LASER. This software was developed for NGS for the adjustment of very large geodetic networks and sparse systems of equations. LASER has demonstrated excellent performance in other applications at NGS, and it is expected that the LASER algorithms could be used to adjust the GNSS system of equations in M-PAGES. Incorporating LASER into M-PAGES will also meet a stated NGS goal of using a single LSA software for all LSA conducted at NGS.

Minimum performance targets for M-PAGES are defined by the current performance of the legacy NGS software used for GPS-only positioning, PAGES, that serves as a benchmark for desired minimum performance. The Multi-GNSS software, M-PAGES, that will replace legacy NGS software PAGES is scheduled to be incorporated in multiple public facing geodetic services, such as OPUS Projects, which currently runs with PAGES software on RHEL7 KVM servers with 30 CPUs and 52GB RAM, and is capable of processing a 100-station network of GPS-only observation files (30 second sampling rate) in less than 2 hours. This benchmark includes geodetic algorithms, such as integer ambiguity resolution, but we note that there is significant variability in the amount of data in a typical OPUS Project (usually with observations files that include observations over a time period equal or less than 24 hours per station). The update will allow the M-PAGES software to handle a larger volume of data due to the inclusion of additional GNSS, such as Glonass, Galileo, and BeiDou.

Page 4 of 25 Revised 5/18/2026

For networks larger than about 20 stations, the runtimes for current M-PAGES software are far above the desired levels. Current M-PAGES performance of SdSolve is provided in the figure 2.

These runs took place on a RHEL8 Amazon Web Services machine with 32 CPUs and 64 GiB memory (instance c6i.8xlarge). Note the analysis conducted here is for 24 hours of 30 second data per station using GPS only observations, without ambiguity resolution. Based on other testing, it is expected that the addition of ambiguity resolution will roughly double the runtime beyond what is shown in the figure. Since M-PAGES is intended for multi-GNSS analysis, which will multiply the data volume far beyond that of GPS-only solutions, it is crucial that runtimes be reduced.

Figure 2. M-PAGES current runtimes in minutes of SdSolve as a function of number of stations. These runs took place on a RHEL8 Amazon Web Services machine with 32 CPUs and 64 GiB memory (instance c6i.8xlarge).

3.2 Software Details

The current C++ program SdEngine, implemented as the SdSolve executable, performs single-difference (SD) GNSS baseline processing to determine station coordinates plus other parameters. Its primary functions are to:

1. Manage the workflow for processing GNSS baselines, including reading configuration, managing observation data, and handling a priori models;

2. Iteratively build and solve the normal equations by accumulating single-difference observation equations epoch-by-epoch; and

3. Implement ambiguity resolution, iteratively solving the system to fix biases to integer values.

The SdEngine class inherits from the NgsLsq::NormalEquations class, which is responsible for building, managing, and solving the system of linear equations using Cholesky factorization methods, supporting unconstrained, fixed, and stochastic constraints (Gauss-Markov Model variations). It uses a Parameter class to define and organize various adjustment parameters (like coordinates, clocks, and atmospheric biases) by scope (GLOBAL, LOCAL, DISPOSABLE) and

Page 5 of 25 Revised 5/18/2026 mode (STATIC, EPOCHWISE, PIECEWISE_LINEAR), including methods for managing parameter life cycles and "sweeping out" local parameters during the sequential least squares process.

3.3 Tasks and Evaluation

The expected outcome of this contract is a substantially improved SdSolve program with improved runtimes on NGS machines. The goal performance benchmark is to process 100 stations of 24 hr length GPS-only observations with a 30 sec sampling, with ambiguity resolution disabled, in less than 1 hour. To meet this goal, the awardee will modify the existing code to leverage LASER CoreLsa and the capabilities of the Eigen library for matrix construction, manipulation, and solution. In addition, the contractor shall consider and implement multi-threading and multi-processing wherever possible, to further decrease runtime.

To support the work, NGS will provide C++ object-oriented libraries from both M-PAGES and LASER. The contractor will use existing libraries, developing new C++ libraries and objects as needed to accomplish the contract goals. New C++ libraries shall use the object-oriented approach and programming style demonstrated in the other NGS code.

The new code shall be capable of being compiled and run on NGS Red Hat 8 Linux machines operating on AWS. As with other M-PAGES code, the new code must be compiled with GNU compilers. The contractor will not be granted direct access to NGS machines; the contractor must provide their own environment and compilers for development. For testing the code, the code must be provided through a private GitHub repository so that an NGS employee can pull the code to NGS machines for compilation and testing. NOAA/NGS will provide system configuration information to the awardee, so that their own development and testing can be conducted in a similar Linux environment to those at NGS.

The following materials will be provided to the awardee:

● Complete M-PAGES codebase, which includes all C++ libraries and programs mentioned above, as well as programs which use these libraries for similar purposes

● Complete LASER codebase, including the CoreLSA C++ library.

● Future work suggestions from the earlier M-PAGES contract.

● HTML documentation for M-PAGES and LASER codes

● NGS coding standards document

● System configuration information for NGS Linux machines

● Data sets prepared for M-PAGES processing, including configuration files (the same data sets used in runtime figure)

● Sample data sets to verify LASER installation on development machines

Page 6 of 25 Revised 5/18/2026

3.4 Deliverables

For each deliverable in this performance work statement, the following items are mandatory in addition to all the source code which they must delete at their end at the end of the project:

● A build script that builds and deploys apps on Windows/Linux servers as desired. NGS has standardized "ant" as a build and deployment scripting language. Apps should build and deploy without requiring specific knowledge of them.

● Include test cases, test data, sample runs, and performance benchmarks so that NGS can replicate these. Any discrepancies identified shall be resolved.

● If the runtime environment has external dependencies, those dependencies must be identified and documented.

● The apps shall implement a logger to capture runtime errors and exceptions to help programmers and admins troubleshoot issues.

● At the conclusion of the contract, once all deliverables are provided to NGS, all source code, test data, etc., must be destroyed by the awardee

Task 1 is the highest priority for NGS operations and should be done before the other two tasks (Tasks 2 and 3). It is acceptable to conduct this task in parallel to Tasks 2 and 3. Task 1 is expected to have a performance period of 6 months, reflected in the deliverables timeline table below.

Description Target Due Date

1.1 Kickoff meeting and code documentation receipt/review. Within 1 month of award

1.2 The contractor has successfully compiled and run M-PAGES with the provided data sets (up to 101 stations), documenting the runtimes on the contractor's development machine.

Within 2 months of award

1.3 Profile the SdEngine/SdSolve program, demonstrate an understanding of the current solution methodology, and make recommendations for code efficiency and speed improvements and LASER integration.

Within 2 months of award

1.4 Write new C++ code to implement SdEngine improvements and incorporate LASER for the LSA.

Within 4 months of award

1.5 Demonstrate that the code meets the runtime requirements defined under Tasks with no loss of solution accuracy.

Within 5 months of award

1.6 The contractor delivers final, functional C++ code and documentation to the NGS project manager.

Within 5 months of award

Page 7 of 25 Revised 5/18/2026

1.7 Assist NGS personnel as they migrate the code to NGS computing resources.

Within 6 months of award

1.8 Oral briefings on status to one or more NGS employees, to be determined by NGS

Every 2 weeks, and after each deliverable

1.9 Develop responses to FOIA and information requests As required

3.5 Technical Point of Contact

The Technical Point of Contact for M-PAGES is Andria Bilich and a member from the NGS LASER team that will be responsible for technical guidance to the contractor and should a dispute arise shall inform the Contracting Officer. This is not a personal services contract and the Technical Point of Contact or no other Federal employee will personally “supervise” the contractor.

VI. TASK 2- CONSOLIDATING READING AND REDUCTION TOOLS FOR

DIFFERENTIAL LEVELING, TOTAL STATIONS, AND EDM OBSERVATIONS.

4.1 Task description and expected improvements

The National Geodetic Survey (NGS) maintains a program (geodesy.noaa.gov/CBLINES/) for the evaluation of electronic distance measuring (EDM) instruments on calibration base lines (CBLs). Base lines have been established in the decades since the 1970s and are made up of a series of survey marks. With careful observations and analysis, the EDM instrument’s additive constant and scale error may be determined. NGS offers the public a Microsoft Windows-based program, CALIBRATE, to support base line observations. The CALIBRATE software aids with data organization, acquisition of observations, data reduction, and analysis. In addition to evaluation of instruments, CALIBRATE is also used for establishing reference values for base lines. The algorithms and procedures used in the CALIBRATE program follows the NOAA publications NGS 10: Use of Calibration Base Lines, NGS 8: Establishment of Calibration Base Lines.

Similarly, NGS provides the public the TRANSLEV program that facilitates the process of editing, formatting, reducing, and checking digital leveling observation data and creating abstracts. The program includes many built-in functions such as predicting temperature differences, refraction corrections, rod corrections and plotting.

The overall goal of Task 2 is to consolidate three overlapping functions in CALIBRATE and TRANSLEV and utilize the new LSA library LASER. This software was developed for NGS for the adjustment of very large geodetic networks and sparse systems of equations. LASER has demonstrated excellent performance in adjusting differential leveling and classical observations, including the use of EDM and total station as separate observations. Incorporating key functions https://geodesy.noaa.gov/CBLINES/ https://geodesy.noaa.gov/PC_PROD/ https://geodesy.noaa.gov/PC_PROD/ https://geodesy.noaa.gov/PC_PROD/PARTNERS/Translev/Translev_5.03.06.zip

Page 8 of 25 Revised 5/18/2026 from CALIBRATE and TRANSLEV with LASER will also meet a stated NGS goal of using a single LSA software for all LSA conducted at NGS. The three common functions that are currently found in both CALIBRATE and TRANSLEV include: the reading/ingestion of input data, reducing the measurements into observations for least-squares adjustment, and providing a final report after conducting a least-square adjustment. A report shall be also available after the measurements have been ingested into the tool (full measurement report), and a reduced observation report after conducting reduction prior to running an adjustment on the observations.

It is important to note that the calibration base line (in CALIBRATE) is used to estimate unknown systematic errors between an EDM instrument and a specific type of reflector. The systematic errors are of two types: an offset (or bias) and a distance-dependent scale factor.

These terms are estimated from distance measurements made between a number of points arrayed along a line at known distances.

4.2 Software Details

The new tools shall be developed in Python the output (reduced observation file) will need to interface with NGS LASER (Least-Squares Adjustments: Statistics, Estimates, and Residuals) engine, which is a C++17 software suite designed to perform high-performance least-squares adjustments for the modernized National Spatial Reference System. The LSA library leverages C++ class inheritance to support five specific adjustment types—3D, leveling, and gravity networks, along with vertical-gravity and calibration-baseline adjustments—while offering seven different LEast-Squares Solution (LESS) types ranging from unconstrained to overly-constrained solutions with both fixed and stochastic parameters. Beyond basic parameter estimation, the suite includes automated fragmented network detection, pre-adjustment blunder and loop-misclosure checks, post-adjustment outlier detection, and multiple variance component estimation.

The contractor will be provided with the source codes for TRANSLEV and CALIBRATE that are in Visual Basic, including comments describing the algorithms and procedures. These source codes will allow the contractor to incorporate the reading and reduction algorithms and procedures into a new single tool in Python that unifies the functionality of TRANSLEV and CALIBRATE. Specifically, the reading/ingestion of input data procedure, reducing the observations with a report on the reduction, and providing a final report after conducting a least-square adjustment.

4.3 Tasks and Evaluation

The expected outcome of task 2 is a set of Python source codes for the operator to be able to read, reduce, adjust and calibrate differential leveling, trigonometric leveling, total station, and EDM using command lines (running in Linux and with executable files in Windows). The new tool will be able to read/ingest input data from the instrument and the estimated location of starting mark. The tool will write a summary report on all uploaded measurements. The end user

Page 9 of 25 Revised 5/18/2026 will then be able to reduce data into observations to get another intermittent report on the reduction, then adjust the observations using the LASER C++ engine, and provide a final report after conducting a least-square adjustment. This might require modifying LASER source codes in order to read the observations and adjust them. NGS will be using the source codes and executables to create public-facing tools using a graphical user interface. Although the interface will be developed by NGS, Appendix A illustrates the workflow and steps that the operators will be required to follow.

The new code shall be capable of being compiled and run on NGS Red Hat 8 Linux machines operating on AWS and capable of being compiled as an executable for running on Windows. The contractor will not be granted direct access to NGS machines; the contractor must provide their own environment and compilers for development. For testing the code, the code must be provided through a private GitHub repository so that an NGS employee can pull the code to NGS machines for compilation and testing. NOAA/NGS will provide system configuration information to the awardee, so that their own development and testing can be conducted in a similar Linux environment to those at NGS.

The following materials will be provided to the awardee:

● TRANSLEV and CALIBRATE (in source codes Visual Basic),

● Complete LASER codebase, including the CoreLSA C++ library.

● Future work suggestions from internal NGS discussions on NSRS modernization.

● Documentation for TRANSLEV, CALIBRATE and LASER codes

● NGS coding standards document

● System configuration information for NGS Linux machines

● Sample data sets in legacy files formats (section 4.3.1) and the new file format (section

4.3.2) to verify proper use of the function of TRANSLEV, CALIBRATE and LASER.

4.3.1 To support Task 2 effort, NGS will provide the TRANSLEV and CALIBRATE (in source codes Visual Basic), and the text files that are currently used in TRANSLEV and CALIBRATE:

HDS file (horizontal distance set) - A user-generated text file containing the published horizontal distances between marks. Published distances are obtained from the base line data sheet. Marks should be assigned “Station Serial Numbers” (SSNs) with up to 4 digits.

DES file (description) - A file containing descriptions of all base line marks, generated via the NGS software program WinDesc (available from the NGS website). Descriptions will include mark designations, station serial numbers (SSNs), geodetic positions, elevations, etc. CALIBRATE uses the description file to auto-fill mark information, reduce EDM measurements, and trap errors due to misidentified marks while observing.

INST.PAR file (instruments) - A text file with metadata on the specific instrumentation to be used on the base line, such as the manufacturer, model, serial numbers, and specifications of the EDM instrument(s) and reflector(s). When installed, CALIBRATE will generate a

Page 10 of 25 Revised 5/18/2026 default INST.PAR file. The user should edit the file to add their instruments, giving each instrument a unique three-digit “Job Specific Identifier” (JSI).

TRA file (“traverse” observations) - A text file serving as the working file within CALIBRATE. As base line activities proceed, data is logged to the TRA file, including instrument occupations, instrument heights, meteorological readings, and distance observations. When fieldwork is completed, the TRA file is used for data analysis.

DAT file (Instrument/Rod Data) - A text file that ensures that specific make and model used in TRANSLEV is registered with the NGS. This information is added to the Inst.dat and Rods.dat files, which are used during the data processing.

LVL file (standardized leveling file) - Standardized text files formatted according to NGS specifications for use in various software applications available by NGS.

HGZ file (leveling report file) - Standardized ASCII report files based on differential leveling data.

4.3.2 NGS will also provide a standardized file format for measurements and reduced observations that will be used as input. MicroSurvey Star*Net (see format description here) and NGS’ GDX file formats will be used for the measurements and/or reduced observations file format . Examples for MicroSurvey Star*Net files are provided in Appendix B, and a full description for MicroSurvey Star*Net and NGS’ GDX will be provided once the contract has been awarded.

It is also important to note that these file formats shall be able to upload total station (horizontal angles, vertical angles, slope distances, horizontal distances, directions, etc.) and leveling data for reduction and adjustment. The types of observation should include: apriori coordinates (Coordinate, position, and elevation data types), Single observation data types, Multiple observation data types, Sideshot data types, Direction data types, Traverse data types, Leveling data types, GPS Vector Data, and Standard Errors.

The ingest/reading tool will allow input of ancillary data for reducing observations:

● Distance observations between marks.

● Temperature, pressure, and relative humidity readings for computing atmospheric corrections to the measurements.

● Elevations for each base line mark.

● Heights of instruments and target reflectors above marks.

https://helpdesk.microsurvey.com/en-us/article/1120-summary-of-star-net-input-data-types-and-inline-options#stderr

Page 11 of 25 Revised 5/18/2026

4.4 Deliverables

addition to all the source code which they must delete at their end at the end of the project:

● A build script that builds and deploys apps on Windows/Linux servers as desired. NGS has standardized "ant" as a build and deployment scripting language. Apps should build and deploy without requiring specific knowledge of them.

● Include test cases, test data, sample runs, and performance benchmarks so that NGS can replicate these. Any discrepancies identified shall be resolved.

● If the runtime environment has external dependencies, those dependencies must be identified and documented.

● The apps shall implement a logger to capture runtime errors and exceptions to help programmers and admins troubleshoot issues.

● At the conclusion of the contract, once all deliverables are provided to NGS, all source code, test data, etc., must be destroyed by the awardee

The contract has a one-year period of performance (six months for Task 1, and six months for Tasks 2 and 3), reflected in the deliverable’s timeline. Task 2 should be done after completing Task 1 that is the highest priority or in parallel if the awardee resources allow that. It is acceptable to conduct Tasks 2 and Task 3 in parallel. Task 1 is expected to have a performance period of 4 to 5 months, reflected in the deliverables timeline table below.

2.1 Kickoff Meeting & Code Documentation Receipt/Review. Within 1 months after completion of Task 1

2.2 Demonstrate understanding of the mathematical operations and efficient implementation in Python and C++, and demonstrate understanding of the provided NGS libraries.

Within 2 months after completion of Task 1

2.3 Recommend a code architecture (pseudocode) for the new Python code for incorporating the three CALIBRATE and TRANSLEV functions with

LASER.

Within 3 months after completion of Task 1

2.4 Write new code with clear comments in the code, and demonstrate results using the new file formats (section 3.3.2), meeting the accuracy results in CALIBRATE and TRANSLEV.

Within 4 months after completion of Task 1

2.5 Finalize code development, and deliver the new Python source codes and documentation to the NGS project manager.

Within 5 months after completion of Task 1

2.6 Assist NGS personnel as they integrate recommended algorithm and/or code into their operational suite using NGS computing resources

Within 5 months after completion of Task 1

Page 12 of 25 Revised 5/18/2026

2.7 Oral briefings on status to one or more NGS employees to be determined by

NGS

Every 2 weeks, and after each deliverable

2.8 Develop responses to FOIA and information requests As required

4.5 Technical Point of Contact

Ben Erickson and Philippe Hensel will be technical Points of Contact for the unified tool that will be responsible for technical guidance to the contractor and should a dispute arise shall inform the Contracting Officer. These are not a personal services contract and the Technical Point of Contact or no other Federal employee will personally “supervise” the contractor.

V. TASK 3- UPDATING GNSS ANTENNA CALIBRATION (ANTCAL) SOURCE

CODES

5.1 Task description and expected improvements

The National Geodetic Survey (NGS) built a custom GNSS antenna calibration application (hardware and software) and uses it to conduct a calibration service (geodesy.noaa.gov/ANTCAL/) for referencing the physical location on the outside of the antenna, Antenna Reference Point, to the GNSS Antenna’s phase center. The average Phase Center Offset is a few centimeters with respect to Antenna Reference Point and is expressed using a North (N), East (E), Up (U) vector. The exact location of the phase center depends on the azimuth and elevation angles of the incoming GNSS signal. These Phase Center Variations can range up to 1 cm (Figure 3). The combination of PCO and PCV is known as the Phase Center Correction (PCC). Accurate determination of the PCC relative to the physical GNSS’ Antenna Reference Point enables accurate positioning (~1 cm) that supports many daily activities.

Without proper calibration, the positioning accuracy of survey-grade antennas can be degraded by up to 10 cm.

http://geodesy.noaa.gov/ANTCAL/

Page 13 of 25 Revised 5/18/2026

Figure 3. (Right image) Schematic illustration of the phase center location with respect to the Antenna Reference Point. (Left image) the magnitude and distribution of Phase Center Variation as a function of azimuth and elevation angles.

NGS has developed an application in Perl 5 and Matlab to collect and process GNSS phase observations. The overall goal of task 3 is to update the source codes currently in Perl 5 and MATLAB, porting them to Python with Windows GUIs and a clean UX. The bulk of this task is to rewrite existing code; one additional new feature shall be developed for the final application.

Interactive data QA/QC shall be incorporated into the new workflow. Final results shall include downloadable files of absolute antenna calibrations in ANTEX format, and include error and combination statistics.

5.2 Software Details

The contractor will be provided with the Perl 5 and Matlab source codes for all stages of the current processing workflow (described in detail below), including inline code comments and supporting documents describing the algorithms and procedures. These source codes will allow the contractor to update the application from Perl and Matlab into Python with a graphical user interface, simplifying and automating the current DOS-prompt command line implementation and removing the requirement for a Matlab license.

5.2.1 Current status

In general, there are two phases:

Stage 1 (Data collection): The configuration for antenna calibration includes two GNSS receivers that collect 10-Hz carrier phase data. One antenna is static (Reference). The second antenna (Antenna Under Test, AUT) is mounted on a robotic arm that is steered and controlled through the DOS command line using Perl 5 codes and supporting executables. Data from multiple sources are combined into a master data set for the session.

Page 14 of 25 Revised 5/18/2026

1. Gather test antenna information from the analyst, and review settings: startTest.py

2. Automated data collection: collectAntcalDataGNSS.pl

a. Download supporting products: IGS ANTEX and broadcast orbits

b. Establish synchronous communications with GNSS receivers and robotic arm

c. Steer the robot to point at specific GNSS satellites every few seconds, collecting a geometrically distributed data set over the course of approximately 2 hours (*see

NOTE)

d. Progressively log robot positions to GNSS receiver

e. After movements complete, download data from GNSS receivers

3. Pre-process data: preprocessAntcalData.pl

a. Convert binary observation data to RINEX (*see NOTE)

b. Read RINEX observations and orbit files, write out tables of phase observations, satellite positions, and robot positions (*see NOTE)

It is important to note that the current process calls executables for compiled C++ codes. One executable is commercial code from Septentrio, the remaining were developed by NGS.

Windows 64-bit executables will be provided for contractor use.

● svPriority.exe: Read IGS ANTEX file to create list of priority satellites for steering the robot.

● solveGNSS.exe: Predict satellite locations using ultra-rapid GNSS orbit file.

● sbf2rin.exe (Septentrio): convert Septentrio Binary Format to RINEX

● rnxAntcalGNSS.exe: Read RINEX observation and sp3 orbit files, write data tables.

Stage 2 (Data Analysis): In Matlab, phase observations are reduced to remove all factors except the Phase Center Corrections (PCC). Visualizations aid QA/QC during data reduction. A spherical harmonic surface is fit to the reduced observations using least squares adjustment, solving for an antenna calibration profile.

1. Load data for solution: antcal_loadData.m

a. Form single differences (two GNSS receivers)

b. Throw away data when robot is moving

c. Compute satellite azimuth and elevation angle in antenna reference frame

d. Calculate geometric range and phase windup

e. Calculate corrections for robot XYZ offsets

2. Solve for individual calibration: antcal_solve.m

a. Calculate prefit residual: data minus models

b. Form time differences of observations a few seconds apart but in different robot orientations

c. Edit data for cycle slips

d. Constrained least squares fit of Legendre polynomials to solve for spherical harmonic coefficients

Page 15 of 25 Revised 5/18/2026

e. Separate PCO and PCV

3. Compute type mean

a. Display plots and data tables, allowing the analyst to compare a set of solutions to each other for consistency, and decide on solutions to keep vs solutions to exclude: typeMeanPrep.m

b. Combine selected data: typeMean.m

5.2.2 Desired new software functionality to remove receiver clock effects

In addition to updating the source codes currently in Perl 5 and MATLAB, porting them to Python with Windows GUIs and a clean UX, the contractor shall add a processing option to Stage 2 to allow asynchronous receiver clocks.

In the current hardware configuration at NGS, both GNSS receivers use a common clock via hard-line connection. This results in identical clock terms in the observation equations at both antenna-under-test (AUT) and reference GNSS receivers. When the data from the two receivers are differenced, the common clock is removed. NGS requires capability to calibrate integrated antenna-receiver units, where an internal GNSS receiver with an independent, unsteerable clock is included in the antenna body. This configuration prevents use of a common clock hard-line connection between AUT and the reference receiver. For calibration of integrated receiver-antenna units on the robotic system, an asynchronous receiver clock methodology must be added to the application.

Generally, most calibration institutions use a “triple difference” approach to remove receiver clock effects from the carrier phase data. These studies and their procedures will be provided to the contractor on award (see references at the end of this section). Alternatively, the contractor can provide a solution or model for the differential receiver clock. One or both of these methods shall be implemented in the contractor’s application. NGS prefers triple difference, but receiver clock modeling/solution is acceptable if performance targets are met.

Selected references on antenna calibration with triple-difference phase:

A) Willi, D., Koch, D., Meindl, M., and Rothacher, M., "Absolute GNSS Antenna Phase Center Calibration with a Robot," Proceedings of the 31st International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2018), Miami, Florida, September 2018, pp. 3909-3926. https://doi.org/10.33012/2018.16040

Page 16 of 25 Revised 5/18/2026

B) Zhou, R., Hu, Z., Zhao, Q. et al. Absolute field calibration of receiver antenna phase center models for GPS/BDS-3 signals. Journal of Geodesy 97, 83 (2023).

https://doi.org/10.1007/s00190-023-01773-7

C) Johannes K., Tobias K., Yannick B., and Steffen S., “Multi-frequency multi-GNSS receiver antenna calibration at IfE: Concept - calibration results - validation”, Advances in Space Research, 68, 12 (2021). https://doi.org/10.1016/j.asr.2021.01.029.

5.3 Tasks and Evaluation

This contract task shall result in a complete and operational Antenna Calibration application written in Python with supporting GUIs that accomplishes all of the functions of the current antenna calibration data collection and data processing codes.

● The complete application shall:

○ Communicate with multiple pieces of equipment as well as external data archives,

○ Gather all data required to solve for an antenna calibration;

○ Reduce phase data to remove all known/modeled factors, leaving only PCC effects in the prefit residuals;

○ Solve for antenna calibrations, with two possible solution strategies enabled:

synchronous receiver clocks (current NGS method) and asynchronous receiver clocks (new implementation);

○ Issue final products in ANTEX format.

● The contractors shall create a graphical user interface that facilitates data collection and data processing, accomplishing and coordinating all tasks covered in the In-Depth Procedure (Appendix B).

● The application shall be used on a MS Windows 11 desktop computer.

● The contractor shall design a logical file naming convention and data organization system so that raw, interim, and final products can be easily “zipped” for archiving after processing is complete. The application shall write data to the local machine using the data organization system.

The contractor will not be granted direct access to NGS machines for development or testing. For testing, the application must be provided through a private GitHub repository so that an NGS employee can pull the application to NGS machines for testing and validation. NOAA/NGS will provide system configuration information to the awardee, so that their own development and testing can be conducted in a similar Windows environment to those at NGS. We recognize that https://doi.org/10.1016/j.asr.2021.01.029 https://docs.google.com/document/d/1pgpY-wBsUO07rVOhhYVg-rVHVWAtO0PfSExMg84KE1o/edit#heading=h.460b1e2mh4wp https://docs.google.com/document/d/1pgpY-wBsUO07rVOhhYVg-rVHVWAtO0PfSExMg84KE1o/edit#heading=h.460b1e2mh4wp

Page 17 of 25 Revised 5/18/2026 the contractor’s ability to test the data collection system will be limited without access to the antenna calibration equipment and computers. Therefore, the tools and the graphical user interface to allow the end user to provide key input parameters and call the robotic arm to collect data (Deliverable 3.4 in the next section) will require NGS personnel to test the data collection and analysis on Windows PC to confirm operation. The contractor’s ability to test the “stage 2” data processing, visualization, and analysis system will be facilitated by sample data sets.

The following materials will be provided to the awardee:

● Current Perl 5 and Matlab source codes

● Windows executables for select data collection and pre-processing tasks

● Documentation

○ “absolute antcal desk reference” - describes process for the analyst

○ “Matlab processing: guide to plots” - demonstration of expected QA/QC visualizations

● NGS coding standards document

● System configuration information for NGS equipment at antenna calibration facility

● Sample data sets for testing and benchmarking the “Data Analysis” system, with inputs

(data tables of phase observations, satellite positions, and robot positions) and outputs (individual and type mean ANTEX)

5.4 Deliverables

addition to all the source code which they must delete at their end at the end of the project:

● A build script that builds and deploys apps on Windows/Linux servers as desired. NGS has standardized "ant" as a build and deployment scripting language. Apps should build and deploy without requiring specific knowledge of them.

● Include test cases, test data, sample runs, and performance benchmarks so that NGS can replicate these. Any discrepancies identified shall be resolved.

● If the runtime environment has external dependencies, those dependencies must be identified and documented.

● The apps shall implement a logger to capture runtime errors and exceptions to help programmers and admins troubleshoot issues.

At the conclusion of the contract, once all deliverables are provided to NGS, all source code, test data, etc., must be destroyed by the awardee

The contract has a one-year period of performance (six months for Task 1, and six months for Tasks 2 and 3), reflected in the deliverable’s timeline. Task 3 should be done after completing Task 1 that is the highest priority or in parallel if the awardee resources allow that. It is acceptable to conduct Tasks 2 and Task 3 in parallel.

Page 18 of 25 Revised 5/18/2026

3.1 Kickoff meeting and code documentation receipt/review.

Within 1 month after completion of Task 1

3.2 Profile the collection and pre-processing Perl 5 codes

(collectAntcalDataGNSS.pl and preprocessAntcalData.pl) and the solutions Matlab code (antcal_loadData.m, antcal_solve.m, typeMeanPrep.m, typeMean.m). Demonstrate an understanding of the current solution methodology, and propose software and UX design for the new application.

Within 2 months after completion of Task 1

3.3 Write new Python code to implement Antenna Calibration and visualize the results.

Within 2 months after completion of Task 1

3.4 Deliver the data collection system to NGS, and assist NGS personnel as they test the data collection process in the production environment.

Within 3 months after completion of Task 1

3.5 Write new Python code to process antcal data and visualize the results. Within 3 months after completion of Task 1

3.6 Demonstrate that the data processing/visualization system, using the provided input products, produces ANTEX individual and type mean products equivalent to the provided output products.

Within 4 months after completion of Task 1

3.7 The contractor delivers the full application, including a GUI design and documentation to the NGS project manager.

Within 5 months after completion of Task 1

3.8 Assist NGS personnel as they migrate the final application to NGS computing resources.

Within 6 months after completion Task 1

3.9 Oral briefings on status to one or more NGS employees, to be determined by NGS

Every 2 weeks, and after each deliverable

3.10 Develop responses to FOIA and information requests As required

5.5 Technical Point of Contact

Page 19 of 25 Revised 5/18/2026

Charles Geoghegan and Ben Erickson will be technical Points of Contact for the unified tool that will be responsible for technical guidance to the contractor and should a dispute arise shall inform the Contracting Officer. These are not a personal services contract and the Technical Point of Contact or no other Federal employee will personally “supervise” the contractor.

VI. TECHNICAL COMPETENCIES

A technically acceptable contractor will demonstrate the following areas of expertise:

● Understanding of geodetic procedures and surveying technologies in order to conduct reduction, least square adjustments, datums and datum deficiencies, and origin information.

● Software based on user requirements and GUI design

● Python programming with UX

● Experience with modeling and removing errors from GNSS phase data

● C and C++ programming

● Experience with the Eigen C++ library at minimum, with LASER experience preferred

● Understanding of the models and algorithms used for GNSS positioning

● Code profiling

● Efficient manipulation of large matrices

● Construction and solving of large sets of normal equations

● Least squares solutions with constraints

VII. IT SECURITY REQUIREMENTS AND GOVERNMENT FURNISHED

MATERIALS

The Assessment and Authorization (A&A) requirements of Clause 48 CFR 1352.239-72 do not apply, and a Security Accreditation Package is not required.

The following is a list of relevant information the Department of Commerce (DOC) Information Technology (IT) Security takes into consideration when assessing the security requirements and risk for procuring IT products and services.

a) The Contractor shall only supply Information Technology (e.g., hardware, software, firmware, etc.) and/or product license and shall not require the use of any contractor owned equipment. The contractor will not have remote access to any government owned equipment.

The Contractor shall ensure the acquiring Information Technology provided disables “phone home” or similar capabilities.

Page 20 of 25 Revised 5/18/2026

b) Product support and supporting documentation allows for the sanitization of the acquiring Information Technology and/or product license upon the disposal of the product. Product shall allow the use one of the approved methods for secure destruction of data/information including unclassified but sensitive information. Approved methods include NIST Special Publications 800-88 Guidelines for Media Sanitization (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf) or the National Security Agency in the Media Destruction Guidance (https://www.nsa.gov/Resources/Media- Destruction-Guidance/).

c) The acquiring information technology is engineered for trustworthy and security that is consistent with the engineering-based trustworthy secure solutions as outlined in NIST Special Publication 800-160 Version 1, Revision 1 Engineering Trustworthy Secure Systems (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v1r1.pdf) and NIST Special Publication 800-160, Volume 2, Revision 1 Developing Cyber-Resilient Systems: A Systems Security Engineering Approach (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160v2r1.pdf).

d) The acquiring information technology complies with Office of Management and Budget Memorandum M-07-18 Ensuring New Acquisitions Include Common Security Configurations and the Federal Acquisitions Regulations (FAR) 39.101(d) regulations require NIST common security configuration checklists including United States Government Configuration Baseline (USGCB) initiative. More information is available at National Checklist Program (NCP), (https://nvd.nist.gov/ncp/repository), the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low-level guidance on setting the security configuration of operating systems and applications. The acquiring information technology considers the following requirements:

i. Software procured meets the standard installation, operation, maintenance, updates and/or patching of software shall not alter the configuration settings from the approved USGCB/other secure configuration.

ii. Applications designed for normal end users run in the standard user context without elevated system administration privileges.

iii. Supporting documentation or reference(s) that describes the security capabilities, the design and development processes and the testing and evaluation procedures used by the product or services being provided for this acquisition.

iv. Supporting documentation or reference(s) that describes all product or service updates and enhancements as they are implemented. The product or service supporting documentation could be the user and system administrator guides, which is documents the functional properties of the security controls employed to permit the analysis and testing of the security controls.

Page 21 of 25 Revised 5/18/2026

e) The acquiring information technology complies with the Homeland Security Presidential Directive 12 (HSPD-12) Policy for a Common Identification Standard for Federal Employees and Contractors requirements from FAR 4.1302 stating: (a) In order to comply with Federal Information Processing Standard (FIPS) 201-3 Personal Identity Verification (PIV) of Federal Employees and Contractors (https://doi.org/10.6028/NIST.FIPS.201-3), agencies must purchase only approved personal identity verification products and services, (b) Agencies may acquire the approved products and services from the GSA, Federal Supply Schedule 70, Special Item Number (SIN) 132-62, HSPD-12 Product and Service Components, in accordance with ordering procedures outlined in FAR Subpart 8.4.

f) The acquiring information technology complies with Internet Protocol Version 6 (IPv6) requirements from FAR part 11.002 requirements that state the agency Chief Information Officer can waive this requirement provided the acquisition requirements documents the appropriate technical capabilities defined in the USGv6 Profile available in the NIST Special Publication (SP) 500-267 (https://www.nist.gov/programs-projects/usgv6-program) and the corresponding declarations of conformance. To meet this requirement each DOC acquisition of IP protocol technology must express requirements for IPv6 capabilities in terms of the USGv6 Profile (i.e., using the USGV6 Capabilities Check List) and vendors must be required to document their product’s support of the requested capabilities through the USGv6 test program (https://www.nist.gov/programs-projects/usgv6-program/usgv6-revision-1) using the USGv6 Suppliers Declaration of Conformity.

Page 22 of 25 Revised 5/18/2026

VIII. APPENDIX A - ILLUSTRATION OF THE PROPOSED NGS GRAPHICAL USER

INTERFACES FOR TASK 2

Main Menu

Data prep window for generating a full observation file and then reducing the observations

Page 23 of 25 Revised 5/18/2026

IX. APPENDIX B - StarNet file structure for input files and observation reports (Full, Reduced, and Adjusted)

B.1 Star*Net example for a Simple Level Network with 4 Fixed…