More, quick, proof that JDX is in way over his head

Anti-sophist

Graduate Poster
Joined
Sep 15, 2006
Messages
1,542
In his recent attempt to "disprove" the pentagon crash using FDR data, he has chosen to now combine two different columns in the FDR to extract his linear trajectory:

He uses the altimeter (or airspeed, maybe) to get an initial velocity, and then uses the G-Force meter to calculate the intermediete and extrapolated velocities. My hypothesis is that the recorded times of these events do not correspond to the measured times.

Under my hypothesis, the altimeter readings or G-Force readings would lag behind, one way or the other, in time, depending on the construction of the system and the PCM dataframe used to record the data. I don't want to get into the technical details of PCM frames here, but suffice to say data has a +/- 1/8 second error, just from the PCM encoding, alone (unless we know the structure of the PCM frame, which I don't believe exists in the public domain)

I used the last 30 seconds of the flight to calculate the acceleration the altimeter felt, based upon reasonable initial velocity and acceleration numbers, and I compared that with the actual G-forces measured.

Keep in mind, this is two seperate sensors, essentially sensing the same quantity:

(purple is the accelerometer, blue is the altimeter)
http://img134.imageshack.us/my.php?image=jdxdelayfn9.png

Keep in mind, these are two seperate measurements, JDX has no problems adding and subtracting, at equal times (noting the differences, in the x-axis, of the peaks and valleys).

The graph clearly shows an average difference of about .5s to .75s, with as much as 2s, between the accelerometer and the altimeter, with the accelerometer measurement delay being more.

What does this mean? The accelerometer data in the CSV file is at least .75 + the measurement delay of the altimeter, from real time. So those acceleration numbers he's using for the final second, didn't happen in the final second.
 
Last edited:
Do'h, I thought it said "More, quick, proof that JDX is on his way over to this thread" :rolleyes:
 
Oh, don't worry, he'll be here. I doubt he'll post anything though. He is much happier being the big math-fish in the very small math-pond over on the LC forum.
 
Anti-sophist, I have a question.

I'm trying to understand your point about the time correlation of the different data channels by analogy to my experience of multi-channel PCM digital audio recording systems, specifically the "modular digital multitrack" machines, i.e., ADAT or DTRS format, which record 8 channels of digital audio on videocassette.

In these systems, each analog input has its own sample/hold and A/D converter. The S/H circuits are driven by the same aperture clock, so sampling for each channel is simultaneous, and the clocking for the A/Ds is shared among all channels, so the conversion for each channel is complete pretty much simultaneously as well.

However, since the videocassette transport has only one recording channel, the data streams from each A/D are buffered and assembled into a frame structure such that they are recorded on the tape sequentially, one channel's worth of data for that sample interval after another.

In playback, the data coming off tape is demultiplexed, buffered and fed to an individual D/A converter for each channel. The sample/hold circuits at the output of each D/A are again all driven by the same aperture clock, so that the analog outputs are once again simultaneous. Since tape transports don't operate at a perfectly constant speed, buffering the off-tape data and reading it out referenced to a stable clock also provides timebase correction.

If the aperture clocks of each of the front-end S/Hs weren't simultaneous, it could still be possible to organize the data coming from each A/D into a frame and record it on the tape, but simultaneity between channels would be lost.

As far as I can tell from the description of the FDR given in the NTSB's Specialist's Factual Report of Investigation for the AA77 DFDR, the recording process is somewhat analogous to what I've just described, with the recorder portion receiving data as a serial, time-multiplexed data stream from the data acquisition system.

If I haven't strained the analogy too far, the simultaneity of data points between channels would be dependent on how the DAQ system handles sampling and quantizing inputs from the different sensors, and without knowing that information there's no way to be sure of whether data points recorded in the same subframe were sampled at the same time.

Is that more or less what you're driving at?

Also, how do you derive the +- 1/8 second figure for the uncertainty due to the encoding?
 
Last edited:
AS said the aircraft needs to pull 3 G's for one full second in order to pull out of that dive. The FDR never gets above 1.7 G's.

I cannot understand why he would use +/- 1/8th of a second. If that is all he has to hold onto for recorded data as it being inaccurate, he has a real problem.

Please review the animation provided by the NTSB. JDX sent me this animation the other day. Headings, airspeed, altitudes, all match the csv file time stamps and real world information such as departure from Dulles.

