GoFast : is the background moving relatively to the movement of the jet ? Or the camera only ?

[dimebag2]

Something does not make sense to me in the GoFast video. I apologize in advance if I'm missing something obvious.

First observation, the camera angle is tilted to the left of the jet direction, so in the video the jet direction is from the bottom left to upper right of the screen, isn't it ?

But then the background should move from the top right to bottom left (opposite to the jet direction), and this is the opposite. At the beginning of the video, we see the camera is fixed on one area over the ocean, and the background does not move. Does this mean that the plane movement does not affect the camera angle, because it's zoomed a lot, or operated manually ? The background only moves when the camera locks on the GoFast, and it moves from bottom left to top right as expected because the camera is now fixed on the GoFast object (that goes opposite to the jet direction).

To me this means the angles of the IR camera are relative to the GoFast movement only (i.e., the plane movement does not affect them, consistent with the fact that at the beginning, the image is still). I tried to compute the speed of the object based on GoFast trajectory only, not using the plane speed (it's a fixed point here), and on a plan including Gofast and the camera (not accounting for its tilt downwards). The speed I get is much faster than what has is found when the plane movement is considered to explain the changes in camera angle. I find 270 Mph, or 433 km/h as a speed to cover the distance done by GoFast in the 20 sec that separate my 3 points. This is based on the displayed distances RNG, considering it's a valid measurement (I know it's debated).

That would make the Gofast not so close to the ocean (due to the range being fairly short), but still a great speed object. Am I completely off here ? Am I correct in assuming the plane movement does not affect the camera angles, or else we would see them change before it's locking on GoFast ?

Here is a schematic of how I see it :

 

[jarlrmai]

https://forums.vrsimulations.com/su...ard_Looking_Infrared_(FLIR)#Inertial_LOS_Mode

When the FLIR is in the Inertial LOS Mode, the MC maintains the FLIR LOS at a constant pointing angle with respect to the inertial reference plane. TDC slewing with TDC priority to the FLIR causes the FLIR LOS to be slewed accordingly. The Inertial LOS pointing mode may also commanded via the Az/Ez format (FLIR as the selected sensor), by depressing the TDC ENT in open space to invoke the scan centering cross, followed by a second depression to select the LOS.

 

[dimebag2]

Thanks ! This is pretty technical with all these acronyms. To put that in context with my more general question, does that mean that the camera movement during the tracking of GoFast is only due to the movement of GoFast ?

 

[jarlrmai]

When not tracking the system keeps the camera pointing relative to the jet, once the object is being tracked the pod gimbal starts moving to keep the object central to the camera system and the jet.

So if the jet is moving and the object isn't the camera has to move and vice versa, if the object and jet were both moving in the same direction at the same speed then the pod wouldn't have to move.

Imagine you are in the passenger seat of the car with some binoculars and you are driving past a parked car what would you need to do with your head/neck etc to keep looking at the car?

 

[dimebag2]

Got it, thanks ! This is simply parallax, I was confused by the beginning of the video. I'm catching up on this !
There must a way to estimate the distance between the object and the background, from how fast it moves away from the screen ? Maybe it's been done before ? That would allow to verify if the RNG is correct ? Something I'm wondering is how do we know if GoFast is going in the same, or opposite, direction than the jet ? Both would lead to parallax, but I suppose it would be greater with GoFast going "towards" the jet.

 

[Edward Current]

Got it, thanks ! This is simply parallax, I was confused by the beginning of the video. I'm catching up on this !
There must a way to estimate the distance between the object and the background, from how fast it moves away from the screen ? Maybe it's been done before ? That would allow to verify if the RNG is correct ? Something I'm wondering is how do we know if GoFast is going in the same, or opposite, direction than the jet ? Both would lead to parallax, but I suppose it would be greater with GoFast going "towards" the jet.

Hi Dimebag2, I created a Blender model of the scenario to investigate these questions and posted about it here the other day. I am still refining the findings and will upload a proper YouTube video when I've completed the analysis.

 

[dimebag2]

Hi Dimebag2, I created a Blender model of the scenario to investigate these questions and posted about it here the other day. I am still refining the findings and will upload a proper YouTube video when I've completed the analysis.

Awesome, I'll check that out when I have a moment, thanks !

 

[Edward Current]

Got it, thanks ! This is simply parallax, I was confused by the beginning of the video. I'm catching up on this !
There must a way to estimate the distance between the object and the background, from how fast it moves away from the screen ? Maybe it's been done before ? That would allow to verify if the RNG is correct ? Something I'm wondering is how do we know if GoFast is going in the same, or opposite, direction than the jet ? Both would lead to parallax, but I suppose it would be greater with GoFast going "towards" the jet.

Here's the link to my full video (contents: backstory, clips of Chris Lehto responding to Mick, a look at the onscreen data, Blender model showing animation of sightline and simulation of camera view, size estimate of object ~2 feet)

 

[dimebag2]

Edwards, that's a cool video, but I'm not sure I understand how you get your numbers. I get pretty much the same pivot point as you (around 12000 ft), but modeling the whole thing in 3D, I do not retrieve the same results.

Here is my 3D model for GoFast : https://www.geogebra.org/3d/javwynek

I try to model the event between the beginning of locking on GoFast (0'11 mark in the video) and 20' later at 0'31. The plane trajectory is at 25000 ft (4.1 Nm), I reconstructed it from a 2D analysis, taking into account the changes in bank angles. It is very consistent with what I have seen from Mick, and in Edward's video above. The plane slightly turn to the left. Uncertainties in the plane trajectory should not affect the results here, I've played with it and moving PT2 a little bit does not change the results too much.

I then create the two lines of position for GoFast, at Point 1 and Point2, based on the azimuth and vertical angles of the camera (43/26, 56/34). I make the assumption that GoFast stays at the same altitude, and we can estimate all the potential trajectories at different altitudes by moving point that marks the position 1 of GoFast (GF1). The corresponding distance between GF1 and GF2 is given, and we can deduce its speed (it's one variable on the left side).

The problem I have is I cannot retrieve the RNG indicated at point 1 and 2. If I choose the trajectory based on RNG2 (3.5), the altitude is 2.2 Nm, or ~13000 ft, but then RNG1 is too high compared to the video (5.3 instead of 4.4). This corresponds to a speed of 136 knots, i.e. 250 km/h, which seems too high for a balloon caught in the wind. That would be a hell of a speed for a bird too ! The minimum speed based on the two lines of position is 230 knots, at 2.5Nm. Any significantly closer or more distant range makes the speed increases a lot. The maximum being 575 knots, or ~1000km/h, if the object was right above the ocean.

It seems to support the idea the the RNG are not reliable here (what Chris Lehto claims in his video). Another argument in his favor : when between the plane and the ocean, the velocity vector of GoFast is not aligned with the line of ocean that the camera scans through the video (blue line at the surface in my schematic). In other words there should be some sort of change in the orientation of the background (like clearly seen in Mick's parallax video).

The only position when the velocity vector aligns with the line of "scanned" background is fairly close to the ocean, around 0.8Nm (1500m), which corresponds to a speed of 740 km/h.

I'll be interested in hearing what you think, and where I may be wrong here. I don't buy the party balloon theory, Navy and DoD employees are not stupid, and I think this analysis shows it's not as easy as it looks.

 

[Mick West]

I'll be interested in hearing what you think, and where I may be wrong here.

I think you're probably reading too much into two data points.

I think interactive 3D recreations are the way to go here. Last year I did one in Unity that matched up with ranges, angles, and the motion of the ocean. I lost interest, but now with a variety of objections being raised (and Unity available for Apple Silicon), I'll maybe try rebooting it and incorporating tracked bank angles.

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.

@BenJ also did one, and made a detailed video about it
Source: https://www.youtube.com/watch?v=FlJvyewbfpA

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.

Wind was important.

 

[Mick West]

This is what I have so far. The angles and Range display are all emergent from the sim.

I forget exactly how it's set up, but it currently has a constant turn rate. Target object is a cube, moving in a straight line.

 

[dimebag2]

Thanks Mick, those simulations are interesting. Indeed the wind may affect the plane trajectory (if it affects the balloon it's included in the trajectory scanned by the camera). It would have to have quite a large effect though, because I did not find big changes in the results when applying reasonable changes to the plane trajectory.

What would be the size of the object in your simulation ? Something I notice in both simulations is that the background speed of the ocean moves significantly slower that in the original video.

 

[Mick West]

What would be the size of the object in your simulation ? Something I notice in both simulations is that the background speed of the ocean moves significantly slower that in the original video.

It's a 1m cube. So about 3 feet.

 

[MclachlanM]

Something I notice in both simulations is that the background speed of the ocean moves significantly slower that in the original video.

If the ocean surface itself was moving, would that be amplified by parallax? The go fast video was taken off the coast of Florida and the Gulf Stream could be what's causing this

From https://oceancurrents.rsmas.miami.edu/atlantic/gulf-stream_2.html
Although this is only 100cm/s [2 knots] at the most.

 

[JMartJr]

If the ocean surface itself was moving, would that be amplified by parallax? The go fast video was taken off the coast of Florida and the Gulf Stream could be what's causing this

I'd suspect you'd be seeing the "movement' of the waves propagating through the water, rather than the movement of the current.

 

[MclachlanM]

I'd suspect you'd be seeing the "movement' of the waves propagating through the water, rather than the movement of the current.

Source: https://youtu.be/p4pWafuvdrY?t=89


The entire top layer of water is sitting on the 'conveyer belt' of the gulf stream. So the waves and even a stationary buoy on the surface would be moving at 2knots, then amplified by parallax and account for the disparity between the simulation and video?

 

[Derick]

The entire top layer of water is sitting on the 'conveyer belt' of the gulf stream. So the waves and even a stationary buoy on the surface would be moving at 2knots,

Well the waves moving would be much faster compared to the actual water current, which given water has no texture is what we would be tracking. And that is caused by wind generally.

Also, if you decide to invent a wind to make the sim closer to reality, whatever direction you push the jet would create wind waves in the same direction at the surface (wind should be roughly same direction, just a lot slower), partly canceling out - but only partly. Anyway I'm no wave expert.

If the ocean surface itself was moving, would that be amplified by parallax?

Not entirely sure what you mean here but I'm going to say no. The thing that really amplifies the speed of the ocean in the sim would be if the turn radius is slightly wrong for whatever reason.

 

[dimebag2]

After correcting my vertical camera angles, the RNG are consistent with the camera angles at Point 1 and 2, and I retrieve your results. A speed of 60 Knots at ~12000 ft. https://www.geogebra.org/3d/javwynek
This all makes sense now. Sorry for the wrong analysis above !

 

[MclachlanM]

Well the waves moving would be much faster compared to the actual water current, which given water has no texture is what we would be tracking. And that is caused by wind generally.

Also, if you decide to invent a wind to make the sim closer to reality, whatever direction you push the jet would create wind waves in the same direction at the surface (wind should be roughly same direction, just a lot slower), partly canceling out - but only partly. Anyway I'm no wave expert.


Not entirely sure what you mean here but I'm going to say no. The thing that really amplifies the speed of the ocean in the sim would be if the turn radius is slightly wrong for whatever reason.

I did a quick video to try and show what I mean:

The speeds of the bars in real life remain the same. However by exploiting the parallax illusion I can make the bars appear to speed up and slow down:

Still Camera - 1.9 bars/second
Camera moving right - 2.2 bars/second
Camera moving left - 1.4 bars/second

This is only the distance between me and my monitor and the effect of a moving background is very noticeable. At the distance in the video this effect may be much greater and even the relatively small translation of the ocean surface caused by the gulf stream would be visible compared to the stationary texture used in the simulation.

Edit:

Well the waves moving would be much faster compared to the actual water current, which given water has no texture is what we would be tracking. And that is caused by wind generally.

What you would see on the surface of the water over a strong current would be the velocity of the wave +/- the velocity of the current underneath.
Think of it like looking down from a bridge and seeing someone walking on a boat (person = waves, boat = current). If there was an object between them with parallax you must take into account when measuring the velocity of the person that the person isn't necessarily stationary and that the what the person standing on isn't necessarily stationary either, which would greatly effect the appearance of the simulation in this scenario.

 

[Derick]

The speeds of the bars in real life remain the same. However by exploiting the parallax illusion I can make the bars appear to speed up and slow down:

Still Camera - 1.9 bars/second
Camera moving right - 2.2 bars/second
Camera moving left - 1.4 bars/second

This is only the distance between me and my monitor and the effect of a moving background is very noticeable. At the distance in the video this effect may be much greater and even the relatively small translation of the ocean surface caused by the gulf stream would be visible compared to the stationary texture used in the simulation.

Sure but what you are doing here is the equivalent of adjusting the turn rate of the aircraft, which as I stated would in fact amplify the ocean speed significantly in how fast it moves though the camera FOV.

But the motion of the waves is a static amount added on to the speed that the ocean appears to be going past the FOV, not something amplified by parallax.

Like there should be an equivalent difference in how many bars pass regardless of background bar speed. So something like -3 bars to +3 bars (moving cam left/right) with no movement of bars, or 7 bars and 13 bars (moving cam left/right) with high (10bar/s) movement. The difference is not amplified.

Hopefully we aren't talking past each other.

 

[MclachlanM]

Sure but what you are doing here is the equivalent of adjusting the turn rate of the aircraft, which as I stated would in fact amplify the ocean speed significantly in how fast it moves though the camera FOV.

But the motion of the waves is a static amount added on to the speed that the ocean appears to be going past the FOV, not something amplified by parallax.

Like there should be an equivalent difference in how many bars pass regardless of background bar speed. So something like -3 bars to +3 bars (moving cam left/right) with no movement of bars, or 7 bars and 13 bars (moving cam left/right) with high (10bar/s) movement. The difference is not amplified.

Hopefully we aren't talking past each other.

Yeah, I'm not sure where I am going with that video aha. It does show that if the motion of the ocean current is moving in the opposite direction of the camera, then the ocean current would appear faster in parallax than it would if the camera were stationary. And that if you were to compare it with a stationary ocean in parallax, they would be different speeds (that's pretty obvious without my video).

On re-watching the footage it is clear that the ocean surface is travelling at a considerable speed by itself. There are a couple of moments where the WSO stops slewing the ATFLIR pod for brief periods of time.
The ATFLIR pod is designed to keep looking at the same point in space when the operator is trying to lock a target, otherwise it would be impossible to target anything as the jet is moving at hundreds of knots. Therefore in these brief periods where the camera is fixed on the angle it was left on (not changed by the velocity or axis rotation of the jet) we would be able to see surface velocities.

I'm bad at explaining this so here a few example of what I mean:
Source: https://youtu.be/cA3OmVAcuE0?t=289


Source: https://youtu.be/HJRb_ofEtYQ?t=944


If I slow down one of these periods where the WSO is not slewing and the camera is holding still (around 2 seconds in) to 0.1x speed we can see that the ocean surface is moving at a fair speed already.

Not sure if we have the FOV numbers for this zoom but we should be able to get an estimate for the speed of the surface, modify the visualisation with this and the backgrounds should then match.

 

[Mick West]

After correcting my vertical camera angles, the RNG are consistent with the camera angles at Point 1 and 2, and I retrieve your results. A speed of 60 Knots at ~12000 ft. https://www.geogebra.org/3d/javwynek
This all makes sense now. Sorry for the wrong analysis above !

So, you're now saying you think the original analysis was correct all along? It's high and slow?

 

[Derick]

I don't know much about the targeting system to be honest.

So the jet is trying to keep the cameras pointing at a point on the surface, but how does it actually do this?
if it is just counteracting the true airspeed and the turning off the jet itself then the apparent movement of the water in that clip could actually be movement of the jet itself that is unaccounted for (because of wind which the jet wouldn't have a great way of determining). It can't just be feature tracking the ground to get lock because then it would stick with the waves.

Unless it is using GPS to get a true location/speed?

But then later there appears to be another similar moment after the first burst of movement except the waves are going a different way?

Not sure if we have the FOV numbers for this zoom but we should be able to get an estimate for the speed of the surface, modify the visualisation with this and the backgrounds should then match.

Height is 25000feet camera angle down 23
should be about 58000 feet away horizontally in short clip you linked so raw distance is
64000 feet away. If the FOV is 0.7(that's what others seem to be using?) left/right then I think the distance left to right is 782 feet in clip you linked.
And 1845 feet bottom to top.
Probably screwed something up but not sure it's worth calculating anyway unless we sure on that FOV.

 

[dimebag2]

So, you're now saying you think the original analysis was correct all along? It's high and slow?

Yes Mick, this is exactly what I find. Here is an upgraded version of my 3D model : https://www.geogebra.org/3d/axynssmq

It gives the speed of GoFast (in knots) in function of all the potential trajectories based on the camera angle (assuming same altitude). I have also added a measurement of the closing velocity, Vc, because it is another parameter given on the F-18 screen. I use this formula :
with v1, v2, p1 and p2 the velocity and position vectors of the plane and GoFast​

At an altitude of 2.1 Nm (12000 ft), all the number in my model match what is seen on the screen in the video (I look at Point 1, 0'11, and Point2, 0'31):

- the RNG is 4.4 Nm at PT1, 3.5Nm, at PT2
- the closing velocity is 200knots at PT1, 150knots at PT2 (in the video Vc is 210, then 160, so I'm very close)
-the speed of GoFast is ~57 knots, i.e. 65Mph

And this is consistent with the object being white (i.e. cold).

Let's assume for some reason the instruments underestimated the range (which would affect Vc too), the maximum speed near the surface would be 295knots, i.e. 350 Mph.

We really need to understand how they concluded it was a fast object close to the ocean, because that's clearly not what the numbers say. Hope it brings something interesting to the table.

 

[jarlrmai]

Yes Mick, this is exactly what I find. Here is an upgraded version of my 3D model : https://www.geogebra.org/3d/axynssmq

It gives the speed of GoFast (in knots) in function of all the potential trajectories based on the camera angle (assuming same altitude). I have also added a measurement of the closing velocity, Vc, because it is another parameter given on the F-18 screen. I use this formula :
with v1, v2, p1 and p2 the velocity and position vectors of the plane and GoFast​

At an altitude of 2.1 Nm (12000 ft), all the number in my model match what is seen on the screen in the video (I look at Point 1, 0'11, and Point2, 0'31):

- the RNG is 4.4 Nm at PT1, 3.5Nm, at PT2
- the closing velocity is 200knots at PT1, 150knots at PT2 (in the video Vc is 210, then 160, so I'm very close)
-the speed of GoFast is ~57 knots, i.e. 65Mph

And this is consistent with the object being white (i.e. cold).

Let's assume for some reason the instruments underestimated the range (which would affect Vc too), the maximum speed near the surface would be 295knots, i.e. 350 Mph.

We really need to understand how they concluded it was a fast object close to the ocean, because that's clearly not what the numbers say. Hope it brings something interesting to the table.

It's great that you were able to work through this yourself and confirm what was discovered here a few years back when we 1st got Go Fast and the TTSA analysis.

 

[MclachlanM]

If I slow down one of these periods where the WSO is not slewing and the camera is holding still (around 2 seconds in) to 0.1x speed we can see that the ocean surface is moving at a fair speed already.

I'm talking rubbish here, just doing ballpark figures gives an ocean with velocity in the hundreds of knots area, much more than what we're looking for so the ATFLIR is most likely in 'snowplough mode'

A video showing what we're actually seeing here: Source: https://youtu.be/xvzxfqymFq0?t=115


If someone were particularly savvy they could find the speed we would expect stationary ground to be moving at that point given the TAS, find the actual velocity at that point, giving the speed of the sea relative to air which when added to the simulation might account for the different speeds of the ocean but it seems like overkill.

 

[jarlrmai]

I'm talking rubbish here, just doing ballpark figures gives an ocean with velocity in the hundreds of knots area, much more than what we're looking for so the ATFLIR is most likely in 'snowplough mode'

A video showing what we're actually seeing here: Source: https://youtu.be/xvzxfqymFq0?t=115


If someone were particularly savvy they could find the speed we would expect stationary ground to be moving at that point given the TAS, find the actual velocity at that point, giving the speed of the sea relative to air which when added to the simulation might account for the different speeds of the ocean but it seems like overkill.

In Go Fast the ATFLIR is in A/A mode which does not do snowplow as far as I can tell. It does

Inertial LOS, this might be the same as Snowplow mode but it's not called that in the manual.

https://forums.vrsimulations.com/su...ing_Infrared_(FLIR)#A.2FA_FLIR_Pointing_Modes

 

[Mick West]

I'm talking rubbish here, just doing ballpark figures gives an ocean with velocity in the hundreds of knots area, much more than what we're looking for so the ATFLIR is most likely in 'snowplough mode'

Can you show your math here? Snowplow mode (a fixed camera angle) would make the ocean surface move at the same apparent speed as the jet, not useful for searching.

In Go Fast the ATFLIR is in A/A mode which does not do snowplow as far as I can tell. It does

Inertial LOS, this might be the same as Snowplow mode but it's not called that in the manual.

I think it's in "Inertial LOS", which is intended to keep the Line Of Sight moving in such a way that it stays over a static target region - "a constant pointing angle with respect to the inertial reference plane." In this case it would basically be to stay on the same patch of ocean, as best it can calculate.

 

[JMartJr]

whatever direction you push the jet would create wind waves in the same direction at the surface (wind should be roughly same direction, just a lot slower), partly canceling out - but only partly. Anyway I'm no wave expert.

Nor am I, but I have some experience of dealing with wind at different altitudes -- it is not a sure bet that the wind at several hundred feet matches the wind "on the deck," much less the wind 10 or 20,000 feet up. Don't count on the wind at the plane atching the wind at the object, and don't expect either to match the wind at the surface. Oh, they MIGHT match -- strange things happen at sea -- but that's not the safe bet.

 

[MclachlanM]

Can you show your math here? Snowplow mode (a fixed camera angle) would make the ocean surface move at the same apparent speed as the jet, not useful for searching.



I think it's in "Inertial LOS", which is intended to keep the Line Of Sight moving in such a way that it stays over a static target region - "a constant pointing angle with respect to the inertial reference plane." In this case it would basically be to stay on the same patch of ocean, as best it can calculate.

Decided to try and get some footage of this stuff in DCS and am very confused now, how do we know that it is in A/A mode?

This is the snowplough in A/G mode:

The A/G in VVSLV mode (Velocity Vector Slaved): IT HAS A RANGE!! There are no objects here, just the plane and the ground, the ground radar has no locks and the laser is not on, so I have no idea what is going on here.

Whatever the A/A mode is doing (I was referring to this as snowplough but it could be called something else, it is used and behaves in a similar way though):

This is in Nav mode AND ALSO HAS A RANGE??? This isn't even a weapons mode so I don't have a clue what it thinks the target is or what it's using to find the range to it:

I'm flying over the ground so the range could be to the floor, still doesn't explain how it knows though. I was trying to get a screen looking something like the video with the Laser finder settings from NAV or A/G and the launch & steer slave option from the A/A but couldn't find it.

More to the point, if I wanted to get a difficult auto-track of a moving target over the ground like in the video I'd certainly choose the VVSLV mode as it keeps the camera still by accounting for the speed of the F-18. In this case, the ocean would be moving and my trig could do with some practice (certainly possible).

 

[jarlrmai]

The BST SLAVE and L+S options only show in A/A mode.

I understand you have the sim and are trying it out which is great but it might help if you read the manual for it because it's easy to get terms mixed up.

As far as I can determining the draw a box grab mode shown in go fast is not simulated.

Where the range comes that is shown in that video from is still a matter of debate.

The sim community don't seem to think whatever it is simulated yet.

https://forums.eagle.ru/topic/272552-atflir-laser-in-aa-mastermode/

 

[dimebag2]

It's great that you were able to work through this yourself and confirm what was discovered here a few years back when we 1st got Go Fast and the TTSA analysis.

Yeah I just went through the whole GoFast thread, that I had somewhat missed. Sorry for reinventing the wheel here.

 

[jarlrmai]

Yeah I just went through the whole GoFast thread, that I had somewhat missed. Sorry for reinventing the wheel here.

Hey no worries it's great when someone comes in and checks our working and I'm sure your learned some useful skills.

 

[MclachlanM]

The BST SLAVE and L+S options only show in A/A mode.

I understand you have the sim and are trying it out which is great but it might help if you read the manual for it because it's easy to get terms mixed up.

As far as I can determining the draw a box grab mode shown in go fast is not simulated.

Where the range comes that is shown in that video from is still a matter of debate.

The sim community don't seem to think whatever it is simulated yet.

https://forums.eagle.ru/topic/272552-atflir-laser-in-aa-mastermode/

The BST and L&S only make sense in A/A mode and only appears in the A/A mode screenshots in the manual, I completely agree.

However, I can't get my head around the LST part with PRF 1688 being shown simultaneously, this refers to the F-18 finding someone else's laser to guide a bomb in (https://en.wikipedia.org/wiki/Laser_designator), and only ever seems to make sense in A/G mode. I don't think laser guided air-to-air options exist for the F-18? This is never seen in the A/A mode screenshots in the manual so seems to be a contradiction.

I was thinking that the WSO might have more options than the single-seat version but I can't wrap my head around why they would set up either an A/A or A/G mode to show a feature that is only useful in the other mode. My theory is that the F-18s aren't in a weapons mode whilst looking at potentially civilian aircraft and are instead in NAV mode, where the WSO has set up the ATFLIR to use options from both A/A and A/G which he can use depending on what he's looking at, but this is purely speculation.

Things like the box grab mode as well might be unique to the two-seat version (is this the F/A-18F version in the videos?) and so these things aren't showing up in the F/A-18C manual. It would make sense to me that features requiring your full attention are added to two-seat versions to make use of the extra person.

 

[Mick West]

I'm flying over the ground so the range could be to the floor, still doesn't explain how it knows though. I was trying to get a screen looking something like the video with the Laser finder settings from NAV or A/G and the launch & steer slave option from the A/A but couldn't find it.

9.4 TGT - is that the same as RNG though?

You are at 25010 feet, looking down 24° below horizontal.

9.4 NM is about 57,000 feet. 25010/sin(24 degrees) is about 61500 feet.

Are you over water there?

 

[jarlrmai]

What the various modes and displays mean is mostly described in the manual I've linked a few times.

There's no doubt they are in AA mode as far as I'm concerned I'd need some sort of documentation / evidence to the contrary.

The ATFLIR SIM is very new and not full featured, the people making it have access to a lot of the same data we do, and the sim users are even using the very same videos we are discussing to determine the missing features. There even say in that thread that hiding the PRF code in AA mode might be oversight in the sim.

I feel that yeah there's probably more options available in the 2 seater WSO version or more is configurable than we know.

Most likely the range is from the RADAR and is shown because of LOS correlation with the tracks from RADAR and ATFLIR.

 

[MclachlanM]

9.4 TGT - is that the same as RNG though?

You are at 25010 feet, looking down 24° below horizontal.

9.4 NM is about 57,000 feet. 25010/sin(24 degrees) is about 61500 feet.

Are you over water there?

Over the ground, approx. this area. I was trying to get a flat area of land in the Caucasus map to see the movement as DCS wasn't really rendering the sea



Edit: Likely not caused by terrain as I get similar strange numbers over ocean:

 

[jarlrmai]

TGT is listed as slant range to target in AG mode I assume unless the laser is used for ranging this is calculated from the basic trig based on altitude above ground and downward angle of the system.

 

[MclachlanM]

Most likely the range is from the RADAR and is shown because of LOS correlation with the tracks from RADAR and ATFLIR.

I'm not so sure:

In this video I am not in A/G or A/A mode, switch the radar off, stitch the master arm switch to safe, make sure the laser is safe and still have a TGT range displayed, maybe the vague internal trig thing than CW Lemoine mentioned is what's happening?

 

[MclachlanM]

A further reason why the WSO footage might not be in A/A mode is that the manuals never show a range stated on the DDI for A/A targets, only ground targets. In A/A mode the range to a target is indicated on the HUD.