IPBFacebook




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 )

24 Pages V  « < 19 20 21 22 23 > »   
Reply to this topicStart new topic
9/11: Pentagon Aircraft Hijack Impossible, FLIGHT DECK DOOR CLOSED FOR ENTIRE FLIGHT

Rating 5 V
 
SerialThrilla
post Dec 9 2009, 05:05 AM
Post #401





Group: Newbie
Posts: 8
Joined: 7-December 09
Member No.: 4,771



I may get the endianness wrong so please correct me if this is wrong.

For the day 9/11, it should come out to (as recorded MSBF):

Word 256, Parent Frame 5, Sub Frame 4
Raw: 0001101010010
Grouped: (000) (1101) (0) (1001) (0)
Fields: (day_x10) (day_x_1) (month_x10) (month_x1) (pad zero)
Go to the top of the page
 
+Quote Post
SerialThrilla
post Dec 9 2009, 05:14 AM
Post #402





Group: Newbie
Posts: 8
Joined: 7-December 09
Member No.: 4,771



Warren,

I have a question with the data formats:

A/C TYPE LSB

D226A101-3G.pdf
Word 256
SUBF 4
SUPF 1

757-3b_1.txt
Frame(s) ALL
Subframe(s) 4
Word 256

Any idea why 757-3b_1.txt has Frame(s) listed as ALL when D226A101-3G.pdf has it listed only for Frame 1?
It appears that data that is in every super frame is given a blank value for the SUPF, such as GMT_SEC (GMT SECONDS).
Does this negatively affect your decoder and possibly why the timestamps are whacky?

Thanks
Go to the top of the page
 
+Quote Post
rob balsamo
post Dec 9 2009, 06:55 AM
Post #403



Group Icon

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



Hi Serial,

Welcome to the forum.

757-3b_1.txt is a custom data frame layout provided by American Airlines which is a modified version of 757-3b found in D226A101-3G.pdf.

757-3b is a generic Boeing Data Frame layout. American Airlines then modified the generic data frame layout to their specific needs of their fleet and operating procedures.

We are looking into this issue. If you find anything you feel needs mentioning, let us know.

Once again, welcome to the forum!
Go to the top of the page
 
+Quote Post
wstutt
post Dec 9 2009, 08:27 AM
Post #404





Group: Troll
Posts: 255
Joined: 27-December 07
From: Brisbane, Australia
Member No.: 2,603



Hi SerialThrilla,

QUOTE (SerialThrilla @ Dec 14 2009, 07:27 AM) *
Thanks Warren. You're right, those dont make sense. I'm curious how you computed 25 for the month?
It appears: (dec. month_x_1) + (dec. month_x10 * 10) = month

<snip>
Your formula for calculating the month is correct. The recorded values for dec. month_x_1 and dec. month_x10 are 15 and 1 respectively.

Warren.
Go to the top of the page
 
+Quote Post
wstutt
post Dec 9 2009, 08:39 AM
Post #405





Group: Troll
Posts: 255
Joined: 27-December 07
From: Brisbane, Australia
Member No.: 2,603



QUOTE (SerialThrilla @ Dec 14 2009, 11:05 AM) *
I may get the endianness wrong so please correct me if this is wrong.

For the day 9/11, it should come out to (as recorded MSBF):

Word 256, Parent Frame 5, Sub Frame 4
Raw: 0001101010010
Grouped: (000) (1101) (0) (1001) (0)
Fields: (day_x10) (day_x_1) (month_x10) (month_x1) (pad zero)
That's close SerialThrilla. It should be :

Raw: 010001010010
Grouped: (01)(0001)(0)(1001)(0)
Fields: (day_x10) (day_x_1) (month_x10) (month_x1) (pad zero)

Warren.
Go to the top of the page
 
+Quote Post
SerialThrilla
post Dec 9 2009, 01:47 PM
Post #406





Group: Newbie
Posts: 8
Joined: 7-December 09
Member No.: 4,771



QUOTE (rob balsamo @ Dec 9 2009, 07:55 AM) *
757-3b_1.txt is a custom data frame layout provided by American Airlines which is a modified version of 757-3b found in D226A101-3G.pdf.

757-3b is a generic Boeing Data Frame layout. American Airlines then modified the generic data frame layout to their specific needs of their fleet and operating procedures.

Ah. Thanks Rob.

QUOTE (wstutt @ Dec 9 2009, 09:27 AM) *
Your formula for calculating the month is correct. The recorded values for dec. month_x_1 and dec. month_x10 are 15 and 1 respectively.

haha wow a value of 15 isn't even close, and the month shouldn't even be a 1. Thanks Warren!

