Rongor

This also happens on my Virpil collective pitch grip hats and it seems to be a bad design of the mechanical contacts. It's simply hard to not accidently push the center down while moving the hat in one of its directions. As said, the only solution seems to not use (not bind) the depress input.

Yeah well, I am with you with the availability of these workarounds. Yet even more the question comes up then: what is the coords readout in the DED good for?

Maybe I missed something but isn't that accurate and also working like this since the release of the A-10C 10 years or so ago? exactly, isn't that working incorrectly? Should give only bearings...

Since we have the possibility to receive the approximate coordinates of an emitting site in the DED when working with the HARM Targeting Pod and display them in the DED, I wonder what to do with these. It would help to transfer these coordinates into a markpoint for example, yet I don't see how this would be possible right now. So my question for those who know: Might this be a real life feature which is waiting to be implemented in DCS some day? If not, how to put these coordinates to use in any way elsewhere? Using them as a Markpoint would be the obvious benefit...

The setting was a flight at night, where visual cues aren't available as much in target areas. So the idea was to locate the site by radar, set a markpoint there, so I could slew my TGP to that markpoint and start scanning for the targets from there, as the next steerpoint is way distant and there are no known target coordinates. Did this successfully the night before and form my memory I'd say the MAVs were on PRE then. I will try this out what you explained, also regarding the possible ECM interference, when I come home later. no worries. It's ok to bring this up. I didn't notice it so far when switching to TWS. Only in the case of making the HMCS SOI I immediately found it distracting, waiting for symbol to change until I lost patience and released the TMS.

A-G selected. Mavericks are powered on in the SMS format. RF up/NORM, FCR forward/on 1. I selected the ground mode in the FCR MFD. radar screen remained black, although I was flying across landscape, around 15000 ft AGL. Checked ECM XMIT wasn't on 2. switched ECM back to standby to be sure. Didn't cure it. Switched ECM back to OPR. Radar came alive. 2. after slewing around on the GM (radar MFD still as SOI), TMS forward to designate. Wanted to create a Markpoint at this location. So I pressed 7/MARK on the ICP. This switched SOI back to HUD, Markpoint DED page didn't receive any further inputs from TMS up. Displayed source in DED: 'HUD' 3. A-A selected, AMRAAMs selected in SMS. FCR is SOI. RWS mode TMS right long didn't switch to TWS as usual, no matter how often or long I pressed. All this happened while flying online. Any idea what I could have missed in any of these cases?

I agree, though in his two drops from 8000R and 14000B it still worked fine.

The laser will of course put its spot on the very location the TGP is showing in your MFD so what did you expect? It is to be expected that LGB will hit in this case. The laser doesn't care for the misalignment in your HUD and so won't the laser seeker in that LGB. I think we have understood the problem but you didn't really respond to the hints that were given so far. What exactly is 'the procedure' you now tried again? Explain it step by step or even better send a track. What about the Altimeter setting and INS alignment? Frederf asked if you are using some kind of mod. You didn't tell. Also cutting down your screenshots isn't helpful as many possible clues are now outside of the frame.

