Bear21

There are two very similar threds on this subject, I repost what I posted there; There is an open text that describes a "hypothetical A-A missile seeker " here https://digital-library.theiet.org/content/books/10.1049/sbra024e_ch18 I have this document, I can't publish it here as it's a pay doc. But it gives all the parameters for an A-A radar seeker of the type we discuss here, info such as angular, range, doppler gates etc and as I understand it the person who made the example knows what his is doing. It's a generic representation of how A-A radar missile seekers are made today, i.e. an AIM-120 C or D, Meteor etc, but it's information is not classified as it approximates all but describes none.

There is an open text that describes a "hypothetical A-A missile seeker " here https://digital-library.theiet.org/content/books/10.1049/sbra024e_ch18 I have this document, I can't publish it here as it's a pay doc. But it gives all the parameters for an A-A radar seeker of the type we discuss here, info suh as angular, range, doppler gates etc and as I understand it the person who made the example knows what his is doing. It's a generic representation of how A-A radar missile seekers are made today, i.e. an AIM-120 C or D, Meteor etc, but it's information is not classified as it approximates all but describes none.

There is a description on how the AIM-120 behaves when e.g. TWS track is lost or STT lock broken and the one-way datalink updates via the radar goes missing in the otherwise excellent Hoggit F-18 resource. Here the quotes with link: https://wiki.hoggitworld.com/view/F/A-18C#AIM-120_AMRAAM "Inherently, the AMRAAM is a partially "fire and forget" missile in that once it acquires the target with its own Radar (termed the "Active" phase), maintaining the target Radar trackfile is no longer necessary; " This is incorrect, you don't HAVE to support the missile once it leaves the rail, the aircraft MC has stored a 3D target space vector in missile memory before launch that tells the missile computer how to calculate the predicted intercept point (given target doesn't maneuver) and its INS tells the computer the missile 3D space vector at all times. The missile autopilot then flies the missile based on this information to X nm (Pitbull distance) of predicted intercept point, where the missile radar searches for the target. If the target has changed course during time of flight the probability of finding the target is reduced. But the missile flight path shall not be affected. A datalink update of the target 3D space vector will affect the missile flight path, however, if the resulting calculated intercept point by the missile computer is changed. The missile will at all times fly to the latest predicted target intercept point, based on the target 3D space vector info it has stored. This is not what the Hoggit text says: " Post-launch Datalink continues until the missile enters the "Active phase" at an optimal point automatically. A Time to Active (TTA) cue is provided to the pilot as explained below. If the target trackfile is lost prior to this point, the missile goes Active prematurely." This is incorrect, the missile does not open the radar prematurely when the datalink update goes missing. It continues flying to the latest intercept point it has (this is verified information). If this is indeed the DCS implementation it's wrong.

We shall be happy the fence-in priming of the TWS in AUTO works. With the absence of the RAID switch and the incorrect stowing of the TDC this is our way out of the situation for now. As an ex fighter pilot I fail to see the usefulness of the MAN mode? Please tell me it's benefits. The only instance that has 100% info on the present L&S/DT2 track vectors and how these relates to the alt/az scan limits is the radar processor, thus it's the most fit to guarantee the tracks are active when I launch the AIM-120 and that the track remains after launch until ACT=0. As Mo410 writes, MAN is seldom used and for good reason.

