Aal77 Fdr Decoder Program, Decodes almost 4 more seconds Options

[wstutt]

Hi Warren!

<snip>

But when it comes to computer code issues such as you discuss in your above quote I am a babe in the woods and can't even begin to muster whatever it is that leads me to comment on the former matters. I can see how the data numbers you cite connect serially (526-782-910 and the subframe numbers - whatta blinding display of math and logic!). So could you please explain further, perhaps starting with the meaning and significance of the "ACMS S/W P/N CODE parameter"?

<snip>

Hi tnemelckram,

The only information I have on the meaning of the ACMS S/W P/N CODE parameter is this note from the D226A101-3G.pdf data frame layout:

NOTE 2F ACMS and Mandatory Software Part Number Recording (757-1, -2, -3, -3A, -3B, -4)

ACMS (optional) and Mandatory software part numbers shall be recorded in the data frame by using
a binary code from 0 to 4095. This code shall be correlated to the actual supplier software part
number in the supplier Version Description Document (VDD). The code must uniquely identify
a software part number or combination of part numbers.
A second option is to broadcast the software part number(s) one character at a time in lSO#5 format
continuously recording the part number in lieu of a unique code.

I see on Wikipedia that ACMS may stand for Aircraft Condition Monitoring System, so perhaps the software in this system changed rather than the software in the FDR that I thought had changed.

Warren.

[onesliceshort]

Hi Oneslice!

1.

That's OK - I can be a real pain in the ass because (in accordance with my disclaimer in my above post to Warren) i can be a real pain in the ass because I post about things that I don't fully understand but make me smell a rat!

Hey Mark,
Way over my head too unless it´s explained in layman terms.

2.

I don't know enough to explain but do know enough to agree with you that this is an internal logical inconsistency in the data.

Among many others. What gets me is the amount of debate and YEARS of probing of this ´internal logical inconsistency´ when the NTSB or L3 Communications should be investigating this as a priority.
As Rob has said, this is a matter of Public Safety if FDRs are susceptible to this ´corruption of data´ (thinking out loud mate, not ranting lol)

3.

Since I have no expertise I can't say for sure but I think that it's safe to say that all of this positional data (FDR INS and Radar) is not exact and does have some inherent margin for error. Then of course going beyond that I can't say that my translation or interpretation is technically correct - it is nothing more than another man's translation. (EDIT TI ADD: Then I may have made errors in executing the measurements using inexact GE tools. But my basic logic with the radar data is that the purpose of "P" and "D" range and bearing taken in one sweep is to give you two points as a margin of error and thus the most accurate position is in between the two. ) But I do think that it clearly shows, as you observe and as Rob might say, "no matter how you slice it", there's no support for the GL-OCT point about the plane hitting the poles, as well as the bank reflected in the data.

Agreed. Though this argument has given detractors ´wriggle room´ for years now. The alleged trajectory of the plane as painted by the Official narrative is very precise in that the lightpoles and directional damage to the facade narrow the path to within metres.
That´s why it´s so frustrating.
As you say, even the miriad of ´most accurate´ paths, even Farmer´s, miss the poles.
The plane would still be too high.

4.

As I understand it, the adjustment is because the radar either does or does not use either geographic or magnetic north as a base. The adjustment is to compensate for the 9.5 degree difference between the two that day. I can't say for sure whether Farmer or me or some other method would be correct. But as far as I'm concerned, it reverts back to point 3 above "no matter how you slice it".

I would actually double check on that one. Farmer would put Walter Mitty and Pinocchio to shame. (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/rolleyes.gif)

5.

As you note that cry can be raised both ways and if you ask me cancels each other out, leaving you with point 3 above.

I would say, given the amount of disinfo and at times bare-faced lies which emanate from one corner more than the other that isn´t an accurate statement.
If ´we´ make a mistake, we correct it or at least acknowledge it and move on.
They do not. Not an opinion based on bias but experience.
But yes, point taken.

6.

Maybe the sum total of all of this means that you toss out all this he data because it it is either inconclusive or a mess. Then all that leaves you with is the CIT eyewitness account evidence on which to base what actually happened. (2ND EDIT TO ADD: Leaving that aside, I also think the weight of all the positional data points to more North than South of Citgo)

