• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

AA77 FDR Data, Explained

I'll be glad to share that information with you. I believe very strongly, as any Constitution-respecting patriot would, in sharing vital information like this. It's all on my debunking DVD "You opened a can of worms, I opened a can of whup-ass," which is only $18.95, and which includes a bonus DVD of Rob Balsamo's Greatest Threats and Boffo Bannings. Payment is by PayPal or postal money order. Please add $8.49 for shipping and handling.
 
Last edited:
I'll pay $200 for the early release autographed edition. I mean I'll donate $200 if you give it to me for free.
 
MarcoPolo,

The poster you are dealing with is Rob Balasmo aka JohnDoeX aka JDX. He is the "head" of pilots for 911 truth. The posts are his copy/pasting to you are his own that he has pasted all over the internet in an attempt to get more attention. It may seem like he is quoting other people, but he's not. It's him. It's all him. Please do not be fooled that this is some professional operation and you are dealing with some member with varied resources and expertise at his disposal. It's a single very disturbed individual.

You aren't the first person to be hit with this copy&paste gibberish and you won't be the last. This man is a habitual liar and a coward and he -will- draw you into the longest and most pointless debate rife with logical fallacy, scientific incompetence, and threats of physical harm. He doesn't care about debate and I'm fairly certain that all he wants is attention to sell DVDs. That's only explanation for why he has continued to repeat the same tired lies, bouncing from website to website. His only goal is self-promotion. QUOTE]

As many of us have found out, myself included.
 
MarcoPolo,

The poster you are dealing with is Rob Balasmo aka JohnDoeX aka JDX. He is the "head" of pilots for 911 truth. The posts are his copy/pasting to you are his own that he has pasted all over the internet in an attempt to get more attention. It may seem like he is quoting other people, but he's not. It's him. It's all him. Please do not be fooled that this is some professional operation and you are dealing with some member with varied resources and expertise at his disposal. It's a single very disturbed individual.

You aren't the first person to be hit with this copy&paste gibberish and you won't be the last. This man is a habitual liar and a coward and he -will- draw you into the longest and most pointless debate rife with logical fallacy, scientific incompetence, and threats of physical harm. He doesn't care about debate and I'm fairly certain that all he wants is attention to sell DVDs. That's only explanation for why he has continued to repeat the same tired lies, bouncing from website to website. His only goal is self-promotion.

As many of us have found out, myself included.


Are you guys saying that Rob Balasmo is also UnderTow and Snowygrouch, and the only way to find out the thrilling conclusion to this saga is to buy a DVD from the P4T?
 
Are you guys saying that Rob Balasmo is also UnderTow and Snowygrouch, and the only way to find out the thrilling conclusion to this saga is to buy a DVD from the P4T?

Don't forget to buy the PfT mug so you can drink your Kool Aid. Or the BBQ apron so you can look oh so stylish grilling burgers.
 
Are you guys saying that Rob Balasmo is also UnderTow and Snowygrouch, and the only way to find out the thrilling conclusion to this saga is to buy a DVD from the P4T?
Undertow is not Balsamo. I think he's the guy that did the actual "decoding" of the FDR since Rob has no idea and wouldn't know heads from tails. I think he used to post at the old lcf and perhaps his identity is even known. No biggie.

Snowygrouch was a one time poster (joined Jan 4th and made 4 posts that day) with nothing since. He was probably a Rob sock.
 
As for the cast of characters, I'm fairly certain the UnderTow, JDX/Rob, and snowygrouch are all different people.

Snowygrouch, I believe, is Callum Douglas.

1. Did Snowygrouch ever complete his analysis of the raw data?

Sort of. I'm pretty sure he is Callum Douglas and he has given "talks" at conferences and some such. No whitepapers or anything else that I would consider "analysis". Mostly DVD filler material, as best as I can tell.

You can find youtube videos of it, I think.

2. If so, did it match up with what Anti-sophist was saying?
3. If not, is there an explanation?
I forget the conversation specifics so you'd need to be more specific. Callum's "presentations" contained largely identical claims as JDX has made repeatedly and I didn't find anything in them of any interest.

I might have missed something.

