correct as is F-16 Maverick ground stabilization bug

[yumemi5k]

Problem: In VIS or PRE mode, mav sensor circle starts gradually drifting away from SPI (TGP square) once you slew the mav sensor even only very slightly.

Reproduction:

Vanilla DCS at newest version, F-16 in Syria or Caucasus, new mission with default weather, pressure, etc, air start at 12k feet, 2x AIM9M, 2X A120B, 2x500lb GPU, 2x AGM-65H (The CCD variant), 2 wing tanks, TGP, HTS, Long ECM pod.

(See track) Air start over high ground, HUD as SOI, move SPI to somewhere where the ground is much lower than the ground directly beneath you. Do not fly directly at SPI but at an slight offset. Maverick WPN as SOI, slew the sensor slightly, notice the mav circle drifts away from TGP square. TMS down on WPN, sensor snaps back to SPI and stays there perfectly, but once you touch the RDR CURSUR joystick it starts drifting again. Note: If ground beneath you and SPI are on the same elevation, this bug does not seem to manifest.

I believe this started since the patch that fixed F-16 CCIP falling short problem. To be honest I agree that this bug sounds crazy so I'm not sure if it's error on my part. Apologies if it is.

F-16 mav ground stab bug.trk

[BIGNEWY]

Hi,

Observing your track, there doesn't seem to be any problem with how the sensors work
You first have HUD as SOI and perform a TMS up command to designate a "visual" point. When you select DMS down to make WPN as SOI, and then move the cursor, you are effective undesignating the point, and you will see the "keyhole" symbol waiting for a new WPN lock. If you press TMS up while MAV is SOI, it will attempt to lock via optical/thermal contrast. If you press TMS aft it will zero de cursor back to the previous designation.

Again, we don't see anything wrong, but perhaps you wish to clarify further?

thank you 

[yumemi5k]

Thanks for the quick response. I've uploaded 2 more tracks with TGP point track showing the same behavior. Mav in the 'good' track taken on flat ground stays ground stabilized after you slew the WPN SOI, and the mav sensor picture doesn't drift. In the 'bad' track where I come from the mountains, the mav picture starts drifting the moment I slew the mav sensor a little bit. What is even more bizarre is that in the 'bad' track, when I later swing back from the sea, the mav sensor stabilizes just fine like in the 'good' track, probably because terrain beneath me is on the same elevation as the point track.

F-16 bad mav ground stab with large elevation diff.trk F-16 good mav ground stab on level ground.trk

[BIGNEWY]

Hi, 

The AGM-65 does not have any internal ground stabilization logic where it is able to calculate the slant range to the terrain elevation within its seeker field-of-view independently of the aircraft.

The TGP for example is able to do this using the radar altimeter, passive-ranging using digital terrain elevation data, or barometric altitude of the selected steerpoint.

But the AGM-65 is just a weapon seeker and does not perform all this gee-whiz math that the aircraft computers can do.
So if the seeker is slewed away from its ground-stabilized reference point to an area of terrain that is at a different elevation, there is no elevation calculation that can be made for that.

I hope that makes sense. 

[yumemi5k]

5 hours ago, BIGNEWY said:

So if the seeker is slewed away from its ground-stabilized reference point to an area of terrain that is at a different elevation, there is no elevation calculation that can be made for that.

I hope that makes sense. 

Thanks for the response. However, the unexpected behavior appears NOT when the mav seeker is slewed to look at a point higher than the SPI, but when the player aircraft is flying over ground higher than SPI. In other words, ground elevation directly beneath you affects mav ground stabilization behavior. I find this very bizarre - I understand mav simply looks at a point the jet tells it to, and the jet calculates the angle it needs to look at using its navigation solution and the 3-dimensional position of SPI. The jet might use radar alt as a last resort if the navigation solution is very bad, but that is not the case for a default mission air start.

As you can see from my OP track and the 'bad' track in reply, the mav seeker circle starts drifting away significantly from SPI square once the seeker is slewed a tiny bit. I really can't think of a valid reason why the ground stabilization should behave like that. To top it off, once you are flying over terrain at the same elevation with SPI, ground stabilization starts working perfectly, which is my main conviction why this is probably a bug.

[RogueSpecterGaming]

@BIGNEWY if you watch the tracks that yumemi5k posted, it shows where when the jet itself is over leveled terrain the MAV is ground stabilized, but the other track shows that when he is flying over mountains that it does not ground stabilize, but as he continues flying and meets leveled terrain the MAV magically ground stabilizes. That is incorrect behavior, as it shouldn't ground stabilize at all on its own, as even you said yourself. It should only ever be ground stabilized if in track mode, AREA mode (65H, G, K) or in correlation with the TGP (specifically PRE). 

[RogueSpecterGaming]

How the MAV behaves in regard to SOI is correct. Let's keep this on topic please. The OP is correct that there seems to be an error in when the MAV is being stabilized. While the jet is over mountains it isn't stabilized, but the minute the jet is over leveled ground it is stabilized. The MAV should not be stabilized unless correlated with the TGP/FCR in PRE, or when using BORE. If using VIS it should not ground stabilize unless a TMS up action has been done as the missile is slaved to the TD Box in the HUD (or JHMCS).

You can see in the tracks that even if using PRE the missile does not ground stabilize until leveled ground is reached.

[yumemi5k]

I think at least it is quite likely that there is a bug, because:

1. Terrain elevation directly beneath player aircraft affects Mav stabilization behavior, which makes no sense.

2. The Mav seeker veers wildly away from SPI square in the 'bad' tracks, which again, makes no sense, as no sensible stabilization effort should produce such a movement.

As for whether the Mav should ground stabilize in VIS mode, my speculation is yes. When you designate a SPI using HUD as SOI, the jet's computer calculates the offset angle from the jet's axis to the SPI, and tells the mav sensor to look at that offset. The mav is just being slaved to onboard MMC and is not performing any tracking at this point. This already is a form of ground stabilization. If you then slew the mav sensor, you merely add an further offset to the aforementioned offset. Whether this new pilot commanded offset equals zero or not shouldn't fundamentally change how mav ground stabilization behaves.

[NineLine]

Thread cleaned, PLEASE stay on topic. 

To the OP issue:
You are seeing the behaviour over uneven terrain but not level terrain, this is because the calculation differences involved between each situation. We do not see a bug here based on this. 

[yumemi5k]

@NineLineThanks for looking into this. However I'm still not convinced:

1. Why should there be "calculation differences" caused by different ground elevation beneath player aircraft? The jet has many other better ways for working out its navigation solution and SPI coordinates, radar altitude shouldn't even matter at all.

2. The maverick remains perfectly on target if not slewed, why should a tiny amount of offset suddenly send it quickly veering off target?

3. OK let's say that a tiny bit of offset is indeed, somehow, treated entirely differently in the jet's computer. Then still, the jet's MMC does an gargantuanly bad job at ground stabilizing the missile. Simply adding the player induced offset angle to where the jet thinks the SPI is would have produced a much better result than the current situation.

I think this started after the "CCIP dropping short fix" patch for the F-16. Could you go to the guy that did the fix and ask if this rings a bell?

I have no documents to support my points, I just find the current implementation extremely bizarre. If you still find no problems, I have nothing more to add.