There is a way around the present DCS RWS to TWS change where MAN is default together with a non correct DCT stowed position (which focuses the TWS scan on the wrong azimuth until TDC is moved over the targets). At fence in go RWS>TWS (it doesn't matter there are no bricks or tracks or set L&S/DT2 in LTWS) and set AUTO. RWS to TWS now defaults to AUTO in switches going forward. If L&S/DT2 is not set in LTWS, AUTO tracking doesn't activate until it's set. The main benefit is then it prohibits the MAN with a stowed position of the TDC. The scan now stays where the scan was in RWS before the switch. If you set L&S/DT2 using LTWS you have a functional AUTO track from go in TWS.

I reported to BIGNEWY that an F-18C pilot told me the stowing of the DCT at RWS>TWS is incorrect, it shall not move.

"TWS manual is seldom used". as an ex fighter pilot I understand this fully, if you want to use F-pole and other manouvers it's almost impossible to nanny a MAN TWS and fight at the same time. This is where a radar processor that has all the info anyway (it has the trackfliles) does a much better job. In the present DCS implementation it's worse as the TDC, around which the MAN TWS scanes, gets stowed when the TWS mode starts.

The present RWS to TWS into MAN mode via RDDI5 shall leave the TDC as is, not stow it, as this is the correct APG-73 implementation. With the present incorrect implementation, the RWS to TWS change corrupts the radar's track file, see appended track file. 2021.03.29 F-18 vs 7 Mig29 targets 2kft to 40kft.trk

A-A radar RWS to TWS mode change is missing its main implementation, the HOTAS command via the RAID button, commanding TWS in AUTO mode. Why is this the main implementation? The F-18C has this on HOTAS = main command mode. RDDI5 (RWS>TWS in MAN mode) requires the pilot to take hand from stick to engage mode = less prioritized alternate method. As this is a non existent function no track file is appended.

This was solved by Steve K. at the Virpil forum, here his post: Almost sounds like maybe DCS is trying to using windows to calibrate the axis and not seeing the range and messing things up. Try going to Windows game controllers properties for the throttle and do a 'Reset to default' from the Settings Tab and see if that brings back the range in VPC tester without having to reflash. I reset to default in the Game controller ulity and now I had my alanog axis back. Strange case of Windows/DCS trying to be smart. Thanks Steve K.

My CM2 Z axis (front zoom/radar antenna elevation) behaves strange after use with DCS (Software 2021.01.02, DCS latest Openbeta) , it suddenly has a Windows output 0% or 50% or 100% in steps rather than an axis behavior. The axis is perfectly normal in VPC configurator with a smooth progressions of raw and calibrated values with 20210102 software but VPC tester and Windows Game controller utility shows the three value behavior as well. I have set no axis to button or other settings to explain this behaviour, all axis are per default, only calibrated. I have done a detailed check in the details window of this axis against the TDC axis (they all three use the same type of sensor) and the settings of all three are identical, left per default in the 20210102 firmware. If I reload the firmware and load the profile for the CM2 it retakes a normal axis behavior in both testers. Then I activate it with DCS and in e.g. F-18 axis it retakes this stepwise output. A recheck with VPCtester and Win game controller confirms the changed output, now in has changed to three steps. It has the values 0%, then 50% and finally 100% as you move the axis over the range. I check my newly arrived CM3 (not used until now) loaded with the same firmware and profile (I added calibration of course), it behaves correctly in VPC tester, Windows game controller setup and DCS, also after flying sorties with the F-18. Then I check the CM2 and CM3 throttles on my work computer where I've loaded 20210102 and there both have the correct analog 0% to 100% axis on VPC tester and Win game controller. As I tested on this computer before I reloaded the CM2 with the 20210102 firmware/profile the stepwise CM2 behavior was on this non gaming computer as well, so it tells you it is indeed a change in the throttle output via Windows. It's seems it's something with my DCS rig that changes this output on the Windows level but I can't figure out what. I have no known software between the VPC throttles and Windows or DCS. I'm an experienced Win user and keep my PCs minimally loaded with software to keep control. I did add Steam VR recently but find it hard to think it would be involved. I do not use Joystick Gremlin or any other joystick output modifier software. That this shows up in VPCtester is strange, you would think it reads the CM2 output directly, but how can then the output change like this between computers with the same version of VPCtester. Anyone experienced this before? I have now changed to use the CM3 with DCS (pray it doesn't degrade as well) but would like to understand what is happening with the CM2 throttle with the same firmware, profile and calibration attached to the same cable and rig as the CM3.

Well, the "always update " philosophy got me into the mess, I had stick and throttle working perfectly on 20200325, then updated to 20201118 in anticipation of the pedals. Got into this bug and also that the IDs changed so my mappings for 15 DCS modules were gone. Also couldn't reload my 20200325 Virpil profiles as the 20201118 changes to XML profile files. A total mess for no good. I won't upgrade from now unless forced.

I had the 20201118 installed before 20210102 so left that firmware and settings for the stick and throttle, no need to update unless you know there are bugs. There were no posts about this rather grave bug (axis go unusable or disappear) what I could see, nor did Virpil actively tell you to upgrade.

