Super Grover

Yes, I'm going to revisit the CMS procedure soon and make it more intuitive. The current version is a workaround for the rearm panel not having our custom presets, but it's too easy to end up with a wrong setup. I'll let you know about the results.

Thank you for the information. I'll try replicating it on that server.

Thank you, JupiterJoe. A quick check of the logs suggests that it might have been something else than the F-14, or if that had been the F-14, it wasn't caused directly by the module. I'll take a look at the latest changes and see if there's anything suspicious. If, by chance, you find a mission where it can be consistently reproduced, I'd be thankful for dropping it here or pointing to a place where I could download it.

DCS offers ability to mission creators to shape the coalitions to their needs. For example, it means that an F/A-18 from USA can fly against a Canadian F/A-18. From the electromagnetic signal point of view, it's impossible to distinguish between the two, so we decided to use the following procedure: 1. We check the mission content. For each known emitter type, we record the countries (sides) which have at least one unit of this type in the mission. 2. In the second step, we create a custom threat library for this mission. If a given type is present only in the friendly forces, the type is marked as friendly. 3. When an EM signal from a known emitter is registered, it is compared with the threat library. If a given type is known as friendly, it will be displayed only when locking you or when the RWR is set to prioritise friendly emitters. If a type is not registered friendly, it is always displayed using normal prioritisation rules. Let me explain it on an example. Mission A: US F-14 vs Iran MiG-29 (only those types are present). All F-14 will be treated as friendly. Mission B: US F-14 vs Iran MiG-29 and Iran F-14. All F-14 will be considered as potentially hostile and all F-14 will be always present on the RWR display. This way we try emulating threat libraries prepared and uploaded to the RWR based on the current geopolitical/theatre of operation situation.

Hey JupiterJoe and lax22, I'll investigate it more closely. Could you provide more details, like what options did you select and what was the flight state? Also, if possible, could you upload your DCS.log and the mission if available?

When INS alignment starts, it initialises its position to the current hook waypoint or the own AC (if hooked). If you hook anything else or a waypoint that hasn't been initialised, the INS will reset to zero. That's only one possibility, but this is the first thing that comes to my mind. If you experience it again, could you share the mission and describe precisely all mods you used and the steps you took so that I can recreate it.

Hey Salty, Did you enter your coordinates before you started alignment or after?

Thank you for reporting this. I'll take a look and fix it.

One thing to note: the AHRS power doesn't require the WCS to be powered. In other words, and simplifying it: the AHRS is on whenever the electrical system is working (powered from a ground power source or the generators). And it means that probably your AHRS keeps spinning when you re-arm and repair so that it will be slowly erecting to the proper horizon position, but it will be much slower than when you do it from a cold&dark situation. Pressing the HDG button on the COMP panel should make it a bit quicker.

Thank you for your observation. Please consider an alternative (and plausible) sequence of events: 1. The INS or the IMU got damaged, the system switched automatically to AHRS/AM. 2. The main source of your attitude is now the AHRS, and it feeds to the HUD/VDIG. 3. During your flight (even before the INS/IMU got damaged), you hit the pitch limits for the AHRS (<82° up or down), and your AHRS tumbled a bit (or more if you did it several times). That's why your horizon isn't level any more. Even when nothing is damaged and manually switch to AHRS/AM and do some loops, you'll observe the same effect. After some time spent in a horizontal unaccelerated flight, it should return to the right position. Pressing the HDG knob/button on the COMP panel may speed up the process. 4. You land and hit repair. The INS and the IMU are fixed now, but the mode is still AHRS/AM as the system never automatically returns to INS after detecting a failure. 5. The AHRS gyros are still spinning, so they don't erect to the upright position that quickly. The result is that you still observe the skewed horizon line from a misaligned (but not broken) AHRS. 6. The IMU and the INS can be used since they are no longer broken, but their state is a complete mess. They need to be reset and realigned from the beginning. I'm not saying that for sure there's no bug. I just wanted to show that it's a complex thing, and we need to understand every detail before we identify the problem. I'll be happy to answer to your questions, and I'd greatly appreciate if you assist in understanding this issue.

Hey DoorMouse, Next time your INS fail, could you note precisely what steps you took to repair and restart? I know that the code for the repairs exists and should be working, but maybe we're missing something here. Please note that both the IMU and the AHRS may require re-alignment/re-erecting, and this may require some time.

Resetting counters is just for RIO to track the number of countermeasures left. The most important action is to reset the programmer - hold the reset switch in RESET for at least 5 seconds. From the manual http://www.heatblur.se/F-14Manual/general.html#programmer : Jester does it each time after reloading the launchers and taking off.

The resolution is limited by the pod not by the display.

Hey Bestandskraft, It often happens that the NAVAIRs are imprecise, and this seems to be the case here too. Indeed, the TACAN transmitter/receiver on the F-14 didn't have a dedicated bearing/beacon antenna installed. We checked more detailed specifications and diagrams. The conclusion was that when a valid bearing signal is received, it should be displayed, as it didn't require any additional processing versus land-based TACAN.

VC is the magnetic variation calculated inside INS/AWG-9 - the program takes the magnetic North from the AHRS and the true North from the IMU/INS, compares the two, and the difference is the VC. However, on a carrier deck, the magnetic North reading can be severely affected by different sources of the magnetic field, and hence the difference can get beyond that 2°. Once airborne, the VC should slowly recover. Or alternatively, to speed up the syncing process, the pilot can press and hold the HDG pushbutton on the compass panel. One thing to remember - the aircraft must be in a straight unaccelerated flight, otherwise the acceleration gate wouldn't let the sync happen.

