2521 replies to this topic

[protostar]

Kudos to you Boon

Don't know if it was dedication or stubborness or just that the subject gripped you so much, but it couldn't have been cheap buying that. I've got to buy British Standards (quite a few of them) plus
updates for my business, and well lets say it's already run into a four figure sum!

Look forward to seeing your next posts.

[Q24]

I had to read that a few times to understand it.

You know I lean toward use of the flight plan to determine were messages are routed as that fits what we are seeing.

But one question…

booNyzarC, on 15 December 2011 - 10:54 PM, said:

This means that it is NOT an indication of the actual RGS used for uplink attempts but is rather a prediction by the airline for where it expects the aircraft to be and is only used if the DSP doesn't already have routing information available in its tables.  Where do you suppose this is derived from?  Original flight plan anyone?

How do we know the airline is not basing prediction on aircraft location downlinks as referred in previous documents?

It still seems inconclusive from what I have read.

Is there anything else you can add?

And we need the second bullet point – how is it that ARINC often does not follow the airline instruction?  Don’t keep us in suspense!  

[booNyzarC]

protostar, on 15 December 2011 - 11:59 PM, said:

Kudos to you Boon

Don't know if it was dedication or stubborness or just that the subject gripped you so much, but it couldn't have been cheap buying that. I've got to buy British Standards (quite a few of them) plus
updates for my business, and well lets say it's already run into a four figure sum!

Look forward to seeing your next posts.

Thanks mate.  I attribute a combination of things to my desire for addressing this issue, but the biggest contributor was ValkyrieWings AKA Rob Balsamo himself; for reasons which should be obvious to anyone who has observed his behavior toward myself and many others for any amount of time.  What can I say?  The guy begs to be put in his place.

The Standards weren't exactly cheap, but they were worth every penny just for this.  It is like an early Christmas gift to myself, if you will.

[booNyzarC]

Thanks Windows Update for rebooting my computer just as I was about finished with my first response to this...

Now, where was I?  Oh yes...

Q24, on 16 December 2011 - 12:31 AM, said:

I had to read that a few times to understand it.

You know I lean toward use of the flight plan to determine were messages are routed as that fits what we are seeing.

But one question…

booNyzarC, on 15 December 2011 - 10:54 PM, said:

This means that it is NOT an indication of the actual RGS used for uplink attempts but is rather a prediction by the airline for where it expects the aircraft to be and is only used if the DSP doesn't already have routing information available in its tables. Where do you suppose this is derived from? Original flight plan anyone?

How do we know the airline is not basing prediction on aircraft location downlinks as referred in previous documents?

It still seems inconclusive from what I have read.

Is there anything else you can add?

The DSP (ARINC) makes use of the location downlinks referred to in previous documents to keep its internal routing tables updated, but the airline does not.  The DPSs use of this is evident by the ARINC 620-4 documentation and from the PDF supplied by Warren Stutt.  In fact, Warren's PDF shows us a perfect example of the Category A network protocol in action with each DLBLK that you see following each ULMSG and ULBLK reference.  The aircraft's omnidirectional transmissions are picked up by every RGS within range and it appears as though the routing table sequences a priority based on signal strength of those transmissions; the RGS with the strongest signal received is assigned as the initial station for future uplinks.  This routing table is dynamically updated with each downlink from the aircraft, just as the previously uncovered reference material has described, and this is distinct from the static information (i.e. the GL text element which I outlined in my previous post) which is supplied by the airline dispatch in each message sent to the DSP for delivery.

I should clarify that ARINC 620-4 does not indicate what source the airlines rely on for this predicted RGS.  That information is likely proprietary per airline or outlined in another standard which defines the communications between the airline and the DSP in more detail; the ATA/IATA Interline Communications Manual (ICM).  I haven't looked for this document yet and I don't really think it is necessary to answer the key questions on the table.  Edit to Add:  But I think it is more than reasonable to assume that the airline's prediction is based on the actual flight plan itself.  The GL text elements definitely appear to follow the flight plan in all of the examples I've examined from the FOIA materials. (/edit)

There is much more to add, yes, but I'd like to get the core points outlined and sourced first; and considering how slow I am in organizing these things it might take me the weekend to finish.  Follow up clarifications and rebuttals to P4T hand waiving will undoubtedly be needed as well.

Q24, on 16 December 2011 - 12:31 AM, said:

And we need the second bullet point – how is it that ARINC often does not follow the airline instruction?  Don’t keep us in suspense!  

Working on it, but all of my source documents closed when Windows Updates decided that I'd clicked on "wait 4 hours" too many times.   Speaking of which, I need to go open all of that up again.

