AA77 FDR Data, Explained

[Turbofan]

AA 587 shows a clear example of such weird behavior. Not quite identical, but once again, your position demands AA 587's record is also "impossible." You're wrong here, and you're wrong on AA 77. All you have to offer so far is excuses.

Hey, I don't see any corrupt bits hanging around after :45 in AA77's FDR file.

Like mentioned above, you still have to deal with DME, and clock sync errors.

Your erase theory still doesn't make sense, so until you can show how 2-4 seconds
of data can be erased from the flash chip AFTER it has been laid down, we'll
debate it.

You "ripped apart" nothing, and my calculation was based on Cap'n Bob's setup of the problem. He set it up, he just couldn't solve it properly, despite it being a freshman High School algebra problem.

That's right "I" didn't rip it apart, but Rob and his team of engineers sure did.
It's in video format and points out the errors you made when trying to relate
your data to the offical flight path and FDR data.

No. The signal is not present at all times. The RADALT assembly only sends a signal on each pulse, after computation, and it may or may not be stored in a read-many register. Since you said the output was "ARINC-ready," that implies it's sent at intervals as part of a negotiated packet structure. It has nothing to do with "how electricity works."

Ok Mr. Semantics, when the first bit is clocked and ready, how long does it
take for that voltage level to present itself at the FDAU.

PLEASE give me a value for the last time so we can put together some sort
of latency between sensor and DFDAU.

What the DFDAU does with it is also not continuous and instant. It will surely wait to poll other information to merge it into a subframe. That takes time. Could be 125 milliseconds, could be seconds, who knows for sure -- you don't, because you haven't asked these questions. The specs you quoted have nothing to do with these design realities. You should find better advice, as you are clearly well out of your field if you believe, or expect me to believe, your claims.

Yes, 500 msec. MAX. That has already been asked.

 

[Mangoose]

So, no answer to my question, Turbofan?

 

[WildCat]

Turbofan keeps spewing nonsense, and it doesn't cause him a bit of pause that there's not a single FDR expert who agrees with the pretend FDR experts at PffffT.

Unbelievable.

 

[R.Mackey]

Hey, I don't see any corrupt bits hanging around after :45 in AA77's FDR file.

I've explained this repeatedly -- that's because you're looking at a file that may well contain only validated parameters. The FDR does not have a file system. You have no way of knowing whether there was garbage on the chip itself. Additionally, according to beachnut there is indeed some flakiness in AA 77's last second or two -- time markers without valid (or any) data, that kind of thing.

Like mentioned above, you still have to deal with DME, and clock sync errors.

Within tolerance. I challenged you to show otherwise on the last page. You dodged.

Your erase theory still doesn't make sense, so until you can show how 2-4 seconds
of data can be erased from the flash chip AFTER it has been laid down, we'll
debate it.

Showed you multiple mechanisms. It makes sense to everyone else. Stop repeating yourself.

That's right "I" didn't rip it apart, but Rob and his team of engineers sure did.
It's in video format and points out the errors you made when trying to relate
your data to the offical flight path and FDR data.

If you're talking about the "hockey stick" flight path hypothesis, you've got to be kidding me. That is surely not consistent with ANY flight data. The FDR shows nothing of the kind.

Cap'n Bob has engineers? Then how in the heck did they fail to solve a simple parabolic word problem??

Once again, the setup I used was his setup. You are attempting to challenge that setup, but without presenting an alternative. How this is my fault, or my error, you're going to have to explain in detail.

Ok Mr. Semantics, when the first bit is clocked and ready, how long does it
take for that voltage level to present itself at the FDAU.

Temper, Turbofan. The time depends on the system capacitance and drive current of the RADALT send assembly, but given the bus requirements should be in the range of microseconds. But that doesn't enter into it. Whether the DFDAU is ready to process it, that matters. So does what it does with the data next.

PLEASE give me a value for the last time so we can put together some sort
of latency between sensor and DFDAU.

Why should I be like you and make up a number? Boeing knows this, not me, and not you. Go find it. I can help you phrase the question properly, but I do not know the answer. My point, again, you keep hiding from, is that the questions you've asked, the specs you've received, are only a small part of the answer.

Yes, 500 msec. MAX. That has already been asked.

For example, this. This is another part. Not the whole thing. There are gaps in between. Talk to a flight data bus systems engineer, not a salesman, and ask the right questions. You should have been doing this years ago, and Cap'n Bob's "engineers" shouldn't need to be told, if indeed they exist.

 

[Turbofan]