QUOTE (wstutt @ Dec 9 2009, 09:39 AM) *
Raw: 010001010010
Grouped: (01)(0001)(0)(1001)(0)
Fields: (day_x10) (day_x_1) (month_x10) (month_x1) (pad zero)

Yup, my mistake. good eye. Warren knows what he's doing.

I'm going to guess that the date and time are entered by the crew as part of the startup/prep list. For such way off values there's a few possibilities:
  1. Crew/government never entered the correct the date
  2. The date/time was broken
  3. This frame or subframe has a different compression tree
  4. The flyover pilot was leaving us a secret message (my favorite)

Let's see what we get when Warren outputs the raw labeled data frames.
Go to the top of the page
 
+Quote Post
painter
post Dec 9 2009, 03:46 PM
Post #407


∞* M E R C U R I A L *∞


Group: Respected Member
Posts: 5,870
Joined: 25-August 06
From: SFO
Member No.: 16



QUOTE (SerialThrilla @ Dec 9 2009, 10:47 AM) *
  1. The flyover pilot was leaving us a secret message (my favorite)

That would be sweet. Then we could spend the next 3 years trying to decode it and the next five arguing with our detractors (when not among ourselves) about what it means. whistle.gif
Go to the top of the page
 
+Quote Post
Jefferson
post Dec 9 2009, 04:38 PM
Post #408





Group: Student Forum Pilot
Posts: 41
Joined: 16-October 06
Member No.: 88



QUOTE (SerialThrilla @ Dec 9 2009, 10:05 AM) *
I may get the endianness wrong so please correct me if this is wrong.

For the day 9/11, it should come out to (as recorded MSBF):

Word 256, Parent Frame 5, Sub Frame 4
Raw: 0001101010010
Grouped: (000) (1101) (0) (1001) (0)
Fields: (day_x10) (day_x_1) (month_x10) (month_x1) (pad zero)


Why 13 bits?
Go to the top of the page
 
+Quote Post
SerialThrilla
post Dec 9 2009, 04:55 PM
Post #409





Group: Newbie
Posts: 8
Joined: 7-December 09
Member No.: 4,771



QUOTE (Jefferson @ Dec 9 2009, 05:38 PM) *
Why 13 bits?

haha because it was two hours past my bedtime whistle.gif
Sorry for the confusion. Warren's correction is the correct one.
Go to the top of the page
 
+Quote Post
Jupiter
post Dec 9 2009, 05:08 PM
Post #410





Group: Student Forum Pilot
Posts: 36
Joined: 28-November 09
Member No.: 4,705



Raw: 010001010010
Grouped: (01)(0001)(0)(1001)(0)
Fields: (day_x10) (day_x_1) (month_x10) (month_x1) (pad zero)

I'm going to guess that the date and time are entered by the crew as part of the startup/prep list. For such way off values there's a few possibilities:
Crew/government never entered the correct the date
The date/time was broken
This frame or subframe has a different compression tree
The flyover pilot was leaving us a secret message (my favorite)


What's the new thing ? Is there any problem with the date ?
Go to the top of the page
 
+Quote Post
localbod
post Dec 9 2009, 06:44 PM
Post #411





Group: Student Forum Pilot
Posts: 37
Joined: 12-January 07
From: UK
Member No.: 433



QUOTE (rob balsamo @ Nov 25 2009, 02:55 PM) *
9/11: PENTAGON AIRCRAFT HIJACK IMPOSSIBLE
FLIGHT DECK DOOR CLOSED FOR ENTIRE FLIGHT

(PilotsFor911Truth.org) - Newly decoded data provided by an independent researcher and computer programmer from Australia exposes alarming evidence that the reported hijacking aboard American Airlines Flight 77 was impossible to have existed. A data parameter labeled "FLT DECK DOOR", cross checks with previously decoded data obtained by Pilots For 9/11 Truth from the National Transportation Safety Board (NTSB) through the Freedom Of Information Act.

On the morning of September 11, 2001, American Airlines Flight 77 departed Dulles International Airport bound for Los Angeles at 8:20 am Eastern Time. According to reports and data, a hijacking took place between 08:50:54 and 08:54:11[1] in which the hijackers allegedly crashed the aircraft into the Pentagon at 09:37:45. Reported by CNN, according to Ted Olson, wife Barbara Olson had called him from the reported flight stating, "...all passengers and flight personnel, including the pilots, were herded to the back of the plane by armed hijackers..."[2]. However, according to Flight Data provided by the NTSB, the Flight Deck Door was never opened in flight. How were the hijackers able to gain access to the cockpit, remove the pilots, and navigate the aircraft to the Pentagon if the Flight Deck Door remained closed?[3]

