84-Simba

I tried yesterday on the very same mission I always do and everything was fine on my side. The slow repair is the most probable fix for this issue.

Very nice ! I'm happy for you

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.

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.

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

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 !

Hi there ! Is there a known way to separate the KU screen like the MPDs are ? At the moment they appear on top of each other and it would be nice to have it hot-swap like the MPDs. Thanks !

Hi ! How did you separate your KU between PLT and CPG ?

Hey there ! Has anyone figured out how to export the KU and have it hotswap like the MFDs when changing seats ? The MFDs are working like a charm in that matter but the KU is still showing both PLT and CPG seats at the same time ... Thank you guys !

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 ...

Attitude hold - Trim button left

Weird, he does the job very well here but I usually am no higher than 200ft and often way lower. I enter my hover, trim ... then activate the ''auto hover'' and switch to the front seat. Note that I have auto-handover boxed.

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.

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)

Hi ! To separate from another problem I'm creating a new thread. I set a JTAC in a Stryker (TOW) and it has the capability to actively lase. When it gives me the coordinates, I get 8 digits and an altitude ... but if the coordinates are completely off, the altitude is true and it lases at the right target. When I say the coordinates are off, they are off by 300m at least. Let's say Axeman picks up a general area coordinates and do the precise targeting with the laser ... What I observed is that he gives me the altitude of the real target but and not the true altitude of the point he gave me. Like - 56572736 at 230ft. Enter those coordinates and the Apache will give you 252ft. Check on the f-10 map and the Apache is right ; the TADS looks where it should and the altitude matches. And if you LST the TADS to where Axeman is lasing (the target) it is at 230ft. So basically Axeman cannot give me more precise coordinates but is giving me the correct target altitude. Is that supposed to work that way ?

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.

Check if you have George AI auto Handover boxed. If not, your controls will remain active when you'll switch to front seat and you'll have to press the handover button.

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.

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

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.

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

What do you mean ?

Is there a way to recalibrate INS ? After an around 30min flight my INS seems to be off. When I enter JTAC coordinates and slave on that point it is waaay off the intended target ... Add to that that I cannot shack anything with the Limas ... they end up where the INS falsely place the point and never track. Weird.

Same as for today.

You need a track to reproduce the wingman calling endlessly ? Come on ... He calls ground and airborne contact more than 200 miles away.