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

Mick West

Administrator
Staff member
I suppose he revised his calculations because it wasn’t fitting the original narrative of TTSA that the object must be moving fast 380 Kn at a low altitude of 100 ft)
I think he did some revision after discovering the CAS/TAS problem, he's still using 250 knots there (CAS)
 

Kaen

Member
The question is if the event log fits the objective events.

Here's a theory: occasionally, over the course of a decade, a pilot will lose situational awareness, but not realize it, and then later write down what he recalled observing.
Yes, but what makes this case interesting is that a second jet was involved and its pilot, Jim Slaight, also seems to have lost situational awareness:

Fravor's recollection is not of the events shown in the video, and really should be treated as separate.
Yes, the video was not made by Fravor, but some time later from another jet at another location - the jet was sent there because the object re-appeared on radar.

But this is the GO FAST thread.
Noted, so I'll stop now ;)
 

Mick West

Administrator
Staff member
Sounds like he did some good work there.
Except for the GIGO aspect. He used the composite screenshot from TTSA which had 4.1 RNG at 22°, when the actual angle was 28°. Also got the plane speed wrong, as mentioned above. And he got the time wrong. All of which I think he later corrected.
 

Mick West

Administrator
Staff member
When assuming how the ATFLIR camera tracks is there anything I should be taking in to account? Can I discount the roll of the aircraft as the camera compensates and translate the camera mount in the x,y,z only?
I think so.

It would be useful to demonstrate the difference between the ground tracking (based on atltude and angles) and a "snowplow" mode where the camera points in a fixed direction/tilt.

The start of the video (e.g from 00:01 to 00:03) appears to be ground tracking, which kind of gives the illusion it was filmed from a helicopter. If it were in snowplow mode I think the sea would be whizzing by. So that would be good to show.
 

Tom Mellett

New Member
I think he did some revision after discovering the CAS/TAS problem, he's still using 250 knots there (CAS)
Mick, but that begs the question of who determined the original narrative of TTSA that the object was flying very fast (380 kn) very close to the surface (altitude = 100 ft.). I don’t think they based it on Macabee’s calculations, which were made March 9 and March 12.

EDIT: Here’s the link
https://coi.tothestarsacademy.com/2015-go-fast-footage/

 

Mick West

Administrator
Staff member
Mick, but that begs the question of who determined the original narrative of TTSA that the object was flying very fast (380 kn) very close to the surface (altitude = 100 ft.). I don’t think they based it on Macabee’s calculations, which were made March 9 and March 12.

EDIT: Here’s the link
https://coi.tothestarsacademy.com/2015-go-fast-footage/

They don't say 380 knots there, or anywhere that I know of.

Their analysis there is incredibly weak, and seems to be based entirely on a subjective visual assessment. i.e. they simply think it looks like it's close to the ocean surface. So I suspect whoever did it was a pretty non-technical person, perhaps Elizondo? Whoever it was, it's reflected very poorly on TTSA's technical abilities.
 

Tom Mellett

New Member
They don't say 380 knots there, or anywhere that I know of.

Their analysis there is incredibly weak, and seems to be based entirely on a subjective visual assessment. i.e. they simply think it looks like it's close to the ocean surface. So I suspect whoever did it was a pretty non-technical person, perhaps Elizondo? Whoever it was, it's reflected very poorly on TTSA's technical abilities.
OK, I got those numbers from Garry Nolan. Now that there’s a clearer picture of TTSA incompetence, I will go back and ask Garry where he got those numbers from.
 

Tom Mellett

New Member
Sounds like he did some good work there.
But what is baffling to me is that he did calculate an object altitude of 1.6 nm which I round up to 10,000 feet. And he even made a remark that this altitude is not close to the ground, thus directly contradicting the “Official” TTSA narrative about the object being very close to the water surface. And yet he still ignored the parallax effect of that altitude in his speed calculations.

Mick already noted his error of using CAS instead of TAS, but at least this version shows that BM is not responsible for the official TTSA statement about the object altitude.
 

Kaen

Member
Hello @Kaen ! Thank you so much for that diagram above. It is really helpful to explain parallax effect to those unfamiliar with it.

