need evidence Scan azimuth problem

[falconzx]

With the last patch i found a new bug. 
If you put radar azimuth scan narrow (+/- 20°) after creating a track file on a radar contact and bugging him, if you return to scan, while climbing or descending with an high pitch angle, the scan try itself to move to the center in a weird and uncontrollable way. Then after a while (probably when the trackfile fades) all returns to normal, and you can control azimuth under all pitch conditions like before.

It's problematic when you re-engage after defending, because it's the classic search you perform in an interrupted f-pole tactic.

This bug was introduced with the latest patches, i'm sure it wasn't there before, it started to happen in some combat manouvers i perform in the same way by ages.
 

f-16_scan_azimuth_weird.trk

Edited May 4, 2021 by falconzx

[falconzx]

I have done more tests, it's more simple than that i described.

Put the Radar Azimuth to A1 (just to make the problem more evident), put the scan to the full left or right, climb or dive 40° degree(it's enough), then roll the plane (it happens on certain bank angles) Look at the scan while doing this, you'll see it moving towards the center... And if you try to correct it, you can't. 

The radar should be gyro leveled, if something odd happens when you just roll the plane, it's definitely a bug.

I hope this helped investigation. Cheers

Edited May 25, 2021 by falconzx

[falconzx]

2.9, years passed, the bug is still present. Bank angles towards the turn in a climb move the A1 scan volume from the inside of the turn, towards the center. If you roll/bank outside the turn it stops happening. 
If you dive the behaviour is inverted: bank angles opposite of the scan volume push the scan azimuth towards the center.

Any news?

Edited February 16, 2024 by falconzx

[BIGNEWY]

Hi, 

this thread has been over looked and the track you supplied no longer works correctly. 

Please supply fresh tracks and any evidence you have something is wrong. 

thank you 

[falconzx]

Very short and simple track. As you'll see from my inputs in the track, i'm not touching any radar controls while performing rolls at +-30/+-40 degree of pitch.

Bank towards the scan only cause the problem when pitch is positive. 
Bank opposite of the scan  only cause the problem when pitch is negative.


 

F-16_A1_SCAN_MOVING_BY_ITSELF_ON_ROLLS.trk

[Lord Vader]

Hello @falconzx

I watched your track and can't understand what you're trying to claim here. This appears to be induced by the antenna gimbal limits trying to remain within that extreme volume angle.

If you have public documented evidence this is wrong, please send it to @BIGNEWYand we'll look into it. 

[falconzx]

Hello, thanks for reviewing but maybe i'm misunderstanding how the antenna gimbals works. F-16s as i know, and tested in DCS is a +-60° in all directions(try STT for example). If this is true the limits should be equal, regardless the roll state of the airplane. If roll influences the gimbals the causes could be two: gimbals are irregular(so there's something wrong in STT), or, there are problems to the gyro stabilization of the antenna.

In the track you can see this irregular behaviour, same pitch, same radar settings, different roll states = different results.

If it can help i've made a video to better explain what i mean, and what's the behaviour expected versus the sent track behaviour on rolls.

In this case i modeled the plane have a +30° pitch and the scan is horizon centered (simulating an ANT elev left to zero) and i've lost 4/5° degree circa over a 60° degree gimbal.

In DCS: F-16C values are way more big. So i suggest to check the math behind this, and also check why results are not even during rolls.

Thanks.

Edited February 21, 2024 by falconzx

[falconzx]

Let's try again with a more clear track, now i've used active pause.

Data to reproduce the incoerency:

Aircraft state:
Pitch: +30
Roll: + or - 90°

Radar and Antenna settings:
Azimuth: A1 and A3
Mode: CRM. RWS or TWS (not relevant)
RDR CURSOR position: just put it close to the MFD lateral edges, without touching them (it will cause an azimuth change)

Use Active PAUSE to mantain this aircraft attitude while doing the tests.

Observations:
In A1 the scan volume determined by the azimuth blue caret (bottom of the screen)  is not following the RDR CURSOR on the entirety of its gimbals. More precisely as you can determine by the graduated scale on the bottom, the scan volume is limited by 20° degree on one side, so the gimbal is like 60° on the side not affected by the issue and 40° on the other side.
Putting A3/A6 the azimuth caret will go and scan where the A1 just couldn't go. More precisely the antenna is going back to it's original +/-60.

