WildCat
NWO Master Conspirator
- Joined
- Mar 23, 2003
- Messages
- 59,856
Where will you be doing this? Please let us know so we can follow along as hilarity ensues!
-
Security incident: ISF was recently accessed by intruders. Please change your password, and change it anywhere else you used it. Read more
AA77 FDR Data, Explained
- Thread starter Anti-sophist
- Start date
-
- Tags
- aa77 flight data recorder
I would be more civil if he owned up to his error. Sorry you don't understand
EEPROM;s either.
His story doesn't make sense, but you can't see it.
There is no misunderstanding his replies.
1. The FDR should have recorded up until impact according to Mackey.
2. According to Mackey, there are six seconds of data missing.
3. You can't erase single cells, or just seconds of data by electrical transients,
during write time, or after.
4. The CPM was found intact. No damage due to impact and the data
was retrieved just fine.
5. After impact, Mackey calculates 200 msecs. 200 msecs of corrupt
write time does not account for 5.8 seconds of missing data!
6. The times stamps are no way in hell out of sync by six seconds!
No matter how you want to read it, neither of his excuses work.
WildCat
NWO Master Conspirator
- Joined
- Mar 23, 2003
- Messages
- 59,856
So, where is it?
This is so fundamental that it defies belief.
Let me try an analogy. I have an answering machine with flash memory. Let's say I have a message on it, and I want to erase it. What do I normally do? Well, I push buttons, go through the menu, and it does the normal erase process. The answering machine identifies the right data blocks, addresses them, and applies a specific voltage to "erase," i.e. reset, the gates in question.
But that's not the only way to erase the data.
Let's say you've called me and are recording a message when lightning strikes a utility pole nearby. Suddenly there's an unusual voltage applied to the EEPROM. Since it's writing, it's already accessed a part of the EEPROM, but it sends the wrong voltage because its power supply can't deal with the spike. Of course, it's likely that lightning would simply blast it to pieces, but let's suppose the lightning strike is almost attenuated by breakers and such, so only the briefest instant of a moderate spike goes through. This spike, and the drop in power afterward, have the potential to affect other cells in the EEPROM. Instead of gently charging a gate to a preset level, all of a sudden there's a time-varying signal, and all of those little capacitances between gates that normally don't do anything react. The spike changes the state of many gates by accident. Those capacitances are always there, and define the maximum speed at which IC's can operate. They also define the IC's tolerance for line noise.
So what may happen is that data is lost. Perhaps the answering machine has its table of contents corrupted, and I lose the whole message as a result. Perhaps it just introduces an annoying "BZZHTHGHGGG" noise in the playback. Or, possibly, it erases everything. All in an instant. Depends on the spike voltage, depends on blind luck.
I can also erase data by hitting it with a hammer. I can obviously damage the circuitry itself, and that will make any data unusable. But it's also possible to do it less destructively, particularly if it is writing while I clobber it. By pounding on the case, I can shake loose parts of the power supply, squeeze things into contact that shouldn't be, or flex cold solder joints. All of which can disrupt the writing process. It may fail to write when it should. It may write wrong bits in longer words, rendering the whole word useless. Or it may corrupt other parts of the EEPROM as well.
Some other things to keep in mind: First is that the FDR is a continuously recording device. It doesn't clean itself before every flight, but instead overwrites old data. So in order to write anything, it has to either overwrite into unprepared blocks or erase previously recorded information. (We're now talking nominal operation, in case you got confused again.) If you interrupt its process in the middle of these steps, you will get some strange results. This is not corruption at all, just what happens when things don't execute cleanly.
Second is that the FDR in question uses Huffman encoding (referred to as "Hoffman" by the NTSB report, but Huffman is the correct spelling) as a compression scheme. Basically all this means is that commonly seen sequences are represented by much shorter symbols; for instance the nominal state of all switches and status during cruise, comprising hundreds of discretes, could be represented by as little as a single (12-bit) word. Or some 12-bit words are reduced to a shorter number of bits, and word length is no longer constant. (I'm not sure which they use in this case.) What is relevant here is that the compression scheme is variable length. It can be very efficient, but it is highly susceptible to corruption. If I flip a single bit in that 12-bit symbol, I have no way of knowing whether I've just invalidated a single measurement or, possibly, hundreds. I may be able to recover the other measurements deductively from the other words, assuming none of them are corrupted, but more often all I can do is dump that data until I come across a valid subframe marker, and start again from there. The amount of corruption we're talking about here need not be very much.
In spacecraft communication, we do not use Huffman encoding for this very reason; instead we use Reed-Solomon encoding, which provides a reasonably efficient error detection and correction mechanism. But this is expensive. We have plenty of time to compress our data, whereas an FDR may not; we also pay a lot more for our data.
Regardless of this, for the last time, the way data is normally erased does not mean there is no other way in which data can be lost. If you can't get past this point, then I'll be forced to conclude you simply do not have the ability to carry on this conversation. It's an embarrassingly simple concept.
Let me try an analogy. I have an answering machine with flash memory. Let's say I have a message on it, and I want to erase it. What do I normally do? Well, I push buttons, go through the menu, and it does the normal erase process. The answering machine identifies the right data blocks, addresses them, and applies a specific voltage to "erase," i.e. reset, the gates in question.
But that's not the only way to erase the data.
Let's say you've called me and are recording a message when lightning strikes a utility pole nearby. Suddenly there's an unusual voltage applied to the EEPROM. Since it's writing, it's already accessed a part of the EEPROM, but it sends the wrong voltage because its power supply can't deal with the spike. Of course, it's likely that lightning would simply blast it to pieces, but let's suppose the lightning strike is almost attenuated by breakers and such, so only the briefest instant of a moderate spike goes through. This spike, and the drop in power afterward, have the potential to affect other cells in the EEPROM. Instead of gently charging a gate to a preset level, all of a sudden there's a time-varying signal, and all of those little capacitances between gates that normally don't do anything react. The spike changes the state of many gates by accident. Those capacitances are always there, and define the maximum speed at which IC's can operate. They also define the IC's tolerance for line noise.
So what may happen is that data is lost. Perhaps the answering machine has its table of contents corrupted, and I lose the whole message as a result. Perhaps it just introduces an annoying "BZZHTHGHGGG" noise in the playback. Or, possibly, it erases everything. All in an instant. Depends on the spike voltage, depends on blind luck.
I can also erase data by hitting it with a hammer. I can obviously damage the circuitry itself, and that will make any data unusable. But it's also possible to do it less destructively, particularly if it is writing while I clobber it. By pounding on the case, I can shake loose parts of the power supply, squeeze things into contact that shouldn't be, or flex cold solder joints. All of which can disrupt the writing process. It may fail to write when it should. It may write wrong bits in longer words, rendering the whole word useless. Or it may corrupt other parts of the EEPROM as well.
Some other things to keep in mind: First is that the FDR is a continuously recording device. It doesn't clean itself before every flight, but instead overwrites old data. So in order to write anything, it has to either overwrite into unprepared blocks or erase previously recorded information. (We're now talking nominal operation, in case you got confused again.) If you interrupt its process in the middle of these steps, you will get some strange results. This is not corruption at all, just what happens when things don't execute cleanly.
Second is that the FDR in question uses Huffman encoding (referred to as "Hoffman" by the NTSB report, but Huffman is the correct spelling) as a compression scheme. Basically all this means is that commonly seen sequences are represented by much shorter symbols; for instance the nominal state of all switches and status during cruise, comprising hundreds of discretes, could be represented by as little as a single (12-bit) word. Or some 12-bit words are reduced to a shorter number of bits, and word length is no longer constant. (I'm not sure which they use in this case.) What is relevant here is that the compression scheme is variable length. It can be very efficient, but it is highly susceptible to corruption. If I flip a single bit in that 12-bit symbol, I have no way of knowing whether I've just invalidated a single measurement or, possibly, hundreds. I may be able to recover the other measurements deductively from the other words, assuming none of them are corrupted, but more often all I can do is dump that data until I come across a valid subframe marker, and start again from there. The amount of corruption we're talking about here need not be very much.
In spacecraft communication, we do not use Huffman encoding for this very reason; instead we use Reed-Solomon encoding, which provides a reasonably efficient error detection and correction mechanism. But this is expensive. We have plenty of time to compress our data, whereas an FDR may not; we also pay a lot more for our data.
Regardless of this, for the last time, the way data is normally erased does not mean there is no other way in which data can be lost. If you can't get past this point, then I'll be forced to conclude you simply do not have the ability to carry on this conversation. It's an embarrassingly simple concept.
Last edited:
X
Slide Rulez 4 Life
- Joined
- Oct 17, 2007
- Messages
- 4,127
No.
Ryan Mackey says there would have been more data had there been no impact.
You distort this into saying that the data should not have stopped before impact.
But I have news for you: The plane impacted the Pentagon!
The fact that the data stops a few moments before has already been explained.
The fact that the data stops is not a contradiction. You merely want to be. And it seems from your posts that you want this very desperately indeed.
But you continue on with your strawman, and attack Mr. Mackey every time he points out your misunderstanding.
This has been pointed out to you enough times from enough people that I have to rule out stupidity, and instead conclude that you are being willfully and maliciously deceitful.
Unfortunately for you, the posters here are neither rubes nor fools, and are not easily tricked.
And while I may not be an electrical engineer, I have no problem following the logic and explanations given to you by so many knowledgeable posters.
Ryan Mackey says there would have been more data had there been no impact.
You distort this into saying that the data should not have stopped before impact.
But I have news for you: The plane impacted the Pentagon!
The fact that the data stops a few moments before has already been explained.
The fact that the data stops is not a contradiction. You merely want to be. And it seems from your posts that you want this very desperately indeed.
But you continue on with your strawman, and attack Mr. Mackey every time he points out your misunderstanding.
This has been pointed out to you enough times from enough people that I have to rule out stupidity, and instead conclude that you are being willfully and maliciously deceitful.
Unfortunately for you, the posters here are neither rubes nor fools, and are not easily tricked.
And while I may not be an electrical engineer, I have no problem following the logic and explanations given to you by so many knowledgeable posters.
Think again.
The lightning is sending a spike prior to encoding. The noise that travels
through the phone lines to YOUR answering machine is what gets transmitted
and recorded as "analog voice data", or even 'digital noise'
The memory in your machine itself does not get damaged. The playback 'noise'
is not representative of erased data...because ummm...we're hearing it!
Proof?
Erase the message and start recording.
Play back.
"Lightning noise spikes" are gone.
Presto. Thank you very much for a another poor analogy and weak attempt
at saving your error.
Sure...
See above.
Again, no damage to CPM. Data retrieved. Impact no where near 3400 g's
FDR is solid state. It's encapsulated. No moving parts, and certainly nothing
is going to move when it's encapsulated.
stike 2...hundred Mackey!
Yawwnn... 200 mseconds of power. Tops.
We are the other 5.8 seconds? huh?
I guess you haven't heard of parity and CRC?
also one look at the data shows it's good. If ...IF....IF a bit flipped getting by parity and CRC
by some act of 'Jebuz', then it would have to be an LSB to escape the naked eye.
C ya in skewl Mackey
This is getting pasted along with your other junk.
Last edited:
Hokulele
Deleterious Slab of Damnation
You've, again, confused data lines and power lines. My analogy refers to noise on the power lines. Not the phone lines.
I remain absolutely fascinated at your ability to not understand.
And now you're confusing permanent EEPROM damage with damage to the data record therein. That's equally astonishing.
Lightning strikes to power lines can and will disrupt memory contained on EEPROMs. That's why, after a lightning strike, many of your appliances won't work anymore. They don't have to catch fire. This is also why EMP after an atomic explosion has such a huge radius of effect. It doesn't take much on some devices.
I'm beginning to wonder if you've understood a single thing I've ever said.
Again, I'm talking about damage to the power bus and supplies, not physical damage to the storage medium itself. Those, you'll find, are not rated for 3400 g's for any length of time.
I suddenly had an image of you burning an audio CD on your computer, and being stunned when it took less than 79 minutes to complete...
I have. I've also heard of EDAC. When you go to a Huffman scheme, it is possible to do some error correction, but it limits your options. The variable-length word storage advantage that it gives you precludes many types of checks.
And if it isn't "good," what do you do then?
C ya in skewl Mackey
This is getting pasted along with your other junk.
Go right ahead. Also, promise me also that you'll provide a link to those postings here. Otherwise, I'm afraid I don't believe you.
Last edited:
Jonnyclueless
Philosopher
- Joined
- Jun 18, 2007
- Messages
- 5,546
Turbo, again, can you tell us why the CVR from flight 77 was unusable?
WildCat
NWO Master Conspirator
- Joined
- Mar 23, 2003
- Messages
- 59,856
Well then, I guess there's no need for anyone to use a surge protector on their expensive electronic equipment!
Where's the link to the thread Turbofan?
The p4t indestructible no lost data FDR! 3400 Gs for 6 milli sec, resists 225 kg from 3 meters (what does a floor of the Pentagon weigh, and is it 3 meters high, what about the WTC?), resist crush 5000 pounds for 5 minutes, 1100 degree C flame for 30 minutes, and it never losses data is an added feature of the p4t new FDR! NEVER! IT CAN'T, Turbofan said so. All true but the lost data feature has not been perfected!
Does anyone not understand why the FDR in the WTC tower may have been crushed between multiple floors with a million pounds of crush force for days?
What did they find when they recovered a FDR in the Pentagon, the one place some of these limits actually could be exceeded in the place planes are not found in buildings!!!
"The recorder displayed evidence of impact, fire and smoke damage." The FDR was damaged! 77 FDR had damage. What about 93? "The recorder displayed evidence of impact."
Why did p4t super experts not decode the real last second of data the NTSB has? Was there data problems? It was lucky the FDR from 77 was not buried and crushed. When you think about plane crashes, you usually do not have office fires and buildings falling on the FDR, well past the specs.
As for why a FDR is missing data. Countless causes. What buss powers the FDR? With dolts in charge in the cockpit, it is amazing if they did not hit switches by accident. One of the idiots could be pulling circuit breakers, not having a clue what the little guy is. Dorks in cockpit, FDR last data is over 6 seconds away, the position in the FDR has 77 over 8 seconds away. To use the FDR, please plot the lat and long for us as you school us; please Turbofan. Mention the 1.5 DME again, with a rigorous accuracy and resolution discussion will prove again your ignorance on the issue and reinforce your reluctance to learn.
How can you take a FDR which shows 77 all the way back at the yellow dot, and make up lies?
Why worry about the function of the FDR, when you fail to understand the data stored in it?
Reality, the FDR is not indestructible, and data can be missing for causes beyond Turbofans one dimensional approach to 77 FDR issues.
Does anyone not understand why the FDR in the WTC tower may have been crushed between multiple floors with a million pounds of crush force for days?
What did they find when they recovered a FDR in the Pentagon, the one place some of these limits actually could be exceeded in the place planes are not found in buildings!!!
"The recorder displayed evidence of impact, fire and smoke damage." The FDR was damaged! 77 FDR had damage. What about 93? "The recorder displayed evidence of impact."
Why did p4t super experts not decode the real last second of data the NTSB has? Was there data problems? It was lucky the FDR from 77 was not buried and crushed. When you think about plane crashes, you usually do not have office fires and buildings falling on the FDR, well past the specs.
As for why a FDR is missing data. Countless causes. What buss powers the FDR? With dolts in charge in the cockpit, it is amazing if they did not hit switches by accident. One of the idiots could be pulling circuit breakers, not having a clue what the little guy is. Dorks in cockpit, FDR last data is over 6 seconds away, the position in the FDR has 77 over 8 seconds away. To use the FDR, please plot the lat and long for us as you school us; please Turbofan. Mention the 1.5 DME again, with a rigorous accuracy and resolution discussion will prove again your ignorance on the issue and reinforce your reluctance to learn.
How can you take a FDR which shows 77 all the way back at the yellow dot, and make up lies?
Why worry about the function of the FDR, when you fail to understand the data stored in it?
Reality, the FDR is not indestructible, and data can be missing for causes beyond Turbofans one dimensional approach to 77 FDR issues.
bje
Graduate Poster
- Joined
- Mar 24, 2007
- Messages
- 1,281
Who would have ever thought the word "impact" would sound so sweet coming from Turbofan.
Caustic Logic
Illuminator
- Joined
- Apr 24, 2007
- Messages
- 4,494
Reasonable people will generally come to an agreement, and I despise unreasonable people who refuse to find any common ground. I also have no clue, nor intend to get one, about the finer points of all this FDR frame stuff. So it's discouraging to see no agreement on anything substantial reached, just a certainty slap-fest where on a fact-by-fact basis I can't say who's right.
That said, Turbofan's over-the-top dismissal of anything Mackey says, and the few points I do understand where he's got ***** backwards and charges ahead with full gusto, the LMAOs and Mackey's general reasonableness and patience in the face of this, makes this debate easy enough to call.
That said, Turbofan's over-the-top dismissal of anything Mackey says, and the few points I do understand where he's got ***** backwards and charges ahead with full gusto, the LMAOs and Mackey's general reasonableness and patience in the face of this, makes this debate easy enough to call.
Edited by chillzero:
Do not breach Rule 10 in your posts.
Last edited by a moderator:
Mr.Herbert
Graduate Poster
- Joined
- Feb 23, 2007
- Messages
- 1,449
Watch out Ryan.... Ranke is getting ready to "expose" you. I'm wondering if he found that tape Ryan made with Paris!!!
http://www.abovetopsecret.com/forum/thread392312/pg14#pid5004561
http://www.abovetopsecret.com/forum/thread392312/pg14#pid5004561
DavidJames
Penultimate Amazing
I going to look around the web and see if I can find where TurboFan makes those posts. Since he claims to have 15 years of electronics background, I'll try and narrow down the possibilities.
Is there a 9/11 ToasterOven Owners For Truth forum?
Is there a 9/11 ToasterOven Owners For Truth forum?
Last edited:
Oh, you apparently don't know the latest. He has supposedly exposed you several times in this thread. You can look as hard as you want go get a good "belly laugh", but it will be impossible to find where he has exposed you.
You know who he is here, so I suggest you tag him the next time he appears.
Caustic Logic
Illuminator
- Joined
- Apr 24, 2007
- Messages
- 4,494