However, before I ask you questions I have about the assumptions made in the diagram, I would like to drop back and punt because I just discovered on FB Bruce Maccabee’s Original calculations made on March 9. (You operated only from his revised calculations dated March 12.) Here is the text of his original calculations. Does it give you any more insight into his process? It looks like his original calculations were more in line with yours, but then I suppose he revised his calculations because it wasn’t fitting the original narrative of TTSA that the object must be moving fast 380 Kn at a low altitude of 100 ft)

Bruce probably based his calculations on a period in the video above where the object crosses the display while the ATFLIR is more or less fixed on the same patch of sea. This is the period from 5,5 s – 7,3 s (duration 1,8 s).

The picture below contains the snapshots of the object entering and leaving the FOV. I projected the object’s end position in the first picture, taking a slight shift of the camera into account (the white rectangle shows the same patch of sea). From these two positions I calculated the percentage of the ATFLIR FOV that the object crossed in these 1,8 seconds.

upload_2018-3-21_19-58-35.png

Let’s go through Bruce's calculations step by step:
The calculated 2,46 nm is not a ‘below airplane altitude’ but the actual object altitude.
During Bruce’s 1,8 s period, the object slant vector is at a downward angle of 24 degrees, not 22.
Slant range is unknown at that time, but can be estimated: At 12 s it is 4,4 nm and decreasing with 0,1 nm per 1,8 s. So at 6 s in the video the estimated slant range would be 4,4 + (0,1 x 6/1,8) = 4,7 nm, not 4,1 (later 4,5).

This gives an altitude difference between jet and object of 4,7 x sin(24) = 1,9 nm.
Jet is at 4,1 nm altitude so object is at 4,1 – 1,9 = 2,2 nm altitude (13.300 feet), not 2,46.

The actual range is closer to 4,7 nm (see above). This gives 0,12 nm instead of 0,1 (later 0,117 nm).

I wonder whether the 1,5 degrees FOV is correct. I thought this was the FOV at zoom level 2, it may be 0,3 degrees at zoom level 1. This would double the value to 0,24 nm

I made a more accurate estimate of the FOV coverage (see picture above), it is 1,31 so the total distance is 1,31 x 0,12 = 0,16 nm instead of 0,14 (later 0,165 nm).

With the 0,16 instead of 0,165 nm this yields a differential speed of 0,16/1,8 = 0,089 nm/s = 316 kt instead of 330 kt, so very close to Bruce’s value.

The 330 kt is a differential speed and needs to be compensated for the parallax effect. Here, Bruce makes some crude approximations using the CAS of the jet, and assuming the parallax compensation equals the jet speed.
In reality the parallax compensation is 0,52 x the jet speed (see my post about the parallax). The camera shifts a little (about 16% of the FOV) along with the object’s trajectory while the object passes. This will add an additional 16% to the parallax compensation speed that I estimated (267 kt instead of 230 kt).

Note that the speed in the ATFLIR display being CAS is solely based on the annotations in the video made by TTSA. Maybe TTSA was wrong and the speed is based on something else like GPS data.


A few additional remarks:

The assumed FOV of the ATFLIR is 1,5 degrees. It may be twice that, i.e., the narrow FOV of an ATFLIR is 3 degrees according this document:
https://www.forecastinternational.com/archive/disp_old_pdf.cfm?ARC_ID=452
That would double the computed differential speed of the object to approximately 650 knots. This speed no longer implies a bird or balloon, and it no longer complies with the speeds computed earlier in this thread.

The object seems to travel against the direction of the jet, while other calculations made in this thread indicate it travels in the opposite direction. This is odd.
 

Robert Sheaffer

New Member
He can state it all he wants but he really need to show some reason why he thinks that.

Why not?

And where is the focal plane exactly? Nothing really appears to be in particularly sharp focus.
The focus for a camera set on an object 12,000 feet away will certainly also be in good focus for an object 25,000 feet away.
 

Tom Mellett

New Member



I wonder whether the 1,5 degrees FOV is correct. I thought this was the FOV at zoom level 2, it may be 0,3 degrees at zoom level 1. This would double the value to 0,24 nm

I made a more accurate estimate of the FOV coverage (see picture above), it is 1,31 so the total distance is 1,31 x 0,12 = 0,16 nm instead of 0,14 (later 0,165 nm).

With the 0,16 instead of 0,165 nm this yields a differential speed of 0,16/1,8 = 0,089 nm/s = 316 kt instead of 330 kt, so very close to Bruce’s value.

