EIVA Helpdesk Support

Q: How does NaviPac calculate the GPS tide, e.g. when also applying a reduction file?

A: NaviPac calculates a GPS tide value in every navigation cycle using the steps below. The result can be stored to a file (.npt) and/or sent to NaviScan.

Calculation steps

1. Raw GPS height(ellipsoidal height from the GGA string) is taken from the GPS used for positioning:
   • Prioritized positioning: the GPS in priority group 1.
   • Combined positioning: all GPS systems are in one group.
   • NaviPac uses at most the first two GPS systems it finds in that group: the weighted mean of their heights if their timestamps are within 0.1 s, otherwise the newest height.
   • GGA quality 4 (RTK Fixed) counts as the highest quality. RTK Float (5) and DGPS count as lower quality. With Discard height if not highest quality enabled (Project settings → GPS), only RTK Fixed heights are used, and the tide pauses while the quality is lower. With the setting off (default), lower-quality heights are used as well; NaviPac only raises an alarm when the GPS drops out of RTK Fixed.
2. The height is compensated for antenna offsets (3D, using roll/pitch), giving the CRP height.
3. Based on the position, a geoidal separation is found and subtracted. Height reduction can be: EIVA geoidal file (e.g. a .vrf reduction file), EGG97, GCG05, VORF, US GC09 or a manual separation, and an optional additional separation can be added on top.
   The tide refers to the vertical datum of the selected model (e.g. Chart Datum/LAT with a VORF or .vrf reduction file, or MSL/national height datum with a geoid model).
4. The heavefrom the motion sensor is taken out of the value. NaviPac transfers the heave from the MRU to the CRP using the MRU offsets and roll/pitch.

   Note:

   • No motion sensor in the setup: NaviPac does not calculate a GPS tide (no .npt values, nothing sent to NaviScan).
   • Motion sensor switched off, or assigned to another object than the vessel: the same as no motion sensor; no GPS tide is calculated.
   • Motion sensor without heave (e.g. a roll/pitch-only instrument): the GPS tide is calculated with heave = 0, so the wave motion is not removed. Use a motion sensor that outputs heave, and check in Raw data that heave is received.

   • Example: An Octans MRU is giving vessel HPR and gyro, with XYZ of 0,0,0. Does this MRU require lever arms set for CRP XYZ?
     Yes. NaviPac needs to calculate the heave value at the CRP, and to do so it needs the offsets from the MRU to the CRP.

5. The Waterline offset is added (compensated for roll/pitch). Waterline is the vertical offset from the CRP to the waterline, positive up. It is normally negative, because the CRP is usually above the waterline. Example: CRP 2 m above the waterline → Waterline = −2.0, and the tide is 2 m lower than with Waterline = 0.
   • With Waterline = 0, the output is the height of the CRP above datum, not the water level.
   • With Waterline set, the output is the water level above datum.
   • A fixed Waterline does not follow draught changes (fuel, ballast, cargo); use a draught sensor for that (step 7).
6. We now have the CRP height with the short-term waves taken away. This is the GPS tide.
7. If a draught sensor is defined (Draught sensor / Draught channelin the GPS tide settings):
   • Use the pressure value. The draught sensor output must be in dbar.
   • Subtract the surface pressure. The surface pressure comes from NaviPac Global settings → Depth calculation parameters and is entered in atm (default 1.00 atm = 10.13 dbar).
   • Convert to depth: NaviPac uses the pressure difference in dbar directly as metres (1 dbar = 1 m). The water density and gravity settings are not applied. In sea water 1 dbar is about 0.99 m, so the draught is about 1% too large (e.g. about 5 cm at 5 m draught).
   • Compensate for the offset of the draught sensor (using roll/pitch).
   • We now have the draught (depth) of the CRP.
   • Apply it to the tide: the deeper the CRP is in the water, the higher the water level. Example: CRP 2 m below the water surface → the tide is 2 m higher than without the draught sensor.
   • Notes
   • The draught correction is applied in addition to the Waterline offset. When a draught sensor is used, set Waterline = 0, otherwise the offset is applied twice.
   • If the draught sensor stops sending data, NaviPac keeps using the last received value. Monitor the draught sensor input during the survey.
   • If no draught value has been received since start-up, the draught correction is 0, without any warning.
8. The result goes into a moving average over the Averaging interval (see below), and the averaged value is output.

GPS tide settings in NaviPac

Output

• File: ddmmyy.npt (e.g. 131026.npt for 13 October 2026), written to the NaviPac data folder, one file per day. Each new file starts with the header line $NPTide,Date,Time,Tide,GPS H. If the data folder cannot be opened, a warning pops up and storing to file is switched off for the rest of the session.
• Format: $NPTide,<Date>,<Time>,<Tide>,<GPS H><CR><LF>
  • Tide: positive above datum, in metres with 2 decimals.
  • Date: dd/mm/yyyy; time: hh:mm:ss.
  • GPS H: ellipsoidal height of the GPS antenna (not reduced to the CRP, no geoid applied), averaged over the averaging interval like the tide. It does not necessarily show the height used for the tide: if two GPS heights are averaged, it shows the height of the first GPS only.
• Time: the date, time and file name use the PC time of the NaviPac PC (including daylight saving time). The NaviPac PC must run on UTC when GPS tide is used. NaviScan also interprets the time in the $NPTide string as UTC. If the PC uses local time, the tide is shifted by the time zone (plus 1 h in summer time) relative to the UTC-based survey data. Example: PC set to UTC+2 with summer time → GGA 09:40 UTC is stored as 12:40 in the .npt.
• Time resolution: 1 second. With a NaviPac cycle faster than 1 Hz and Store continuously on, several values are stored with the same time.
• To NaviScan: the same string is sent in real time (instrument ID 902) while Calculate GPS tide is active, at the same rate as the file: every cycle with Store continuously, otherwise once per averaging interval.

Make sure the tide matches how the depths are reduced in NaviEdit, so draught/waterline is not applied twice or left out.

Requirements for a good GPS tide

• RTK Fixed GNSS (GGA quality 4). RTK Float (quality 5) heights can be off by several decimetres. To use RTK Fixed heights only, enable Discard height if not highest quality (Project settings → GPS).
• A motion sensor with heave, with correct offsets to the CRP. Without a motion sensor, no GPS tide is calculated; without heave, the tide is calculated but wave motion is not removed.
• Correct antenna offsets to the CRP. In Combined mode, all GPS systems must give the same CRP height.
• Correct geoid/reduction model for the area.
• Correct Waterline, or a draught sensor (not both).
• NaviPac PC on UTC (required, see Output).
• Correct time alignment between the GNSS and the motion sensor (see troubleshooting below).

Troubleshooting: the GPS tide shows wave-like noise

The GPS tide only removes the wave motion if the GNSS height and the MRU heave describe the same moment in time. If there is a time offset Δt between them, the error is about Δt × vertical velocity. Example: in a 1 m swell with an 8 s period, a 0.2 s offset gives about ±15 cm of noise.

Typical signs

• The noise is at wave period and grows with the weather.
• The individual antenna heights look clean.
• The noise may build up and drop back over several minutes, because the timing between the GNSS and the NaviPac cycle slowly drifts.

What to check

• That the motion sensor delivers heave (Raw data).
• The time stamping of the GNSS (Use age/time), the delay set for the motion sensor, and ZDA/PPS time synchronisation.
• The MRU and antenna offsets to the CRP.
• The GGA quality indicator.

Workaround: the error oscillates around zero at wave period, so smoothing the tide over 30–60 s or more before applying it to bathymetry in NaviEdit removes most of it.