I've explained this repeatedly -- that's because you're looking at a file that may well contain only validated parameters. The FDR does not have a file system. You have no way of knowing whether there was garbage on the chip itself. Additionally, according to beachnut there is indeed some flakiness in AA 77's last second or two -- time markers without valid (or any) data, that kind of thing.

Right, but they left this 'garbage' on AA 587's file.

Anyway, as I've explained a few million times DME and clock sync are working
against you aside from ALT.

Within tolerance. I challenged you to show otherwise on the last page. You dodged.

No dodge here as you have mistaken once again. DME is +/- 0.1 nm, clock
sync is 0.01 seconds.

Showed you multiple mechanisms. It makes sense to everyone else. Stop repeating yourself.

Your multiple mechs don't account for DME, clock sync, alt. It does not
explain how 2-4 seconds of data can be erased from CPM after is has been
written.

Once again, your theories only account for a small share of the pie.

If you're talking about the "hockey stick" flight path hypothesis, you've got to be kidding me. That is surely not consistent with ANY flight data. The FDR shows nothing of the kind.

No, I am talking about tthe video that takes your drawing and speaks about it.

Temper, Turbofan. The time depends on the system capacitance and drive current of the RADALT send assembly, but given the bus requirements should be in the range of microseconds. But that doesn't enter into it. Whether the DFDAU is ready to process it, that matters. So does what it does with the data next.

Oh god...

Which ever way you slice it, you need to get there within 500 msec. Simple
as that.

YOu are also forgetting that the data is sent along with a time stamp which
means you're getting the current device info when clocked into the frame.

For example, this. This is another part. Not the whole thing. There are gaps in between. Talk to a flight data bus systems engineer, not a salesman, and ask the right questions. You should have been doing this years ago, and Cap'n Bob's "engineers" shouldn't need to be told, if indeed they exist.

Here's a clue, the FAA, EUROCAE, and all those fun organizations make up
rules and regulations for the data acq. systems.

Manufacturers who want to play the game must design their equipment to
meet, or exceed the specification.

If the device does not meet spec, it cannot be certified and used in a
commerical airliner.

Salesmen know this. Design Engineers know this. You should know this.

Therefore the system design, and the components used with the system
are well within the limits. Your latency garbage is for the birds.

Maybe we can ask MacGyver if he thinks the system randomly inserts
delays to make your theory work when you want it to?

 

[R.Mackey]

Right, but they left this 'garbage' on AA 587's file.

Ah, no. The AA 587 analysis didn't work from any file. They looked at the chip directly, being genuine experts with the proper tools. Something your friends didn't and couldn't do. Please tell me you understand the difference?

Anyway, as I've explained a few million times DME and clock sync are working
against you aside from ALT.

I don't understand what this is supposed to mean.

No dodge here as you have mistaken once again. DME is +/- 0.1 nm, clock
sync is 0.01 seconds.

This is not an explanation. It's two assertions with no connection to anything. Explain your claim, don't just tack on new ones.

Your multiple mechs don't account for DME, clock sync, alt. It does not
explain how 2-4 seconds of data can be erased from CPM after is has been
written.

Show me. And "erased after written" is only one of several candidates. You keep pulling this evasion; it didn't work before, it won't work now.

Once again, your theories only account for a small share of the pie.

Explain.

No, I am talking about tthe video that takes your drawing and speaks about it.

Cap'n Bob's "engineers" only speak in video form..?

I've asked you on probably six different threads now -- give me boundary conditions, and I will find you a flight path. You have never taken me up on this. Nor did Cap'n Bob in his various guises. Why not?

Oh god...

Which ever way you slice it, you need to get there within 500 msec. Simple
as that.

YOu are also forgetting that the data is sent along with a time stamp which
means you're getting the current device info when clocked into the frame.

Flashbacks to ten pages ago. The timestamp exists because there is time smear. If it was as simple as you claim, wouldn't be necessary. Funny, huh?

Here's a clue, the FAA, EUROCAE, and all those fun organizations make up
rules and regulations for the data acq. systems.

Manufacturers who want to play the game must design their equipment to
meet, or exceed the specification.

If the device does not meet spec, it cannot be certified and used in a
commerical airliner.

Salesmen know this. Design Engineers know this. You should know this.

Therefore the system design, and the components used with the system
are well within the limits. Your latency garbage is for the birds.

Let me explain the most fundamental principle of engineering. You cannot levy requirements on someone who isn't your customer. L-3 and Rockwell etc. are working to a spec that describes a piece of the system. They can neither sense nor verify a system-level requirement. That is Boeing's problem.