The 330 kt is a differential speed and needs to be compensated for the parallax effect. Here, Bruce makes some crude approximations using the CAS of the jet, and assuming the parallax compensation equals the jet speed.
In reality the parallax compensation is 0,52 x the jet speed (see my post about the parallax). The camera shifts a little (about 16% of the FOV) along with the object’s trajectory while the object passes. This will add an additional 16% to the parallax compensation speed that I estimated (267 kt instead of 230 kt).

Note that the speed in the ATFLIR display being CAS is solely based on the annotations in the video made by TTSA. Maybe TTSA was wrong and the speed is based on something else like GPS data.


A few additional remarks:

The assumed FOV of the ATFLIR is 1,5 degrees. It may be twice that, i.e., the narrow FOV of an ATFLIR is 3 degrees according this document:
https://www.forecastinternational.com/archive/disp_old_pdf.cfm?ARC_ID=452
That would double the computed differential speed of the object to approximately 650 knots. This speed no longer implies a bird or balloon, and it no longer complies with the speeds computed earlier in this thread.

The object seems to travel against the direction of the jet, while other calculations made in this thread indicate it travels in the opposite direction. This is odd.
First of all, the document you link to is an older generation ATFLIR, the NITE-Hawk. Instead of doubling the FOV from 1.5 to 3.0, you may need to cut it in half to 0.7.

The Paracaster calling himself Realm makes an argument that the FOV for this “3rd video” has to be 0.7

https://www.theparacast.com/forum/threads/pentagon-ufo-study-media-monitoring.19069/page-5#post-270549

He quotes from a Raytheon brochure:
Notice the Narrow FOV of 0.7
Here again notice the Narrow FOV as 0.7
And @Kaen , notice in the next line that this version replaces the older NITE-Hawk that you linked to above.
 
Last edited:

jarlrmai

Member
When I finally made what I consider to be a close approximation to the video in Blender the parallax looks closest with a fov of 0.7 and an object of 1 meter, the power of the ATFLIR is quite ludicrous this is tracking an object of that size from kilometers away. Hard part of the video is a sea texture that looks close to the video.
 

jarlrmai

Member
Rough 1st draft proof of concept, whatever other disclaimers you need this is a try.

Source: https://youtu.be/j1O4iBke2vo


assumptions used in render

Object is ~1 meter
Object is stationary (clearly not the case in reality)
FOV is 0.7
Video is 30 fps, tracking lasts 22 seconds, video is 660 frames camera position keyframes each second based on values from post on this thread by JUSTIN SHAW for the tracking period.
Camera tracks object using a constraint in Blender may not match exact tracking characteristics of the ATFLIR.

It would be helpful if someone could confirm the object's position relative to the camera (x/y) at the start of tracking ie how far in front and to the left it is. I have used 5k left of camera and 5.2k ahead.

I can provide the .blend if anyone wants.
 

Agent K

Active Member
First of all, the document you link to is an older generation ATFLIR, the NITE-Hawk. Instead of doubling the FOV from 1.5 to 3.0, you may need to cut it in half to 0.7.

I've argued for 0.7 degrees based on this old brochure and some other reasons.
https://web.archive.org/web/20091211103559/http://www.raytheon.com:80/businesses/rtnwcm/groups/sas/documents/content/rtn_sas_ds_atflir.pdf

But FAS says 30X magnification, which suggests 1.5 degrees, if 1X magnification is 45 degrees.
I thought the "previous FLIR capabilities at 4x" referred to Nite Hawk, but 3 degree FOV is better than 4X magnification.
 

Agent K

Active Member
When assuming how the ATFLIR camera tracks is there anything I should be taking in to account? Can I discount the roll of the aircraft as the camera compensates and translate the camera mount in the x,y,z only?
You can discount the roll of the camera, which isn't displayed in any case, but the video is rolled opposite the roll of the aircraft to keep the horizon horizontal so the WSO doesn't get nauseated. See the Gimbal video. The horizon is tilted in the video, but if you rotate your screen counterclockwise the way it it would be in an aircraft, the horizon will be horizontal.
View attachment 30642
 
Last edited:

Agent K

Active Member
The start of the video (e.g from 00:01 to 00:03) appears to be ground tracking, which kind of gives the illusion it was filmed from a helicopter. If it were in snowplow mode I think the sea would be whizzing by. So that would be good to show.
I wonder if it was in A/G mode or A/A mode. The geopoint ground tracking suggests A/G mode, but all the symbology on the screen resembles the Gimbal video, which was surely A/A.
 

