Joint use of FLIR and AGM65-F

[Bearfoot]

 

Bearfoot, you're not on the latest OB, are you? The steps you're describing worked great couple of builds ago. (talking about MavF v. movers) Actually, it worked even better 5 or 6 builds before the latest. There was no need for multiple TDC presses, unless the MavF snapped to the wrong target. But... mad cycle continues. Hopefully the devs are on the right track to solve the problem.

 

I am using the latest OB. And always have. I've been flying the Tomcat exclusively though until a few weeks ago, so never really explored A2G stuff in the Hornet, so have no experience with how this worked before. I figured out this approach through trial-and-error. Not sure if it is "as intended and correct", "as intended but incorrect", or a bug.

[Bearfoot]

It would be a whole lot simpler if point track actually updated the target location continuously...

 

Would you happen to know if this is a DCM-ism, or how it is in the actual aircraft?

 

 

[KittyVCAW-1]

 

If you've created the point track, and 30 seconds has passed since creating it - but you still have a point tracking solution - can't you simply TDC depress again to get the maverick seeker head to slew to the most recent position? Seems to work for me...

 

 

Cheers,

 

Ziptie

 

i eventually figured this out on my own. I assumed the tracking was updated live in real time. It was never explained to me this is not how it works. All I was saying is it might help other people if they knew this information. I'm also trying to figure out if this is actually how it works in the real airplane or is this WIP stuff. Armed with this important information firing IR mavs is no longer an issue for me.

[Ziptie]

 

i eventually figured this out on my own. I assumed the tracking was updated live in real time. It was never explained to me this is not how it works. All I was saying is it might help other people if they knew this information. I'm also trying to figure out if this is actually how it works in the real airplane or is this WIP stuff. Armed with this important information firing IR mavs is no longer an issue for me.

 

Glad to hear sir, happy employment and here’s to many more shacks! :thumbup:

 

Cheers,

 

Ziptie

[CougarFFW04]

Hi everybody,

 

I think that the major problem is that Mav seeker tends to lock on everything (trees, roadway guardrails, public lights,...) BUT moving vehicles...

This would explain why it might work pretty well in some places and completly fails in other.

[Ziptie]

Hi everybody,

 

I think that the major problem is that Mav seeker tends to lock on everything (trees, roadway guardrails, public lights,...) BUT moving vehicles...

This would explain why it might work pretty well in some places and completly fails in other.

 

Indeed this is where using the laser mavericks in a 'cluttered' area can prove more effective / less bothersome. That being said, those obviously require a continuous good spot from the laser - either requiring you to be in a more vulnerable position for a longer period of time, or getting a buddy lase. I agree, the FLIR showing trees/plants/telephone poles with the same intensity as a moving vehicle is a bit frustrating. Very much looking forward to when that can be corrected.

 

 

Cheers,

 

Ziptie

[CougarFFW04]

Indeed this is where using the laser mavericks in a 'cluttered' area can prove more effective / less bothersome. That being said, those obviously require a continuous good spot from the laser - either requiring you to be in a more vulnerable position for a longer period of time, or getting a buddy lase.

Certainly the -E version is a good option to prevent trees/plants DCS bug but I was interested in the -F

 

 

I agree, the FLIR showing trees/plants/telephone poles with the same intensity as a moving vehicle is a bit frustrating. Very much looking forward to when that can be corrected.

Especially when we know how easy it is to correct that...

Of course I didn't see the DCS code but probably they check for "things" around the designated position and it's just a matter of 3 lines of code to ignore not desirable objetcs. I did that in Lua code for other puposes. You could argue that if the code ignore trees by default we could lock target in forest. Wrong because if we do not see the target on the FLIR we cannot designate it. Hope they know about this frustrating bug...

 

[Ziptie]

Certainly the -E version is a good option to prevent trees/plants DCS bug but I was interested in the -F

 

 

 

Especially when we know how easy it is to correct that...

Of course I didn't see the DCS code but probably they check for "things" around the designated position and it's just a matter of 3 lines of code to ignore not desirable objetcs. I did that in Lua code for other puposes. You could argue that if the code ignore trees by default we could lock target in forest. Wrong because if we do not see the target on the FLIR we cannot designate it. Hope they know about this frustrating bug...

 

Yeah, I prefer the F variant as well. Only use the E variant if I've got a buddy lase. Personal opinion of course.

 

I also hope that they sort the FLIR out sooner rather than later (across all aircraft that use TGP).

 

 

Cheers,

 

Ziptie

[oldcrusty]

Certainly the -E version is a good option to prevent trees/plants DCS bug but I was interested in the -F

 

 

 

Especially when we know how easy it is to correct that...

Of course I didn't see the DCS code but probably they check for "things" around the designated position and it's just a matter of 3 lines of code to ignore not desirable objetcs. I did that in Lua code for other puposes. You could argue that if the code ignore trees by default we could lock target in forest. Wrong because if we do not see the target on the FLIR we cannot designate it. Hope they know about this frustrating bug...

 