Founded in August 2006, Pilots For 9/11 Truth is a growing organization of aviation professionals from around the globe. The organization has analyzed Data provided by the National Transportation Safety Board (NTSB) for the Pentagon Attack, the events in Shanksville, PA and the World Trade Center attack. The data does not support the government story. The NTSB/FBI refuse to comment. Pilots For 9/11 Truth do not offer theory or point blame at this point in time. However, there is a growing mountain of conflicting information and data in which government agencies and officials along with Mainstream Media refuse to acknowledge. Pilots For 9/11 Truth Core member list continues to grow.

http://pilotsfor911truth.org/core.html for full member list.

http://pilotsfor911truth.org/join to join.

[1] Hijacker Timeline - http://pilotsfor911truth.org/forum/index.php?showtopic=17

[2] Common Strategy Prior to 9/11/2001 - http://pilotsfor911truth.org/pentagon.html

[3] Right click and save target as here to download csv file with "FLT DECK DOOR" parameter.





Rob ive been out of the loop for a while and have just got back on the net and back to the new site.I will be ordering my copy of the new video soon -as it looks like the answer to so many questions about what could have taken place aboard those aircraft and the fantasy that has been rolled out by the Bush government and to some extent the Obama administration.
The door being closed all through the flight of AA77!!
Youve blown my f*$!ing mind.I need to sit down in a darkened room!
Rest assured i will be telling everyone i know about this here in the UK.
You are a legend and all your efforts are appreciated.Please pass on my admiration and respect to Rusty when you speak to him next.Without real pilots like yourselves these lies would never see the light of day.
Respect -localbod. handsdown.gif
Go to the top of the page
 
+Quote Post
wstutt
post Dec 9 2009, 08:59 PM
Post #412





Group: Troll
Posts: 255
Joined: 27-December 07
From: Brisbane, Australia
Member No.: 2,603



Hi SerialThrilla,

QUOTE (SerialThrilla @ Dec 14 2009, 11:14 AM) *
Warren,

I have a question with the data formats:

A/C TYPE LSB

D226A101-3G.pdf
Word 256
SUBF 4
SUPF 1

757-3b_1.txt
Frame(s) ALL
Subframe(s) 4
Word 256

Any idea why 757-3b_1.txt has Frame(s) listed as ALL when D226A101-3G.pdf has it listed only for Frame 1?
You raise an interesting point. The MANUFACTURER CODE occupies bits 1 to 5 of the word you referred to above. If it is decoded according to D226A101-3G.pdf it has a constant value which is interpreted as TELEDYNE. If it is decoded according to 757-3b_1.txt then the value keeps changing. Clearly the MANUFACTURER CODE shouldn't change therefore at least for this parameter, the FDR file appears to be encoded according to D226A101-3G.pdf rather than 757-3b_1.txt.

All the parameters that I have decoded that do not have a blank SUPF in D226A101-3G.pdf, have a Frame(s) value one less in 757-3b_1.txt, except for a SUPF of 1 which has a Frame(s) value of ALL, as in your example above.

QUOTE
It appears that data that is in every super frame is given a blank value for the SUPF, such as GMT_SEC (GMT SECONDS).
Correct, data that appears in every frame of a super frame is given a blank value for the SUPF.

QUOTE
Does this negatively affect your decoder and possibly why the timestamps are whacky?

Thanks
I've tried decoding GMT MONTH, GMT DAY, GMT YEAR, GPS HOURS, GPS MINUTES and GPS SECONDS using both data frame layouts and could not get sensible values using either. See my Notes on Parameters for the AAL77 FDR Decoder web page for more.

Warren.
Go to the top of the page
 
+Quote Post
wstutt
post Dec 10 2009, 01:10 AM
Post #413





Group: Troll
Posts: 255
Joined: 27-December 07
From: Brisbane, Australia
Member No.: 2,603



I've added new parameters to my program. Read about it here

Warren.
Go to the top of the page
 
+Quote Post
SerialThrilla
post Dec 10 2009, 02:07 PM
Post #414





Group: Newbie
Posts: 8
Joined: 7-December 09
Member No.: 4,771



QUOTE (wstutt @ Dec 9 2009, 09:59 PM) *
I've tried decoding GMT MONTH, GMT DAY, GMT YEAR, GPS HOURS, GPS MINUTES and GPS SECONDS using both data frame layouts and could not get sensible values using either.

Yup, I've been modifying your code (nice code btw, it was easy jumping into) and I can't get any sensible values for these columns either.
I'm going to try playing around a bit with the frame layout maybe later tonight..
Go to the top of the page
 
+Quote Post
jensdarup
post Dec 11 2009, 02:50 PM
Post #415





Group: Student Forum Pilot
Posts: 69
Joined: 10-September 09
Member No.: 4,610



