New FDR Decode

reply to post by JFrickenK

Glad I could help. This is the kind of research that I really enjoy doing.

Originally posted by 911files

Originally posted by thomk

Originally posted by 767doctor

Bobby needs to show this exact schematic from AA's manual which shows a connection from the flight deck door sensor(S10165 in this drawing) to EICAS.

I disagree.

If he wants to make his case, he has to show a connection of the door sensed signal all the way to the input of the FDR.


TomK

I disagree with both of you. To make his case he has to show evidence that the parameter was actually being recorded. In other words, at least one instance of change in the recorded parameter in 42 hours of data. He can't, so the rest is just interesting trivia.

Perhaps you can show me the data path which generated column 106 in AAL77_tabular.csv, which was obviously recorded ?

I didn't think so.

Originally posted by thomk
I disagree.

If he wants to make his case, he has to show a connection of the door sensed signal all the way to the input of the FDR.
TomK

Unfortunately, the only connection to the FDR is a serial data connection
from the FDAU.

The best you're going to get is a connection from the door circuit to the
EICAS. The documentation shows Port 41 for door messages. Port 41
is buffered by EICAS; IE: All door monitoring routes through EICAS as
per schematic and DFL.

Originally posted by JFrickenK

Originally posted by 911files

Originally posted by thomk

Originally posted by 767doctor

Bobby needs to show this exact schematic from AA's manual which shows a connection from the flight deck door sensor(S10165 in this drawing) to EICAS.

I disagree.

If he wants to make his case, he has to show a connection of the door sensed signal all the way to the input of the FDR.


TomK

I disagree with both of you. To make his case he has to show evidence that the parameter was actually being recorded. In other words, at least one instance of change in the recorded parameter in 42 hours of data. He can't, so the rest is just interesting trivia.

Perhaps you can show me the data path which generated column 106 in AAL77_tabular.csv, which was obviously recorded ?

I didn't think so.

Perhaps you can show me an incidence of the door being open in 42 hours of recorded flight operation.

I didn't think so....

Originally posted by thomk
All of PfT's maintenance & circuit hand-waving is incompetent nonsense. Turbofan is not an aircraft mechanic. He is an auto mechanic. He has precisely zero time maintaining aircraft.

No, I am not an automechanic. I don't know who started that rumour,
but it's incorrect. I have a side business which caters to performance
tuning/building, and retail sales.

The only time I had a "full time" position in automotive was for about six
months in 2008 when I left a job in electronics to pursue other interests...
and that was to run my shop.

Your other question:

I currently work in the satellite industry. My focus is RF communication and behaviour
in systems when launched into space. Since 1995 I have been working
with military, and/or government related projects including tuning waveguides
for NORAD systems when working at Raytheon.

No, I have never repaired an airplane however I have read, interpreted and
drawn THOUSANDS of digital/analog schematics, diagrams, etc.

[edit on 7-12-2009 by turbofan]

reply to post by 911files


I see my point went right over your head.

@ Tino, Have you had a chance to look at what I am referring to ?

I have not been able to follow it past the combining of the 2 signals into one.
( toward the EICAS )

Yet it IS recorded in the official CSV file, and that value does fluctuate.

Edit to add - Start at 28-21-02 and work towards the column 106 output of AAL77_tabular.csv

[edit on 7-12-2009 by JFrickenK]

Originally posted by JFrickenK
reply to post by 911files

 

I see my point went right over your head.

No, your point is moot. Unless you can show an incidence of the door being open, then there is no way to establish it as a functional parameter. You can speculate, spew technobabble for 20 more pages and it will not change the fact that the value in that bit did not change in 42 hours of recorded data. You are simply trying to blow smoke up everyone's skirt to detract from that fact (not speculation). Now it is up to everyone else to determine how reasonable is it to beleive the door was never opened. Not a very reasonable assertion.

Originally posted by 911files

Originally posted by JFrickenK
reply to post by 911files

 

I see my point went right over your head.

No, your point is moot. Unless you can show an incidence of the door being open, then there is no way to establish it as a functional parameter. You can speculate, spew technobabble for 20 more pages and it will not change the fact that the value in that bit did not change in 42 hours of recorded data. You are simply trying to blow smoke up everyone's skirt to detract from that fact (not speculation). Now it is up to everyone else to determine how reasonable is it to beleive the door was never opened. Not a very reasonable assertion.

Actually it is not moot at all. If there is no path from those sensors to the outputted data in column 106, HTF did those values get recorded in the CSV file which was released via FOIA ?

BTW, the door thing was pages ago... Do try and keep up.

