Re the 5th handshake, the only thing I could think of is that there were some intervening signals between the 4th and 5th handshakes with the result that the 5th handshake was 1.5 hours after the 4th. How that would affect the time difference between the interrogation and reply, if at all, I do not know.

Unfortunately, those who understand how these things work, the real experts, have not come forward to expose these fraudulent BTO numbers and hold Inmarsat to account. Instead, the pseudo experts pretended they understood these numbers and embarked on an orgy of flight path modelling on these fake numbers. Some on Jeff’s blog are still hard at it, apparently.

Personally I doubt any real expert or whistleblower will come forward. They would have in mind the sudden demise of the satellite operator, among other things, Mike Exner’s assurance that it was unrelated notwithstanding.

You may also note that with rare exception, one 10.5 kb/s P channel transmits at .405 and .905 after the second. The other transmits at .407 and .907. Slots are power of 2 fractions of a second, suggesting slots start 1/2 second apart from each other.

On the way back, times *roughly* land around the same .405 or .905s, but +/- 2000us. The consistency of the received times suggest, as expected, that the signals were released with a particular target receipt time in mind. The +/- 2000us suggests that it’s not that accurate and maybe the +/-300us isn’t applicable here.

I think it’s worth emphasizing that the round trip time on the handshakes are much larger than an actual round trip, yet not necessarily longer as the plane got further away. Further, the by-design delay between the AES receipt of the log-on interrogation and the AES response is unreported and unknown to us, but is also unrelated to the distance.

I’m still not seeing where a five-digit value like 18040 fits in this timeline. For the record, I don’t it’s made up, I just don’t think it’s a BTO from the log.

The 5 digit BTO values in the Inmarsat datalog are fraudulent and only those perpetrating the fraud would know where those numbers came from.

Inmarsat would be recording on their logs the BFOs and BTOs. As we have seen, the BFOs cannot exceed +/- 383Hz while the BTOs cannot exceed +/-300 microseconds. Obviously, Inmarsat took out the actual BTOs recorded for flight MH370 and substituted the real numbers with the 5 digit numbers we see in the datalog.

As regards the geolocation technique using angle of elevation, the paper by Cisco previously referred to (and other reference materials available on the net) describe how this technique works. The question is whether Inmarsat would be recording the angle of elevation as part of the routine or whether this information can be extracted or calculated after the fact from other information recorded routinely.

The closest thing to a round trip signal in the datalog would probably be the completed handshakes where the GES would send a ‘Log-on/Log-off Interrogation’ and the AES would reply by transmitting a ‘Log-on/Log-off Acknowledge’. The 4 completed handshakes at 19.41, 20.41, 21.41 and 22.14 UTC show a time difference between the signal from the GES and the corresponding reply from the AES of 1.996 seconds, 1.997 seconds, 1.998 seconds and 1.999 seconds respectively.

To your first point, I wouldn’t argue that your scenario is impossible, only that the numbers don’t make sense for ANY scenario. Here’s the timeline as I see it:

T1 – ground initiates request on P channel
T2 – AES receives request on P
T3 – Start of AES response on R channel
T4 – Possible receipt of request at ground on R channel
T5 – R channel time slot begins
T6 – Possible receipt of request at ground on R channel

Ground logs show time stamps for T1s and either T4s or T6s.

According to the spec, BTO or error would be measured as either T4-T5 (negative, early arrival, >-300us), or T6-T5 (positive, late arrival, <300us). The time between T2 and T5 would he arbitrary. Logs show T6-T1 and or T4-T1 to be several seconds, so T5-T2 must also be several seconds and cannot merely be travel time. In other words, the AES is told to respond in a time slot far enough in advance. The AES chooses T3 so that the signal arrives as close to T5 as possible.

In this scheme, there is no round trip measurement available from the signal times. Round trip could be determined if the AES communicated T2 and T3 back to the GES in the packet, as it would be (T2-T1)+(T4orT6-T5). But, this would contradict the stated use of the signal block start time. If round trip was calculated this way, it would not be stored as an offset except possibly as an offset from some clearly defined number like 500,000 or a power of 2 like 524,288.

So, where do we get a 5 digit BTO? That is my theory – we cannot possibly have a 5 digit BTO unless one of the following is true:

1) The "bias" value is known prior to logging, AND T2 and T3 are available at the time of logging (which means the packet must be read before its receipt is logged)
2) The responses are arriving way off spec relevant to the signal block times
3) The BTOs are not raw values from a log but the product of significant manipulation or a merge with data received later.

Does that sound right?

1. “…these numbers don’t quite fit- among other things, they are inverted as they are lowest at the northernmost sat position…”. The numbers would make perfect sense if the AES was just off the coast of Vietnam at all times during the pings.

2. There is an interesting paper by Cisco on various geolocation techniques, a link to which can be found in the PhysicsForum blog on MH370. The techniques covered in that paper include angle of elevation of the signal.