Cheers.

Edited by booNyzarC, 16 December 2011 - 01:29 AM.

[skyeagle409]

booNyzarC, on 15 December 2011 - 10:54 PM, said:

I'd like to get back to the ACARS discussions and hopefully bring some finality to the subject.

I got tired of hunting through countless PDF files available online in search of the answers we are all looking for and decided to go straight to the source.  Don't get me wrong, I learned a vast amount by going through that process.  Having determined that I wasn't going to find everything needed to refute these claims for free online, I decided to buy ARINC Specifications 618-5 and 620-4, which were the relevant specifications in place circa September 11, 2001.  They have a ton of valuable information in them which answer many of the questions we've all been arguing over for the past several weeks.

To definitively put this argument to rest I'll be quoting from both specifications and referring back to other documentation which has been provided previously.  I'll not be providing the full ARINC documents for copyright reasons, but as you can see below I have taken screen shots of relevant pages and quoted specific relevant sections to directly address the issues that have been raised by P4T, BUBS, and others both here and in other forums. Anyone interested in purchasing the documents for themselves is more than welcome to do so and I'll provide links to where I bought them from at the end of this post series.  I'd also be happy to answer specific questions and provide relevant sources links from these documents if needed when and if I have time later.

The short version of this is that Balsamo and crew are completely wrong in their assertions that the ACARS messages in the Team7_Box13_UAL_ACARS.pdf indicate that UA175 and UA93 were in the air after the reported crash times.  With the documentation from ARINC Specifications 618-5 and 620-4, combined with the recently linked 5 AWA 898 Printout of ARINC messages.pdf from Warren Stutt the answers are conclusive, incontrovertible, and beyond further debate.

The documents in question prove without any doubt whatsoever that UA175 and UA93 DID NOT receive any uplink messages after their reported crash times.

This series of posts should definitively demonstrate the following points:

• The RGS locations referenced in Team7_Box13_UAL_ACARS.pdf were supplied by the airline and do NOT indicate which station was actually used by the DSP (ARINC) to deliver, or attempt to deliver, the uplink message.
• The actual RGS used for uplink attempts by the DSP (ARINC) can be the same RGS as predicted by the airline, but it often isn't the same.
• Messages from the Team7_Box13_UAL_ACARS.pdf with a secondary time stamp can be confirmed as NOT being delivered to the aircraft by analyzing Warren Stutt's 5 AWA 898 Printout of ARINC messages.pdf, which definitively proves that the secondary time stamp indicates something else entirely.

If anyone can point out problems with the interpretations and explanations below, feel free.

This first post will deal with the first bullet point, as it seems to be the prevailing opinion of many that the RGS listed in these FOIA pages were the actual stations used; but they in fact do NOT indicate this.

The RGS locations referenced in Team7_Box13_UAL_ACARS.pdf were supplied by the airline and do NOT indicate which station was actually used by the DSP (ARINC) to deliver, or attempt to deliver, the uplink message.  To illustrate this, consider one of the final messages which was sent from Ed Ballinger on dispatch for delivery to UA93 at 10:10 Eastern time:

DDLXCXA CHIAK CHI68R
.CHIAKUA 111410/ED
CMD
AN N591UA/GL CMI
- QUCHIAKUA 1UA93 EWRSFO
- MESSAGE FROM CHIDD -
DO NOT DIVERT TO DC  AREA
CHIDD  ED BALLINGER

;09111410 108575 0706

The 4th line contains two elements provided within the message text itself by the airline.  These are referred to as TEIs, or Text Element Identifiers.  The first is defined as the Aircraft Number (AN) and the second as the Ground Station (GL).  I refer to Table 3.2.3-1 on page 16 (Page 24 in the PDF) of ARINC 620-4 for these definitions:




The significance of the GL element is described above the table on the same page which discusses uplink conversion and processing functions.  In particular, notice conditions c and d as follows:

c. The SMT contains either an Aircraft Registration Number (AN) text element or a Flight Identifier (FI) text element and the corresponding text element is valid. Refer to Appendix B2. If the DSP does not have tracking information for the aircraft addressed, the following supplementary condition applies:

d. If the SMT contains either a GL text element (approximate geographic location of aircraft) or an AP text element (airport location of aircraft) and that text element identifies an airport or city known to the DSP, the DSP uses this information to determine the ground station for transmission to the aircraft.

See the full page here:

Pg16(Pg24inPDF)-UplinkMessageHandling_cropped.jpg

