Abstract
Examiners read drone flight logs with open-source parsers, and published comparisons of these parsers count the rows a tool writes or note whether it crashed. We tested whether such counts say anything about the evidence. Six parsers (DatCon, DROP, DRDP, Fodogu, pymavlink and GRYPHON) were run three times on each of the 72 files of four NIST CFReDS drone datasets, 1,296 runs with pinned versions and hashed inputs and outputs. Every coordinate a tool wrote was compared with two reference decoders: one accepts a DJI packet only when its checksum verifies, the other reproduces the Mission Planner exports shipped with the ArduPilot logs. On the DJI Phantom 3 files, DatCon and DROP wrote no unsupported position and agreed exactly wherever both reported one; 729,793 reference records (82.4%) are reproduced by both. The count differences earlier read as complementary recovery come from repeated rows and from two undocumented display rules: DROP blanks positions logged with two or fewer satellites, and DatCon writes nothing before a flag set by the first record with non-zero position and height. At the rate used here, 98.3% of DatCon's GPS-receiver rows repeat an earlier value (97.9% at its 30 Hz default). Runs that ended with status zero and no coordinates from a file holding them made up 21 of 126 runs on formats a tool claims to support and 61 of 120 on other formats. On the ArduPilot logs, 545 of 927 positions that pass a plain latitude and longitude range test were logged without a three-dimensional fix. All 431 completed run triples were bit-identical. The procedure is stated as a formal model, so that each reported quantity has a definition.