Why won't you ask them? Why won't you ask them the right questions? You seem to have no trouble asking the wrong questions of the wrong people, so it isn't fear of looking foolish.

Maybe we can ask MacGyver if he thinks the system randomly inserts
delays to make your theory work when you want it to?

You may ask him, but since that isn't my theory, and he is sure to read the thread, I would anticipate him again reminding you not to twist words around. Assuming he responds at all, that is.

 

[jaydeehess]

List the crash examples that have occured which meet your requirement that they are similar to AA77, or accept the examples of lost data from crashes that did occur, or admit that this was a once in a lifetime occurance.

I don't admit anything without a logical explanation my friend.

A logical explanation for why there has never been a crash that would satisfy yourcall for us to show one that does?

You have set the bar at a crash that is similar to that of AA77. If there has never been one, ever, you are calling for us to produce a report of a crash that has not occured.
If there is one that would satisfy your stipulation that it be similar to the flight of AA77 then by all means let us know.

Not according to the flash memory expert you contacted and who was good enough to post here.

Yes, he is good for posting here. Have we determined how a few seconds
of info gets wiped out once written to memory? No, not yet.

Please review his posts. He has stated that a block that had only a few seconds worth of data in it could be erased at impact thus eliminating those few seconds worth of data.
retroactive ETALet it be known henceforth that I, MacGyverS2000, in no way, shape, or form, support the findings and/or claims of TurboFan. I am making this statement, to be posted whenever my name and/or claims are invoked by TurboFan, due to his incessant failure to publicly acknowledge that I have succinctly and scientifically shown all of his claims of EEPROM flash failure modes to be incorrect and seriously flawed. While he cannot find fault with any of the multiple scenarios and realizable scientific proof I have provided, his obtuse attitude towards the obvious conclusion (i.e., flash memory can lose data) forces me to wash my hands of any further debate with him until such time as he's willing to see (and admit) reason. While I in no way support any one particular theory, I feel the need to separate myself from any individual who, metaphorically speaking, chooses to shake my hand in friendship when they want something and ignore me when I'm no longer of use.

Which also means that Pft took their original page of meaningless arithmetic and ripped it apart. Mackey's calcs were based upon the parameters supplied by PfT in the original nonsensical page of arithematic. If those parameters were so worthy of rolled eyes then take it up with PfT

However all PfT did to 'correct' their own nonsense was draw a picture and , with no explanation as to how they determined that their radial lines were perpendicular to a tangent of the arc they drew, fudged their way through to arrive at even larger g acellerations than they got using the original nonsense.

The trouble is, Mackey's calcs are not based on the flight data.

I bolded the part you missed.
I notye that you and PfT refuse to address how the perpendicularity of the radial lines was determined, other than 'it looked kinda like it would be about right to us'.

PfT will not however deign to try using the same math on any flight path that the plane might take to do what is claimed, fly from over Columbia Pike to a point(any point) that could be characterized as NoC to a point over(or at least close to) the accepted point of contact with the Pentagon wall, and having that flight path be consistent with all witness descriptions of a fast and low aircraft (low enough to fool people into believing it hit a low floor of the Pentagon) that did not display extreme bank angles

.

A point ignored by TF

Why no pretty drawings of the NoC flight path with radial lines and lateral g forces calculated? Why no pretty drawings showing the plane below the roofline of the Pentagon as it passes by the Citgo and then over the Pentagon as it passes over that building? Instead, only handwaving arguements about how the actual flight path cannot be analyzed?

The reason for that is we believe in a flyover. It's easy enough to
throw together and a flight path NoC; I've already offered to do that.
This has already been covered in the other thread, so no need to go off
topic here.

Soooo, you won't do it because you simply believe. Note that I ask for both a drawing of the flight path and the same analysis done by PfT on the south path's vertical manouver to be done on a NoC path.

Rockwell has no interest in how often the DFDAU polls, collects, ingests data from it's or any other reporting device.

Rockwell's spec is for how long their (Rockwell's) device takes to process signals and create a signal ready for the DFDAU to poll, collect or ingest.

That is correct so we've established the signal generation and transmit
time.

We also have the MAX allowable time of 500 msec for this signal to store
itself to CPM.

Rockwell's number is only the generation of the signal, that means nothing concerning when the DFDAU will collect that parameter nor does it have anything at all to do with when it will be ensconced in the flash memory.