Mick West

Administrator
Staff member
And zoomed in, in 3D the object motion looks pretty random.

I think that's a bit misleading as the limits of your axes are not square, so it greatly exaggerates the up/down and left/right motion. If you view it in a 0.2 nm cube it's
ScreenFlow.gif

A more of less straight line within the rather low resolution we have for angles. Then an odd kink at the end.

Here's the code setting the axes' limits, using NMI for everything for simplicity.
Code:
	  ax.set_xlim3d([-3.2850, -3.2850+.2])
	  ax.set_xlabel('X')

	  ax.set_ylim3d([1.74, 1.74+.2])
	  ax.set_ylabel('Y')

	  ax.set_zlim3d([2.138, 2.138+.2])
	  ax.set_zlabel('Alt')

	  ax.plot(-gs[:,1] / NMI, gs[:,0] / NMI, gs[:,2] / NMI)
 

Mick West

Administrator
Staff member
Is there a list of timestamped coordinates for the tracked object in this thread?
You can't really get one without picking a wind speed and direction. I've been playing with Justin's code, and with the wind at 30,50 and 70 knots (all at 180 degree to the plane's initial heading) the track is radically different. Here the Black dot is the start position, the black triangles are the three end positions. (the red, green, and blue are just the side and top projections). Metabunk 2018-03-23 12-47-05.jpg

Notice the 50 knot path ends up near where it started.

Probably we'd need to pick the wind settings that give the best end result in term of matching the motion of the ocean.

What format exactly are you looking for?
 
Last edited:
You can't really get one without picking a window(sic) speed and direction. I've been playing with Justin's code, and with the wind at 30,50 and 70 knots (all at 180 degree to the plane's initial heading)
Do you mean 'on the nose' ?
At sea level it looks to me to be about 15+ knots, more or less towards the plane (taking into account the the foreshortening of the waves). 30-50 knots at 2.15 nmi altitude seems reasonable.
 

Mick West

Administrator
Staff member
Then an odd kink at the end.
That kink appears to be a data problem, @JUSTIN SHAW you were duplicating the last values on the change times, end the final time, meaning it appeared to have a drastic slowdown at the end. I've redone it without the kink

Here's a scale image showing the jet's motion (red) the objects motion (black, barely visible) and the track this makes on the ground (i.e. the sea surface at the center of the image when locked on) . The movement of the object has little effect on the ground projection
Metabunk 2018-03-23 15-50-15.jpg

But notice the jet has a smooth curve, whereas the ground track varies a bit.
Metabunk 2018-03-23 15-54-39.jpg
Metabunk 2018-03-23 15-54-54.jpg

The image includes drop lines from the start and ends of the paths to show the height above the ground.
 

Justin Shaw

New Member
Nice plot @Mick West! I think the conclusion holds: No strange behavior. I'm standing down on this unless we get more data.

Small hint: arange(start, stop, step) will give an array from start up to (but not including) stop. So your "if (WIND_KTS + SPD_STEP < SPD_END):" check is not required. One nice way to get the spdNames populated is to "join" strings with commas. Like this:

speed = arange(SPD_START, SPD_STOP, SPD_STEP) ## make an array of speeds
names = [str(spd) for spd in speeds] ### make a list of string names
comma_sep_names = ','.join(names)
 
Last edited:

Mick West

Administrator
Staff member
Nice plot @Mick West! I think the conclusion holds: No strange behavior. I'm standing down on this unless we get more data.
Yes I don't think there's a huge amount to be gained here for fine-tuning the details, there's too much inaccuracy (and unknowns) anyway, but the basic thing is there's a slow moving object around 13,000 feet, and the apparent motion is almost entirely from parallax whichever way you dice it.

Here's using all the data (left) vs just the endpoints (right). The track of the object (bottom) varies more, but the end result (top, green) is the same.
Metabunk 2018-03-23 16-52-51.jpg
 

Getoffthisplanet

Active Member
Code attached
I just did a quick eyeball, this is this the same roll data from After Effects that you posted the other day?

Also, I've been using the raw raw X, Y, Z jet position data posted by @JUSTIN SHAW.

Plotting that data is beyond my abilities, are you saying you have an update?

If so, can you post similar to how he did, so I can just basically copy and paste it into an Excell doc?

