IPB




POSTS MADE TO THIS FORUM ARE THE SOLE RESPONSIBILITY OF THE AUTHOR AND DO NOT NECESSARILY REFLECT THE VIEWS OF PILOTS FOR 911 TRUTH
FOR OFFICIAL PILOTS FOR 9/11 TRUTH STATEMENTS AND ANALYSIS, PLEASE VISIT PILOTSFOR911TRUTH.ORG

WELCOME - PLEASE REGISTER OR LOG IN FOR FULL FORUM ACCESS ( Log In | Register )

 
Reply to this topicStart new topic
Acars Question For Dennis Cimino

woody
post Mar 23 2012, 12:42 PM
Post #1


Woody Box


Group: Respected Member
Posts: 257
Joined: 28-August 06
Member No.: 20




Hi Dennis

QUOTE (Dennis Cimino @ Mar 20 2012, 06:28 AM) *
he's not a pilot. and in all honesty, non-aviation people really don't get it. aviation is a very very hard thing for most people to fully comprehend and fully
understand.

only a pilot with a lot of experience can fully grasp a lot of stuff we take for granted...and it's not too very often you'll find a layperson who
even remotely comes close to understanding either the FAR's or the reason why procedures are the way they are.


here's someting from a layperson.

You know Stutt's ARINC file and certainly have studied it to a certain degree.

I have a question that bugs me for weeks now: these ULBLKs (Uplink Blocks, Ground-to-Air messages) - are they initialized by a handshake, i.e. an exchange of data between ground station and plane? This was told to me by a friend who's not an expert in communication technics, but close to that. He told me that ACARS basically follows the same procedure as Telex and Fax.

Thanks for the answer in advance.

Go to the top of the page
 
+Quote Post
woody
post Apr 30 2012, 03:14 PM
Post #2


Woody Box


Group: Respected Member
Posts: 257
Joined: 28-August 06
Member No.: 20



Hmm...I think I can forget to get an answer from Dennis.

But it was a rhetorical question anyway. The ULBLKs are indeed initiated by a handshake procedure before the core message is transmitted. Everybody can check that out with keywords like ACARS, handshake, fax, telex, etc. Or ask a friend who is familiar with communication technics.

So we have this causal chain:

ULBLK sent -> Handshake was successful -> Good VHF connection between ground station and plane -> the plane's transceiver is intact and the plane is within Line of Sight (or nearly-LOS) of the ground station.

One thing is for sure: this "plane" here



has neither an intact transceiver, nor is it within LOS of any ground station, so it is certainly not able to perform an ACARS handshake.

But according to the Stutt ARINC files, United 93 exchanged 18 handshakes with a ground station after the Shanksville crash:

FLoc=364376761 ULMSG 10:10:59
FLoc=364377004 ULBLK 10:10:59
FLoc=364444200 ULBLK 10:11:09
FLoc=364509548 ULBLK 10:11:19
FLoc=364582400 ULBLK 10:11:29
FLoc=364644886 ULBLK 10:11:39
FLoc=364717563 ULBLK 10:11:50
FLoc=364793973 ULBLK 10:12:00
FLoc=364860965 ULBLK 10:12:10
FLoc=364917445 ULBLK 10:12:20
FLoc=364988118 ICPUL 10:12:30

FLoc=364414154 ULMSG 10:11:04
FLoc=364987939 ULBLK 10:12:30
FLoc=365059033 ULBLK 10:12:40
FLoc=365135360 ULBLK 10:12:50
FLoc=365214130 ULBLK 10:13:00
FLoc=365302744 ULBLK 10:13:10
FLoc=365386465 ULBLK 10:13:20
FLoc=365464105 ULBLK 10:13:30
FLoc=365550345 ULBLK 10:13:40
FLoc=365612804 ULBLK 10:13:50
FLoc=365678382 ICPUL 10:14:00

These are messages #18 and #19 to Flight 93 following the chronology of United dispatch expert Michael Winter, and he implicitly says they have been received by the plane. Warren Stutt, however, seems to think that Winter is an idiot:

Also the file shows that there are no type DLBLK blocks and therefore no ACARS messages received from UAL93 after the official time of the crash.

Warren.


Mr. Stutt overlooks the difference between "received" and "acknowledged". Obviously messages #18 and #19 have not been acknowledged (no DLBLKs), but this doesn't mean they have not been received. A ULBLK may have been received by the plane, but the acknowledgment may fail to reach the ground station, and that's obviously what happened here. That's why the messages are resent every 10 seconds and after 9 futile attempts, an error message (ICPUL) is generated.

Like many I'm sure that the Stutt ARINC files have been forged to a certain extent. But as you see, you can still extract valuable information out of it. In fact, the files correspond to Winter's statement pretty well.

I'm currently working on my next blog entry. Everybody here is encouraged to tell me (sources included) if ACARS uplinks are indeed initiated by a handshake.

This post has been edited by woody: Apr 30 2012, 03:16 PM
Go to the top of the page
 
+Quote Post
rob balsamo
post Apr 30 2012, 06:03 PM
Post #3



Group Icon

Group: Admin
Posts: 9,602
Joined: 13-August 06
Member No.: 1



QUOTE (woody @ Apr 30 2012, 03:14 PM) *
Warren Stutt, however, seems to think that Winter is an idiot:


