Tags:
  1. Mick West

    Mick West Administrator Staff Member

    I think he did some revision after discovering the CAS/TAS problem, he's still using 250 knots there (CAS)
     
  2. Kaen

    Kaen Member

    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:

    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.

    Noted, so I'll stop now ;)
     
  3. Mick West

    Mick West Administrator Staff Member

    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.
     
    • Agree Agree x 1
  4. Mick West

    Mick West Administrator Staff Member

    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.
     
  5. Tom Mellett

    Tom Mellett New 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/

     
  6. Mick West

    Mick West Administrator Staff 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.
     
    • Agree Agree x 1
  7. Tom Mellett

    Tom Mellett New Member

    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.
     
  8. Tom Mellett

    Tom Mellett New Member

    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.
     
  9. Kaen

    Kaen Member



    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.

    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.
     
    • Useful Useful x 1
  10. Robert Sheaffer

    Robert Sheaffer New Member

    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.
     
  11. Tom Mellett

    Tom Mellett New 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.

    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/t...udy-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: Mar 21, 2018
  12. jarlrmai

    jarlrmai New 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.
     
  13. jarlrmai

    jarlrmai New 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.
     
  14. Mick West

    Mick West Administrator Staff Member

    Yes please. You should be able to upload it, or mick@metabunk.org
     
  15. Agent K

    Agent K Member


    I've argued for 0.7 degrees based on this old brochure and some other reasons.
    https://web.archive.org/web/2009121...s/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.
     
  16. Agent K

    Agent K Member

    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.
    20171216-124632-bqy6h.
     
    Last edited: Mar 21, 2018
  17. Agent K

    Agent K Member

    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.
     
  18. Mick West

    Mick West Administrator Staff 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
    ScreenFlow.

    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)
    
     
    • Like Like x 1
  19. Justin Shaw

    Justin Shaw New Member

    Agreed. I used NMI for my x and y coords and FEET for alt. So a 1-1 scale would have been even more distorted. The 3D spin is a nice touch.
     
  20. jarlrmai

    jarlrmai New Member

    Is there a list of timestamped coordinates for the tracked object in this thread?
     
  21. Mick West

    Mick West Administrator Staff Member

    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.

    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: Mar 23, 2018
    • Like Like x 1
  22. Clouds Givemethewillies

    Clouds Givemethewillies Active Member

    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.
     
  23. Mick West

    Mick West Administrator Staff Member

    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.

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

    The image includes drop lines from the start and ends of the paths to show the height above the ground.
     
    • Like Like x 1
  24. Mick West

    Mick West Administrator Staff Member

    Code attached
     

    Attached Files:

  25. Justin Shaw

    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: Mar 23, 2018
    • Useful Useful x 1
  26. Mick West

    Mick West Administrator Staff Member

    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.
     
  27. Getoffthisplanet

    Getoffthisplanet New 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?

    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: Mar 23, 2018
  28. Mick West

    Mick West Administrator Staff Member

    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: Mar 23, 2018
  29. Mick West

    Mick West Administrator Staff Member

    In the meantime, here's the positions that match the diagrams above.
     

    Attached Files:

  30. Getoffthisplanet

    Getoffthisplanet New Member

    Right. Just want to double check if goFastRoll.txt is the same data contained in Go Fast Tilt tracking.xlsx?

    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.
     
  31. jarlrmai

    jarlrmai New 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.
     
  32. Mick West

    Mick West Administrator Staff Member

    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.
     

    Attached Files:

  33. jarlrmai

    jarlrmai New Member

    You need to interpolate or 'lerp' as it is known for smooth transition between your cartesians.
     
  34. Mick West

    Mick West Administrator Staff Member

    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.
     
  35. Getoffthisplanet

    Getoffthisplanet New Member

    Nailed it:

    [​IMG]

    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?
     
  36. Mick West

    Mick West Administrator Staff Member

    Oops. My eyes are getting old.

    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
    
    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.
     
  37. Getoffthisplanet

    Getoffthisplanet New Member

    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?

    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.
     
  38. igoddard

    igoddard Active Member

    As well its path appears to be a straight line when the footage is stabilized to the ocean:

    [​IMG]

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

    [​IMG]

    From the blog of a high-altitude balloon business.

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

    Mick West Administrator Staff Member

    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.

    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.
     

    Attached Files:

  40. Mick West

    Mick West Administrator Staff Member

    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.
     
    • Agree Agree x 1