6.1. DJI PPK (Matrice)

6.1.1. Overview

DJI PPK post-processes the GNSS log that a DJI enterprise drone (Matrice 4E, Matrice 3E, Matrice 350 with Zenmuse P1 – all write the same files) records during a photo flight, against a static GNSS receiver logging on a known point. The result is the position of the camera at every photo in EGSA87 / EPSG:2100 with orthometric heights, ready to import into Agisoft Metashape or Pix4D as camera positions.

The processing engine is RTKLIB (demo5), the same engine as GNSS Processing. The tool chooses the processing settings itself, tries several when the first does not fix, and checks the result against the drone’s own real-time positions.

The tool is found under Drone > Drone Tools > DJI PPK (Matrice).

6.1.2. What you need

  • The drone’s flight folder as copied from the SD card: one .OBS (rover RINEX), .NAV (navigation), .MRK (one line per photo) and the .JPG photos. .RTK and .pbk files are not needed.

  • The base station RINEX: the observation file (.26O, .obs, .rnx) and its navigation files (.26N, .26G, .26L, .26C …). The base must log for the whole flight, preferably a few minutes before take-off and after landing.

  • The EGSA87 coordinates and orthometric height of the point the base stood on, and the antenna height.

6.1.3. Measuring the base antenna height

Enter the vertical height from the mark to the antenna reference point (ARP) – normally the bottom of the antenna mount. The antenna’s own phase-centre offset is then added automatically from the antenna calibration file (ANTEX).

Warning

The antenna height in the RINEX header is only a starting value. Receivers sometimes write a slant height, or a height to the phase centre, there. On the reference flight the Stonex S10 header said 0.1343 m – exactly the antenna’s L1 phase-centre offset – while the measured height was 0.0845 m. A wrong antenna height moves every camera height by the same amount, and nothing in the processing can detect it. The field stays highlighted until you confirm the value.

6.1.4. Workflow

  1. Inputs – choose the flight folder and the base observation file. The navigation files with the same name are found automatically (add others with Add…). The summary shows the files found, how many photos match the .MRK events, and whether the base covers the flight. The output folder defaults to <flight folder>\PPK.

  2. Base – import your point list (name,E,N,H; Greek names and names with spaces are fine) and click the base point, or type its coordinates. If the base was not on a known point, choose From CORS baseline (see Base from a CORS). Check the antenna height and type, pick the EGSA87 transformation (EPSG:1272 or HEPOS, see Datum) and the geoid model (EGM2008 and the HEPOS geoid for Greece are supplied; Constant N uses one value for the whole site) and the ANTEX file (the IGS20 file is supplied). The page shows the base position in WGS84 and notes about the antenna.

  3. Processing – press Run PPK. Automatic is recommended (see below); Manual runs once with the options you set. A 10-minute flight takes 10-40 seconds per attempt. Cancel stops at any time.

  4. Results – one row per photo with E, N, H, their standard deviations and the solution quality (fix, float, none). The tool writes cameras_EGSA87.csv (photo,E,N,H,sdE,sdN,sdH – the format Metashape and Pix4D import directly) and cameras_EGSA87_full.csv (adds WGS84, quality, GPS time and geoid N) to the output folder, plus the trajectory ppk.pos and the processing log ppk_log.txt. The buttons export CSV, XLSX and KML (Google Earth) copies, and PDF report writes the solution as a report (below).

  5. Quality – read the checks before using the result (next section).

  6. Write positions into photos (Results tab, optional) – writes the PPK camera positions into the photos themselves, so Metashape and Pix4D read them without a CSV. See the next section before using it.

6.1.5. PDF report

PDF report (Results tab) writes the whole solution as an A4 PDF: the input files, the settings that went into the run (base point, antenna, transformation, geoid, mode), the result (solution used, photos fixed, PPK vs on-board RTK, base position), the Quality tab as a table with its pass / CHECK marks, a sketch of the cameras and the base, the camera positions table and the processing log. The firm name, logo, accent colour and the surveyor’s signature block come from the Company Info profile shared with the Network Adjustment report (Reports > Company Info in the Network Adjustment window).