4. Did the raw data ever get shared and the original analysis duplicated?
To my knowledge, no. I've had several people PM me offering a data frame-layout so that I could verify their decodings. I've turned down all of those offers because I don't really feel like endangering peoples jobs for such silliness.

One of them, at least, ignored my refusal, and emailed me the frame layout anyway. If I ever decide to revisit the issue, I'll check their decoding of the "full" data to make sure it matches.

5. I think the P4T guys still hold that the NTSB info does not match up to the “official story”. Is this because of Snowygrouch’s work with the raw FDR data or are they falling back on their erroneous CSV analysis?
They've migrated almost all of their claims away from the flawed CSV claims and toward the newer decoding stuff. The problem is their newer decoded data uncovers newer and more exciting flaws in their analysis.

The problem with this thread is that it's actually fairly dated and it's been so effective that many of the original claims in play when I wrote it are no longer being made.

Let me know the claims you are specifically interested in, and I'll dig up the responses from me/apathoid/beachnut that deal with it.
 
Last edited:
In the interest of tying up loose ends, I recall that P4T's decoding of the data showed that the data record ended when 77 was around 500 feet up, but somewhere close to the Sheraton at that time. This is more than a mile from the Pentagon, with plenty of distance left to get down to light-pole altitude when it got to that intersection.

Thus, their analysis seemed to refute their whole raison d'etre. Shouldn't they have simply disbanded after that, or am I recalling wrongly?
 
In the interest of tying up loose ends, I recall that P4T's decoding of the data showed that the data record ended when 77 was around 500 feet up, but somewhere close to the Sheraton at that time. This is more than a mile from the Pentagon, with plenty of distance left to get down to light-pole altitude when it got to that intersection.

Thus, their analysis seemed to refute their whole raison d'etre. Shouldn't they have simply disbanded after that, or am I recalling wrongly?

They have conveniently ignored the fact that the data they decoded shows the plane was 6+ seconds from impact.

The way they justify this is great:
The regulation says an FDR can only lose at most 1.5 seconds of data when it loses power. (And an L3 communications engineer verified that their recorders meet this requirement)

When AA77 hit the pentagon, the FDR lost power. Therefore, it could have at most 1.5 seconds missing.

The concept that crashing into reinforced concrete at 500mph isn't the same as "losing power" doesn't occur to JDX. Furthermore, it's still a "proof by regulation". It's sorta like claiming that OJ is innocent of murder because murder is illegal. Therefore, he couldn't have done it. Despite, ya know.. the evidence. We have an identical situation. He's citing regulations and designs.. in attempt to make the evidence of what actually happened go away.

I have, as of yet, seen any evidence-based rational for their dismissal of the very obvious evidence that their time-scale of all their analysis is shifted forward in time.
 
the traditional word is 16 bits but I think this usage is appropriate, although you might explain the difference between the traditional word in computers and how you're using it. Just to avoid accusations you don't know what you're talking about.

I don't think you can say that. All sorts of word sizes have been used on different processors(I've even heard of a processor that used 39 bits).
 
Last edited:
Solid State Recorders, like all medium, are quite unpredictable if they fail during write operations. The actual area being used to record data can very easily be corrupted if power fails while writing. It’s plausible that the crash caused problems in and around this local area of data, causing corruption of the 9:37:45 data frame (again, changing a single bit in a synch word is enough to cause software to completely choke).

I haven't read this entire thread, so please excuse this question if it has
already been addressed:

Are you stating that the data recorded in solid state memory was partially
corrupt (specifically the last two seconds?)?

L3 communications certifies their FDR's up to 3400 g's of impact force.
Are you stating that the data recorder selectively re-wrote the last
two seconds of data upon impact ?

What software are you referring to? If a bit was dropped, how is said
software effected? When you say software, are you referring to firmware
instead?

Would you agree that the data bus and FDR had power at least until the
nose of the plane impacted the Pentagon wall?

Would you agree that serial, multi-plexed data would continue to write
to the FDR solid state memory if one, or more sensors failed?

What causes 'pressure lag', or data lag at sea level that would not be
realized at 25,000+ feet at 500+ MPH?

Thank you for your time Anti-sophist.
 