Based on the apparent inconclusiveness mentioned above, apart from the fact that the poles are missed, this ´margin of error´, whether there actually IS one or not, will provide fuel to detractors for years to come.
I´m not saying ´throw it out´, but take it with a pinch of salt.
Personally speaking, the witness testimony can be the only non-biased, inambiguous way forward.
NOBODY saw that path even if it is more North than South.

Peace
OSS

[tnemelckram]

Hi Oneslice!

Based on the apparent inconclusiveness mentioned above, apart from the fact that the poles are missed, this ´margin of error´, whether there actually IS one or not, will provide fuel to detractors for years to come.
I´m not saying ´throw it out´, but take it with a pinch of salt.
Personally speaking, the witness testimony can be the only non-biased, unambiguous way forward. NOBODY saw that path even if it is more North than South.

I agree. Here's the best way I can think of to address the problem you note. The government is our real opponent, not a bunch of GL's doing its dirty work. It's up to the government to explain or reconcile the inconsistencies in its FDR and Radar data. So far it has said nothing. Hell, for all I know the government thinks that its data is a bunch of internally inconsistent crap, but just isn't saying so for obvious reasons.

Another argument is that the entirety of the FDR and Radar positional data contains so many cross-checks that it rules out all arguments about "margin of error". You have FDR, RADES and then three sets of DCA airport radar data with two integral cross checks (P and D range), and finally the data from the other three airports (BWI, IAD and ADW). Thus you have eleven cross checking data sets that are weighted more toward NOC than anything else and thus tend to only support the CIT eyewitnesses and do not tend to support anything else.

But the best way would be to discredit the FDR data from the inside out by computer code analysis as JFK was trying to do with Warren's work. That's much better than my perhaps imperfect attempt to attack one part of it from the outside in. If the FDR falls, then CIT's eyewitnesses either dominate the field or are the only thing remaining to occupy it.

[onesliceshort]

Hi Oneslice!


But the best way would be to discredit the FDR data from the inside out by computer code analysis as JFK was trying to do with Warren's work. That's much better than my perhaps imperfect attempt to attack one part of it from the outside in. If the FDR falls, then CIT's eyewitnesses either dominate the field or are the only thing remaining to occupy it.

Fair enough Mark.

I only wish I could read the data, actually pick it apart bit by bit and do my part.
Still can´t figure out how the straight path was derived from the same program which points to a continuous 6º bank at that speed. Am i reading too much into this or is this bank negligible?

Peace
OSS

[onesliceshort]

Hi OSS,

It appears in the last 7 seconds of my decode.

It goes up to 6.3° then decreases back to 0° about 0.06 seconds before the end of the data in my decode.

See the following image for the locations of the aircraft according to the FDR file:
(IMG:http://www.warrenstutt.com/General%20Images/AAL77%20Final%20Right%20Bank.jpg)

They are almost 4 seconds of continuous data after the end of the NTSB CSV file.

P4T's decode (ReadOut2) ends 1 second before the end of the NTSB CSV file so my decode has almost 5 continuous seconds after the end of ReadOut2. I don't know whether the NTSB animation quite matches up with the NTSB CSV file.

Warren.

Hi Warren

1) Is ´B´ the final data point (I mean of all data extracted, but specifically positional)?
That is ´0.06 seconds before the end of the data ´ in your decode or are there any data points beyond this? The ´4ft radalt´ reading for example.

2) It took 7 seconds to get from point ´A´ to point ´B´?

Cheers
OSS

[wstutt]

Hi OSS,

Hi Warren

1) Is ´B´ the final data point (I mean of all data extracted, but specifically positional)?
That is ´0.06 seconds before the end of the data ´ in your decode or are there any data points beyond this? The ´4ft radalt´ reading for example.

There are normally 256 words per subframe and one subframe is recorded per second. The last recorded subframe is incomplete and contains only 243 words.

Point B is the last latitude and longitude. The latitude and longitude are stored in words 59 to 62 in each subframe so that is (243 + 1 - 59) / 256 = 0.7 seconds before the end of the data.

