reported earlier INU drift and Lima tracking bug

[84-Simba]

Hi again !

I'm still struggling with the points and the Lima in the Apache.

If I do a cold-dark startup and fly about 30-40 min, my Limas won't shack anything. I also noted that my stored points are always far from where I pointed them.
I point a target, lase and store. If I ACQ that point and slave, the TADS will point way off. If I move the TADS to the intended target, lock and launch a Lima, the missile will fly to the "wrong stored point" and seems to track something that is not there.

You'll find a track attached (drift) .. it's rather long but that's the only way to ensure potential drift bug or problem or mishap from my side.

Again, the problem is not present when starting hot and on station.

 

Drift.trk Drift2.trk

Edited June 28, 2023 by 84-Simba

[84-Simba]

Did another test and it seems that the Limas are actually tracking something because they go right at the same point and appears to make a quick left-turn just before touching the ground.

4 shots at the same target from 4 different positions and distances (4 to 7 km) and the missiles went right at the same point in the ground.

Tried to turn them all on instead of auto ... no factor.

Tried to lase with different codes ... no factor.

Edited June 28, 2023 by 84-Simba

[84-Simba]

Again another test today and you'll find the track attached.
Again, it is another long track but it proves the INU problem :

Did a straight flight to the BP, lase/store/slave (T02 & T03) to find the very same "offset" and the first 2 Lima shots went exactly where they always go when ACQ T02.

For the sake of it, I did unbox/rebox doppler and reseted INU 1 and 2 ... another lase/store/slave on the same target (T04) and there was a slight offset but to the right this time.

Launched the Lima and the missile took another trajectory but tracked the target and shacked.
ACQ on a second target previously stored (T03) and there was the same offset as when I stored it, but the missile tracked and shacked.

 

So ... there is definitely INU drift involved that from what I understood, the Limas are inertialy guided first, then radar.

There is no informations on the proper way to update the position of the Apache and Casmo told me that it wouldn't be needed since it would be blended with GPS.
But even a rather butcher way of doing it solved the issue.

What makes me think there is some bug involved is that the first 2 Lima shots seemed NOT to fall ballisticaly behind the target (at 7ish km).

Both went EXACTLY on the same point in the ground and did a quick turn just before hitting the ground, like if they were tracking something that is not there (and beside the intended target, nothing is there and the Shilka targeted is in the open roughly 50m to the right).

And after the INU reset, the 3rd shot took another trajectory and found it's intended target. Between 1st, 2nd and 3rd shots I did not move one bit so the initial lasing for the Lima was the same for all 3 shots.

I would expect this behaviour from a JDAM, because if the the position of the launch point is untrue then the inertial guidance drives the bomb off.

But the Lima is supposed to have a terminal radar guidance, and there is no way it should track a "false position" ... add to that that on the first 2 missed shots, the missile passes just under the nose of the Shilka. I don't mind the missile going off for the first part off its flight (if the designated target coordinates are wrong because of an INU drift), but I can't see why it cannot correct its trajectory to reach a target 50m away.

 

@BIGNEWY
@Raptor9

Can anyone investigate this issue ?
I'm sorry in advance for the long tracks but this the only way to accumulate enough INU drift to demonstrate the issue.

OR, I missed something in my startup that keep the INU position blended with the GPS, but I did not see anything about that in Matt's, Casmo's nor anyone's startup videos.

Thank you !
 

Test INU reset.trk

[BIGNEWY]

Hi, 

please be patient we will take a look soon. 

It is often best to put different issues in different threads but as you mention you think it is related we will investigate. 

thanks

[84-Simba]

7 minutes ago, BIGNEWY said:

Hi, 

please be patient we will take a look soon. 

It is often best to put different issues in different threads but as you mention you think it is related we will investigate. 

thanks

Thank you ... Yes, I guess it will take longer than usual by nature of the problem.
I anticipated the confusion about the JTAC so I edited the original post and title to delete it completely.

I will run another thread to be more precise on that topic.

[BIGNEWY]

thanks, 

I have checked and we do have a report already for INU drift, I have added your thread to the report. 

thank you

[84-Simba]

I may have missed that because I wasn't sure what I was looking for.

But that doesn't explain why the Lima would look like tracking a "false" target I believe, since it is supposed to be radar guided.

[BIGNEWY]

I will check with our resident expert once active. 

thanks

[BIGNEWY]

