Scaramanga
Senior Member
One is assuming that the balloon actually came from the nearest shore. We actually have no idea. It might have been round the world twice for all we know.
Go Fast - Balloon theory
- Thread starter jackfrostvc
- Start date
One is assuming that the balloon actually came from the nearest shore. We actually have no idea. It might have been round the world twice for all we know.
TheCholla
Active Member
What if Gimbal/GoFast happened on the evening of January 24 EST? And not Jan21. Jan25 2:30 UTC is the date that is indicated in the metadata of the Gimbal video.
January 25 is also the dates given for these events (referred to as the new "Tic-Tac events"), in an unclassified DoD email Marik had found.
Source: https://twitter.com/MvonRen/status/1520055496836718593?s=20&t=If3RD6rJKKQVRkyjFkaVkQ
This correspond to 9:30pm local (EST), and R. Graves has said Gimbal was filmed in the evening at the end of a training exercise.
The evening of January 24 is a much closer match as far as wind speed close to 25000ft, compared to Januray 20. At 8pm local (Jan25 1UTC), now we find the wind being >110 knots at 300 miles off Jacksonville. The wind is also stronger at 14000ft that evening, but for the wind to reach 100Knots they would have to be very far off the coast.
Jan 25 1UTC (8pm local EST)
Below I show it a bit earlier, 5pm local, to check the whole evening. Jacksonville is right in the band of strong westerlies at 24000ft (probably a bit stronger at 25000ft, i.e. ~120Knots).
So there is a strong possibility that Gimbal was filmed on January 25 UTC, despite the official document released by the Black Vault dating the events to January 21. Maybe a bureaucratic mistake?
It doesn't change the analyses, it only removes any remaining possibility that the Atlas rocket has something to do with it. I also like January 24 better because that's my birthday
For GoFast, more room for wind versus intrinsic speed, although the wind still does not reach the estimated ground speed me and Mick have found (>100 Knots).
Jan 24 22UTC (5pm local EST)
January 25 is also the dates given for these events (referred to as the new "Tic-Tac events"), in an unclassified DoD email Marik had found.
Source: https://twitter.com/MvonRen/status/1520055496836718593?s=20&t=If3RD6rJKKQVRkyjFkaVkQ
This correspond to 9:30pm local (EST), and R. Graves has said Gimbal was filmed in the evening at the end of a training exercise.
The evening of January 24 is a much closer match as far as wind speed close to 25000ft, compared to Januray 20. At 8pm local (Jan25 1UTC), now we find the wind being >110 knots at 300 miles off Jacksonville. The wind is also stronger at 14000ft that evening, but for the wind to reach 100Knots they would have to be very far off the coast.
Jan 25 1UTC (8pm local EST)
Below I show it a bit earlier, 5pm local, to check the whole evening. Jacksonville is right in the band of strong westerlies at 24000ft (probably a bit stronger at 25000ft, i.e. ~120Knots).
So there is a strong possibility that Gimbal was filmed on January 25 UTC, despite the official document released by the Black Vault dating the events to January 21. Maybe a bureaucratic mistake?
It doesn't change the analyses, it only removes any remaining possibility that the Atlas rocket has something to do with it. I also like January 24 better because that's my birthday
For GoFast, more room for wind versus intrinsic speed, although the wind still does not reach the estimated ground speed me and Mick have found (>100 Knots).
Jan 24 22UTC (5pm local EST)
Last edited:
jackfrostvc
Senior Member
I think I mentioned this before, but did you account for ocean water speed? Rather than assume it's static
JMartJr
Senior Member.
Speed of wave propagation is the key, I think... actual speed of the water is probably not detectable.
Didn't someone post a link where you can track meteorological balloons? I think it was in one of the threads dedicated to the Chinese spy balloon and related objects.
I don't have time now, but might be worth taking a look to see if there are any balloons in that area at the time of the video.
I don't have time now, but might be worth taking a look to see if there are any balloons in that area at the time of the video.
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:
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)
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.
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.
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.
Last edited:
Similar threads