6.1.6. Writing positions into the photos

Write positions into photos… overwrites, in the original JPG files, the GPS position the drone stored with the PPK camera position:

  • EXIF GPS latitude / longitude (to 0.000001”, the drone stores 0.001” = 3 cm) and altitude;

  • the DJI XMP tags GpsLatitude, GpsLongitude, AbsoluteAltitude, RtkStdLat/Lon/Hgt (the PPK accuracies) and RtkFlag (50 fixed, 34 float);

  • the Pix4D XMP tags Camera:GPSXYAccuracy and Camera:GPSZAccuracy.

Latitude and longitude are always WGS84. Choose the height with the Height selector next to the button:

  • Ellipsoidal (WGS84 h) – the default and what DJI itself writes in these tags. In Metashape set the camera reference to WGS84 and the project to EGSA87 with the EGM2008 geoid: the result then matches cameras_EGSA87.csv exactly (same EPSG:1272 shift and geoid as the PPK). With the HEPOS transformation the photogrammetry software’s own EPSG:2100 conversion differs from the CSV by up to about a metre; import cameras_EGSA87.csv instead, or write orthometric heights.

  • Orthometric (EGSA87 H) – the height of cameras_EGSA87.csv (ellipsoidal minus the geoid model used for the PPK). Use it when the photogrammetry project reads the altitude as a height above sea level and applies no geoid of its own.

The choice is remembered and the confirmation repeats it.

Warning

The photos are changed in place and the drone’s original positions are not kept (no backup). Only the metadata changes – the image data is copied byte for byte and every file is replaced safely (written to a temporary file first, the file date is kept). DJI’s image signature (DJI-SIG) becomes invalid; this does not affect photogrammetry software. Photos without a PPK position are not touched.

6.1.7. What the automatic mode does

Three problems stop a drone PPK from fixing, and the automatic mode handles each of them:

  • Different signals on drone and base. The Matrice declares two GPS L2 signals but records only one of them; RTKLIB on its own picks the empty one and loses GPS L2 entirely. The tool reads which signals really carry data on both receivers and makes them use the same one (the log shows e.g. G L2: ... -> L2X on both).

  • Low satellites. Satellites near the horizon are often blocked or reflected by the drone and the terrain. The tool tries elevation masks of 15, 20 and 25 degrees, then without GLONASS, then Galileo + BeiDou only, and stops at the first attempt that fixes at least 98 % of the photos and agrees with the drone’s own RTK.

  • Fast climbs and descents. The motion model is tuned for a drone, so the height does not lag behind the drone in climbs and dives.

The camera position is the interpolated antenna position at the shutter time plus the antenna-to-camera offset the drone records for every photo in the .MRK.

6.1.8. Datum

The base point is converted EGSA87 -> WGS84 with the selected transformation and geoid model, and every camera is converted back with the exact inverse. The base therefore lands on its published coordinates (round trip below 2 mm) and the transformation and geoid-datum errors cancel over the site. Heights are orthometric, tied to the height of the base point.

Two transformations are available:

  • EPSG:1272 3-parameter shift – the EPSG / PROJ definition of EPSG:2100, the one Metashape, Pix4D and QGIS use. About 1 m off in absolute terms, which the base cancels.

  • HEPOS 7-parameter + 2 km grid (Ktimatologio) – the official HEPOS transformation, as used by HEPOS receivers and the Hellenic Cadastre: 7-parameter Helmert, TM87 and the 2 km correction grid (data\geoid\*.gsb). Use it with the HEPOS geoid (selected automatically). The base’s WGS84 position is then its HTRS07 position.

Because the base is held on its EGSA87 coordinates either way, the choice changes the cameras only by the local differences across the site: on the 1 km reference flight at most 11 mm horizontally and 7 mm vertically. Choose HEPOS when the results must agree with HEPOS-surveyed points or cadastral data. The Quality tab and the log name the transformation used.

