CM-802AKG ghost input/guidance drift

[Tippis]

The manual guidance of CM-802AKG missiles break down on the second shot by having some kind of ghost input or guidance drift causing the missile to constantly receive a downwards/right command that the pilot has to struggle to cancel out.

 

 

When firing two AKGs against the same waypoint in direct mode with a couple of minutes separation, the first missile can be guided as expected. Nudging the controls around shifts the aimpoint and the missile path adjusts accordingly. It is fairly trivial to move it over to a viable target, lock on, and have the missile handle terminal guidance. In the video above, from 2:30 onwards, the missile settings and the final guidance of the first missile can be seen. Zooming in and out to get a better view also works as expected and does not impact the missile control in any way.

 

With that good hit out of the way, turning around and firing a second missile, everything seems to work as normal at first. However, the instant any kind of manual input is given, the missile control goes off the rails. See 6:00 onwards in the video. A nudge to the left spikes the aimpoint down and right, and constant counter-input is required to even begin to keep the missile flying straight. Zooming in dampens the input (which is as expected) but the constant downwards/right ghost input is still there at full force and the manual, dampened input is no longer sufficient to cancel it out — the missile quickly guides itself into a descending rightwards spiral and hits the sea.

 

The fact that nothing strange happens with the first missile highly suggests that this is not a binds issue. It controls just fine under the exact same circumstances as the second missile. In addition, this is with all other control binds cleared — only a single analogue control stick is bound to the x- and y-axis for sensor control, so no other device should be able to generate this extra input.

 

This happens in SP with a runway hotstart and as such should be unrelated to the fixed cold-start/MP bugs, but the spiraling input suggests that there may be some connection with missiles (both 802AKGs and 802AKs) circling above some random spot near a designated target.

 

 

e: Based on later testing (see post #3) it seems like there is some cross-contamination going on if one missile is locked on while others are still attached to the aircraft. It is almost as if the automated steering from that lock-on set a new centre point for subsequent missiles. Manually guided missiles do not suffer from this, nor do missiles fired in rapid sequence (i.e. both are in the air at the same time, before any MITL and lock-on phases have begun). Thus, the replication steps are something along the lines of:

 

1. Prepare the 802AKG missiles for firing.
   
2. Launch one missile, wait until MITL
   
3. Slew the crosshair over to a target, lock on, and let the missile hit.
   
4. Launch a second missile, wait until MITL
   
5. Slewing is now broken.
   

cm-802akg-steering.trk

Edited December 11, 2019 by Tippis

[L0op8ack]

will check

[Tippis]

Breakthrough – potential cause found.

 

As an update, based on the issues described in the “Slew doesn't not center when using MITL CM-802AKG” thead, I went back to try to cancel out the drift I was experiencing. This could be done temporarily by centring the aiming cross using keyboard inputs, at which point the missile would follow the set course.

 

The slew would still not auto-centre, just as described in the other thread, but temporarily it would cancel out the incorrect centre position that would be set for the second missile. However, applying any kind of slew input with the bound analogue axes would once again reset the centring to an incorrect off-axis state and the missile would once again dive into the sea. So while the two may be related, it is not just a matter of keyboard input accidentally setting the steering cross wrong.

 

This was attempted with a fully cleaned and repaired install, with all default binds, once again suggesting that it is not an ghost input issue from any device, but rather that the second missile is somehow being fed an incorrect base orientation as its basis for slewing.

 

On a hunch, I tried a couple of runs where I attempted different mixes of locking on a target and not. It seems that if you lock onto a target for terminal guidance, that guidance “infects” subsequent fired missiles. By not locking on the first missile, the second can be guided just fine. If both missiles are in the air before any MITL is engaged, the cross-contamination does not occur.

 

In the attached tracks:

• The first shows what happens when trying to simply steer the missile onto a target without locking on: everything works perfectly.
  
• The second shows what happens when locking on the first missile and then trying to steer the second on-target (or just into a position where it can also lock on): the lock-on guidance seems to cross-contaminate the second missile, making any slewing next to impossible to control as it centres on an off-axis point.
  
• The third shows what happens if both missiles are fired in close succession, such that the first missile has not yet entered MITL-mode when the second is launched: no cross-contamination happens for the second missile – both can be controlled and locked-on without issue.
  
• The fourth and fifth show what happens if more than two missiles are fired (using infinite ammo, but this also seems to hold true for rearms): that cross-contamination happens for some subsequent missiles once a lock-on has been used. So, on the first attempt:
  
  • First missile — manually aimed (deliberate miss), slewing works as expected.
    
  • Second missile — launched before MITL on first missile, locked on, slewing works as expected.
    
  • Third missile — launched after MITL on the second missile, locked on, slewing works as expected.
    
  • Fourth missile — launched before MITL on the third missile, slewing broken due to contamination from missile 2(?)
    

  On the second attempt:

  • First missile — locked on, slewing works as expected.
    
  • Second missile — launched before MITL on first missile, manually guided (deliberate miss), slewing works as expected.
    
  • Third missile — launched after MITL on the second missile,slewing broken due to contamination from missile 1(?).
    
  • Fourth missile — launched before MITL on the third missile, manually guided, slewing works as expected.
    

   

The fourth and fifth track is particularly interesting. On the one hand, it seems like firing from one station contaminates the other (as seen in test #2), but test #5 suggests that you can “cancel out” some of that by having two missiles in the air at once where the last one does not use the lock-on functionality. The first missile in that firing sequence should contaminate both shot three and four, but only #3 is effected (which is fired from the same station as missile #1). Similarly, with test #4, one would expect that both missile #3 and #4 would be contaminated by the second missile, but only #4 is (which, again, is fired from the same station as missile #2).

cm-802akg-steering-unguided.trk

cm-802akg-steering-guided.trk

cm-802akg-steering-rapidfire.trk

cm-802akg-steering-multilaunch.trk

cm-802akg-steering-multilaunch2.trk

Edited December 19, 2019 by Tippis

[Tippis]

Still an issue in the 41256 build.

[L0op8ack]

we were focus on CTD bugs, input filtering have to be delayed.

sorry

[Tippis]

Oh well. At least there are some work-arounds (simply not locking anything, or making sure all missiles are in the air before trying to guide them) in the meantime.