Have a CM2 stick and throttle and finally the ACE pedals. After updating to the 20201118 software (to calibrate the Virpil ACE pedals replacing CH Products) some axis started behaving strangely. The RAW values from the Flaps lever changed after a short USB disconnect/reconnect to reconfigure, making it unusable (it had the lowest value about 2/3 through and logical value was 0% or 100%), then the radar elevation axis disappeared gradually and finally yesterday my stick pitch axis went crazy like the Flap one after a USB disconnect/reconnect. Nothing helps, not recalibration or any other changes. Reloading the 20201118 firmware doesn't help either. It's all a Zero calibration bug in the 20201118 software! Just update to 20210102, recalibrate and things turn normal. Funny there is not a more explicit warning on the Virpil website. I though I had hardware problems initially, as it's the Raw axis values that gets affected. Except for this rather serious bug I'm very happy with the Virpil stuff, quality and feel is top. Now a tip: For CM2 throttle users, you can make a simple burner push through detent with a piece of wood and two ballscrews (M4*12, available at amazon). See photo (picture when checking out the function, has araldite glued it since). Yes it scratches the paint on the throttle levers but it doesn't bother me, it's metal below the paint and it's not affected. Have got the CM3 throttle now but in no hurry to change, the burner detents functions just fine. It's a fixed detent but this is easily adjusted with the axis curves.

I use both for the Hornet vertical radar axis. The slider with center for large changes in radar vertical tilt (with a reasonable deadzone as it otherwise floats the axis for any centering faults) and the right rotary inside the 5way for small changes. Try it, it's useful.

Yes, good than you can close this part. The other is the third TDC press shall not un-designate, only the un-designate button shall do this.

I ran it again with the default 16 seconds aging, no difference. It's an AIM-120 RWS > STT DDI display format issue, the HUD info is correct, the DDI display of STT lacks almost all info, the display is like a Angle Only Track (AOT) track though what you have is an STT with range gate set and working (as the HUD is correct and you get Shoot display and the AIM-120 shot works).

Forget about my grief, I added the modifier as a switch, my bad. Controls work as they should.

Don't think so. it's a STT with the AIM120 range info lacking, you see that in the HUD which has a correct STT info display, including max range, no escape and min range and you can fire an AIM120 on the info (you can't on a L/TWS). Look at the track file.

See attached trk file. In AA AIM120 mode and RWS a TDC press over cross target (assume highest ranking RWS file) sets L&S correctly, second TDC press sets an incorrect STT on the RDR DDI, without AIM120 in-range info, no right range info etc. A further DTC press undesignates (which is wrong, nothing should happen). Do the same with DMS right with TDC over the RWS target and it shall give a direct STT. It doesn't, it gives a RWS L&S, press DMS right again with TDC over L&S, same strange STT with no info on DDI. HUD symbolgy works, but you are busy with DDI to kill several Bandits. right now it doesn't work because of missing in-range info. At present on this version of Openbeta a correct A-A STT does not exits it seems. Also, when switching from RWS to TWS the TDC shall keep it's RWS position, as you often have marked the target to IFF interrogate, then TWS shall center on that TDC position. Now it restarts from top left meaning you lose TWS scan on the Bogey to Bandit IFF you made. Not logical. 2021.02.01 F-18 STT faulty vs Bogey (Mig29) .trk

I can confirm this bug, had it today and I have had it severeal times over the last six months both on stable release 2.5.6 and now latest OpenBeta. The fix was really hard to find, you press reset, shut down the radar etc, nothing helps, but now thanks @Kapsu we know what to do. Your radar is really gone when it enters this mode.

Thanks Bailey, brilliant!!

I'm on OpenBeta meaning the CMS files get changed often, i.e. you need to reset User privileges as above each time you update if your Windows login puts you in User space (guess some get logged in as Admin and then it's not necessary). But then you need to change something in DiCE for the aircraft as the app only writes to the file on a change of values. Could this be changed so you have DiCE write to the files at startup of DCS/DiCE? It would help.

This chart is probably correct, it fits with my observations when doing BFM versus Mig-29 and Su-27 with the models. It's very hard to win a Mig-29 one circle fight with the F16 as you need to hit the corner speed of 440kts exactly and stay there. Then you only keep up with the Mig-29 and the Su-27 beats you. It's almost impossible to find a speed range where you outturn a Mig-29 (which the F-16 vs Mig-29 diagrams says as well). The F-18 shall be flown 100kts slower, then it turns inside the Mig and Su, then you are in the control position ie on the 6 after a while. The F-16 has a too small wing, this is why it's optimum speed is higher, the Hornet's larger wing and especially larger span (to reduce induced drag which dominates in a sustained hard turn) makes it the better BFM Guns fighter.

That's from Boeing marketing material to explain why the Super Hornet is a better alternative. Observe it loads up the 18C with three bags to get the same radius of action. On internal fuel the 18C turns faster than the Super Hornet, though it's a bit unfair as the SH can fly longer on internal fuel.