After having many exchanges with "Warren Stutt" over the years, combined with his admitted lack of expertise in aviation, and his repeated evasion of crucial questions which destroy his theories, I am convinced he is nothing more than a Sheldon wannabe.
Go to the top of the page
 
+Quote Post
bambooboy
post May 4 2012, 02:45 AM
Post #4





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935



QUOTE (woody @ Apr 30 2012, 03:14 PM) *
I'm currently working on my next blog entry. Everybody here is encouraged to tell me (sources included) if ACARS uplinks are indeed initiated by a handshake.


HI Woody.

my two cents here (I say 2cents only because I'm pretty sure ou yet knows about this document...if not...? bingo? )

PDF version: BOEING CAGE CODE 81205 doc n D926T0280.pdf
http://www.boeing.com/commercial/caft/cwg/...767_ATS_SRO.pdf

DOC version: PegasusSRO.doc
http://www.overlookci.com/PegasusSRO.doc



It says there:
-----------
7.3.2.3 ACARS Air-Ground Protocol
(...snip...)

Messages greater than 220 characters are termed 'multi-block' messages. That is, they are divided into 'blocks' no greater than 220 characters in size. Each 'block' then becomes an individual transmission on the air-ground subnetwork.

The ACARS air-ground protocol is a CSMA protocol with a window size of 1, which uses a simplex channel. In simple terms this means that if the VHF channel is in use then access is denied but when clear then all users may access it. An ACARS block must be acknowledged before another ACARS block can be transmitted. Transmission cannot occur if a block is being received

All ACARS message headers contain the aircraft registration, a technical acknowledgment field and an up/downlink block identifier (UBI/DBI). Messages are acknowledged by other messages with a Technical Acknowledgment set to the Block Identifier value used in the message being acknowledged. A negative acknowledgment is indicated by a special character. If either the DSP or the airborne Communications Management function has no data to send but must acknowledge a received message, it sends a 'general service message' with the appropriate Technical Ack.
All ACARS messages have a Block Check Sequence (BCS) appended to them for error checking purposes.

7.3.2.3.1 Uplink Transmission
(...snip...)
For each message transmitted, the DSP sets a NO ACK timer. One of three things may then happen:

A message is received with a technical acknowledgment corresponding to the UBI used in the uplink message. The transmission is considered successful and the UBI is incremented for the next message.
The DSP receives a message with a negative acknowledgment (NACK). The transmission is considered to have failed and a re-try is attempted. There may be three re-tries.
The NO ACK timer expires and no acknowledgment has been received. The transmission is considered to have failed and a re-try is attempted. There may be three re-tries.
Once the NO ACK timer expires and none of the retries have been acknowledged, the DSP should route the message via an alternate media (such as SATCOM) or to another service provider using internetworking. If all attempts via all means are unsuccessful, the service provider originally receiving the uplink notifies the originator of the message that the message was not delivered. The service provider then purges the message.

(...snip...)

Step Description
1 ATC sends message to SP
2 SP sends message ACK to ATC [SP returns msg with reason if uplink cannot be formatted]
3 SP breaks message into blocks if necessary, then sends block to Airborne Communications Management function
4 Airborne Communications Management function sends block ACKs to SP [Airborne Communications Management function sends NAK if BCS fails]
5 Airborne Communications Management function re-assembles blocks if message is a multi-block message, then sends LDU1 to Airborne ATS application system
[Airborne Communications Management function sends reject to SP if uplink is undeliverable]
6 Airborne ATS application system sends link layer ACK to Airborne Communications Management function
[Airborne ATS application system sends NAK if CRC fails or if the msg is larger than 2 LDUs]
7 SP sends MAS to ATC after all blocks are ACK'd by the Airborne Communications Management Function. [SP returns msg with reason if uplink was undeliverable]


----------

So, as far as I could understood, the answer to your question is (unfortunatelly) No.
there is no handshake. it's a more "physical" thing. it's not ISO-OSI like for this aspect.

"Dispatcher" send message to "Plane".
if "Plane" VHF Channel is occupied by other transmission/plane is out of LOS/ plane is crashed/VHF is broken/etc the message is not delivered (at first try by original provider). the NO ACK timer expires and no acknowledgment is received. So from here on start all the procedural steps: 3 retry; then other Channels, other provider, and then ICPUL error code etc sent to the originator (dispatcher)

all these try and retries last at max 11 minutes.
after that time, ARINC CPS must send an error message to the dispatcher (originator).

hope it helps.
ciao


Bambooboy
http://info911insidejob.blogspot.com/
Go to the top of the page
 
+Quote Post
bambooboy
post May 4 2012, 03:04 AM
Post #5





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935




ops... this part forgotten... so here it is:

in other words:

there is no way (well, not exactly, but you can understan what I mean) to be sure by which RGS or even GES the message is transmitted.
it is even uncertain which is the provider who phisically deliver the message.
Even time is not that sure (11minutes range, well, let's say 12 to be large)
BUT:
UNLESS an error report apeears in the dispatcher log: by default this means that the message has been positively delivered

the fact that Arinc is forced to try also thru GES and thru other Providers... it's just another thing that disminish the credibility of the "stutt's logs" anyway (not to talk about the different FLoc Numbers and the missing FOIA stamps and Bates numbers).

again,
hope it helps.

ciao
bambooboy
Go to the top of the page
 
+Quote Post
woody
post May 8 2012, 03:29 PM
Post #6


Woody Box


Group: Respected Member
Posts: 257
Joined: 28-August 06
Member No.: 20



Hi bambooboy

nice to meet you! salute.gif

Your argument is that because the word "handshake" doesn't appear in the Boeing manual, there is no handshake. But because the handshake is a low-level automatical standard operation, there is no need to mention it IMHO. Simply not important enough.

But in fact, the word pops up one time in the paper:

QUOTE
7.3.2.1 DOWNLINK MESSAGE FLOW

On the ground, messages are received by either an RGS or a GES which forward the messages to the DSP. They also perform some minor processing. One important function being to facilitate 'tracking' by adding the identity of the receiving RGS or GES to the message.

Upon receiving a message, the DSP 'handshakes' with the aircraft Communications Management function according to the ACARS air-ground protocol. The DSP then performs a number of functions on the received message.


In the "Uplink Messages Flow" section, there is no handshake mentioned, but as I said, just because it's not mentioned doesn't mean it's not existent. I'm sure that all of the uplinks are initiated by a handshake, just like the downlinks. And again, ACARS is, like Fax, an offspring of the old Telex system, all of them using handshakes to establish and optimize the communication process.

Here's another argument. If the ground station would send the ULBLKs "blindly" (i.e. without handshake), this would mean that the transmission process to a plane out of LOS would congest the frequency and waste precious time, without any chance to reach the recipient. I've learned that the "Plain Old ACARS", which was in effect on 9/11, was pretty slow and inefficient. To keep the system efficient, it was therefore mandatory to throw out all redundant transmissions. Uplink messages to a plane out of LOS are 100% redundant. A preceding handshake would enable the sender to cease the transmission of the core message, thereby saving valuable time because the handshake needs much less milliseconds than the core message. This is another benefit of the handshake.

Another thing regarding the Boeing document - I'm not sure if the routine described there was in effect on 9/11, at least not 100%. For instance the Boeing paper talks about three retries in a NO ACK situation. But the Stutt ARINC file has maximum nine retries before a NO ACK error message is generated.

This post has been edited by woody: May 8 2012, 04:06 PM
Go to the top of the page
 
+Quote Post
bambooboy
post May 9 2012, 02:47 AM
Post #7





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935



Hi Woody,
as promised, here I am trying and answering your points; 'tough "debating" or "brainstrorming" is a more correct term than "answering".

As you know, me too I do think acars are really the key to unveil the "mistery", so dont misunderstand my replies (may be I'm right, may be I'm wrong, I simply trying to explain what I've understood from the documents, BoeingCageCode/PegasusSRO in particular).

so, let's go on
(PS: the list is not ordered for importance)

1):
You say: "...regarding the Boeing document - I'm not sure if the routine described there was in effect on 9/11..."

Yet I had the same question too for a while. So I sit at the desk, red, researched and then I wrote two posts on the topic:
- the first:
http://info911insidejob.blogspot.com/2012/02/research-sections-il-fmc-flight.html
- the second:
http://info911insidejob.blogspot.com/2012/02/research-sections-perche-possiamo.html
[written in italian, but all quotations and imgs, are in english; so it should be easy also for not italian speaking people to read and understand]

and yes: FMC and Pegasus infos in Boeing document apply to UA93/UA175.
But is also correct to highlight that:
1.0 PURPOSE AND SCOPE
"This document will not cover the requirements associated with the Airline Operational Communications Datalink (AOC DL)."

We know there are 3 different types of acars "services":
- Air Traffic Control (ATC)
- Aeronautical Operational Control (AOC)
- Airline Administrative Control (AAC)

"AOC and AAC messages are used to communicate between the aircraft and its base. These messages are either standardized according ARINC Standard 633 or defined by the users, but must then meet at least the guidelines of ARINC Standard 618. "
Source: http://en.wikipedia.org/wiki/Aircraft_Communications_Addressing_and_Reporting_System

These words will also come handy later, when I tell you about your point on the numbers of retries (3 by Boeing, 9 by Stutt)


2)
from the last line of point one, directly come to my mind this:
but d'you think Stutt's Arinc log are true???"
- FLoc numbers wrong
- no FOIA number
- no offical stamps whatsoever
- no bates numbers on pages
- no FOIA author's name
- no FOIA date
- UA175 logs missing
- no day/month/year for the document output
NOTHING
can it be considered a reliable source? Imho: NO.

3)
about "handshake"... you quoted:
"7.3.2.1 DOWNLINK MESSAGE FLOW"
"Upon receiving a message, the DSP 'handshakes' with the aircraft Communications Management function according to the ACARS air-ground protocol. The DSP then performs a number of functions on the received message"

