Processing block

Description

The processing block is used to configure how Qinertia should process the mission. You can select the processing mode, the motion profile dynamics and even select which GNSS base stations should be used in the solution.

Processing modes

Qinertia offers several processing modes from GNSS only PPK (Post Processed Kinematic) to fully automated tightly coupled INS solution. Qinertia also features different GNSS augmentation algorithms from single base station to Virtual Base Station (VBS) network to deliver a centimer-level accuracy in all situations.

Auto/Manual modes

Qinertia CLI has been designed from the ground up to offer a unique and advanced automatic processing mode. In this mode, Qinertia picks up the best processing algorithm based on available base stations and mission profile. However, Qinertia CLI also gives a full manual control on how the processing is done to address all our integrator needs:

Manual mode: In manual mode, you have a full control and you explicitly tell Qinertia to process the data using a dedicated processing algorithm. If the selected processing mode requires GNSS base station data, you are responsible to tell Qinertia which base station has to be used. You can however ask Qinertia to download base station data from a CORS network and/or import your own base stations data.
Automatic mode: Qinertia comes with a powerful automatic processing mode that tries to pickup the best GNSS augmentation solution based on the mission data and available base stations. This automatic processing mode first download all surrounding base stations. Then, it combines the downloaded base stations with the ones optionally imported by the user to select the best available GNSS processing mode in that order of preference:
1. Single base Station PPK
2. Virtual Base Station PPK
3. Post Processed PPP (Precise Point Positioning)

Processing Types

The table below list all available processing modes for GNSS only processing:

Mode	Description
`gnssAuto`	Automatic Selection: Process RAW GNSS data to output a GNSS only post processed solution but let Qinertia select the best algorithm according to available base station and mission data.
`gnssSingleAuto`	Single Base station Automatic mode: Qinertia will pickup the best processing mode between `gnssSingle` and `gnssSingleIonoShield` depending of current ionospheric activity and base station characteristics. You have to provide a valid GNSS base station as described in Base Station Block.
`gnssSingle`	Single base station Short Baseline mode: Qinertia will process RAW GNSS data to compute a GNSS only PPK solution using a single base station with standard short base line algorithms . You have to provide a valid GNSS base station as described in Base Station Block.
`gnssSingleIonoShield`	Single base station IonoShield mode: Qinertia will process RAW GNSS data to compute a GNSS only PPK solution using a single base station and IonoShield algorithms. You have to provide a valid GNSS base station as described in Base Station Block.
`gnssVBS`	Virtual Base Station Network: Qinertia will process RAW GNSS data to compute a GNSS only PPK solution using a Virtual Base Station network. The VBS is created using the bases stations specified in the Base Station Block array. The processing will fail if the specified base stations are not suitable to create a valid VBS network.
`gnssPPP`	Precise Point Positioning (PPP float): Qinertia will process RAW GNSS data to compute a post processed Precise Point Positioning float solution. The PPP solution is available worldwide but it offers a lower accuracy and longer convergence time than other processing modes.

Please find below all processing modes applicable for Inertial Navigation System (INS) processing:

Mode	Description
`insAuto`	Automatic Selection: Process RAW GNSS and IMU data to compute a tightly coupled INS solution but let Qinertia select the best algorithm according to available base station and mission data.
`insSingleAuto`	Single Base station Automatic mode: Qinertia will pickup the best processing mode between `insSingle` and ins`SingleIonoShield` depending of current ionospheric activity and base station characteristics. You have to provide a valid GNSS base station as described in Base Station Block.
`insSingle`	Single base station Short Baseline mode: Qinertia will process RAW GNSS and IMU data to compute a tightly coupled INS solution using a single base station with standard short base line algorithms. You have to provide a valid GNSS base station as described in Base Station Block.
`insSingleIonoShield`	Single base station IonoShield mode: Qinertia will process RAW GNSS and IMU data to compute a tightly coupled INS solution using a single base station and IonoShield algorithms. You have to provide a valid GNSS base station as described in Base Station Block.
`insVBS`	Virtual Base Station Network: Qinertia will process RAW GNSS and IMU data to compute a tightly coupled INS solution using a Virtual Base Station network. The VBS is created using the bases stations specified in the Base Station Block array. The processing will fail if the specified base stations are not suitable to create a valid VBS network.
`insPPP`	Precise Point Positioning (PPP float): Qinertia will process RAW GNSS and IMU data to compute a tightly coupled INS solution using PPP float positioning mode. The PPP solution is available worldwide but it offers a lower accuracy and longer convergence time than other processing modes.
`insLoosely`	INS loosely coupled processing: The mode uses PVT (Position Velocity Time) measurements that are, most of the time, real time GNSS solutions to compute a post processed loosely coupled INS solution. The processing will fail if no valid PVT data has been imported.
`insReprocess`	INS reprocessing: Compute an INS solution in forward only direction using PVT measurements. This processing mode should return the same results as a real time INS solution. The processing will fail if no valid PVT data has been imported.