Code:
x [m], y [m], z [m]
6.33, -0.00,7620.00
 
Last edited:

Mick West

Administrator
Staff member
I just did a quick eyeball, this is this the same roll data from After Effects that you posted the other day?

Also, I've been using the raw raw X, Y, Z jet position data posted by @JUSTIN SHAW.

Plotting that data is beyond my abilities, are you saying you have an update?
That text file was the roll data used as an input to Justin's code.

The curve I'm plotting are slightly different to the ones shown earlier by Justin as there was a problem with the way wind was handled. The newer code does it better, meaning the angles on the plots now match the numbers.

I can output numbers in script format if you like. Let me know what the actual script looks like that you create with Excel.
 
Last edited:

Getoffthisplanet

Active Member
That's text file was the roll data used as an input to Justin's code.
Right. Just want to double check if goFastRoll.txt is the same data contained in Go Fast Tilt tracking.xlsx?

In the meantime, here's the positions that match the diagrams above.
GF_Jet_xyx_30kt-180dg.csv is the updated data I'm interested in.

GF_Target_xyx_30kt-180dg.csv is the unknown object?

I'm not exclusively trying to simulate the actual event. Although, corroborating the data presented here would be great.

So, I'll wait on trying out the GF_Target_xyx_30kt-180dg data. Right now, I've been trying to backtrack/subtract the object's position in Max based on the known variables.

My interest is combining the hard math posted here with presenting the data in an easily digestible way.

My MaxScript is beginner level. It's the result of me discovering the power of both MaxScript and Excel for animating.

jet_position_.ms is for every frame converted to feet since the scripts I have that calculate speed work only when Max's System Units are set to feet.

Code:
with animate on
(
	  at time 0 $jet_position.position =  [20.8,0,25000]
	  at time 1 $jet_position.position =  [41.5,0,25000]
...
	  at time 1029 $jet_position.position =  [21310.4,1111.5,25000] 
)
I've done a few attempts and it seems the raw data for every frame might be too granular.

So, I've been converting the position data into a spline with vertices created for every frame, then normalizing the spline in order to smooth it out for use it as a motion path.

I've been getting fairly consistent results in Max. Altitudes of the object are matching fine.

But, after RNG locks at frame 368 the speed of the object calculated in Max ranges from 45 MPH towards the beginning to 200-300+ MPH on the last 60-70 frames.

This is such a mind bending challenge, as a novice, I've caught myself making mistakes.
 

jarlrmai

Member
The video I made in blender starts at the tracked stage, I just set keyframes for the coordinates of the jet each second and set the framerate to 30fps and then added 660 frames to match the tracked time of 22 seconds.
 

Mick West

Administrator
Staff member
My MaxScript is beginner level. It's the result of me discovering the power of both MaxScript and Excel for animating.

jet_position_.ms is for every frame converted to feet since the scripts I have that calculate speed work only when Max's System Units are set to feet.

Code:
with animate on
(
at time 0 $jet_position.position = [20.8,0,25000]
at time 1 $jet_position.position = [41.5,0,25000]
...
at time 1029 $jet_position.position = [21310.4,1111.5,25000]
)
I've done a few attempts and it seems the raw data for every frame might be too granular.

So, I've been converting the position data into a spline with vertices created for every frame, then normalizing the spline in order to smooth it out for use it as a motion path.
Jitter might be due to the low number of decimal places of previous data. The jet path seems pretty smooth to me.

I added some code to spit out maxscript for the jet and the target. This is only during the time it is tracked, from 14 to 32 seconds.
Code:
def writeMaxScript(thing,positions):
   outFilename = "GF_"+thing+"_MAX_"+str(WIND_KTS)+"kt-"+str(WIND_HDG_DEG)+"dg.txt"
   f = open(outFilename,"w+")
   f.write("/*\nTrack of GO FAST %s in feet for %d Knots at %d\n%s\n*/\n\n" %(thing, WIND_KTS,WIND_HDG_DEG, infoString));
   f.write("with animate on\n{\n")
   t=0
   for p in positions[:]:
	  f.write("\t at time %d\t$%s_position.position = [%f, %f, %f]\n" % (t,thing,p[0]/FEET,p[1]/FEET,p[2]/FEET))
	  t+=1
   f.write("}\n")
   f.close()