Yes, in the "download message Flow 7.3.2.1" the term handshake apperar. BUT:
a) it is the downlink section downlink and not in the uplink one
b) and more more important: in the Boeing document handshaking is written in between " ".

This, imho, because the term is used as a quick n easy to understand reference, but it is not "real" handshaking (if it was, why writing 'handshakes' and not handshakes ?.). It surely is something that can be compared to, but it is not the same as the TCP 3-Way Handshake (SYN,SYN-ACK,ACK). Here we are in a fake 3-way, while in reality it is only a two-way (ack or no-ack), that is why it cant be officially called "hanshake".

Then, you wrote:
"handshake is a low-level automatical standard operation".
Low-level or High-level, it make few or no difference to us all now. What is important is the fact that is automatic. That's totally true. And it can be red in the following sub-chapter:
"7.3.2.3.2 DOWNLINK TRANSMISSION":
"- Airborne Communications Management function divides message into blocks, then sends block to DSP (Note: The AirborneCommunications Management function continues to send the message until the DSP responds.)
- DSP sends block ACK to Airborne Communications Management function [DSP sends NAK or no response if BCS fails]
- DSP sends message to ATC Facility
- ATC Facility sends ACK to DSP
"

It is important to remenber that acars are a one-way communication system (n better terms "this means that if the VHF channel is in use then access is denied" [Source 7.3.2.3 ACARS AIR-GROUND PROTOCOL]).
In acars case "HANSHAKING" is the whole ACKNOWLEDGEMENT process and more, becuase it keep in itself also CRC calculation to prevent errors and message itself.
This is not TCP this is not fax or phonecalling, this is a VHF (data-link) radio broadcast transmission!!!