This significance is further described on page 17 (Page 25 in the PDF) as follows:

The DSP records the flight identifier for each aircraft from the aircraft's downlink messages. If the TEI FI is used subsequently in addressing an uplink message, the message is sent to the aircraft with the AN or FI address depending on the input TEI. If the DSP cannot perform this conversion but the user has included GL or AP TEIs, the uplink ACARS message will be sent through the station specified with the flight identifier in the address field.

And again further on page 18 (Page 26 in the PDF) here:

For an uplink message that requires delivery to an aircraft not active in the system, DSPs start with the Geographic Locator (GL) or Airport Locator (AP) specified by the ground user (airline or other host computer). Delivery through each possible locator is attempted a configurable number of times.

There are other mentions as well, but these should suffice.  You can see this /GL RGS element with every message sent for uplink in that FOIA document and the significance of this text element is the same for each.

Conclusion:

It is undeniable that the RGS locations referenced in the messages from the Team7_Box13_UAL_ACARS.pdf were supplied by the airline and included in the original message as it was sent from dispatch to the DSP.  This means that it is NOT an indication of the actual RGS used for uplink attempts but is rather a prediction by the airline for where it expects the aircraft to be and is only used if the DSP doesn't already have routing information available in its tables.  Where do you suppose this is derived from?  Original flight plan anyone?

This in itself is sufficient to debunk the claims of P4T, but I'll add to this with more posts to further clarify the remaining two bullet points and possibly address other issues.

I'd like to give credit where credit is due.  Cz has provided a ton of information all along which has supported this conclusion.  I see this documentation from ARINC as merely the final validation for much of his hard work.  In addition, I'd like to thank Warren Stutt for providing the information that he has given over on the P4T forum.  I'll be making use of it to follow up with the remaining points and possibly other points of clarification.

I look forward to the hand waiving and non-definitive responses that Balsamo and crew are sure to respond with.  Or perhaps one or two of them will surprise me and acknowledge their error.  Will Balsamo do the right thing and remove the proven misinformation from his web site?  Time will tell, but I'm not holding my breath.

Cheers.

Outstanding, BooN!! My hat off to you!

Your post explains it well and I agree that it is time for P4T, to remove all of the misinformation from its website, but it is anyone's guess when that will happen.

[booNyzarC]

Thanks Skyeagle, much appreciated.

booNyzarC, on 15 December 2011 - 10:54 PM, said:

I'd like to give credit where credit is due.  Cz has provided a ton of information all along which has supported this conclusion.  I see this documentation from ARINC as merely the final validation for much of his hard work.

As I'm working on the post for the second bullet point I realize that I haven't really done justice with the above credit given to Cz. I just want to reiterate and more adequately emphasize the credit due to Cz, not only in the documentation that he has diligently reviewed and shared publicly over the last few weeks, but also in our PM discussions throughout the development of our hypothesis the whole way through.  I have inadvertently meshed some of his points with my own in my posts today, which could leave people with the false impression that today's posts are the fruit of my labor alone.  Well, they aren't.  This whole process has been collaborative from the first moment I stepped into this ACARS subject and we've bounced ideas off of each other both publicly in posts and privately in PMs.

These points which disprove Balsamo and crew are as much Cz's as they are mine.  I'll try to be more diligent in pointing out Cz's contributions with my future posts.  As much as I'd like to take credit for his brilliance, I don't want to leave the impression with anyone that this is all my doing when it truly isn't.

Cheers

[quillius]

booNyzarC, on 16 December 2011 - 12:31 AM, said:

Thanks mate.  I attribute a combination of things to my desire for addressing this issue, but the biggest contributor was ValkyrieWings AKA Rob Balsamo himself; for reasons which should be obvious to anyone who has observed his behavior toward myself and many others for any amount of time.  What can I say?  The guy begs to be put in his place.

The Standards weren't exactly cheap, but they were worth every penny just for this.  It is like an early Christmas gift to myself, if you will.

Hey Boon, very good. Always fascinating to watch people go through the gears when needed.

Game on.

(ps. claim on expenses   )

[booNyzarC]

quillius, on 16 December 2011 - 10:29 AM, said:

Hey Boon, very good. Always fascinating to watch people go through the gears when needed.

Game on.

(ps. claim on expenses   )

Thanks quillius.  

[booNyzarC]

Part 2 of this post series will address the second bullet point from my first post.

• The actual RGS used for uplink attempts by the DSP (ARINC) can be the same RGS as predicted by the airline, but it often isn't the same.

