This skin was created by Cortez of the IF Skin Zone modified by JDX
All views expressed in this forum are not necessarily the views of pilotsfor911truth.org
Please click on the banner to read the mission statement of pilotsfor911truth.org

zIFBoards - Free Forum Hosting
Free Forums. Reliable service with over 8 years of experience.

Learn More · Sign-up Now
Welcome to Pilots For Truth. We hope you enjoy your visit.


You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.


Join our community!


If you're already a member please log in to your account to access all of our features:

Name:   Password:


This Forum Is Now Read Only. New Forum Can Be Found Here. Thank You.


 

 Questions for Undertow and FDR.
awmatt
Posted: Jun 2 2007, 07:30 PM


Poster


Group: Members
Posts: 10
Member No.: 1,103
Joined: 2-June 07



Has anyone seen anything like this so far? Note how damaged the chassis is of the FDR, but the surface-mount itsy-bitsies on the inside are fresh and clean.

http://www.ntsb.gov/Events/2001/AA587/exhibits/241509.pdf

Not surprising how none of the 9/11 accidents are listed in their database:

http://www.ntsb.gov/Publictn/A_Acc1.htm

A 757-225 example that carries the Honeywell UFDR model 980-4100-DXN (not the same model as Flight 77):

http://tinyurl.com/27jw9t

Interesting document on TWA 800:

http://www.ntsb.gov/publictn/2000/AAR0003.pdf

Description of the hardware inside a modern, EEPROM-based FDR, which in this case held over 60 hours of data (some were over 80, depends on compression):

http://www.ntsb.gov/Events/2000/aa1420/Exh.../AA1420_10A.pdf

The L3 model FA2100 described above uses Huffman encoding, like this:

http://en.wikipedia.org/wiki/Huffman_coding

Note that Flight 77 had an L3 model FDR, as listed in the raw file, so it probably uses Huffman encoding. The FA2100 device records 768 bits per second of data, smaller after compression (not sure if Flight 77 had a FA2100 or not). I've seen that UnderTow has written similar to this in another forum, talking about data acquisition and time delays.

Huffman encoding is used on TI calculator games, which I've dabbled in before. The ZIP format uses Lempel-Ziv encoding, which is better but more complicated.

UnderTow, how far have you gotten on decoding the raw file?

Do we have the actual packet data placement diagram (which word, 1-12, has which bits for which of the listed values)? I'm having trouble finding this from NTSB, only a simple list comes up.

Do we know if the Huffman tree is decided on the fly or instead hard-coded by design of the FDR? Do we know any other details of the compression?

Do we know what the CUR_INDEX parameters refer to? As a side note, it seems unlikely and impossible! to shift the entire 24MB (exactly) of data each time a new piece is recorded. Therefore it must be written in a loop, and maybe CUR_INDEX tells where the "international date line in megabytes" so to speak is sitting.

- Arthur pilotfly.gif
Top
johndoeX
Posted: Jun 2 2007, 09:57 PM


LGA Patriot
Group Icon

Group: Admin
Posts: 4,430
Member No.: 1
Joined: 13-August 06



Hi Authur,

Welcome to the fourms...

The Raw Data has been decoded and can be found here...
http://z9.invisionfree.com/Pilots_For_Trut...?showtopic=4574

Analysis of Raw Data Radar Altitude can be found here...
http://z9.invisionfree.com/Pilots_For_Trut...?showtopic=4801

Undertow will have to answer your other questions...

Hope you dont mind that i split your post into a new topic...

Once again.. Welcome!

Rob
Top
awmatt
Posted: Jun 3 2007, 01:10 PM


Poster


Group: Members
Posts: 10
Member No.: 1,103
Joined: 2-June 07



Ya I wondered why it moved? That confused me so much. We have PMs going too, he's just a bit busy now.

Loved snowygrouch's presentation. That actually answered a lot of my questions and now makes some of my post obsolete.

- Arthur

P.S.: Why does everyone have trouble spelling my name?

This post has been edited by awmatt on Jun 3 2007, 01:10 PM
Top
johndoeX
Posted: Jun 3 2007, 02:40 PM


LGA Patriot
Group Icon

Group: Admin
Posts: 4,430
Member No.: 1
Joined: 13-August 06



QUOTE (awmatt @ Jun 3 2007, 02:10 PM)


- Arthur

P.S.: Why does everyone have trouble spelling my name?

My apologies my friend... and to top it off, i have an uncle named Arthur! Could never spell his name correctly..


smile.gif
Top
UnderTow
Posted: Jun 4 2007, 03:21 PM


Extreme Poster
Group Icon