the fact that for each message (max 220 characters) the system set timers AND wait for ACK, NO-ACK, and if everything ok then the UBI is incremented for the next message: this is the "handshake", the "acknowlege", the "CRC" and the "message" too.

The document, IMHO, is self-explantory when writes:
"7.3.2.3 ACARS AIR-GROUND PROTOCOL"
"Messages are acknowledged by other messages with a Technical Acknowledgment set to the Block Identifier value used in the message being acknowledged. A negative acknowledgment is indicated by a special character. If either the air-ground message processor or the airborne Communications Management function has no data to send but must acknowledge a received message, it sends a 'general service message' with the appropriate Technical Ack."

"Messages are acknowledged by other messages with a Technical Acknowledgment set to the Block Identifier value used in the message being acknowledged", can only means that:
the acknowledge (ie: the physical evidence of positive receipt) is not done on a (low-level) layer, but need two messages (automatic) to be positively "confirmed"

Making it simple: "sender" sends a message to "receiver", but until there is not (an automatic) reply the "handshaking status" is unknown.
In fact, "if either the air-ground message processor or the airborne Communications Management function has no data to send but must acknowledge a received message, it sends a 'general service message' with the appropriate Technical Ack."

4)
you wrote:
"For instance the Boeing paper talks about three retries in a NO ACK situation. But the Stutt ARINC file has maximum nine retries before a NO ACK error message is generated"

That's true (if you believe Warren Stutt Arinc Logs to be true and untampered), but:

- a) "7.3.2.3.1 UPLINK TRANSMISSION"
"Once the NO ACK timer expires and none of the retries has been acknowledged, the DSP should route the message via an alternate media (such as SATCOM) or to another DSP using internetworking (Section 7.3.3). If all attempts via all means are unsuccessful, the DSP originally receiving the uplink notifies the originator of the message that the message was not delivered. The DSP then purges the message.

-b) "1.0 PURPOSE AND SCOPE"
"This document will not cover the requirements associated with the Airline Operational Communications Datalink (AOC DL)".

-c) AOC and AAC messages are used to communicate between the aircraft and its base. These messages are either standardized according ARINC Standard 633 or defined by the users, but must then meet at least the guidelines of ARINC Standard 618.
Source: http://en.wikipedia.org/wiki/Aircraft_Comm...eporting_System

This is (IMHO) the reason why we encounter more re-tries in the sattamassagana Stutt Arinc log file.

5)
It is a fact, an evidence, that Boeing wrote:
"7.3.2.3.1 UPLINK TRANSMISSION"
"If all attempts via all means are unsuccessful, the DSP originally receiving the uplink notifies the originator of the message that the message was not delivered".

So, my question is: what does this means? what this imply?

It clearly imply that: until a "notice by the DSP to the sender" is not present in the dispatcher acars log, the dipacher previous messages were sent and phisically received by the plane for sure (that's the trick of the ack no-ack timers).

yes, you can ask me: "hey, but how much times last the various reties?", and this is a correct and spicy questions.
But is a question a little bit harder to answer.

Boeing says:
"7.3.2.3.2 DOWNLINK TRANSMISSION"
"The Airborne Communications Management function may retry a message if the NO ACK timer expires. The timer is programmed differently depending upon whether the Airborne Communications Management function is using VHF or SATCOM, and depending upon the DSP. For example, in ARINC VHF, typically retries are between 10 - 25 seconds, whereas with SITA VHF, the retries are between 6 - 15 seconds. SATCOM retries are 180 seconds apart for the first two attempts, then the Airborne Communications Management function artificially declares the SATCOM to be NO COMM for 600 seconds before attempting a downlink again. The NO ACK timer is reset if an uplink is received."

We know (from Ballinger log and from the totally uncertain Stutt Arinc logs that no GES (no SATCOM) has been utilized (all the acronymous are from RGS).
So the count it should be simple: number of retries * 25 seconds

But we (I at least unfortunatelly) do not have the Arinc 618, Arinc 620, Arinc 633 and Arinc 622.

So, based on the debunkin efforts of boonyzarc and co., I actually have to accept that between the first un-received message by the crashed UA93 and the obbliged error report from the ARINC CPS to the UAL dispatcher (Ballinger), can even pass up to 11 minutes (ICPUL at 10:14 - crash at 10:03:11 = 11 minutes ).

11 minutes is an outrageous long time, but... ok, ok. let's accept it for a moment. It is true that ACARS sistem at those time was "slow and inefficient", even though 11 minutes is much more than "slow"

But again, let's accept it for a while.
Let's accept it becuase it does not anyway solve the "Acars theory" questions!!!
11 minutes retry can only save duhbunker asses on the UA93 problem... but even that way how they can explain the Ballinger uplink at 9:23 EDT, and the one at 9:51 EDT to UA175, while crash time is 9:03:11 ?
Unless they say that Ballinger with his 44 years as a dispatcher, and all the dispatchers at the UAL SOC in Chicago, all of them missed Arinc CPS error reports log on their screens, they can only do one other thing only. Guess which?
yessss! have UA175 acars missing from Stutt files!
LOL


well Woody, hope my 2cents-brainstorming helps you (and others) in your researches.
I do appreciate if you'll reply to my point of views (thread or PM is the same): as told before, this is what I understood from the papers, but it is always a good thing when somebody explain where and why (IF) one's misunderstanding

Bambooboy

This post has been edited by bambooboy: May 9 2012, 02:51 AM
Go to the top of the page
 
+Quote Post
woody
post May 10 2012, 09:32 AM
Post #8


Woody Box


Group: Respected Member
Posts: 257
Joined: 28-August 06
Member No.: 20



You touch many topics. I'll use your section numbers for my answers.

1) and 4)

