"GO FAST" Footage from Tom DeLonge's To The Stars Academy. Bird? Balloon?

[gtoffo]

Again, I think a balloon is more likely, mostly because of the radar return.

What do you mean? Birds should have a radar return (source: https://www.smithsonianmag.com/smart-news/how-doppler-radar-can-track-bird-migrations-180952834/)

If this was a bird shouldn't its shape be more discernible at such a range (around 5400 meters at the low point in the video)?

 

[Mick West]

Birds should have a radar return

Flocks of birds can fool weather radar, but I don't think an individual bird is going to give a strong return on a radar designed to detect larger metal objects. But I'm not sure.

If this was a bird shouldn't its shape be more discernible at such a range

Well, it's only a few pixels across, and would likely be mostly gliding at that altitude. But the general "blob" shape does seem to resemble a balloon more than a bird. Very hard to say though. At a distance planes and birds also look like blobs.

 

[gtoffo]

Flocks of birds can fool weather radar, but I don't think an individual bird is going to give a strong return on a radar designed to detect larger metal objects. But I'm not sure.


Well, it's only a few pixels across, and would likely be mostly gliding at that altitude. But the general "blob" shape does seem to resemble a balloon more than a bird. Very hard to say though. At a distance planes and birds also look like blobs.

Remember those are military grade radars. They are the best sensors in the world. Their mission is to track stealth planes at extreme range.

The radar cross section of a stealth fighter isn't different from a bird according to some sources (it's all classified of course). An F-22 is supposedly "comparable to the radar cross sections of birds and bees" (source: https://www.globalsecurity.org/military/systems/aircraft/f-22-stealth.htm)

So of course those radars can distinguish birds but they probably filter them out normally (remember F-18 radars are so sophisticated they can recognise the exact aircraft type based on the radar return of their turbine blades which are characteristic for each model https://www.princeton.edu/~ota/disk1/1993/9351/935106.PDF so it's safe to assume they can distinguish the radar return of a bird). But if you ask them to calculate the range to a large bird you are tracking with ATFLIR they won't have any problem at all.

Also, 4 miles is not a lot in terms of the capabilities of those sensors. You are around 10% of the total range of ATFLIR (40 nm). A big bird should be pretty clear and distinguishable.

And just how big is the "bird"?
Not sure if someone did this already but to calculate approximate size:
Pixels of object / total pixels of the video on my screen: 13/644=0.020
ATFLIR NFOV Zoom level 1 field of view 0.70 deg https://www.explorescu.org/post/nimitz_strike_group_2004
So apparent size is 0.020*0.70=0.014126° which at a distance of 3.4 nautical miles=6296 meters means the object is around 1.55 meters wide.

No problem tracking anything that big with an F-18. And its shape should be distinguishable as this is a very normal range for those sensors.

 

[Buraje]

The radar could probably detect a bird, but there is no indication radar was used in the Go Fast video. Someone speculated that radar was used to determine range, but that has not been confirmed. Which brings up a potential problem with the (impressive) analyses contributed on this thread: Unlike radar which can measure distance to a target by the timed echo, visual and infrared tracking do not provide direct range information. How does real-time range information appear on the display? I suspect that Raytheon engineers generated an algorithm to calculate the apparent range to a visual- or infrared-tracked target by assuming a stationary target and basing the calculation on the aircraft/ATFLIR motion data (translations and rotations), angular direction to the target, and instantaneous slew rates of the camera positioner required to maintain tracking lock. If that’s correct, and if we now use those calculated range values in frame-by-frame trigonometric motion analysis, it’s not surprising that the results indicate the target is nearly stationary. It’s indeed possible that the tracked target in the video is near the indicated distance, at around 13,000 feet altitude, moving relatively slowly. But if the target is actually in motion, the fixed target assumption is false and the indicated range values are wrong. We can’t exclude the possibility that the target is much further away, near the water surface, going fast.

 

[Mick West]

I suspect that Raytheon engineers generated an algorithm to calculate the apparent range to a visual- or infrared-tracked target by assuming a stationary target and basing the calculation on the aircraft/ATFLIR motion data (translations and rotations), angular direction to the target, and instantaneous slew rates of the camera positioner required to maintain tracking lock.

That doesn't make any sense. Why would they assume a stationary target? The vast majority of flying targets are moving, even a balloon. To find the distance from the angle change you'd need the relative velocity. Why would they program a system that invariably gives the wrong answer?

Also the Gimbal video was shot by the same plane at around the same time, and no range indication appeared.

And if you assume the range is wrong, then all that tells you is that the object is somewhere along the line of sight - it could even be close and fast.

 

[Buraje]

The visual and infrared mode are typically used instead of radar for ground targets. So the ATFLIR provides the apparent range to fixed ground targets when the track lock is established. How else could it be measured?

The technique of using the instantaneous slew rates of the camera positioner to calculate range would not work well if the angle to the target is close the to the aircraft's direction of travel. That's probably why a range solution was not obtained in the Gimbal video.

 

[Mick West]

The visual and infrared mode are typically used instead of radar for ground targets. So the ATFLIR provides the apparent range to fixed ground targets when the track lock is established. How else could it be measured?

With the terrain maps, and intersecting that with the line of sight.

The technique of using the instantaneous slew rates of the camera positioner to calculate range would not work well if the angle to the target is close the to the aircraft's direction of travel. That's probably why a range solution was not obtained in the Gimbal video.

It seems like a highly inaccurate method of judging distance, which will not work at all in many situations, and relies on assumptions for other situations.

Everyone seems to think that there was a radar lock, or at least some accurate range determination. So it seems like pointless speculation to entertain this non-working method.

 

[BenJ]

Probably overkill by this point but this video can be recreated in a game engine to review flight paths and FOV and other bits, I actually think the video was narrower than 1 degree else you can't get the movement of the Ocean to match the video - even if you try moving the water in the complete opposite direction by any reasonable ammount (which it's already doing in the model I've made) it doesn't compensate enough.

Blog post below and then there's an associated youtube video that covers much of the same stuff already discussed here, the 'game' build and Unity files are all in GitHub.
https://jabituyaben.wixsite.com/maj...ious-recreating-a-pentagon-ufo-video-in-unity

Could do this for the Gimbal and FLIR videos as well but nothing much is really happening in those! The approach I'd take for those ones would be to use post-processing i.e. effects filter to show how glare can make an object appear as if it's rotating. For the Nimitz one it would be removing the lock and changing from 2 different FOV's.

 

[Mick West]

Probably overkill by this point but this video can be recreated in a game engine to review flight paths and FOV and other bits, I actually think the video was narrower than 1 degree else you can't get the movement of the Ocean to match the video - even if you try moving the water in the complete opposite direction by any reasonable ammount (which it's already doing in the model I've made) it doesn't compensate enough.

I did something very similar using Unity a two months ago, but then Unity started crashing on me, and other factors led me to lose interest. I just revived it, although I've already forgotten how I did most of it. I set it up with the video playing on one side, and added a recorder to allow scrubbing though the frames.



There's just two object, the "main camera" (the jet) and the "object"

Main Camera:


So that V of 190 m/s is 369 knots, the TAS (calculated from CAS), and the turn rate is a constant 0.61 left.

An important factor to get the angle of the ocean to match was the wind speed, although looking at it now I have a separate velocity and add that to the wind, which is fine for the Jet, but not for the object if it's a balloon. Here's the update function for the camera (jet), incorporating the turn and the wind.

 public override void FixedUpdate2()
    {

        float t = Time.deltaTime;

        // rotate the VELOCITY of the camera, as we are turning
        // assuming here the velocity is the same as the forward axis of the jet
        m_v = Quaternion.AngleAxis(m_turnRate * t, Vector3.up) * m_v;
        //  Debug.Log(m_turnRate +", "+ m_v);

        // incorporate wind into absolute velocity
        GameObject windObject = GameObject.Find("Wind");
        Vector3 windVelocity = windObject.GetComponent<Wind>().WindVector();
        Vector3 resultantVelocity = m_v + windVelocity;

        // Translate the camera position in world space
        // (local space would be the orientation of the camera)
        transform.Translate(resultantVelocity * t, Space.World);

        GameObject obj = GameObject.Find("Object");
        transform.LookAt(obj.transform);

    }

Anyway, not sure if I'll get back into it any time soon.

 

[jarlrmai]

I was rewatching the Go Fast video with new information gained from reading up on the simulated ATFLIR manuals.

What's interesting is that the WSO manually slews and then optically tracks the object, however when he captures it a range shows (the RNG figure we used to calculate the altitude)

This range comes from the RADAR from what I can work out, however the L+S and SLAVE options are not boxed meaning there is no slave, I wonder if this means that the system knows if the ATLFIR gets an optical lock that points it at the L+S track and if it has range for that track it shows it?

 

[gtoffo]

I was rewatching the Go Fast video with new information gained from reading up on the simulated ATFLIR manuals.

What's interesting is that the WSO manually slews and then optically tracks the object, however when he captures it a range shows (the RNG figure we used to calculate the altitude)

This range comes from the RADAR from what I can work out, however the L+S and SLAVE options are not boxed meaning there is no slave, I wonder if this means that the system knows if the ATLFIR gets an optical lock that points it at the L+S track and if it has range for that track it shows it?

Exactly. However consider this might be a more modern system compared to the FLIR video.

I think it just works both ways. You can optically track and use it to get a radar return or do the opposite: radar lock and then slave atflir. In any case the sensors are fused and synchronised.

 

[zedzded]

Not sure why there is much credence given to the bird theory. There are 430 billion birds in the world, if the US militaries radar was struggling to differentiate between aircraft and birds they would sure be in a bit of a pickle....

 

[zedzded]

Even if the radar technology was that clunky and archaic it couldn't differentiate between a large bird and a plane, surely the Pilots and radar operators would be used to seeing and dismissing these radar anomalies. Random dots moving across their radar system would be a daily occurrence. Besides they had numerous sightings of the Tic Tac UFOS and described them in some detail.

 

[JMartJr]

if the US militaries radar was struggling to differentiate between aircraft and birds they would sure be in a bit of a pickle....

I think that assumes facts which are not in evidence. Do we know they couldn't tell a bird (or balloon, I personally think is more likely) from an aircraft? Listening to the chatter in the video, I hear some guys hugely entertained that they managed to lock onto a difficult or surprising target and very pleased with themselves. I don't hear them claim that they believe it to be an aircraft.

 

[jarlrmai]

One thing about Go Fast with new knowledge of how SLAVE and L+S works as per above, is that if they had had wanted to they could likely have slaved the ATLFIR to the RADAR track that provides the range data, it feels like they were maybe trying out/practicing with autotrack, something that they would not likely do if this were a live full mission/unknown object encounter.

 

[Todd Wasson]

I get a different speed from some of you guys on "go fast" so will show how I solve it. Maybe somebody can point out a mistake. Forgive the non standard math notation. I'm a physics engine programmer so use vectors and am writing pseudo code here. This is how we typically do things in physics simulations.

First, a disclaimer: It's not clear to me whether the range info is accurate or not. I'm not a pilot so can't say for sure, but in DCS World the flashing "B" on the display in an A10-C means both the IR and laser are active so range info should be "accurate". If the F-18 is the same, then it's probably reliable, but we should ask some pilots to make sure. Lehto says the target isn't being lased so maybe I'm wrong about the flashing "B", or maybe he missed it like I did.

Regardless, this analysis will assume the range info is correct. Please check my math, easy to make mistakes here:

Assumptions:

-F-18 is in level flight with no heading changes.
-F-18 true air speed is 367 kts (http://www.hochwarth.com/misc/AviationCalculator.html using 0.61 Mach and 25,000 feet altitude which gives 252 kts CAS. Close enough?)
-Target velocity is constant

Reference frames:
Jet - Velocities and positions relative to F18. X+ right, Y+ up, Z+ forward relative to F-18
F18Air - Velocities and positions relative to air at F-18's position.

Other variables/vectors :

float range1 (range to target at sample point 1)
float range2 (range to target at sample point 2)

Vector3 Jet.DirToTarget1 (direction to target relative to jet at sample point 1)
Vector3 Jet.PositionTarget1 (position of target relative to jet at sample point 1)
Vector3 Jet.DirToTarget2 (direction to target relative to jet at sample point 2)
Vector3 Jet.PositionTarget2 (position of target relative to jet at sample point 1)
Vector3 Jet.VelocityTarget (relative velocity of target in jet's reference frame taken between sample points 1 and 2)

Sample point 1 is taken at 13.667 sec in the original video, shortly after lock where both the elevation and bearing conveniently tick over to -27 deg and 45 deg in the same frame. Assuming the integer display rounds up at 0.5, this would give a starting elevation of -26.5 deg and 44.5 degrees.

Starting with Jet.DirToTarget1 aligned with jet frame (z+ forward, other components 0):
Jet.DirToTarget1.x = 0
Jet.DirToTarget1.y = 0
Jet.DirToTarget1.z = 1.0

Rotating vector down 26.5 degrees around x axis for elevation and normalizing updates to:
Jet.DirToTarget1.x = 0
Jet.DirToTarget1.y = -0.4461977
Jet.DirToTarget1.z = 0.8949344

Rotating above vector -44.5 degrees around y axis for heading and normalizing updates to:
Jet.DirToTarget1.x = -0.6272678
Jet.DirToTarget1.y = -0.4461977
Jet.DirToTarget1.z = 0.6383123

Projecting along this vector to range 4.3 nautical miles to get target position relative to the jet (Jet frame):

Jet.PositionTarget1 = Jet.DirToTarget * range1 (where range1 = 4.3 nautical miles)
Jet.PositionTarget1.x = -2.697252 nautical miles (-14,241.49 feet)
Jet.PositionTarget1.y = -1.918651 nautical miles (-10,130.48 feet)
Jet.PositionTarget1.z = 2.744743 nautical miles (14492.24 feet)
--------------------------------
Done with position sample point 1.
--------------------------------
Now for sample point 2. I take this at 21.267 seconds (7.600 seconds after sample point 1) which has elevation and bearing both update in the same frame to -30 deg (elev) and 50 deg (bearing), meaning -29.5 deg and 49.5 deg. Range clicked over to 3.9 less than 0.2 seconds prior to sample point 2 so I'm using 3.9 nautical miles for range2:

Jet.DirToTarget2.x = -0.6618237
Jet.DirToTarget2.y = -0.4924236
Jet.DirToTarget2.z = 0.5652508

Jet.PositionTarget2 = Jet.DirToTarget * range2 (where range1 = 3.9 nautical miles)
Jet.PositionTarget2.x = -2.581113 nautical miles (-13,628.27 feet)
Jet.PositionTarget2.y = -1.920452 nautical miles (-10,139.99 feet)
Jet.PositionTarget2.z = 2.204478 nautical miles (11,639.64 feet)

This gives a target altitude of about 10,135 feet below the jet if we average the two heights. Jet is 25,000 feet so target altitude evaluates to 25,000 - 10,135 = 14,865 feet.
-----------------
Now for the target velocity in jet frame (Jet.VelocityTarget), calculated from positions at sample points 1 and 2 and elapsed time between sample points:
-----------------
New variable:
Vector3 Jet.DisplacementTarget = JetPositionTarget2 - JetPositionTarget1
Jet.DisplacementTarget.x = 0.116122 nautical miles (613 feet)
Jet.DisplacementTarget.y = -0.001801 nautical miles (9.51 feet)
Jet.DisplacementTarget.z = -0.540265 nautical miles (-2,852.60 feet)

Dividing by elapsed time between the sample points (7.600 seconds) gives Jet.VelocityTarget:

Jet.VelocityTarget.x = 0.015279 nautical miles / sec
Jet.VelocityTarget.y = -0.0002370383 nautical miles / sec
Jet.VelocityTarget.z = -0.071088 nautical miles / sec

In knots (* 3600):
Jet.VelocityTarget.x = 55 knots
Jet.VelocityTarget.y = -0.8533377 knots
Jet.VelocityTarget.z = -255.915 knots

Jet.SpeedTarget via vector length (sqrt(x*x+y*y+z*z)) = 261.7627 knots

--------------------------------
So to sum up at this point: We have the target velocity, speed, two positions relative to the jet. To check the math I'll compute VC at both sample points to verify it matches the HUD VC (closing velocity). This is the velocity vector dotted with each respective target direction vector (one at each sample point, but I use the same velocity vector for both since I only have one. This is assuming target velocity is constant over the 7.6 second time period between sample points 1 and 2 which may or may not be true):

Jet.VCCalculated1 = Dot(Jet.VelocityTarget, Jet.DirToTarget1)

Jet.VCCalculated1 = -197 kts (FLIR flips sign to + for closing targets and says VC 210 kts at point 1 so ~6% error)

Jet.VCCalculated2 = Dot(Jet.VelocityTarget, Jet.DirToTarget2)
Jet.VCCalculated2 = -181 kts (FLIR says VC 180 so we're dead on with sample point 2)

So this is within 0% and 6% error on the VC as displayed on the FLIR. It seems likely this difference is just due to precision in the range. If the HUD showed another digit or two this would probably be bang on.

Now for target true air speed (TAS) in F18's air. Taking F18 air speed as 367 knots in new velocity vector "JetVelocity" = (0,0,367) in F18Air frame:

F18Air.VelocityTarget = Jet.VelocityTarget + JetVelocity
F18Air.VelocityTarget.x = 55.01318 knots
F18Air.VelocityTarget.y = -0.8533377 knots
F18Air.VelocityTarget.z = 111.085 knots

Giving F18Air.Speed (length of above vector) = 124 knots. <---This would be the air speed of the target in the F18 air's frame.

So with these numbers the target would be moving 124 knots TAS (assuming same wind speed as jet which may not be true). With jet at 367 knots, jet would be overtaking the target (both flying in the same direction, more or less) and giving the parralax.

The problem I'm seeing with the balloon hypothesis is you'd need essentially a 124 knot headwind at the jet (possible) but 0 wind only 10,000 feet below it, or at least a difference of 124 knots in the flight direction between the two altitudes essentially in opposite directions. I know wind can change pretty quickly with altitude at different wind layers and 120+ knots at high altitude is not unheard of, but it'd have to be aligned with the jet too. I suppose it's possible, but I'm finding it a little harder to swallow than some others here because of the testimony that comes along with all this, radar jamming events and so on, the object being colder than the ocean, etc.. It just seems unlikely that a carrier group is tracking individual birds and vectoring F18s after them. Surely the Aegis radar system or whatever they're called filters that stuff out if it even can track a single bird?

Regardless, if our navy is chasing balloons and birds while our F18's are signaling radar jamming events when a WIZO locks a target that the radar can't identify immediately, we have a lot bigger problems than UFOs.

 

[jarlrmai]

I get a different speed from some of you guys on "go fast" so will show how I solve it. Maybe somebody can point out a mistake. Forgive the non standard math notation. I'm a physics engine programmer so use vectors and am writing pseudo code here. This is how we typically do things in physics simulations.

First, a disclaimer: It's not clear to me whether the range info is accurate or not. I'm not a pilot so can't say for sure, but in DCS World the flashing "B" on the display in an A10-C means both the IR and laser are active so range info should be "accurate". If the F-18 is the same, then it's probably reliable, but we should ask some pilots to make sure. Lehto says the target isn't being lased so maybe I'm wrong about the flashing "B", or maybe he missed it like I did.

Regardless, this analysis will assume the range info is correct. Please check my math, easy to make mistakes here:

Assumptions:

-F-18 is in level flight with no heading changes.
-F-18 true air speed is 367 kts (http://www.hochwarth.com/misc/AviationCalculator.html using 0.61 Mach and 25,000 feet altitude which gives 252 kts CAS. Close enough?)
-Target velocity is constant

Reference frames:
Jet - Velocities and positions relative to F18. X+ right, Y+ up, Z+ forward relative to F-18
F18Air - Velocities and positions relative to air at F-18's position.

Other variables/vectors :

float range1 (range to target at sample point 1)
float range2 (range to target at sample point 2)

Vector3 Jet.DirToTarget1 (direction to target relative to jet at sample point 1)
Vector3 Jet.PositionTarget1 (position of target relative to jet at sample point 1)
Vector3 Jet.DirToTarget2 (direction to target relative to jet at sample point 2)
Vector3 Jet.PositionTarget2 (position of target relative to jet at sample point 1)
Vector3 Jet.VelocityTarget (relative velocity of target in jet's reference frame taken between sample points 1 and 2)

Sample point 1 is taken at 13.667 sec in the original video, shortly after lock where both the elevation and bearing conveniently tick over to -27 deg and 45 deg in the same frame. Assuming the integer display rounds up at 0.5, this would give a starting elevation of -26.5 deg and 44.5 degrees.

Starting with Jet.DirToTarget1 aligned with jet frame (z+ forward, other components 0):
Jet.DirToTarget1.x = 0
Jet.DirToTarget1.y = 0
Jet.DirToTarget1.z = 1.0

Rotating vector down 26.5 degrees around x axis for elevation and normalizing updates to:
Jet.DirToTarget1.x = 0
Jet.DirToTarget1.y = -0.4461977
Jet.DirToTarget1.z = 0.8949344

Rotating above vector -44.5 degrees around y axis for heading and normalizing updates to:
Jet.DirToTarget1.x = -0.6272678
Jet.DirToTarget1.y = -0.4461977
Jet.DirToTarget1.z = 0.6383123

Projecting along this vector to range 4.3 nautical miles to get target position relative to the jet (Jet frame):

Jet.PositionTarget1 = Jet.DirToTarget * range1 (where range1 = 4.3 nautical miles)
Jet.PositionTarget1.x = -2.697252 nautical miles (-14,241.49 feet)
Jet.PositionTarget1.y = -1.918651 nautical miles (-10,130.48 feet)
Jet.PositionTarget1.z = 2.744743 nautical miles (14492.24 feet)
--------------------------------
Done with position sample point 1.
--------------------------------
Now for sample point 2. I take this at 21.267 seconds (7.600 seconds after sample point 1) which has elevation and bearing both update in the same frame to -30 deg (elev) and 50 deg (bearing), meaning -29.5 deg and 49.5 deg. Range clicked over to 3.9 less than 0.2 seconds prior to sample point 2 so I'm using 3.9 nautical miles for range2:

Jet.DirToTarget2.x = -0.6618237
Jet.DirToTarget2.y = -0.4924236
Jet.DirToTarget2.z = 0.5652508

Jet.PositionTarget2 = Jet.DirToTarget * range2 (where range1 = 3.9 nautical miles)
Jet.PositionTarget2.x = -2.581113 nautical miles (-13,628.27 feet)
Jet.PositionTarget2.y = -1.920452 nautical miles (-10,139.99 feet)
Jet.PositionTarget2.z = 2.204478 nautical miles (11,639.64 feet)

This gives a target altitude of about 10,135 feet below the jet if we average the two heights. Jet is 25,000 feet so target altitude evaluates to 25,000 - 10,135 = 14,865 feet.
-----------------
Now for the target velocity in jet frame (Jet.VelocityTarget), calculated from positions at sample points 1 and 2 and elapsed time between sample points:
-----------------
New variable:
Vector3 Jet.DisplacementTarget = JetPositionTarget2 - JetPositionTarget1
Jet.DisplacementTarget.x = 0.116122 nautical miles (613 feet)
Jet.DisplacementTarget.y = -0.001801 nautical miles (9.51 feet)
Jet.DisplacementTarget.z = -0.540265 nautical miles (-2,852.60 feet)

Dividing by elapsed time between the sample points (7.600 seconds) gives Jet.VelocityTarget:

Jet.VelocityTarget.x = 0.015279 nautical miles / sec
Jet.VelocityTarget.y = -0.0002370383 nautical miles / sec
Jet.VelocityTarget.z = -0.071088 nautical miles / sec

In knots (* 3600):
Jet.VelocityTarget.x = 55 knots
Jet.VelocityTarget.y = -0.8533377 knots
Jet.VelocityTarget.z = -255.915 knots

Jet.SpeedTarget via vector length (sqrt(x*x+y*y+z*z)) = 261.7627 knots

--------------------------------
So to sum up at this point: We have the target velocity, speed, two positions relative to the jet. To check the math I'll compute VC at both sample points to verify it matches the HUD VC (closing velocity). This is the velocity vector dotted with each respective target direction vector (one at each sample point, but I use the same velocity vector for both since I only have one. This is assuming target velocity is constant over the 7.6 second time period between sample points 1 and 2 which may or may not be true):

Jet.VCCalculated1 = Dot(Jet.VelocityTarget, Jet.DirToTarget1)

Jet.VCCalculated1 = -197 kts (FLIR flips sign to + for closing targets and says VC 210 kts at point 1 so ~6% error)

Jet.VCCalculated2 = Dot(Jet.VelocityTarget, Jet.DirToTarget2)
Jet.VCCalculated2 = -181 kts (FLIR says VC 180 so we're dead on with sample point 2)

So this is within 0% and 6% error on the VC as displayed on the FLIR. It seems likely this difference is just due to precision in the range. If the HUD showed another digit or two this would probably be bang on.

Now for target true air speed (TAS) in F18's air. Taking F18 air speed as 367 knots in new velocity vector "JetVelocity" = (0,0,367) in F18Air frame:

F18Air.VelocityTarget = Jet.VelocityTarget + JetVelocity
F18Air.VelocityTarget.x = 55.01318 knots
F18Air.VelocityTarget.y = -0.8533377 knots
F18Air.VelocityTarget.z = 111.085 knots

Giving F18Air.Speed (length of above vector) = 124 knots. <---This would be the air speed of the target in the F18 air's frame.

So with these numbers the target would be moving 124 knots TAS (assuming same wind speed as jet which may not be true). With jet at 367 knots, jet would be overtaking the target (both flying in the same direction, more or less) and giving the parralax.

The problem I'm seeing with the balloon hypothesis is you'd need essentially a 124 knot headwind at the jet (possible) but 0 wind only 10,000 feet below it, or at least a difference of 124 knots in the flight direction between the two altitudes essentially in opposite directions. I know wind can change pretty quickly with altitude at different wind layers and 120+ knots at high altitude is not unheard of, but it'd have to be aligned with the jet too. I suppose it's possible, but I'm finding it a little harder to swallow than some others here because of the testimony that comes along with all this, radar jamming events and so on, the object being colder than the ocean, etc.. It just seems unlikely that a carrier group is tracking individual birds and vectoring F18s after them. Surely the Aegis radar system or whatever they're called filters that stuff out if it even can track a single bird?

Regardless, if our navy is chasing balloons and birds while our F18's are signaling radar jamming events when a WIZO locks a target that the radar can't identify immediately, we have a lot bigger problems than UFOs.

Can I ask why you think we did this debunk in the 1st place?

 

[Leonardo Cuellar]

I get a different speed from some of you guys on "go fast" so will show how I solve it. Maybe somebody can point out a mistake. Forgive the non standard math notation. I'm a physics engine programmer so use vectors and am writing pseudo code here. This is how we typically do things in physics simulations

Excellent! I wanted to ask you some questions. What do you mean by flashing B? The one close to the altitude? Why do you assume the heading is constant? The fighter, to point 2, should already have started to turn. I keep having problems about the true meaning of the angle of azimuth. The manual and many studies indicate it as the angle between the ground track and the LOS. It makes no sense to consider it in an aircraft or air frame of reference. The azimuth always has the same meaning for both A/G and A/A targets. What is the VC formula? Are you sure that the value read on the display is expressed in TAS and not IAS? I completely agree with you for the balloon. During that time (January 2015) the wind at FL250 never exceeded 120kt along the East Coast. 10k ft below, the speed ranges at between 40 and 80 kt. There is no physical possibility of having zero wind. The direction can vary very well. It depends on the mass flowing to the ground. The object was unquestionably self-propelled. Thanks for your great work.

 

[Mick West]

-F-18 is in level flight with no heading changes.

But the heading changes. If I set the turn rate to near zero, then, yes, you get 130+ knots.


But other values give much lower speeds.




Source: https://www.geogebra.org/m/ayazsujy

 

[MclachlanM]

First, a disclaimer: It's not clear to me whether the range info is accurate or not. I'm not a pilot so can't say for sure, but in DCS World the flashing "B" on the display in an A10-C means both the IR and laser are active so range info should be "accurate". If the F-18 is the same, then it's probably reliable, but we should ask some pilots to make sure. Lehto says the target isn't being lased so maybe I'm wrong about the flashing "B", or maybe he missed it like I did.

In the A10 an 'L' will appear when the laser is firing, if the 'B' appears on the screen, to denote both IR and laser are active, the 'L' for laser will still show, also the 'B' doesn't flash.




In the F-18 the flashing B next to the altitude means that the altitude switch is set to show RADAR altitude, however the aircraft is too high to give an accurate number for this so has defaulted to displaying the barometric altitude instead.

If the laser were firing then we would have a lot more indication; an 'L ARM' displayed to show the laser is armed, a flashing 'LTD/R' when it is firing and the target reticule bars will also flash. Here is me firing the laser to demonstrate, the aircraft must be in air to ground mode and the operator must pull the trigger to get the laser to fire, as far as I understand it wouldn't usually be operated manually to get range like this, instead it would automatically fire once a laser-guided bomb has been released:

All evidence points to the range coming from the RADAR plus trigonometry, there is no real reason to doubt the accuracy apart from Chris Lehto dismissing it and given he doesn't really explain why it's inaccurate + his increasingly dodgy videos I'm happy to say he's wrong.

but we should ask some pilots to make sure.

I agree, unfortunately pilots are generally not willing to go into the details of classified systems. Here is the only take from an F-18 pilot that we have (I think):
Source: https://youtu.be/M9NhOKy2K80?t=505

 

[dimebag2]

Indeed the trajectory of the plane has to be accounted to retrieve meaningful results. Considering a straight trajectory for the plane will put you way off. The fact that the plane and GoFast are not at the same altitude is important too, so the calculations are more accurate when building a 3D model : https://www.geogebra.org/m/axynssmq

My model gives a speed of 58 Knots for GoFast, considering the lines of bearing and RNG given in the video. Of course we don't know the wind shear between the plane altitude (25000ft) and GoFast (12000ft), that's an important factor that is missing to retrieve the GoFast speed.
This guys did the same kind of analyses and also find a speed of 50-60 Knots :

Source: https://youtu.be/y5Uf4N-JkQY

 

[Todd Wasson]

Excellent! I wanted to ask you some questions. What do you mean by flashing B? The one close to the altitude? Why do you assume the heading is constant? The fighter, to point 2, should already have started to turn. I keep having problems about the true meaning of the angle of azimuth. The manual and many studies indicate it as the angle between the ground track and the LOS. It makes no sense to consider it in an aircraft or air frame of reference. The azimuth always has the same meaning for both A/G and A/A targets. What is the VC formula? Are you sure that the value read on the display is expressed in TAS and not IAS? I completely agree with you for the balloon. During that time (January 2015) the wind at FL250 never exceeded 120kt along the East Coast. 10k ft below, the speed ranges at between 40 and 80 kt. There is no physical possibility of having zero wind. The direction can vary very well. It depends on the mass flowing to the ground. The object was unquestionably self-propelled. Thanks for your great work.

Fl
Thanks for the wind information. Good to know.

Flashing B next to the altitude at the bottom right, yes. I'm not sure if that means what I think it does (video game programmer and flight sim junkie here, not a real pilot, and definitely not military), but in DCS World it works that way on the A10C at least. I haven't tried the pod on the F18 (no guarantee it's the same as reality anyway) so I'd need confirmation from Raytheon or a pilot to be sure unless somebody here already knows.

We do know the laser/IR beam status if we're claiming the range information is accurate, right? Lehto insisted it's not being lased and therefore the range was nonsense, which many people are unfortunately ignoring. It's possible he missed the flashing "B" though like I did (I was looking for a flashing "L" the first time I saw the video, I'm still kicking myself for not seeing the "B"), or it doesn't mean what I think it does. Nobody's perfect, I've pointed out a couple things to Lehto that he's missed as well and have made similar mistakes myself. Yesterday he pulled his last video after I posted a tic tac simulation I made in his comment section:

Source: https://www.youtube.com/watch?v=KvnBYL17VcA&ab_channel=ToddWasson

He thanked me for the video and accepted he had the "instant acceleration" wrong on the tic tac, that the camera panning simply stopping when track is lost is enough to explain the supposed physics defying maneuver. None of us are perfect either.

Heading/turn rate: My analysis assumed constant heading because there is no heading or turn rate information available which would mean guessing. I avoid that if I don't know something, as I would hope we all would, especially something like turn rate on an aircraft flown by a fly-by-wire system that has several different autopilot options on top of what's always running, none of which I have any telemetry on, nor do I know whether any of the autopilot modes are active or not. This isn't a Cessna 152. A computer is flying the plane even when autopilot is "turned off", so the control surfaces may not be doing what I expect, and I can't see the pilots inputs either. Is he using any right rudder to deliberately keep his heading constant? Is the flight computer feeding in rudder? Is the autopilot "maintain altitude" mode doing it? There's no way to know from the video.

Bank angle only correlates well with turn rate under specific constraints. The pilot, flight computer and autopilot are free to deviate from this and frequently do. Cross wind landings are all done with non zero bank angle and zero turn rate. For an extreme case, there's the knife edge maneuver, 90 degree bank angle with essentially 0 turn rate:

Source: https://www.youtube.com/watch?v=JLDjxzQw2o0&ab_channel=KPRC2Click2Houston

Whether it's level flight or not I couldn't say (probably not), but it's not inconceivable if the airspeed is high enough. Regardless, the point is you can bank to lesser angles than this and maintain 0 turn rate and level flight if you want to. This pilot could have just as easily pushed the stick forward and had a turn rate that's the opposite direction from what the lift vector would suggest. The fun is in trying to keep turn rate close to 0 despite bank angle. He even takes his hands off the controls in the end and the plane doesn't react. If a computer is in control of the flight control surfaces via a fly-by-wire system like an F-18, anything is possible. The F22's flight computer for example has several interesting modes of operation that are completely different from a typical plane. One maintains a given (vehicle frame vertical) acceleration so long as control inputs are zero, another maintains constant direction. In the first mode you can pull a 5g turn, let go of the controls, and it'll maintain 5g. Push the stick forward momentarily and let go and you'll now be at 4g. Pull it back and let go and you can go to 6g. There are other modes that work completely differently from this. Even in airliners there are substantial differences between the manufacturers. I have an airline pilot friend that switched from one to the other, and we had a very long, interesting conversation about the differences in how their flight control systems worked (Airbus vs Boeing). The fact is we simply don't know what the turn rate really is on go-fast.

In my experience, guessing at unavailable data like turn rate leaves analyses vulnerable to confirmation bias effects, so I generally avoid it. We tend to massage such parameters to get the conclusions we want, like wanting to verify beyond a shadow of a doubt that a target is a bird or a balloon (or a physics defying alien ship for that matter) by inserting our own non-existent turn rate and other information to get the conclusion we wish for. I've fooled myself in my own work with this enough times to realize confirmation bias works both ways, so I just avoid it. It's ok to infer sometimes and say "if the turn rate is this or that value then the results will be this" without knowing if that's actually the correct turn rate, but we have to be very clear about what we're doing and not kid ourselves into thinking we know the value of a variable we have no telemetry for. If we do, we're just guessing, plain and simple.

Yes, that means my assumption of 0 turn rate is also wrong for the same reason, but with the bank angle being this small I felt it was a reasonable assumption and would lead to a useful analysis anyway. Your turn rates may very well be just as reasonable. The problem is we can't be sure either way without telemetry. I did the analysis anyway because all the others I've seen so far have been 2D simplifications or quasi-3D at best. 0 turn rate seemed reasonable and useful enough to perhaps glean something useful anyway, at least as good as any turn rate guess I could reasonably make. I wouldn't even attempt to guess a turn rate here, quite frankly, and have cringed every time I've seen others do it. To my mind there's just so much room for error there I wouldn't even attempt it. Instead I figured "let's try with 0 turn rate in a proper 3D vector calc treament once and see what the result would be. Maybe it'll shed some light on something anyway."

The fact is we don't really know if the jet is actually turning from bank angle alone, especially such a small bank angle which was developing over a good chunk of the time between my sample points. In DCS I often roll just to keep a target in view without any appreciable turn rate, especially if the target is 30 degrees down and off to the side like go-fast was. All you do is bank and feed in some opposite rudder to maintain heading and altitude if you wish. It's not that hard, especially with a top tier fly-by-wire system and the autopilot altitude controller possibly helping you. Cross wind landings are done this way too by banking into the wind and using opposite rudder so the aircraft can land with zero turn rate, zero crab angle, and non-zero bank angle. At the last second you zero the bank angle so all three are as close to zero as you can get on touch down. This way you touch down wings level with small slip angles at the tires (best to have small tire lateral forces at touchdown) while maintaining runway heading.

Bearing/azimuth: My coordinate frames are a matter of convenience and are just fine for a 0 or negligible turn rate analysis. Standard vehicle coordinate systems whether they're cars, planes or anything else, are just that: Defined relative to the main axes of the vehicle along principle directions of the vehicle (forward, up right). I.e., "local coordinates" in 3D engine parlance where three perpendicular planes cut the vehicle up. It makes sense to vehicle dynamics engineers and is more commonly used than not. Terms are frequently defined in these coordinate systems separately. For example from my own work, in race car dynamics simulations a tire coordinate system is defined with tire lateral and longitudinal forces (two perpendicular components of the same force) defined in that frame. That vector can be rotated into the vehicle frame, then projected to the road frame (which could be rotated relative to world frame) where the left/right component becomes "cornering force." Same goes for lateral acceleration versus cornering acceleration. They're different, and the difference has to do with coordinate frame choices of interest. Another frame can be aligned with the velocity vector of the vehicle. The rearward component of that tire force from any of the other frames becomes "induced drag" in this third frame.

So yes, it's common to work in multiple coordinate frames like this depending on what one is modeling/analyzing. This isn't relevant to anything in my analysis though because my "jet frame" was oriented as right = (1,0,0) up = (0,1,0) forward = (0,0,1) (standard left handed coordinates) so it is non rotated and therefore in the same coordinate frame the FLIR bearing/elevation is in. I.e., it's just the global frame rotated around the vertical axis to align itself with the horizontal part of the forward vector of the jet. If I were to analyze the flight as it's turning, I'd rethink the coordinate frames. However, it suffices perfectly well for the assumptions I made.

Air speed: IAS is on the display. I have never heard a pilot use the term "calibrated air speed." They say "indicated" which might be the same as "calibrated air speed." Your air speed indicator on the panel better well be calibrated so it's not reading 20kts when it should be reading 200kts, right? When ATC says "maintain air speed below 180 kts" the pilot doesn't respond with "do you mean indicated or calibrated?" Engineers and pilots may very well be using different terminology there which makes sense for them, but by the time it's installed on the airplane and ATC and pilots are using it, there's no longer any practical difference that I'm aware of. What a pilot sees is whatever is on his airspeed indicator, and he calls that "indicated air speed." If he's a fighter pilot he can switch the HUD to true air speed. I'm not a pilot myself, but occasionally fly in the front seat with friends who are. They're concerned with three speeds: What they call "indicated", TAS, and ground speed from GPS. That's it.

Anyway, this is irrelevant to my post. The analysis used TAS calculated from IAS/CAS (depending on whether you're talking to a pilot or an aeronautical engineer), where elsewhere in this thread I saw agreement on a TAS value of 367 kts, so I used that so it could be compared with other analyses in this thread which also used that value. As long as Mach number matches you should be good to go on the speed. If 367 TAS is wrong then I can redo it with a different number. My "air frame" is what TAS is measured in. My "global frame" (not shown because it's not needed for 0 turn rate analysis) is what ground speed is measured in. My "jet frame" is what VC would be measured in. Hence the two different frames.

VC formula: It was shown in my post. It's answering the question "how quickly is the target moving toward or away from me?" The vector calc method of doing that in 3D is to construct a vector to the target, then take the component of the difference in vehicle velocities along that vector direction. I.e., it's a dot product operation. My calculated VC with this method matches the FLIR VC pretty closely (that's why I did the check) so the rest should be ok.

What's been bothering me is I've seen all kinds of estimates for the speed of this thing from 0 all the way to 500+ miles per hour (by a Colonel fighter pilot, no less, all the more surprising with the VC and air speed data staring her right in the face), and everyone seems absolutely convinced they have the correct answer. So I wanted to do my own. Confirmation bias is rampant. I have yet to see anyone do an analysis at any level and say "gee, this is surprising and isn't what I expected." The people who manage to get 0 or 50 mph or similar are absolutely convinced they're right and get their desired "it's a balloon or bird" answer, while the people who get 500+ are equally convinced their analysis is perfect and conclude it's ET. There's a lot of "let's make it fit" surrounding this thing, whether it's the Colonel who apparently can't read a FLIR correctly or somebody who sees flapping wings in two or three digitally zoomed and processed pixels so is absolutely convinced he's looking at a bird. Maybe he's right, but how can he be so sure? Some of these people have to be wrong (I could be too), and I'm finding it frustrating that everyone is so damned sure of themselves about everything when it comes to this topic.

I'm perfectly happy to say "the target is doing this or that" and at the same time say "I don't know what it is." Meanwhile, I want to get to the bottom of it. If it's aliens, fine. If it's birds, fine. I just want to know either way.

 

[Todd Wasson]

Indeed the trajectory of the plane has to be accounted to retrieve meaningful results. Considering a straight trajectory for the plane will put you way off. The fact that the plane and GoFast are not at the same altitude is important too, so the calculations are more accurate when building a 3D model : https://www.geogebra.org/m/axynssmq

My model gives a speed of 58 Knots for GoFast, considering the lines of bearing and RNG given in the video. Of course we don't know the wind shear between the plane altitude (25000ft) and GoFast (12000ft), that's an important factor that is missing to retrieve the GoFast speed.
This guys did the same kind of analyses and also find a speed of 50-60 Knots :

Source: https://youtu.be/y5Uf4N-JkQY

Thank you. I'll check it out later.

 

[Todd Wasson]

But the heading changes. If I set the turn rate to near zero, then, yes, you get 130+ knots.


But other values give much lower speeds.




Source: https://www.geogebra.org/m/ayazsujy

How do we know the correct turn rate? Neglecting a variable doesn't automatically mean the analysis is less accurate (although it certainly can sometimes). If the correct answer is 2 and I neglect it (0) and you guess 10, my guess is closer even ignoring turn rate. If the real answer is 8 then yours is closer. How do we know?

Are we really just getting turn rate from speed and bank angle in level flight (meaning no altitude changes) with no knowledge of the control inputs? I know Chris was doing that and it made me cringe. I got a minute into him trying to predict the flight path that way and turned it off. Maybe I'm wrong, but with no heading/AOA info or a GPS track I would not expect this could be done with enough accuracy to bother. Might still be interesting to do, but I'd be inclined to take the results with a grain of salt. I certainly wouldn't bother trying anything like that with race cars anyway.

Is this a 2D treatment or 3D and presented in 2D?

I'll look more at your circle picture (think I saw it in one of the de-de-de-debunk things between you and Chris and thought it was neat, nice job), but I'm wondering if those solutions are valid and consistent with the VC readings. The velocities of the object in the two cases are very different from one another, so my (not always perfect) intuition is telling me they'd result in different VC readings and rule out certain trajectories. Tracing paths and projecting target position possibilities from directions is one thing, making sure the velocity measurements along the target direction vector fits with that too seems like it'd be quite another. Perhaps you've analyzed that in detail already and found them valid? If not, maybe try putting velocity vectors on those target points consistent with the travel between the two points and see if they dot with the direction vectors to reproduce the VC reasonably well. Maybe just one velocity vector like I did connecting the two target points. I think we're all probably pretty ok with the target constant velocity scenario.

I wonder if it's possible to work backwards from the VC and the target direction vector to get the target velocity vector directly which might rule out certain trajectories for the jet and target. Will have to think about that one awhile.

Meanwhile, I hope we keep in mind we don't know the laser/IR beam status yet so this may be much ado about nothing (including my analysis). Perhaps that was done already and I haven't seen it. All I know is Lehto was pointing out in that first video that they weren't, and I knew from DCS that if the laser isn't on the target then it's just giving a rough estimate at best (totally unreliable, I missed tons of laser guided bomb targets until I found this out). What do we do if fighter pilots who rely on these systems to bomb targets tell us the range is invalid? Tell them they're wrong?

Don't know about you, but one thing I found frustrating in my analysis was the range info (assuming it's right) only goes to one decimal place, a whopping 600 feet of room for error immediately. Plenty precise for a fighter pilot's job probably, but not ideal for analysis. I wish we had the onboard telemetry from the F-18, but I doubt that'll ever happen.

 

[Todd Wasson]

Mick, a little more on VC: Referring to your geo pics, imagine putting a velocity vector for the target connecting the two target points (start and end) in both pictures. VC would be something like the component of that velocity vector along the target direction vector (from jet to target). Those two pictures would give different VCs at the initial jet position and flight direction regardless of the flight path of the jet afterwards (turning or not). So it would not seem to me like both (maybe neither) could be valid solutions at the same time if VC data is present. From a position only perspective they might be fine, but with VC data I'm not so sure. Maybe it is, I just have some alarm bell going off in my head right now about that. Will chew on it another time. Maybe I'm misfiring.

 

[Todd Wasson]

In the A10 an 'L' will appear when the laser is firing, if the 'B' appears on the screen, to denote both IR and laser are active, the 'L' for laser will still show, also the 'B' doesn't flash.




In the F-18 the flashing B next to the altitude means that the altitude switch is set to show RADAR altitude, however the aircraft is too high to give an accurate number for this so has defaulted to displaying the barometric altitude instead.

If the laser were firing then we would have a lot more indication; an 'L ARM' displayed to show the laser is armed, a flashing 'LTD/R' when it is firing and the target reticule bars will also flash. Here is me firing the laser to demonstrate, the aircraft must be in air to ground mode and the operator must pull the trigger to get the laser to fire, as far as I understand it wouldn't usually be operated manually to get range like this, instead it would automatically fire once a laser-guided bomb has been released:

All evidence points to the range coming from the RADAR plus trigonometry, there is no real reason to doubt the accuracy apart from Chris Lehto dismissing it and given he doesn't really explain why it's inaccurate + his increasingly dodgy videos I'm happy to say he's wrong.


I agree, unfortunately pilots are generally not willing to go into the details of classified systems. Here is the only take from an F-18 pilot that we have (I think):
Source: https://youtu.be/M9NhOKy2K80?t=505

Sorry, I missed your post trying to reply to everyone. I need to get some real work done so will read it later. Skimming quickly I see you answered a couple of my questions (flashing "B" especially), so I thank you. I'll read the rest later.

Just a quick one for now: Seems you're confirming (the best we can right now) that indeed there's no laser or IR ranging after all, which I think would just leave radar like you described. I'm skeptical of a radar track 58 degrees off the nose and 36 degrees down at 3-4 miles, especially with the other claims about it being only 6 feet in size. Can we be 100% sure there's a radar lock? (Maybe you explained it in your post already and I skimmed too quickly).

If I'm wrong and there is a radar lock, wouldn't that rule out a bird? Don't know about you, but in DCS I have a hell of a time getting the F18 to hold a radar lock on anything. It's annoying as hell. You can breath too loudly and it'll lose lock. I had a Mig-29 heading straight at me, two miles away and couldn't get the stupid radar to even ping it, much less lock. I have a hard time believing the real plane is that horrible, but if it is, well.... Bird locks at 58/36 degrees 3-4 miles out are probably out of the question.

Can we rule out the possibility that the range information is an estimate from the FLIR system itself? That's what it sounded like Lehto was saying and the DCS A10 indeed seems to do something like that with ground targets (hence my initial terrible bombing runs with that plane, my range was inaccurate so the pickle timing was off far enough for most of my laser guided bombs to miss the targets by a long shot. I then learned I had to lase the target briefly to update range even for a stationary ground target).

On the software side I could imagine writing a "no laser/IR beam or radar track" case that assumes the FLIR target is the size of a typical fighter plane, scans the pixels for size and reports range that way if no track data is present. Maybe it could use intensity to help estimate range. Is that possible or do we know for sure that isn't the case?

We really need to be sure about the range. If we're not, this is largely a waste of time and we should probably just conclude what the Navy did when they did their analysis with full telemetry access: "Unknown."

On another note, it's good to see a fellow DCS player here. What do you run? I've got the Warthog setup with Oculus. It's mind bending.

 

[Todd Wasson]

Looking at go fast again now I don't think there's a radar lock. If there was he could have slaved the FLIR to it instantly like was done in the gimbal video. In go-fast it looks like the FLIR itself acquires the target (probably looking for moving patterns in contrast or similar) after some manual FLIR steering to try to get it somewhere on screen. The Wizo seems to say so himself when the pilot asks him how he locked it and he says auto mode. That's when the range pops up. Let me know if you disagree, but I'm pretty sure that's not a radar lock which would mean we have range uncertainty, and possibly a considerable amount just like Chris said and we see in DCS World (you'd have to specifically program that into the model, it wouldn't be there by accident). Chris said the laser is powerful enough to blind you from 18 miles so they're not exactly in the habit of shining it on air targets.

The only way I can imagine ranging something is with a beam of one kind or another or estimate it from pixels, but to do that I'd think you'd have to make an assumption about the size if it can't identify the target visually. My only question is how bad could the range info really be? Just because we can see it tracking smoothly from 4.0 to 3.9 to 3.8, etc., doesn't mean it's not off by a long shot. Maybe it is, maybe it isn't, but I want to be sure. We all should.

 

[Todd Wasson]

Can I ask why you think we did this debunk in the 1st place?

I didn't think of it at all. It doesn't matter to me.

 

[jarlrmai]

I didn't think of it at all. It doesn't matter to me.

Interesting, where do you think the need to work out the height/speed of the object came from? I mean on the face of it this video isn't that interesting right? You've shown that it's just a slow moving object that doesn't do anything unusual. Why the fuss?

 

[jarlrmai]

Looking at go fast again now I don't think there's a radar lock. If there was he could have slaved the FLIR to it instantly like was done in the gimbal video. In go-fast it looks like the FLIR itself acquires the target (probably looking for moving patterns in contrast or similar) after some manual FLIR steering to try to get it somewhere on screen. The Wizo seems to say so himself when the pilot asks him how he locked it and he says auto mode. That's when the range pops up. Let me know if you disagree, but I'm pretty sure that's not a radar lock which would mean we have range uncertainty, and possibly a considerable amount just like Chris said and we see in DCS World (you'd have to specifically program that into the model, it wouldn't be there by accident). Chris said the laser is powerful enough to blind you from 18 miles so they're not exactly in the habit of shining it on air targets.

The only way I can imagine ranging something is with a beam of one kind or another or estimate it from pixels, but to do that I'd think you'd have to make an assumption about the size if it can't identify the target visually. My only question is how bad could the range info really be? Just because we can see it tracking smoothly from 4.0 to 3.9 to 3.8, etc., doesn't mean it's not off by a long shot. Maybe it is, maybe it isn't, but I want to be sure. We all should.

Feel free to chime in:

https://www.metabunk.org/threads/atflir-and-range-information-radar-laser-passive-range.11809/

 

[Todd Wasson]

Interesting, where do you think the need to work out the height/speed of the object came from? I mean on the face of it this video isn't that interesting right? You've shown that it's just a slow moving object that doesn't do anything unusual. Why the fuss?

I want to know what it is.

 

[Todd Wasson]

Feel free to chime in:

https://www.metabunk.org/threads/atflir-and-range-information-radar-laser-passive-range.11809/

Thanks, will take a look.

 

[Leonardo Cuellar]

Thanks for the wind information. Good to know.

Flashing B next to the altitude at the bottom right, yes. I'm not sure if that means what I think it does (video game programmer and flight sim junkie here, not a real pilot, and definitely not military), but in DCS World it works that way on the A10C at least. I haven't tried the pod on the F18 (no guarantee it's the same as reality anyway) so I'd need confirmation from Raytheon or a pilot to be sure unless somebody here already knows.

Regarding the turnrate, you have focused on a further problem that consolidates the fact that the GOFAST video isn't debunked at all as it has been led to believe since its release. Of course, a maneuver as you have assumed is closer to a acrobatic maneuver than to a dogfight. My question about VC is very simple. You calculated the closure speeds, and compared them to the values shown on the HUD / SA. But I asked you: you have found some values of TAS, but are you sure that the values of VC that appear on the display are in TAS and not in IAS? All speed values on an aircraft cockpit are expressed in IAS. Are you sure that instead the VC is expressed in TAS? However, I agree with you that the trend of the VC excludes some types of trajectory, where initially the two objects are on divergent or distancing trajectories. I am sure that like me you have the feeling that what you see is odd because its speed isn't unusual but the fact that its shape and its aerodynamic characteristics, identified by weapon systems and professionals, was not able to reach them.

 

[dimebag2]

@Todd Wasson, I just had a quick exchange with a military pilot on Reddit, here is what he says about the range in GoFast : "I can tell you that lasing anything is NOT allowed for routine encounters. You’d need to be legit targeting something for that to be allowed. So it makes sense that the laser was not in use. But FLIR pods use look angles to estimate range and location. You can correlate that with radar to get relatively precise info."

Then I told him that in my model I don't use the RNG, only the plane trajectory and lines of bearing from the camera to retrieve the GoFast trajectory. And at an altitude of 12000 ft the potential trajectory of GoFast exactly matches the numbers of the video (suggesting the geometry is correct). This supports that the RNG is an estimate based on what the FLIR sees. He then replied this :
"Yes, I think the ranging is likely derived by what you said. Largely by aircraft sensors corroborating with look down angles of the lens, perhaps even focus plane, to determine an estimated range. I wouldn’t bet money on the range value. But it’s at least a starting point."

For GoFast to be fast, one would have to determine how the RNG estimate may have been way off. Just an example, an unusual temperature for the object (but is apparent IR temperature even used to estimate the RNG) ?

 

[Todd Wasson]

Sorry, Leonardo, I misunderstood your question the first time and thought you were asking about the calculation itself and coordinate frame selection, not the units. You wrote:

"My question about VC is very simple. You calculated the closure speeds, and compared them to the values shown on the HUD / SA. But I asked you: you have found some values of TAS, but are you sure that the values of VC that appear on the display are in TAS and not in IAS?"

That's a good point I hadn't thought of. I wouldn't think IAS would be used for anything other than the plane's airspeed, but I'm not sure. I'd think what's valuable to the pilot would be to know how fast they're actually approaching a target (that would be the real closure speed after all). I don't see why showing anything else (IAS) would make any sense. I don't know for a fact that that's the case though, so I have to say "I don't know." Best I could do is fire up DCS and see how it works there, although I can't be 100% sure the results there would apply to the real plane, so it wouldn't really prove anything. Maybe a good question for Lehto next time Mick talks to him?

(Mick, if you're reading, I just watched the playback of your live stream with Chris and thoroughly enjoyed it. Hats off to both of you. Your video of the de-rotation of the sun answered a question of mine. Great demonstration.)

"I am sure that like me you have the feeling that what you see is odd because its speed isn't unusual but the fact that its shape and its aerodynamic characteristics, identified by weapon systems and professionals, was not able to reach them."

Yes, my sentiment is somewhat similar. The "very slow object" (balloons and birds) explanations aren't sitting well with me yet. On the other hand we have the Colonel claiming 500+ mph which I see as even more ridiculous. Seriously, I have no idea how she arrived at that. Either she's wrong or I have very seriously misunderstood something here. Anyway, maybe if I get time to spend a day on this I could try to reproduce the whole thing in Unity with matching VCs and so forth to see what would be required, although I'm not sure there's a point if we are now sure the range info is too far off the mark. Not sure if it's really possible with the given information anyway, but it might be an interesting exercise regardless. Who knows, maybe with a little curvature it'll change the picture dramatically for me like Mick said and I'll end up surprised? Maybe there's only one solution that would match up the whole trajectory with VCs and everything. Then it'd be a done deal in my book one way or the other, or if we find the range info is unreliable by a large margin, I'd just chalk it up as "unsolvable/unknown" like the Navy apparently did.

Either way, like you wisely pointed out, I better make sure it's really TAS and not IAS.

 

[Todd Wasson]

@Todd Wasson, I just had a quick exchange with a military pilot on Reddit, here is what he says about the range in GoFast : "I can tell you that lasing anything is NOT allowed for routine encounters. You’d need to be legit targeting something for that to be allowed. So it makes sense that the laser was not in use. But FLIR pods use look angles to estimate range and location. You can correlate that with radar to get relatively precise info."

Then I told him that in my model I don't use the RNG, only the plane trajectory and lines of bearing from the camera to retrieve the GoFast trajectory. And at an altitude of 12000 ft the potential trajectory of GoFast exactly matches the numbers of the video (suggesting the geometry is correct). This supports that the RNG is an estimate based on what the FLIR sees. He then replied this :
"Yes, I think the ranging is likely derived by what you said. Largely by aircraft sensors corroborating with look down angles of the lens, perhaps even focus plane, to determine an estimated range. I wouldn’t bet money on the range value. But it’s at least a starting point."

For GoFast to be fast, one would have to determine how the RNG estimate may have been way off. Just an example, an unusual temperature for the object (but is apparent IR temperature even used to estimate the RNG) ?

Thanks for sharing the pilot information. Some of that is new to me so I've learned something. It sounds like he's saying we can't count on the range indicator after all? So we have some error tolerance, my next question would be how much error could we be looking at here? Closer to 0.1 miles or 1 or 10 miles or what? If it's not some ridiculously huge margin I could repeat the analysis for a couple of extremes and see what speeds we get, at least for the 0 turn rate case. Normally if the range info isn't reliable I wouldn't bother, same reason I didn't try to estimate turn rate.

 

[Todd Wasson]

Of course, a maneuver as you have assumed is closer to a acrobatic maneuver than to a dogfight.

Yes, I was showing the most extreme example possible to illustrate the point that bank angle doesn't tell us the turn rate. As I understand it, the charts people refer to are the simplest possible 2D solution. They're correct only in the case where the aircraft lift vector lies entirely along the vertical plane (geometric plane as in a big flat surface, not "airplane") between the turn center and the aircraft, and the thrust vector is aligned with the velocity vector. In other words: 0 AOA. The latter is not necessarily true, and in the presence of any angle of attack, the former never is and the latter usually isn't either. If it were true, 90 degree bank in level flight (level meaning "not changing altitude" here) with 0 turn rate would be impossible. It's not. All you need is a lateral force component in the aircraft's frame (left/right along the wings) and some upwards thrust to reduce the lift vector requirement and alter the turn rate at that bank angle away from the 2D case. Throw in some side slip and a little rudder action and it changes it more. So no, I'm afraid we can't really use bank angle to predict turn rate or radius even at small bank angles and low turn rates (maybe even more so at low turn rates). This isn't an "acrobatic maneuver" thing either, it's an "all turns of any kind" thing. This is another area where 2D simplifications can lead us into trouble.

This could probably have been better illustrated had I started the knife edge video with it already at 90 degrees roll so that thumbnail is visible, then said "before you start the video, tell me the turn rate and turn radius. When you think you know the answer, hit play."

I would accept that kind of curved path analysis as reasonable if heading information was on screen though. It's unfortunate the FLIR doesn't show it and we don't have GPS telemetry.

 

[Z.W. Wolf]

Article dated: Dec. 6 2013

Navy demonstrates ability to launch surveillance UAVs stealthily from submerged submarines​

WASHINGTON, 6 Dec. 2013. U.S. Navy researchers have demonstrated a long-sought-after capability to launch unmanned surveillance aircraft stealthily from submerged submarines, which vastly extends the reach of the Navy's submarine force as a long-range reconnaissance asset.

Officials of the Naval Research Laboratory (NRL) in Washington on Thursday announced they have demonstrated the launch of an all-electric, fuel cell-powered, unmanned aerial vehicle (UAV) from the fast attack submarine USS Providence ((SSN 719) while the submarine was underwater.

The drone involved was the NRL-developed Experimental Fuel Cell Unmanned Aerial System (XFC UAS), a folding-wing UAV launched vertically from a Sea Robin launch vehicle, which itself was launched from a Tomahawk cruise missile launch cannister inside a torpedo tube aboard the Providence, a Los Angeles-class attack submarine -- one of the smallest submarines in the U.S. subsurface forces.

This configuration of the Sea Robin launch vehicle and Tomahawk launch canister launched from a torpedo tube also could be employed aboard Navy Virginia-class attack submarines, Seawolf attack submarine, and Ohio-class ballistic-missile and cruise-missile submarines.

During the test aboard the Providence off the U.S. East Coast, the Sea Robin launch vehicle containing the XFC UAS rose to the ocean surface after discharging from the torpedo tube. When the package reached the surface, it appeared as a spar buoy.

The "capability to launch unmanned surveillance aircraft stealthily from submerged submarines" issue may have more relevance to the 2004 Tic Tac case. Afterall, there was a development phase to this technology. In 2013 this "long sought-after capability" was mature enough to be revealed publicly. It seems to be reasonable that the year 2004 would fit within that apparently long development phase.

If the image we're seeing on the video was produced by the fuselage and the wings are not visible, this shape fits what we see.

But doesn't it also fit the fuselage-only shape of innumerable small fixed wing aircraft?



Typical light sport aircraft. Fits well within the maximum speed estimate of 66 mph and the low of 20 mph (with headwind). [see below]

And it fits the body-only shape of birds.

Referring to the The Quantum Physics Boys Video... their estimate at 52 knots (59 mph). They say the "The Cholla" estimate is 58 knots (66 mph). And they say that MW's estimate is 20 to 40 knots (23 to 46 mph). All of these values are within the capability of migratory birds at high altitude.

Airline passengers aren't the world's only high-altitude travelers: Bar-headed Geese have been observed migrating at elevations topping 23,000 feet in the Himalayas. Roaming the frigid skies around Mount Everest is no small feat, and for most animals — including humans — these heights are basically off-limits. Even well-equipped mountaineers with oxygen masks and polar expedition gear can have trouble functioning at this altitude. Not so for the amazing geese that brave these oxygen-starved elevations armed with nothing but their own stamina and wing power.

Migratory birds travel at the same speeds we usually do while driving. These range from 15 to 55 miles per hour, depending on the species, prevailing winds, and air temperature.

Because there is only one object let's look at birds that fly inside a home territory.

Golden Eagle Behavior​

https://www.eagles.org/what-we-do/educate/learn-about-eagles/golden-eagle-behavior/#:~:text=Extremely fast, they display astonishing,speeds of 150 – 200 mph.

[Golden Eagles] are... extremely fast.... A normal soaring speed is about 28-32 mph; when they are hunting, they can glide [straight and level] at speeds up to 120 mph. When diving (or stooping) for prey, they reach speeds of 150 – 200 mph.

.


Pelican
https://en.wikipedia.org/wiki/Pelican

A fibrous layer deep in the breast muscles can hold the wings rigidly horizontal for gliding and soaring. Thus, they use thermals for soaring to heights of 3000 m (10,000 ft) or more... to commute distances up to 150 km (93 mi) to feeding areas.

Pelicans fly at a more modest 20 to 30 mph. But this is airspeed. What about groundspeed with a tailwind?

I don't see why the bird hypothesis is "unconvincing."

 

[Leonardo Cuellar]

I don't see why the bird hypothesis is "unconvincing

These records are made under completely different conditions. A pelican or bird of prey can reach 3000 meters by taking advantage of thermals, not flying straight uphill for a long time. So also the Indian geese, reach those altitudes but always fly at very low heights from the ground. If a bird was visible in the GOFAST video, there is no biological justification for it to travel at 5000 meters level, over 300 miles from the coast at a constant speed of tens of mph, in winter.....

 

[Leonardo Cuellar]

This could probably have been better illustrated had I started the knife edge video with it already at 90 degrees roll so that thumbnail is visible, then said "before you start the video, tell me the turn rate and turn radius. When you think you know the answer, hit play."

Impeccable.
I ask you: it is possible to take advantage of the parallax of the background to obtain the speed of the object, thus transferring all motions into an absolute frame of reference such as the ground?