[time-nuts] Inmarsat needs a time-nut

[Poul-Henning Kamp]

Inmarsats long awaited article about the MH370 calculations is now
available:

	journals.cambridge.org/download.php?file=%2FNAV%2FS037346331400068Xa.pdf&code=99d6daf127f9c88ca22b52fd9ff5084a

I think I've spotted a weakness.

The "BFO-Bias" is the frequency error of the aircraft terminals
timebase and the calibrate it to 150Hz using communications while
the plane is on the ground.

The terminal most likely uses a TCXO for the rapid startup.

A 150Hz error on a 10MHz TCXO would be 15PPM which would be
impressively bad for this kind of application.

Its therefore likely that the TCXO is in the 100MHz range giving
an error of a more likely 1.5PPM.

The aircraft terminal is powered down and possibly in very hostile
environmentals for around one hour, prior to the log-on at 18:25:27Z,
but Inmarsat assume, without any comment or qualification, that the
BFO-bias is still the same and still constant.

I don't think those are valid assumptions.

Retrace is typically not specified for TCXOs, for a good reason.

I don't think it is unreasonable to assume that the TCXO came up
with a difference of +/- 1PPM from the previous frequency, after
being turned off for an hour, where both temperature and air pressure
may have violated specs.

That means that the BFO-bias after the 18:25:27Z logon isn't 150Hz,
but somewhere in [50...250Hz], and what's more, it's probably not
even constant for the first 10-15 minutes after power-on.

(In fact, I'm not even sure that the assumption that the frequency
offset at ground level can be used at lower air-pressure at
flight-level in the first place.)

I havn't gone through their math to see what the implications would
be, but I think it will vastly ruin the geometry of the fix.


Poul-Henning


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.