New FDR Decode

Originally posted by R_MackeyNote that the Comparator_Fail_FO have empty cells yet the others are recording a digit. The empty cells are due to perhaps a broken line between the sensor and the FDAU.

Wrong. THis is incorrect.

A broken line between the SENSOR and FDAU does not give you an empty
cell in an Excel spreadsheet!

You are confusing crash protected memory with a bunch of numbers in
a CSV file!

Flight data recorders cannot contain spaces, empty cells, or numbers.
Crash protected memory is a series of gates which use direct current
to change state. You either get a voltage level LOW (0), or voltage level
high (1) when you address the line drives for any gate.

The .fdr file is a representation of these gates.

The CSV file is a 3rd generation format which required a SOFTWARE PROGRAM
to convert the values.




[edit on 3-12-2009 by turbofan]

Originally posted by 911files

Originally posted by turbofan
My view on 9/11 remains the same as I am interested in well researched,
well documented evidence in order to remain honest in my studies.

[edit on 3-12-2009 by turbofan]

Found a 1 in that 42 hours worth of data yet?

No, have you found any origin for that white smoke, or associated parameters in the FDR to prove light pole strikes?

Originally posted by turbofan

No, have you found any origin for that white smoke, or associated parameters in the FDR to prove light pole strikes?

No, I'm not working the smoke angle, but as far as the pole strikes yes. I won't repost it all, but there are changes in the acc data that correlate with the time-adjusted postional data and the poles.

reply to post by R_Mackey


I'm sure you do understand that the labels such as 'FLT DECK DOOR' with or without a prefix like 'RSVD' are not embedded within the raw data file. In Warren's decoder the labels are embedded in the code along with word #, subframe# and bit position within the word for that particular parameter so even if it was reserved, or not functioning, the same label (FLT DECK DOOR) would be displayed in his output.

The disputed parameter is embedded in bit 1, subframe 3 of word 251 along with a number of other parameters including an analog reading (Indicated AOA) in bits 3-12 of every subframe.

Bit map of word 251:

Word 251 Assignments
Subframe
Bit # 1 2 3 4
1 Aft Cargo Door #1 Aft Cargo Door #2 Flight Deck Door Main Cargo Door
2 Aft Cargo Door Elect Access Door Fwd Cargo Door Fwd Access Door
3 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
4 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
5 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
6 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
7 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
8 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
9 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
10 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
11 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg
12 Ind AOA Deg Ind AOA Deg Ind AOA Deg Ind AOA Deg

It's obvious that bit 1 subframe 3 MUST be present whether the door is actually scanned or not otherwise that entire word and the remainder of the subframe will be corrupted (every bit has to be there, working or not).

Take a look at Warren's decoder output and especially every subframe in which FLT DECK DOOR 'closed' appears and on that row compare the Indicate AOA value.

Does it vary throughout the file ?
Indeed it does showing that there's no doubt about word 251, subframe 3 being used.

This basically shows that even if there was no valid signal from the door, a 0 or a 1 would still have to be 'padded' into that bit position to maintain data integrity. 'FWD CARGO DOOR' is bit 2 in the same subframe word 251 as FLT DECK DOOR so ditto for that one as well IE a dummy value is necessary if no real value exists.

reply to post by Pilgrum


Very good Pilgrum. You went a whole lot deeper into the current code than I have (been occupied with other stuff).

reply to post by Pilgrum


Correct. I tried to explain that several times: a disconnected FLT_DECK_DOOR parameter
will still register ZERO in the crash protected memory because the
FRAME LENGTH CANNOT CHANGE!

EDIT: Clarify parameter

[edit on 3-12-2009 by turbofan]

reply to post by turbofan

Originally posted by turbofan
I am no longer supporting the latest P4T claim as there is insufficient documentation to make a conclusive statement.

This does not mean that my view on previous FDR research changes;
simply the connection to FLT_DECK_DOOR cannot be confirmed at this
time.

When the proper manuals come available, I will reassess PilotforTruth's
position and post accordingly.

My view on 9/11 remains the same as I am interested in well researched,
well documented evidence in order to remain honest in my studies.

[edit on 3-12-2009 by turbofan]

Turbofan/Tino,

You and I undoubtedly disagree about a lot of things regarding 9/11, but I would like to applaud this show of skepticism. I apologize for my derisive and insulting remarks to you earlier in the thread, and I will be civil with you from now on.

