I can't resist the temptation anymore, I just have to rip apart these earlier calculations Bruce Maccabee has made (as copied from Metabunk). Remember that he seemed to be the go to expert for Garry Nolan for example:
Bruce Maccabee TENTATIVE CALCULATIONS
B. Maccabee
Mar. 9, 2018
(((Plane at 25000 ft = 4.1 nm
Object altitude calculated as: (4.1 nm [height of plane] – (4.1 slant range [plane to object]) x sin 22 = 4.1 – 1.54 = 2.46 below airplane altitude;
Height of object = (height of plane – distance below plane ) = 4.1 – 2.5 = 1.6 nm (not close to surface)
The sensor is aimed 35 deg left of plane axis and this angle increases to 57 or 58 so at the end so the object was traveling with a velocity component parallel to the track of the airplane.
Estimated size of object based on apparent size of black-hot image is approx. (1.5 deg angular width of screen based on narrow FOV) x ([1.5 mm to 2mm diameter of black dot image size on 92 mm wide screen]/[92mm screen width]) x 0.0174 rad/deg x 4.1 nm[slant range] x 6077 ft/nm = 10 to 15 ft!....
At 4.1 nm range to the object, the distance across the 1.5 deg FOV is (4.1nm) x [1.5 deg x 0.0174 rad/deg]= 0.1 nm.
It crosses the FOV at about a 45 deg angle so the actual approximate distance across the FOV is 0.1 nm/0.707 = 0.14 nm;
it crosses in 4 to 3 sec implying a differential speed of the plane and object of 0.14 nm/ ( 4 to 3 sec)/(one hour/ 3600) = 126 to 170 kt)…
Since the plane is going at about 250 kt the object was going at the speed approx. (250 – 150) = 100 kt in the same direction as the airplane but clearly slower)calculation assumes land speed is approx. same as air speed) )))
Let's go through those step by step:
(((Plane at 25000 ft = 4.1 nm
This to me is already a good example how he doesn't seem to understand how much accuracy matters in these calculations. 4.1 nm=24912ft, so he is just introduced an additional error of around 90 feet for no good reason. The altimeter is likely highly accurate, giving figures with 10 feet accuracy, so there's no sense to lose accuracy like that from the get go.
Object altitude calculated as: (4.1 nm [height of plane] – (4.1 slant range [plane to object]) x sin 22 = 4.1 – 1.54 = 2.46 below airplane altitude;
So he is using 4.1 slant range to object, which corresponds to the video between 4237 and 4239 seconds. At that time, the video clearly indicates the camera is pointed 28-29 degrees below the aircraft axis. So why the hell is he calculating sin 22? It was 22 degrees at the beginning of the video, when we don't even know the range yet, but we know pretty much for certain it's more than 4.4nm, as that is the first figure the rangefinder gives and then it starts to decrease.
So he is making his calculations on figures that do not even match those that are clearly visible in the video.
Let's see if even that simple calculation is actually correct with those figures:
4.1-4.1*sin(22)=2.564
Nope, he messed that one up as well, introducing yet another error of 0.1nm. Was that because he actually used more accurate altitude in that calculation than his awful rounding? Nope, that would just cause a bigger error. He just couldn't calculate 4.1 – 1.54.
Height of object = (height of plane – distance below plane ) = 4.1 – 2.5 = 1.6 nm (not close to surface)
And yet another rounding from that already incorrect 2.46 to 2.5, luckily this time it reduces his earlier error somewhat.
The correct altitude would be closer to 2.2nm. That's already more than 27% off!
That's pretty unbelievable, considering the actual calculation, when using correct numbers, is pretty simple.
Guess what: Even Google can do that in two steps, you don't even need a separate calculator.
First write "25000 feet to nautical miles", and it responds "4.1144708". Then use that and write the rest of the equation to the search field in nautical miles, using the correct angle: "4.1144708-sin(28 degrees)*4.1" and it responds "2.18963739258". That's 4055 meters, which seems to be very close to the correct value.
The sensor is aimed 35 deg left of plane axis and this angle increases to 57 or 58 so at the end so the object was traveling with a velocity component parallel to the track of the airplane
Which is basically just a lucky guess from him, since he doesn't seem to understand the parallax effect and doesn't even try to calculate how the plane was moving.
Estimated size of object based on apparent size of black-hot image is approx. (1.5 deg angular width of screen based on narrow FOV) x ([1.5 mm to 2mm diameter of black dot image size on 92 mm wide screen]/[92mm screen width]) x 0.0174 rad/deg x 4.1 nm[slant range] x 6077 ft/nm = 10 to 15 ft!....
He is almost certainly using an incorrect FOV, which should be 0.7 degrees, so that already introduces more than 2x error. I also cannot comprehend why he is calculating screen dimensions in millimeters instead of pixels, which would have more precision in this case.
That "0.0174 rad/deg" is PI/180, so changing degrees to radians there, although with a rounding error again, it should be 0.0175 with that precision. So he is calculating sin(1.5 degrees)*4.1nm there to get the width/height of the camera view area at that distance, but for some strange reason left out the trigonometric function he is using. And apparently he also moved the (incorrect) FOV angle of 1.5 outside that sin and instead multiplies that in first, introducing yet another but this time very small error.
(Edit: on a closer look, it seems he just put the result of the sin function there as value, which made it harder to see what he was doing)
For some strange reason, even his value for converting nautical miles to feet is off by one, it should be 6076. Why can't he use even a single correct number in his calculations? (even though that's yet another small difference that doesn't count much)
So, let's see if even that calculation is done correctly with all those incorrect values. I'm getting a rounded range of 11-14 feet, so I guess he rounded those to the nearest 5 ft or something. Doesn't really matter to introduce additional inaccuracies, as it's all based on incorrect numbers anyway, and those size estimates are pretty inaccurate. In reality the object is around 3 to 7 feet when the calculation is done with correct values.
At 4.1 nm range to the object, the distance across the 1.5 deg FOV is (4.1nm) x [1.5 deg x 0.0174 rad/deg]= 0.1 nm.
To be more precise, it's 0.107nm with his incorrect values, so his rounding again loses 7% of accuracy there.
It crosses the FOV at about a 45 deg angle so the actual approximate distance across the FOV is 0.1 nm/0.707 = 0.14 nm;
If he had used accurate numbers from the previous calculation, that would have been 0.15 nm.
it crosses in 4 to 3 sec implying a differential speed of the plane and object of 0.14 nm/ ( 4 to 3 sec)/(one hour/ 3600) = 126 to 170 kt)…
Great, more inaccurate numbers, but who cares, since he is using the wrong tool for the job anyway. So the result with those numbers is 126 to 168 knots, would have been 135 to 180 knots if he wouldn't have lost the accuracy above.
So now the important question is: What did he actually just calculate? He calculated the
apparent speed of the object moving across the screen. As if the plane was stationary. But it wasn't, and the object was high up. He doesn't seem to understand at all how most of that apparent speed is because of the movement of the plane. Even though he calculated earlier the object is at high altitude.
Since the plane is going at about 250 kt the object was going at the speed approx. (250 – 150) = 100 kt in the same direction as the airplane but clearly slower)calculation assumes land speed is approx. same as air speed) )))
He is using the CAS speed, while in reality he should be using the TAS speed, which is actually around 370 kt.
If he would have done the sensible thing and calculated the track of the jet and the relative distances and velocities between that and the target, he wouldn't need to care about the land speeds, and the presumably larger difference in winds on the ground level, but just the relative differences between the altitudes of the jet and the target.
Similarly he could have calculated pretty good estimates for the speed by using the rangefinder closing velocity values. The results from both of those methods are close to each other, so the display actually provides enough data to verify the speed estimates to certain degree with different means.
I really cannot understand why there seems to be a common myth that he is supposedly some sort of an expert on these sorts of calculations. He seems to be pretty clueless.
Considering his later "calculations" apparently resulted a speed of 330 kt, I would rather trust a random number generator.
Edit: Here's his revised version:
REVISION OF SPEED CALCULATION MARCH 12. [by Bruce Maccabee]
I have re-evaluated the speed of crossing the FOV (1.5 deg is assumed) during the short time that the image of the water was nearly stationary and pointing at a fixed area about 10 nm from the plane.
In my TENTATIVE CALCULATION I estimated "4 to 3 seconds" of crossing time.
However, when I subsequently counted the number of video frames I found that it took about 55 frames at 30 frames/ sec which corresponds to 55/30 = 1.8 sec.
The exact distance to the object at that time is not known because the system had not yet locked on.
However when it did lock on a short time later the range was about 4.1 nm and decreasing.
I therefore "guesstimate" the range at 4.5 nm.
The width of the FOV is 1.5 deg x 0.0174 rad/deg = 0.026 rad which corresponds to 0.117 nm at 4.5 nm distance,
The object crossed the FOV area at an angle of about 45 deg so the distance traveled as it crossed the FOV was about (0.026 rad) x 1.41(to account for the 45 degree crossing) x 4.5 nm = 0.165 nm.
It traveled this distance in about 1.8 sec for a speed of 0.092 nm/sec which is about 330 kt....about twice the larger speed previously calculated but certainly not an earth shaking speed.
So still doesn't seem to understand the parallax effect and the contribution of the movement of the plane to the apparent speed, is using the wrong FOV, admits he messed up calculating the frames, which is still the wrong tool to use, he still seems to have issues with his vision if he believes the distance was 4.1 nm when the target was locked, it makes no sense to use "guesstimates" when the accuracy of the actual values from the display is already a problem, but at least there are some values available, and his results are much worse than those with all the errors he was trying to fix. Seems like some of his earlier errors helped to mitigate some of his other errors...