Group: Admin
Posts: 1,228
Member No.: 19
Joined: 28-August 06



QUOTE (Arthur)

I read the file http://www.aa77fdr.com/ReadOut2Personal.html. I presume this was written by you.
It says the radio altitude was 273 feet at the "end" of recording, and no impact was shown.
What could have possibly happened in that case, i.e. why did the recording stop then?
What was the last recorded time that you saw in the expensive software package; was it the same as that in the CSV file and/or animation?
Is there any "official" explanation for why the FDR stopped early, and the plane was still quite high?


Yes, aa77fdr.com is my page. I have a long history with this file and data.
I spent several months trying to get another readout of the raw file done. That link is my quick recap of what happened when I finally did get one done. However, I am still hopeful that a full examination be performed. The readout I achieved was very good, but not up to full investigation standards.
I would say that reverse engineering the raw zip, or the uncompressed raw data, is a nearly impossible task imho.

The question of what is the last recorded bit is still open. Remember, my 2nd Readout was of whole complete subframes only.

The full tabular readout and numbers are there for anyone to compute with, it won't add up to either the official story, or the ntsb animation. And only aligns with the official ntsb readout in some cases, not others.

When reading other people's excuses for all these problems keep in mind that anything about the equipment, the airplane, the data, and like has NOTHING to do with 9/11 and should be as-is with any other incident in the Aviation Industry whether Civilian or Military.

For instance, prior to full digital storage for flight data, the Maximum Time that could be lost by a Tape based recorder is 1.2 Seconds.
Not including destruction of the media. But from power loss or impact etc..
This 1.2 Seconds is undeniable, hard, and a studied fact done by the Safety Industry.

