reported earlier AG slewing and radar updates

[SeaBass80]

Hi,

a few perceived bugs have already been reported concerning slewing of the GM radar. Running the risk of overreporting, I would like to mention these bugs that are very "annoying" and seem to break with the otherwise smooth "clickology" of the F-16 cockpit/MFDs.

• In ground-mapping modes with A3 or A1 azimuth settings, the radar map generated during a prior sweep will move along with the cursor when slewing it around, until the radar image gets replaced on the next sweep (F16-A3 slew.trk). This is likely a bug, as it temporarily produces wrong coordinate to radar map relations when hitting the freeze button at the wrong moment. It is also very likely related to how the freeze mode itself is implemented, as it is very similar to this already-reported bug.
• In the expanded radar modes, the radar image only gets updated when the finger is off the slew axis (F16-DBS2 slew.trk). There are actually two updates to the radar map that is being displayed:
  The first update occurs the exact moment that the finger leaves the slew axis and essentially returns the ground map to the position it had before the start of slewing. At this moment, the map displays a cursor/map combination that does not equal the SPI coordinates, as those are already slewed to the new position.
  The second update finally occurs when the next radar frame/sweep is started and overwrites the image with the new, correct one.
  This behavior was reported before, though marked "correct-as-is" for lack of written documentation. The only reference I can provide is the publicly available HAF -34 for the F16C/D Block 50 (1997), which states that in DBS1/DBS2 "refinements in cursor position take effect only at the start of a frame" (p. 1-148). I take this as meaning that the DBS1/DBS2 ground map should be refreshed once per radar sweep, regardless of whether the cursor is in the process of being slewed around.
  Circumstantial evidence that the current implementation is wrong is mainly that due to the long update time in DBS2, there is a high probability that FZ mode is used to freeze the radar map in-between the "first" and "second" radar map update described above. In this case, the radar would display a ground map and a targeting cursor at the position before the slew started, but the SPI coordinates would already have been slewed to the new coordinates. This simply cannot be right for the real-life aircraft.
• Very likely related to the above problems: The "update" of the radar GM mode ground map display is handled quite differently in A6 and A3/A1 azimuth settings. In A6 setting, the ground map is static and only refreshed when the radar beam passes on its sweep. This means that in a turn, the SPI cross temporarily moves across the display map before the map is updated. In A3/A1 modes, the ground map is (presumably correctly) rotated based on the INS information so as to have the SPI cursor always on top of the correct ground map point (F16-GM radar map updates.trk).
  I actually presume that the ground map should behave just like the air-to-air modes of the radar, in that the radar return image is correctly shifted and rotated based on aircraft INS data in-between radar sweeps. This is the only way that a SPI cross that is fixed with respect to the MFD frame will always stay on top of the designated ground point: the radar map needs to reflect the INS-derived aircraft movement even between updates. Obviously, none of this is described in the public documents, but this is true for either interpretation of what is correct and what isn't.

F16-A3 slew.trk F16-DBS2 slew.trk

F16-GM radar map updates.trk

Edited April 21, 2022 by SeaBass80
added another related bug

[BIGNEWY]

I will ask the team to take a look. 

The slewing issue has been reported however

thanks

[llOPPOTATOll]

Track: https://1drv.ms/u/s!Aixanfk_YcTj6Bl2BliGRDUqj4Z7?e=LdkOOW

Edited August 23, 2022 by llOPPOTATOll

[Arctic Fox]

This is a serious problem that makes designating targets with the FCR cursor very difficult. The Hornet suffers from a similar problem when trying to make a TGT using the A-G radar, probably the same underlying issue.

[RuskyV]

It gets worse, try narrowing the azimuth without any DBS modes and pan the cursor. You can literally drag the image all over radar screen.

[enyak]

We've had this yesterday with the TGP installed, even though it had no active track and wasn't SOI. For some reason setting the TGP to standby fixed the issue and the FCR was able to slew freely and stay in position.

Edited August 23, 2022 by enyak

[SeaBass80]

This seems to be the same issue reported by me and before by others, see here. It was marked as "reported before" and locked, but has not yet been resolved. It is great though that you included the real-life videos on this to convince the team to tackle this soon. I still consider this a very awkward problem that takes lot away from the beautiful hands-on functionality of the F-16 switchology.

[NineLine]

This was already reported earlier.