3. According to the CNN article referred to in my previous comments regarding the calculation of the arc from the angle of elevation, the angle of elevation would be recorded as the satellite needed to know where a signal was coming from. I do not know how true this statement is. Wouldn’t it have been easier for the AES to just report its location if indeed location information was required?

4. My own thinking is that the pings were picked up by more than one satellite.

5. One has to remember the Malaysians announced at 2324 UTC that the plane had gone missing.

6. The entire intelligence community would then be on full alert if not already so.

7. I find it difficult to believe that Inmarsat and other satellite agencies did not do anything after the announcement, to try to track any signals coming from the AES.

8. We all know by now such signals would be carrying its special ID code identifying them as coming from the AES on MH370.

9. The ‘final arc’ published on March 15th was derived from the ping at 0011 UTC, which is 47 minutes after the Malaysians’ announcement.

10. It may have been calculated based on its angle of elevation as Inmarsat said or from triangulation techniques based on detection of the signal by 2 or more satellites.

11. Obviously if it was a case of the latter, Inmarsat cannot come out and say so as that would mean having to admit they actually know where the plane was at such time ( the actual location, not just an arc).

12. The idea that the signals emitted by the AES from 1825 to 0019 UTC and there were exactly 100 such signals, were picked up only by the Inmarsat IOR satellite and no other satellite, defies logic.

http://www.atsb.gov.au/publications/2014/mh370-burst-timing-offset.aspx

If you read this carefully, and treat the word “error” as “BTO,” you’ll find that it matches the paradigm you and I are describing perfectly. Basically, what the protocol manual calls BTO, the above document calls an “error.” The values, of course, have a mean of 0, can be either positive or negative, and always fall within +/-300us. The deviations, as expected, come from movement, presumably between the time the signal is sent and the time it is received.

Note that NOWHERE in this document are the words “bias” or “nominal terminal” used. In other publications, that bias had to be derived, so it theoretically wasn’t known when the values were stored. Had it been known prior to storage, we wouldn’t be dealing with “offsets” but with the full round trip time. It would not need to be derived as an average. It could simply be added back in.

The inconsistencies are so irreconcilable that it almost looks like there are two groups working separately here.

One group (the December article) appears to be discussing values that are +/-100us, measured from the start of a time slot. This is in keeping with the spec and strongly suggests timing compensation is occurring. This group is calling their values “errors,” but they appear to match the specification’s BTO concept.

The other group is discussing mysterious 5-digit numbers that are supposedly the round trip time minus some arbitrary bias that nobody knew until they averaged a bunch of numbers. This group is calling their values “offsets” but it’s not at all clear when they became “offset” or what they are offset from.

The inconsistencies in official documentation leave a lot of room for rampant speculation, so of course I could be way off base here. But I come to the following conclusions:

1. The BTO is not round trip. There is no timing of any message, as you said, that would generate a round trip. The P channel sends a request, and the R channel sends a response. The gap between them is much more than round trip time.

2. The BTO is not start-of-slot offset, unless the system is way off the protocol and has hopelessly degraded bandwidth.

3. The elevation angles are something of a mystery – if the times were really the raw data, why were elevation angles ever needed? They are not a necessary step in the sequence time values – LOS distance – sub satellite position – lat/long. That elevation angles were presented suggests that they were recorded, but I’m not sure how that’s possible. It is very odd how fast they disappeared from the discussion.

4. Though I don’t know anything about the hardware, it seems only logical that the time offset was also minimized just like the frequency offset. Minimizing either one improves bandwidth, and the inputs needed to make adjustments are identical. Considering the fact that the protocol appears to limit the BTO, one would think the same mechanism would be in play.

All of this leads me to wonder if the BTOs are a function only of the satellite’s deviation from 64.5/0. That both BTO and BFO correlate to the satellite movement certainly shores up this idea. However, these numbers don’t quite fit – among other things they are inverted as they are lowest at the northernmost sat position. Any ideas here?

You can find the answer to most of your questions in Part III of the Manual For Aeronautical Mobile Satellite (route) Service which contains a detailed description of the Inmarsat system, including various technical specifications.

1. Collisions

As stated in the Manual, R channel is random access slotted Aloha. Collisions are possible under Slotted Aloha.

T channel is reservation TDMA. The GES reserves time slots for transmissions requested by the AES (for messages exceeding a certain length). If everything is working perfectly, there would not be any collisions for T channel transmissions.

2. What is the BTO according to Inmarsat

Please read how Inmarsat defined the BTO in the various reports (the Inmarsat datalog of May 27th, the ATSB Report of June 26th and the Inmarsat paper published in the Journal of Navigation). I have summarized in previous comments how Inmarsat has given different and inconsistent definitions for the BTO in the various reports. Please scroll up to to read those comments.

3. The BTO as defined in the manual.

I have also in previous comments quoted from the manual the provisions defining the BTO. Under the manual, the BTO is basically the difference between the timeslot defined by the P channel and the time the signal actually arrives and to be certified for Inmarsat system compliance, the BTOs for any AES cannot exceed +/- 300 microseconds.