Bottom line, AS needs to account for 3 G's (his own words) for 1 full second in order to pull out of that dive.

I have also seen JDX's challenge for debate. Here is the full quote.
All/Any JREF'ers are welcome to sign up here for this debate. Once one instance of name calling/ridicule/attempts at character assassination is used.. you're gone.


Once this thread gets off topic due to "You're not a pilot JDX".. you're gone. Either debate the facts above.. or dont post.

Deal?

[crickets chirping]


I guess JREFers cant hold an intellectual debate without name calling. Seems no one wants to debate this....

Im not surprised.. it makes Billzilla look like he doesnt know what he's doing.

I'm sure if you people can refrain from name calling, stick to the topic and debate the facts, it seems JDX welcomes you. However, in my short experience on this site that may not be possible. I haven't done anything here in terms of attacking someone and so far I have been attacked just for posting. JDX also says MarkyX (whoever that is) is pre-registered at Pilots For Truth and knows about it.

You expect JDX to come here? I wouldn't want to either if I were him. Nothing would get done and it would turn into a gang rape bash fest. I sampled that in the short time I have been here and I believe the official reports.
 
im sure people here will line up around the block to debate JDX if an impartial moderator were named, however JDX wont debate unless he has the ability to ban his opponent, makes it look liek hes very afraid of being beaten

just look at the CS/TS1234 "debate" thread, did that turn into a "gang rape bash fest" or did other JREFers keep their own comments out of the debate thread?
 
From what I understand, JDX isn't really concerned about debating people from the internet. He offered an area to submit your "debunks" if you wish.

JDX and his organization are concentrating on ALPA, APA, the NTSB, the FBI and Congressmen to get answers.

The fact is that the FDR shows the aircraft too high. All scenarios were explored and cross-checked. It was not supplemented by a letter from the NTSB showing any errors as was the Mode Control Panel indications.

If AS knows how to correct Pressure Altitude to True Altitude, tell him to start there for the csv file.

The G Forces are only a supplement to cross-check the altitude data. Along with system indications, vertical speed, alternate analysis based on vertical speed, etc.
 
AS said the aircraft needs to pull 3 G's for one full second in order to pull out of that dive. The FDR never gets above 1.7 G's.

Sigh, you don't read very well. I said it needed to pulll 3 G's for one second to pull completely out of the dive (as in, be at 0fpm descent). There is no evidence that is necessary. I said it was _possible_ for a plane to do. You claimed it would rip the wings off.

I do NOT believe that the plane hit the pentagon at 0 fpm descent, therefore I do NOT believe it pulled 3 Gs ever. My point was it was merely _possible_ and wouldn't have ripped off the plane wings. I have never said the plane MUST have pulled 3 Gs to have hit the pentagon.
I don't understand why you keep copy/pasting large sections of text, and completely misquoting me.
 
AS said the aircraft needs to pull 3 G's for one full second in order to pull out of that dive. The FDR never gets above 1.7 G's.

I cannot understand why he would use +/- 1/8th of a second. If that is all he has to hold onto for recorded data as it being inaccurate, he has a real problem.

Please review the animation provided by the NTSB. JDX sent me this animation the other day. Headings, airspeed, altitudes, all match the csv file time stamps and real world information such as departure from Dulles.

Bottom line, AS needs to account for 3 G's (his own words) for 1 full second in order to pull out of that dive.

I have also seen JDX's challenge for debate. Here is the full quote.




I'm sure if you people can refrain from name calling, stick to the topic and debate the facts, it seems JDX welcomes you. However, in my short experience on this site that may not be possible. I haven't done anything here in terms of attacking someone and so far I have been attacked just for posting. JDX also says MarkyX (whoever that is) is pre-registered at Pilots For Truth and knows about it.

You expect JDX to come here? I wouldn't want to either if I were him. Nothing would get done and it would turn into a gang rape bash fest. I sampled that in the short time I have been here and I believe the official reports.


Pity that he bans anyone who tries to debate him - or should I say you ban them as soon as...

Three experienced pilots now - all banned as soon as they disagreed.

Go away you fraud.
 
From what I understand, JDX isn't really concerned about debating people from the internet. He offered an area to submit your "debunks" if you wish.
well thats not a debate, and in the quotes you posted above a debate is clearly referred to