[edit on 7-12-2009 by JFrickenK]

I think it's hilarious --- but, in a very sad way, that over at PfffT, on the home page, the 'Pentagon Aircraft Hijack Impossible" is still prominently displayed.

Truly if not criminal, then I don't know what else defines it....how many people are being duped, even as we sit here?

Tick, tock.

And, of course...no room for dissent, not for the discussion that has taken place here, nothing to tell those naive people who eagerly send their money in that it's all a sham.

Caveat Emptor.

Originally posted by JFrickenK
Actually it is not moot at all. If there is no path from those sensors to the outputted data in column 106, HTF did those values get recorded in the CSV file which was released via FOIA ?

BTW, the door thing was pages ago... Do try and keep up.
[edit on 7-12-2009 by JFrickenK]

BTW, there is no state change recorded ... do try and keep up. The last few pages have been dances around the issue.

Originally posted by 911files

Originally posted by JFrickenK
Actually it is not moot at all. If there is no path from those sensors to the outputted data in column 106, HTF did those values get recorded in the CSV file which was released via FOIA ?

BTW, the door thing was pages ago... Do try and keep up.
[edit on 7-12-2009 by JFrickenK]

BTW, there is no state change recorded ... do try and keep up. The last few pages have been dances around the issue.

So in your own words, how was the data in column 106 generated with no apparant link to the sensors which it was monitoring ?

In your own time.

Originally posted by JFrickenK

Originally posted by 911files

Originally posted by JFrickenK
Actually it is not moot at all. If there is no path from those sensors to the outputted data in column 106, HTF did those values get recorded in the CSV file which was released via FOIA ?

BTW, the door thing was pages ago... Do try and keep up.
[edit on 7-12-2009 by JFrickenK]

BTW, there is no state change recorded ... do try and keep up. The last few pages have been dances around the issue.

So in your own words, how was the data in column 106 generated with no apparant link to the sensors which it was monitoring ?

In your own time.

I stay away from things I am not qualified to speak to. I keep try to keep it simple. We have a file that is a record of the serial bit data stream. I can speak to data streams and was intimately involved with this one. For 42 hours of recording, the value which some folks claim represents FLT DECK DOOR remains 0 and is interpreted by the frame layout as CLOSED. It never changes. There could be multiple reasons for this.

a) The door was never opened in 42 hours of recorded operation.
b) The bit position is not the one we think it is (software "bug").
c) The parameter is not active (not "hooked up").

Since a) is nowhere near being a rational hypothesis, that leaves b) and c). The hypothesis promoted by P4T is a) and I'll leave it to you and others to debate b) and c). However, without a state change in the bit (an instance of 1, or OPEN), a) can NEVER be validated since only a change in state could prove that hypothesis c) is null. All of the other speculation (such as what you are asking me about) is moot. Even if the parameter is "hooked up" to the DAU, it obviously is NOT represented in the data stream, or else reasonable minds are asked to beleive that the door was never opened in 12 recorded flight, pre-flight and post-flight operation. Reasonable minds reject the later.

Originally posted by 911files


I stay away from things I am not qualified to speak to. I keep try to keep it simple. We have a file that is a record of the serial bit data stream. I can speak to data streams and was intimately involved with this one. For 42 hours of recording, the value which some folks claim represents FLT DECK DOOR remains 0 and is interpreted by the frame layout as CLOSED. It never changes. There could be multiple reasons for this.

a) The door was never opened in 42 hours of recorded operation.
b) The bit position is not the one we think it is (software "bug").
c) The parameter is not active (not "hooked up").

Since a) is nowhere near being a rational hypothesis, that leaves b) and c). The hypothesis promoted by P4T is a) and I'll leave it to you and others to debate b) and c). However, without a state change in the bit (an instance of 1, or OPEN), a) can NEVER be validated since only a change in state could prove that hypothesis c) is null. All of the other speculation (such as what you are asking me about) is moot. Even if the parameter is "hooked up" to the DAU, it obviously is NOT represented in the data stream, or else reasonable minds are asked to beleive that the door was never opened in 12 recorded flight, pre-flight and post-flight operation. Reasonable minds reject the later.

And YOU are back on the door thing.

Do you even have a clue as to what column 106 represents ?

[edit on 7-12-2009 by JFrickenK]

[edit on 7-12-2009 by JFrickenK]

Originally posted by JFrickenK

And YOU are back on the door thing.

Yep...

Originally posted by 911files

Originally posted by JFrickenK

And YOU are back on the door thing.

Yep...

Well I am not and have not been for several pages.

