Super Grover

It's * not ǂ The whole string is a BIT code. When it's close to "XXXXX *1 444" it means that everything is fine.

As I explained in the previous posts, it's highly improbable that what you experienced was due to the carrier's magnetic field. You don't have to wait 10 minutes to correct the compass readings after a catapult launch. You can fast slave the compass heading using the HDG push button on the COMPASS panel: number 5 here http://www.heatblur.se/F-14Manual/cockpit.html#compass-control-panel Press it with your LMB and hold until the SYNC indicator shows no deviation. It will work only when your wings are level, your speed is constant, and your vertical speed is zero.

Hey Bruce_D, I'm sorry that the kneeboard doesn't work as you would like it to work. Indeed your observation is correct, and the TACAN list won't show the stations/units that are inactive when you enter the cockpit. This is a limitation of DCS and the method used to prepare the list. The kneeboard can't predict all intentions of the mission creator, and it's not a substitute of advanced flight planner. It was also our intention to make it realistic - so it's not updated once airborne. However, we understand that the feature you're asking for is important for you and we will update the kneeboard if we find a proper way to include those late activated units on the list.

I'm sorry to read that you had troubles using the radios. There are multiple reports in this thread, and I can't get a consistent picture of what isn't working for you. Unfortunately, most of the reports don't contain enough detail to reproduce the conditions under which the radios don't work. Thus, I can't tell if something is a bug or a user error. The radios and radio communication may seem to be simple, but it's the opposite. Multiple options available (Easy Communication, F-14B radio menu special options), two radios and one intercom, and two sets of controls make it quite a complex system. Therefore, I need to ask you to include more details in your future reports related to the radio systems. Please describe all the actions you take in the simulator. Specify if you are using Easy Communication or not and if you use any radio related special option. Take screenshots, and if possible, please include the mission.

Hey Andrei, I'm sorry that the radios don't work for you. However, I'm quite sure that unmodded DCS can't show "VHF FM" in any radio menu of the F-14. The only possible options are "UHF ARC-159", "VHF/UHF ARC-182", and "ICS". If you're using "Easy Communication", then you can also have "AUTO". Thus, the only possibility that you have "VHF FM" is that one or more files are corrupted or that you are using a mod that replaced some radio communication files. Could you repair your DCS and remove all mods? Then, make sure that you're using standard controls for the radios. Launch your F-14 and stay in the pilot seat. Try opening the menus using: - RALT (Right ALT) + \ to open "UHF ARC-159" - RCTRL (Right CTRL) + \ to open "VHF/UHF ARC-182" - RSHIFT (Right SHIFT) + \ to open "ICS" - \ to open "AUTO" - but only when using "Easy Communication". If any menu title is different, please, take a screenshot. Try communicating using the radios, remembering to set correct frequency. When using "Easy Communication", you can skip frequency tuning, and use "AUTO" to select the station you want to communicate with - the frequency will be set for you automatically. Also note, that some of the bands on the ARC-182 use manual modulation (AM/FM) settings. Finally, ensure that the AI units have correct frequencies assigned in the mission editor - otherwise, you may be unable to contact them. If this doesn't work for you, please describe in details all the steps you take in DCS to setup your radio. If possible, please include screenshots showing your radio display and radio menu. Finally, please write if you're using "Easy Communication".

There was a bug in the code which loads mission editor settings. It's corrected now in the open beta branch. However, a part of the behaviour which you observed is still valid. Imagine a situation in which you loaded 60 flares and 0 chaff, and you don't use LAU-138. In this case, the correct settings for your ALE-39 are: L10 - F, L20 - F, R10 - F, R20 - F. You can always check what is the correct settings in your kneeboard. Now, you (as the RIO) use the chaff switch to release one chaff. It does nothing because no ALE-39 section is marked as chaff. Imagine that you don't change your loadout but you set L20 to C on your panel. You press the chaff switch again, and the system releases one flare. It's because the system is not aware of the actual loadout and it uses the settings dialled on the control panel. You commanded to dispense one chaff, but the only section marked in the programmer as containing chaff is L20, so the sequencer sends one release impulse to that section, and the dispenser ejects one of the cartridges loaded in that section. And all cartridges in that section are flares, so it releases one flare.

Hey! Thanks for reporting your observations. @|DUSTY| I've checked HAWK online, and indeed sometimes it gives no launch indication. I investigated it further, and it looks that sometimes in multiplayer you can be tracked by multiple subsystems of one SAM system. In such a situation, the first strongest locking subsystem may be not the subsystem engaging you with a missile, and we are checking for the missiles guided from the strongest lobe. I've corrected this by checking all subsystems and not only the strongest one. Should be available in the next update. Side note: "sometimes" in my case was 10-20%. For 80-90% it gave correct indications. @mattag08 Now, "U" should appear only for some unknown types, not in the database. I checked it online and offline today, using the latest open beta, and it worked correctly. However, I found that the HAWK CWAR radar wasn't in the database, so I added it. I think that multiple "U" you got was because of the mission (maybe spammed with CWARs ?) and not the RWR.

Thanks for the reports. I tried Eclipse twice using a debug build so I could get more info should it have crashed. But it didn't. Hard to tell what caused the crashes for you and if it was the F-14. However, we will keep testing, and of course, crash logs that you will send us may help.

The simplest answer is that we emulate lobes (main and side) of radar beams for all AI units. It should reduce the distance at which the ALR-67 will inform you about being locked or about a missile launch when you're in a side lobe of a radar tracking another aircraft. It has been discussed in this thread: https://forums.eagle.ru/showthread.php?t=237416 and some other RWR threads.

Thank you for reporting this. It's fixed now internally. It will be available in the next update (not today's update). It also closes these bug reports: https://forums.eagle.ru/showthread.php?t=236268 https://forums.eagle.ru/showthread.php?t=236289

The ICS PTT button works as an additional Jester menu toggle button only when flying with Jester (so not with a human RIO) and when the special option 'OPEN MENU: RADIO MENU KEY FOLLOWED BY PTT (SRS PRIORITY)' is selected. To open the ICS radio menu with this option selected, you should press the radio menu key (default '\') and follow it with the ICS PTT key/button (default Right Shift + '\').

Today, I committed a change which adds the functionality you asked for. It will enter one of the next updates.

Well, when using WIDE FOV, there's no wider FOV, so that it will drop it. But it should switch from EXP to NARROW, and from NARROW to WIDE. At least it did it when I tried it for the last time.

Thank you for these kind words. I'm glad you like the LANTIRN Yes, you described it precisely. The object you want to POINT track must be of a proper visual size - not too small and not too large. It must be easily identifiable - the background can't be cluttered with other hot objects. So it will lock on a single building or a tank in a field. But it may be unable to initiate POINT on a building in a city or a vehicle hiding in an urban area. The pod monitors track quality continuously, so you may successfully start tracking, but then the track may be dropped because the view has changed. The pod will automatically switch to a wider FOV when the tracked object becomes too big to fit the frame.

During development of the LANTIRN, I watched probably all GBU delivery video available. Almost all used manual lasing. And I remember maybe only one or two in POINT, the rest in AREA. My observation is that auto lase works quite well in DCS for stationary targets when the pilot is precise in following the release cues from the LANTIRN.

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.