6.1.9. Base from a CORS

When the base receiver was set up on an unknown point, its position can come from a permanent reference station (CORS: HEPOS or a commercial network) that logged at the same time. On the Base tab choose From CORS baseline; the point list is replaced by:

  • CORS observation file – the station’s RINEX for the day (its navigation files with the same name are used automatically; a Stonex *.ALM almanac is ignored, since its orbits are only km-accurate);

  • Published CORS coordinates of the station marker: latitude, longitude and ellipsoidal height, ECEF X/Y/Z (both in the network’s frame, HTRS07 for HEPOS), or EGSA87 E/N/H converted with the selected transformation;

  • CORS antenna height and type – leave empty to use the RINEX header.

Solve base from CORS processes the static baseline CORS -> base (the coarser of the two logging intervals, normally the CORS’s 30 s; first with the broadcast ionosphere, then with ionosphere and troposphere estimated for long baselines) and fills in the base E, N, H with the selected transformation and geoid. Then run the PPK as usual. The run refuses to start if anything that went into the CORS solve was changed afterwards.

  • Use the HEPOS transformation when the CORS coordinates are HTRS07: with the EPSG:1272 shift the absolute position is about 1 m off, since nothing cancels it any more.

  • A fixed solution needs enough common time: about 30 minutes for 10 km, an hour or more for 20-30 km. A float CORS baseline is reported and may be decimetres off.

  • The base antenna height and calibration cancel in the camera positions (they are used for both baselines); only the base mark’s H depends on them.

  • RTKLIB’s formal standard deviations are optimistic; expect roughly 1 cm + 1 ppm of the CORS distance horizontally and twice that in height.

Tested on a 1.3 km baseline between two static receivers (the CORS held at its position): fixed at ratio 16, 31 mm from an independent solution with neither antenna calibrated.

6.1.10. Quality checks

Check

What it means

Photos fixed

Share of photos with a fixed (integer) solution. Below 98 % the float photos are much less accurate (decimetres).

PPK vs on-board RTK: scatter

Spread of the difference between the PPK cameras and the drone’s real-time RTK cameras. A few mm horizontally and 1-3 cm vertically is normal.

PPK vs on-board RTK: offset

A constant difference – the datum of the drone’s RTK correction source. Not an error, reported for information.

Base single-point vs point

The base’s own autonomous position against the coordinates you entered. More than 5 m: wrong point, wrong coordinates or a grossly wrong antenna height.

Base covers the flight

Seconds of base data before and after the flight. Two minutes or more is advised.

Antenna

Height used, RINEX header value and the phase-centre offset from ANTEX; the note explains any mismatch.

Photos <-> MRK

Photos without an event and events without a photo. A missing index in both (a dropped trigger) is normal.

Trajectory gaps at photos

Photos where the solution has a gap.

Base round trip EGSA87

Should be below 2 mm.

The sketch below the table shows the cameras coloured by quality (green fix, olive float, red other) and the base point. Zoom with the mouse wheel and pan by dragging.

6.1.11. Reference result

PY DAM, 17 Sep 2026: Matrice 4E, 542 photos, Stonex S10 on PY7. The first two automatic attempts fixed about half of the photos; the third (mask 25 degrees) fixed all 542, with a scatter against the on-board RTK of 3 mm / 2 mm / 9 mm (N/E/U).

6.1.12. Troubleshooting

  • GNSS engine not available – the engine library must be next to the SurveyTools executable: iqrtk.dll on Windows, libiqrtk.so on Linux. An older library is refused as stale (see the GNSS chapter’s Troubleshooting); use the one shipped with this version.

  • Antenna not in the ANTEX file – check the antenna name (IGS format, e.g. STXS10SX017A) or load a newer ANTEX file. Running without it biases every height by the antenna’s phase-centre offset.

  • The base does not cover the flight – photos outside the base logging time get no position (quality none).

  • Few photos fixed in every attempt – check the base point and antenna height (Quality tab), the base logging interval and that the base and drone recorded at the same time; look at ppk_log.txt.