Super Grover

The magnetic flux valve alone is even simpler than a normal compass we know from the GA aircraft. In opposition to a normal compass, it is not balanced so will show the magnetic north only in horizontal flight. On the other hand, it is unaffected by acceleration errors because it has no moving parts. It doesn't have to be balanced, because, in normal operations, it is gyro stabilized. When in a level flight at high AoA (let's say 15 units), flying east or west, the magnetic flux valve behaves like a whiskey compass would behave when decelerating: it turns south - hence your observation. However, when flying north or south, it would turn much less or might even not turn at all. It is because in a nose up attitude, the flux valve is tilted back against the horizon, just like a whiskey compass when decelerating. As I wrote above, the magnetic flux valve output isn't presented directly to the crew - in normal operations, it is gyro stabilized in the AHRS. When flying low AoA, it should show more or less the correct magnetic heading. When you decelerate and fly high AoA, it will slowly align with the erroneous magnetic heading from the magnetic flux valve. In our F-14, we simulate the magnetic field declination and inclination, the magnetic flux valve, the AHRS gyro stabilization and the AHRS slaving rates. Hence, you should be able to experience all imperfections of the magnetic field sensing devices; and as we can see you are experiencing them :). If you are curious and want to check what happens internally, you can switch to the backup modes which expose some of the raw measurements. You can switch the HUD and VDI to use the AHRS as the attitude source. Just switch the NAV MODE selector (number 12 here: http://www.heatblur.se/F-14Manual/cockpit.html#tactical-information-display-tid ) to AHRS/AM. Then, if you want to present the magnetic flux valve output, select COMP on the compass panel (number 4 here: http://www.heatblur.se/F-14Manual/cockpit.html#compass-control-panel ) - your HUD, VDI and BDHI will use the MAD output directly. For those, who want to dig more, two links for a smooth take off: - A few words on Earth's magnetic field, and magnetic dip: (sidenote: the magnetic dip for the Caucasus is ~60° down) - A short introduction to magnetic compass errors:

It's quite complicated. There are a few reasons why your magnetic heading could have been that wrong. Did you take off from a carrier? If yes, then probably you got some initial error on the AHRS directional gyro -> error in the magnetic heading in SLAVED mode after launch. Even if you do nothing, it should return to normal after a while (much longer while), but you have to fly level and constant speed (and flying constant low speed in the F-14 is a challenge). The magnetic field from the carrier decays really fast with distance from the ship, so I don't think it could cause that. Plus the magnetic heading is gyro stabilized (in SLAVED), so even when you do a really close fly-by, it shouldn't impact your magnetic heading. Then, there's the magnetic flux valve (Magnetic Azimuth Detector - MAD) in the vertical tail. It's fixed. It feeds the AHRS with the relative direction of the magnetic North. When you roll or pitch, it becomes sensitive to the vertical component of Earth's magnetic field. This means - it becomes erroneous. That's why the directional gyro slaves to the MAD only in horizontal flight. At least in theory. In practice - you fly constant speed in a nose up attitude or with some hardly noticed bank for long enough, your directional gyro will slave to a slightly erroneous magnetic North. That's why it's important to observe the HSD and the TID for the MV acronym (magnetic variation). It is displayed alternately with the IN or IM when the difference between the computed magnetic variation (MC) and the manual magnetic variation (VM) is greater than 5°. If your directional gyro/synchro is shifted, it may result in erroneous interpretation of the TACAN direction on all instruments. You might have the carrier straight in front of your nose, but the BDHI will show the TACAN a few degrees to your left or right. However, the radial (bearing) reading would be correct; it would be just your magnetic heading wrong. And there's much more... :)

Thank you for your reports. Aaaaand it's fixed now. :) It'll enter one of the next updates (probably not the closest one).

Thanks for your observations, VampireNZ! There's nothing to worry about. It looks that everything is ok. - X and Y share frequencies in A/A, and DCS tunes TACAN channels by the frequency. - We use custom code to simulate the TACAN navigational set AN/ARN-84(V), which includes tracking, signal processing, logic, error modeling, and failures. What you described is probably related to the device memory (8-10seconds) of a tracked signal when the signal has been tracked for long enough. During this period, the last valid measurement will be displayed, even though the signal isn't present any longer. A very similar logic is applied when you start tracking - the device has to receive the signal for a short while before it starts displaying it. For further details on tracking, errors, timing and everything else, please refer to the specification of the AN/ARN-84: MIL-N-81207A.