There is nothing really wrong with the Ir Mav, or L Mav for that matter... in my opinion. Well, couple of minor wrinkles to iron out.

The problem is sensor integration or mission computers. Also, bunch of 'stuff' is not completed yet, from what I was told.

[Ziptie]

IR seeker head in the maverick (and IR mode in TGP) seeing a telephone pole or a bush as the same thermal intensity as a tank is definitely a problem sir.

 

 

Cheers,

 

Ziptie

[oldcrusty]

IR seeker head in the maverick (and IR mode in TGP) seeing a telephone pole or a bush as the same thermal intensity as a tank is definitely a problem sir.

 

 

Cheers,

 

Ziptie

 

Yea, few wrinkles to iron out...

[Bunny Clark]

 

Would you happen to know if this is a DCM-ism, or how it is in the actual aircraft?

 

 

Unfortunately, no. I'm not aware of any publicly available documentation on how the Lightening pod works with the Hornet. I hope that in real life point track constantly updates target position and someday in DCS it will as well, but I cannot say for sure that it works that way in real life.

 

 

IR seeker head in the maverick (and IR mode in TGP) seeing a telephone pole or a bush as the same thermal intensity as a tank is definitely a problem sir.

 

 

That should, hopefully, be solved when we get the new thermal rendering engine. But that won't necessarily solve the "problem" of the seeker locking onto these objects. If there's sufficient thermal contrast between a bush or telephone pole and the background, it's entirely possible for a Maverick to lock on to them in real life.

[Recluse]

From today's newsletter:

 

We are also working on the ground effect for the Hornet and have corrected lofting for the HARM. A bug when using IR-maverick for the first time has also been resolved as well as many more improvements.

 

Not sure what bug this was. I know I have had issues getting the MavF to successfully lock even when everything looks good, but I don't recall it being specifically when the first one is fired. I have also noticed that the first Mav automatically uncages when the TDC is moved to the MAV DDI, and subsequent missiles need to be manually uncaged. Maybe that is it?

[oldcrusty]

From today's newsletter:

 

 

 

Not sure what bug this was. I know I have had issues getting the MavF to successfully lock even when everything looks good, but I don't recall it being specifically when the first one is fired. I have also noticed that the first Mav automatically uncages when the TDC is moved to the MAV DDI, and subsequent missiles need to be manually uncaged. Maybe that is it?

 

If you're talking about Wags' mini-update, he was referring to a bug related to using mixed loads of MavF and MavE. If MavF was used first, there was a problem with getting a firing solution with MavE. At least I think that's what he's talking about.

Frederf suggested the issue was caused by a laser code reset to 1111, regardless of what DDI was showing.

[Recluse]

 

If you're talking about Wags' mini-update, he was referring to a bug related to using mixed loads of MavF and MavE. If MavF was used first, there was a problem with getting a firing solution with MavE. At least I think that's what he's talking about.

Frederf suggested the issue was caused by a laser code reset to 1111, regardless of what DDI was showing.

 

Ahh ok.. thanks!

[Wizard_03]

 

Unfortunately, no. I'm not aware of any publicly available documentation on how the Lightening pod works with the Hornet. I hope that in real life point track constantly updates target position and someday in DCS it will as well, but I cannot say for sure that it works that way in real life.

 

 

 

That should, hopefully, be solved when we get the new thermal rendering engine. But that won't necessarily solve the "problem" of the seeker locking onto these objects. If there's sufficient thermal contrast between a bush or telephone pole and the background, it's entirely possible for a Maverick to lock on to them in real life.

 

What your all describing is having the Lpod hand-off targets to the MavF seeker and it's not capable of doing that in the hornet, they can be pointed to the same spot, but the pod cannot hand-off tracks to the missile seeker as it can in say the F-16. If you want to use Mavs with the pod against a moving target, the E is a much better choice in the hornet, because it gives you a single track solution. IN other words the Lpod and MavFs cannot talk to each other as in other aircraft, they can only talk to the system separately.

 

[Bunny Clark]

What your all describing is having the Lpod hand-off targets to the MavF seeker and it's not capable of doing that in the hornet

I'm not thinking of a FLIR to MAVF hand-off like a Viper PRE delivery specifically. Just having the FLIR in PTRK mode continue to update the target designation point as the tracked object moves, rather than needing to hit TDC Depress all the time to update the target location. It would be useful for making an Auto LGB delivery on a moving target as well.

 

[oldcrusty]

 

What your all describing is having the Lpod hand-off targets to the MavF seeker and it's not capable of doing that in the hornet, they can be pointed to the same spot, but the pod cannot hand-off tracks to the missile seeker as it can in say the F-16. If you want to use Mavs with the pod against a moving target, the E is a much better choice in the hornet, because it gives you a single track solution. IN other words the Lpod and MavFs cannot talk to each other as in other aircraft, they can only talk to the system separately.

 

Shouldn't MavF be able to lock on the mover once the pod directs the MavF's seeker to it, provided the missile seeker is within its own parameters? I've been able to do it with SOI on the Mav's DDI (no designation on Tpod).

