AA77 FDR Data, Explained

[R.Mackey]

Absolutely not. The written word endures. The telephone offers no advantages whatsoever that I can determine.

If you're really so unnerved by other posters, then just stop responding to them. You are hardly a poster child for high signal-to-noise posting.

Also, we're all waiting for you to make good on your "promise" from yesterday. Surely some independent evaluation of device physics and failure couldn't hurt, right? Have you made any progress?

 

[LashL]

Turbofan,

How about linking to all of those "electronics engineering" sites that you claimed you were going to "expose" R. Mackey on yesterday?
You seem to have lost your appetite for it. Why is that?

It sure looks like you've been posting a whole lot of bluster without any substance. Or, to cite Kim Mitchell, since you're Canadian and all, your posts look like "a whole lot of feathers and not much chicken".

 

[Turbofan]

I say a live audio interview for the world to hear is much more impressive
than hiding behind a keyboard.

I've got you beat on signal-to-noise. We already went over that silly little
lightning storm static on your answering machine. Those aren't flipped bits!

When you can provide evidence, or examples of stored data flipping state
from a transient ... without blowing the chip. Come and see me...or call me.

My promise will be kept. I'm waiting for my account to be activated. Soon
all of your buddies will see that EEPROM's don't lose, or flip a couple of
selective bits.

"Look Mr. Transient, there's the last few seconds of data in CPM. Why
don't you make your way to that specific address, change a couple of
bits and then filter yourself out through the LRC circuitry. Don't worry,
we wont tell Mr. Mackey that the data recorded to :45. He'll make up
an excuse about the NTSB being wrong, or the clock sync being off by
SIX SECONDS!"

 

[fitzgibbon]

So Turbo,

You had any bites from the MS on your earth-shattering info yet? You seem to have an awful lot of time to post on forums

 

[jaydeehess]

Looks like Mackey is busted because that linked article doesn't support
his theory, nor say a thing about transient spikes altering bit states.

I note that the question asked was

My EEPROM is sometimes corrupted, what can I do to prevent this?

and that the explanation was that odd things occur if VCC drops. I would imagine that odd things could also occur if a spike occured on the data bus, or the ground (or VEE), or the clock circuit.

The article of course assumes a stable enviroment for the EEPROM which certainly was not the case for the last few seconds of Flight 77.

Doing a little other research I find that EEPROM data corruption is common in cases where a reset is not done on power down.

Gee I can't imagine why such was not performed when the aircraft hit the wall.

Once it hit the first lamp post all bets are off on the stability of electronic supplies on board.
Just the bald fact that many other FDR's have lost several seconds worth of data prior to a crash whlie others wrote and retained data right up to aircraft destruction should clue you and PfT in but you seem to willfully ignore that.

I too am interested in your posts to electronic forums concerning this. Whenever you are ready just post a link.

 

[Turbofan]

I note that the question asked was

and that the explanation was that odd things occur if VCC drops. I would imagine that odd things could also occur if a spike occured on the data bus, or the ground (or VEE), or the clock circuit.

Neither scenario would support previously biased gates from changing state.
There is no mecahanism to enable address lines. Any sort of random
spike while the current data is written could not possibly flip a single
gate.

The duration of the spike would not be sufficient.

Large spikes will damage the gate, not change a state. According to the
NTSB, the data was retrieved as expected and the unit was working as
expected.

If you believe R. Mackey, you also have to include and justify a clock sync
error of six seconds, as well as an out of tolerance event for the equipment
which measured DME (well before :45 and still recovered from CPM).

The article of course assumes a stable enviroment for the EEPROM which certainly was not the case for the last few seconds of Flight 77.

THat is far from a thorough article, or explanation. Try looking up how EEPROMs are made, their
layout, their function.

Once it hit the first lamp post all bets are off on the stability of electronic supplies on board.

" light pole impacts" were not even recorded/sensed according to FDR data,
and the north approach witness accounts.