Agreed - the difference between the Stutt file and the Boeing paper regarding the number of re-tries emerges probably because the Boeing paper doesn't refer to the AOC.

2)

I share all of your objections and have addressed them in my last blog entry "Open letter to Warren Stutt". I have also addressed there the odd missing of CLE and CAK in the position data and recommended to take the Stutt file with a grain of salt.

However - despite these flaws, I regard the Stutt file as very meaningful because it allows to take a deep look inside the ACARS communication on 9/11, and I have learned a lot from it. In fact, when it comes to the time (disregarding the position) the Stutt file confirms Winter's statement and the list of Ballinger's ACARS messages to UA93. It corresponds to them 1-1. It is even able to explain the case of message #20 (Winter) which has a different look than messages #21 to #24, but has been rejected just like them. Due to the Stutt file, it is clear that when Ballinger sent message #20, the system was still busy with resending message #19 in a 10-seconds rhythm, and message #20 had to wait in the output buffer. Messages #21 to #24 were rejected outright because the output buffer was empty, that's why they have a different appearance than message #20.

This is just one example that the Stutt file is helpful even if some data seem to have been altered. But if I have a tasty looking apple in my hand with just a little unappetizing spot, I cut out the spot and eat the rest of the apple. Again: I've learned a lot from the Stutt file, especially from the parts which are certainly not altered because they are not in conflict with the official story.

3)

Half a year ago, I didn't even know that a "handshake" existed in communication technics. From what I've read since and what I've heard from more knowledgeable people, a handshake is an exchange of data between a sender and a recipient to prepare the transmission of the actual message. Your definition says that the message itself is part of the handshake. But I've never met such a generalized definition of a handshake.

Here's what wikipedia says about "handshaking":

QUOTE
In information technology, telecommunications, and related fields, handshaking is an automated process of negotiation that dynamically sets parameters of a communications channel established between two entities before normal communication over the channel begins. It follows the physical establishment of the channel and precedes normal information transfer.


I don't see how the complete ULMSG-ULBLK-DLBLK sequence (which is a handshake according to you) fits this definition.

5) I'm not sure what's your point here, so here are my 2 cents:

The NO ACK timer in the Stutt file is definitely 10 seconds. If a ULBLK is not acknowledged, it is resent after 10 seconds. There are countless examples, two of them I have just posted. The 11 minutes have nothing to do with these NOACK timer. With each downlink of the plane, the 11 minute timer begins to run. If the plane hasn't sent a downlink for 11 minutes, it sends a special "tracker message" downlink to refresh its status on the ground. If the plane doesn't send a downlink for 11 minutes for some reason, the routing table of the DSP is empty, and if the dispatcher tries to send an uplink message then, an error is generated.

This is also something you can derive from the Stutt file. The last downlink from UA93 happened at 10:01 (it was in fact a tracker message). Message#20 was rejected because the routing table was empty, and the routing table was empty because UA93 didn't send a downlink for 11 minutes.

Go to the top of the page
 
+Quote Post
bambooboy
post May 10 2012, 01:34 PM
Post #9





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935



QUOTE (woody @ May 10 2012, 09:32 AM) *
1) and 4)
Agreed - the difference between the Stutt file and the Boeing paper regarding the number of re-tries emerges probably because the Boeing paper doesn't refer to the AOC.

yep!

QUOTE (woody @ May 10 2012, 09:32 AM) *
2)
I share all of your objections and have addressed them in my last blog entry "Open letter to Warren Stutt". ...snip...
...However - despite these flaws, I regard the Stutt file as very meaningful because it allows to take a deep look inside the ACARS communication on 9/11...snip...
...the Stutt file confirms Winter's statement and the list of Ballinger's ACARS messages to UA93. ...snip...
...it is clear that when Ballinger sent message #20, the system was still busy with resending message #19 in a 10-seconds rhythm, and message #20 had to wait in the output buffer. Messages #21 to #24 were rejected outright because the output buffer was empty, that's why they have a different appearance than message #20.