That figure of 0.06 seconds should actually be 0.02 seconds. I calculated it incorrectly. The ROLL ANGLE CAPT parameter is recorded 4 times per subframe in words 46, 110, 174 and 238. The last value at word 238 is (243 + 1 - 238) / 256 = 0.02 seconds before the end of the data. I forgot to say earlier that I have found that up to about the last 9 words of data in a compressed section of data can have strange values, so that final ROLL ANGLE CAPT value of 0° could be incorrect given that it is the 6th to last word of data.

The radalt parameter is stored in words 31 and 32 in each subframe so the last value of 4 ft is (243 + 1 - 31) / 256 = 0.8 seconds before the end of the data.

2) It took 7 seconds to get from point ´A´ to point ´B´?

Cheers
OSS

Here is the last 8 seconds of latitude, longitude, roll angle and radalt values:
(IMG:http://www.warrenstutt.com/General%20Images/AAL77%20Last%208%20Seconds.jpg)
Point A is the location in row 6 of the spreadsheet in the image which is subframe number 151362. Point B is the location in row 30 which is subframe number 151368. They are 151368 - 151362 = 6 seconds apart.

Warren.

[onesliceshort]

Hi Warren,

Here is the last 8 seconds of latitude, longitude, roll angle and radalt values:
(IMG:http://www.warrenstutt.com/General%20Images/AAL77%20Last%208%20Seconds.jpg)
Point A is the location in row 6 of the spreadsheet in the image which is subframe number 151362. Point B is the location in row 30 which is subframe number 151368. They are 151368 - 151362 = 6 seconds apart.

I made a (very) rough plot of the data just to make it easier (for me) to read at a glance and Point ´B´ appears to me to be the point with the radalt reading of 57ft not the 4ft reading on line 30. No?

(IMG:http://i659.photobucket.com/albums/uu311/buckwheat_bucket/wstuttdatapoints.jpg)

It´s a rough plot of mine á la layman and point F coresponds with Point ´B´ on your map.

Are you counting inclusively Warren? A = 1 second, B = 2 seconds, etc? I know that subtracting the above subframes gives us ´6´ but not when calculating the time to arrive from ´A´ to ´B´.

By my reckoning there are 5 seconds between A to B (or A to F on my map)

[wstutt]

Hi Warren,



I made a (very) rough plot of the data just to make it easier (for me) to read at a glance and Point ´B´ appears to me to be the point with the radalt reading of 57ft not the 4ft reading on line 30. No?

(IMG:http://i659.photobucket.com/albums/uu311/buckwheat_bucket/wstuttdatapoints.jpg)

It´s a rough plot of mine á la layman and point F coresponds with Point ´B´ on your map.

Are you counting inclusively Warren? A = 1 second, B = 2 seconds, etc? I know that subtracting the above subframes gives us ´6´ but not when calculating the time to arrive from ´A´ to ´B´.

By my reckoning there are 5 seconds between A to B (or A to F on my map)

Hi OSS,

It looks to me like your point B should be split in to two points.

Here is my plot of the last 8 seconds with the points marked with the Subframe Counter numbers:
(IMG:http://www.warrenstutt.com/General%20Images/AAL77%20Last%208%20Seconds%202.jpg)

Warren.

[onesliceshort]

Aah, okay (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/doh1.gif)
Cheers Warren

OSS

[rob balsamo]

Looks like our good friend Mackey finally decided to look up the definition of supercritical after I had to repeat it twice, although once again, a little knowledge is more dangerous than none.... Perhaps Mackey while sweeping the floors at NASA overheard Whitcomb talking to a friend or something... (RIP Whitcomb! Don't let Mackey upset your slumber)

First from Mackey....

"Boeing aircraft typically cruise above their critical Mach number..... Up at altitude, they cruise around 0.8 Mach or so all day long. This is done using supercritical wing design," - Ryan Mackey

And now reality...

"Several methods exist to reduce wave drag, including the use of swept wings, slender or thin bodies, and supercritical airfoils. These airfoils have critical Mach numbers very close to one (hence the term supercritical) thereby delaying and reducing the large increase in drag due to wave drag. " - aerospaceweb

"With the supercritical wing, a substantial rise in the drag-divergence Mach number is realized and the critical Mach number is delayed even up to 0.99. This delay represents a major increase in commercial airplane performance." - Centennial Of Flight Commission.

(bolding emphasis mine)

Just a quick search I did to help out Mackey. (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/smile.gif)

For those still confused, a supercritical wing design delays Critical Mach. It doesn't allow more efficient flight above Mcrit as Mackey would have you believe.

Ohhh... so close Mackey, but still wrong. (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/smile.gif)

IIRC, Mcrit (Critical Mach, or... Mach Critical) on a 757/767 is near .89-.91 Mach. Usually Mmo is structured around Mcrit. I'll double check with our 757/767 Capts.

(by the way Mackey, not all Boeings utilize supercritical wing design. But i'll let you look that up along with your static "probes" on such aircraft...)

Just a quick update on this....

I did an interview with Dwain Deets last night on the aircraft speeds and brought up Mackey statements regarding critical mach. Needless to say, Dwain and I had several good laughs at Mackey's expense as well.

Credentials and Experience of Dwain Deets.

Dwain Deets
MS Physics, MS Eng
Former Director, Aerospace Projects, NASA Dryden Flight Research Center
Served as Director, Research Engineering Division at Dryden
Recipient of the NASA Exceptional Service Award
Presidential Meritorious Rank Award in the Senior Executive Service (1988)
Selected presenter of the Wright Brothers Lectureship in Aeronautics
Associate Fellow - American Institute of Aeronautics and Astronautics (AIAA)
Included in "Who's Who in Science and Engineering" 1993 - 2000
Former Chairman of the Aerospace Control and Guidance Systems
- Committee of the Society of Automotive Engineers
Former Member, AIAA Committee on Society and Aerospace Technology
37 year NASA career

http://pilotsfor911truth.org/core.html#Deets

Keep an eye out for an article we will be releasing on the Aircraft speed topic in the near future. Probably later today.

[wstutt]

I now have version 1.8 of my AAL77 FDR Decoder available on my web site along with new output files.

I have removed unnecessary trailing zeroes after the decimal point for some parameters.

I have also added some new parameters.

You can read further notes on the new parameters here.

Warren.

[wstutt]

I now believe that the reason that the NTSB didn't decode the last 4 seconds of data from the AAL77 FDR was due to a bug in the ROSE software provided by L3 Communications, the manufacturer of the FDR. More details are on my web site here.

Warren.

[rob balsamo]

From your page:

"I reported my findings to the L3 Communications Aviation Recorders division. They replied that version 3.6a was not the latest version of the ROSE software. Unfortunately, they also said that they were not willing to investigate my findings further, but would do so at the request of an accident investigation office."

Was version 3.6a the "latest version" in Sept 2001 - Feb 2002 when the NTSB decoded the data?

[wstutt]

From your page:

"I reported my findings to the L3 Communications Aviation Recorders division. They replied that version 3.6a was not the latest version of the ROSE software. Unfortunately, they also said that they were not willing to investigate my findings further, but would do so at the request of an accident investigation office."

Was version 3.6a the "latest version" in Sept 2001 - Feb 2002 when the NTSB decoded the data?

Hi Rob,

The most recent files in the ROSE 3.6a setup are dated 22 April 2004, so it would appear to be more recent than the version that the NTSB used.

Warren.

[rob balsamo]

Hi Rob,

The most recent files in the ROSE 3.6a setup are dated 22 April 2004, so it would appear to be more recent than the version that the NTSB used.

Warren.

So if it's not the same version they used, and you "believe" there to be a bug in version 3.6a, what is the point of your inquiry?

That earlier versions also have some sort of "bug"?

Also, reading through your letter to the NTSB, I don't think you'll get much of a response after admitting you produced a modified file with your own created software.

Did you send them a copy of your software as well?

The 71.5 degree AOA is also very interesting.

I was going over your Parameters page again the other night when you posted the update above. We briefly talked about this before, but did you notice how many times you needed to use the Generic 757 DFL in lieu of the custom made American Airlines DFL? You thought the custom made DFL made non-nonsensical values.

There is a reason American Airlines has different formula's for their aircraft and why they make a custom made DFL.

So, the question becomes, if N644AA caused the damage at the Pentagon, and in fact was an AAL aircraft, with an FDR programmed to AAL standards, why wasnt the AAL custom DFL able to decode the entire file?

Hmmmm......

Did you figure out why the altitude has different values when using 757-3b_1.txt yet? (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/wink.gif)

Looking forward to the Legge paper. When is it coming out?

[wstutt]

So if it's not the same version they used, and you "believe" there to be a bug in version 3.6a, what is the point of your inquiry?

That earlier versions also have some sort of "bug"?

Yes, and that the current version may still have the bug. Even if the bug has since been fixed, it still could have affected earlier decodes by the NTSB.

Also, reading through your letter to the NTSB, I don't think you'll get much of a response after admitting you produced a modified file with your own created software.

I gave them a copy of the original unmodified file as well. What would you suggest?

Did you send them a copy of your software as well?

No. Would you suggest sending the executable only or the source code as well?

The 71.5 degree AOA is also very interesting.

I was going over your Parameters page again the other night when you posted the update above. We briefly talked about this before, but did you notice how many times you needed to use the Generic 757 DFL in lieu of the custom made American Airlines DFL? You thought the custom made DFL made non-nonsensical values.

There is a reason American Airlines has different formula's for their aircraft and why they make a custom made DFL.

So, the question becomes, if N644AA caused the damage at the Pentagon, and in fact was an AAL aircraft, with an FDR programmed to AAL standards, why wasnt the AAL custom DFL able to decode the entire file?

Hmmmm......

Did you figure out why the altitude has different values when using 757-3b_1.txt yet? (IMG:http://pilotsfor911truth.org/forum/style_emoticons/default/wink.gif)

Sure, it uses a different formula. If you graph it though, you see sudden jumps that you don't get with the formula from the generic 757 DFL. That's why I believe the formula in the generic 757 DFL is the correct one to use for this parameter.

I would also have thought that the AAL custom DFL would have always been the correct one to use, but it didn't always turn out to be the case.

Looking forward to the Legge paper. When is it coming out?

It's still under peer review.

Warren.

[rob balsamo]

Yes, and that the current version may still have the bug. Even if the bug has since been fixed, it still could have affected earlier decodes by the NTSB.

Your assertion of a "bug" is based on your "belief". This is an argument from incredulity and speculation.

Some people still "believe" in the Easter Bunny, but that doesn't mean he exists.

I gave them a copy of the original unmodified file as well.

Yes, they already have that. The point being that you also gave them a modified file which you admit having been modified with a program you designed which you did not give them.

I would also have thought that the AAL custom DFL would have always been the correct one to use, but it didn't always turn out to be the case.

It is the correct one to use, for an American Airlines airplane. That is why American Airlines made it.

It's still under peer review.

Warren.

His "peers"...? ...or someone who actually knows something about aviation...

His last "paper" also was claimed to go through "peer review" but needed 8 revisions after being reviewed by someone with actual expertise. It still needs at least 5 more revisions.

If my email exchanges with Frank are any indication, this new 'paper' will suffer the same fate.

You should really tell him to remove the CWS nonsense from his last paper, all it is doing is getting some good laughs from real pilots.

[wstutt]

Your assertion of a "bug" is based on your "belief". This is an argument from incredulity and speculation.

Some people still "believe" in the Easter Bunny, but that doesn't mean he exists.

Hi Rob,

Did you look at the evidence I gave for my belief that a bug exists in this version of the ROSE software?

Yes, they already have that. The point being that you also gave them a modified file which you admit having been modified with a program you designed which you did not give them.

They may not necessarily have the decompressed file in the format of the one I gave them since ROSE can export to files in many formats. What do you think they would do with the program if they did have it? I'll give it to them if they ask for it.

It is the correct one to use, for an American Airlines airplane. That is why American Airlines made it.

<snip>

Here is a graph showing altitudes calculated as per the two data frame layouts during part of the takeoff: (IMG:http://warrenstutt.com/General%20Images/Altitudes%20of%20Different%20Data%20Frame%20Layouts.jpg)
Which one looks most sensible to you?

Warren.

[rob balsamo]

Hi Warren.

Hi Rob,

Did you look at the evidence I gave for my belief that a bug exists in this version of the ROSE software?

I did, and it is not compelling. Namely due to the fact that you admit the NTSB used a different version of the software than the one you claim has a "bug".

Do you really think the NTSB (or L3 Communications for that matter) would let such a "bug" go unnoticed for over 4 years? Omitting the most essential last seconds of flight? I suppose anything possible given the fact those who make excuse for the govt story scream from the roof tops it is all due to "Incompetence!", this is why I filled out a ASRS report last year, the moment I became aware of a possible grave situation in Flight Safety. Why did you wait so long?

With that said, your last 4 seconds from your admitted "modification", still do not add up to an impact.

They may not necessarily have the decompressed file in the format of the one I gave them since ROSE can export to files in many formats. What do you think they would do with the program if they did have it? I'll give it to them if they ask for it.

Why not give it to them before they ask for it? Because all they have now is a file which you admit you modified, and a file they are already familiar with. Why look any further into the one you admit you modified? I'm not saying they won't, but if someone sent me a file they admitted to modification, and I already have the original, I would find no need to look further and discard the inquiry.

Again, they have already been aware of your "last 4 seconds" since last year from my ASRS report. NTSB has shown precedent that they usually correct their errors in less than a year, if such errors exist.

Here is a graph showing altitudes calculated as per the two data frame layouts during part of the takeoff:
Which one looks most sensible to you?

Warren.

Of course they are different. There is a reason for that.


Again Warren, there is a reason why American Airlines custom made their own DFL. As you agree, it should work for an American Airlines aircraft. There is a reason American Airlines has a different formula for their altitude data.

In other words Warren, this is further evidence that the FDR data is not from N644AA, it certainly does not lend to positive identification.

Anytime you wish to address my concerns regarding Legge, feel free.

[wstutt]

Hi Rob,

Hi Warren.

I did, and it is not compelling. Namely due to the fact that you admit the NTSB used a different version of the software than the one you claim has a "bug".

It would have been a different version, however it appears to have the same bug.

Do you really think the NTSB (or L3 Communications for that matter) would let such a "bug" go unnoticed for over 4 years? Omitting the most essential last seconds of flight? I suppose anything possible given the fact those who make excuse for the govt story scream from the roof tops it is all due to "Incompetence!", this is why I filled out a ASRS report last year, the moment I became aware of a possible grave situation in Flight Safety. Why did you wait so long?

I brought the bug to the attention of L3 Communications so they can fix it. It may not show up on every decode. At the time you filed your ASRS report, I did not have the decompressed file from the ROSE software. Now that I do, I have gained insight as to why I was able to decode more data from the FDR than the NTSB.

With that said, your last 4 seconds from your admitted "modification", still do not add up to an impact.

Is the "last 4 seconds" you refer to from the CSV files on my web site? They are generated by my AAL77 FDR Decoder which does not use this modified file. It reads the raw FDR file provided by the NTSB.

Why not give it to them before they ask for it? Because all they have now is a file which you admit you modified, and a file they are already familiar with. Why look any further into the one you admit you modified? I'm not saying they won't, but if someone sent me a file they admitted to modification, and I already have the original, I would find no need to look further and discard the inquiry.

What would they do with the program? Run it and produce the same modified file? Did you look at the original unmodified raw FDR file from the NTSB which was used to modify the binary file produced by ROSE?

I also sent the NTSB a CSV file from my AAL77 FDR Decoder so they can compare it with their CSV file. You've looked at both of them.

Again, they have already been aware of your "last 4 seconds" since last year from my ASRS report. NTSB has shown precedent that they usually correct their errors in less than a year, if such errors exist.

Have they said they found no such error?

Of course they are different. There is a reason for that.


Again Warren, there is a reason why American Airlines custom made their own DFL. As you agree, it should work for an American Airlines aircraft. There is a reason American Airlines has a different formula for their altitude data.

In other words Warren, this is further evidence that the FDR data is not from N644AA, it certainly does not lend to positive identification.

The Pressure Altitude is not the only thing wrong with the AAL77 DFL. For example, according to AAL77 DFL, S/F CYCLE COUNT 0 is in all Frames, but S/F CYCLE COUNT 1 is in Frame 1. S/F CYCLE COUNT 2 to S/F CYCLE COUNT 15 follow the same pattern.

Anytime you wish to address my concerns regarding Legge, feel free.

I'll let him speak for himself if he so chooses.

Warren.