AG Radar bug when Designating after update?

[LastRifleRound]

I don't know if this is a bug or a misunderstanding on my part on how the radar is supposed to function.

I have a target point with 4 offsets. I start a mission with some significant INS error built in (70min of flying).

I perform an INS PVI update and get the error low, no problem.

I map the target, it's an airfield. There is significant drift (mission is in 1991). Expected.

I update using one of the offsets, then refine the update using another one of the offsets on a smaller point.

I switch to the target waypoint (it's 2 in this case) both on the UFC and in the AG Radar format. Designation looks good, so I leave it alone and bomb the target. No problem, target hit (though the string doesn't center, I'm sure that bug's already been reported).

I go for a second pass and decide to drop a pair of Mk84 on a target of opportunity, an IL76 on the ramp. I make sure the radar is set to "TGT", and designate the aircraft and get "DESIGNATE" appearing on the radar. The ENTIRE nav polygon for waypoint 2 (which is a target point) shifts as if I had just done an update. Not only that, but the original target is still the one marked by the ASL. I assumed the point of using TGT vs UPDT is that it should treat the designation as something independent of navigation and set it as the "SPI" essentially. What gives?

[Rainmaker]

Not sure if I am understanding your issue correctly, but target points will shift with designations.  Its is a feature of target points only. 

[LastRifleRound]

4 hours ago, Rainmaker said:

Not sure if I am understanding your issue correctly, but target points will shift with designations.  Its is a feature of target points only. 

The target point should shift, not the entire nav polygon. Also the designation on the radar doesn't match the HUD

[Rainmaker]

5 hours ago, LastRifleRound said:

The target point should shift, not the entire nav polygon. Also the designation on the radar doesn't match the HUD

I’m not sure what you mean by polygon?  If that is a ref to the offsets, they are in relation to the target point location. 
 

As for the radar/HUD mismatch, that could be due to two main things, drift and altitude deltas between the steer point/target point elevation anf actual elevation of the target location. 

[LastRifleRound]

13 minutes ago, Rainmaker said:

I’m not sure what you mean by polygon?  If that is a ref to the offsets, they are in relation to the target point location. 
 

As for the radar/HUD mismatch, that could be due to two main things, drift and altitude deltas between the steer point/target point elevation anf actual elevation of the target location. 

Let me ask a fundamental question to illuminate the issue. What is the difference between an "UPD" on point x., and a designation of "TGT"?

If the answer is literally anything at all, the current implementation is bugged 

[Rainmaker]

43 minutes ago, LastRifleRound said:

Let me ask a fundamental question to illuminate the issue. What is the difference between an "UPD" on point x., and a designation of "TGT"?

If the answer is literally anything at all, the current implementation is bugged 

Update moves the entire route, des will effect the target point.  Both can/will look tye same if you are just looking at the target point. 
 

From what you have said so far, its working as intended. 

[Hatman335]

3 hours ago, Rainmaker said:

As for the radar/HUD mismatch, that could be due to two main things, drift and altitude deltas between the steer point/target point elevation anf actual elevation of the target location. 

The target cursor functions works for me as intended, but I also experienced the same mismatch between the target location on the HUD versus on the AG radar map, even right at the moment of designation.

[Rainmaker]

4 minutes ago, Hatman335 said:

The target cursor functions works for me as intended, but I also experienced the same mismatch between the target location on the HUD versus on the AG radar map, even right at the moment of designation.

As above, the mismatch could be a few different things. There was also so unintended excessive drift that should be addressed in the most recent patch. Would need screenshots, video, something to see why it might be off. Could be a coordinate problem, or alt deltas. Cant speak to any of it for sure. 

[Hatman335]

55 minutes ago, Rainmaker said:

As above, the mismatch could be a few different things. There was also so unintended excessive drift that should be addressed in the most recent patch. Would need screenshots, video, something to see why it might be off. Could be a coordinate problem, or alt deltas. Cant speak to any of it for sure. 

I will make a video or track, but let's ensure that my methodology is sound.

I set up a very short airspawn, in a mission dated 1991, with 70 minutes of flight time set on the drift slider. I selected MN PPKS. I did my MN PVU, then I did my initial map. Steerpoint 2 was a big bunker on a smaller land feature, it was very easy to find, I updated my system using that. Then I mapped the target area and designated 4. There were no PB#17 errors, I double checked. Freezed the map and as I got closer, I did several redesignations, they were all noticeably short of the designated area and slightly offset right. The time between the designation tests and the MN PVU did not exceed 5 minutes. All points were added through the mission editor and that automatically loads the correct elevation, but I also double checked it manually. 

 

The update was as good as I could do it, the PVU was still valid, the elevations were all correct. What could be the issue?

 

I repeated the same test using EGI and I only mapped and then repeated the designations, without the PVU or the update. As expected, the issue was significantly lesser pronounced but it was still noticeable.

[Rainmaker]

Showing short sounds like the elevation delta. Current SP height needs to be as close as possible to actual target elevation. The radar uses SP height for target elevation. 

[Hatman335]