Just the bald fact that many other FDR's have lost several seconds worth of data prior to a crash whlie others wrote and retained data right up to aircraft destruction should clue you and PfT in but you seem to willfully ignore that.

Link me to an example. There are none which mirror this scenario and
data loss that we're debating.

I too am interested in your posts to electronic forums concerning this. Whenever you are ready just post a link.

Will do.

Is someone going to answer my question about landing gear and exit hole dimensions?

 

[R.Mackey]

Though it is not widely known, these types of power issues are actually quite prevalent, especially in embedded applications. In fact, based on SiliconSystems’ industry experience, roughly 75 percent of storage-related field failures are triggered by power-related corruption. When power goes out or fluctuates, drives can be corrupted and data lost, resulting in downtime as drives get reformatted, operating systems reinstalled, or products returned.

Source

This is an industry puff-piece, not a scholarly reference, but it nonetheless clearly identifies that the problem is known and understood specific to flight data recorders. And this is normal operations they're talking about, not a crash!

Anyway, while we await Turbofan to make good on his boast, I should point out once again that the whole discussion is moot. At worst, wrong FDR data means that the FDR data is wrong. No matter what the FDR says, it cannot magically make the remains of a crashed aircraft go away.

If you, Turbofan, are actually interested in a productive discussion, there are two avenues I would suggest. The first is that you identify what you want to talk about. If you want to talk about device physics, there are resources I can bring to the table. For instance, one of my advisors is full professor of Electrical Engineering at Caltech, and I know several people in the space microdevice physics laboratory at JPL, who routinely destructively evaluate components. Flash memory is one of them, having only recently begun to appear in space applications. I would, however, suggest that a discussion on EEPROMs, Flash, and performance under adverse environmental conditions should be separate from this thread, and should be in the Science subforum. And, of course, that you should attempt to argue like an adult.

Second, after re-reading the NTSB Report, and from your own comments such as recovery of RADALT afterwards, it seems that the NTSB did not go through the grunge data by hand, but merely presented data that was also validated, i.e. conformed to the standard frame tables. This is pretty ordinary from looking at other crash investigations -- afterward, a specialist team attempts to decode the remaining damaged frames by hand. I suspect we can demonstrate that the aircraft remained flying for some time after 9:37:44 simply by considering this invalid data, even if we can't unscramble it. How much data remains? I throw this open to the whole group.

 

[Turbofan]

Your 'puff' article doesn't refer to bit level corruption. Your article does
not state whether the device is EEPROM. The article does not state the
certifications for the device.

It's just 'puff' as you call it.

R. Mackey, why don't you tell me about the exit hole and landing gear
dimensions?

Topics

#1:
I'd love to compare the entry hole and fuselage dimensions to the exit
hole and landing gear dimensions.

#2:
Let's talk more about data recorded to :45 and the NTSB impact time of
:45

#3:
Can we discuss bit level corruption from transients as it pertains to your
theory of FDR data loss. This is totally related to the topic and should
remain in this thread/forum. I too can bring more to the table.

I promise to debate more calmly if the other members who are not technically
inclined refrain from posting just to boost their post counter.

 

[R.Mackey]

R. Mackey, why don't you tell me about the exit hole and landing gear
dimensions?

Because it's off-topic. Rule 11 applies. Plus, it's pretty obvious you're just desperate to change the subject. We've been watching the "Truther Shuffle" for years, you know.

Topics

#1:
I'd love to compare the entry hole and fuselage dimensions to the exit
hole and landing gear dimensions.

Off-topic. But very briefly, as I've explained here before, the hole is at least partly caused by blast, not just bits of landing gear. This is not Looney Tunes and we do not expect a cut-out shape of debris to be left in the wall. If the hole was smaller than the debris, you might have something, but it is not.

#2:
Let's talk more about data recorded to :45 and the NTSB impact time of
:45

Why, let's.