in the past JDX has demanded that rebuttals be emailed to him personally, and "if they are good" he will post them

fat chance, if they are good, he'll delete them and claimed we are ignoring his challenge, and if he has any kind of response he'll post it and ridicule it and never give anyone an opportunity to respond
 
All pilots interpret instruments in their cockpit and cross check it with other instruments to make sure the primary instrument is telling them the truth. That is the basics of Instrument Flight.

JDX and the Pilots for Truth did exactly that when they saw the altimeter showing 480MSL at end of recording. They also tried to get the radar altimeter data through Boeing from the additional raw data .fdr file (not the csv), but Boeing refused to help due to "corporate relationships". One would think that if the additional raw data .fdr file supported gov theory, Boeing would be jumping at the bit to put their name on it. In this respect, JDX and I agree completely.
 
How do you expect JDX to come here and debate you people when 4-6 of you are jumping on me at once? Imagine if he came here. I can't even keep up with your posts. This happened last night.

Have a good day all. This site is useless and gets nothing done. We are going to the real experts such as the NTSB to get answers. Not some net junkies.
 
Anti-sophist, I have a question.

I'm trying to understand your point about the time correlation of the different data channels by analogy to my experience of multi-channel PCM digital audio recording systems, specifically the "modular digital multitrack" machines, i.e., ADAT or DTRS format, which record 8 channels of digital audio on videocassette.

In these systems, each analog input has its own sample/hold and A/D converter. The S/H circuits are driven by the same aperture clock, so sampling for each channel is simultaneous, and the clocking for the A/Ds is shared among all channels, so the conversion for each channel is complete pretty much simultaneously as well.

However, since the videocassette transport has only one recording channel, the data streams from each A/D are buffered and assembled into a frame structure such that they are recorded on the tape sequentially, one channel's worth of data for that sample interval after another.

In playback, the data coming off tape is demultiplexed, buffered and fed to an individual D/A converter for each channel. The sample/hold circuits at the output of each D/A are again all driven by the same aperture clock, so that the analog outputs are once again simultaneous. Since tape transports don't operate at a perfectly constant speed, buffering the off-tape data and reading it out referenced to a stable clock also provides timebase correction.

If the aperture clocks of each of the front-end S/Hs weren't simultaneous, it could still be possible to organize the data coming from each A/D into a frame and record it on the tape, but simultaneity between channels would be lost.

As far as I can tell from the description of the FDR given in the NTSB's Specialist's Factual Report of Investigation for the AA77 DFDR, the recording process is somewhat analogous to what I've just described, with the recorder portion receiving data as a serial, time-multiplexed data stream from the data acquisition system.

If I haven't strained the analogy too far, the simultaneity of data points between channels would be dependent on how the DAQ system handles sampling and quantizing inputs from the different sensors, and without knowing that information there's no way to be sure of whether data points recorded in the same subframe were sampled at the same time.

Is that more or less what you're driving at?

Also, how do you derive the +- 1/8 second figure for the uncertainty due to the encoding?

Ok, there are two major sources for error in FDR PCM data.The first is referneced by the +- 1/8 second mention, for the v.acc, due to the encoding of the PCM.

The PCM stream on the FDR has a major-frame period of 1 second and a minor frame period of 1/8 of a second. The v.acc data was sampled at 8hz, so once per minor frame. There is no way to tell when, in the minor frame, the v.acc was actually sampled. In other words, if the minor frame length was 100 words (say 2 bytes), and the major frame was 800 words (so 800 words per second), then the V.Acc could be words 1,101,201,301,401... or it could be words 99,199,299,399, etc.

This uncertainty results from not knowing the PCM encoding. Your D/A system does know the encoding PCM structure coming in, so it is able to base time on the position of a word inside the PCM structure. This, again, is based on the assumption that data put into the PCM structure at time t was also measured near time t. That is not always a safe assumption. Regardless, we don't know the PCM structure in this case, so our error for each individual data point is +/- the sample frequency of that data point.

So, the altimeter (which is sambled only at 1Hz), could have been sampled at word 1, or it could have been sampled at word 799. They are both part of the same frame, with the same timestamp.

---