BTW, we were both wrong about the ADC; lets just say Boeing did a little outside the box thinking(I don't mean that literally, though) .

Respect to Turbofan for his latest posts.

reply to post by 767doctor


Thank you Jay,

It was pretty much a no brainer once I found out this press release was
based on a poor understanding of how the flight data is recorded, as well
as not having the proper manual to prove whether a connection was
made between the cockpit door and the FDAU (possibly via EICAS).

If you read the top of the page, it's clear he has no clue about how the
bit values are stored and how they make their way into an Excel spreadsheet.

This latest development does not mean that I am taking a new side on
the events of 9.11.01; it simply means I will not put my name behind
erroneous claims. I will back up all previous research done by P4T,
but I cannot tolerate the leader of a pilot organization issuing a press
release based on a gut feeling...and a bad one at that.

After many attempts of trying to explain why Mr. Balsamo was wrong,
he simply didn't wish to learn and cut me from the forum and blocked
my e-mails. He will not remove my posts which are associated to the
latest theory so therefore I must make it clear that I want no part of
an organization that chooses to make claims without providing their
members and the general public with proof.

There are far more valid anomalies with the FDR/Official story to worry
about in my opinion. Let's see if we can discuss them in a more civil
manner from this day forward (I can't see that lasting too long however! )

[edit on 3-12-2009 by turbofan]

Rob if you continue to send me personal e-mails and block my returns,
I will continue to expose your lack of understanding here. For the last
time, remove my posts which are associated with the latest press release.

It appears Tino Desideri/Turbofan has switch sides due to this latest article and is now bashing us (me personally) on ATS.

Here is an email sent to Tino regarding this fiasco if anyone has any questions.

Keep in mind, Tino attempted to delete his posts here. We dont delete posts. So he has been placed into the Guest category until he can perhaps cool down a bit. But instead it appears he wishes to make it worse on ATS.

No, I'm not switching sides...I guess you failed to read my statement, or
you were too quick to shut me off after correcting your errors.

My posts were only deleted within the FLT_DECK_DOOR thread. I do NOT
agree and therefore want no association with your THEORY.

Aircraft Accident Investigators have to perform guess work on all the attached parameters to determine whether the parameter was hooked up to record, or if it was showing its true state, according to your theory.

Mr. Balsamo does not understand the difference between discrete digital
parameters, and analog parameters. He does not understand that a DC
voltage is required to set bit states within the FLASH memory.

As for your posts that you now want deleted from our forum, are you telling me you didnt know the day you read my article that a zero can also mean a "place holder" as you now claim?

As I NOW claim? I'm telling you the day I read your article, I expected
a thorough analysis, checked and proven before making a public statement
that a hijacking was "IMPOSSIBLE" due to one parameter which you cannot
prove as even being connected! WHere is that 757 manual? Did you
manage to locate one from your contact yet? Don't you think you should have obtained
the manual FIRST and checked your sh#t before mass mailing your contacts and media list?

I'm embarrassed to say I began debating this expecting to have access to
proper documentation to support such a claim.

Are you also saying we should ignore this data and not hold the NTSB responsible for providing it showing a cockpit door indication closed?

See above! WTF are you going to do when the NTSB, or AA comes back
with a disconnect for FLT_DECK_DOOR? I hope for your sake, you find
a manual that supports your theory. When that happens, I will reassess
my position on this topic.

Tino, we never claimed to have proof, nor have we claimed to have the data "confirmed". You claimed that, now you look like a fool so you're trying to save face.

I look like a fool because YOU sent out a public statement saying the
hijack was impossible...but now YOU cannot prove it?

The data conflicts with the govt story. We want to know why. You seem to want to make excuses for it.

I don't make excuses, and I certainly don't make false claims. Unlike YOU
just did. YOu wanna talk RAD ALT., PA, DME, etc. FINE. That's a valid
arguement. FLT_DECK_DOOR is not!

(again, dont bother replying as you been blocked)

Stop sending me e-mails please. Maybe when you're ready to listen
and learn how things really work, you are welcome to write back.


[edit on 3-12-2009 by turbofan]

Originally posted by turbofan
reply to post by 767doctor

 

Thank you Jay,

It was pretty much a no brainer once I found out this press release was
based on a poor understanding of how the flight data is recorded, as well
as not having the proper manual to prove whether a connection was
made between the cockpit door and the FDAU (possibly via EICAS).

If you read the top of the page, it's clear he has no clue about how the
bit values are stored and how they make their way into an Excel spreadsheet.

This latest development does not mean that I am taking a new side on
the events of 9.11.01; it simply means I will not put my name behind
erroneous claims. I will back up all previous research done by P4T,
but I cannot tolerate the leader of a pilot organization issuing a press
release based on a gut feeling...and a bad one at that.

After many attempts of trying to explain why Mr. Balsamo was wrong,
he simply didn't wish to learn and cut me from the forum and blocked
my e-mails. He will not remove my posts which are associated to the
latest theory so therefore I must make it clear that I want no part of
an organization that chooses to make claims without providing their
members and the general public with proof.

There are far more valid anomalies with the FDR/Official story to worry
about in my opinion. Let's see if we can discuss them in a more civil
manner from this day forward (I can't see that lasting too long however!

)

[edit on 3-12-2009 by turbofan]

Well, we couldn't have gotten off to a worse start than we did, but I'm sure you'll find that I am perfectly capable of having a civil discussion, even with people whose viewpoints are diametrically opposed to mine. Its a matter of respect. You've just earned mine; Balsamo has not. If he were interested in honest debate, I'd be the first to extend an olive branch...but I won't hold my breath.

As far as FDR anomalies, well, you're barking up the wrong tree if you looking for me to say theres nothing strange about some of the data. I will say that Warrens decode has helped tremendously though. The final four seconds answered many questions that I had(obviously the altitude aspect), but it begs other questions....I'll be the first to admit that.

This is how the leader of an organization acts; block my access to reply
and makes false statements!

And just as a reminder... (this was sent to Tino as well, several times, but he chose to ignore it)

No, not ignored. I corrected you. There are error all over your posts
on ATS. I have a slew of e-mails which you admit not having an understanding
of the FDR, schematics, or data.

If you continue to slander me, I will have no choice but to defend myself.

....we have verified Warrens data for the last flight only, the alleged hijacking on Sept 11, it shows the door closed.

As mentioned above, you're fine to use parameters when they fit your
need, but you'll throw away all other parameters until you can verify
his code?

Still to this day you don't understand that the code reacts the same way
for one set of flight data, as it would another. IE: If flight deck door
is closed for the last flight, the same program code that Warren wrote
applies to all FLT_DECK_DOORS in the remainder of the flights.

This is the same deal for all other parameters. Funny how you questioned
RAD ALT, but not FLT_DECK_DOOR?

And if logic has any value, this would be the bit value recorded if the FLIGHT DECK DOOR parameter wasn't hooked up to the system so when a tech reviews the data, he can readily admit its not valid.

A Tech would have the proper frame layout, and wiring schematics
to show whether or not FLT_DECK_DOOR was connected. From there,
the tech can easily determine if the zero's are from a disconnected
parameter, or from a closed door.

You cannot do this, and therefore your claim is invalid!

Originally posted by turbofan
YOu wanna talk RAD ALT., PA, DME, etc. FINE. That's a valid
arguement. FLT_DECK_DOOR is not!

Actually, you can scratch DME off the list. For some reason, the P4T has different positional data than the Warren RO. Once the Warren RO is aligned with the radar and proper time, the DME values match accordingly. There is a 0.25 precision in the fdr DME data. The actual VOR distance is ~1.64 when the DME is recorded at 1.5. When it reads 1.25, there is a similar accuracy, ~1.36 from the DCA VOR.

You can download the aligned kmz model and check it for yourself.

KMZ Model

Just a note: Looks like DME is sampled at WORD 253 (at the end of the subframe) and POS at 59-61. So a good 1/2 to 3/4 seconds after the POS is sampled, the DME is. The next position is 1.54 (relative to the 1.5 DME), so the sampling was done closer to that POS (-4) than the one registered in that subframe. Well within the 0.25 precision range (DME stored in 0.25 increments).

[edit on 3-12-2009 by 911files]

Originally posted by 911files

Originally posted by turbofan
YOu wanna talk RAD ALT., PA, DME, etc. FINE. That's a valid
arguement. FLT_DECK_DOOR is not!

Actually, you can scratch DME off the list. For some reason, the P4T has different positional data than the Warren RO. Once the Warren RO is aligned with the radar and proper time, the DME values match accordingly.

And the hits keep on coming.

It would seem that the only fraudulent FDR data has been produced by PfffT themselves.

reply to post by 911files


I suppose you're wondering what I mean by, "FRAME LENGTH CANNOT CHANGE"?

Here's what's going on (from Warren on P4T):

Hi Rob,

Both the data frame layouts I received from the NTSB state that for both the COMPAR ENABLE F/O and COMPAR ENABLE CAPT parameters that 0 = ENABLE and 1 = DISABLE.

Since COMPAR_ENABLE_F_O is 1 (DISABLE) and COMPAR_ENABLE__CAPT is 0 (ENABLE), this could explain why COMPARATOR_FAIL_F_O is blank and COMPARATOR_FAIL_CAPT is not blank, respectively.

Both data frame layouts state that for the COMPARATOR FAIL CAPT parameter that 0 = NOT and 1 = FAIL. COMPARATOR_FAIL_CAPT is 1 (FAIL) as you said.

There are other columns in ReadOut2 that are blank however.

The columns in Readout2 that are blank are FTP, PRM, PPP, TIME, PATH, MENU, MYIP, DFDR, REMIP, UPLOAD, UPDFTP, OPTION, PROMPT, PPPNUM, QARFTP, PEERMRU, UPL_SRC, NETMASK, FTPPASS, STATION, PPPPASS, VERSION, PPPSNUM, PPPUSER, PPPDNUM, MACADDR, COMSPEC, MDM_INT, FTPUSER, FTPRADDR, FTPRUSER, FTPSADDR, FTPSPASS, MDM_PORT, MDM_RATE, FTPQUSER, FTPSUSER, RSYNCSRC, PPPSUSER, PPPSPASS, FTPQPASS, FTPQADDR, FTPRPASS, PPPDUSER, PPPDPASS, APiasmode, ReviewedBy, ALTradsign, CursorStart, InterpretedBy, CON_MODE_OPER, InvoiceNumber, IncidentDetails, SoftwareVersion, ACMS_S_W_P_N_CODE, COMPARATOR_FAIL_F_O, A_P_T_E__FLAP_POSITION_2 and ACType.

My program already decodes ACMS S/W P/N CODE, I don't know why it would be blank in ReadOut2.

Warren.

ETA: I hope this answer's Jefferson's questions as well.

This is the EXACT same thing I explained to Rob earlier today before
Warren posted. Warren and I had a private mesasge exchange,
however I cannot receive any futher updates because my access is
removed.

See post at top of page where Rob believes a blank column = disconnected
parameter.

When Rob sent me his CSV files yesterday, I explained that both contain
parameters that are updating, not updating, and have blank columns.
There is no logic within these spreadsheets that proves a blank column
indicates a disabled/disconnected parameter. This is a CODING issue!

Furthermore, I explained that Warren's decode was able to pull parameters
that RO2 could not. As you will see on the P4T forum, Rob is already on
his second false assumption that COMPARATOR F/O is blank and therefore
the plane should have been grounded.

Wake the F up Rob! Maybe you will believe Warren over me? Wait for
the decode before going public next time.


[edit on 3-12-2009 by turbofan]

I understood what you were saying. That is what I was talking about with the serial bit data stream. It is a fixed format and like you say, is always the same length. This is a simplified way of stating it, but the 'upgrade' to to 757-3B was an increase in the length so it could carry more parameters. So yes sir, you are correct.

The differences come from the software used to 'decode' the stream. Warren is looking at the stream itself and recovering values using the frame layout. Undertow was very secretive about the specifics under which the P4T RO was done. I don't see anything sinister in that because my understanding is the person assisting wished to remain 'off-the-record', a courtesy I extend to many of my sources as well.

Originally posted by turbofan
I look like a fool because YOU sent out a public statement saying the
hijack was impossible...but now YOU cannot prove it?

I wish I were a little fly on the wall when the boys at Aviation Week and Space Technology or some other professional aviation organization gets these PfT/Balsamo "news releases". I am sure Balsamo sends these to them. It would no doubt be high humor.

I wonder why they do not jump right on the PfT bandwagon when these things come out? Could it be that Balsamo is as screwed up as a soup sandwich? Or, as PfT would claim, AW&ST is no doubt in on the whole schema as well.

I think we know what the answer is.

That press release is looking pretty stupid now, don'cha think, Cap't_Bob_Mackey?

PfT has this bad habit of driving a stake in the quicksand thinking it is solid ground. We can add this technical and PR debacle as yet another bullet to the ever-growing list of PfT clownish claims such as the vectoring of Gopher 06 up along the very edge of Prohibited Area 56, the "surface to air missiles" at the Pentagon being stood down and the misinterpretation of the CS1 departure.

Adieu, PfT.

[edit on 3-12-2009 by trebor451]

reply to post by 911files


Yes, RO2 was produced using industry software from a qualified operator,
that much I can assure you. Undertow is still available for contact if anyone
cares to learn more.