This isn't really evidence. We see the situation after release, so it doesn't matter if his TGP is tracking the target. As long as the SFW received the correct data at some time before pickle (which it apparently didn't somehow). He would have to tell us if he sent the data from a tracking TGP to the CBU before dropping. If he didn't, why did CCRP release the bomb? Only if the CCRP took the steerpoint or the target was designated with a different method (HUD). The misalignment of the TGP in the HUD is a hint, that even an evidently tracking TGP wouldn't have provided the correct data.

Set your altimeter to the QNH set in the mission. This is an everday procedure in real life aviation, if you aren't sure what this is about, you'll find plenty of stuff on this in the net. Think of QNH as the current meteorological pressure at sea level, calculated for your area. Due to weather, the QNH does change and has to be fetched and set into your altimeter for every flight, even during flights (if they take long or you transit into different regions, because weather may change during an hour and of course might be different in a region 100 NM away). You will find the value in the mission briefing. If you created the mission by yourself and didn't change anything in the weather settings, the standard 29.92 will do it. Take care to flip the little lever at the bottom right of your altimeter to ELEC and keep it there for some seconds until the indicators stop adjusting. At cold start, this lever may be on PNEU, which is kind of a backup solution only. Only then set the QNH value by turning the dial. Ideally do this before engaging INS alignment, or at least during the first two minutes of alignment, if you chose to go NORM alignment. If you don't know where to find your current QNH while sitting on the parking spot, look up your current elevation on the F10 map, then turn the dial until the altimeter shows this elevation. Radar alt and baro alt still will show differences, this is due to terrain of course. So in most cases your baro alt will be higher. On your pic it is the opposite, that is why it's obvious you didn't set it, as there shouldn't be any 1200 ft terrain depressions below sea level on any of the DCS maps.

Have the same problem, files attached I only flew the F-16 in these cases. I was busy with the TGP. dcs.log-20211229-223911.zip dcs.log-20211231-004429.zip

Can confirm this happens frequently. TMS aft on WPN SOI page is the only cure I came about.

This. And I reported it in this forum, so ED can save us the errand by adjusting the default config or tell us why they choose to leave it that way and eventually drop some lines about this in the manual.

It's nice you guys can explain how to adapt to the situation. If you had paid attention you would have seen I am not looking for workarounds. I have no idea how many time you guys waste to cancel a thread. The current default situation of the MFD configuration in both Override modes is a problem. It's possible ED simply didn't implement it yet in a reasonable way. Probably they didn't made their minds up what should still be selectable in the right MFD by default. We just don't know, until we can read it up in the manual. What we do know is that you guys don't care for ED to review this. Of course, ED keeping it as it is now would enable you to go on lecturing people how smart you can work around an issue like this. I understand that now.

As explained in this thread, wind currently can affect availability of ILS. This also leads to bug reports addressing specific maps. Yet it seems to be a more general problem instead. In many occasions, ILS is not available, as if there was no ILS at the airfield at all. Please fix and advise me how to deliver additional data, if needed.

As of today, ILS of Hatay still doesn't work. No indications on the needles. No morse identification.

The way you depict it here is totally misleading and is not suited for people actually intending to understand how TACAN works. TACAN doesn't operate on VHF. You can't receive a TACAN by converting its channel to a VHF frequency. This is a common misconception from this misinterpreted table. TACAN, DMS and transponders share standardized 2x126 channels in the frequency band of 960 - 1215 MHz. All these are basically some sort of secondary radar. It is a system of clients polling a serving station. The civilian DME is compatible to the ranging segment of the military TACAN and therefore uses the same freq range, stepping and (internally) channel numbering. To not have the civilian operator needing to enter DME channels, DME is usually incorporated into the VOR receivers, which work in the range of 108-118 MHz. When a civilian DME is constructed, often co-located to a VOR, the list you posted is the VOR frequency of a VOR which operates a DME on that respective TACAN-compatible channel. You are basically tuning your civilian DME receiver by tuning your VOR receiver to a VOR, which under the hood always looks for a DME in the list of DME channels corresponding to each VOR frequency. You can use that table, convert the TACAN channel to a VOR frequency which you can enter in your VOR receiver to then recveive the TACAN's DME segment. That is all. You can't do it backwards. A VOR frequency or even the presence of DME has no say if there is a TACAN. The fact that you have a DME channel on a map doesn't tell you if there is a TACAN present. Also a VOR frequency doesn't tell us, if there is a TACAN. In some cases TACANs are co-located to VORs. This would be visbile on a map by a special symbol, called a VORTAC. VORTACs enable civilian aviation to make use of the co-located TACAN's DME, so the operator of the VOR ground station at the same location doesn't have to errect a DME there. If the Israelis don't want the TACAN to be published (be it as DME or as a VORTAC), the map symbol probably wouldn't give this away and therefore the published VOR frequency gives us no idea if there is a TACAN at all. So why would the Israelis or anybody want to "hide" that TACAN? It's most likely not for security reasons but to keep the system running. TACAN, just like the civilian DME can only serve a maximum number of clients. If the station is saturated by polling clients, it can't handle additional queries. So the idea in a regularly busy airspace would be to keep the TACAN's serving capacity as high as possible instead of risking military flights not being able to use it because there are already 120 civilian flights using the DME.

After switching to dogfight override, you used OSBs to switch right MFD pages which is necessary because DMS doesn't do the job anymore. You are basically demonstrating what I described multiple times now. Well thanks so much for this vague comment. Again, it's known we can put them back. I am questioning the fact that selecting an override mode by default blanks out all other page formats, so that DMS doesn't affect that MFD anymore. The manual mentions that MFD getting switched to the respective SMS page. No where it is stated that other pages OSBs get blanked and for what purpose the configuration of the SMS page includes blanking out the other pages (so you can't use DMS on this MFD anymore as single and only effect).

probably this happened to me too then. Right after designating system targets, the Acquisition cursor likely rested over it, effectively having a cursor target. So this legitimately caused antenna control to stop. Solved for now. Thanks

I can confirm this. It's even in the manual. You can read it up there. DMS doesn't work on the non-FCR MFD while in any of the two override modes. This will regularly be the right MFD and in this case, DMS right. DMSright.trk

It's nice that you can setup your MFDs for the override modes. Yet this has nothing to do with the problem I explained. The problem's are: - DMS is not working for the non-FCR MFD while in Override - when switching to HSD using the OSBs on the non-FCR MFD while in Override, going back to SMS doesn't display INV under OSB 3, although pressing the OSB still opens the INV page. These may be bugs and deserve attention.

System tracks are not bugged tracks. The FCR isn't providing missile launch parameters at this point so there is no need to hand off antenna controls to the FCR. Designating a system target does nothing to the radar, it's merely a function the pilot can use to sort targets on his B-scope. The TWS is literally made for maintaining scanning while tracking, so if the FCR starts do take over after designating system targets, something might be wrong.

Just noticed that while in TWS mode, the antenna elevation can't be adjusted anymore as long as there is at least one target designated as system target or higher. Returning all contacts to track targets returns antenna elevation control. IN RWS SAM/DTT modes, antenna elevation control is unimpaired. I suspect bugs? Would expect antenna elevation fixed in STT. If it's correct to have it fixed for system tracks, probably should be fixed for SAM/DTT too?

Tried that, you are right. It would be nice to see that corrected and added in the manual then. The reader needs to know, that not acknowledging the LATLON will still countdown to 10 and yet this mustn't be interpreted as "well done alignment" and that the SALT in fact isn't edited by ICP input...

The line below the pic on page 144 claims: "In DTT, pressing TMS left will swap the primary and secondary targets". This is obviously an error. TMS right is swapping targets in DTT.