Furthermore, in your situation, you sample analog components "in real time", as they are needed in the PCM stream. Digital data from the air-data-computer doesn't have the same luxury. When the PCM stream says "I am at word 117, I need the computer air speed", the Air Data Computer isn't going to drop what it's doing to send that out.

So, the digital half of a DAU, for these systems, buffers these outputs, and timestamps the measurements. So at time=18ms the ADC might say "Ok, here's my altimeter reading: 49", and then at time=47ms, the control unit says "I need altimeter data for the PCM stream", and the DAU will give it the reading it buffered that occured at 18ms.

In the military, we timestamped, individually, all buffered outputs, because the TIME the data was recorded was not the TIME it was measured. There's no way to know, without the PCM structure, if this data is present in the PCM stream. If it's not, then assigning the pcm-location as 'time' for buffered data points is incorrect.

Hopefully that made sense, when I get home tonight, I'll explain it more clearly when I have time draw a picture or two.
 
Last edited:
How do you expect JDX to come here and debate you people when 4-6 of you are jumping on me at once? Imagine if he came here. I can't even keep up with your posts. This happened last night.

Have a good day all. This site is useless and gets nothing done. We are going to the real experts such as the NTSB to get answers. Not some net junkies.
we are simply replying to an open thread, if you want a private debate create a thread and ask that no one else posts in it except your opponent, youd be surprised at the amount of self control we JREFers can excercise :P
 
How do you expect JDX to come here and debate you people when 4-6 of you are jumping on me at once? Imagine if he came here. I can't even keep up with your posts. This happened last night.

Have a good day all. This site is useless and gets nothing done. We are going to the real experts such as the NTSB to get answers. Not some net junkies.


It's unfortunate that you've put no effort to understand my points, or my debunking of JDXs claim. You repeatedly misrepresent my stance on several issues, and have taken several of my quotes out of context to prove points that factually false.

Try to understand the follow points:

!) There is no evidence the plane hit the pentagon at 0 fpm.
Therefore, the plane did not need to make a 3 G turn to hit the pentagon.

2) If the plane hit the pentagon at 0 fpm (which it didn't)
The plane would have needed a 3 G pull-up for one second.
That is not impossible, as you have claimed.

3) I am not an expert, but I know more than JDX. My analysis is more thorough, more scientific, and based on the actual hardware.

4) I fully support you guys going to the real experts to get answers. That is an excellent idea.
 
One would think that if the additional raw data .fdr file supported gov theory, Boeing would be jumping at the bit to put their name on it.

You actually think that Boeing gives a damn about this FDR analysis? :eek: Is it because (a) they're all in on it and are running scared or (b) because the Truth movement is so huge the negative publicity must be hitting their sales? Only a thoroughly brainwashed, deluded Truther could think either of those things. Not somebody, as you claim to be, who's just innocently wandered into this.
 
Last edited:
If I haven't strained the analogy too far, the simultaneity of data points between channels would be dependent on how the DAQ system handles sampling and quantizing inputs from the different sensors, and without knowing that information there's no way to be sure of whether data points recorded in the same subframe were sampled at the same time.

Is that more or less what you're driving at?
Yes, that's part of what he's driving at, but there are other factors that could contribute to the non-simultaneity of the readings. Aircraft instruments have inherently different ways that they sense their data, and inherently different delays in showing a change. I took flying lessons 27 years ago, so I don't remember the details, but I recall that if you're trying to hold level flight, you have three sources of information: the altimeter, the vertical speed indicator, and the sound of the engine. I was taught not to use the VSI (I think that was it and not vice-versa), because the VSI has a delay, but to use the altimeter. A very experienced pilot told me that the sound of the engine is even a better, more immediate indicator, because if you start losing altitude, you gain speed, and engine RPMs go up. Of course, this applies only to the fixed-pitch props that I was flying then.

Anyway, there are more factors to the various delays besides for queueing onto the tape, and A-S's differentiation method clearly shows the end result of all those factors.

A-S, I didn't study it in detail, but a factor that could possibly explain the amplitude differences you see in some areas may be the bank angle. A banking turn would increase the airframe Gs but wouldn't show on the VSI.
 

ISF - Join now!

Every member here is approved by hand. No bots, no spam, just people who care about evidence and honest debate.

Membership is free!

Create your free account

Back
Top Bottom