What should the vessel's incident/event report on this GNSS interference episode specifically include, beyond the basic timeline?

A. Nothing, since the event did not result in a position excursion or contact

B. The specific evidence that distinguished a common-cause GNSS issue from independent equipment faults, the verification method used (cross-technology check against Fanbeam) that prevented reliance on the false positions, confirmation that another vessel in the field reported the same issue, and the fact that no ASOG limit was exceeded — both the near-miss and the resilient response are valuable data

C. Only the names of the DGNSS equipment manufacturer, omitting the operational response entirely

D. Only that "a temporary GNSS fault occurred and resolved itself" with no further detail

A. A Fanbeam fault, since it is the system not showing the change

B. A GNSS-wide problem affecting both satellite receivers simultaneously (interference, spoofing, or a satellite constellation issue) rather than two independent sensor faults — the fact that both units moved identically and together is the key clue, since genuinely independent reference systems failing identically at the same instant is far less likely than a shared external cause

C. Two simultaneous but entirely unrelated hardware faults in both DGNSS receivers

D. Normal GNSS behaviour requiring no further attention since both units still agree with each other

A. Trust the DGNSS units since there are two of them and only one Fanbeam, following a simple majority-vote assumption

B. Average the DGNSS and Fanbeam readings together to obtain a compromise position

C. Manually exclude both DGNSS units from the DP position solution immediately, relying on the Fanbeam (and any other unaffected reference) — do not wait for the DP system's automatic voting to resolve this, since two affected units may outvote the one correct reference if left to automatic logic

D. Take no action since the vessel's thrusters have not yet responded to the apparent jump