This will require a bit of a rehashing from information that Warren Stutt has already described over on the P4T forum, but I'll add a little more detail to help clarify his fine work with more documentation from ARINC Specifications 618-5 and 620-4.

For the sake of illustration, I'll use the last message that was acknowledged as received for United Airlines Flight 93.

From pages 127 and 128 of 5 AWA 898 Printout of ARINC messages.pdf, in agreeance with page 4 of t-0148-911MFR-01098.pdf, we see that the last downlink acknowledgment from UA93 was from message #17 noted in the Knerr/Winter interview on page 57 of Team7_Box11_FBI302s_ACARS.pdf.  This acknowledgement is listed in MFR-01098 with a time stamp of 1351:58 Zulu, or 9:51:58 Eastern.

From the Team7_Box11_FBI302s_ACARS.pdf Winter states:

Messages #16 and #17 were sent to the aircraft from CHIDD using the RGS near Ft. Wayne, IN, FWA as designated in the line "AN N591UA/GL FWA...". The messages were sent to the ACARS printer.

This is the message as formatted on page 48 in the Team7_Box13_UAL_ACARS.pdf:

DDLXCXA CHIAK CHI68R
.CHIAKUA 111351/ED
AGM
AN N591UA/GL FWA
- UA93 EWRSFO
- MESSAGE FROM CHIDD -
LAND ASP AT NEAREST --NEAREST AIRPORT.ASP .ASP ON GROND.ANYWERE.
CHIDD  ED BALLINGER

;09111351 108575 0676

And this is how it was formatted on page 127 in Warren's PDF:

FLoc=352538978 AJPSBcnt= 273  ULMSG S=31 D=21  BEPts=20010911 13:51:53
ADNS MsgLen= 216  Org Addr= CHIAKUA  Org TimeStamp= 20010911 13:51:00
Smi= AGM  AgyNum= 65535
Tail Number= .N591UA  FltID= UA0093
Target Stn= FWA<00><00> Target Method= 2
<CR><LF>
<SOH>QU DDLXCXA<CR><LF>
.CHIAKUA 111351/ED <CR><LF>
<STX>AGM<CR><LF>
AN N591UA/GL FWA<CR><LF>
- UA93 EWRSFO<CR><LF>
- MESSAGE FROM CHIDD -<CR><LF>
LAND ASP AT NEAREST --NEAREST AIRPORT.ASP .ASP ON GROND.ANYWER<TSTRET>
E.<CR><LF>
<CR><LF>
CHIDD ED BALLINGER            <CR><LF>
<ETX><EOT>

The more astute of readers might make note of the sending time stamps for the above message is indicated as BEPts 13:51:53 and Org TimeStamp 13:51:00.  Some might think that this message doesn't match with the previously mentioned 1351:58 Zulu from the MFR-01098, but keep in mind that the MFR is talking about the downlink message as depicted a little later in this post, not the uplink message as is depicted above.

We can see that the predicted RGS sent by the GL text element as provided by the airline was the RGS station in Fort Wayne Indiana; FWA.  This is wholly consistent with the original flight plan for United 93 and where the aircraft would have been at around 9:51 Eastern if it had not been hijacked.  The ULBLK which follows this entry didn't route through FWA, however. Instead, it routed to the aircraft through PIT based on the DSP's dynamically updated routing table as we can see in the ULBLK message below it.

FLoc=352565664  AJPSBcnt= 254  ULBLK S=31 D=21  BEPts=20010911 13:51:56
UL MsgLen= 213 Stn= PITC6 StnDelivType= 1
Tail= .N591UA Fid= UA0093
<SOH>2.N591UA<NAK>C1A<STX>.CHIAKUA 111351/ED <CR><LF>
AGM<CR><LF>
AN N591UA/GL FWA<CR><LF>
- UA93 EWRSFO<CR><LF>
- MESSAGE FROM CHIDD -<CR><LF>
LAND ASP AT NEAREST --NEAREST AIRPORT.ASP .ASP ON GROND.ANYWER<TSTRET>
E.<CR><LF>
<CR><LF>
CHIDD ED BALLINGER            <CR><LF>
<ETX>

Below that we can see the acknowledgment message from the aircraft was received by not just one, but multiple RGS locations. And the first acknowledgement, as corroborated by the MFR-01098 PDF has a time stamp of 1351:58 Zulu.



and





Reviewing all of the other successfully uplinked messages in the same PDF we can see that this is consistent.  This is an indication that the aircraft was operating in a Category A network.  If it were a Category B network, only one RGS should receive the message.  There are other indications as well, but I'll get into that later in a supplemental post; unless Cz points it out before me.