L3 communications certifies their FDR's up to 3400 g's of impact force.
So? The one thing missing when looking at the FDR for all of us is total understanding of the entire system. This includes but is not limited to the engines of the plane supplying power to the electrical system, the generators, generator drives, battery, TRs, the FDR system itself. In the FDR system, of 77, the data collected in a second is transferred by the bus at the same speed. The data flows at 3072 bit per second, gee, the amount of data collected in a second is 3072 bits! What does the system do if there is a delay? Is the delay data buffered until it can be COMPRESSED and ENCODED so it can be STORED in the secure chip. Because the stuff not in the SECURE CHIP ENCLOSURE is toast when the nose hits the Pentagon!!! I could care less what the FDR can stand in Gs! The system that supplies the data to the FDR secure section is not able to handle 3400 Gs. If you can look up the number of Gs the system can take, why not look up how the system handles delays in the data stream, how much data is in the pipeline to be stored, worse case? What happens to the data in the pipeline when the system is smashed up? What does this spec, 3400 gs have to do with 9/11 and flight 77?



Are you stating that the data recorder selectively re-wrote the last two seconds of data upon impact ?
The data is encoded, how is it encoded and the last data written would be corrupt unless there was power to the system to finish the data stream encoding and compression; at least the data of interest for the terminally stupid CTers. The FDR is not used to settle made up CTs by people like 9/11 truth who manufacture lies, false information and implied Looney tune conclusions. What does this have to do with 77 hitting the Pentagon?


Would you agree that the data bus and FDR had power at least until the nose of the plane impacted the Pentagon wall?
NO! The terrorist pilot was in a PIO in pitch, the G force on the plane was varying the last 20 seconds due to pilot input on the stick (yoke) from 1.3, 0.3, 1.7, 0.3, 1.5, 0.8, 1.75, .6. In the last data point the most extreme stick down force was introduced, there is a lag between this and the maximum g force. 1 g is normal, we are at 1 g most of the time. Can you tell me if the aircraft Generators can handle .2 g, because the input on the last data point could have generated a negative g, and if the Generator drives are not made for that, they trip, removing power about the time all those Witnesses said the 77 pitched down a lot! Power off, the last 3 to 5 seconds are missing! Gee, has anyone told me how the system, the FDR system handles data backups? What does this have to do with 77 hitting the Pentagon?

77g.jpg


Did these questions come from seeing Pilots for truth?: p4t, spew pure junk. They say the system can not have more than a .5 second data lag, but they can not produce the spec (most likely this is a transport lag)! They say a bunch of junk to sell DVDs to real dumb people who love a conspiracy made up by snake oil salesmen of the internet; p4t. Many examples of FDR missing data. This is why the standard for FDR change all the time. The new recorders are going to have power back up so the system can record data, data available during power failure. The FDR from 77 was found in the Pentagon providing one piece of evidence which destroys the liars of 9/11 truth who spread false ideas in medium of questions. Even p4t are unable to make theories and conclusions about 9/11 due to ZERO evidence to support them, they can not even produce more than hearsay sources for their claims. Not the kind of pilots you want in the left seat, these guys posses no knowledge and judgment to make rational decisions on 9/11, what makes you think they can do better at flying?
 
So? The one thing missing when looking at the FDR for all of us is total understanding of the entire system. This includes but is not limited to the engines of the plane supplying power to the electrical system, the generators, generator drives, battery, TRs, the FDR system itself. In the FDR system, of 77, the data collected in a second is transferred by the bus at the same speed. The data flows at 3072 bit per second, gee, the amount of data collected in a second is 3072 bits! What does the system do if there is a delay?


Quite simply put without smoke and mirrors: the data received from the
sensor is stored in the solid state crash protected memory within 0.5
seconds (worst case). You are confusing bus speed, and polling time
with propagation delay.

Is the delay data buffered until it can be COMPRESSED and ENCODED so it can be STORED in the secure chip. Because the stuff not in the SECURE CHIP ENCLOSURE is toast when the nose hits the Pentagon!!!

Fine. Then why does the NTSB animation stop before impact? Where
is the data between the stop point, and impact point?