Agreed. I didnt say that Stutt acars are not helpful, I said that... I said tath... well, ok, I tell: are untrustable and/or tampered! obviously (if not why tampering them?) they have to be in (partial) accord with Winter words and Ballingers logs

QUOTE (woody @ May 10 2012, 09:32 AM) *
3)
...snip...a handshake is an exchange of data between a sender and a recipient to prepare the transmission of the actual message. Your definition says that the message itself is part of the handshake. But I've never met such a generalized definition of a handshake.
Here's what wikipedia says about "handshaking" ...snip...

I was "generalizing" on purpose to explain the concept (as stated in the PegasusSRO.doc).
In that official document, anyway, nowhere is stated anything about acars "handshakes". the only time they uses that word, Boeing takes good care in writing it in between "" ('handshake' and not simply handshake. and this makes me ringing a bell.)

let's go talking about "handshaking", now:

A)
"Handshaking can be used to negotiate parameters that are acceptable to equipment and systems at both ends of the communication channel, including, but not limited to, information transfer rate, coding alphabet, parity, interrupt procedure, and other protocol or hardware features"
SOURCE: http://en.wikipedia.org/wiki/Handshaking

I discard this for acars becuase:
this would be pretty useless (imho) in ACARS communication system, because communication architecture is known and cant differ from one/sender to another/receiver ( all message MUST follow the same protocol specifications. both arinc and sita must respect the same main rules. providers format messages).
Acars is a "closed"/specific communication environment. Moreover, DSP yet convert and proprely format all acras messages, so this (imho again) excludes the problem solved by the ISO-OSI layers model (that is a model for "open" environments, in which the sender cant know before which is the architecture of the receiver).

from the same SOURCE, you can in fact read that: "Handshaking makes it possible to connect relatively heterogeneous systems or equipment over a communication channel without the need for human intervention to set parameters".
Is acars system an eterogeneous system or equipment? No. All equipments and all providers must strictly comply with the same protocols.

B)
but, as we all know, an handshake can also be something "simplier".
Wikipedia too (to make it easy I used the same SOURCE as before, but on the net there's plenty of pages talking about handshaking and ISO-OSI, etc.) says it:
"A simple handshaking protocol might only involve the receiver sending a message meaning "I received your last message and I am ready for you to send me another one"
SOURCE: http://en.wikipedia.org/wiki/Handshaking

I think this fits perfectly the acras case! and I think that this is exactly the idea of handshaking you are referring to, ain't it?

But "involving the receiver sending a simple automatic message meaning "I received your last message and I am ready for you to send me another one"... is not exactly the same of what we can read in that Boeing .pdf, isn't it? YES, I do think so!

In my previous reply I wrote:
"Messages are acknowledged by other messages with a Technical Acknowledgment set to the Block Identifier value used in the message being acknowledged", can only means that:
the acknowledge (ie: the physical evidence of positive receipt) is not done on a (low-level) layer, but need two messages (automatic) to be positively "confirmed"


So, where is the difference from what wikipedia say about "simple handshaking" ( A simple handshaking protocol might only involve the receiver sending a message meaning "I received your last message and I am ready for you to send me another one")?
I do not see any.

That's why I say, in my horrible english and in my horrible way to express my thougths in any languages) that in the acars system the "handshaking" is part of the messages too, a part more focused on acknowledgment; and that's way Boeing call it 'hanshaking' and not handshaking (IMHO)

In this "closed" communication environment the handshaking needed to determine the correct protocols to exchange datas are useless.
But what is still needed (to know if a message has been or has been not delivered and successfully with out errors) is the evidence of the "connection status" (the "I received your last message and I am ready for you to send me another one").
This thing is performed by the DSP setting, among the other, the NO ACK timer.
( A message is received with a technical acknowledgment corresponding to the UBI used in the uplink message. The transmission is considered successful and the UBI is incremented for the next message.
The DSP receives a message with a negative acknowledgment (NACK). The transmission is considered to have failed and a re-try is attempted. There may be three re-tries.
The NO ACK timer expires and no acknowledgment has been received. The transmission is considered to have failed and a re-try is attempted.
)

The whole job is on the acknowledge's shoulders. but acknowledgements are part of the messages too.
So, if you think that in my previous post I've been too much "generalizing", I hope in this one I've been a little more neat in my explanations wink.gif

C)
and there is a one more point that should drive to conclude for "no official handshaking" in acars protocols. And this point is Stutt logs (for those who believe in them).
In Stutt logs there are not datas that can be labelled as such ("A simple handshaking protocol might only involve the receiver sending a message meaning "I received your last message and I am ready for you to send me another one"), or not as far I realized it.

Based on the "handshaking" theory they should I guess, because RGS do not "dechyper" the messages: they only send/receive, acting as a bridge to/from DSP. And DSP is the only one that decrypt/reads/understand datas inside and keep tracks of exipring times. So, imho, even if "handshaking" exists, RGS should have forwarded to DSP to know the result of the handshakings. But these quick simple chit-chat are missing in Stut logs

My reasoning on this point C is unproven (except for the fact that those handshaking are not present in Stutt logs): just logic I know, so it can be totally screwed up too. But anyway it is a point to think about too.

QUOTE (woody @ May 10 2012, 09:32 AM) *
5)
...If a ULBLK is not acknowledged, it is resent after 10 seconds...snip..
...The 11 minutes have nothing to do with these NOACK timer. With each downlink of the plane, the 11 minute timer begins to run. If the plane hasn't sent a downlink for 11 minutes, it sends a special "tracker message" downlink to refresh its status on the ground...snip...