The 0.5 sec spec cannot be what you claim it is if the buffer stores an entire frame (which takes 1 second to collect and compile) before that frame gets sent to flash.

L3, and Rockwell now! Do either of these companies support the conclusions reached by PfT?

No, neither of them will comment (1000th time I've said this now), and neither
of them have submitted a statement supporting the OGCT. So they are
not taking any side, they are simply not commenting.

Why does PfT continue to argue inccessantly with internet persona whom they (PfT) claim do not have the expertise to offer any intelligent counter to PfT's claims? Why does PfT steadfastly refuse to write up a consise and objective technical paper illustrating how they arrive at the conclusion that the FDR data shows a grossly different flight path than the one illustrated by the lamp post damage?

Just trying to put to rest the myths that stem from people on this site.
Besides it's fun.

So none of this is very serious to you. I could have sworn that Rob Balsamo claims this is a very important subject, even going so far as to say it is cause for revolution and extra-judicial executions.
My bad, I guess he was just having fun.

 

[MacGyverS2000]

Not according to the flash memory expert you contacted and who was good enough to post here.

Yes, he is good for posting here. Have we determined how a few seconds of info gets wiped out once written to memory? No, not yet.

I am simply beside myself at this point, Turbo. On a point-by-point basis you can find no fault with every theoretical or realistic possibility I offer for how flash memory can be corrupted, yet when asked by someone else if my arguments are faultless you say 'no'. Which is it?

Because of this duplicity, you force me to put into writing my personal thoughts on the matter. I hereby expect all other members of the JREF forums to repost the following paragraph in response to any post TurboFan writes which invokes my name or any of the information provided by me. This should be done from this date and time forward and continue to do so until such date and time that the facts stated in the following paragraph become invalid or moot.



Let it be known henceforth that I, MacGyverS2000, in no way, shape, or form, support the findings and/or claims of TurboFan. I am making this statement, to be posted whenever my name and/or claims are invoked by TurboFan, due to his incessant failure to publicly acknowledge that I have succinctly and scientifically shown all of his claims of EEPROM flash failure modes to be incorrect and seriously flawed. While he cannot find fault with any of the multiple scenarios and realizable scientific proof I have provided, his obtuse attitude towards the obvious conclusion (i.e., flash memory can lose data) forces me to wash my hands of any further debate with him until such time as he's willing to see (and admit) reason. While I in no way support any one particular theory, I feel the need to separate myself from any individual who, metaphorically speaking, chooses to shake my hand in friendship when they want something and ignore me when I'm no longer of use.

 

[jaydeehess]

Quote: Mackey
What the DFDAU does with it is also not continuous and instant. It will surely wait to poll other information to merge it into a subframe. That takes time. Could be 125 milliseconds, could be seconds, who knows for sure -- you don't, because you haven't asked these questions. The specs you quoted have nothing to do with these design realities. You should find better advice, as you are clearly well out of your field if you believe, or expect me to believe, your claims.

Yes, 500 msec. MAX. That has already been asked.

Now the 500msec is something different again. Now it is the time it takes for the DFDAU to collect and merge a parameter into a subframe. Still has to get from buffer to memory then Turbo, oops now you are taking longer than 500msec to have that data in the memory, and only if the buffer starts sending that frame to memory in a continuous fashion, which is not what you stated before, nor does it corresspond with the way most flash memory works in which the write command sees a block of words written. If the write block is 32 words long it will take approx 1/8th second at 256 w/s for each write block to be stored in flash. So if it is now 500ms to collect and compile a data point plus 125 ms to have that data point stored in memory you are up to 750 ms.

 

[Bobert]

Did YOU GET THAT TF?
Lets see it one more time just in case you missed it:

Let it be known henceforth that I, MacGyverS2000, in no way, shape, or form, support the findings and/or claims of TurboFan. I am making this statement, to be posted whenever my name and/or claims are invoked by TurboFan, due to his incessant failure to publicly acknowledge that I have succinctly and scientifically shown all of his claims of EEPROM flash failure modes to be incorrect and seriously flawed. While he cannot find fault with any of the multiple scenarios and realizable scientific proof I have provided, his obtuse attitude towards the obvious conclusion (i.e., flash memory can lose data) forces me to wash my hands of any further debate with him until such time as he's willing to see (and admit) reason. While I in no way support any one particular theory, I feel the need to separate myself from any individual who, metaphorically speaking, chooses to shake my hand in friendship when they want something and ignore me when I'm no longer of use.

Amazing how whenever an expert weighs in from outside of the truth movement/JREF they ALMOST ALWAYS come to the same feeling as expressed above.

Can someonw post this over at ATS?
This should go down as YET ANOTHER CIT defeat.

 

[Turbofan]

I am simply beside myself at this point, Turbo. On a point-by-point basis you can find no fault with every theoretical or realistic possibility I offer for how flash memory can be corrupted, yet when asked by someone else if my arguments are faultless you say 'no'. Which is it?

Sir,

We are talking about data which has been written to memory and stored.

From that stored data, we are talking about "erasing" just a few seconds
worth.

We are not talking about corruption.

From this clarification, do you agree or disagree that a transient can pick out
a few frames of data and ERASE it from the memory chip?

IE: 1111 1111 1111 x 256 words per frame.

Keep in mind this is happening as power is decaying.

FYI: I'm not looking to become friends, however I do appreciate your HONEST
and detailed reply of how certain words can be erased without wiping out a block of data.

 

[Turbofan]

Now the 500msec is something different again. Now it is the time it takes for the DFDAU to collect and merge a parameter into a subframe. Still has to get from buffer to memory then Turbo, oops now you are taking longer than 500msec to have that data in the memory, and only if the buffer starts sending that frame to memory in a continuous fashion, which is not what you stated before, nor does it corresspond with the way most flash memory works in which the write command sees a block of words written. If the write block is 32 words long it will take approx 1/8th second at 256 w/s for each write block to be stored in flash. So if it is now 500ms to collect and compile a data point plus 125 ms to have that data point stored in memory you are up to 750 ms.

My god.

500 msec is the time for the signal to get from SENSOR TO CRASH PROTECTED MEMORY
as per SPEC.

 

[lapman]

My god.

500 msec is the time for the signal to get from SENSOR TO CRASH PROTECTED MEMORY
as per SPEC.

You must have a copy of the spec. Please post the portion of the spec that covers this.

 

[Bobert]

Sir,

We are talking about data which has been written to memory and stored.

From that stored data, we are talking about "erasing" just a few seconds
worth.

We are not talking about corruption.

From this clarification, do you agree or disagree that a transient can pick out
a few frames of data and ERASE it from the memory chip?

IE: 1111 1111 1111 x 256 words per frame.

Keep in mind this is happening as power is decaying.

FYI: I'm not looking to become friends, however I do appreciate your HONEST
and detailed reply of how certain words can be erased without wiping out a block of data.

MacGyver has asked this to be posted when you bring up his name.

Let it be known henceforth that I, MacGyverS2000, in no way, shape, or form, support the findings and/or claims of TurboFan. I am making this statement, to be posted whenever my name and/or claims are invoked by TurboFan, due to his incessant failure to publicly acknowledge that I have succinctly and scientifically shown all of his claims of EEPROM flash failure modes to be incorrect and seriously flawed. While he cannot find fault with any of the multiple scenarios and realizable scientific proof I have provided, his obtuse attitude towards the obvious conclusion (i.e., flash memory can lose data) forces me to wash my hands of any further debate with him until such time as he's willing to see (and admit) reason. While I in no way support any one particular theory, I feel the need to separate myself from any individual who, metaphorically speaking, chooses to shake my hand in friendship when they want something and ignore me when I'm no longer of use.

 

[Turbofan]

Ah, no. The AA 587 analysis didn't work from any file. They looked at the chip directly, being genuine experts with the proper tools. Something your friends didn't and couldn't do. Please tell me you understand the difference?

Well those same 'experts' didn't see any sort of erasure, or corruption of bits
in their 'expert' analysis of AA77's FDR, or it would have been included in the
report.

My friends never had the chip itself, otherwise I assure you they would have
the resource and ability.

Show me. And "erased after written" is only one of several candidates. You keep pulling this evasion; it didn't work before, it won't work now.

Erased a few seconds of data is not likely after written without wiping out
an entire block along with it. This is the detail that I don't believe MacGyver
is getting due to the smoke and mirrors presented by yourself and many other
members here.

Cap'n Bob's "engineers" only speak in video form..?

I've asked you on probably six different threads now -- give me boundary conditions, and I will find you a flight path. You have never taken me up on this. Nor did Cap'n Bob in his various guises. Why not?

Are you kidding me? After COUNTLESS attempts to get you guys in a room,
or live on radio which you FLAT OUT REJECTED!

Do you have a change of heart now? Would you like me to set it up?

That is Boeing's problem.

No, that would be ARINC's problem.

So, can we setup this meeting and/or phone call now?

 

[Turbofan]

No problem, I'd like to keep this on top to get his reply asap.

Particularly about this quote:

A1: This depends on the flash unit in use, but anything that is sized to hold megabits of data (such as the Intel unit posted way back when) will have page sizes in the 32kB (for boot blocks) to the more common 128kB-512kB range (for normal data blocks). You can see a smaller portion of a block get erased should a transient happen during the erasure cycle, but this is not standard operation.

Does this also apply to previously recorded blocks which are currently not
addressed/enabled for erasure?

IE: Arbitrarily selecting erase lines of stored blocks and taking out a few
frames worth of data?

MacGyver has asked this to be posted when you bring up his name.

Sir,

We are talking about data which has been written to memory and stored.

From that stored data, we are talking about "erasing" just a few seconds
worth.

We are not talking about corruption.

From this clarification, do you agree or disagree that a transient can pick out
a few frames of data and ERASE it from the memory chip?

IE: 1111 1111 1111 x 256 words per frame.

Keep in mind this is happening as power is decaying. 200-400 msec.

FYI: I'm not looking to become friends, however I do appreciate your HONEST
and detailed reply of how certain words can be erased without wiping out a block of data.

 

[Bobert]

I really dont think that MacGyver is going to address you further.
Now you are just playing games with the above post.
I am sure based on the CIT playbook your next step will be to insult and misquote him.
I hope that the mods take note of this behavior on your part.

 

[jaydeehess]

My god.

500 msec is the time for the signal to get from SENSOR TO CRASH PROTECTED MEMORY
as per SPEC.

Mackey stated:

What the DFDAU does with it is also not continuous and instant. It will surely wait to poll other information to merge it into a subframe. That takes time.

Your response was that it would take 500 msec.

Now you go back to 500msec to have a signal from any particular sensor go from that sensor, to the DFDAU, be compiled to its subframe and fill the buffer to a full frame (this is what you have stated in the past) at which point the frame is sent to the flash memory. However the data rate is 256 words per second meaning it will take at least one second for a frame to be inputted to the DFDAU before the DFDAU outputs it at the same rate to the flash memory.

If you wish to make the write block smaller than one full frame let's have the size of it.

Does this also apply to previously recorded blocks which are currently not
addressed/enabled for erasure?

Explained many times now.
-The write block is smaller than the erase block.

-Prior to recording to an area that contains old data an erase block command resets a block the size of several dozen frames of data.

-The FDR starts receiving data into that , now reset(erased) block.

-Shortly after starting to fill that cleared block it is erroneously reset again.

-This occurs at impact and, if this is a 'clean' erasure, has effectively erased all trace of the last few seconds worth of data and rest the entire block to all 1's. However, the conditions present are far from ideal and there is no gauruntee that the erasure will be clean and complete to the erase block in question, thus it could still contain some corrupted words (some gates still at at zero)

 

[Turbofan]

I really dont think that MacGyver is going to address you further.
Now you are just playing games with the above post.
I am sure based on the CIT playbook your next step will be to insult and misquote him.
I hope that the mods take note of this behavior on your part.

my question is valid as I believe he is still referring to data corruption.

This is not about whether, or not data can be erased from EEPROM, it
is about erasing a few frames/seconds of data under the conditions of
power decay by transient.

As he has quoted, the block erase size is approximately 128K for data
blocks. We are talking about 14K of data.

My question still stands: If gates are tied together for block erase,
how does just a few of these gates received the erase voltage without
wiping out the entire block?

Furthermore, as power decays how is the gate biased with sufficient
voltage such that the atransistors are able to change state.

 

[Turbofan]

However the data rate is 256 words per second meaning it will take at least one second for a frame to be inputted to the DFDAU before the DFDAU outputs it at the same rate to the flash memory.

No, that is totally incorrect. It will not take at least one second. If that
were true, the system would have constant delay and crash.

You still do not understand.

All you need to remember is MAX time for data to store itself into CPM is
500 msec from the sensor.

Explained many times now.
-The write block is smaller than the erase block.

OK.

-Prior to recording to an area that contains old data an erase block command resets a block the size of several dozen frames of data.

OK

-The FDR starts receiving data into that , now reset(erased) block.

OK

-Shortly after starting to fill that cleared block it is erroneously reset again.

OK...

-This occurs at impact and, if this is a 'clean' erasure, has effectively erased all trace of the last few seconds worth of data and rest the entire block to all 1's.

Not OK. It can't erase JUST the last few seconds. It must take out the
entire block as per design.