IonoShield

Qinertia 4.0 introduces the new IonoShield algorithm for single base station processing. IonoShield is ideally suited to cope with high ionospheric activities and also increases tolerance for longer base station baseline.

GNSS Base Stations

The processing block contains a bases parameter that is an array of Base Station Block entries. This array lets you import GNSS base station data and also list the base stations to use in the solution.

This bases parameter has different usage scenarios depending on the selected processing mode as shown below:

Automatic: The parameter is optional and can be used to add user base stations in addition to the ones automatically downloaded by Qinertia. All these base stations will be taken into account by Qinertia to pick up the best GNSS algorithm.
Single Base: The parameter is required to specify the base station to use in the PPK solution. The array should contain only one base station otherwise the processing will fail.
Virtual Base Station: The parameter is required to specify a list of base stations to use in the VBS network. At least three bases stations are needed to successfully create a VBS network.
Precise Point Positioning: The parameter is ignored as PPP doesn't use base station data at all.
INS loosely or reprocessing: The parameter is ignored as INS loosely/reprocessing uses PVT data directly.

Qinertia is fully integrated with CORS (Continuously Operating Reference Stations) network and can download, for you, base stations data from several CORS providers. It can also use base stations imported by the user and even combine both downloaded and user base stations.

To support this feature, the Base Station Block can be used in two different ways:

If you specify GNSS base station data files, Qinertia will import this base station.
lf you don't specify data file but just a base station name, it will force Qinertia to download this base station and use it.

JSON Block Sample

INS automatic mode

The example below uses the automatic mode to let Qinertia pickup up the best GNSS augmentation solution. Qinertia will download automatically all needed resources for you.

"processing": {
  "motionProfile": "automotive",
  "type": "insAuto"
}

JS

Single Base Station (User defined geodesy datum)

The processing block below illustrate an INS tightly coupled solution using a user supplied Emlid Reach RS2 base station. The base station position is read from the base station file but the frame (datum) is supplied by the user.

This sample also illustrate a full geodesy configuration with origin datum set to default WGS84 and the CRS set to French legal reference system.

"processing": {
  "motionProfile": "uav",
  "type": "insSingle",
  "processFrom": "2020-04-27T09:00:00Z",
  "processUntil": "2020-04-27T09:15:00Z",
  "singlePass": true,
  "bases": [
    {
      "positionMode": "published",
      "position": {
        "frame": "EPSG:1313"
      },
      "data": [
        "base/emlid-reach-rs2.ubx"
      ]
    }
  ],
  "geodesy": {
    "originDatum": "EPSG:6326",
    "projectCrs": "EPSG:9794",
    "transformations": [
      {
        "fromDatum": "EPSG:6326",
        "toDatum": "EPSG:1313",
        "transformation": "SBG:0001"
      }
    ]
  }
}

JS

Single Base Station (PPP survey)

The processing block below illustrate an INS tightly coupled solution using a user supplied base station. The base station position is not known precisely so the user ask Qinertia to compute a PPP static solution before starting the INS processing.

"processing": {
  "motionProfile": "marineHarshSurvey",
  "type": "insSingle",
  "processFrom": "2020-04-27T09:00:00Z",
  "processUntil": "2020-04-27T09:15:00Z",
  "singlePass": true,
  "bases": [
    {
      "positionMode": "ppp",
      "data": [
        "base/30232770.16g",
        "base/30232770.16n",
        "base/30232770.16o",
        "base/30232780.16g",
        "base/30232780.16n",
        "base/30232780.16o",
        "base/30232790.16g",
        "base/30232790.16n",
        "base/30232790.16o"
      ]
    }
  ]
}

