Emirates flight EK421 on 1st June 2022 from Perth, Australia to Dubai, UAE took 10 hours 31 minutes. The aircraft operating this flight was a Boeing 777-300ER and departed Perth International Airport at 14:26 UTC arriving in Dubai International Airport at 00:57 UTC.
The Emirates flight EK421 on 1st June 2022 was successfully detected and tracked over the Indian Ocean. 17 position indicators and 46 progress indicators allowed flight tracking over a 3 hour period. The intersections of multiple WSPRnet links align with the estimated position of the Boeing 777-300ER aircraft and these WSPRnet links show SNR, drift or dual anomalies for the particular WSPRnet links involved within the 3 hour analysis time frame. These indicators allow an absolute determination of the aircraft’s position at 17 points in time and a likely determination of the aircraft’s position at 46 further points in time. The resulting aircraft track aligns with the ADS-B data from FlightAware where available.
The flight route is almost entirely over the Indian Ocean and at 18:46 UTC crosses the estimated flight path of MH370 which disappeared on 8th March 2014 in the Southern Indian Ocean. ADS-B data from FlightAware is available for almost 6 hours of the flight in 3 parts, firstly near Australia, secondly near Sri Lanka and India and finally near Oman. There is a total gap of 4.6 hours over the Indian Ocean where the aircraft is out of range of land based ADS-B receivers.
The paper can be downloaded here
@All,
A message from the MH370 next of kin:
“You have put in an astounding amount of work into tracking MH370!!
We thank you for your time and effort.
We are praying OI will find the plane!!
We have posted the paper on the MH370 Families FB Page.”
@All,
In our paper we cite Harry Nykvist (Nyquist US).
According to the IEEE paper linked below Harry Nyqvist changed his name to Harry Nyquist upon arrival in the US:
“Harry Theodor Nykvist was born on February 7, 1889 in Nilsby, a small village in Sweden. He was the fourth child among eight siblings. His father, Lars Jonsson Nykvist, was a shoemaker, his grandfather was a watchmaker.”
“In 1907 he left Sweden, landed in Boston, changed spelling of his family name to Nyquist.”
https://ieeexplore.ieee.org/document/9722940
@All,
A new article by Geoffrey Thomas of airlineratings.com on the WSPR technology:
https://www.airlineratings.com/news/industry-news/mh370-tracking-expert-demonstrates-technology/
@All,
Another article by Geoffrey Thomas of airlineratings.com asking why wouldn’t Malaysia want to find MH370:
https://www.airlineratings.com/news/why-wouldnt-malaysia-want-to-find-mh370/
Assuming that power to the Satellite Data Unit on mh370 was lost sometime after 17:21 UTC and then restored shortly before 28:25 UTC, would the SDU perform more quickly after a hard reboot, like with a personal computer? If ACARS were no longer reporting to the SDU, would this fact decrease the time in which the plane’s SDU would receive, process and reply to a signal from the satellite? Finally, approximately how many kilometers difference in the distance of the plane to the satellite are there for every 100 microseconds? Meaning, if the SDU spent only 2,700 microseconds receiving, processing and replying to a signal from the satellite, instead of the assumed 4,700 or so microseconds, how many more kilometers would we expect the airplane to be from the satellite at the time of the interrogation?
@Jennifer,
Welcome to the blog!
You ask: “would the SDU perform more quickly after a hard reboot, like with a personal computer?” and “would this fact decrease the time in which the plane’s SDU would receive, process and reply to a signal from the satellite?” and “approximately how many kilometres difference in the distance of the plane to the satellite are there for every 100 microseconds?” and “how many more kilometres would we expect the airplane to be from the satellite at the time of the interrogation?”
The Satellite Data Unit (SDU) is a part of the satellite communications system. It is not designed for navigation, but for communication. The communication relies on a very stable temperature controlled oscillator. The transmissions between the ground station in Perth, Australia and the Inmarsat satellite over the Indian Ocean and the MH370 aircraft are all at the speed of light and at various set frequencies. The frequency bands and the speed of light do not change following a reboot of the SDU.
The Burst Timing Offset (BTO) is measured at the ground station and allows us to calculate the distance from the satellite to the aircraft, as we know the distance from the ground station to the satellite at each point in time.
The Burst Frequency Offset (BFO) is also measured at the ground station and allows us to calculate the relative velocity between the satellite and the aircraft, as we know the velocity of the satellite, the L-Band uplink frequency, the C-Band downlink frequency, the SDU aircraft doppler compensation, the aircraft satellite uplink doppler, the ground station satellite downlink doppler, the Enhanced Automatic Frequency Control (EAFC) effect and the eclipse effect.
Following a reboot of the SDU the temperature controlled oscillator which is in an oven will settle at the correct operating temperature and a very stable operating frequency. If this were not the case, then the handshake signals to establish a communication between the aircraft and the ground station via the satellite would not work.
At 18:25:27.421 UTC the SDU issued a Log-On request. This was answered at 18:25:28.852 UTC with a Log-Confirm. Further channel control signals were received by the SDU and at 18:25:34.461 UTC the SDU sent a Log-On Acknowledge. A total of 26 signals were exchanged culminating in a further acknowledgement at 18:28:14.904 UTC. We know that the SDU was working normally.
At 18:39:52.907 UTC the SDU received a call announcement. Although the call was unanswered, a total of 92 signals were exchanged showing the SDU was working normally.
A further set of handshake signals and a second call announcement comprising a total of another 71 signals being exchanged and showing the SDU was working normally up until 8th March 2014 00:19:38.407 UTC.
The BTO and BFO data are reliable and give the correct distance of the aircraft from the satellite and the correct relative velocity between the aircraft and satellite. In answer to your specific question there are approximately 15 kilometres difference in the distance of the plane to the satellite for every 100 microseconds.
@Richard
This is very helpful information, thank you for your help. I have a few more questions now.
As I understand the BTO calculation method, the unknown quantity is the amount of time the SDU on mh370 took to receive, process and reply to a signal. The processing time for each plane’s SDU is unique, some are slower and some are faster in processing signals. Also, an SDU’s processing speed varies from flight to flight. So the same unit may for whatever reason process signals more quickly during one flight and more slowly during the following flight. I also understand that SDU’s are presumed to have a consistent processing speed throughout the same flight.
If we assume for the sake of my question that after the SDU was rebooted and came back online at about 18:25 UTC after a prolonged, perhaps hour long, shut down, the SDU performed as if this post 18:25 UTC world were an entirely new flight, then what is the “whatever reason” that cause or causes the SDU to perform more or less quickly from flight to flight? What affects an SDU’s processing speed?
For example, after 18:25 UTC the SDU did not transmit any information reports from the ACARS. The SDU also failed to transmit the flight ID after 18:25 UTC. If the SDU did not have to take the time, in mere microseconds, to obtain a report from ACARS or the flight ID number, would the SDU be able to process and reply to signals more quickly?
How can we determine whether the SDU was processing information more quickly or slowly after the 18:25 UTC reboot than it was before it lost power after 17:07 UTC? Is this something that could be tested?
@Jennifer,
ACARS is an application which uses either satellite or radio communication. The fact that the application was switched off is irrelevant to the SDU operation.
It is not the case that each SDU varies from flight to flight. You state: “The processing time for each plane’s SDU is unique, some are slower and some are faster in processing signals.” This statement can be misleading. Obviously different SDU manufacturers or different product types will have different capabilities.
In the case of MH370, the processing time of the SDU is controlled by an oven controlled high stability reference oscillator located in the SDU, which is used as the primary frequency reference for:
– Radio Frequency Module Local Oscillators
– Synthesised Channel Local Oscillators
– Modem Sample Rate Clocks
– Voice Codec Bit Rate Clock
The crystal oscillator provides good stability versus temperature, power supply voltage and load variations. The output frequency is 10.08 MHz and has sufficient mechanical adjustment range to compensate for ten years of ageing. The reference oscillator frequency is sent to the Radio Frequency Module (RFM) where it is buffered and routed to each modem. The oscillator also outputs a logic signal directly coupled to the SDUs Main Processor Module to indicate the oven temperature stabilisation. The channel phase-locked-loop synthesisers and other phase-locked-loop oscillators are all referenced to the single reference oscillator.
The SDU utilises two kinds of signals as inputs for transmission, analog audio or digital data. The multi-channel satcom system is able to transmit data and voice information simultaneously in full duplex mode. The power management and frequency selection in this system is controlled by the ground station without any pilot’s assistance. Aviation Binary Phase Shift Keying (A-BPSK) is used up to 2,400 bps and Aviation Quaternary Phase Shift Keying (A-QPSK) is used up to 21 kbps.
The digital packet data to be transmitted is routed to the SDU main processor assembly, the analog voice to the six codec assemblies of the SDU and the digitised cabin voice is routed to the transcoder circuits of the SDU. There are seven modems in the SDU and eight available channels in the SDU’s RFM. There is a flexible system of connecting modems to channels.
The SDU system table memory contains the location of all satellites. When a ground station is selected, the SDU uses this location information and aircraft positional information from the Inertial Reference System (IRS) to compute the position of the satellite relative to the aircraft. The SDU then transmits pointing and tracking coordinates (aircraft relative azimuth and elevation) to the beam steering unit to permit optimum signal transmission and reception between the high gain antenna subsystem and the satellite. The high gain antenna subsystem translates these steering commands into control signals to the antenna. Once the beam has been steered toward the satellite, the SDU receives the pilot tone from the satellite transponder through its receive RF link from the antenna subsystem. The SDU can adjust the transmission frequency in one-Hertz increments to compensate for the Doppler shift caused by the speed of the aircraft. The receive mode is handled in a similar manner. Since this is a full-duplex system, the transmit and receive signals are processed simultaneously.
In the automatic mode, the SDU operation is fully automatic with satellite log-on and handover procedures occurring without external control. In the user commanded mode, the flight crew or flight control system is able to select the satellite and ground station for log-on and handover, and can initiate handovers at any time. The user command mode was not used after the SDU reboot as the flight number was not entered.
The automatic mode is considered the normal mode of operation. The log-on policy is normally set to automatic. As I have shown previously, the log-on at 18:25:27 UTC was successful. The SDU automatically picks up, where it left off. The SDU was not processing information more quickly or more slowly after the 18:25 UTC reboot, than it was before it lost power.
Mr. Richard, you might have a potential breakthrough in the MH370 universe.
But I didn’t understand one thing. If MH370’s flight path intersected with Emirates, why isn’t there any info about the plane?
And why Malaysian Government doesn’t want to find the plane? Or have they already got the coordinates but didn’t release due to subsequent backlash?
@Kanishk,
Welcome to the blog!
I have published what I believe is the final resting place of MH370. Ocean Infinity has confirmed their intention to search again with their latest technology in 2023 on a “no find, no fee” basis covering the area I have indicated.
The Malaysian Government agreed contractual terms with Ocean Infinity for the previous search in 2018. I cannot understand why the Malaysian Government is hesitating to agree contractual terms for a renewed search in 2023.
I read that since the Govt. Of Malaysia owns the airline, if it is somehow confirmed (don’t know that ever happen now) that They would be faced with claims and lawsuits in the amount of millions of dollars so they don’t want to know where the plane is according to Prime Minister Tony Abbott they know exactly what happened – that it was murder suicide
@All,
A reader has written to me asking to republish the MH370 GDTAAA WSPRnet Analysis Flight Path Report with the altitude and fuel usage included.
WSPR can determine position, ground speed and track.
WSPR cannot determine altitude directly, only indirectly through a change in the true air speed.
For this reason, I did not include altitude and fuel analysis in the 124 page flight path report. The suggestion has merit and it may be worth investing the considerable amount of time in performing this analysis. We do have a lot of data on fuel range and endurance from Boeing, Rolls Royce, MH370 and previous 9M-MRO flights.
There are many other factors that effect fuel usage and it might be possible to make assumptions on all these factors:
1. Descents and climbs.
2. Turns.
3. Step climbs.
4. Air conditioning packs.
5. APU usage.
6. One engine shut down.
7. Cross feed valves.
8. Outside air temperature.
9. Winds.
10. Aircraft weight.
11. Performance degradation allowance.
12. Mach.
13. Speed schedule (ECON, LRC, MRC, CM).
14. Delta static air temperature.
In a previous report that I wrote together with Ulich, Iannello and Banks we attempted to make these assumptions, but came to no definitive conclusions.
https://www.dropbox.com/s/lszarw2w8qb2a3p/The%20Final%20Resting%20Place%20of%20MH370%20-%207th%20March%202020.pdf?dl=0
The fuel model and fuel analysis is described in full in this paper, especially in the appendices A, B, C and D.
Could the communications problems experienced on MH371 partly explain the downgrading of the IFE software on 7th March prior to the departure of MH370?
In Appendix 1.6A of the Safety report item 6 listed says:
“07 March 2014
EPESC software downgrade carried out
IAW TSI/77/SR/14092 IFE of CHI
satisfactory.”
Additionally, if there were any hardware problems within the IFE, or any other of the plane’s electronics, it could be that the subsequent uploading of the terrain database (item 4 in the maintenance log) played some part in the tragedy, (eg by making extra demands of old circuitry with downgraded software).
It’s probably worth noting that 9M MRO was manufactured in the era of the so-called “capacitor plague”
https://en.wikipedia.org/wiki/Capacitor_plague
@All,
Please note the only website worth “studying” is the website from Victor Iannello,