Now, Balsamo has claimed that the RGS stations referenced in the DLBLKs in this document from Warren aren't actually front end RGS stations.  He claims that because the RGS identifiers are followed by suffixes they are Back End Processing routers.  He even cites his very own self-proclaimed ACARS expert (one Dennis Cimino) to corroborate this claim.  My initial questions to Balsamo and Cimino would be:

• If BepStnName stands for Back End Processing router Station Name, as your claim seems to suggest, what does BEPts stand for in the message headers for each message in that PDF?  Does it stand for Back End Processing router Time Stamp?  Don't get me wrong, I do think there is a Back End involved with this claim, but I don't think it is the kind that Balsamo is suggesting...
  
• If a suffixed RGS station, like PITC6 for example, is not an actual front end RGS station, why does line two of the above referenced ULBLK message specifically indicate that Stn= PITC6 had a StnDelivType= 1?  It doesn't refer to it as BepStnName, it refers to it as simply Stn, and it follows by what is obviously depicting a Station Delivery Type of 1.  If this station didn't uplink the message, which station did?  It certainly wasn't FWA because we have already established that /GL FWA is merely the predicted station as provided by the airline when the message was originally sent from United's dispatch and is not directly related to the actual RGS used for uplink unless very specific conditions apply; which they did not at this point by your own admission.

Perhaps one of his cronies can deliver some answers to these questions, but I don't suggest than anyone hold their breath.

In the mean time I think that Cz has offered a much more reasonable and plausible possible explanation for this suffix in a PM and I'll quote him here:

Czero 101, on 15 December 2011 - 02:40 AM, said:

Also, regarding Balsamo stating that "PITC6" isn't the PIT RGS:

I did some time on a jury for a murder a few years back and one aspect of the case had us being informed by an expert on certain aspects of how Cell Towers work.

One of the things we learned is that the towers almost always have multiple transceivers to allow for complete and overlapping 360 degree coverage. Info showing which tower and which specific transceiver handled a call was presented to us so as to show how the accused's movements were tracked by the Telco and the Police.

My first thought on seeing "Stn=PITC6" was that it was indicating the specific transceiver on the PIT RGS that was used to either transmit or receive the message. Most likely it refers to the receiving transceiver, imo...

This possible explanation makes perfect sense to me.  Is it definitive and irrefutably sourced by ARINC documentation?  Not so far as I've found, but it certainly makes a lot more sense than Balsamo and crew's interpretation.

As an added note, this PM also included Cz's suspicion that the SSV indication in those DLBLK messages most likely represent some kind of signal strength verification which is used by the DSP for prioritizing in its routing table.  I concur that this is highly likely, though I haven't found specific documentation which details the meaning of this acronym either.  The interpretation does appear to match when you review the prior DLBLK messages with the highest SSV value and the subsequent uplink routing decisions throughout the PDF.  I haven't reviewed every instance, but each one I've looked at has matched this expectation and it lends significant credibility to this interpretation in my opinion.  I briefly mentioned this signal strength in my prior post to Q24 but I didn't properly credit Cz for the idea, so I will now.  And yes, he has given me permission to quote from our PMs about this subject for any who are wondering.

You may not have noticed, but I've been a bit side tracked in the previous paragraphs.  I'll get back to the bullet point in question, which is that the actual RGS used for uplink attempts by the DSP (ARINC) can be the same RGS as predicted by the airline, but it often isn't the same.  I've illustrated one example above with Ballinger's message 0676, let's briefly look at a few more from Warren's PDF.


Regarding American Airlines Flight 11:

Pages 52 and 53 show that the predicted GL RGS was ALB, but that the actual ULBLK RGS utilized was LGA.

Pages 54, 55, 56, 57, and 58 show that the predicted GL RGS was BUF, but that the actual ULBLK RGS utilized was also LGA.

Also notice that there are no DLBLK messages after the reported crash time for AA11 of 8:46:30.  Pages 59 to 65 give us summaries of all attempted uplinks after that time with a Reason Code for failure of 311.  This Reason Code is documented in ARINC 620-4 as No ACK (No response from aircraft) on page 145 (page 153 of the PDF) in table 2-3 from Attachment 2:



If you fully review this PDF supplied by Warren you'll find that this Reason Code is listed for most of the messages addressed to each aircraft included in the PDF after the reported crash times.  I suppose that might be because they had crashed...


Regarding United Airlines Flight 93, whose messages begin on page 66:

The first divergence between the predicted RGS and actual ULBLK delivery RGS comes after the last crew initiated downlink at 13:26:10 on page 103, when they requested - /C4 EWRSFO ED COFIRM LATEST MSG PLZ