#3:
Can we discuss bit level corruption from transients as it pertains to your
theory of FDR data loss. This is totally related to the topic and should
remain in this thread/forum. I too can bring more to the table.

Feel free to ask.

I promise to debate more calmly if the other members who are not technically
inclined refrain from posting just to boost their post counter.

I can make no guarantees about the behavior of others. Besides which, you are by far the worst offender. Try acting rationally and I'll bet the rest settle down as well. If not, that's what Ignore is for. Pretty simple stuff.

 

[beachnut]

" light pole impacts" were not even recorded/sensed according to FDR data,
and the north approach witness accounts.


Link me to an example. There are none which mirror this scenario and
data loss that we're debating.

Will do.

Is someone going to answer my question about landing gear and exit hole dimensions?

The FDR stopped recording/data stopped over 6 second prior to impact. The FDR position confirms this, Balsamo plots it and wrongly says the INS crashed, IT DID NO CRASH! The lamppost may not do damage unless the engine eats a lamppost, in 1.3 second, the FDR would stop anyway, no evidence may be seen. The engines were at their temperature limits, parts of the engine may have had problems; did electrics trip power due to overheat conditions, due to operation over the 350 KCAS limit! I was surprised the engines could stand the EGT in the last 20 seconds, but they are rated very high! Wonder if the electric balked and stopped working at the high temperatures in the engine, or blew something. When the plane was near sea level over 100 knots above TOP SPEED for the 757 (the 767 has some high dive speeds, not sure if they are applicable for 757). What bad things can happen. The WTC planes were higher, you would be surprised the difference 500 feet makes at sea level.

Power lost, FDR stops. Another possible good reason data is missing. Did you see the rpm and EGT? Wow!

The landing gear? Funny you have over 1000 pounds of TNT kinetic energy event and you wonder why the hole in the wall is there? A good physics course could help; a car could damage a wall like that.

I checked, KE of the car is trivial compared to the impact of a 757 over 500 mph? Can you help me check my work?

 

[X]

I checked, KE of the car is trivial compared to the impact of a 757 over 500 mph? Can you help me check my work?

Is that necessary?