JS

Virtual Base Station

In this example, we will ask Qinertia to download six bases stations from IGNRGP CORS network and combine these base stations with one user supplied base station to create a VBS network. We also force one base station to be the master VBS base station.

"processing": {
  "motionProfile": "uav",
  "type": "insVBS",
  "bases": [
    {
      "name": "DOMP"
    },
    {
      "name": "SEES",
      "forceAsVbsMasterBase": true
    },
    {
      "name": "MAUP"
    },
    {
      "name": "BRMZ"
    },
    {
      "name": "MAN2"
    },
    {
      "name": "COVI"
    },
    {
      "positionMode": "manual",
      "position": {
        "latitude": 48.018614136,
        "longitude": 0.155282549,
        "height": 128.174,
        "frame": "EPSG:1313"
      },
      "data": [
        "base/41232770.16g",
        "base/41232770.16n",
        "base/41232770.16o",
        "base/41232780.16g",
        "base/41232780.16n",
        "base/41232780.16o",
        "base/41232790.16g",
        "base/41232790.16n",
        "base/41232790.16o"
      ]
    }
  ]
}

JS

Real time RTCM stream

Qinertia can parse real time RTCM data stream and use it as a base station. The following example showcase this feature by simply setting the data field to diffCorrOrigin.

"processing": {
  "motionProfile": "uav",
  "type": "insSingle",
  "processFrom": "2020-04-27T09:00:00Z",
  "processUntil": "2020-04-27T09:15:00Z",
  "singlePass": true,
  "bases": [
    {
      "positionMode": "manual",
      "position": {
        "latitude": 48.91,
        "longitude": 2.17,
        "height": 94.47,
        "frame": "EPSG:1313"
      },
      "data": "diffCorrOrigin"
    }
  ]
}

JS

Manual Rejections

You can create manual areas where INS aiding such as GNSS position are rejected forcing pure inertial position. This feature is reserved for advanced users for troubleshooting and setup validations. It should not be used in normal production environment as Qinertia embeds advanced filters to automatically reject aiding when necessary.

Please find below a simple example that reject GNSS position and velocity measurements as well as true heading information for 200 seconds.

"processing": {
  "motionProfile": "automotive",
  "type": "insAuto",
  "rejection": {
    "begin": "2022-12-25T09:02:00Z",
    "end": "2022-12-25T09:05:20Z",
    "useAidings": {
      "pvt": "never",
      "hdt": "never"
    }
  }
}

JS

Create Project From CLI file

You can create project in Qinertia from a full or partial CLI file. This is very helpful to both offer a nice third party IMU support with project settings reading like feature as well as to debug your CLI files.

The following example, shows the only parameter that is read and used when you create a project from a CLI file in Qinertia GUI.

"processing": {
  "motionProfile": "marine"
}

JS

Block Specification

