I'm reviving this topic due to the NASA UAP Panel discussion, where Joshua Semeter, the Director for Space Physics at Boston University, gave at talk that was essentially my initial analysis of GoFast
Source: https://youtu.be/PLyEO0jNt6M?t=302
In his "Determination of Object Velocity" he did a single turn-rate overhead analysis with no wind.
The 34 knots, 40 mph, that he calculated, is in line with the range of possible speeds that I and others calculated back in 2018, in the original Go Fast thread:
https://www.metabunk.org/threads/go...onges-to-the-stars-academy-bird-balloon.9569/
(there's a LOT of work in that thread, some out-of-date, but a lot of relevant thoughts, calculations, data extractions, and visualizations)
This current thread outlines some of the issues with wind.
The 2D simple analysis:
- Assumes zero wind, so airspeed is the same as ground speed. But the wind will be different at different altitudes, and reportedly 120 knots at 25,000 feet.
- Assumes a single bank angle, when the bank angle changes.
- Only considers two lines of sight.
Subsequent analysis using multiple lines of sight revealed some squiggly paths. But that is probably due to inaccuracies in the data.
Sitrec is my situation recreation tool, which I've not really looked at a for a few months, so I need to get back up to speed with what it is doing. But I think there's a variety of issues and unknowns:
TURN RATE, and its application
The turn rate is a simple function of the bank angle (extracted from the on-screen artifical horizon) and the jet speed (a constant: TAS, True Air Speed = 341 knots)
JavaScript:
function turnRate(bankDegrees, speedMPS) {
var g = 9.77468 // local gravity at 36°latitude, 25000 feet https://www.sensorsone.com/local-gravity-calculator/
var rate = (g * tan(radians(bankDegrees))) / speedMPS
return degrees(rate);
}
The current code takes the turn rate and uses it to rotate the jet each frame. The jet speed is then applied along the forward vector of the jet, meaning the jet is always pointing in the direction it is moving relative to the air around it. This does not seem entirely physically accurate, as the direction of the
velocity of the jet will lag a little behind the direction of the
body of the jet.
More realistically I'd have separate orientation, velocity, and angular velocity which would then all be affected by the combination of thrust, air pressure, and the configuration of the flight control surfaces. I think the lack of this is, in part, responsible for the irregular path.
In the Gimbal analysis this was "fixed" by adjusting the turn rate so the resultant video matched the movement of the clouds. In Gimbal, here's the resultant path using "Match Clouds"

And then using "Bank and Speed"
GoFast currently does not have a "match water" option, and we have a somewhat irregular path.
Matching video is the ultimate arbiter of the simulation. Inaccuracies come from inadequacies (and possibly errors) in the simulation, and errors or low resolution in the input data. Here we are essentially driving the bank angle from the cloud motion, and then using that in our simple model, but it does not mean that it's simply the bank angle that was wrong. There are other sources of error.
INACCURACIES IN ON SCREEN NUMBERS
The numbers we use are Azimuth, Elevation, and Range. The most obvious limitation is that they are low resolution - to 1 degree, or 0.1 NM for range. But they are also of uncertain fidelity. The angles are probably accurate to within 1°. The RNG value is in steps of about 600 feet, and it's not clear how it is derived. Some have said it's totally wrong, and the object is down by the water. I'm working under the assumption that it's
roughly correct.
PITCH
Pitch seems to be displayed by the position of the plane angle above the artifical horizon. At the start the wings are level, and the plane pitched up a bit. When they bank to the left, they pitch up a bit, and then this pitch is gradually reduced. This is probably the autopilot pitching up and increasing thrust to maintain speed and altitude. I'm not sure if this plays a part - but it might be responsible for the initial curve of the path after lock-on.
For now I need to dig back into the code (and data), and start by visualizing the data a bit better to see why the end result is the way it is. I'll work towards using the water speed (and direction) as a driver.