Jun stated:
Previously in this thread, I described how it was possible to use the offset detected at the AES Rx of the SAT P channel carrier to pre-compensate the AES Tx frequency in the opposite direction, so that the SAT Rx always received the AES on the assigned channel frequency.
I agree (and also previously stated in less detail) that pre-compensation values could readily be derived from observed Doppler shift in the download signal received from the satellite.
It now transpires that the Honeywell SATCOM package installed on 9M-MRO used a software algorithm to calculate the Doppler shift correction to be applied, based on the aircraft position and motion. However, the software assumed that the SAT was actually at its geostationary position of 0° 64.5°E and didn't take into account the eccentric ellipse of +/- 1.63° about the equator performed by the SAT in a siderial day.
Its this eccentric motion which is used by Inmarsat to differentiate whether the aircraft was on a Northern or Southern vector.
So, in this case the BFO is the difference between what the AES calculated, and what it would have calculated if its software used the actual SAT ephemeris values.
The idea that the BFO is pre-computed based on aircraft location, heading and velocity has recently been mentioned with some frequency here and elsewhere. The approach is certainly possible, but it seems vastly over-complicated (and thus error-prone) as a solution to the Doppler compensation problem compared to measuring the downlink Doppler shift.
Also, what is our basis for thinking that this is ACTUALLY happening in the Aero Classic units?
Just as importantly, given that Inmarsat, Duncan Steel and others used the BFO values essentially as a proxy for aircraft velocity (subject to some adjustments for three-dimensional heading), the residual error due to movements of the "geostationary" satellite (and uncompensated by the postulated pre-computation system) fails QUANTITAVELY to account for the observed values in the 100Hz - 350Hz range.