Am I looking at this correctly?

The pod can aquire the moving target from a fairly good distance.

MavF's seeker can aquire the mover on its own, also

 

But... if the pod is locked on a mover and points the missile to it the missile locks the ground spot.

 

The procedure followed: Locked the mover in PTRK on the pod > SOI to MavF > Uncage the Mav. > The Mav's seeker snaps to the target and locks the ground spot below.

 

Am I missing something?

Currently, I don't even bother using the pod on moving targets when I'm loaded with MavF's

[Wizard_03]

I'm not thinking of a FLIR to MAVF hand-off like a Viper PRE delivery specifically. Just having the FLIR in PTRK mode continue to update the target designation point as the tracked object moves, rather than needing to hit TDC Depress all the time to update the target location. It would be useful for making an Auto LGB delivery on a moving target as well.

 

The thing is the system can't have a moving TGT designation outside of the appropriate A2G radar mode. The designation in this case is only for a single point, which is true for most aircraft, F-16 included. The pod however can track a moving target, which is why when you try and designate a mover with the pod and then slave the MavF on over, it will go the spot that you designated, whether the target is still there or not. Hence for what your describing to work you would need the pod to pass that track directly to the missile. Because it can't pass it too the system and then the missile.

[Wizard_03]

 

Shouldn't MavF be able to lock on the mover once the pod directs the MavF's seeker to it, provided the missile seeker is within its own parameters? I've been able to do it with SOI on the Mav's DDI (no designation on Tpod).

Am I looking at this correctly?

The pod can aquire the moving target from a fairly good distance.

MavF's seeker can aquire the mover on its own, also

 

But... if the pod is locked on a mover and points the missile to it the missile locks the ground spot.

 

The procedure followed: Locked the mover in PTRK on the pod > SOI to MavF > Uncage the Mav. > The Mav's seeker snaps to the target and locks the ground spot below.

 

Am I missing something?

Currently, I don't even bother using the pod on moving targets when I'm loaded with MavF's

 

It can, sure, provided the targets not moving too fast and or there is enough contrast right out the gate. But it's not really reliable for those reasons and others.

 

As I understand it IRL the pod would be bipased all together, like you said. Maybe you use it get a designation close to the target, but for the attack you would just put the TDC on the Mav page and lock up the target manually. Rather then jumping back and forth between the pod and mav feed.

[Bearfoot]

I'm not thinking of a FLIR to MAVF hand-off like a Viper PRE delivery specifically. Just having the FLIR in PTRK mode continue to update the target designation point as the tracked object moves, rather than needing to hit TDC Depress all the time to update the target location. It would be useful for making an Auto LGB delivery on a moving target as well.

 

For LGB's, you do not need to "manually" update the target designation. A simple point track (even without the offset cursor) works fine for the laser tracking, of course. But I guess you are referring to the Auto release cuies? I guess the Auto release cues may not update but with ground vehicle speeds not sure if that makes a difference in practice -- the difference is made up for by the guidance. At least, I find LGB plinking moving vehicles having so much less a fiddly switchology than either Mav F or E.

 

(Of course, LMAV's have other issues where (for some people at least) you cannot launch till the TGP is SOI (or I guess "TDC assigned to TPOD format" in Hornet-speak. But that's another story.)

[Bunny Clark]

Wizard_03][/b]The thing is the system can't have a moving TGT designation outside of the appropriate A2G radar mode.

That's curious. If the system can handle a moving designation in GMTT I'd think it could do it for the FLIR as well. But maybe not, I don't really know.

 

But I guess you are referring to the Auto release cuies?

Yup. I've had LGBs miss before because they were dropped too far out of the bucket by AUTO. Now I'll typically re-designate at around 5 seconds before release and make a quick course correction and then it's fine. But it'd be cool if the designated point just followed the target.

 

(or I guess "TDC assigned to TPOD format" in Hornet-speak. But that's another story.)

You can replace "SOI" with "TDC Priority" or just "Priority" in Hornet-speak :)

 

 

[Wizard_03]

That's curious. If the system can handle a moving designation in GMTT I'd think it could do it for the FLIR as well. But maybe not, I don't really know.

 

The radar is a lot more integrated with the aircraft. The same is true for the AA modes, The pod and radar can correlate tracks that they both have and be cued to each-others LOS, but they can't actually hand off tracks to each-other. AFAIK

[oldcrusty]

 

The radar is a lot more integrated with the aircraft. The same is true for the AA modes, The pod and radar can correlate tracks that they both have and be cued to each-others LOS, but they can't actually hand off tracks to each-other. AFAIK

 

It should be fun when we get auto acquisition mode (part of AGR?). Point the HUD or better yet, an HMD at a moving target... IF you can see it, get a radar lock, confirm VID on Tpod, switch to weapons and send them on the way... OK, I'm just theorizing right now, hehe.

We should be able to get an Auto release solution on a mover in that scenario... should we?:D