# Gimbal distance and Speed Range Estimates using Lines of Bearing and/or DCS

I believe that besides the problem of elevation (for the object to appear above the horizon the fighter would have to be at about 51,000 feet) there is also something wrong with the apparent motion of the clouds, that if it were Venus, they would have to be between the observer and the pointed object and then move to the left.

I believe that besides the problem of elevation (for the object to appear above the horizon the fighter would have to be at about 51,000 feet) there is also something wrong with the apparent motion of the clouds, that if it were Venus, they would have to be between the observer and the pointed object and then move to the left.
The object is below the jets artificial horizon (it's horizontal plane of reference), and above the visible horizon formed my the cloud top. There's nothing obstructing the view of a celestial object in this part of the sky.

I agree apparent motion of the clouds is wrong. I'm thinking the clouds are moving along with the wind from left to right passed the stationary planet. Still trying to wrap my mind around how this would work.

This is where you are making your mistake, you're getting both the turn of the aircraft and the turn of ATFLIR from the angle of the targeting pod.

By assuming that the turn rate of the aircraft is the same as the turn rate of the targeting pod you are assuming that the aircraft is moving forward and turning, then the targeting pod is turning in the opposite direction therefore looking at the same bearing it was before. You don't need a CAD model to tell you that this is always going to end up with parallel lines.

The good work you have done with interpolating the displayed angle with frames is being let down by your inaccurate calculation of turn rate, here is what you have compared to the youtube analysis and my recreation in DCS:

Consider that my recreation in DCS is consistent with an aircraft only 15nmi away and you see how accurate you need to be.

Couple all this with the fact the object clearly gets bigger over time, it was the middle of the day, it's unclear if a planet would even show up on ATFLIR and the testimony about the RADAR as well as the 99.9RNG indicating jamming I think we can rule out Venus.

Last edited:
Apologies, getting that from the Tic Tac incident. Not even sure if that would matter for IR either.

Cassi O, I compared your plane trajectory with mine, they align very well. I overlay them using this online tool, the rendering is messy but we clearly see my Points 1 to 4 are on the same trajectory as yours. There is no uncertainty on the camera angles at those points (just have to read the value at 0'01, 0'11, 0'21, 0'31). So we should get similar lines of bearing. Mine are certainly not parallel. Hope it helps and we can find the discrepancy.

Cassi O, I compared your plane trajectory with mine, they align very well. I overlay them using this online tool, the rendering is messy but we clearly see my Points 1 to 4 are on the same trajectory as yours. There is no uncertainty on the camera angles at those points (just have to read the value at 0'01, 0'11, 0'21, 0'31). So we should get similar lines of bearing. Mine are certainly not parallel. Hope it helps and we can find the discrepancy.

That's really cool!

I used your GeoGebra calculator and pushed the gimbal point out to:
Gimbal=(-1000000,742000)

This matched my angles from the video for PT1 and 2, but not 3 & 4.
(My angles: 53.452L, 38.780L, 21.116L, 0.5R)

Looks like the difference is your curve bends a bit more than mine.

Thanks for the graph Cassi O, it's very useful. That makes sense, small differences in trajectory have large impacts on the lines of bearing. I checked, I can reproduce your parallel lines of bearing with a RoT a PT2 of 1.7, and a RoT at PT3 of 1.9. My problem is these RoT are too small compared to the bank angles from the video.

My model uses three RoT :
- RoT1=1.5°/sec from PT1 to PT2 (0'01 to 0'11) -> this does not look too off compared to the numbers from the graph below. And this portion of the trajectory is in good agreement with your results anyway.
- RoT2=2°/sec from PT2 to PT3 (0'11 to 0'21). That's where our trajectories start to diverge. With a RoT of 1.7°/sec I find a parallel line of bearing at PT3 like you, but the RoT2 is clearly more around 2°/sec at his point of the video (see graph below).
- RoT3=2.3°/sec from PT3 to PT4 (0'21 to 0'31). Here I would need a RoT of 1.9°/sec to get a parallel line of bearing at PT4, while in the video the RoT3 is clearly larger, around at least 2.3°/sec (graph below)

Let me know what you think.

Cassi O, I compared your plane trajectory with mine, they align very well. I overlay them using this online tool, the rendering is messy but we clearly see my Points 1 to 4 are on the same trajectory as yours. There is no uncertainty on the camera angles at those points (just have to read the value at 0'01, 0'11, 0'21, 0'31). So we should get similar lines of bearing. Mine are certainly not parallel. Hope it helps and we can find the discrepancy.
You made the same mistake I did, which is to assume that just plucking a bearing number from the display at some point in the video would be accurate enough. But the lines of bearing are so close to parallel that being one degree or two off really does matter and can throw everything off. That way only works if you're fortuitous (or deliberate) in picking the times, which neither of us were. In #117 I described one approach to dealing with this, in which I measured the indicated azimuth for every frame and used Gaussian smoothing to estimate the unrounded azimuth. Once you do that you see there's a huge range of possible locations for the object, and that's discounting possible wind shear.

It might be possible to make this consistent with Venus but you'd also have to take the overall wind and rotation of the Earth into account.

It might be possible to make this consistent with Venus but you'd also have to take the overall wind and rotation of the Earth into account.
Does anyone know the approximate date (and time) of the video?
It would be better to check Venus position before going into so much trouble.

You made the same mistake I did, which is to assume that just plucking a bearing number from the display at some point in the video would be accurate enough. But the lines of bearing are so close to parallel that being one degree or two off really does matter and can throw everything off. That way only works if you're fortuitous (or deliberate) in picking the times, which neither of us were. In #117 I described one approach to dealing with this, in which I measured the indicated azimuth for every frame and used Gaussian smoothing to estimate the unrounded azimuth. Once you do that you see there's a huge range of possible locations for the object, and that's discounting possible wind shear.

It might be possible to make this consistent with Venus but you'd also have to take the overall wind and rotation of the Earth into account.

I looked at your previous posts, first you found similar lines of bearing than me (#100). But it seems you have a pre-assumption that these lines should be parallel, and the object being distant, so you discard it as being erroneous, while a close trajectory in fact matches your data.

You get parallel lines with smoothing of the azimuthal angles (#117), but why would you do that ? What matters to retrieve Gimbal trajectory is the instantaneous angle at a certain position of the plane no ?

I think what's key is the lines of bearing between PT2 and PT3. After they cross, Gimbal has to change direction to match the trajectory, and that makes the trajectory unlikely for a regular plane or fighter (except going very fast, or having dramatic rate of turns). There are uncertainties on these lines of bearing, but I don't think they are so high that we cannot say anything about the object position.

I looked at your previous posts, first you found similar lines of bearing than me (#100). But it seems you have a pre-assumption that these lines should be parallel, and the object being distant, so you discard it as being erroneous, while a close trajectory in fact matches your data.
I didn't discard the conclusion because it gave a small distance for the intersection point. I discarded it because it couldn't be made consistent with a steadily moving object at _any_ distance.
You get parallel lines with smoothing of the azimuthal angles (#117), but why would you do that ? What matters to retrieve Gimbal trajectory is the instantaneous angle at a certain position of the plane no ?
Yes but not just any position. This is because the indicated azimuth angle is not the raw angle the sensor is actually pointing to, but rather a value rounded to the nearest whole degree. That means that whenever the display indicates 15 degrees, the angle could really be anywhere between 14.5 and 16.5 degrees -- a range almost 3 full fields of view wide! I erroneously assumed this didn't matter too much, but it does. With the smoothing, we get a reasonable (if heuristic) estimate of the 'unrounded' azimuth, which is really what we want here.

If you're doubtful that the smoothing makes sense, here's a simple way to check that it does: find the frames at which the smoothed and indicated angles exactly agree, and plot the bearing lines for those frames. The conclusion you'll get should be qualitatively similar to what I have in #117. Because of the smoothing, it really doesn't seem to matter much which line of bearing you plot -- they all converge more or less in the same area, which is very much not the case if you use the rounded numbers.
There are uncertainties on these lines of bearing, but I don't think they are so high that we cannot say anything about the object position.
You can draw the lines of bearing reasonably well if you're careful in picking the frames (as I describe above), but that results in a huge range of plausible positions, which only gets larger if one takes into account wind shear or possible differences in true airspeed.

Yes I'd like to try that. Could you give me the values of the azimuthal angles you get in your Matlab code after smoothing ?
What you get in those lines at 1, 11, 21, 31. This way I can compare with the exact same azimuth angles you have. Thanks for sharing your code !

poly_fit_az = np.polyval(np.polyfit(azdf["time"], np.array(azdf["azimuth"]), 8), azdf["time"])
smoothed_az = scipy.ndimage.gaussian_filter1d(np.array(np.array(azdf["azimuth"]), dtype=np.float64), 20.0, mode='nearest')

azimuths = scipy.interpolate.interp1d(
azdf["time"], smoothed_az,
fill_value="extrapolate", kind=interpolation)

azimuth = {t: azimuths(t) for t in [1, 11, 21, 31]}

There is no uncertainty on the camera angles at those points

There is no uncertainty on the camera angles at those points
I agree with FatPhil that this is an unjustified assumption. First, the angle is changing so rapidly in Gimbal (compared to GoFast for example), that even assuming the angle is correct within one frame leaves an uncertainty of 5–10%. Second, I suspect that the angle indicator reflects the angle of the outer gimbal only. There is an inner stabilizing gimbal whose exact position (which is also the exact position of the camera) may not be reflected in the angle indicator. This becomes especially apparent around the 0° point, where the stabilizing gimbal is working especially hard.

Using those numbers to calculate sightlines out 40NM is probably expecting far more precision than the angle indicator can deliver.

Well what I meant is that we have the readings directly on the screen, i.e. it's not retrieved indirectly from something else. Of course there must be uncertainties due to instrument, but who knows what they are. I assume there are not huge because we are dealing with high military tech. But I don't know anything about those systems of course. Just looking at the maths to see what we can infer from them. If we cannot trust any data and everything is so uncertain we may as well give up and say there is now way to tell if it's a distant or fairly close object. I'm not there yet.

I didn't discard the conclusion because it gave a small distance for the intersection point. I discarded it because it couldn't be made consistent with a steadily moving object at _any_ distance.

Why would the object have to move steadily. In his statement Ryan Graves mentions the objects stops towards the end of the video (when it supposedly rotates). His words : "Meanwhile, the ‘Gimbal’ object that was following behind them suddenly stopped and waited for the wedge formation to pass. Then it tilted up like you can see in the clip, and that’s when my video cut out, but it just kept following the other five or six, doing like a racetrack pattern,” Graves stated, explaining what isn’t shown on the public “Gimbal” video."

I don't discard that data as long as there is no evidence of why he would lie. These elements make sense with convergence of the final lines of bearing, but not with the first ones. In my model this is consistent with a fairly straight trajectory at close distance (5-15 Nm).
https://www.geogebra.org/classic/vb5qg3vf

Small changes in the angles make a difference, but not dramatics enough to completely overturn the results.

Quick complement on my previous comment : adding a 5th point in the model (considering the trajectory for the last 4 seconds, 0'31 to 0'34, and an azimuth of R7°), its line of bearing (green dotted line) is very close to the line of bearing of point 4 (pink dotted line), consistent with the object having stopped. I know this is irreconcilable with a jet, but if we trust them the numbers totally align with the pilot testimony. What it could be in the range of conventional explanations I don't know, I'm just trying to objectively look at the maths with the numbers we have.

Last edited:
Yes I'd like to try that. Could you give me the values of the azimuthal angles you get in your Matlab code after smoothing ?
What you get in those lines at 1, 11, 21, 31. This way I can compare with the exact same azimuth angles you have. Thanks for sharing your code !
I'm attaching the csv with smoothed and unsmoothed azimuth angles for all frames.

I also made a comparison of what happens if you pick times carefully vs not carefully, with and without interpolation. Here's what the bearing lines look like:

The the "haphazardly picked times" were [1, 11, 21, 31], whereas the "carefully picked times" were [1.63496830163496, 10.5438772105438, 21.2212212212212, 31.5648982315649]. With carefully picked times, interpolated and non-interpolated clearly agree, and interpolated with haphazardly picked times gives slightly different bearing lines but which still intersect in the same area. The non-interpolated, haphazardly picked times is clearly the odd one out and the only one that demands a trajectory that's difficult to explain.

In other words, a steadily moving object is consistent with this provided the error bars for the azimuths are taken correctly into account.

#### Attachments

• smoothed_azs.csv
45 KB · Views: 192
There's another dimension that doesn't fit the F/A-18 closing in on a close object.

With the F/A-18 at 25,000', and starting with the object 6.41 miles away centered in the FoV with a -2° tilt.:

http://walter.bislins.ch/bloge/inde...23432-1~0.0065-12-1376.01556-1~34.53-81-1~2-8

The target appears well below the visible horizon at 4.05 miles away, and the pod needs to tilt -3.1° to keep object centered in the FoV:

http://walter.bislins.ch/bloge/inde...432-1~0.0065-12-1376.01556-1~34.53-81-1~3.1-8

In the video, the tilt stays at -2°, and the object is always above the cloud tops.

Last edited:
Thanks marcus, very helpful. I made a new version of my model with the "carefully picked times", using the corresponding average rate of turn and time of flight between them (taken from your data, #117) to retrieve the plane trajectory, and matching the refined camera angles you have. The small differences add up and change the lines of bearing a bit, but it does not change the conclusions.

Here are the new lines of bearing I get :

Not exactly like yours, but close enough. The problem here for the distant object hypothesis is that beyond 25 Nm (x=-20), its positions at PT3 and PT4 start to diverge from its positions at PT1 and PT2. It's not as pronounced in your case but we see it's starting to happen too around x=-30. A jet cannot be at PT1 and 2 and jump suddenly at PT3 and 4.

Updated model using ths refined data is here : https://www.geogebra.org/classic/p4zhvaaf

Without interpolation (my previous model) :

Here the main result is the same, with things getting worse even quicker. It mostly comes from different rate of turns, I have them a bit larger than yours (I have 1.5/2/2.3 for RoT1/2/3, you have 1.55/1.88/2.16). As soon as the blue line starts being above the others, that means Gimbal would have to make a sharp turn to catch up with the orange and pink line. And very quickly this makes for a long trajectory, i.e. unrealistic speed for a plane.

The only plausible trajectories are comprised between 5 Nm (or even lower ?) and 30 Nm. From my lines of bearing, I would say maximum, 10 Nm. From your lines of bearing, we could extend to 30 Nm, but that would mean a non-moving or very slow object (i.e. not a plane). No trajectory from our lines of bearing supports the plane hypothesis. If too far the trajectory becomes chaotic, if too close the slowdown of the object is not compatible with a plane.

Let me know what you think. Could you develop on this : "a steadily moving object is consistent with this provided the error bars for the azimuths are taken correctly into account" ? What trajectory do you have in mind that supports this statement ?

Last edited:
There's another dimension that doesn't fit the F/A-18 closing in on a close object.

Not sure I follow your argument, sorry if I miss something. From this calculator, a object at 8 Nm could be seen with an angle of -1.6°, and supposing it stays at the same altitude, be seen with an angle of -2.3°after the distance being reduced to 5.5 Nm. Both measurements would be rounded to -2°on the screen. A distance going from 8 Nm to 5.5 Nm is a plausible trajectory of a close object in my model.

But that's interesting because it gives a lower bound for the range (didn't think about that). With the object going in a straight line more or less perpendicular to the lines of bearing, less than 5 Nm is ruled out.

Last edited:
Looking at the video, when locked on the target, the system keeps the target dead center in the FoV. With both fighter and object maintaining a constant altitude, the angle down will increase as the fighter closes in.

Also closing in on the object, the line of sight changes, so it goes from appearing above the visible horizon to below the horizon. This did not happen in the video.

Last edited:
adding a 5th point in the model (considering the trajectory for the last 4 seconds, 0'31 to 0'34, and an azimuth of R7°), its line of bearing (green dotted line) is very close to the line of bearing of point 4 (pink dotted line), consistent with the object having stopped. I know this is irreconcilable with a jet, but if we trust them the numbers totally align with the pilot testimony. What it could be in the range of conventional explanations I don't know, I'm just trying to objectively look at the maths with the numbers we have.
We don't have any pilot testimony to align the numbers with. Considering how inaccurate these calculations have been so far I think you're being far too quick to rule out a jet.

I'd be interested in what the same analysis could figure out from the DCS run I did as the numbers from the targeting pod are so similar, are you suggesting that the fractional differences between these two videos are the difference between a conventional jet flying straight and level as shown and something irreconcilable with a jet?

We don't have any pilot testimony to align the numbers with. Considering how inaccurate these calculations have been so far I think you're being far too quick to rule out a jet.

I'd be interested in what the same analysis could figure out from the DCS run I did as the numbers from the targeting pod are so similar, are you suggesting that the fractional differences between these two videos are the difference between a conventional jet flying straight and level as shown and something irreconcilable with a jet?
Excellent work! Is it possible adding a 120KTS headwind to the object to the Scenario?

Yes that's an awesome way to look at it. What's the blue line, it represents the rate of turn right ? Are your bearing angles calculated from that line, or the purple one ? A trajectory not too far from this could be found in my model, or the one of Marcus, around 12Nm, but Gimbal would have to turn. It's hard to find any rectilign and steady trajectory that would match our lines of bearing. I'll look into this further when I have more time, I really want to understand what is different between our two models.

If your calculation is right and this is a possible trajectory, it's still only 12 Nm away. Shouldn't we be able to see more of a plane signature, especially because the angle of sight changes and we see it from the bottom side at the end ?

I'd be interested in what the same analysis could figure out from the DCS run I did as the numbers from the targeting pod are so similar, are you suggesting that the fractional differences between these two videos are the difference between a conventional jet flying straight and level as shown and something irreconcilable with a jet?
Wait, do you use True Air Speed (~360 knots) or the calibrated air speed given on the screen? We have to use True Air Speed here.

Is it possible adding a 120KTS headwind to the object to the Scenario?
I could but it would be applied to both planes the same so there wouldn't be much point (think of the wind like a conveyer belt, all that matters is the velocities/flightpaths relative to each other). What would change things is wind shear (i.e. different wind conditions for each plane) although I'm not sure how I would do this in DCS.

What's the blue line, it represents the rate of turn right ? Are your bearing angles calculated from that line, or the purple one ?
I don't know what the blue line is for, the dotted purple line is where the nose is pointing and the solid purple line is the flightpath.

Wait, do you use True Air Speed (~360 knots) or the calibrated air speed given on the screen? We have to use True Air Speed here.
The original video and recreation are both 240 IAS.

If you're going to give it a go then you probably shouldn't trust the numbers from Tacview, instead use the numbers that DCS gives:

Quick guide to the numbers that are important:

If your calculation is right and this is a possible trajectory, it's still only 12 Nm away. Shouldn't we be able to see more of a plane signature, especially because the angle of sight changes and we see it from the bottom side at the end ?
I got a plane doing the same thing at 15nm to work as well (https://www.metabunk.org/threads/gi...f-bearing-and-or-dcs.11836/page-3#post-251528), the limiting factor I found wasn't the validity of the flight path but my ability to use the ATFLIR. 12nmi is still very far away, as you can see an F-18 appears as a non-distinct blob, smaller than the object in the Navy video, more than possible for it to be obscured by glare (we're waiting for a big update to the infrared simulation in DCS).

I'll look into this further when I have more time, I really want to understand what is different between our two models.
Me too, I worry that it's just because the information we're given in the video is not accurate enough to pin down the location of the other object.

I could but it would be applied to both planes the same so there wouldn't be much point (think of the wind like a conveyer belt, all that matters is the velocities/flightpaths relative to each other). What would change things is wind shear (i.e. different wind conditions for each plane) although I'm not sure how I would do this in DCS.
Thank you my friend. Actually I needed to understand the steering cue dot behavior. As you can see its shifting does not coincide with the original video.

Thank you my friend. Actually I needed to understand the steering cue dot behavior. As you can see its shifting does not coincide with the original video.
This bit?

It's good to remember that DCS don't have access to the real classified ATFLIR stuff so what we're seeing is just the Eagle Dynamics team's best guess. I had a hunch that since there are also a number of other pods in DCS that the code for the position of the relative direction dot might just be copied from one to another and not necessarily accurate for each pod, I think this is probably the reason it is off from the original video.

The AN/AAQ-28(V) LITENING II and AN/ASQ -228 ATFLIR in the same situation overlaid so you can see that the relative direction dot for the ATFLIR is probably copied from the LITENING pod (as well as a lot of the other UI):

#### Attachments

• 1626644369414.png
212.5 KB · Views: 184
It's good to remember that DCS don't have access to the real classified ATFLIR stuff so what we're seeing is just the Eagle Dynamics team's best guess. I had a hunch that since there are also a number of other pods in DCS that the code for the position of the relative direction dot might just be copied from one to another and not necessarily accurate for each pod, I think this is probably the reason it is off from the original video.
Very well. It would have been interesting to understand the type of steering, if heading corrected, or just a lead angle.

Very well. It would have been interesting to understand the type of steering, if heading corrected, or just a lead angle.
Not too sure what you mean here. The dot isn't a steering dot it's just a visualisation of where the targeting pod is looking relative to the nose of the aircraft (i.e. so that the operator can glance at the dot and get themselves orientated quickly without having to read the two angles on screen and work it out).

Here's the only time it's discussed in the manual if it helps:

And a video of the original video + mine overlaid on top so you can see that they are actually agreeing on where the object is relative to the plane, just one is closer to the edge of the UI than the other:

Not too sure what you mean here. The dot isn't a steering dot it's just a visualisation of where the targeting pod is looking relative to the nose of the aircraft (i.e. so that the operator can glance at the dot and get themselves orientated quickly without having to read the two angles on screen and work it out).
I think that manual is very illustrative. The steering cue dot is an important part of the HUD and I've seen it reproduced in the ATFLIR's SA display. Its displacement is not specular to azimuth, you can see it in the GIMBAL VIDEO when this value is 0 °L, and in fact it has a well-defined trend from an analysis. The problem is that there are different steering cue dots, from the one that indicates the heading to the one that indicates the lead angle. For this reason I wanted to understand if it changed behavior based on the wind. But I think DCS is a lot less true to reality than I thought. I thank you all the same.

Me too, I worry that it's just because the information we're given in the video is not accurate enough to pin down the location of the other object.

I recreated your Gimbal trajectory in my GeoGebra model, using the angle from the vertical (~31deg) and the distance to the fighter (almost constant at 12.9 Nm). Our Gimbal trajectories diverge after PT2 (0'11). This is the difference between a normal trajectory, and an odd one. I still cannot pinpoint what makes for the difference. I have to significantly alter my rate of turns (taken from @Marcus refined data), from 1.88 to 1.75 at PT2, and from 2.16 to 1.9 at PT3, to make it match your trajectory. But in your simulation the rate of turn is higher than that, and is closer to my original rates of turn. Still scratching my head to figure it out. Maybe you're right and we don't have enough information to be more precise.

By the way, what do the numbers of ~250 mean in your simulation (the one uder F/A-18C) ? It is different from the indicated air speed that is around 240.

By the way, what do the numbers of ~250 mean in your simulation (the one uder F/A-18C) ? It is different from the indicated air speed that is around 240.
The line under F/A-18C shows this:

So it is the Altitude above Sea Level, ASL, in 'cherubs' (i.e. 253 = 25,300ft).

Wait, do you use True Air Speed (~360 knots) or the calibrated air speed given on the screen? We have to use True Air Speed here.
I did a weather analysis in the period according to which the video took place, that is between 20 and 30 January 2015. According to some sources, the exact day would be 21 January 2015 off Jacksonville, probably in the restricted area W-138 or W-139. Unfortunately, there was no 120KTS jet stream present at FL250 at that date, nor was there a significant cloud layer. This scenario is instead compatible with the day January 24, at about 1800 UTC, but off the coast of Norfolk, probably in the restricted area W-79. This could be a further clue that GOFAST and GIMBAL were recorded during the same mission. At that time the altitude temperature was ISA +11. In the clip, the CAS varied between 238-242KTS, therefore equivalent to a TAS between 354 and 360KTS.

@MclachlanM

Comparing more closely your lines of bearing with mine, clearly you have a less curvy trajectory, that makes them close to parallel.
That does not quite fit the geometry in my model, neither the one of Marcus shown above.

Here is a video with your bank angles overlaid with the real bank angles :

First I want to say that your simulation is pretty damn close ! But maybe overall your plane is not turning enough ? You miss some turn at the beginning for a few seconds, then you have slightly lower angles between 0'11 and 0'16, and 0'23 and 0'30. I don't know but maybe that's enough to diverge from our trajectories ? I'm just trying to find out why we get different results, there are of course uncertainties in both approach, geometry and simulation.

One of the things that bug me about Gimbal having a steady trajectory is the movement of the clouds. If they were only due to the camera rotation, wouldn't they move the same between azimuths L7 and 0 (marks 0'27 and 0'30), and azimuths 0 and R7 (0'31 to the end)? However the clouds movement slows down and stops, instead of increasing again after the camera passed azimuth 0. It makes me think that what we see is also the effect of Gimbal slowing down and stopping.

Is there a way to add a cloud layer in this kind of simulation ?

Last edited:
On the other hand the difference of angles between our final lines of bearing are ~3°. Just the one second with no turn of rate at the beginning of your simulation + slightly less turn of rate between PT2 and PT3 could explain that difference.

### Venus​

The Venus hypothesis to explain how my lines of bearing came out nearly parallel did not hold up.

I wasn't able to think of a way Venus could appear to move in the opposite direction of the jet across the clouds. My first thought was wind was blowing the clouds making the object appear to move.

Source: https://youtu.be/sbWiI7gQFXw

I'm pretty sure there wasn't a hurricane in the area on the day of the encounter, so I couldn't come up with a model with enough wind speed/sheer to overcome the jet's speed.

I still think it's possible to see Venus with the FLIR pod during the day, and in fact IR might make this more likely, because by blocking the scattered blue light, there's better contrasts.

Filters

A cheap red screw-in eyepiece filter will counter the blueness of the sky (Orion sells a filter set, red, yellow, green and blue, for a good price). Moving upmarket, some recommended ones are long-pass filters that block wavelengths shorter than a particular frequency, for example, RG665, RG720, and RG830, where the number indicates that cutoff wavelength.

Source:

### Can You See Planets Or Stars In The Daytime With A Telescope?​

https://telescopenights.com/stars-in-the-daytime/

I took this photo of Venus yesterday evening after sunset using my darkest R720 IR filter.

Last edited: