Jak525

Ah OK. Bottom line is single TDC depress on a HAFU that's already L&S = acquisition. If no DT2 exists, an undesignated trackfile would be STT'd in 2 depresses (once to designate as L&S, another to STT). Yeah? Really though this is all just a convoluted alternative to using Fast Acq (bumping Castle toward the Attack format), which STTs anything under the cursor with one press.

Interesting, this is definitely way newer logic. The double action didn't use to exist. You have to use RSET to undo the L&S. A single action on the L&S would go to STT. Also depressing on the DT2 makes it L&S, but undesignates the old L&S rather than making it the DT2 as wel.

FD is also an alternate means of steering. AUTO basically draws a virtual line in space you steer to. FD gives you a line to fly a specific bank angle, much like the magenta bars on a typical PFD instrument. In fact, FD steering is more comparable to CCRP in the A-10 than AUTO is.

This present behavior is actually wrong. TWS switch from RWS should default to MAN even with AUTO previously selected, with the exception of the later-added HOTAS command via the RAID switch. However selecting PB5 or using the cursor to do so should default to MAN. Other than that the only time it should default to AUTO is from STT. The other exception is when an AMRAAM is fired in RWS then it should go to TWS automatically in AUTO mode. Regardless it would be way quicker to go to TWS AUTO from RWS if they would implement the cursor selection of those push buttons. Quickly select TWS via cursor then move to select AUTO also via cursor. Remember the RAID switch shortcut wasn't always in the real jet either.

There's the answer, thanks. If it's added in 21X unlikely ED's got the info then. We'll still get HOTASability of TWS sometime via the cursor though, y'all, fyi.

This issue is solved: As it's been said there should be no diamond reticle in A/A, which was the focus of this report. A/G looks fine.

Precisely - great explanation. And yes, in DCS it will let you guide 10 AMRAAMs, however the limit should actually be 8. (10, not 8, Radar trackfiles are supported, however, so it'd be a limitation of the APG-65/73's ability to spew out missile datalink commands.)

Really, if the Litening was modeled off of a newer OFP, there would be minimal difference. However, there is a gigantic gap between the two, and so the DCS ATFLIR will be way better than the Litening due to more modern functionality.

Correct, yep. The max TWS frame time is ~3 seconds (obviously can be less). Regardless this isn't about the frame time restriction itself - that's implemented. It's just about the UI mechanization of selecting the azimuth width.

Yeah, the cursor-selection is the way around it. And no, the OSB logic right now is not correct. It should be as I describe in the report. You do make a good point but apparently they elected to do it the other way. It's a trade off because although you do describe a problem, with the current way it's in DCS another problem is created in that if you desire to increase the azimuth, say you're in 4B at 40° and want to be at 80°, right now you'd have to cycle through 6B, then to 2B, which'd reset the azimuth to 20° since you're going thru 6B. Then, you'd have to increase the azimuth to 80° after. Similar to the problem you described. In the end though using the cursor would be the quickest way since you can directly select any bar or azimuth without cycling.

You cannot have 120 degree in TWS. 80 is the max. But yes, if the uncommanded value is within limit, it's not going to do anything. It will only change the uncommanded value if it violates the TWS scan volume restrictions. Tl;dr it's less than or at max, no change, if it's more than maximum, the uncommanded value is automatically decreased. So yeah, if you have a 20 degree azimuth, it's never going to be changed when you cycle through the bars, because 20 degrees is permitted in 2B, 4B, and 6B. If, however, in 4B you were at 40 degrees, going to 6B would change it to 20, since 40 at 6B is no bueno. However, if you directly cursor-selected 2B, it wouldn't change, since 40 is permitted at 2B. (The cursor selection function is bugged at the moment.) (TWS restrictions) 2B - 20, 40, 60, 80 4B - 20, 40 6B - 20

Yeah, just the SA

Current behavior - In TWS, with a given bar selection (2, 4, or 6), the azimuth selection is limited to whatever azimuth is allowed for that bar. For example, if 4B is selected, the azimuth select cycles through 20 and 40 degrees. If 6B is selected, only 20 degrees is available. If the elevation bar setting is cycled, the azimuth is automatically decreased to meet the limit. For example, if 2B and 60 degrees is selected, cycling the bar setting to 4B would automatically command a 40 degree azimuth. Correct behavior - It should work like it does, but both ways, instead of just one. For example, with 6B selected, you should still be able to cycle to 40, 60, and 80 degree azimuth. However, if you cycle to 40, it would decrement the bar automatically to 4B, and if you selected 60 (or 80), it would decrement the bar to 2B. In other words, both elevation bar and azimuth width can be selected at any time in TWS (with the exception that TWS does not ever allow for 1B elevation bar or 140 degree azimuth width). When you select either the bar or azimuth, the one you did not change yourself is automatically changed IF required. Right now, this works when changing the elevation bar, but not the other way around. TWS azimuth select bug.miz.trk

Just fyi, the fact you can do that (command STT on empty space) is a bug too, and it's not a spotlight search. That's not yet implemented. A single TDC depress within a second should set the scan center, even in RWS. Holding TDC depress for more than 1 second would do a Spotlight search.