This happens on the left if you have left wing down.
This happens on the right if you have right wing down.

If you repeat the test with -30 pitch:
This happens on the right if you have left wing down.
This happens on the left if you have right wing down.

If you repeat the test with 0 pitch:
No issue is observed.



Little offtopic(sorry), but i've no time to follow now to a different bug report: in the second part of the track i played with elevation to see how in SAM mode the elevation caret is not showing anymore the angle relative to the horizon (gyro stabilized) only, but seems it's alternating a nose relative angle while tracking the target.
Considering that SAM it's alternating between tracking and scanning, that's theorically ok, what it's not ok it's the "delay" between the two visualizations.

Seems like the antenna has to travel in elevation between the two phases, while it's only a change about relativity of the angle visualized by symbology. That's not correct, if i've not moved my ANT ELEV axis on my control, the antenna should be very close to the bugged contact, so there should be no delay or transition stealing time to scan phase.

Considering the VERY limited time to scan in SAM mode it's important to "unlink" what's the symbology "speed" from what's the antenna actual position and moving speed.
 

F-16_azimuth_scan_volume_incoerency.trk

Edited July 19, 2024 by falconzx

[falconzx]

Il 19/07/2024 at 13:54, falconzx ha scritto:

Putting A3/A6 the azimuth caret will go and scan where the A1 just couldn't go.

@Lord Vader sorry if i bring this up again, but i think the last track is quite interesting in response of your latest answer. Gimbal limits should apply to the radar dish angle. In the track is clear shown what i claim: the dish in A3/A6 go where in A1 cannot go.

Can we have an answer on this? Thanks.

Take care.

Edited August 14, 2024 by falconzx

[Lord Vader]

Thanks again for bringing this to us.
I still maintain my opinion this looks (just looks) like a gimbal limitation on the turn but if we feel this needs an improvement we'll certainly address it.

[Yaga]

On 8/14/2024 at 6:04 AM, Lord Vader said:

Thanks again for bringing this to us.
I still maintain my opinion this looks (just looks) like a gimbal limitation on the turn but if we feel this needs an improvement we'll certainly address it.

Watching this in tacview will easily confirm if this is a gimbal limitation or not. Select the 'relative bearing 3D' measurement line and set the F-16 as object 1, and the target as object 2. 

@falconzx I agree with you that there is something weird going on when tracking a target while rolling and pulling. I see this behavior every time I loft a shot up and rollover into a dive with the target near the edge. The scan zone azimuth wiggles on the FCR as you roll. 

If you could post the tacview of the track file you already provided, perhaps @Lord Vader can find the time give this a more critical look. 

[falconzx]

5 ore fa, Yaga ha scritto:

see this behavior every time I loft a shot up and rollover into a dive with the target near the edge.

Hi Yaga, thank you very much for the support.

Since 2021, when I reported this bug, I have been living with this problem. It's a very serious bug for highly experienced pilots like us who use the F-16 in tournaments and competitions. Perhaps casual users who don't push the limits don't realize how severe it is. But unfortunately, it seems that despite clear tracks accompanied by all the explanations I could give to describe the problem, it's still not admitted that there's a bug. In my opinion, there's a comprehension issue on Eagle Dynamics' side.

I clearly wrote that a case is visible where the radar dish sweep is limited to 40°, and I listed the steps to reproduce the phenomenon.

If, faced with this, I'm told that "it always seems like a gimbal limitation in a turn," then I give up. I give up because we all know that the F-16 has a gimbal limitation of 60°. I even created a 3D model to understand, in a +30° pitch, how much the horizontal azimuth reduction is, and I recorded a video to show it. From my readings, it results in very few degrees, far from the 20° degrees lost in DCS.

here is the tacview of the track I recorded.

 

Tacview-20240817-122221-DCS-F-16_azimuth_scan_volume_incoerency.trk.zip.acmi

Edited August 17, 2024 by falconzx

[falconzx]

If it can help: I suggest focusing on the symbology at the bottom of the MFD, the blue caret. Looking at it, it will be evident that in A3/6 it moves freely until it touches the edge of the screen, while in A1 the scan is forcibly shifted, forcing the blue caret to a limited movement. If in A3/A6 the blue caret was able to scan at that angle, there is no logical reason why in A1 it cannot move the scan to that point.

Thankyou and take care guys.
 

Edited August 17, 2024 by falconzx