I could care less what the FDR can stand in Gs! The system that supplies the data to the FDR secure section is not able to handle 3400 Gs. If you can look up the number of Gs the system can take, why not look up how the system handles delays in the data stream, how much data is in the pipeline to be stored, worse case? What happens to the data in the pipeline when the system is smashed up?

After 500 milliseconds (worst case), that information would not have
reached the memory and stored. Confirmed by L3 communications.

What does this spec, 3400 gs have to do with 9/11 and flight 77?

Because some of you claim the impact force damaged the crash protected
memory. This is a false claim.

The data is encoded, how is it encoded and the last data written would be corrupt unless there was power to the system to finish the data stream encoding and compression; at least the data of interest for the terminally stupid CTers.

Once again, only 500 milliseconds would be corrupt. How do you explain
the missing radar altimeter info in the CSV file? It's in the raw data!

NO! The terrorist pilot was in a PIO in pitch, the G force on the plane was varying the last 20 seconds due to pilot input on the stick (yoke) from 1.3, 0.3, 1.7, 0.3, 1.5, 0.8, 1.75, .6. In the last data point the most extreme stick down force was introduced, there is a lag between this and the maximum g force. 1 g is normal, we are at 1 g most of the time. Can you tell me if the aircraft Generators can handle .2 g, because the input on the last data point could have generated a negative g, and if the Generator drives are not made for that, they trip, removing power about the time all those Witnesses said the 77 pitched down a lot!

Guess what? You can move the stick until you're blue in the face. The
movement of the airplane generates the g force, not the yoke movement!!!

The data, and animation shows nothing in the way of extreme alt. changes
to produce such a lag.

Power off, the last 3 to 5 seconds are missing! Gee, has anyone told me how the system, the FDR system handles data backups? What does this have to do with 77 hitting the Pentagon?


Once again, the animation stops pre-impact. Where is the data up until
the impact point. The FDR still had power!

They say the system can not have more than a .5 second data lag, but they can not produce the spec (most likely this is a transport lag)!

L3 communications certifies the FDR's. Do you know what it takes to
certify a commercial airliner for passenger flight?

Do you know what checks need to happen before the plane takes off
prior to flight? If you knew, you wouldn't have typed your statement.

Even p4t are unable to make theories and conclusions about 9/11 due to ZERO evidence to support them, they can not even produce more than hearsay sources for their claims.

The NTSB supplied the data. It doesn't support the official story. WHy
are you slamming PFT?
 
Guess what? You can move the stick until you're blue in the face. The
movement of the airplane generates the g force, not the yoke movement!!!

The data, and animation shows nothing in the way of extreme alt. changes
to produce such a lag.
So, you're saying that you can move the stick (yoke) all over the place and this doesn't make the aircraft move in response? At least that what it sounds like you are saying.

I assume beachnut's g data is from the FDR. Doesn't that show the aircraft was responding to input from the yoke?

I'm confused. :confused:
 
Last edited:
Mr. Skinny,

What I am stating is that the yoke movements captured in the data file
do not produce the g forces measured by the sensors.

The body of the aircraft does not respond in a 1:1 relation with the yoke
input as the mass of the plane, air pressure, inertia, etc. must be considered.

When viewing the simulator animation, you can confirm this by viewing the
plane's movement with respect to the yoke input.
 
Mr. Skinny,

What I am stating is that the yoke movements captured in the data file
do not produce the g forces measured by the sensors.

The body of the aircraft does not respond in a 1:1 relation with the yoke
input as the mass of the plane, air pressure, inertia, etc. must be considered.

When viewing the simulator animation, you can confirm this by viewing the
plane's movement with respect to the yoke input.
Understand that there is not an exact 1:1 relationship, but doesn't beachnuts graph show the actual g forces from the FDR?

It's not showing stick movement directly, but beachnut is rightly assuming, I believe, that the g forces shown are indicative of Pilot Induced Oscillation (PIO).


ETA: Beachnut's graph isn't properly labeled so I'm not sure what it shows. Just assuming it's g's
 
Last edited:
I'll have to check my copy of the data file again. I don't see this trend,
and it certainly doesn't show up in the simulation video.

Here is something I'd like to present about the FDR data and how solid state
storage systems function.

