Super Grover

Hey! LANTIRN has its own INS, and it uses GPS data to align/correct the INS. Also, it can read waypoint coordinates from AWG-9. However, I think that the way you use VIS FIX may be wrong. With CAP drum set to NAV category, the VIS FIX button is used to apply a shift to own INS position based on a position of a waypoint you can easily identify visually. You have to press it when overflying that waypoint. It means that the FIX procedure doesn't change the coordinates of the waypoint, but only updates the INS. That's why you observed no change of the QWP1 on the LANTIRN screen. The only way to update a waypoint position is to enter new coordinates manually or drag it with the HCU.

If I remember correctly (I would have to dig in the documentation), the CADC doesn't use any altimeter settings (just plain 29.92). Altimeter setting (correction for non-standard pressure) is applied in the altimeter.

It's possible that the sliding can cause that, but I have to investigate it further.

Pulling G is not required to accumulate error. If the INS is misaligned, it'll accumulate error even when staying still on ground.

The INS has only a limited ability to detect alignment errors. More often it would be just true heading being wrong, and you can only verify it by checking the true heading through CAP+TID (or mag var, but that you'd expect to be off on a carrier). You can't tell if the true heading is wrong by just observing the BDHI or the VDI/HSD/HUD, because they are all magnetic and by design they are default driven from the AHRS. Moreover, even with a very bag alignment, initially the INS will show the correct position, as it's initialized at that position and the initial velocity is zero. However, it will catch some false velocity very quickly. There's another possibility; if it was a multiplayer session with some heavy lags/desyncs, the INS could have sensed large differences between own velocity and the carrier velocity through SINS, leading to significant alignment errors.

It depends on how you fly the aircraft as an acceleration greater than 75 knots/minute disables slaving the directional gyro of the AHRS to the magnetic field from the magnetic azimuth detector (MAD). This means that it's very easy to never let your AHRS resync. You have to fly level and constant speed, and this is often a challenging task when those two engines are just waiting to give you more power and more speed, and when the pilot is looking for the opportunities to fight and keeps maneuvering. @sLYFa Jester knows the mag var from the kneeboard :) and he enters it on startup, after switching the NAV mode to INS.

The F-14 doesn't have any magvar database. It uses the AHRS magnetic heading together with the INS true heading to compute the magnetic variation. The INS knows how to draw true north during alignment from observing the gyros drift.

Assuming that all INS-related devices were OK, the first thing to check would be the COMPass panel (pilot's right side console) http://www.heatblur.se/F-14Manual/cockpit.html#compass-control-panel Fly straight, level, constants speed at low AOA and check the display marked as 1 - SYNC IND. If the needle is shifted from the centre, the AHRS has drifted/aligned to a wrong magnetic heading and caused that MV error. Press and hold that HDG PUSH button (5) until the needle moves back to the centre. If the needle doesn't move, you're probably turning/climbing/diving/accelerating/decelerating - just check your speed and attitude and try again.

Just FYI, the bearing accuracy of digital readout of the AN/ARN-84(V) - the TACAN - is between 0.5° (for signals stronger than -82 dBm) and 2.0° (below -90 dBm). And we model that in our TACAN receiver. What you observed and recorded in the video is that TACAN inaccuracy together with possible mag var drift.

From the picture you posted, it looks that you are ~45NM from the TACAN, which is far for TACAN FIX. At that distance, the calculated mag var errors and the measured TACAN bearing inaccuracy (don't underestimate this) may introduce significant errors to your position updates. In other words, what you see on the TID, the delta, it's NOT the difference between the aircraft true position and the current position. It's the difference between what the INS thinks is the true position and the current position. Back to manual delivery, we don't need to post any manuals here, but it would be useful to understand what you want to achieve. Because from your description it looks that you may be trying something that the F-14B couldn't do.

There's nothing suspicious in the "mess" continuing after unpausing because it's directly linked to the velocity error which is introduced during the active pause period. Yes, the range is slant; however, when applying the INS update, the difference between the aircraft altitude and the TACAN elevation is taken into account. I'm not sure what is your procedure to prime the INS. Did you perform FINE GND alignment? Did you move during the alignment? Or maybe you entered a hot aircraft? There are many reasons leading to such drift. Moreover, it's not scripted, and it's not a simple function. Even when you perform the same alignment twice, each time the error of the alignment (and hence the drift) will be different. Updating own position by editing it through CAP/TID or via VIS FIX should give the same results. I think I don't understand what you call "manual bombs release". The INS should work fine for Computer Pilot or Computer Target but using it for anything else will probably fail.

Thank you for your report. It's a known thing and a limitation of DCS. The nose gear on the F-14 is unique - long-travel strut which is almost fully extended on ground, and the AI animations/procedures can't handle that properly (we don't control those animations/procedures - they are built-in DCS functions). So this is the best compromise I managed to achieve for the AI aircraft.

It's the active pause that messes with your INS. The INS "thinks" that it's flying in some direction, and it applies all corrections necessary to keep the platform level, but it doesn't move so the correction is wrong. I've just checked it with my debug tools, and everything is ok until I hit ACTIVE PAUSE. I'll look for a solution to stop updating the INS with active pause in use. Also, I wanted to mention that we model TACAN inaccuracy accordingly to the device specification, so I just wanted to warn you that comparing with that introduce some additional errors. Finally, I wanted to reassure you that we haven't touched the INS for weeks and that I check the debug output regularly and we haven't observed any INS anomalies when the device is used properly.

It's a feature of the real F-14.

Thank you for your report, Shadoga. The log doesn't contain anything suggesting that the F-14 caused that crash directly. Although I can't rule out some indirect F-14 impact on that crash, the log looks as it was a crash in the core of DCS. Also big thanks to everyone reporting that the CTDs are gone for you.

Hey Shadoga, Thanks for your log. Unfortunately, nothing is suggesting what caused that crash, and it's a bit unlikely that accepting a client RIO could trigger something fatal on the F-14 side as nothing changes in the F-14 until the RIO gets spawned in the cockpit. If the simulator keeps crashing for you in such situations, please let us know, and we will investigate it further.

As we've been hunting down those random crashes you reported (as Cobra wrote before, DCS doesn't produce crash logs because of the DRM, so it has been extremely complicated), we've received multiple reports with crashes happening outside of our code and in the other parts of DCS. So just that you're aware that only some of the crashes you experience while flying the F-14 are from the F-14. And of course we're very sorry that you experience any crashes with the F-14. Nevertheless, our testers haven't got any F-14 crashes for weeks and probably the next patch should eliminate that last issue with PAL/TCS that I discussed in this topic before. Finally, I wanted to write that we take all your reports very seriously, and after we receive a proper crash log, either from you or from our testers, usually we have it fixed the same day or the next day. So I wanted to thank you all for your reports because you're making the F-14 module better.

It's fixed internally and should be available to you with the next update.

Those were static objects placed in the mission editor so the fix should apply to all maps.

I want to thank huppel for suggesting that mission, and everyone for reporting their crashes. I've finally managed to trigger a CTD using that mission, and it's probably the weirdest DCS crash I've ever seen. It's a mix of a very specific avionics setup, plus the environment, plus some static objects in the vicinity of the aircraft. But the key was some partially initialized static objects - like the oil rigs, gas stations, etc. That's why some of you experienced those crashes, while the other didn't - it was very mission specific. So at least one source of the CTDs is fixed. I can't guarantee that it was the only reason of the CTDs you got, but I can say that at least this one is going to be fixed for you on Wednesday.

That is indeed a bug. Thank you for letting us know about it. I've just fixed it so it should be available in the next update.

Could you post a screenshot of the VDI or HUD, please? Also, could you write the annunciator lights which are on before and after the repair, both cockpits? Quite possible that you are in AHRS/AM and the AHRS is just misaligned due to operations at >82° of pitch. In that case, could you press and hold for 3 minutes the HDS set pushbutton on the compass panel? It requires being stationary or in a straight horizontal unaccelerated flight.

The simplest answer to the question asked in this topic is that you can't switch between the RIO and the pilot seats in multiplayer because DCS doesn't support it at the moment, and it wasn't our design decision.

Hey! I'm sorry that the radar doesn't detect tankers for you. I've checked it on my end today, and the result is as in this picture: So as you can see, it works in our internal builds. To help you with your problem, and to help us understanding if there is any bug, could you try the location from my screenshot? Then could you send us the mission you used in your flight, the precise location of the ships that have no radar returns, provide us with some screenshots of your radar display for those ships, and finally describe all actions you took (step by step) to set up your radar? I'm sure we will find a way to make the ships appear on the radar display . Best regards Krzysztof

It's fixed internally. Today's patch is based on a build we submitted earlier this week, and it doesn't have that fix included. It should be available in the next build