It's not entirely a bug. The radar beams could be narrower, but yes, your RWR will show some false information, because it doesn't inform you that you are locked or there's a missile flying towards you. It rather tells you that it is sniffing a radar wave which it's recognized as a lock, or as missile guidance, or whatever the EM signal is. The target of this radar signal might be someone else and you might be in a side lobe, or you might be hit by a signal deflected from something. I recommend this thread: https://forums.eagle.ru/showthread.php?t=237416 The bottom line is: it's ok but it will be even more correct/realistic with the new beam shape emulation we will introduce in one of the next updates. And finally some important words about the RWR:

"When the anticollision lights are on, the flasher for the position lights is disabled and the lights revert to steady." Please verify that the anticollision lights are off.

For those who can't live without the accelerometer, I'll add, that the location of this gauge will be different in the F-14A. You'll find it where the radio repeater displays are in the F-14B - so much higher than now. The right side of the instrument panel was rearranged with the introduction of the ALR-67 (AFC 794 upgrade). The ALR-67 took the place of the radio frequency repeaters; the repeaters moved up and pushed the accelerometer to the place you know well from our cockpit. I bet the pilots appreciated the modern RWR more than they were disappointed with the new location of the accelerometer .

The jammer works as for any other DCS aircraft. The only thing missing is the audio output - we're still working on it, and it will be added at a later time.

Thanks for the report, and I'm sorry that you experienced those crashes. I reviewed the updated again, and I've found a typo that causes that trouble for you. Should be updated in the next F-14 update.

I thought that I could mention another functionality of our RWR that some of you may be unaware of. In real life, the RWR uses a threat database containing different radar emitter signatures, the associated symbols that are displayed to the crew, but also defines which radar systems are friendly and which are used by the enemy. In DCS, the selection of units available to both sides is often fictitious, so assuming that NATO/US aircraft/SAMs are always friendly, and Russian aircraft/SAMs are always the bad guys would be impractical. Instead, we decided to use per mission created threat databases, which are automatically generated when you enter the F-14. If a given type is only used on your side, the type is marked as "always friendly", and it's normally hidden from the display in the non-lethal and lethal rings. However, it will be still displayed in the critical ring (lock or launch warning). If you need to display all friendly emitters, the RIO can use the DISPLAY TYPE selector and switch it to FRIEND. http://www.heatblur.se/F-14Manual/cockpit.html#radar-warning-receiver-panel This way, your RWR should be less cluttered from the harmless emitters. However, when a type is present on both sides, all units of this type will appear on the RWR display - both friendly and hostile.

Certainly worth adding!

Hey, Thanks for informing us about the issue. Indeed there's a bug in the loading CMS options set in the editor. It's already fixed internally and should be available in the next update. I'll use this thread to present the correct procedure of using the ground crew to change the ALE-39 loadout. When rearming, you mustn't change the flare/chaff selection from the default DCS rearm window - if you change it, the system may not work properly. Instead, you should use your ICS radio menu and: 1. Select "F8. Ground Crew" 2. "F6. Select AN/ALE-39 Loadout" 3. Choose the option you need. 4. The radio menu will close. Open it again. 5. Select "F8. Ground Crew" 6. Select "F1. Rearm & Refuel". Choose your weapons, fuel, and paint scheme if you want. Don't change flares and chaff. Click OK. 7. Your selected AN/ALE-39 loadout will be ready when the rearming is finished.

Jester X/Y is fixed internally. Should be available to you soon. Cheers.

We plan to apply it to all SAM systems.

But you are aware that everything: - the antenna radiation pattern, - the threshold at 100 NM, - the 15 NM distance are just a made up example? And that I selected those numbers to match your -15db nicely?

I mentioned the distances for a reason - the long distances of operation force the radars to be very powerful emitters. I will give you an example using your -15db. As you calculated, it is 0.03. Now imagine that the law governing your device follows the inverse square of the distance from the emitter. Your device can detect the main lobe of the emitter from 100nm. At that distance, the -15db side lobe will be below your detection threshold. Now, let's position your device at 15nm from the emitter, in the main lobe. The signal is (15/100)^-2= 44 times stronger than before. 44 times stronger than before means 16.5db. So when you move to the side lobe at 15nm, your received signal will be equal to 133% of the signal you received in the main lobe at 100nm. So certainly above the threshold. But you are in the side lobe at 15nm. Your device has no means to know if you are 100nm from the emitter in the main lobe (and maybe you are the target) or 15nm from the emitter in the sidelobe. And that's only a small part of the full picture.