With the engineering of digitial data storage, do you think they actually Increased this error margin. Does anyone actually think that these systems allow for greater then 1 second of possible lost data? That is a fricking conspiracy right there and a full investigation should commence. (afterall, L3 provides FDR's for the military as well, some helo's and jet's even use the FA2100).

Here it is. The data is what the data is. People can flex it, pull it, and strecth it. But it won't fit. For the Official Story and Official Timeline it won't fit and never will.

Personally, I think because it's a gludge. The data doesn't fit becuase it didn't happen like we are told. Period.

-UT
undertow@aa77fdr.com
Top
awmatt
Posted: Jun 4 2007, 11:43 PM


Poster


Group: Members
Posts: 10
Member No.: 1,103
Joined: 2-June 07



Thanks for the replies. Many of my questions are answered.

Any details about the file format would be appreciated, so we don't unnecessarily tread the same path. Any details at all, no matter how big nor small.

I recently reverse-engineered a Java platform for currency trading and made my own multi-platform program from scratch that automatically traded for me, and contained a simulator and optimizer for the trading robots. I had no source code to work from, and much of the network information was encoded within the Java platform with 308/309-digit numbers to modern encryption standards (mod-pow technique). Because of this I could not totally decipher the packets with a network analyzer; instead, I had to rely on the horribly-written class-oriented Java code with few real variable names (sometimes as many as five different things were all named "a" in the same file). This took about a year to complete. I also put a simple Internet browser on my TI-86 graphing calculator when I was 13, and a grayscale, zoomable GPS navigation map on my TI-89 two or three years later. All of these projects require skills related to the .FDR file format. Not bragging, but "impossible" is subjective - as long as you have the time.

Thanks again, all. Good work.

- Arthur
Top
UnderTow
Posted: Jun 5 2007, 01:22 PM


Extreme Poster
Group Icon

Group: Admin
Posts: 1,228
Member No.: 19
Joined: 28-August 06



There are several steps you would have to go through.
First is the L3 property packaging which makes the actual .fdr file. Could be Huffman, but most likely there is more to it. A lot of the details are based on standards published and purchasable through ARINC. L3 is free to build on top of those specs as well, as long as they don't violate them or the certification tests.

This would ideally result in a straight binary file of just the recorded parameters. But most likely there would be bit padding on each parameter, sub-frame, or any, all or partial binary groups that would need to be evaluated prior to seeing one parameter (in binary).

Once that is done, you take the resulting binary, find the frame markers, and begin translating the bin groups to engineering units using the data layout and computations.


The really funny (or not) thing is... for anyone 'in the industry' this whole process described above takes zero effort, zero time, and zero skill. Completely residing in tested and proven systems in place for over 20 years. ie the computer and software program. It took me longer to type this then what it would take for anyone to do another read out and tell the world what the last bit recorded was.



Top
awmatt
Posted: Jun 5 2007, 01:48 PM


Poster


Group: Members
Posts: 10
Member No.: 1,103
Joined: 2-June 07



Do you have any diagrams, subframe layouts, relevant documents, or any other details? PMs are fine, and I understand if you're busy - I've got too much to do too.

- Arthur
Top
UnderTow
Posted: Jun 6 2007, 02:37 PM


Extreme Poster
Group Icon

Group: Admin
Posts: 1,228
Member No.: 19
Joined: 28-August 06



Arthur,
In your efforts, all you need is this trimmed version of the frame layout.

573b.Short.txt

This along with the CSV ReadOut2 should be enough to determine if you successfully extracted the data.

Again, feel free to email me with any questions/progress/comments as well.

Thanks
Top
awmatt
Posted: Jun 6 2007, 02:50 PM


Poster


Group: Members
Posts: 10
Member No.: 1,103
Joined: 2-June 07



Thank you!
Top
wstutt
Posted: Feb 16 2008, 01:19 AM


Poster


Group: Members
Posts: 14
Member No.: 2,603
Joined: 27-December 07



Hi UnderTow,

QUOTE (UnderTow @ Jun 7 2007, 08:37 AM)
Arthur,
In your efforts, all you need is this trimmed version of the frame layout.

573b.Short.txt


In the frame layout, I notice that the parameter assignments for the PRES POSN parameters are listed twice, but with different port names. Because the parameters have different port names, I believe they are actually latitude/longitude values from different sources.

I notice that port FMC L/R-D-4 is the same one listed for the GPS time parameters, so I presume that that set of latitude/longitude values are from the GPS. I presume the set of latitude/longitude values for the port IRU L-A-3 come from a different source that is not the GPS - perhaps an inertial system?

According to the NTSB's report on the FDR, the FMC L/R-D-4 values are in the list of "Parameters Plotted" (values included in their CSV files) whereas the IRU L-A-3 values are in the list of "Parameters Not Working Or Unconfirmed" (values not included in their CSV files). This also leads me to believe that there are two sets of latitude/longitude values which are different and recorded separately.

I see that according to your frame layout, the two different sets of latitude/longitude values are recorded in the same locations in every subframe. Is there a mistake?

I could also only find one set of latitude/longitude values in ReadOut2.

If there are two sets of latitude/longitude values, I would be interested in comparing them.

Warren.
Top
dMole
Posted: Feb 16 2008, 04:21 AM


Very Active Poster


Group: Members
Posts: 306
Member No.: 2,294
Joined: 1-October 07



QUOTE (wstutt @ Feb 15 2008, 11:19 PM)
I could also only find one set of latitude/longitude values in ReadOut2.

If there are two sets of latitude/longitude values, I would be interested in comparing them.

Hi Warren,

Do you like canned worms or something? wink.gif I also only located one set of lat/lon data in the "a77.2_complete.csv" file. I just compared this to my USAF 84 RADES data, and was VERY surprised to find the latitudes and longitudes very nearly on top of each other (excellent data agreement). Height is a different matter, especially with the ModeC radar transponder being turned off at 08:50:38 and big data gaps in the RADES data. It looks like AA77 took off "wheels up" very near 08:20 EDT.

Latitude chart
http://www.orbitfiles.com/download/id2571344146.html

Longitude chart
http://www.orbitfiles.com/download/id2571345304.html

Newest AA77 FDR/RADES Height chart (simpler, without velocities)
http://www.orbitfiles.com/download/id2571346839.html

A little about primary and secondary radar (there should be some RADES info near the bottom- it started out in the UA175 section):
http://z9.invisionfree.com/Pilots_For_Trut...dpost&p=9911143

About "ModeC" Secondary Radar:
http://z9.invisionfree.com/Pilots_For_Trut...post&p=10658379

If that @#$% file server goes down again, I can try to email you the files. The original RADES data .XLS from the CD should be available zipped at:
http://www.orbitfiles.com/download/id2392699235.html

Hope this helps,
d

EDIT: That RADES spreadsheet will likely tick your system clock, so save a "working copy" with your charts. I think the RADES forum was taken down- see the UA175 "mach" thread for details- but it's about 25 pages long... If you need the RADES readme.doc let me know (but I don't have the CD with me tonight).

This post has been edited by dMole on Feb 16 2008, 05:36 AM
Top
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:
« Next Oldest | American 77 | Next Newest »
zIFBoards - Free Forum Hosting
Free Forums. Reliable service with over 8 years of experience.
Learn More · Register Now

Topic Options












Hosted for free by zIFBoards* (Terms of Use: Updated 2/10/2010) | Powered by Invision Power Board v1.3 Final © 2003 IPS, Inc.
Page creation time: 0.0366 seconds · Archive