As mentioned the INU drift has been reported so I will leave the thread as reported, but I am not convinced it is related to the LIMA issue you are seeing. 

Please ensure the missile is actually tracking a target, "LOBL NORM" will be replaced with "RF MSL TRACK" and the box will become big LOBL size. Then you can fire. 

Unless the track is not playing back correctly of course, this advice may help you with LIMA shots. 

 

[84-Simba]

Just look at my posts above.

2 back-to-back shots and the Limas tracked some ghost target (and not ballisticaly fell somewhere) 50m away from the ''initial lock'' target.

Both went to the EXACT same spot and had the exact same flight profile/path and behaviour.

Note that you can observe the EXACT same behaviour (the missiles fall in the EXACT same spot) in both tracks, meaning it is consistent from one test flight to another, even with a different flight route to target.

 

Then INU reset

 

Next shot at the same target, from the very same position (not moved one bit), very same procedure and it tracked the right spot and shacked.

It took a different flight profile though.

One last shot at another target and it worked again (while it was not working in previous tests as shown on other tracks)

So no, it is not a matter of setup nor anything.

The third track is the most obvious at showing everything and should be slightly shorter than the very first.

The second track is to show that everything is working fine when put directly on station (just for the sake of proving there is something degrading over time of flight)

Edited June 28, 2023 by 84-Simba

[84-Simba]

And I tested all 3 tracks myself and they were working just fine ...

I can provide the .miz file if you want to do it by yourself.

[84-Simba]

Further testing and I can provide some datas, if useful :

T01 entered in the TSD at startup is : 37S BA 5490 2560

When arrived at my battle position, ACQ to T01 and as expected, it has drifted.

The TADS slaves roughly to 5491 2562 (on the F-10 map)

Repositionned the TADS to the intended target, designated a Lima and ACQ/slave the seeker.

The missile was pointing at the offset.

Launched a Lima and the missile tracked something and fell roughly at 5479 2557 (F-10 map)

----- Reseted both INU ------

ACQ T01 but now the TADS slaves to roughly 5496 2558

Realigned the TADS and designated a Lima, ACQ the seeker and the missile was again pointing at the offset point.

Launched the missile and this one tracked and shacked its intended target (5490 2560)

In both shots the Lima seeker was as expected pointing at the offset point, not the vehicule I just designated ; this seems logical since the Lima has an inertial guidance in LOAL for the first seconds of its flight.

Conclusion :

With a degraded INU the Lima is tracking something that is not there at all and after an INU reset (still off but less degraded I suppose), it tracks correctly and shack the intended target.

Note that during all this I was having George maintening an hover at roughly 150ft.

The only time the helicopter moved is when I reseted the second INU.

The aircaft yawed a bit and stabilized (Thx George !!)

Next time I'll wait for INU 1 to reset entirely before reseting INU 2 ... or land somewhere and reset both on the ground.

For now it seems to work more like the Viper, meaning the GPS is not updating the INU at all time but only when you request an update (if I understood the Viper correctly)

If I follow Casmo's words, it should be embed at all time.

But I stand corrected since I never actually saw an Apache IRL ...

[84-Simba]

Hi !
As of today and with the last patch it seems the problem is solved. I managed to fly the very same training mission as always and did not performed an INU reset. The Limas are now tracking correctly and the INU does not seem to drift ; the slaving to a just stored target put the TEDAC right on spot.

Thank you very much guys !

[pedro.santuchi]

On 6/28/2023 at 9:30 AM, 84-Simba said:

Again another test today and you'll find the track attached.
Again, it is another long track but it proves the INU problem :

Did a straight flight to the BP, lase/store/slave (T02 & T03) to find the very same "offset" and the first 2 Lima shots went exactly where they always go when ACQ T02.

For the sake of it, I did unbox/rebox doppler and reseted INU 1 and 2 ... another lase/store/slave on the same target (T04) and there was a slight offset but to the right this time.

Launched the Lima and the missile took another trajectory but tracked the target and shacked.
ACQ on a second target previously stored (T03) and there was the same offset as when I stored it, but the missile tracked and shacked.

 

So ... there is definitely INU drift involved that from what I understood, the Limas are inertialy guided first, then radar.

There is no informations on the proper way to update the position of the Apache and Casmo told me that it wouldn't be needed since it would be blended with GPS.
But even a rather butcher way of doing it solved the issue.