I would think even a high school student (that's when they get into KE here) could see it.

KE = 0.5*mass*velocity²
Car: small mass, low velocity
Jetliner: big mass, high velocity (difeerences of facotrs, not multiples).

Therefore, jetliner KE >> car KE.

In this case, no calculations are needed.
Unless you want to tell me how fast those cars were going.

 

[R.Mackey]

Beachnut, you've looked at this too --

1. What is the actual data recorded at the last full subframe, at 9:37:44 (or :45)?

2. Is there any partial data recorded afterward?

3. If so, how much? Is any of it intelligible at all?

The key to figuring out if something is impossible is first trying to see how it might be possible, and then evaluating what you come up with for plausibility. I'm willing to go through this again, and show how it can be put into a valid narrative. Or maybe you've got some data I don't know about.

Bring your constraints. Let's put together a hypothesis. That goes for everyone.

 

[beachnut]

Beachnut, you've looked at this too --

1. What is the actual data recorded at the last full subframe, at 9:37:44 (or :45)?

2. Is there any partial data recorded afterward?

3. If so, how much? Is any of it intelligible at all?

The key to figuring out if something is impossible is first trying to see how it might be possible, and then evaluating what you come up with for plausibility. I'm willing to go through this again, and show how it can be put into a valid narrative. Or maybe you've got some data I don't know about.

Bring your constraints. Let's put together a hypothesis. That goes for everyone.

1.
The last data second, :44 , there are two more time stamps :45 :46 no decoded data on NTSB

p4t file last data decoded :43, p4t decode failed to apply algorithm to the frames for time, the time they store is repeated 4 times for the end time, essentially the next frame first second time, IE, :43 has the time of 13:37:45 all seconds in the 4 second frame. Not a big deal.

 

[beachnut]

Beachnut, you've looked at this too --

1. What is the actual data recorded at the last full subframe, at 9:37:44 (or :45)?

2. Is there any partial data recorded afterward?

3. If so, how much? Is any of it intelligible at all?

Bring your constraints. Let's put together a hypothesis. That goes for everyone.

2. In the p4t decode they have one more second past :43, all error, not decoded, and a line after, all errors.

There are also error lines in the data; p4t only from a quick look now, again

I had a thought why p4t decode has errors; when parameters are checked and not verified or damaged, they could preclude decoding a whole second. But how can leaving them out, the corrupt items, and let you selectively decode the rest of the data correctly, like the NTSB decode looks free of errors.

The NTSB did decode :44, the data follows and makes sense following the p4t :43 second.


The NTSB did decode :44, the data follows and makes sense following the p4t :43 second.
NTSB says they did not decode a bunch of variable not verified, or recorded properly. I can't see how you can then decode around those areas. But I see errors, missing seconds, not found in the NTSB version.

The NTSB and p4t decode match, except for rounding differences, slight resolution differences (450 vs 449.5), and p4t decode all the data in each second, NTSB only selected variables. No big deal;

 

[beachnut]

Beachnut, you've looked at this too --

Bring your constraints. Let's put together a hypothesis. That goes for everyone.

This is harder to do, than ...

This is tough, the real way these boxes work is proprietary except for what is specified by the FAA and ED regulations. These are commercial items in competition with other firms. The real workings where they do not have to disclose are not. I am talking bs slightly but this is a fact you learn when you work acquisition in the AF and I presume it is similar in the real world as companies protect their edge and shortcomings.

As long as they meet the specs there is little they have to reveal of the inner workings.

So much for bs.

I found it interesting the data rate to the secure chip, was the exact rate of the data for one second collected. I assume this was at one time the maximum transmission speed, but I am assuming as chips and data transmission has improve the data rate are higher.

I do not know if there is an emphasis on this model to get all data, and not miss a second. If the true data rate is the same as the data collected per second and the system is designed not to miss a second there has to be a buffer to hold the data delayed secure storage at any time. Therefore if the data rate is fixed to the chip, the buffer will have extra seconds missed waiting to be stored, at the end of flight the seconds in buffer will finally be stored. This is pure bs, but I am an engineer, and if I wanted all the data, what else can I do if the pipeline speed is the same rate as data collected per second. (until the chips are faster, etc.)

There are 3 seconds early in the p4t decode marked as #error, no data in the line.

This could be an early model, one of the first to go to 256 word per second. Is there a buffer to collect data if there are problems? If so, I now understand the 0.5 second requirement introduced to prevent buffer losses as I imagined in early models. Imagine a buffer of 20 seconds to be stored, you would be upset if your accident clue was lost; hense the .5 second to secure chip spec was finally introduced. I forgot if 77 was covered, or grandfathered. There are transport delays in these systems.

The data rate bothered me, it is like we are passing bricks to be stacked per second and it takes one second to stack, and we mess up, I have to buffer the brick, and we end up with not only a few bricks not stacked, but more than a few seconds to get back just stacking. A few missed bricks and we are 6 seconds behind.

Total bs, but I have spewed total bs before, sometimes right, sometimes wrong


i owe some sodas and beer now...

 

[Jonnyclueless]

I promise to debate more calmly if the other members who are not technically
inclined refrain from posting just to boost their post counter.

Stop playing the victim when you are the instigator. Excuses excuses ecuses. Just like wanting to use the phone as if somehow you'll be able to make arguments on the phone that you cannot on text.

Continue with the dog and pony show pretending you are an expert and that everyone else is an idiot. Continue pretending to be a victim when you start the accusations and are proven wrong. 75% of your arguments are just this kind of nonsense.

You've been shown a phenomenon that everyone expert and otherwise is already very familiar with is how memory can be damaged. It happens to everyone and every electronic equipment and happens to FDRs as has been shown. You make the argument that the NTSB said the box performed as expected. But the expectation in airplane crashes is not that everything is going to work as if it were new from the factory and up to spec. Their is an assumption that there's going to be some damage as is normal. When they say it operates as expected, they mean just that. As opposed to the CVR which was damaged beyond readability. There is no all or nothing in these situations. And as far as the NTSB the FDR worked as expected in that they were able to get enough data from it to see what happened. They aren't using it to determine the exact position and altitude down to the second because they already know the plane hit the pentagon. They don't need the data to prove tha because it's already known and is an indisputable fact. It would be a waste o their time and resources.

But continue with your little ego driven fantasy of being an expert and throwing temper tantrums like a little baby and pretending you are the victim here.

 

[Caustic Logic]

Wrong CL.

If you're basing a decision on my 'laughing' you are in big trouble like Mackey
and he's too bold to own up.

You either believe 1 of his 5 excuses, or the NTSB is 6 seconds off.

Pick one and stick to it!

Wrong? I called the debate against you. Of course you'll say wrong, and with - gasp - confident certainty! I don't know how or why, but the FDR is clearly missing several seconds of data, despite all your bluster. This is a possible true 9/11 mystery, and PfffT refuse to even touch it, instead focusing on made up fantasies based on accepting the "official story" impact time of 9:37:45 as the only moment the plane hypothetically hit - from about a mile away. Looking forward to out debate.

 

[Caustic Logic]

I just noticed something shocking. This is a big thread I've been noticing... we're on page 63 now! Well of course it's been up since October 13 2006, almost two years.

Here's the scary part... page 11 starts with Boloboffin back in late March 2007, then peters out to Oct 31, silence, a lonely post in February 2008, silence, then the first post by Turobfan July 6. That was page 11. We're 52 pages on from that in a little over two months, with the turbofan spinning away full speed the whole way.

My word!

Is that normal?

 

[bje]

I just noticed something shocking. This is a big thread I've been noticing... we're on page 63 now! Well of course it's been up since October 13 2006, almost two years.

Here's the scary part... page 11 starts with Boloboffin back in late March 2007, then peters out to Oct 31, silence, a lonely post in February 2008, silence, then the first post by Turobfan July 6. That was page 11. We're 52 pages on from that in a little over two months, with the turbofan spinning away full speed the whole way.

My word!

Is that normal?

It's normal, and necessary, for Turbofan et al.

But I think the particular structure of forums here and elsewhere where threads are limited to the discussion of the title of the thread plays nicely into the hands of conspiracists. Arguing about AA77 FDR data, for instance, as a single issue without discussing it in context of all the other evidence is what allows Turbofan et al to ignore the implications of his claims and other relevant evidence.

The behavior of CIT and P4T - and virtually all conspiracists - is to strictly limit discussion to a narrow topic independent of all other contradictory evidence. Turbofan will go on and on and on about EPROMS but will never discuss the implications - a flyover and what that claim implies. And with the forum structure, he doesn't have to.

 

[Turbofan]

Because it's off-topic. Rule 11 applies. Plus, it's pretty obvious you're just desperate to change the subject. We've been watching the "Truther Shuffle" for years, you know.

I'm not trying to change the subject. You will notice I'm still talking about
the FDR along with other topics. It`s not PFT who are running from
live debates. Remember that.

Off-topic. But very briefly, as I've explained here before, the hole is at least partly caused by blast, not just bits of landing gear. This is not Looney Tunes and we do not expect a cut-out shape of debris to be left in the wall. If the hole was smaller than the debris, you might have something, but it is not.

Actually, it looks a lot like Looney Tunes because of the shape of the hole.
vs. landing gear dimensions.

Your explanation of the exit hole is based on assumptions. If you had all
of the info and had an investigation report from the FBI, ASCE or something
to support such claims, it may be considered valid.

Caustic Logic has offered to talk with me live via phone. Why don`t you
take the offer as well? I`ll pay.