It's a parallel between your car's computer, and how a flight data recoder
operates. This is a basic overview to help the average person understand
why the missing and erroneous data presented by the NTSB does not
make sense.

I wont tell you want my area of expertise, profession, or experience is
because I've seen/read what many have said about Gage, Jones, Balsamo, etc.

Apparently, education and experience doesn't get you far in this world...

So here's my write up about data storage on a very basic level. I will
answer any questions you might have about this information, and FDR
related data as best I can.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


I'd like to bring your attention to a device that almost everyone has in their vehicle since inception of computer
controlled engines. I say almost everyone because some of you many still drive vehicles that do not use computer
control.

Your car, much like a commercial airliner has a controller and data recording device which reads important
sensor information, and adjusts parameters to maintain engine operation. The computer, often referred to
as Powertrain Control Module (PCM), or Vehicle Control Module (VCM) also stores operation parameters, and
fault data.

Believe it, or not, your modern day car uses a program which dictates how the engine performs. Below, I have
linked an image from my vehicle scanner which shows the ignition control table for my car.
The numbers in the green, yellow and orange cells tell the computer when to signal the ignition module to
fire off a spark to the spark plugs.

http://procision-auto.com/Tino/911_pcm_scan3.jpg

The computer reads information from several sensors around the car, and makes adjustments based on
engine load, what you want the car to do, and the current operation conditions. For example, if you
want to go faster, you press the accelerator pedal and the computer will respond accordingly.

Using a sensor connected to the accelerator pedal linkage and throttle valve, the computer understands
how far down you have pressed the pedal. This is called Throttle Position Sensor (TPS). The picture
below indicates that my throttle position is 0% (or closed). We can verify this by looking at other sensor
information such as engine RPM (1102 RPM, or idling), Mass Air Flow (1.24 lb./minute), Manifold Pressure
at 43 kPa, etc. Everything checks out!

http://procision-auto.com/Tino/911_pcm_scan5.jpg

This analysis software also allows me to view the parameters in graphic form so I can relate the sensor
information in real time:

http://procision-auto.com/Tino/911_pcm_scan.jpg
http://procision-auto.com/Tino/911_pcm_scan2.jpg

If your engine experiences any troubles (major, or minor), the computer will record and store the information
in memory, and also issue a fault code. If the problem is severe enough, the computer will also set a
Malfunction Indicator Lamp (MIL) which will appear on your instrument cluster as "service engine soon", or
a picture off a wrench, or engine depending on your car.

This tells the driver that something isn't proper. It helps the mechanic to trouble-shoot the error.
In the table below, you will see a list of codes on the right (PXXXX), followed by a description of
which sensor corresponds to the code.

http://procision-auto.com/Tino/911_pcm_scan4.jpg

Much like a flight data recorder, these codes are stored in protected memory and can't be erased
even if the car battery is disconnected. If a sensor fails, or is disconnected, the computer will
continue to record sensor information and store error codes.

What's the point of this? Well, those who claim the FDR is "fine" don't seem to understand that certain
parameters don't coincide, or make sense with all of the other information.

If a sensor were to fail on the airplane, the FDR will continue to record data. It will NOT wipe out seconds
of information! The FDR also sets a trouble code exactly like your car's computer so that airplane
maintenance technicians can see a history of the trouble and repair the airplane.

It is absurd and false to claim that the FDR , or CSV file would omit an entire parameter. At best,
the sensor would show a malfunction and record a value of some sort, as well as set an error code!

Sever Impact will not erase certain data cells. This is a common arguement
with debunkers. It's impossible to lose data while the computer has power.
Something must be written to the data address!

Also noteworthy is that engine sensors respond extremely quickly! Within milliseconds, a manifold
pressure sensor can sense a change in pressure, send the info to the computer, and display it on
my scanner!

This BS about sensor lag, or data write time of 2+ seconds is bogus.

If your $1500.00 car computer can do all of this, you can rest assured a much more elaborate and expensive jet data acquisition system will outperform
this many times over.

Do not hotlink images.
Replying to this modbox in thread will be off topic  Posted By: Lisa Simpson
 
Last edited by a moderator:
I'll have to check my copy of the data file again. I don't see this trend,
and it certainly doesn't show up in the simulation video.