What makes me think there is some bug involved is that the first 2 Lima shots seemed NOT to fall ballisticaly behind the target (at 7ish km).

Both went EXACTLY on the same point in the ground and did a quick turn just before hitting the ground, like if they were tracking something that is not there (and beside the intended target, nothing is there and the Shilka targeted is in the open roughly 50m to the right).

And after the INU reset, the 3rd shot took another trajectory and found it's intended target. Between 1st, 2nd and 3rd shots I did not move one bit so the initial lasing for the Lima was the same for all 3 shots.

I would expect this behaviour from a JDAM, because if the the position of the launch point is untrue then the inertial guidance drives the bomb off.

But the Lima is supposed to have a terminal radar guidance, and there is no way it should track a "false position" ... add to that that on the first 2 missed shots, the missile passes just under the nose of the Shilka. I don't mind the missile going off for the first part off its flight (if the designated target coordinates are wrong because of an INU drift), but I can't see why it cannot correct its trajectory to reach a target 50m away.

 

@BIGNEWY
@Raptor9

Can anyone investigate this issue ?
I'm sorry in advance for the long tracks but this the only way to accumulate enough INU drift to demonstrate the issue.

OR, I missed something in my startup that keep the INU position blended with the GPS, but I did not see anything about that in Matt's, Casmo's nor anyone's startup videos.

Thank you !
 

Test INU reset.trk 13.75 MB · 2 downloads

The same problem is happening to me. Exactly as you described.

[84-Simba]

2 hours ago, pedro.santuchi said:

The same problem is happening to me. Exactly as you described.

Be sure you have the last update and try a long repair of DCS ...

[[DE] T-Bone]

On 7/31/2023 at 6:46 PM, 84-Simba said:

Hi !
As of today and with the last patch it seems the problem is solved. I managed to fly the very same training mission as always and did not performed an INU reset. The Limas are now tracking correctly and the INU does not seem to drift ; the slaving to a just stored target put the TEDAC right on spot.

Thank you very much guys !

We had the case yesterday that our target points drifted over time, so the bug is still present.

[84-Simba]

So maybe the very last update reintroduced it ?

Before the updates I ran a slow repair so maybe it was this that solved the issue for me.

I'll be away from DCS for a few days but will retry.

[[DE] T-Bone]

5 minutes ago, 84-Simba said:

So maybe the very last update reintroduced it ?

Before the updates I ran a slow repair so maybe it was this that solved the issue for me.

I'll be away from DCS for a few days but will retry.

I don't think this bug has been fixed yet, at least I can't see anything in the changelog.

But as the title shows it is already reported.

Edited August 5, 2023 by [RENEGADES] T-Bone

[84-Simba]

3 minutes ago, [RENEGADES] T-Bone said:

I don't think this bug has been fixed yet, at least I can't see anything in the changelog.

There were a few words about INU but not directly the bug we are experiencing.

I'll try again in a few days.

Tell us if a slow repair is solving the problem.

Edited August 5, 2023 by 84-Simba

[pedro.santuchi]

22 hours ago, 84-Simba said:

Be sure you have the last update and try a long repair of DCS ...

DCS has the latest update. I'm going to try to do a long repair. Tks

[pedro.santuchi]

11 hours ago, pedro.santuchi said:

DCS has the latest update. I'm going to try to do a long repair. Tks

84-Simba
Solved the problem with 3 steps:

1-I uninstalled the AH-64 module
2-I did a long repair on DCS open beta
3- I reinstalled the AH-64 module
I tested it in a multiplayer environment and in single player as well. It worked 100% again. Thank you very much

[84-Simba]

Very nice !

I'm happy for you

[Moxica]

Not sure if it is Lima related; I've experience offset after slave/unslave tads.
Tads locked/looking in the wrong place after.
Way off the targets I was looking at.

[303_Tees]

I just played online today and this bug is still active

[McFly0081]

Same issue here... Flew a RotorOps last night. After about 30-45 minutes in the air, the issue would surface. Lima's would not track properly. They would take a hard left hook off the rail (sometimes right), then when approaching the target, would sail past and land behind and to the right. Had to take a new bird to fix the problem (which is only a temporary fix). However, this is all before reading this entire thread. My frustration in the RotorOps is what made me dig for others having this same problem. I'll have to test if INU reset helps or possibly a full repair and reinstall of he AH-64D module.

Edited August 11, 2023 by McFly0081