17 minutes ago, Rainmaker said:

Showing short sounds like the elevation delta. Current SP height needs to be as close as possible to actual target elevation. The radar uses SP height for target elevation. 

The target area where I did the designation tests was the Eastern section of Batumi airfield and the area has a constant 33 feet of elevation. Even the initial designation is off, I tried to do it just once, targeting the Western part of the ramp and the HUD indicator was significantly short of the actual point designated on the patch map. 4. had an elevation of 33 feet.

Edited July 24, 2023 by Hatman335

[Rainmaker]

28 minutes ago, Hatman335 said:

The target area where I did the designation tests was the Eastern section of Batumi airfield and the area has a constant 33 feet of elevation. Even the initial designation is off, I tried to do it just once, targeting the Western part of the ramp and the HUD indicator was significantly short of the actual point designated on the patch map. 4. had an elevation of 33 feet.

 

Yeah, would likely need a track or video then to see. The last version had some runaway drift, but it should hopefully be addressed already in todays patch. 

[LastRifleRound]

MN PVU does nothing to limit drift it only clears up the radar map, as MN isn't implemented. Use INS PVU and leave the nav source on the UFC as INS. 

I will upload a track showing the behavior I described. It's sounding like it's unintended behavior.

[Kercheiz]

Yes, you are doing it wrong (likely)

When designating a TOO, you must have no steerpoint selected on the radar screen. PB17 must say "SP" and no number.

Otherwise, if any target point or target point offset is selected, the whole target+offsets group will be updated so that the selected one is where the cross is, and the updated target point (not the selected offset) set as A/G designated target. This pos update is temporary and bound to the A/G designation, and not a permanent update (unlike UPDT)

So before working with a TOO designation, unselect the target on PB17 or select a non target point (circle or square)

Edited July 24, 2023 by Kercheiz

[LastRifleRound]

7 hours ago, Kercheiz said:

Yes, you are doing it wrong (likely)

When designating a TOO, you must have no steerpoint selected on the radar screen. PB17 must say "SP" and no number.

Otherwise, if any target point or target point offset is selected, the whole target+offsets group will be updated so that the selected one is where the cross is, and the updated target point (not the selected offset) set as A/G designated target. This pos update is temporary and bound to the A/G designation, and not a permanent update (unlike UPDT)

So before working with a TOO designation, unselect the target on PB17 or select a non target point (circle or square)

 

Thanks, this clears it up. Looks like it works as intended, then. I'll give this a shot and report back.

[LastRifleRound]

Ok all good. The system operates as @Kercheizexplained.

However, I'm noticing once I correct for drift and bomb, I get dead on results, but 5 minutes in on my second pass the INS is accumulating errors faster than I can correct them. I need another PVU in the time it takes to extend 10nm and turn around. I went 20nm one time, did a PVU, re-mapped, had to fix the drift again, and by the time I bombed the TOO the nav had drifted enough to miss.

I bumped the mission to 2016 and the problem goes away (as updating and PVU becomes unnecessary with EGI).

Is excessive drift a known issue they're working on? It seems more related to the amount of time in mission and the amount of "inflight time" you program into the ME just sets initial conditions. It basically makes pre EGI periods impossible to fly without GBU's.

[SloppyDog]

On 7/25/2023 at 5:59 AM, LastRifleRound said:

Ok all good. The system operates as @Kercheizexplained.

However, I'm noticing once I correct for drift and bomb, I get dead on results, but 5 minutes in on my second pass the INS is accumulating errors faster than I can correct them. I need another PVU in the time it takes to extend 10nm and turn around. I went 20nm one time, did a PVU, re-mapped, had to fix the drift again, and by the time I bombed the TOO the nav had drifted enough to miss.

I bumped the mission to 2016 and the problem goes away (as updating and PVU becomes unnecessary with EGI).

Is excessive drift a known issue they're working on? It seems more related to the amount of time in mission and the amount of "inflight time" you program into the ME just sets initial conditions. It basically makes pre EGI periods impossible to fly without GBU's.

Interesting discussion. I'm having the same error when using Auto Mode, The target diamond is right on over the target, but the Azimuth Steering Line (ASL) is off. Same thing happens: first pass, all success. Second pass, the INS drift is way off in a matter of minutes. Getting in back to target, the diamond is over the target, but the ASL leads me to some point off the designation diamond. Off by as much 1,400 feet. 

NotSo in the Razbam Discord said that the INS drift rate is about 0.6 nm/h; or 3,645 feet/h. So, in a matter of five minutes, the INS drifts as much as half as it would in one hour. I believe it is influenced by the time you set in the Airborne Time option in the Mission Editor. Less time, less drift rate, more time, way more drift rate. I believe that this setting influences the drift, like it gets back to the value you have set (i.e. 45 min) as soon as you do a update.

I'll do a mission, the same mission as I always do to test it, but starting from a cold start and alignment, and see if the same phenomenon still occurs.

Edit: As of note, NotSo said that the ASL bug is known and is being worked on.  

Edited July 26, 2023 by SloppyDog