Yes, POINT can be initiated only in WHOT, and it is not a bug. However, once POINT is engaged properly, you should be able to switch to BHOT, and again, it's not a bug :) .

Hey Ramsay! Actually, you weren't precisely on the radial 117° (297°) but probably around 118-119. The deflection needle isn't accurately aligned, and the direction to the TACAN station (that little arrowhead) is slightly shifted to the right from your heading. You are right that the sensed magnetic north direction and the declination shouldn't affect TACAN radial readings. However, we the TACAN itself has some limited accuracy, and according to the specification for the AN/ARN-84(V) the error can be as large as between 0.5° and 2.0° for the digital bearing and between 1.0° and 2.5° for the analogue bearing. The error depends on the strength of the signal received. We measure the signal reception, and we model the errors, so it is possible that in your case that's the reason for the difference you observe. BTW these TACAN bearing measurement errors are the main reason why TACAN fixes for the INS may introduce INS errors even more significant than before the fix.

Thanks for the report. I'll look closer, what can explain your observations and if the system behaviour is correct. However, I have to apologize that my schedule for the next week is full so it may take me a little longer. I'll let you know when I have something on this.

Thanks for the comment. The display MODE switch doesn't work as a filter, but it is used to prioritize threat categories, as indicated in the manual http://www.heatblur.se/F-14Manual/general.html#controls . It means that it may impact what is displayed only when the total number of threats detected is greater than 15, or greater than 6 in LMT. I hope this short explanation helps. Please, feel free to ask more questions if something is unclear. Also, if you still find that some RWR behaviour is a bug, please provide us with a more detailed explanation of what you observe and what is the behaviour you would expect from the device.

Also, check if there's only one carrier using ICLS - if there is more, the signal from them may interfere and result in unstable ICLS signal or even make tuning the ICLS impossible. The longer version of this story: it is possible to have multiple carriers using ICLS, but remember to set different channels to the carriers sailing close to each other. Additionally, please remember, that channels that are 10 channels apart share one frequency, so two carriers operating together and using channel 1 and channel 11 respectively will also make ICLS operation disturbed or impossible.

888.888 is displayed in the test position. Try lowering the brightness a bit.

Yes, POINT can be established in WHOT only. Or rather, to be more precise, it can be engaged on objects that appear white on a dark background (no matter if it's WHOT or BHOT). Once POINT is successfully engaged, it should be possible to change the polarity. However, due to the limitations of the simulation, it is simplified to: you can go into POINT only in WHOT.

Quite possible. You can try using a wider field of view. Hmm, I'm not exactly sure how area track works technically, but if you try to area track a position 100m next to a ship, with the ship already being on camera it might use the ship as a reference. I'm entirely specualting here though. Yes, that's how it should work. Under good weather conditions, the area track should always work when used on the ground (within some reasonable distance), and over water only if there's another contrasting object or shore visible and close to the cross. This required some tuning, so if you find a situation when the tracking should work but it isn't (or shouldn't work but it is), please send me a screenshot, and if possible the mission, and I'll re-tune the algorithms. Of course clear weather only.

In the INS mode, the two headings - the true heading from the INS/IMU and the magnetic heading from the AHRS - are completely independent and never synced. They are used together to calculate the magnetic variation value.

First of all, the AHRS can't be considered as a reliable and precise enough source of magnetic heading, not mentioning true heading which for which the performance is even worse. That's why the "MV" acronym appears on the TID only after the difference between the calculated magnetic variation, and the entered magnetic variation is greater than 5 degrees. Entering own heading is useful when performing an in-flight reset of the IMU. The procedure is to: 1. Set NAV MODE to OFF. 2. Press PRGM RESTRT (not simulated yed). 3. Set NAV MODE to IMU/AM. 4. Fly straight and level for 3 to 5 minutes. 5. Enter own true HDG. 6. Enter winds. 7. Enter own LAT and LONG (from wingman, carrier, AWACS). The INS mode would not be available, but it should allow using the IMU/AM. Answering Looney's questions. A. Why does the INS calculates a groundspeed when own aircraft heading is set to, in this case, 62 degrees? I may have an idea of the reason for such a high ground speed drift, but it's difficult to say it for sure without seeing the debug data. However, I can try explaining it. Earth rotates at a rate of 15° per hour, and Earth surface (with aircraft parked on it) moves at ~600 kt (for latitude ~45°). The INS must adjust for such a movement, and accounts for it in the algorithms and applies necessary corrections to the IMU platform. When you input a wrong heading, the INS applies wrong corrections, and the IMU is not levelled correctly any longer. In consequence, and the INS starts sensing gravity as a false horizontal acceleration, and it starts drifting very quickly. With own heading error of 62°, the INS mixes East-West with North-South so heavily, that it can easily result in false ground speed readings at the level of Earth surface linear speed. B. Why didn't the system switch over to a backup mode as the GS and TAS units it got were vastly different? The INS itself has limited means of detecting a failure like this. GS and TAS can be (and usually are) different because of wind. And wind can be as strong as 100kt (this is the wind speed at FL300 over the Great Lakes from today). Of course, 600kt is much less probable :D, but we have to remember that it is a system from the early '70s, and it required a bit more attention from the operator when compared with modern INS.