Ourorborus

Cheers, but I was referring to closed beta. Like most users I already use open beta. Besides, open beta is too late to help make a good ATC system, the framework is already set at that point and you are only looking for bugs. Just letting ED know there are some of us with expertise happy to help create something good.

As a real life ATC, Sim ATC has long been something that drives me mad. That said, I am happy to see if that nut can be finally cracked and would be happy to help out. How does one get onto beta testing for this?

+1000. I have the same issue in the F18 and the Apache. The problem is that HMD senses up/down tilt with its inbuilt accelerometers. DCS then takes that value as gospel, and places the HMD in the center of the view. Unfortunately due to different face shapes, the HMD may be tilted up or down slightly on your face, placing your personal center of view slightly above or below the absolute center of view. Thus the JHMCS/IHDDS displays slightly high/low. i.e if the HMD sits on your face tilted up 2 degrees from the "perfect" horizontal. the JHMCS/IHDDS will appear 2 degrees high in your vision. Re-centering while looking down/up doesn't fix the problem as accellerometers sense you are looking up/down. I personally wedge a small cloth between the top of my HMD's face cushion and my face as I have long given up on ED even acknowledging this problem let alone fixing it.

Like the idea of an "AP engagement Dead zone" as a different setting to axis dead zone.

So its not just me!!! I am also a VAICOM user so it could well be something between VAICOM and Huey. No issues in other modules, (F18, F14, Spit) For me It doesn't matter if I use VAICOM "OPTIONS" or a key bind the menu only shows once in about 20 attempts.

Some irregular drift in datalink is to be expected, As Big Newy stated, a datalink contact can be up to 12 seconds old. How long depends on many things and will vary constantly. Your own display shouldn't extrapolate a PPLI as this will potentially add further error to the position. Remember the PPLI is simply a position sourced from another aircraft, and has already been subject to track filters/extrapolation etc. Think of datalink as a type of LAN. The protocols/language differ but the concept is the same. Instead of Cat5/6 cable or wifi it is linked over crypto radio. So, 1. Aircraft A (AWACS/wingman etc) detects a track, the track is subject to interpolation to account for RADAR update rate. (e.g. time for AWACS RADAR to complete a 360degree sweep, wingman may have a wide 6 bar sweep etc....) 2.The information is encrypted. Anyone who has ever used crypto radio voice will know there is noticeable delay in transmission. So the data may be 1-2 seconds old before it even leaves the donor. 3. The data is broadcast over the network. This is a biggie. Unlike your home LAN, the network is subject to atmospherics, antennae shielding, changes in range... the list goes on. Try maintaining a wifi network between 10 cars on the highway and you will get the idea..... Now make those cars maneuver abruptly in 3d and fill the electromagnetic spectrum with multipe RADAR, UHF, VHF, ECM etc etc... 4. The data is received, decrypted and displayed in aircraft B (you). 5. Like all networks this data is constantly being refreshed, updated and transmitted to/from all participants... with so many variables is impressive that the delay is only up to 12 seconds.

I can adjust the left right alignment with a "VR recenter" keybind. In fact the recentre keybind works for 5 degrees of movement, forward back, left right, , up/down, rotate left right, but not tilt up down. That is fixed slightly high for me. For ED to replicate, it is NOT noticeable unless using an in game HMD display such as the F18 JHMCS. It is the JHMCS that displays high/low, not the whole VR picture.

Simplest way is to ignore the QFE on DCS ATIS, and just adjust your altimeter to read the airfield altitude on startup. That will give you QNH. Unless the mission has a very dynamic pressure system, that QNH will hold true for most 2 hour (or less) sorties. Particularly if you are operating in VMC below the LSALT. In real world application, you would set Airfield QNH, for arrival/departure, area qnh outside the terminal area, Force QNH within the AO, and if complying with ATC, 1013/29.92 above the transition altitiude. (Fighters tend to ignore this unless transiting/cruising outside the AO). These figures will update throughout the day as weather progresses (but not THAT frequently) However, unless the MIZ designer has provided all this info for you (either in briefing or by a script), setting QNH as indicated above before takeoff should suffice for 99% of missions in VMC, and probably 90% of missions in IMC.