As a layman I wonder why in such a complex system as an aircraft date and time aren't registered automatically. Seems to me a bit anachronistic.
Go to the top of the page
 
+Quote Post
SerialThrilla
post Dec 11 2009, 05:29 PM
Post #416





Group: Newbie
Posts: 8
Joined: 7-December 09
Member No.: 4,771



QUOTE (jensdarup @ Dec 11 2009, 02:50 PM) *
As a layman I wonder why in such a complex system as an aircraft date and time aren't registered automatically. Seems to me a bit anachronistic.


From my inspection last night, the unsigned value of the entire 12-bit frame that contains the DAY (and MONTH) portion of the date remains 4030 for the entire FDR. Even crossing over midnight (GMT or -4/-5 GMT) it doesn't change.

Either the they input the wrong date, the date isn't even correctly being recorded, or this is the wrong data frame layout.
Unfortunately I only have two documents, the American database and the Boeing generic. dunno.gif
Go to the top of the page
 
+Quote Post
jensdarup
post Dec 12 2009, 04:22 AM
Post #417





Group: Student Forum Pilot
Posts: 69
Joined: 10-September 09
Member No.: 4,610



QUOTE (SerialThrilla @ Dec 11 2009, 11:29 PM) *
From my inspection last night, the unsigned value of the entire 12-bit frame that contains the DAY (and MONTH) portion of the date remains 4030 for the entire FDR. Even crossing over midnight (GMT or -4/-5 GMT) it doesn't change.

Either the they input the wrong date, the date isn't even correctly being recorded, or this is the wrong data frame layout.
Unfortunately I only have two documents, the American database and the Boeing generic. dunno.gif

When it should be the wrong data frame layout, does this mean date isn't displayed correctly or does this mean date isn't registered at all? When it wouldn't be displayed correctly one should be able to assume that it would change at midnight nevertheless. If it is not registered as date there wouldn't be a necessary for any other parameter to change at midnight. - When date/time has to be input from pilots wouldn't they have to change it at midnight too?
Go to the top of the page
 
+Quote Post
wstutt
post Dec 12 2009, 04:57 AM
Post #418





Group: Troll
Posts: 255
Joined: 27-December 07
From: Brisbane, Australia
Member No.: 2,603



Hi SerialThrilla,

QUOTE (SerialThrilla @ Dec 15 2009, 08:07 PM) *
Yup, I've been modifying your code (nice code btw, it was easy jumping into) and I can't get any sensible values for these columns either.
I'm going to try playing around a bit with the frame layout maybe later tonight..
Thanks for the kind words. You're the first person I am aware of who is looking through the source code for my AAL77 FDR Decoder. Hopefully there will be more.

Warren.
Go to the top of the page
 
+Quote Post
wstutt
post Dec 12 2009, 05:10 AM
Post #419





Group: Troll
Posts: 255
Joined: 27-December 07
From: Brisbane, Australia
Member No.: 2,603



QUOTE (jensdarup @ Dec 16 2009, 08:50 PM) *
As a layman I wonder why in such a complex system as an aircraft date and time aren't registered automatically. Seems to me a bit anachronistic.
As far as time goes, although I couldn't get sensible values for GPS HOURS, GPS MINUTES and GPS SECONDS, I did get sensible values for GMT HOURS, GMT MINUTES and GMT SECONDS, so we do have values for the time from the FDR file.

Warren.
Go to the top of the page
 
+Quote Post
wstutt
post Dec 12 2009, 05:20 AM
Post #420





Group: Troll
Posts: 255
Joined: 27-December 07
From: Brisbane, Australia
Member No.: 2,603



Hi SerialThrilla,

QUOTE (SerialThrilla @ Dec 16 2009, 11:29 PM) *
From my inspection last night, the unsigned value of the entire 12-bit frame that contains the DAY (and MONTH) portion of the date remains 4030 for the entire FDR. Even crossing over midnight (GMT or -4/-5 GMT) it doesn't change.

Either the they input the wrong date, the date isn't even correctly being recorded, or this is the wrong data frame layout.
Unfortunately I only have two documents, the American database and the Boeing generic. dunno.gif
I tried finding the date in the data, by getting a program to try decoding every combination of WORD, SUBF, SUPF, MSB and LSB and look through the results to see if they looked like something that behaved like the day of the month should like changing as the time crosses over midnight as you mentioned. Unfortunately I didn't find anything. When I earlier tried the same approach with UAL93's FDR file, I did find the date.

Warren.
Go to the top of the page
 
+Quote Post

24 Pages V  « < 19 20 21 22 23 > » 
Reply to this topicStart new topic
4 User(s) are reading this topic (4 Guests and 0 Anonymous Users)
0 Members:

 




RSS Lo-Fi Version Time is now: 13th December 2017 - 12:11 AM