Help - Search - Members - Calendar
Full Version: United 93 Csv File Download
Pilots For 9/11 Truth Forum > Flight Number > United 93
rob balsamo
Edit to Add: Dec 17, 2007 UA93 CSV Files

We are now in possession of above files. We are currently analyzing the same. So far from what i have seen, it doesnt look good for the govt story (as usual), nor does it look too good for those who make the excuse that altimeter lag was a factor on a 757 flying 'outside the envelope'.

Just a tease for now... more information will be forthcoming...

Cover letter page 1 of many....

Jan 15, 2008 edit to add:
This is great news Rob. Can't wait for the rest. cheers.gif
Same here!

QUOTE (johndoeX @ Apr 12 2007, 07:23 PM)
We are now in possession of above files. We are currently analyzing the same. So far from what i have seen, it doesnt look good for the govt story (as usual), nor does it look too good for those who make the excuse that altimeter lag was a factor on a 757 flying 'outside the envelope'.

Somehow I knew you were going to say that! wink.gif
QUOTE (johndoeX @ Apr 12 2007, 07:23 PM)
altimeter lag was a factor on a 757 flying 'outside the envelope'.

Could you translate that for those of us who don't speak 'pilot'? blink.gif
Yeah Rob, keep up the good work. cheers.gif
rob balsamo
Is it possible to tell at this stage how much (if any) of the recorded flight time is present and correct/missing/suspect?
Remember again, there are TWO distinct seperate data sets here.
One is the animated representation, the other is the text CSV read out.
So it's important to always denote which you are talking/asking about, if not both. smile.gif

In the CSV, Two sensors stop recording at 2 minutes and 3 minutes before the end of time in the readout file.

One has to do with the internal plumbing, and the other with a control surface (aileron to be exact there).

It is extremely suspect. There is a lot to go over though, but so far it doesn't look good (again) for the official story in my opinion.

Others have told me to calm down, so that's what I'm trying to do. biggrin.gif

Thanks very much to everyone.
rob balsamo
added csv file download to original post...

Is there a timestamp "offset" that needs to be accounted for in the UA93 data? I heard that there is a ~24 second discrepancy in the AA77 FDR and RADES data from what Tume told me.

Thanks again Rob! cheers.gif
QUOTE (dMole @ Dec 17 2007, 05:51 PM)
I heard that there is a ~24 second discrepancy in the AA77 FDR and RADES data from what Tume told me.

Haha. The Farmer strikes at common knowledge with his Final Mystery.

I would not worry about that 'discrepancy' at the moment.
Thanks UT for the clarification.

To avoid any aspersions being cast against Tume, let me clarify that Tume was merely informing me of a potential pitfall based upon the information that the Farmer had provided to Tume, I believe. Obviously, 25 seconds at aircraft speeds can make some HUGE differences in position and collisions...

So is it reasonable then to proceed with the AA77 and UA93 FDR data "as is" similar to GPS timestamps? vacuum.gif
rob balsamo

The NTSB plotted AA77 one second away from the pentagon wall. The DME data confirms it.

The NTSB plotted the UA93 data within feet of ground elevation at impact. The altimeter confirms it, which by the way, crushes those who use the altimeter lag argument for AA77 being 400 feet too high considering UA93 rate of descent was almost 6 times as much at impact... according to the data.

The "25 seconds" difference doesnt matter much when we can confirm position based on the data. The "6 seconds missing" argument is complete hogwash based on what i have described above.
For anyone investigating the FDR data allegedly from UA93's crash site- a word of caution on timestamps.

I have found 3 different data sampling rates in the 4 .CSV files in "". The "A to E" and "M to T" data files were apparently sampled at 2 Hz (or 2 times per second, or 0.50 second intervals). The "F to L" data file was sampled at 4 Hz (or 0.25 second intervals). Finally, the "U to Z" data file was sampled at 8 Hz (or 0.125 second intervals).

This could create some minor hassle when trying to graph data columns from different timebases/data files, but there is a relatively easy work-around in MS Excel using time addition and conversion functions.