Hey Tomsk, Thanks for your involvement and all your effort in explaining your problem. I appreciate that you want to make our product better. However, you got some points wrong, and you come from some false assumptions which make your conclusions wrong. First, I've never written that we model the beams as 10-15 degrees wide. We don't. At some point, I might have written that some of the SAM systems use quite wide beams (true for some older systems), as wide as those numbers. Currently, the beam size is governed by DCS or module owner, and usually, it's wider than that, and we cannot control it. Over the next weeks, we will introduce our custom enhanced emulation of the main and side lobes which should improve the beam modelling. As stated in the preceding posts, the electromagnetic wave generation and propagation isn't simple to understand. The radars have to work at really long distances, where some of the equations are inversely proportional to the square of the distance or even the fourth power of the distance. The amplitudes change drastically over the range, and the numbers of decibels (note: decibels not decibals) you mentioned are easily reached when compared something that is close and something that is far. It's really complicated. I'd love to bring you our algorithms and explain the mathematical models that stay behind them so that you could verify them on your own, but unfortunately, I can't because of the obvious confidentiality reasons. Probably, it would also be quite exhausting and boring to get through them for most of the readers. Hence, I must ask you to trust us that we really know our job and that we have enough education and skill to do it right. Nevertheless, you're right with one thing. We should never stop chasing for perfection. And that's why we're preparing an update or a series of updates containing our custom beam properties modeling that I mentioned before. I hope you will appreciate them, because our main goal is making the RWR as realistic as possible, given all the limitations of the platform. And realistic quite often means imperfect. Best regards

That's the world of the EM warfare. The RWR is not a crystal ball or a magical box that knows which missile carries a death wish with your name on it. And radar antennas are no lasers. To detect a target, a radar has to emit quite significant energy in the form of an electromagnetic wave. The wave has to travel to the target, and then back to the radar antenna. It means that the signal that returns to the radar is much much weaker than the signal at the target - the signal that the RWR can receive. And that weaker signal must be still intensive enough for the SAM to detect the target. So the signal at the RWR, in a typical situation, is quite intensive even at longer distances. However, there are situations when the RWR can receive faint signatures from a lethal threat. So choosing which potentially lethal threat ignore and which keep is very difficult. And usually, it's better to be conservative and warn about more threats that aren't lethal than to miss that one missile that wants to hunt you down. Add to that that no antenna is perfect, and it has multiple side lobes - and the RWR can't tell if a signal received comes from the main lobe or a side lobe. As Victory205 wrote, this is just scratching the surface. Now let's return from those theoretical considerations to our DCS World. The good news is that we found a way to emulate the main/side lobe shape for the SAM threats using some fancy in-house developed techniques . Additionally, we added some additional custom corrections to the guidance signal strength which will improve the simulation at longer distances. Now it's as real as it gets. Does it make the RWR more selective? At very long distances, it makes the situation a bit clearer. But the closer you are to a SAM, the more prone to fake launches the RWR becomes - and the result it's similar to the current state you have in the sim. Because the SAMs are just huge glowing electromagnetic lanterns.

It's controlled by the RIO with the FLARE MODE switch - in any position other than PILOT, the DLC/CMS will launch chaff. You can ask Jester to set the FLARE MODE switch - it's one of the options in the defensive submenu.

Thank you all for the reports. We want to support all possible display configurations, including 4k and multimonitor setups. We started using custom UI position and resolution when we corrected the menu position for multiscreen configurations. However, it appears that DCS returns lower UI resolution when the UI scaling option is set. We're looking for a solution that will correct the menu size and positioning for the 4k setups, but keep the same functionality for the multimonitor configurations. I will let you know when a fix enters internal tests.

"ECM Jam Toggle" from the pilot settings does nothing. Probably it was used in the very early prototyping stages and slipped into the release unnoticed. It's removed now. Thanks for spotting this!

Jester inputs all mission waypoints after he finishes entering the aircraft position. From the pilot's perspective, this may look like entering own coords because the pilot can't see which waypoint is hooked. Also, after Jester switches to INS, he verifies that own coordinates are correct.

Thank you for testing and letting us know about the issue. We have identified the cause of the crashes, and we are testing a fix now.

It should work that only when you see ground you can go AREA or POINT (remembering all additional conditions for POINT). Even fog and dust should work correctly (I tweaked that some time ago), but apparently something has changed. I'll take a look soon. Clouds will block the view, so they also won't let you engage tracking.

And as suggested above, if it still doesn't work after checking the points from my previous post, please check it with the default clear weather. The algorithm for visibility calculations have been tested in different conditions, but it's almost impossible to cover all scenarios. Also, the weather in DCS is continuously tuned and improved which may affect the LANTIRN too - some algorithms tweaked and tested a few months ago may be slightly unoptimized for the current conditions. If you find any weather-related anomalies, please let us know, and we will improve the visibility handling for the given conditions.