On this you're perfectly right. It's my fault I didnt express myself clearly enough. I wrote about the 11 minutes because that was what the duhbunkers wrote about to wipe out the acars problems for UA93. I simply introduced that variable to explain that EVEN IF we accept this for granted, the sum dont adds up correctly for UA175 (see point 5 in my previous post)

Again and again ever, I can be wrong (as anyone can be), but these actually are the conclusions I came to. I need more than a 'an handshake there must have' to take it for sure. Anyway all this do not affect or wipe out what acars logs loudly show!

bambooboy

PS: I think is a good thing this kind of confrontation-brainstorming (weakening the weak away and giving strenght to strongest points), helping both and others to wipe some fog away.

This post has been edited by bambooboy: May 10 2012, 01:39 PM
Go to the top of the page
 
+Quote Post
bambooboy
post May 10 2012, 02:53 PM
Post #10





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935



as always... I forget a part...here it is

Talking about handshaking:

The ACARS air-ground protocol is a CSMA protocol with a window size of 1, which uses a simplex channel. In simple terms this means that if the VHF channel is in use then access is denied but when clear then all users may access it. An ACARS block must be acknowledged before another ACARS block can be transmitted. Transmission cannot occur if a block is being received
SOURCE: PegasusSRO.doc

simplex channel.
not duplex or multiplex. that's the point

this simply makes impossible "handshaking" the simoultaneous iso-osi way you are "imagining" of.
but pretty well explain why more messages (that have to be routed to the DSP, and that can be tracked as in the sattamassagana Stutt Arinc logs) are needed for "aknowledgement".

Again, why the need to handshake if you yet know exactly the protocol you must utilize for the establish connection and send/receive datas on a simplex channel?

bambooboy

Go to the top of the page
 
+Quote Post
bambooboy
post May 16 2012, 03:04 AM
Post #11





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935



Hi all,
here it is a little small gem, for all those intersted on the ACARS debate.

Just discovered thid document:
http://ntl.bts.gov/lib/1000/1200/1290/tn95_66.pdf

Fisrt thing to sy ais that is an official FAA and ARINC document. Second it is dated back to 1995, so prior than 2001 and prior than some better tuning f the ACARS protocol.

But what's in it?

two things:
a) times needed to deliver/receive an ACARS message, stress tested in NYC-DCA-CHI Corridor (absolutely the same as the one for UA93). results talks about:
"Most of the message transit times fall into the 11- to 20-second bin range, with the second highest incidence in the 6- to 10-second range"

b) pretty import is that when we look at the log (Ballinger and Stutt), always apperas characther and punctualization that looks like without any sense (axcept to say: well, these are simply characters used in the ACARS world).

well in this document there is the complete list of these, and their explanations.

I list for you here:

Label Sublabel Uplink/Downlink Message Type

DEL n/a U General Acknowledgment
:; n/a U Autotune to New Frequency
RA ~1 U Display Message
RA ~ 2 U 000I Dump
RA ~ 3 U Memory Dump
RA ~ 4 U Loop-Back Test
51 n/a U GMT Update
54 n/a D Voice Go-ahead
DEL n/a D General Acknowledgment
NAK n/a D Non-Acknowledgment
H1 DF D DFDAU Message
Q0 n/a D Link Test
Q5 n/a D Unable to Deliver Message
RB ~2 D 000I Dump


these coded characther looks like they did not have changed during the years, and we can see them in Stutt logs

Hope this will be helpful to Woody and all others interested in deeply look in the UAL acars.

RB ~3 D Memory Dump
RB ~4 D Loop-Back Test Response
52 TXT D Free Text Message
51 n/a D GMT Update Request

This post has been edited by bambooboy: May 16 2012, 03:09 AM
Go to the top of the page
 
+Quote Post
bambooboy
post May 16 2012, 10:10 PM
Post #12





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935



for those interested in the topic, here is another link that helps in clarify some others acars coding.

LINK: http://www.wavecom.ch/onlinehelp/WCODE/def...ments/acars.htm

From that pge, in among the others thing, we can learn that the "2" just after the <SOH> means that the transmission has been BROADCASTED (ACARS transmission in mode A).

example:
2.N591UA7RASQUHDQWDUA~10093-11 HOWGOZITUA93 EWRSFOEWR 1201/1242 490APSB 1311 35 432 DJB 1338 35 400 BVT 1409 35 363 IRK 1445 35 322 PWE 1508 35 296 MCK 1536 39 263 FQF 1603 39

that the values S=31 D=21 (present all along in the pdf) are referred to the "Character Sync"

and that the uplink test message transmitted at regular intervals from ground stations are called "SQUITTERS", and in the rawdata are the "SQ"

example:
2.N591UA7RASQUHDQWDUA~10093-11 HOWGOZITUA93 EWRSFOEWR 1201/1242 490APSB 1311 35 432 DJB 1338 35 400 BVT 1409 35 363 IRK 1445 35 322 PWE 1508 35 296 MCK 1536 39 263 FQF 1603 39

