[RESOLVED] Ins Position Update

[fjacobsen]

Hello,

 

When I do a waypoint flyby position update, if I press the REC button wherever inside the radius of 15 nautical miles and then press the VAL button the INS drift will be set to 0. I don't need to fly over the landmark's waypoint.

 

I do my best with my English but here is a video showing this "feature".

 

https://youtu.be/1jFciXIU3S0

 

 

 

 

Any news on this issue ?

It´s a long time since it was reported.

 

 

The way it should work is like on the AJS37 Viggen.

 

 

Is it just me, or is progress slow on this module ?

[myHelljumper]

Progress is voluntarily slowed down for the moment :

 

https://forums.eagle.ru/showpost.php?p=3071866&postcount=4454

 

But things are still moving :

 

https://forums.eagle.ru/showpost.php?p=2618507&postcount=1

 

When their reasons to give priority to the harrier are cleared I'm sure the progress will resume at full speed :).

[fjacobsen]

Has this been fixed ?

[Tripleinside]

Nope.

[Joni]

:(

[Jack McCoy]

Still an issue.

 

That's one annoying thing about DCS full-fidelity models: rack you brain trying to understand stuff, go crazy at odd hours of the night, only to find out it's a glaring bug... :(

 

That actually kept me away from BlackShark in the early days. More time doing QA than actual flying/enjoying. :(

[Sanatog]

Can anyone confirm if there are still issues with the INS, specifically with position update?

 

I just picked up the 2000 in the sale and I'm running through the training missions. And at the moment I am unable to get the updates to work, regardless of radar update or not. Similarly INS bombing always fails as again i cant update the IP.

[Tripleinside]

And even if you could, INS bombing would fail because it lacks precision, and because the auto release is not working in PI mode... lol !

 

 

I can update the UNI in flight (REC+VAL) it's just very basic: you don't have to radar range the point in OBL mode, or even fly over the point. Just hit REC+VAL below 10 Nm of the waypoint, and the UNI will update

 

 

=> This aspect of the UNI is very badly modeled, and is in dire need of fixing...

[Sanatog]

Thanks, that explains all the issues I was seeing. REC+VAL did appear to do something, it just didn’t seem to update to where I pressed the buttons.

[Nansaram]

INS Position Update still not working now.

 

with REC button, the delta is catched, but with VAL button, it reset to 0 and NAV position does not changed.

[Kercheiz]

INS Position Update still not working now.

 

with REC button, the delta is catched, but with VAL button, it reset to 0 and NAV position does not changed.

 

 

In 2020, REC does not even compute/display any delta now. It seems impossible to update the INS.

 

 

 

This makes AG bombing almost useless for small, hard to spot targets.

[Frederf]

I just did an offset (radar) and an overfly update and it showed delta info and changes my 00 coordinates on VAL.

 

It's working the same today as it was last year. It's still doing the wrong update logic (making INS perfect) but it's doing what it used to.

 

When you want to check INS update logic make a deliberate large error in 00 coordinates (e.g. 30 minutes of Lat or Long) and then run the update. Since the update always perfects the INS you won't see a very large change is the drift was small.

[Kercheiz]

I tried again and it worked... strange. I confirm you don't need to overfly the point to do a perfect update.

 

 

 

I maybe tried in A/G BF mode the first time.

[RAZBAM_ELMO]

Sorry for getting to this one late, yes known and team has been trying different ways to work around it.

[Ramsay]

Sorry for getting to this one late, yes known and team has been trying different ways to work around it.

 

TL;DR:

 

Good to know it's being looked at.

 

Detail / Speculation

 

• Overfly update might be fairly straight forward as the aircraft's INS coordinates "simply" need to update to those of the selected waypoint.

 

• OBS is a little more difficult as both the HUD diamond position (7 pixel high) and radar range measurement are fairly inaccurate ATM.

 

AFAIK the Harrier's TGP area track displays slant range well, so a "cheat" would use similar logic and the HUD OBS diamond - rounding errors, etc. should hopefully make it less than perfect.

 

The maths is "easy" i.e. selected waypoint coordinates +/- radar ranging offset.

 

For info. - How INS update was working in 2.5.5.x

 

https://forums.eagle.ru/showthread.php?p=4198819#post4198819

[Frederf]

The mathematics is easy (pseudocode).

 

Overfly update

positionAssumed = waypointPosition;

 

Radar offset update

positionAssumed = funcNewLocationFromPositionAndVector( waypointPosition, -vectorToUpdate);

 

Here's an example of a radar offset update long hand:

Waypoint N41°30' E039°21'

Radar info 280°T 8120m

 

(8120 x cosine(280)) / 111111 = 0.012690 or 45.7''

(8120 x sine(280)) / (111111 x cosine(41.5)) = -0.09609 or -5'45.9''

 

N41°30' - 45.7'' = N41°29'14.3''

E039°21' - -5'45.9'' = E039°26'45.9''

 

New "00" position N41°29'14.3'' E039°26'45.9''.

 

Check that from N41°29'14.3'' E039°26'45.9'' to N41°30' E039°21' is 280 8120m. It's close maybe could be better. The hard work is deriving a new coordinate based on a given position and a vector.

 

Considering that the module probably has access to the XYZ positions of the assumed point, waypoint, and radar offset point you would convert all of them into XYZ then do the subtractions in XZ and when you're done convert that XZ into a coordinate to display on the PCN.

 

E.g.

Waypoint X 6000, Z 9000.

Actual Ownship X 7500 Z 8500

Actual Radar Point X7900 Z 8900

 

Then radar vector is X+400, Z+400. If waypoint is X 6000, Z 9000 then Assumed Ownship must be updated to X 5600, Z 8600.

 

Checking that from 5600, 8600 to 6000, 9000 is a +400, +400 which is the same as the delta from the actual own to actual radar.

[RAZBAM_ELMO]

Appreciate the effort to help correct this guys but the logic the SDK follows may not always translate well from IRL to game. Like I mentioned before the team is exploring variations and options to better increase the realism between the IRL system and the system in game.

[myHelljumper]

Appreciate the effort to help correct this guys but the logic the SDK follows may not always translate well from IRL to game. Like I mentioned before the team is exploring variations and options to better increase the realism between the IRL system and the system in game.

 

Perfect, hope they find a solution for this :).

[RAZBAM_ELMO]

Perfect, hope they find a solution for this :).

They are on it.

 

Sent from my SM-N960F using Tapatalk

[dorianR666]

On 12/27/2016 at 12:06 PM, Boagord said:

When I do a waypoint flyby position update, if I press the REC button wherever inside the radius of 15 nautical miles and then press the VAL button the INS drift will be set to 0. I don't need to fly over the landmark's waypoint.

Just wanted to report that this ^^^ is still true 4 years later, as of current OB.

 

Having to do correct INS fixes is half the personality of strike missions in these pre-GPS aircraft (Viggen etc.). Disappointing that this doesnt work...

Edited December 25, 2020 by dorianR666

[dorianR666]

To express it in pseudocode

 

Current incorrect behaviour:

ins_coordinates := real_plane_coordinates

Expected behaviour:
ins_coordinates := entered_coordinates_of(selected_waypoint)

 

 

 

Or if RAZBAM implemented the INS drift as separate variable, instead of continuously modifying INS coordinates

 

Current incorrect behaviour:

ins_drift := 0

Expected behaviour:

ins_drift := entered_coordinates_of(selected_waypoint) - real_plane_coordinates

Edited December 25, 2020 by dorianR666

[myHelljumper]

Hi, this should've been fixed in the last update. I'll move this to resolved, if you still have issues, post them here I'll reopen the report.

 

Thanks.