The uplink divergences from here are hard to follow, but I'll briefly list them.

Page 108 shows that the predicted GL RGS was CAK, but page 109 shows that the actual ULBLK RGS utilized for uplink at 13:32:02 was PIT.

This trend continues on pages 109, 110, 111, 112, 114, 115, and 117 which show all ULBLK messages as being routed through PIT.

Pages 118, 119, 120, 121 show ULMSGs predicted to route through CLE but that were actually routed through PIT with the ULBLKs.

Pages 123, 124, and 125 show ULMSGs predicted to route through TOL but that were actually routed through PIT.

Page 126 introduces the first prediction of FWA, and the actual routing utilized was through PIT, and we come full circle on page 127 with the originally referenced example that I described earlier in the post; the final acknowledged message from UA93.

Attempted uplinks continue through page 136 and the failed Reason Codes mentioned before likewise continue through page 133: 311 No ACK (No response from aircraft).  Pages 134 through 136 give Reason Code 231 No Station To (No tracking available and neither GL nor AP appear).


Regarding American Airlines Flight 77, whose messages begin on page 137:

As with the other flights, the divergence between the predicted GL RGS provided by the airline's text elements begins after the aircraft was hijacked.  The first divergence I noted in Warren's PDF was on page 191; the predicted RGS was CRW, but the actual ULBLK RGS was HTS at 12:59:45.

Then on pages 194, 195, 196, 197, and 199 we see several instances where the predicted RGS was CVG and the actual was HTS.


In light of the above information, perhaps I slightly mis-worded that second bullet point.  It should probably actually read:

• The actual RGS used for uplink attempts by the DSP (ARINC) can be the same RGS as predicted by the airline, but it often isn't the same in the event that the target aircraft has been hijacked and diverted from its original course with the intention of crashing into a building.

At any rate, I think this point has been well established and you might notice that I partially covered the third bullet point as well.  In the next post I'll finish up the third bullet and perhaps add some more references to help clarify other points and ACARS as a whole.

Cheers


Edit: Typo

Edited by booNyzarC, 16 December 2011 - 04:42 PM.

[skyeagle409]

booNyzarC, on 15 December 2011 - 10:54 PM, said:

I look forward to the hand waiving and non-definitive responses that Balsamo and crew are sure to respond with.  Or perhaps one or two of them will surprise me and acknowledge their error.  Will Balsamo do the right thing and remove the proven misinformation from his web site?  Time will tell, but I'm not holding my breath.

Cheers.

I hope Balsamo does, because he is handing out bad information, which is leading people down a dead-end street, but I am not hold my breath either.

[skyeagle409]

booNyzarC, on 16 December 2011 - 04:30 PM, said:

Great job, BooN!

The P4T website is a joke, and your references have proved that beyond any doubt, but I need to add Woody Box as well.

[Czero 101]

I've had a busy few days and haven't had time to post in here, so thanks to BooNy for picking up my slack.

I've got a little time before I have to head out again today, so I thought I'd address the Category A vs. Category B kerfuffle...

We've been over it many times, and the definitions of a Category A and Category B ACARS message have been trotted out a few times for all of us to see.

Last week, BooNy presented information in his post 1661 showing us that, at the time, ARINC used Category A message, while SITA used Category B:

booNyzarC, on 10 December 2011 - 12:57 AM, said:

For this hypothesis to be possible it requires that UA175 was relying on a Category A network and not a Category B network.  Some may recall the claim that Commercial Airlines use Category B protocol by Valkyrie in post 1103, but he has offered absolutely zero evidence to support this claim.  Among the many documents I've looked through over the last couple of weeks, I've found the following which I think might suggest otherwise...

From page 60 of Air Traffic Services Systems Requirements and Objectives - Generation 4:

7.3.2.3.4 CATEGORIES OF OPERATION

There are two categories of operation for VHF ACARS: Category A, used by ARINC and Category B used by SITA.

I haven't seen any references to SITA in the FOIA documents, so I'm fairly certain that the investigation only involved the airlines and ARINC.  I'd have to go back and review more to be certain, but I'm also pretty sure that the bulk of SITA's expansion into the US was well after 2001.  If this entry from the PDF is accurate, that pretty much rules out the possibility that UA175 was relying on a Category B protocol.  The approval date for this document is July of 2001, so even if ARINC has adopted Category B protocols since then, we can tell that they hadn't done so by less than two months prior to September when this event took place.  The same information can be found on page 58 of this document, but it is dated in May of 2000.