It appears to have been a peculiarly "wild" ride from my early investigations of this data set.
rob balsamo
Different parameters have different sampling rates. I dont think its exclusive to file creation.

For instance, Altitude recording is 1hz, while pitch/roll angles are 4hz and G loads are 8hz (IIRC).

Hope this helps...
I post the same question on the other topic too biggrin.gif

Hi, great forum this!!!

I was looking for a topic like this.

About the CVR of the UA93.



What the family members heard:
On April 18, 2002 family members were finally allowed to listen to the cockpit voice recorder. “The FBI initially declined to play the tape, saying it was too disturbing, and it was evidence that might be used in criminal prosecutions related to the attacks of September 11.” (Among the Heroes, p. 374). The family members were “forbidden from recording the tape or from taking notes” (p. 375).


9/11 commission report says:

UA175: CVR Destroyed
AA11: CVR Destroyed
AA77: CVR Found but "Not Readable"
UA93: CVR found/Readable

for the UA93,
I would like to know:
How much was readable the CVR?
Is it possibe that somebody had manipulated it?
Can you tell with sureness that the CVR data recording is 100% correct?
Is it possible to have the timeline of what the UA93 CVR says?

thank you very much
QUOTE (johndoeX @ Apr 12 2007, 07:23 PM)
Edit to Add: Dec 17, 2007 UA93 CSV Files


I just noticed that the CSV files mentioned above (the first message in this topic) are comma quote delimited whereas the CSV files from the CD provided by the NTSB available here mentioned in this topic which have identical contents to the CSV files on the CD available here are comma delimited without the quotes around the text values.

I have not checked to see whether there are any more important differences.

rob balsamo
Not sure what that means as im not an excel expert... but ok.

Either way, the files available here are directly from the NTSB via the FOIA, sent to yours truly... cover letter is included in original post.
Hi Rob,

I've looked at the files further and I can see some differences in the numbers when I open the files in Excel.

The files have the same names so I found that I needed to rename one or both of them to get Excel to open them even though they were in different folders.

When I had a look at the files DCA01MA065_tabAtoE.csv in Excel for example, I could see in columns DO and DP (CONTROL COLUMN POSN-CAPT (DEG) and CONTROL WHEEL POSN-CAPT (DEG)) that the numbers in the columns are slightly different, -0.308 compared to -0.31 for example.

I haven't looked to see if there are any more significant differences in the numbers.

I suspect the NTSB has been sending out slightly different versions of the files to different people. I also recall some discussion that I didn't read closely about different modification dates on files that should be the same on the CDs received by different people from the NTSB.

rob balsamo
Thanks Warren,

Thats interesting (although not surprising).... keep us posted if you find more conflicts between files.

Also, i noticed.... is it possible that your spreadsheet is set to 2 decimal places on one file and set to 3 on another? Again, i dont know much about Excel, however, the conflict you describe above looks like a rounding up.
Hi Warren,

There should be two toolbar buttons for "increase decimal" and "decrease decimal" in Excel (just left of the "increase indent" and "decrease indent" buttons, unless that toolbar is turned off in options).