Here is something I'd like to present about the FDR data and how solid state
storage systems function.

It's a parallel between your car's computer, and how a flight data recoder
operates. This is a basic overview to help the average person understand
why the missing and erroneous data presented by the NTSB does not
make sense.

I wont tell you want my area of expertise, profession, or experience is
because I've seen/read what many have said about Gage, Jones, Balsamo, etc.

Apparently, education and experience doesn't get you far in this world...

So here's my write up about data storage on a very basic level. I will
answer any questions you might have about this information, and FDR
related data as best I can.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


I'd like to bring your attention to a device that almost everyone has in their vehicle since inception of computer
controlled engines. I say almost everyone because some of you many still drive vehicles that do not use computer
control.

Your car, much like a commercial airliner has a controller and data recording device which reads important
sensor information, and adjusts parameters to maintain engine operation. The computer, often referred to
as Powertrain Control Module (PCM), or Vehicle Control Module (VCM) also stores operation parameters, and
fault data.

Believe it, or not, your modern day car uses a program which dictates how the engine performs. Below, I have
linked an image from my vehicle scanner which shows the ignition control table for my car.
The numbers in the green, yellow and orange cells tell the computer when to signal the ignition module to
fire off a spark to the spark plugs.

http://procision-auto.com/Tino/911_pcm_scan3.jpg

The computer reads information from several sensors around the car, and makes adjustments based on
engine load, what you want the car to do, and the current operation conditions. For example, if you
want to go faster, you press the accelerator pedal and the computer will respond accordingly.

Using a sensor connected to the accelerator pedal linkage and throttle valve, the computer understands
how far down you have pressed the pedal. This is called Throttle Position Sensor (TPS). The picture
below indicates that my throttle position is 0% (or closed). We can verify this by looking at other sensor
information such as engine RPM (1102 RPM, or idling), Mass Air Flow (1.24 lb./minute), Manifold Pressure
at 43 kPa, etc. Everything checks out!

http://procision-auto.com/Tino/911_pcm_scan5.jpg

This analysis software also allows me to view the parameters in graphic form so I can relate the sensor
information in real time:

http://procision-auto.com/Tino/911_pcm_scan.jpg
http://procision-auto.com/Tino/911_pcm_scan2.jpg

If your engine experiences any troubles (major, or minor), the computer will record and store the information
in memory, and also issue a fault code. If the problem is severe enough, the computer will also set a
Malfunction Indicator Lamp (MIL) which will appear on your instrument cluster as "service engine soon", or
a picture off a wrench, or engine depending on your car.

This tells the driver that something isn't proper. It helps the mechanic to trouble-shoot the error.
In the table below, you will see a list of codes on the right (PXXXX), followed by a description of
which sensor corresponds to the code.

http://procision-auto.com/Tino/911_pcm_scan4.jpg

Much like a flight data recorder, these codes are stored in protected memory and can't be erased
even if the car battery is disconnected. If a sensor fails, or is disconnected, the computer will
continue to record sensor information and store error codes.

What's the point of this? Well, those who claim the FDR is "fine" don't seem to understand that certain
parameters don't coincide, or make sense with all of the other information.

If a sensor were to fail on the airplane, the FDR will continue to record data. It will NOT wipe out seconds
of information! The FDR also sets a trouble code exactly like your car's computer so that airplane
maintenance technicians can see a history of the trouble and repair the airplane.

It is absurd and false to claim that the FDR , or CSV file would omit an entire parameter. At best,
the sensor would show a malfunction and record a value of some sort, as well as set an error code!

Sever Impact will not erase certain data cells. This is a common arguement
with debunkers. It's impossible to lose data while the computer has power.
Something must be written to the data address!

Also noteworthy is that engine sensors respond extremely quickly! Within milliseconds, a manifold
pressure sensor can sense a change in pressure, send the info to the computer, and display it on
my scanner!

This BS about sensor lag, or data write time of 2+ seconds is bogus.

If your $1500.00 car computer can do all of this, you can rest assured a much more elaborate and expensive jet data acquisition system will outperform
this many times over.
You want to say this again and...

 

Back
Top Bottom