4. The BTO in the Inmatsat datalog is bogus.

Contrary to the manual, the BTOs in the datalog exceed 10,000 microseconds. So that is the first sign these BTOs values are not burst timing offsets as such but some other values, or just mere fabrications.

You will note from my comments analysing the various definitions of the BTO given by the Inmarsat, that any attempt to portray the BTO as some sort of round trip figure is just plain bogus.

Firstly, the BTO as defined in the manual can be both negative and positive. If the signal arrives early it is negative, if it arrives late it is positive or vice versa. An RTT value by definition can only be positive. So the BTO under the manual cannot be referring to an RTT value.

Secondly, what sort of signal are we talking about that went round trip? is there any signal in the Inmarsat datalog that went on a round trip? If u can detect one, please let me know.

5. How does the AES minimize the BTO?

The system would be considered to be working perfectly if each time the signal arrives just at the right time ie at the timeslot specified, in other words, zero BTO. How would an AES try to minimize the BTO? Basically by calculating the propagation delay ie the time it would take the signal to travel from the AES to the satellite to hit the timeslot just in time.

How is the propagation delay calculated by the AES on MH370? I do not know for sure but logic would suggest it is a closed loop system like the compensation for the Doppler whereby the AES would calculate the propagation delay from information derived from the IRS via the AIMS, the same information used to calculate the Doppler correction ie the position, speed, track etc of the plane at any point in time.

If the IRS datalink was lost due to whatever reasons, the AES would not be able to calculate the propagation delay (or the Doppler). The resultant BFOs and BTOs would just be a function of the movement and velocity of the satellite, which is exactly what we see in the data.

By the way, when the ‘final arc’ was announced on March 15th (prior to the discovery of the partial ping), Inmarsat had said the arc was calculated from the signal’s angle of elevation. No mention of anything about BTOs then.

Anyone who has read the manual would know one cannot use the BTO as defined in the manual, to calculate the distance between the AES and the satellite. It would appear all the experts have so far failed to read the manual or are suffering from a collective case of wilful blindness. In either case, these self professed experts are guilty of, in the words of someone on Jeff’s blog, HELPING TO SELL A LIE.

I see you are alive and well.

Indeed, my questions on the BTO were not a popular topic. It appears that you and I have independently raised the question of the time slot as it relates to the BTO. My focus was the possibility that one or more of the BTOs could be tethered to the wrong time slot, perhaps by human interpretation, the way we assume an old Buick has 110,000 miles even though its 5-digit odometer only shows 10,000.

I was not expecting to tone of the responses suggesting I was ignoring the laws of physics. Nonetheless, nobody has any obligation to answer a question they feel is a waste of time. So, here I am.

From the answers I did receive, I got contradictions:
1. Collisions are possible and result in a retry
2. Collisions are not possible because time slots are arranged by the ground or the satellite.

From another source, I’ve learned that R-channel is not collision proof, while T-channel is because the slots are always assigned. So, both 1 and 2 above could be accurate, just incomplete.

Now, here’s the part in struggling with.
3. Inmarsat’s paper says BTOs are measured from the beginning of the time slot
4. Others say they are round trip.
5. Your reference says the max is 300us and either positive or negative.

Items 3 and 4 conflict, unless the time slot starts exactly when the ground starts the signal. Only then can the offset to the time slot start be the same as the round trip. However, under this scenario, much of the slot would be empty, and the BTO could never be under 300us as required.

That’s where I’m struggling with these values. As far as I can tell, and let me know if you think otherwise, a slot is 125ms and an R packet is 33 bytes. Up to 5 packets could fit in a slot. However, the slot is smaller than the round trip time of 496ms, so the measured time can’t be both round trip and start-of-slot offset, because by the time the AES sent the signal it would be in the wrong slot.

So, then I assume that the signal really is +/-300us from a slot boundary, and the AES waits for an upcoming slot, and sends the signal early enough that it hits +/-300us from the slot start time. That sounds efficient and reasonable, but that’s not what these BTOs look like. That also means there must be a mechanism that holds up a signal so it arrives at the scheduled time. The protocol wouldn’t work otherwise.

That mechanism would either need to use 1) the plane’s location, 2) the last measured signal trip time or a pilot signal, or 3) a nominal terminal constant.

So, let me just get your thoughts on #1 here. It is problematic because if the plane’s location is used to target the right slot, the BTO should always be near zero, the way the BFO is compensated (partially.) Logically, if the frequency is compensated to account for the location, why wouldn’t the timing also be compensated this way? And, if the frequency algorithm is broken because of 1) the software issue and 2) the satellite wobble, then wouldn’t the timing also be broken?

But, the protocol rule you state (and I’ve also found) simply cannot work without a fairly accurate timing delay, OR the bandwidth is highly degraded and Inmarsat just deals with it.

Your thoughts?