This document provides an overview of the OEM6 and OEM7 SPAN® logs used for post-processing in Inertial Explorer® (IE) 8.70. A list of required logs outlines the minimum logging requirements needed for post-processing. Additional logs are recommended for increased ease of use, specific applications, and troubleshooting purposes. Example lists of commands and logs are provided at the end of the document, which can be used as templates for basic data collections.
There are multiple logging formats which can be used to record NovAtel receiver data. Table 1 provides a summary of these formats and select examples. It is recommended to log data records in binary format, as the NovAtel/OEM decoder in IE supports only binary logs. After data conversion, all decoded logs will be displayed in the conversion summary. Further details on data types and log formats can be found in the OEM User Manuals.
Table 1: Logging Different Formatting Types
The choice of logging triggers depends on the log itself, and how the data is used in post-processing. Each log trigger outputs the current message immediately after it has been called.
ONCE: Outputs the current message only once.
ONCHANGED: The log is output only when the values in the message change.
ONNEW: The log will be output every time the log is updated. This ensures that internally triggered logs are also output.
ONTIME <#>: The log will continually be requested and output every <#> seconds during data collection.
The choice between ONNEW and ONCHANGED is dependent on the type of data collection and user preferences. The ONNEW trigger can result in larger files with duplicate logs that are ignored by IE’s converter. The ONCHANGED trigger is preferable to avoid duplicates and minimize file size. However, if the ONCHANGED log request is made before the logging file is opened the log will not be triggered until a value has changed. This may cause issues in short surveys, as slow changing logs (such as RAWEPHEMB) may not be logged during the data collection period. For this reason, ONNEW is suggested for short surveys.
If using ONCE, the user must ensure that the logging file has been opened before the log call. If not, the information will not be saved anywhere in the file, as the log will not be called again.
While in INS operation, the highest rate that GNSS logs should be requested is 5 Hz (0.2 seconds). GNSS logs include, but are not limited to, RANGECMPB, BESTPOSB, BESTGNSSPOSB, RTKPOSB and PSRPOSB. The recommended rate for all GNSS logs is 1 Hz for GNSS and INS Integration.
The following list outlines the logs required and recommended for post processing in IE. For differential processing, a subset of these logs must be logged at the base. The ‘Required for’ note describes how IE uses the data provided in the log. Suitable ‘Alternative’ logs are also listed, which can be selected based on user preference. The ‘Used for’ note describes how IE uses the data provided in the log. Not all logs will be used in IE post-processing, but can be ‘Helpful for’ troubleshooting purposes and record keeping. Finally, ‘Requirement’ notes outline prerequisite steps needed for the successful output of the log.
These logs are required to collect the raw data necessary for post-processing.
The following logs are not required for post-processing, but provide information that aids in project setup, data analysis, and troubleshooting. A number of logs specified below are used for extracting real-time trajectories to a Waypoint readable format. Instructions on how to generate these files are provided in Appendix A: Full Project Example.
This section outlines the logs required for integration of application-specific data in Inertial Explorer. Please note that this list contains only the logs required in IE, and does not encompass all logs and commands required for the proper set up and real time tracking of these systems. Further information on application-specific setup can be found in the OEM User Manuals.
The following Ephemeris logs can be decoded in IE. RAWEPHEMB and GLOEPHEMERISB are considered as Required Logs, but are listed here for completion.
* The log GALEPHEMERIS is being deprecated and will eventually be replaced by GALINVAEPHEMERIS and GALFNAVEPHEMERIS. As these two new logs are not yet supported by IE, the continued use of GALEPHEMERIS is recommended.
This section provides an example of how a well-planned list of logs and commands will allow for an efficient work flow in Inertial Explorer. The following SPAN data collection uses GPS and GLONASS constellations, a dual antenna system, and set up with the default IMU orientation (standard Y forward, Z up, X right). The equivalent OEM6 and OEM7 logs and commands used in this data collection are listed below to provide a summary example. The figures on the following pages demonstrate how the information from these logs is used in IE to convert and generate files, and auto-fill set up parameters for the project.
Data conversion can be done with Convert Raw GNSS data to GPB Utility. Use the “Get Folder” button to browse to the folder containing the raw GNSS data, and then use the “Auto Add All” feature to add all raw GNSS data, including NovAtel data, for conversion. A number of logs, specified in the Recommended Logs list, are used to generate real time trajectory files during data conversion. After the raw data file is added, click either the Global Options or Options button, and check off Create trajectory files for supported records. After the data has been converted, the trajectory files can be loaded and viewed in IE, to compare against the post-processed solutions.
Figure 1: GNSS Raw Data Converter Utility – Auto-detect the NovAtel OEM7 / SPAN Receiver Type
Figure 2: GNSS Raw Data Converter Utility - Generate real time trajectory files during data conversion
as the original raw data file. As shown in Figure 3, the data used in this example generated the *.epp, *.gpb, *.hmr, *.imr, *.sta and real time trajectory files (*.fp and *.ft). Table 2 lists all of the files which can be produced upon data conversion; not all data sets will contain the relevant data to produce all of these files. When the GPB file is loaded into the project as a Rover or Master, the other file types are also added.
Figure 3: Files generated after raw data conversion of this example data set.
Table 2: All possible file types generated from data conversion
With this data logged, converted, and added to the project, users can then auto-fill a variety of parameters in the Processing Settings. Figure 4, Figure 5, and Figure 6 show the parameters filled using the logs recorded in the example data collection.
Figure 4: When adding a remote or base station file, the Antenna Profile will be auto-filled using information from the THISANTENNATYPEB log, read in from the STA file.
Figure 5: The Lever Arm and IMU rotation will be auto-filled from the IMR file.
Figure 6: Heading parameters are auto-filled from the HMR file. The Gimbal Mount and Distance Measuring Instrument values are auto-filled when MMR and DMI files, respectively, are added to the project.