Parameter	Type	Description
`motionProfile`	enum	Select the motion profile / vehicle dynamics to use for the processing: `airplane`: Airborne vehicles that have a likely forward travel direction `automotive`: Ground vehicles such as cars with low to no side slip `helicopter`: Rotary wing vehicles that don't have a specific travel direction `marine`: Marine applications such as bathymetry and vessel monitoring & control `marineHarshSurvey`: Dedicated to high performance bathymetry in high multi-path environment `pedestrian`: Used for very low velocity applications that have no likely forward travel direction `truck`: Ground vehicles such as trucs or cars with steered rear axle that experience minor slide slip `uav`: Designed for highly accurate surveys with UAV (fixed or rotary wings) `static`: Assumes static GNSS RAW observables to improve accuracy (GNSS only).
`type`	enum	Select the processing mode such as GNSS only or INS tightly coupled solution: `gnssAuto`: Automatic GNSS only processing `gnssSingleAuto`: Single base station GNSS only processing (auto short/IonoShield selection) `gnssSingle`: Single base station GNSS only processing (short baseline algorithm) `gnssSingleIonoShield`: Single base station GNSS only processing (IonoShield algorithm) `gnssVBS`: Virtual Base Station network GNSS only processing `gnssPPP`: Precise Point Positioning GNSS only processing `insAuto`: Automatic INS tightly coupled processing `insSingleAuto`: Single base station INS tightly coupled processing (auto short/IonoShield selection) `insSingle`: Single base station INS tightly coupled processing (short baseline algorithm) `insSingleIonoShield`: Single base station INS tightly coupled processing (IonoShield algorithm) `insVBS`: Virtual Base Station network INS tightly coupled processing `insPPP`: Preceise Point Positioning INS tightly coupled processing `insLoosely`: INS loosely coupled processing (uses PVT) `insReprocess`: INS reprocessing (uses PVT)
`mechanicalEstimationPass`	bool	Set to `true` to estimate mechanical installation parameters and then automatically execute a second run to get the final post process solution. Only the parameters that have been flagged to be not precise in the Settings block are estimated.
`processFrom`	string	ISO 8601 UTC date time which specify from which point in time we should process data.
`processUntil`	string	ISO 8601 UTC date time which specify until which point in time we should process data.
`singlePass`	bool	If set to true, force Qinertia to process the log only using one passe instead of the default three passes.
`bases`	array	Array of GNSS base stations to use and import in the processing. See below for object details. The parameter can be required or optional according to the selected processing mode: Required for: `gnssSingle`, `gnssVBS`, `insSingle`, `insVBS` Optional for: `gnssAuto`, `insAuto` Ignored for: `gnssPPP`, `insPPP`, `i` `nsLoosely`, `insReprocess`
`geodesy`	object	Define the geodesy configuration to use for this project. See below for object details. If this block is omitted, Qinertia will use the automatic mode.
`rejection`	array	Optional list of rejections areas to forbid the INS to use some aiding such as a GNSS position, true heading, odometer velocity and so on. Please check the rejection object definition below.

Base station sub block

Parameter	Type	Description
`name`	string	Base station name that is required to explicitly tell Qinertia to download and use a base station from a CORS network. In this case you should NOT specify any data files. Otherwise, if you have specified data files, this optional parameter can be used to override the base station name read from the files.
`receiver`	enum	Manually specify the base station GNSS receiver model so Qinertia can tune its GNSS algorithms to deliver optimal results. The available GNSS receiver models are: `auto`: Try to detect the model from imported data or fallback to `default` `default`: Use this model if your GNSS receiver is not listed `ubloxF9`: L1/L2 u-blox RTK receiver with RAW data `septentrio`: Survey grade Septentrio receivers `novatel`: Survey grade Novatel receivers `trimble`: Survey grade Trimble GNSS receivers `javad`: Survey grade JAVAD receivers `ashtech`: Survey grade Trimble/Astech receivers `topcon`: Survey grade Topcon receivers `spectra`: Survey grade Spectra receivers `leica`: Survey grade Leica receivers If not specified, the receiver model is detected automatically. If the model can't be detected or is not found the `default` model is used.
`positionMode`	enum	Define which position Qinertia should use for this base station: `auto`: Let Qinertia select the best available base station position between PPP and the published one. `manual`: The base station position is read from the position.x parameters of this block. `ppp`: Automatically compute a static PPP on the base station data and use this position. `published`: Use the position from the CORS provider database or from the the RINEX / base station file. If you don't specify this parameter, Qinertia will use the `auto` default mode.
`position.latitude`	number	Base station latitude in decimal degrees and positive north. Required if `positionMode` is set to `manual`.
`position.longitude`	number	Base station longitude in decimal degree and positive east. Required if `positionMode` is set to `manual`.
`position.height`	number	Base station height above ellipsoid in meters and positive upward. Required if `positionMode` is set to `manual`.
`position.frame`	string	Base station position frame/datum full code (`authority:code`). Optional for `auto` and `published` modes. Required if `positionMode` is set to `manual`.
`antenna.type`	string	Antenna ANTEX identifier that can ovverides the one read from the GNSS data. The valid options are: `auto`: to let Qinertia detect the antenna from the input GNSS data and fallback to generic if not antenna model is found `generic`: to use a default antenna model that doesn't apply any APC/ARP or L1/L2 offset `custom`: to specify your own L1/L2 ARP to APC offsets. In this case, the offsets node is mandatory. any valid ANTEX id such as `"TWIVSP6037L NONE"` for example If not specified, the default `auto` option is selected.
`antenna.offset.l1`	number	Define the ARP to L1 phase center vertical offset in centimeter for GPS signals. This field is applicable and mandatory only if `antenna.type` is set to `custom` value.
`antenna.offset.l2`	number	Define the ARP to L2 phase center vertical offset in centimeter for GPS signals. This field is applicable and mandatory only if `antenna.type` is set to `custom` value.
`antenna.height`	number	Antenna height offset in meters to apply between the base position and the selected reference point (APC or ARP).
`antenna.reference`	enum	Choose where the base station position is referenced to: `arp`: The position is referenced to the Antenna Reference Point (default). `apc`: The position is referenced to the Antenna Phase Center point.
`data`	array/enum	This field can either be an array of files or an enum value: Array of GNSS data files to import for this base station. The paths can be either relative or absolutes. Enum to either use data from online CORS providers or use imported real time differential RTCM corrections: `online`: download base station data from SBG Systems CORS database. `diffCorrOrigin`: import RTCM data received in real time during mission acquisition. If not specified, the online option is used and Qinertia will download base station data automatically from CORS databases.
`rtcmBaseId`	string/number	The id of the RTCM base station to import if there are multiple base stations in a RTCM stream. Use the "`auto`" value to let Qinertia automatically pickup the best base station from the RTCM stream. If not specified, the "`auto`" value is used by default.
`forceAsVbsMasterBase`	boolean	If set to true, force this base station to be the master base station in a VBS network. This is only applicable for VBS processing modes such as `gnssVBS` or `insVBS`. If not specified or set to false, Qinertia will automatically pickup the most suitable master base station within the VBS network.