Just let me clarify, you want ILS added to the hornet because you have no idea how to shoot a TACAN approach. Yet you somehow know of a super ILS that gives a "3 wire everytime"........ Please elaborate, I am interested how you can get a 3 wire off an ILS. (PS.You do know that airfields don't have a "3 wire" and carriers don't have ILS don't you?)

You are talking about ILS CAT IIIC. It has existed for a significant time in the civil world and permits autolanding. Implementation in a fighter may or may not ever happen given the cost/weight/maintenance issues required. When the rest of the conversation refer to TACAN etc, they are talking about the TACAN Approaches not just the aid. Any navaid can have an approach built around it, and these days you can have approaches built entirely around GNSS/RNP without any ground based aid. (Even the GNSS approach can be flown in the F18 although given the lack of a data cartridge is too cumbersome to program in to be useful.) The aim of any instrument approach is to safely descend an aircraft to a point where they can get visual and land. All a precision approach (like an ILS) gives over a non-precision approach (TACAN/VOR etc) is a glideslope and usually lower minima. While I would love to see the option for ILS as I am Australian and tend to replicate Aussie models which had the ILS, the ability to recover off TACAN, DME, and even NDB approaches is there, you just need to put the time in to learn how to fly them.

I know the HMD alignment system is simulated however it doesn't allow alignment of a VR HMD. When conducting alignment, the cross hair has to be put on the other cross hair. Unfortunately, this does not correct for VR headset alignment. To explain. The center of the HMD display is placed over what the sim thinks is the center of our VR HMD. However, if for example the VR HMD physically points slightly upwards on our face, the sim thinks we are looking slightly up, even though we looking straight ahead. i.e. the real center of the VR HMD is below where the sim thinks it is. Consequently to align the cross hairs during the alignment procedure the pilot has to physically tilt their head down. Once "aligned" the HMD display remains high within the VR HMD for the duration of the flight. (for me it is about 4degrees) The reverse would happen if the VR HMD pointed slightly down on your head. To replicate this issue, place two pads between your VR HMD cheek pads and your face to physically tilt it upward, and see where the HMD display sits in your field of view. Request a setting (even in a lua) to permanently/semi-permanently account for personal variations of VR HMD fitment.

I have been holding out on this until the conflict between real controls and leap selection is resolved. Thinking laterally, I wonder if there is a way to permanently inhibit any mapped controls with the leap motion. That way anything you have mapped to real buttons (HOTAS MFD etc) can be permanently inhibited and leap ignores them....

I also find that. But then I find altitude references a bit all over the place in DCS. I have never been bothered to crunch the numbers on the error but I always figured it was either the tanker was reporting actual (GPS/Measured with an infitiately perfect ruler) altitude sourced from the game engine as opposed to the pressure altitude displayed in my cockpit. Or it could be that the Tanker has listened to the ludicrous ATIS and set QFE instead of QNH. Either way it has never stopped me finding the block of flats in the sky.

Actually Primary and Secondary are different types of RADAR. Primary is the traditional form of radar where the signal is bounced off the target. In your jet this is the RWS/TWS etc. In ATC this is known as a PSR (Primary Surveillence RADAR). Secondary is the system that requires an active response. I.e the interregator and the transponder. In your jet this is the IFF. In ATC it is known as SSR (secondary surveillance RADAR). The SSR is the RADAR head, whereas the Transponder is the aircraft's component. A surveillence RADAR is one that has a wide (normally 360deg) but relatively slow scan rate, and can be PSR or SSR (often with both colocated). An attack RADAR is a form of primary radar but often has a secondary interrogotor added to use as IFF. Azimuth for both types is gained from where the head is pointing when the reflection/response is received. Distance is gained for both as a calculation of the round trip time for the reflection/response. It is possible to spoof and increased distance with secondary by introducing a delay to the response time. SSR does not normal return an altitude. Primary attack RADARs get altitude by using lobe interference and scan bars. PSR get altitude by the Mode 3C/S return. Secondary/IFF modes are: 1 and 2. Military use only. Numbers to be set will be in the ATO. 3 ATC (both civil and military). 3A returns four digit ID only. 3C returns a four digit ID plus barometric altitude. This is a pressure altitude and the SSR display needs to correct for QNH. 3C has been the standard for several decades. S ATC (both civil and military but mostly civil). Returns an aircraft iD and lot of information fom the aircraft FMS. This includes bank angle, autopilot settings, current altitude, IAS, TAS and whole lot more... 4 and 5. Military use only. Can be used for challenge and response by Anti Air weapon systems. To answer the original question. SSR/IFF is transmitted on 1030MHz and the response is transmitted on 1090MHz so yes it can be detected. (Some militaries can vary these freqs.)

Actually most ATC RADARs are only SSR but outside of the military they only use Mode 3C and Mode S. Primary radars are not used too often anymore as the ATC environment is cooperative. SSR also has better range efficiency than Primary RADARs due to the bean only goin out not out and back. Most Transponders, including Mode 1,2,4 and 5 tranponders fitted to miltary, have an interrogate light to show you are being interrogated.

Was so excited by this, but looking the vids I think I will wait until it can be inhibited for the controlls you actually have (i.e HOTAS and MFD)

very nice sir.

Sadly it doesn't appear to solve our issue :(. The alignment is to ensure a properly mounted HMD is aligned with the Aircraft. Unfortunatly the DCS implementation assumes our HMD is properly fitted even thought the "centre" is high for many in VR. Thus it still aligns high.

OK so I found my problem. Reducing field of view in WMR for steam totally messed up my eye allignment!. Back to 100% field of view and a quick copy left to right in the alignment tool and better than ever!

Until now my reverb 1 has been fine but randomly today each eye is all over the place in DCS only. Hence I tried this tool. It seems to me that the values generated should be the values stored int he device firmware. And they are jsut being misread by dcs. Is there a way to read those values off the firmware and just copy them into the lua?

If it isn't crosswind, check you don't have a second axis bound to rudder, or something bound to rudder trim.

There is also a Rudder trim axis that could be bound to something.

In fact to get us back on topic I will edit my post... Push forward. No I'm not being flippant. Almost every aircraft has an issue where trim for final is different to trim for takeoff. You have to allow for this in go rounds and, depending on the technique you were tought, during touch and goes. One school of thought is to priotise runway safety and trim upwind when you can do it by feel, like you do in a go round, another is to priortise upwind standardisation by trimming on the ground. At least with the hornet it will trim itself once flaps are up. As for the Hornet, (and I am happy to be corrected by those here that flew them for real) I believe they subscribe to the former school of thought. In a touch and go they barely strike the ground. In fact it looks more like "low go round". an example... F/A-18 Hornets • Touch & Go Training - YouTube

..and yet ICAO states runway safety events occur more than 4 times the rate of loss of control in flight events. And when they do occur are far more likely to result in hull loss...... Lets get back onto topic shall we?