RTK fixed, float or none: reading the flag out of your own images

A DJI RTK image carries three groups of positioning fields in its XMP, not one. RtkFlag is the fix status. RtkStdLon, RtkStdLat and RtkStdHgt are standard deviations of the solution in metres, east-west, north-south and vertically. The Mavic 3 family adds RtkDiffAge, the time since the last correction message arrived, and the NTRIP host, port and mount point when a network correction service was used. Esri's Drone2Map documentation reads the first four and surfaces them per image in the project table as AccX, AccY and AccZ.

The decode is the part that fits in a snippet. Flag 0 is no positioning, with accuracy in the region of tens of metres. Flag 16 is single-point positioning at metre level. Flags 34 to 49 are float solutions, decimetre to metre depending on how old the base corrections were. Flag 50 is fixed, centimetre level relative to the correction provider. Worth knowing before you lean on it: DJI documents these values for the MRK timestamp file rather than for the XMP tags themselves. The table everyone uses is third-party, and while Esri's documentation and Sitemark's support notes agree on it, other sources disagree about what 16 means. Treat the flag as a strong hint and the standard deviations as the cross-check.

The deviations are the better evidence because they are continuous rather than categorical. Without base corrections they sit above 1 m. A healthy fixed solution writes something around 0.01 m. Sitemark's note puts the deviations above 1 m whenever no corrections reached the aircraft, exactly the picture you would expect from a receiver computing its own position unaided. If the flag and the deviations disagree, believe the deviations.

RtkDiffAge explains the other two. Documented readings run from 0.4 s alongside a flag of 50, to over 80 s alongside a flag of 34, to 0 when no base station was connected. A correction more than a few seconds old is stale, and a float solution with an eighty-second age is not telling you the sky was bad; it is telling you the link died and the receiver coasted.

RTK measures the phase of the carrier wave rather than the code modulated onto it, which is a far finer ruler. The catch is that a phase measurement is only known to within a whole number of wavelengths, and that unknown integer count is the ambiguity. Resolving it is what makes a solution fixed. A float solution has estimated the ambiguity as a real number and never committed to an integer, which is why it is a different class of answer rather than the same answer with more noise.

The numbers follow from that. DJI's published RTK positioning specification for the Phantom 4 RTK is 1 cm + 1 ppm horizontal RMS and 1.5 cm + 1 ppm vertical RMS. The ppm term is the baseline: one part per million is 1 mm per kilometre from the base, so a correction source 20 km away adds about 2 cm before anything else goes wrong. A float solution degrades to decimetres or worse, a single-point solution to metres, and a flag of 0 to tens of metres. The separate figure DJI quotes for the absolute horizontal accuracy of the finished photogrammetric model, 5 cm, applies at 100 m altitude with a 2.7 cm ground sample distance on a sunny day: a best case, not a promise.

Fix is also fragile. Obstructions, multipath off buildings and water, a dropped radio or network link, and plain baseline length all push a receiver from fixed back to float. This is why the count matters more than the capability: a flight can hold fix for two hundred images and lose it on the return leg over a treeline, and nothing will warn you, because from the aircraft's point of view nothing failed.

Open your own images in the metadata viewer on this site. It reads RtkFlag and the three RtkStd fields out of each file in your browser, classifies the fix type per image, and falls back to the standard deviations when the flag is absent or unrecognised. It also reads the senseFly and Parrot GPSXYAccuracy field, so a non-DJI airframe is not a dead end. Nothing is uploaded, so you can run it over a client's imagery without a conversation about data handling.

Load the whole flight rather than one photograph. The batch summary tells you how many images carry RTK data at all and how many of those were fixed, which is the single number worth putting in a flight report. Then export the positions as CSV, KML or GeoJSON. The CSV carries an rtk_fix column and horizontal and vertical accuracy columns next to every position, so you can open it in your GIS, symbolise by fix status, and read the answer as a map rather than a table.

The map is where the diagnosis happens, because the pattern names the cause. A contiguous run of float down one flight line, or everything after a particular timestamp, points at a link failure or a base that went down partway through. Float scattered across the whole block points at the environment - canopy, structures, a poor sky view. The KML opens in Google Earth, and the Map Lab on this site will show the photo positions, the flight path and your GCPs together.

If the count comes back as 180 of 220 fixed, you have a decision instead of a worry: deweight the weak images, refly those lines, or lean on ground control over that part of the block. What you cannot sensibly do is assume, which is exactly what an RTK aircraft invites you to do.

This is the finding that should change how the flag is read. A pilot on the MavicPilots forum, flying a Mavic 2 Enterprise Advanced with an RTK module against an NTRIP service about 20 km away, reported FIX status with accuracy values populated at around 0.09 ft horizontally and 0.22 ft vertically - roughly 2.7 cm and 6.7 cm. Pix4D ingested those values happily. The RMSE after processing was still poor. The cause was not the positioning at all: the images carried motion blur from flying at about 11 mph in marginal light.