Relative Paths

Relative paths are referenced to the JSON process file unless you have specified a base path with the --input option while invoking Qinertia command line.

Geodesy sub block

Defines the geodesy configuration to use for the project.

All geodesy resources such as CRS, datums, transformations between datums and so on are referenced using a unique authority:code format.

For example, if you use EPSG authority, the format should look like EPSG:9794 for the RGF93 v2b / Lambert-93 definition.

You can easily get all available authority:code definitions from Qinertia GUI.

Parameter	Type	Description
`useAutomaticMode`	boolean	Set to `true` to use the simplified automatic mode. When set to `true`, the other fields in this block as ignored.
`projectCrs`	string	Project CRS (Coordinate Reference System) full code (authority:code) This field is required if `useAutomaticMode` is false.
`originDatum`	string	Origin datum full code (authority:code) This field is required if `useAutomaticMode` is false.
`transformations`	array	Override the transformation to use between datums that would otherwise be automatically selected by Qinertia. One entry per transformation to override.
`transformations[].fromDatum`	string	Source datum full code (authority:code)
`transformations[].toDatum`	string	Target datum full code (authority:code)
`transformations[].transformation`	string	Transformation full code (authority:code)

Automatic Geodesy

Qinertia implements a simplified/automatic geodesy mode. This mode automatically pickup the most relevant CRS / Datums configuration based on the project configuration.

For example, if you select a GNSS base station in RGF93 v2b, Qinertia will consider the project datum to be RGF93 v2b to express the processing in the same datum as the base station.

Rejection sub block

Defines a single rejection entry with a being/end epoch time. You can create as many rejections as you would like but they should not overlap.

For each rejection entry, you can define for each aiding input if it should be rejected or not from the INS solution. For example, you can decide to only reject the GNSS true heading but still use the GNSS position.

At least one useAidings item should be specified such as all or pvt.

Parameter	Type	Description
`begin`	string	ISO 8601 UTC date time when the rejection area starts.
`end`	string	ISO 8601 UTC date time when the rejection area ends.
`useAidings.all`	string	The `useAidings.all` property is exclusive with other specific aiding below. Use the `"never"` value to reject all aiding inputs.
`useAidings.gnss`	string	Set to `"never"` value to completely reject GNSS aiding (ie position and velocity data). This rejection applies to loosely and tightly coupled modes and forbid GNSS usage in the INS solution.
`useAidings.hdt`	string	Set to `"never"` value to reject dual antenna GNSS true heading measurements.
`useAidings.dvl`	string	Set to `"never"` value to reject Doppler Velocity Log aiding.
`useAidings.odo`	string	Set to `"never"` value to reject Odometer (DMI) wheel speed aiding.

GNSS only processing

Rejections are only relevant for INS processing modes and have no effect for GNSS only processing.

Download PDF