Not acknowledged yet I don't think, but no, it's not correct.

A/G tracks are not actually part of MSI despite having HAFU-like symbols. MSI is the term for A/A trackfile sensor fusion. Anyway it does seem per @Mo410 who I assume is a pilot or avionics guy that they should only be on the SA format, and not the Az/El or Attack format.

The altitude right of a HAFU symbol should be rounded to the nearest thousand without a decimal. So, for example, 10,800 displays as 11. 33,100 displays as 33. Note that the differential altitude number by the elevation caret on the left side of the Attack format is, and should be, given a decimal place. No issue there. Current behavior - altitude to the right of HAFU is displayed with a single decimal place. E.g. 10,800 is displayed as 10.8. Correct behavior - altitude to the right of HAFU is displayed to the nearest whole thousand. E.g. 10,800 is displayed as 11. HAFU altitude nearest thousand bug.miz.trk

ED has modeled things from various OFPs, it's not that consistent (understandably so), but yeah, when faced with modeling something never planned it's likely they won't elect to do so when it's in something so new. It'd be great though - I'd be totally for it. I forgot about that paper though. I haven't read it in full, but if it describes the CAS format sufficiently to model it, then that's great. Usually white papers don't describe avionics functions in enough detail though to be used as the sole source.

CAS format wasn't added until OFP 23X, around 2010. Unlikely ED has information on it.

Already reported before. It's known

Hey Bignewy, I feel stupid. I thought I had sent you a PM about this but I guess it never went through... I just sent it now, sorry about that.

It is definitely the case in 2002, which is quite close. I have never seen the behavior described in any other way. The question would be whether ED's references support anything else, so I suppose that's a question for the devs.

When an L&S target is designated, the AIM-9 should slave to it by: 1) pointing seeker LOS at L&S LOS 2) ensure angle of coincidence (AOC) test is met. This means the AIM-9 seeker LOS and L&S LOS are within 1.5 degrees of each other, or within 3 degrees of each other for a target 26+ degrees off boresight. Technically it should ensure the LOS's meet this for at least 0.3 seconds. 3) if/once 2 is true, command the seeker to independently track. If at any point 2) is not true, the AIM-9 slaves back to the L&S line of sight and the process starts over at step 1. The result is that the AIM-9 is ALWAYS slaved to the CURRENT L&S, because this angle is always being checked. Now, here's the bug. When the AIM-9 has not yet been commanded to independently track (no tone heard), the seeker properly slaves to the L&S line of sight. You can see this demonstrated when I step the L&S through various targets that are way too far away for the seeker to see yet and there is no tone. During this the seeker steps to each new L&S. However, once I step the L&S to a close range target (close enough for the 9 to see it), the seeker is commanded to independent track and you hear the tone. This is correct. The problem then occurs after this when I step the L&S to another target. The computer SHOULD be recognizing AOC is false and going, "oh, the AIM-9 is tracking, but its LOS and the L&S (the new L&S now) LOS are way off. Back to step 1." However, that's not happening, and the seeker continues tracking the old target. One fix I notice is pressing the Cage/Uncage switch will re-command the AIM-9 to slave to the L&S LOS. However, this is not correct, and the Cage/Uncage button has a different function when an L&S exists (I will make another report on this particular behavior). AIM9 AOC test bug.miz.trk

When the HMD is turned on, and the AIM-9 is slaved to the L&S line of sight, the seeker is never commanded to lock-on. Lock-on should be commanded once the angle of coincidence test (AOC test) is met between the seeker and L&S LOS, and there is a good audio tone. This works properly with the HMD OFF. However, with the HMD on, the seeker never locks on. You can tell this is happening because of the tone. The low pitch steady tone means the seeker is detecting sufficient contrast but has not been commanded to independently track. The high pitch steady tone means the seeker is tracking. In the HMD on .trk, you never get the high-pitch tone, but in the HMD off trk, you do. In the HMD on replay I also briefly commanded seeker lock-on without any L&S (hit RSET), to clearly demonstrate the difference in tones. You can hear when I do independently track the seeker without an L&S, there is a much higher pitched tone. Current Behavior - With both HMD on and off, AIM-9 is slaved to L&S LOS. However, with the HMD on, the AIM-9 is never commanded to independently track once it has a good tone (and seeker LOS meets proper coincidence angle with L&S LOS). With HMD off, behavior is correct and AIM-9 independently tracks upon good tone and angle coincidence test. Correct Behavior - With HMD on or off, AIM-9 should be commanded to track independently when slaved to the L&S target, once angle coincidence test is met and there is a good tone. AIM9 HMD on not locking bug.miz.trk AIM9 HMD off locking demonstration.miz.trk

You should only need to use the SA. The point of the SENSR sublevel is toggle universal contributors to MSI. This is separate from actually disabling D/L (it just tells the computer not to use any L16 info in sensor fused [MSI] trackfiles), and is also separate from the MSI option on the Attack format, which is wrong at the moment but, perhaps confusingly, should not actually toggle any MSI processing (it should just be a display config for the Attack format only, not even the Az/El or SA).