This post has been edited by bambooboy: May 16 2012, 10:10 PM
Go to the top of the page
 
+Quote Post
bambooboy
post May 19 2012, 04:13 PM
Post #13





Group: Student Forum Pilot
Posts: 43
Joined: 28-February 10
Member No.: 4,935



just passing by to see if there were any replies/deabting/confuting facts.
but 9 days later, everything looks silent and quiet.
well, this fortify my explanations about "no handshakings on a simplex channel in a closed known environmet" I guess

This post has been edited by bambooboy: May 19 2012, 04:14 PM
Go to the top of the page
 
+Quote Post
woody
post Jun 14 2012, 11:26 AM
Post #14


Woody Box


Group: Respected Member
Posts: 257
Joined: 28-August 06
Member No.: 20



QUOTE (bambooboy @ May 19 2012, 08:13 PM) *
just passing by to see if there were any replies/deabting/confuting facts.
but 9 days later, everything looks silent and quiet.
well, this fortify my explanations about "no handshakings on a simplex channel in a closed known environmet" I guess


bambooboy,

I sent you a PM, but was unable to reach you. What's up?

Go to the top of the page
 
+Quote Post
rob balsamo
post Jun 14 2012, 01:44 PM
Post #15



Group Icon

Group: Admin
Posts: 9,602
Joined: 13-August 06
Member No.: 1



QUOTE (woody @ Jun 14 2012, 11:26 AM) *
bambooboy,

I sent you a PM, but was unable to reach you. What's up?



Bambooboy is banned and this is why...

http://pilotsfor911truth.org/forum/index.p...&p=10805388
Go to the top of the page
 
+Quote Post
woody
post Jun 19 2012, 02:10 PM
Post #16


Woody Box


Group: Respected Member
Posts: 257
Joined: 28-August 06
Member No.: 20



QUOTE (rob balsamo @ Jun 14 2012, 05:44 PM) *
Bambooboy is banned and this is why...

http://pilotsfor911truth.org/forum/index.p...&p=10805388



Ooops...okay, in case he drops in and reads this...

I wanted to apologize for not answering for weeks. My regular job simply didn't leave me any spare time, but it's getting better now.

When I started this thread, I was looking for someone so familiar with ACARS that he's able to answer this simple question - are ULBLKs initiated by a handshake? - straightforward with YES or NO. Someone like Dennis Cimino.

bambooboy's arguments have some merit, and maybe he's right, but the "maybe" doesn't satisfy me. I'm still convinced that a handshake is part of the air-ground protocol for a couple of reasons, some of them have I mentioned. Anyway: the answer to my question can surely be found in the ARINC-618 protocol, but you have to pay for this document, about 200 bucks. This doesn't deter me, but I have no online cash account either. So let's wait until I find a way to achieve ARINC-618.

The question is pretty important. In the Stutt file, we have not only 18 ULBLKs for UA 93 after the Shanksville crash, but also 18 ULBLKs for AA11 after the North Tower crash (which doesn't really surprise me because the NORAD tapes have AA11 airborne after the crash, too) and also 2 ULBLKs for AA77 after the Pentagon blast.


Go to the top of the page
 
+Quote Post
woody
post Sep 5 2012, 02:55 PM
Post #17


Woody Box


Group: Respected Member
Posts: 257
Joined: 28-August 06
Member No.: 20



Okay, it's time now to close this thread. It has fulfilled its purpose.

I just detected, that Dennis Cimino had answered my handshake question already (that's maybe why he didn't react) - in Rob's ACARS article:

QUOTE
when an aircraft receiver's MDS (minimum discernible signal) sensitivity is achieved or reached out of the 'tangential' noise floor level, the aircraft's receiver then begins to try to data frame sync with the ground. then once that happens and two way 'ping pong' as data link persons refer to it, happens, then any queued messages get shipped to the receiving system and data relative to the aircraft's flight get sent back down to the ground.


http://pilotsfor911truth.org/ACARS-CONFIRM...FTER-CRASH.html

What Dennis calls "ping-pong" is a two-way synchronization procedure to enable the transmission of a message, in other words: a handshake;

I detected this statement, honestly, just hours ago. Don't worry - I don't intend to use it in my next blog entry. There are better sources for the handshaking. The prices of the ARINC papers have drastically gone down now, so I have acquired ARINC-618, the air/ground ACARS protocol.

According to ARINC-618, every message (uplink/downlink) is initiated by a "preamble", a procedure where phases, bits and characters are being synchronized. Without preamble, or handshake, or pingpong, the message ist not transmitted. More details in my next blog entry, in 2-3 weeks.

The transceiver of a burning crashed plane on the ground is certainly not able to handshake with the ground system.

But according to the Stutt files, we have eighteen ULBLKs (uplinks) to UA 93 between 10:11 and 10:13.

Moreover, we have 18 uplinks to Flight 11 between 8:48 and 8:50 and two uplinks to Flight 77 at 10:41 (somewhere in Kansas or so). All of these uplinks indicating that the planes' receivers responded with a handshake - they were alive and airborne.

Operation Northwoods, anyone?





Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 




RSS Lo-Fi Version Time is now: 23rd April 2014 - 01:30 PM