writeMaxScript("jet",poss)
writeMaxScript("target",gs)
which writes:
Code:
/*
Track of GO FAST jet in feet for 30 Knots at 180

Turning, Detailed Data (new)
*/

with animate on
{
	 at time 0	$jet_position.position = [19.072251, -0.002185, 25000.000000]
	 at time 1	$jet_position.position = [38.144503, -0.005828, 25000.000000]
	 at time 2	$jet_position.position = [57.216754, -0.010929, 25000.000000]
	...
}
Note higher precision numbers.

output attached.
 

Attachments

Mick West

Administrator
Staff member
You need to interpolate or 'lerp' as it is known for smooth transition between your cartesians.
Who does?

The data above is per frame, so you can't usefully interpolate more. It could be smooth though, with a moving average or somesuch. However I suspect the higher definition numbers will be smooth.
 

Getoffthisplanet

Active Member
Jitter might be due to the low number of decimal places...Note higher precision numbers.
Nailed it:



I added some code to spit out maxscript for the jet and the target. This is only during the time it is tracked, from 14 to 32 seconds.
Good grief. You're a beast.

Thank you for taking the time to whip up the MAXScript. Though, I couldn't get it to run until I replaced the brackets with parentheses.

Just to double check, is that 14 seconds to 32 seconds or 12 to 34?

Also, can you post the position data for all 1030 frames?
 

Mick West

Administrator
Staff member
Thank you for taking the time to whip up the MAXScript. Though, I couldn't get it to run until I replaced the brackets with parentheses.
Oops. My eyes are getting old.

Just to double check, is that 14 seconds to 32 seconds or 12 to 34?
14 to 32, in the code it looks like:
Code:
dt = .0333333333 # time step
t = arange(14, 32, dt) # numpy. returns 1d array from 14 to 32-dt in steps of dt (0.1)
N = len(t)  # nubmer of timesteps in our recreation
Also, can you post the position data for all 1030 frames?
Not easily, the code (which is mostly @JUSTIN SHAW's) is focussed on the tracking portion, it would need a bit of restructuring to model the plane outside of that, and even more to get that synced with a moving object.
 

Getoffthisplanet

Active Member
Oops. My eyes are getting old.
Oh yeah, I hear ya.

Ok, but I thought the thing starts getting tracked at 12 seconds when "4.4 RNG" pops up on-screen then continues on to 34 seconds when the video ends?

Not easily, the code (which is mostly @JUSTIN SHAW's) is focussed on the tracking portion, it would need a bit of restructuring to model the plane outside of that, and even more to get that synced with a moving object.
I mean just the position data for the hornet, not the thing.

@JUSTIN SHAW posted it before so I assumed it was easily updatable, I have no idea.
 

igoddard

Active Member
I think that's a bit misleading as the limits of your axes are not square, so it greatly exaggerates the up/down and left/right motion. If you view it in a 0.2 nm cube it's
View attachment 32340

A more of less straight line within the rather low resolution we have for angles. Then an odd kink at the end.
As well its path appears to be a straight line when the footage is stabilized to the ocean:



But here's the predicted vs actual flight path of a balloon that's similar in its random meandering to the path Justin modeled:



From the blog of a high-altitude balloon business.

https://bovineaerospace.wordpress.com/2015/11/02/predicting-the-flight-path-of-a-solar-balloon/
 

Mick West

Administrator
Staff member
Ok, but I thought the thing starts getting tracked at 12 seconds when "4.4 RNG" pops up on-screen then continues on to 34 seconds when the video ends?
I trimmed the ends so the data only included where the ATFLIR numbers (angles and range) changed, otherwise it's at a value for an unknown length of time. You could probably extrapolate a bit though. So I start just after the first elevation (dip angle) changes at 13s19f, and end just before the last el change at 32s7f. This was to keep the track the object from kinking at the ends.

I mean just the position data for the hornet, not the thing.

@JUSTIN SHAW posted it before so I assumed it was easily updatable, I have no idea.
The positions are relative to where the jet starts (0,0) so starting earlier will yield different numbers relative to where the object is. But see attached.
 

Attachments

Mick West

Administrator
Staff member
But here's the predicted vs actual flight path of a balloon that's similar in its random meandering to the path Justin modeled:
Justin's graph great exaggerated the amount of meandering. It could well be a straight line within the bound of measurement error.

And your balloon path is probably over a much larger time.
 
Top