The arithmetic is worth doing once, because it shows how independent the two failures are. Eleven miles per hour is about 4.9 m/s. At 1/400 s the aircraft moves about 1.2 cm during the exposure, which at a 2.7 cm ground sample distance is under half a pixel and invisible. At 1/100 s it moves about 4.9 cm, nearly two pixels, and every tie point in the block is being matched on a smeared feature. The geotag can be perfect while the photograph attached to it is not worth tying anything to.

A second report, from a pilot comparing a Matrice 4E against a Phantom 4 RTK on a government network about 10 km out, records fix for the full flight on both and RMSE figures of 0.218 m and 0.313 m for two M4E units against 0.013 m for the P4RTK. These are single-user forum anecdotes rather than controlled tests and should be read as such. The direction they point in is consistent, and it matters more than the figures: a fixed flag is a necessary condition for a centimetre product, never a sufficient one.

RTK gives you the position of the aircraft relative to the base station. If the base coordinate is wrong, every image is wrong by the same amount and every flag still reads 50. Set a D-RTK 2 down on an unknown point in automatic mode and it uses its own single-point position, which its specification puts at about 1.5 m horizontal and 3.0 m vertical RMS. Relative accuracy across the block stays at 1 to 2 cm. Absolute accuracy inherits the base error in full.

The symptom is unmistakable once you know to look for it. Every image fixed, a model that is internally beautiful, sitting a metre and a half off the client's control - and a second flight from a fresh base placement on the same spot landing a metre away from the first. Nothing in the metadata records this. The flag reports the quality of a measurement, not the truth of what it was measured from.

The quieter version is a datum mismatch. A network correction service broadcasts in whatever reference frame its mount point uses, and global frames such as ITRF track plate motion while regional datums such as NAD83 are pinned to an epoch, so the gap between them widens every year. A consistent 50 cm to 1 m offset from local control, uniform across the site, is a datum problem rather than an accuracy problem - which is why Esri's advice when imagery shifts against a checkpoint is to review the coordinate systems first. The guides here on WGS 84 versus NAD83 and on choosing a CRS set out what that costs.

The vertical axis carries its own trap. A centimetre-accurate RTK height is still a height above the ellipsoid unless something converted it, and the geoid undulation runs to tens of metres. The guide here on ellipsoidal height versus height above sea level covers that failure in full.

PPK attacks the same problem from the other end. Instead of correcting in real time over a link that can drop, the aircraft logs raw GNSS observations, the base logs its own, and the two are combined after landing. The whole observation file is available to the processor, which is why PPK is more resilient to dropouts: an RTK solution loses accuracy the moment the link breaks, while a post-processed solve can often recover the same epochs afterwards.

This changes what the flag means. A PPK workflow rewrites the positions in the image files - Emlid Studio writes geotags into the EXIF from a precise events file, and tools such as REDtoolbox write coordinates and accuracy values back into the JPEGs directly. RtkFlag, though, was written at capture and describes the real-time solution the aircraft had then, not the coordinates now sitting in the file. None of the published documentation states what geotagging software does with the flag, so the honest position is to treat it as stale after PPK and read the PPK software's own quality report instead.

What does not change is the need for checkpoints. Whichever method you used, the accuracy claim stays a claim until something independent of it tests it. Esri's guidance is specific: use the Fix Image Location for High Accuracy GPS option with checkpoints rather than with ground control points, and treat a significant shift against a checkpoint as a sign that the configuration or the coordinate system is wrong. A few surveyed points kept deliberately out of the solution are the only thing that catches a base entered a metre out, a mount point in the wrong frame, or an ellipsoidal height delivered as an elevation.

The metadata viewer here reads and reports. It opens your images in the browser, decodes RtkFlag, RtkStdLon, RtkStdLat and RtkStdHgt, classifies each image as fixed, float, single, DGPS or none, and gives you the batch count and a map. It exports those positions with the fix status attached as CSV, KML or GeoJSON. For a go or no-go decision on a block of imagery, that is usually enough.

It cannot reprocess anything. A JPEG does not carry raw GNSS observables, so no browser tool can recompute a position, run a PPK solve, or turn a float image into a fixed one. It cannot tell you whether the coordinate you typed into the base was correct, because nothing in the image records what that coordinate was supposed to be. It cannot check your data against checkpoints you have not surveyed. Those are jobs for your GNSS software and for the field.

It also cannot resolve the one genuine ambiguity in the subject. The DJI XMP decode table is reconstructed from third-party documentation rather than from a published specification, which is why this page names its sources instead of presenting it as settled fact. Where the flag and the standard deviations conflict on your own imagery, the deviations are the measurement and the flag is only the label.