You may want to look at what I am talking about.

( lets see if this works since I can't link directly to the .PDF for some reason )

media.abovetopsecret.com...

Cool, that worked... It is columns 1 ( Time stamp ) and column 106 with the NULLs stripped out of AAL77_tabular.csv

[edit on 7-12-2009 by JFrickenK]

Originally posted by JFrickenK

Well I am not and have not been for several pages.

You may want to look at what I am talking about.

I know what you have been talking about, and so do you. It is sorta like "Rob" Mackey and his fdr expert who claims there is no way to know that the other 11 flights were from the same plane. Yeah there is, they are from the same fdr and correspond to the flights reported on P4T. Duh...you guys really are not too bright.

Originally posted by 911files

Originally posted by JFrickenK

Well I am not and have not been for several pages.

You may want to look at what I am talking about.

I know what you have been talking about, and so do you. It is sorta like "Rob" Mackey and his fdr expert who claims there is no way to know that the other 11 flights were from the same plane. Yeah there is, they are from the same fdr and correspond to the flights reported on P4T. Duh...you guys really are not too bright.

I see you now have a one track mind stuck on "door".

If you are unable to see the implications of my point then you are downright stupid.

Onto ignore you go.

Edit to add - I am not Rob nor am I PFT.

BTW, The serial number of that FDR is what ?


[edit on 7-12-2009 by JFrickenK]

Originally posted by 911files

Originally posted by thomk

Originally posted by 767doctor

Bobby needs to show this exact schematic from AA's manual which shows a connection from the flight deck door sensor(S10165 in this drawing) to EICAS.

I disagree.

If he wants to make his case, he has to show a connection of the door sensed signal all the way to the input of the FDR.


TomK

I disagree with both of you. To make his case he has to show evidence that the parameter was actually being recorded. In other words, at least one instance of change in the recorded parameter in 42 hours of data. He can't, so the rest is just interesting trivia.

John,

Correct me if I am wrong, but the recording that we are interested in comes from the FDR. So the door sensor would have to be hooked up to the FDR (either thru the EICAS, or one of the other boxes).

I understand that this data bit may already be encoded into data words per ARINC when passed to the FDR. This would mean simply that you've got to follow the sensor from the door sensing thru all of its formatting & encoding circuits on the way to the FDR. But ultimately, you've got to trace it all the way from the door sensor to the FDR.

As I've said before, I consider all of this unnecessary. Other evidence proves to me that the bit was not recorded.

In my judgment, the lack of a changed bit gives me a 99.9% probability that the bit was not recorded. The fact that it did not bounce around (especially during engine start) tells me that it was not floating. The fact that the cockpit WAS entered during the flight raises the 99.9% probability to 100%.

I am willing to bet a beer with anyone here that, once people have found the RIGHT maintenance manual & schematics, this is exactly what they will find: that the sensor was not sent to the FDR. And that in one of the boxes, that bit was not allowed to float, but was arbitrarily set to Logical 0.

Any takers??

TomK

Originally posted by JFrickenK

Originally posted by 911files

Originally posted by thomk

Originally posted by 767doctor

Bobby needs to show this exact schematic from AA's manual which shows a connection from the flight deck door sensor(S10165 in this drawing) to EICAS.

I disagree.

If he wants to make his case, he has to show a connection of the door sensed signal all the way to the input of the FDR.


TomK

I disagree with both of you. To make his case he has to show evidence that the parameter was actually being recorded. In other words, at least one instance of change in the recorded parameter in 42 hours of data. He can't, so the rest is just interesting trivia.

Perhaps you can show me the data path which generated column 106 in AAL77_tabular.csv, which was obviously recorded ?

I didn't think so.

Perhaps you could reply to the logic that I DID use rather than blather on about the illogic that I did NOT use.

I didn't think so...

TomK

Originally posted by turbofan

Originally posted by thomk
I disagree.

If he wants to make his case, he has to show a connection of the door sensed signal all the way to the input of the FDR.
TomK

Unfortunately, the only connection to the FDR is a serial data connection
from the FDAU.

The best you're going to get is a connection from the door circuit to the
EICAS. The documentation shows Port 41 for door messages. Port 41
is buffered by EICAS; IE: All door monitoring routes through EICAS as
per schematic and DFL.

This is not a problem in the slightest for a competent tech.

You get the right EICAS data manual, and it will describe precisely the data inputs & the data outputs. And it will also describe precisely how unused inputs are tied high or tied low.

There is zero "unfortunately" associated with this.
There is zero "difficulty" interpreting the schematics.


TomK