investigating Maverick F not receiving current ATFLIR point track target info

[vCSG3 Bloat 203]

When using Maverick F against moving ground targets, the ATFLIR point track used to (and I believe it should) continuously update the system target point. When uncaging the Mav F, the seeker would previously snap to the current position of the point tracked target.

Now, after the recent TDC depress changes to make JDAM TOO rippling somewhat unbroken, the TDC depress is REQUIRED even in point track. This results in the Mav F seeker never having the most recent position of the target when uncaging. With moving targets, this means the only way to successfully hand over from point track to MavF is to TDC depress and instantly change SOI back to mav and uncage. Even a second delay is enough to throw the seeker sufficiently behind the moving target

Please see this short 1min clip that illustrates this. I can generate a track if required.

https://clips.twitch.tv/OriginalBlightedDragonflyBuddhaBar-ZTlQOtOaGsJN2fi-

Many thanks for your continued efforts!

[Harker]

The actual issue is that the ATFLIR, while in AUTO track, will not continue updating the designation if the TDC priority is moved to another display. Normally, it should continue to do so, until another sensor is commanded to designate, regardless of where TDC priority is.

[vCSG3 Bloat 203]

40 minutes ago, Harker said:

The actual issue is that the ATFLIR, while in AUTO track, will not continue updating the designation if the TDC priority is moved to another display. Normally, it should continue to do so, until another sensor is commanded to designate, regardless of where TDC priority is.

thank you, that is the fuller way to look at it. Cheers pal!

[BIGNEWY]

Hi 

if you have evidence the maverick should slave to a moving target please PM me, as we have it now the Mav will slave to the TGP LOS of the AUTO target, but you must then undesignate and manually lock the moving target.

thanks

[Harker]

Hi 
if you have evidence the maverick should slave to a moving target please PM me, as we have it now the Mav will slave to the TGP LOS of the AUTO target, but you must then undesignate and manually lock the moving target.
thanks

That's not the issue, the real issue is that the designation diamond stops being updated as soon as TDC priority is moved away from the FLIR page.

That's wrong, since the FLIR is still the designating sensor, as indicated on the HUD (it says FLIR) and thus it should continue updating the designation no matter where TDC priority is.

As for the Maverick, it should slave to the designation, that part is not wrong. The problem arises from the fact that people move TDC priority to the IMAV page, in order to uncage it and then the designation stops being updated from the FLIR.

[MARLAN_]

https://forum.dcs.world/topic/295031-atflir-in-point-track-doesnt-update-target-designation/#comment-4952178

[BIGNEWY]

9 minutes ago, Harker said:

That's wrong, since the FLIR is still the designating sensor, as indicated on the HUD (it says FLIR) and thus it should continue updating the designation no matter where TDC priority is

If possible please PM me with any evidence I will run it by the team again

[BIGNEWY]

4 minutes ago, MARLAN_ said:

https://forum.dcs.world/topic/295031-atflir-in-point-track-doesnt-update-target-designation/#comment-4952178

If this is the same issue then it is reported for the team to investigate. 

[Harker]

If possible please PM me with any evidence I will run it by the team again

Thank you for running by the team.

I don't have any documentation specifically stating that "the designation continues to be updated by the designating sensor, even after the TDC is taken away from the page".

Manuals logically imply that the designation is driven by whatever created it, regardless of TDC priority. The TDC comes into play if you depress it, while on another sensor page, in which case, that sensor becomes the designating one.

The current logic in DCS is also not described or implied anywhere and furthermore makes no sense, at least based on anything I've read.

Anyway, I'll see if I can find a document that clearly describes the process, however I don't think that TDC priority will be covered in it, because it's never stated that it affects anything in the first place, at least according to what I've been able to find.

[BIGNEWY]

without any evidence it should be different I wont be able to get any changes made. 

but thank you for the reply. 

[MARLAN_]

Hi, in this track it shows if the TDC Priority is not assigned to the FLIR page the designation does not update anymore. You can see the FLIR tracking the vehicle but the diamond indication for designation stops moving until the TDC Priority is returned to the FLIR page.

This of course causes big issues when you are forced to remove TDC Priority from the FLIR page and move to the maverick page as the maverick keeps attempting to return to the FLIR designation which has suddenly stopped updating. The maverick is capable of tracking the moving vehicle if there is no FLIR designation, but is unable when the FLIR is tracking because the designation is lagged behind as soon as TDC priority is moved.

There will be trouble finding specific evidence that explains that this isn't programmed into the F18 software, does ED possess evidence that it does exist? It makes no sense for the FLIR to stop updating its designation when TDC priority is removed from an active designation. If this existed as is would cause major issues in practical use as seen in the track.

I think it is extremely unfair to say changes cannot be made if there is not evidence that specifically states in the negative that anti-user software design is not implemented for the F18. Sometimes interpretation is needed unless it is explicitly stated that this design is actually implemented.

NTRP 3-22.4-FA18A-D 4.3.5.1.2.2.1 and NTRP 3-22.4-FA18A-D E.11.2.3.2 briefly talk about this in the positive form.

 

FLIRDesignation.trk

Edited June 24, 2022 by MARLAN_

[84-Simba]

I would agree for the TDC priority ''bug'' ... I can't see why the pod would stop tracking.

But ... I'm not sure for the Mav.

When you switch from tgp DDI to Mav DDI and uncage, the system will handoff the position of the target from the tgp to the Mav and its seeker will snap to that position.

But during that process, the target will move and I'm not sure the system can continuously handoff the position to have a tracking.

The way I see it, the mav seeker will look at the position the tgp was looking when you initiated the handoff and then you have make the mav seeker track the target on his own.

So, your mav seeker will end-up behind the moving target anyway.

Don't you think ?

[oldcrusty]

It sounds to me like we are all on different builds here.  I'm on the latest OB and the way this 'silly' missile works on my rig is:

1. In a low contrast desert environment -

   If the Mav is slaved to GMT radar, it follows the radar track from quite a distance and when close enough for its seeker to snatch the mover, it locks and stays on it till 'rifle'. Unless... there is a lamp post or a fence near the target at the time of acquisition. The Mav's seeker definitely prefers those, hehe.

   If the Mav is slaved to FLIR, it's still doable, just have to do bunch of cage/uncage flipping and lots of times switching TDC to FLIR then back to MAV then cage/uncage.

2. In an urban environment or around forests, roads with center dividers, lamp posts or fences...  good luck.

So, for me the biggest issue is the Mav seeker and criteria for acquisition of static v. movers.  I doubt it is true contrast.  Also, I'd be happy to see the Mav following the FLIR the same way it follows GMT when in slave mode.