If the cells are text-formatted, you might need to click to highlight the appropriate column and then right click, format cells, [as Number], and adjust the decimal places. (Sorry Mac users, you're on your own with that single mouse button- not my department). There should be a way to strip the double quotes when importing the CSV into Excel, but I didn't see double quotes in the data of either ISO (they usually make things very messy in spreadsheets). Were the double quotes in the column headings maybe?

I saw ".308" in column "DO" of both of the ISO files linked that I just downloaded again. If you look at the very top line (above the column letter headings, but below the toolbar), you should see the "raw" cell contents or formula, regardless of Excel's format and display settings.

Strangely enough, the ISO gave me a "read only, locked by another user" error message that the other ISO did not when opening the "A to E.csv" files. This is a common error when working on a network-server spreadsheet (which I'm not supposed to be here :ph43r: ) My virus scanners didn't bark about Excel macros either- strange.

Usually a CSV file doesn't have the control and formatting codes that an XLS file does- I dunno. You'll probably want to save your work as XLS file type to save all the formatting (and I put the graphs in the XLS file too).

I still haven't found my AA77 FDR radar altitude data column yet, but I've been tracking NYC "rodents" this week. I'll try to compare the various FDR files for velocity (since I have USAF 84 RADES radar data for all 4 flights- that should be linked in the UA175 "mach" thread around page 24). You might want to look at the acceleration data for UA93- it is pretty strange. Pandora's Black Box 3 is a great jump-start.

I've got about 2 decades of experience with spreadsheets, going back to the old Lotus days. If you want to pick my brain a little, let me know.

I'll advise if I find some more discrepancies, but I think the FDR team's excellent work and our RADES work has pretty well sunk the OCT. That boat simply won't float.
rob balsamo
QUOTE (dMole @ Jan 25 2008, 09:48 AM)
I still haven't found my AA77 FDR radar altitude data column yet,

Hey d,

The Radar Alt for AA77 is in Read-Out2 from the raw file decode. The NTSB omitted the RadAlt from the original csv files, but it was included in the raw file. One can only speculate why they did this, but in my opinion its due to the fact the RadAlt also shows too high further confirming Baro Alt.

Interesting to note, the NTSB omitted lat/long and RadAlt from the UA93 files.
Hi dMole and Rob,

I understand what you are saying about that Excel could be set to display the numbers to different fixed decimal places, however I have written a C# program to compare the files and it shows that the numbers are slightly different in some columns.

I found the contents of the CSV files in the ISO images to be byte by byte identical with each other but with slight differences from Rob's CSV files.

Excel does automatically strip the quotes if they are present when it imports the file so the quotes are not likely to make any difference to anybody in practice.

Here are the columns that I found were different (this results file is in CSV format):

File Name,Column Name,Largest Difference

As you can see the differences only occur in the third place after the decimal point so the differences will probably not make any difference to anybody however it would depend on how accurate the numbers are presumed to be.

Thanks Warren,

C-sharp, huh? I knew 2 of his grandfathers and an OOP uncle of his. wink.gif I've got a book on C-# and compilers but not the time to delve into it.

I looked at the data measurement units in my data files.

"AtoE" columns DO & DP are control angle in degrees- I wouldn't worry much past the 1st decimal.
"AtoE" columns EX through FB are Engine EPR ratios and settings- I find it interesting, but most probably won't.

"FtoL" column N is Flap Handle Position in degrees- probably only interesting at takeoff and "conventional" landing.
"FtoL" column EN is Lateral Acceleration (in g)- same as below
"FtoL" column EW is Longitudial Acceleration (in g)- vertical acceleration is the most interesting one, and I'd stop at the 1st decimal place there.

"MtoT" column I is "MACH SELECTED-MAN"- (in mach number)- could be interesting, but I'll defer to the pilots here on operational details (I'm from science/engineering myself).
"MtoT" column BM is Rudder Pedal Position (in degrees)- again 1 decimal place.
"MtoT" columns CK & CL are Stator Vane Position (in inches)- engine related, and I only saw 2 decimal places in the data I scanned. I wouldn't worry about this one right now.

Full Authority Digital Engine Control (if you're interested)

"UtoZ" column O- aha, Vertical Acceleration (in g)- ranges from +4.15 to -1.89 in my file- probably 2 decimals needed. In case you're wondering, the -1.89 g vertical acceleration is "weightless, NASA Vomit Comet" kind of stuff.

Thanks for coding that program and combing the data- more eyes is nearly always a good thing. I was using the "early" NSTB file for AA77 that I got from P4T, and the recent UA93 CSV file to be found above.

I think you'll find the UA93 data is strange enough that a couple of decimal points won't make much difference (especially when compared against the USAF 84 RADES radar data).

I didn't mean to insult your Excel skills, but I've been asked more than once try to write for the laypersons too here.

Thanks again,
d thumbsup.gif
rob balsamo
If the files are slightly different, this should be of concern as they all should be identical coming from the NTSB... no?

Also, something to consider.... could the slight difference in bytes be due to the fact i zipped the files?
Hi dMole and Rob,
(from dMole)

I didn't mean to insult your Excel skills, but I've been asked more than once try to write for the laypersons too here.

Don't worry, no offence taken. You certainly had a valid consideration. smile.gif

In fact it appears to me that the NTSB are the ones who have been using different numbers of fixed decimal places.

(from Rob)

If the files are slightly different, this should be of concern as they all should be identical coming from the NTSB... no?

Well, I expected the files to be identical too. That's why I posted as soon as I found out that they weren't. On closer inspection and in light of dMole's comments, I am now happy that the differences are real but not significant.

Also, something to consider.... could the slight difference in bytes be due to the fact i zipped the files?

Definitely not. The zipped files are restored with identical contents when they are unzipped.

rob balsamo
Actually.. come to think of it... the files above are the first files i received from Mick Harrison (see first cover letter above). I havent even used the files i received through my later FOIA request (see second cover letter above). I'll post the files i received when i get some time and fire up the other pc if you guys want to compare those files as well....

Even though the differences arent "significant", just being "different" should be significant in itself i would think. Mainly due to the fact they are all supposed to be identical. What would cause the differences?

Edit to add:

I went ahead and fired up the other pc to get these online before i forget....

I just ripped these files directly from the NTSB CD-ROM they sent me and uploaded them to the server. The only thing i did to them was zip them up. I didnt even rename the folder. Let me know if these are any different.
Hi Rob,

Even though the differences arent "significant", just being "different" should be significant in itself i would think. Mainly due to the fact they are all supposed to be identical. What would cause the differences?

By "not significant" I meant that the numeric values would be unlikely to change anybodies interpretation of the events recorded in the files. e.g. I am presuming whether the vertical acceleration is 0.005 G's more or 0.005 G's less would not really mean anything as suggested by dMole.

I do agree with you that I find the fact that the files are not completely identical is odd. Is it possible that Mick Harrison inadvertently loaded then saved the files? That may account for the differences. Otherwise, perhaps the NTSB ran the software that generates the CSV files more than once with different settings as to the number of fixed decimal places to be generated.

I found that the files in your last reply have identical contents when I did a byte by byte compare to the files in the ISO images I linked to however the modification dates on the files are different. That makes three sets of CSV files for UA93 that I am aware of that have identical contents but different modification dates. Then of course there is the set of files you received from Mick Harrison that have similar but not identical contents.

The 2 immediate causes of the data differences I can see are

1. Degradation of the magnetic FDR media- time, oxidation, electromagnetic fields, rough "landing", humidity, etc.
2. Different computers used to decode the binary data- differences in CPU and FPU, I/O chips and driver hardware, flaky/"noisy" communication cables used.

Magnetic hysteresis (in the storage media sense) is probably not something most want to jump into right away.

Then there's the obvious possibility- bogus data being distributed/created by NTSB (and also USAF 84 RADES radar "data"). I don't think the public has seen any FAA radar data yet (if it still exists).

If bogus, then they got these 2 UA93 FDR versions awfully close. In the digital age, I'm not sure why they wouldn't be identical data sets if copied from one FDR tape read. If 2 or more FDR magnetic tape reads, then you can get this kind of "data drift" or worse- lost data.

We might need an FDR data traceability thread for both AA77 and UA93 with file dates, sizes, times, etc. The NTSB is a common "source" of the data, so maybe these 2 (or more) data streams should be looked at as parts of an FOIA whole (esp. in the OCT sense).

Or not... dunno.gif
rob balsamo
Keep in mind, both FDR's are reportedly Solid State, no magnetic tape.

They are also time limited items that must be checked, replaced, refurbished, within a certain amount of time... I forget the regulation, but i think it might be a 12 month item.

As for "rough landing". FDR's are built to withstand an impact of 3,400 G's. I think it can handle a "rough landing" without skewing the data. thumbsup.gif

More on SSFDR's (PDF from L3)

All FDR's are tested prior to flight. Whether a self testing FDR or pilot tested during power-up checklist, if the FDR is malfunctioning, its replaced or the airplane doesnt leave the gate.
Hi Rob,

Good points- I've likely seen too many acronyms in my day, and forgot the "SS" part of "SSFDR". Digital data is not likely to drift, but bit corruption is still possible. Digital data is more likely to get "scrambled" (in the completely unreadable sense) or just disappear than analog data would be IMHO. Do we know how long the solid state circuits or batteries are supposed to last? I remember something about 20 days or so. It looks like the Boeing FDR rule change was on October 11, 1991:

Also the 3400g rating still makes me wonder how two 1g building collapses can vaporize at least 4 of SSCVR, SSFDR, FDR, and/or CVRs.

Was this an L3 Communications unit? I got the impression that it was ONLY A PORTION of a Honeywell SSFDR from the following:

There could possibly have been Allied Signal back then and also Smiths Industries from my research:
Item 55 on page 11

Thanks Rob,

P.S. is there a thread about all this same stuff for the AA77 SSFDR?
Hi dMole,

Was this an L3 Communications unit? I got the impression that it was ONLY A PORTION of a Honeywell SSFDR from the following:

I notice that the "MANUFACTURER CODE" field in the CSV files repeats the single value "Honeywell"

Hi Dmole!

Excuse me please!

I've read:

"...remote area microphone monitors and control panels for cockpit voice recorders"

Witch is the use for this instrument?
Hello Stuart,

I spent quite a while at the Honeywell website today. It looks like their SSFDR, SSCVR, Combi, and "microphone" all share one small "stock photo" orange prop with possibly different labels.

There wasn't much at Honeywell, even after signing up for their login page.


EDIT: A possible answer to my data lifetime question above from Honeywell's SSFDR page: "The SSFDR utilizes a modular crash survivable memory unit (CSMU) for protection of the solid-state flight data recording memory. The CSMU retains the most recent 25 hours of digital flight data and timing information."

I'm not certain if this means 25 hours worth of flight data kept indefinitely, or else data kept for 25 hours then lost, or something in between those.

Would you like to read what is wright here?

"The other controller also speculates that anyone knowledgeable enough to cut off the transponder might also have pulled the circuit breaker for the cockpit voice recorder in the so-called black box, deactivating it, to minimize information available to authorities."

it seems that the hijackers know very well the transponder use and his clues...

I can't believe this...

Is it possible that hijackers would tourned off the transponder for not leave to know the exactly position of where they were?

Evrybody have little notions in flyng theory know that when you have the transponder tourned off, on the radar you are an UFO...

Ando so you'll became a target for scramble jet immediately... in a normal situation!

It is strange that "tolk-back button" was accidentally enable from pilot or hijackers...

So, if i was the hijackers and I would like put the plane into the WTC, I leave the transponder tourned on and fake a mistake radio bad-function...

I have the time for to do what I want to do in twenty minutes, with the fear that an F-16 don't launch me an AIM 9 or, bad, an AIM 120 AMRAAM!!

I think that transponder utilizzation in 9/11 was in relation with the "home run" function...

So, we have clues in avry for CVR (also if CR 9/11 tell UA93 CVR was found and readble...)

For what Joe Vialls tells:

"Home run" take the plane via-transponder and immediately cut the cockpit communications channel...
Hello Stuart,

That is very good information that I had not seen before- thank you! It probably should go with the AA11 section, though.

I think Italian is your native language, so I looked around for your benefit (in native Americanized English wink.gif ). You may want to repost this same very good information on the AA11 thread at:

To divide the workload (especially to help the unfortunate administrators), there are a few people at P49T that specialize on certain flights, research subjects, or else certain "crash" locations. I research far and wide though.

Thank you again Stuart,
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2020 Invision Power Services, Inc.