That information alone should be enough to quash Valyrie / Balsamo's "the UA Aircraft were using Category B messages" idea which needs to be the case for their theory to be true. Well, that's probably not ALL that needs to be true, but it is part of it.

The ARINC 618 Specification clearly describes the differences between Category A and B messages. Not only does it describe the difference, it shows you how to differentiate between them when looking at the "message source" (for lack of a better term) such as what has been provided for UA93 by Warren.

From the ARINC 618, page 34 (pdf page 46):



The section highlighted above says several interesting things. First off:

CATEGORY A - Aircraft may broadcast the message
to all DSP ground stations in the aircraft’s VHF
coverage area. Message delivery of this type is
denoted by a “2” character in the mode character of the
downlink message (see Section 2.3.2.1).

This passage has two very salient points in it, the first one being that an aircraft broadcasting Category A messages will broadcast to all RGS locations within the VHF radio's range. Typically, this is 200NM, but its not like once 200NM is reached, the signal reaches a brick wall and just stops dead in the air. The signal will continue propagate outward from the aircraft until it is too weak to be received. While the likelihood of success drops the farther outside the 200NM range an RGS is, it is still possible that an RGS outside the 200NM could in fact receive a VHF ACARS transmission. Balsamo would have you believe that this is not possible, that the YYZ (Toronto Pearson Int'l Airport), DTW (Detroit - Wayne County) or IAD (Washington - Dulles) RGS locations are simply too far away for it to have received a message from the aircraft.

In reality, they are not too far, if UA93 was in fact not flying on its original flight route, but rather had been turned back east by the hijackers.

YYZ is within 200NM of the PIT, CLE and CAK RGS locations and the location of UA93's crash just outside of Shanksville, PA, and YYZ is just on the edge of the 200NM "limit" of the TOL and CMH RGS locations.

Balsamo wants you to believe that its not possible for YYZ to have received a message from UA93 because that fact starts to erode the "UA93 - or the plane that replaced it - was flying west and the messages were actually sent from TOL, FWA and CMI RGS location" theory.

In reality, UA93 was using the PIT RGS as is shown in the ACARS log Warren has provided. DTW and IAD are also within the 200NM "limit" of where the aircraft actually was - heading east towards Washington or New York.

Amyway... moving on...

Section 2.3.2.1 referenced above says the following:

2.3.2.1. Category A Mode Character

All Category A uplinks are uniquely idetified with a "2"
(3/2) in the Mode Character position.

Page 114 (pdf page 126) gives us a definition of the first line in an ACARS message and indicated where the Mode Character position is:



And page 134 (pdf page 146) gives a graphical representation of the Mode Character position:

On page 135 (pdf page 147) there is the following summary (no screen shot at the moment):

Typically, the first 23 characters of the message preamble are known as the Pre-Key and each character is represented by seven bits of logic ‘ones’. These characters allow the receiver automatic gain control and transmitter power to stabilize. The next two characters (bit ambiguity) enable the receiver to determine that the process of identiQing character bits is operating correctly. The two-character synchronization (SYN) bits allow the message processor to establish character synchronization. Following the SYN characters is the start of heading (SOH) character which indicates the beginning of the message block. The Mode character which follows the SOH is transmitted to indicate the category of operation. ACARS supports two categoriesof operation, CAT A and CAT B. CAT A operation is identified by a Mode character of ‘2’. The seven-character address field identifies the destination of the message. In an uplink message, the address is the airplane registration or the flight number.

If we refer back to Warren's screen cap:



we can see the following line in the formatted uplink message:

<SOH>2.N591UA<NAK>C1W<STX>.CHIAKUA 111350/ED <CR><LF>

This categorically proves that the message being sent between the UA Ops centre and UA93 were Category A messages, and the fact that several RGS locations show receipt of the DLBLK is completely expected.

As BooNy also stated I believe that the "SSV=" is a reference to the signal strength. We consistently see that the PIT location has the highest value in this field, while RGS location farther away - such as YYZ, DTW, IAW, etc. - consistently show lower values. These values could also be used (by someone a bit more familiar with the procedure than I) to triangulate the aircraft's position at the time the messages were received by the listed RGS location, and I believe that would place UA93 in the vicinity of the PIT RGS, and on its way to its resting place near Shanksville.




Cz

[booNyzarC]

Great clarifications Cz, and much easier to read/understand than my efforts!

I'll look it over in more detail and see if I have anything to add.  Edit:  For anyone looking for the missing image in Cz's post, here is the referenced page:

Czero 101, on 16 December 2011 - 09:47 PM, said:

--
And page 134 (pdf page 146) gives a graphical representation of the Mode Character position:

It isn't as pretty as Cz's, but oh well...  (/edit)



Meanwhile, I wanted to comment a bit regarding part of my earlier post from today:

booNyzarC, on 16 December 2011 - 04:30 PM, said:

• If BepStnName stands for Back End Processing router Station Name, as your claim seems to suggest, what does BEPts stand for in the message headers for each message in that PDF?  Does it stand for Back End Processing router Time Stamp?  Don't get me wrong, I do think there is a Back End involved with this claim, but I don't think it is the kind that Balsamo is suggesting...
  
• If a suffixed RGS station, like PITC6 for example, is not an actual front end RGS station, why does line two of the above referenced ULBLK message specifically indicate that Stn= PITC6 had a StnDelivType= 1? It doesn't refer to it as BepStnName, it refers to it as simply Stn, and it follows by what is obviously depicting a Station Delivery Type of 1. If this station didn't uplink the message, which station did? It certainly wasn't FWA because we have already established that /GL FWA is merely the predicted station as provided by the airline when the message was originally sent from United's dispatch and is not directly related to the actual RGS used for uplink unless very specific conditions apply; which they did not at this point by your own admission.

I just want to add a little clarification here.  BEP technically does stand for Back-End Processor, but this does not necessarily translate into the meaning and implication that Balsamo has suggested; that it is dissociated from the actual RGS.

Also, as Warren Stutt has pointed out elsewhere, the BepStnName, Stn, and Target Stn fields used for ULBLK and DLBLK messages each consist of 5 characters, not 3.  Even in instances where only 3 characters are actually used, the field size is still 5 and the two unused characters are filled with null values of <00><00>.

Edited by booNyzarC, 16 December 2011 - 10:20 PM.

[booNyzarC]

Czero 101, on 16 December 2011 - 09:47 PM, said:

From the ARINC 618, page 34 (pdf page 46):

http://www.digitalaf...m/618pg46_1.jpg

The section highlighted above says several interesting things. First off:

CATEGORY A - Aircraft may broadcast the message
to all DSP ground stations in the aircraft’s VHF
coverage area. Message delivery of this type is
denoted by a “2” character in the mode character of the
downlink message (see Section 2.3.2.1).

This passage has two very salient points in it, the first one being that an aircraft broadcasting Category A messages will broadcast to all RGS locations within the VHF radio's range. Typically, this is 200NM, but its not like once 200NM is reached, the signal reaches a brick wall and just stops dead in the air. The signal will continue propagate outward from the aircraft until it is too weak to be received. While the likelihood of success drops the farther outside the 200NM range an RGS is, it is still possible that an RGS outside the 200NM could in fact receive a VHF ACARS transmission. Balsamo would have you believe that this is not possible, that the YYZ (Toronto Pearson Int'l Airport), DTW (Detroit - Wayne County) or IAD (Washington - Dulles) RGS locations are simply too far away for it to have received a message from the aircraft.

In reality, they are not too far, if UA93 was in fact not flying on its original flight route, but rather had been turned back east by the hijackers.

YYZ is within 200NM of the PIT, CLE and CAK RGS locations and the location of UA93's crash just outside of Shanksville, PA, and YYZ is just on the edge of the 200NM "limit" of the TOL and CMH RGS locations.

Balsamo wants you to believe that its not possible for YYZ to have received a message from UA93 because that fact starts to erode the "UA93 - or the plane that replaced it - was flying west and the messages were actually sent from TOL, FWA and CMI RGS location" theory.

In reality, UA93 was using the PIT RGS as is shown in the ACARS log Warren has provided. DTW and IAD are also within the 200NM "limit" of where the aircraft actually was - heading east towards Washington or New York.

I do have one addition for this portion of Cz's post regarding the 200NM "limit" which sprang to mind as soon as I read through it more fully.  Somewhere along the way these last couple of weeks I found the following reference which illustrates that the 200NM isn't a hard stop just as you are describing Cz.  In fact, it extends this range to about 250NM at an altitude of 30,000 feet.

Quote

The propagation characteristics of the VHF band restrict transmission
and reception to essentially line-of-sight conditions. The maximum line of-
sight range for an enroute aircraft at an altitude of 30,000 feet is about
250 nautical miles. The radio range decreases at lower altitudes to a
strictly localized coverage when the aircraft is on the ground.

Source (page 48)

Cheers

[skyeagle409]

To sum it all up;

The 'Pilots for 9/11 Truth,' website has now crashed and burned!!!.