INS UPDATE

Alignment Error and INS Updates

A little additional detail on how INS updating currently "works".

Here, I've added a 2 minute / 2 NM alignment error during a cold start alignment and you can see the HUD waypoint "+" corrects itself after an "Overfly" update several miles away.

... it looks like INS drift and update is very close to being finished, it's just a shame Razbam has left it as WIP since release.

A little additional detail on how INS updating currently "works".

 

Here, I've added a 2 minute / 2 NM alignment error during a cold start alignment and you can see the HUD waypoint "+" corrects itself after an "Overfly" update several miles away.

 

 

... it looks like INS drift and update is very close to being finished, it's just a shame Razbam has left it as WIP since release.

Thanks for Ramsay for your so fast and great answer. Top community

I first had to test it with the Hoover Dam as waypoint 1, with the training mission M2 it did not work for me. I was of the opinion that only the drift of the waypoint is reset in the Flyby Update. (And does not concern the own position), which turned out to be wrong. With the update all positions are reset to their true origin. That corrects the drift that occurs after a certain time. It is not necessary to update the update above the crosshairs, it has to be done within the 10 NM where you see the crosshairs in the HUD. This also applies to the radar INS update. You don't have to bring the diamond in the HUD exactly to the point. You only have to be within the 10 NM range where the crosshairs are visible and have already hiked. If you now press the INS Update button the original state is restored and the crosshairs in the HUD move back to their old position. So the waypoint is not redefined, so the diamond does not have to be exactly over the target but only in range. See picture Drift in HUD and after Position Update WP1. Please correct me if I get it wrong.

Kind regards and thanks

Mario

If you now press the INS Update button the original state is restored and the crosshairs in the HUD move back to their old position. So the waypoint is not redefined, so the diamond does not have to be exactly over the target but only in range.

Correct, though AFAIK that's not how it works IRL.

Perhaps one day Razbam will make it so you have to Overfly a waypoint/landmark or place the HUD diamond correctly to accurately update the aircraft's INS/position i.e. to the waypoint's co-ordinates.

See picture Drift in HUD and after Position Update WP1.

Good pictures.

Please correct me if I get it wrong.

You understand how it's working in DCS :thumbup:

It´s a real shame that Razbam seemingly aren´t able to code this realistic.

They just have to look at the HB Viggen.

Perhaps one day Razbam will make it so you have to Overfly a waypoint/landmark or place the HUD diamond correctly to accurately update the aircraft's INS/position i.e. to the waypoint's co-ordinates.

I really don't understand why this hasn't been implemented after all those years?!

The INS update is almost complete, but this very important part is still missing and without it the INS update is just a superficial cheat that allows you to reset drift at any time at any place without all the challenges that a proper INS fix should have (see F-14 and the Viggen for proper INS update functionality).

I'm really frustrated by this :mad:

Meanwhile they're anouncing a new aircraft module every few months...

I really don't understand why this hasn't been implemented after all those years?!

 

The INS update is almost complete, but this very important part is still missing and without it the INS update is just a superficial cheat that allows you to reset drift at any time at any place without all the challenges that a proper INS fix should have (see F-14 and the Viggen for proper INS update functionality).

 

I'm really frustrated by this :mad:

+1. This and the PI bombing and CCRP bombing bugs are all 3 years old. It's unreal.

+9999999999999999999999

It's one of those immersion-killer bugs that the M2000 still has after I don't remember how many years

It´s a real shame that Razbam seemingly aren´t able to code this realistic.

They just have to look at the HB Viggen.

I don't really understand DCS SDK coding but can it be really that difficult? Basically the PREP'd waypoint lat/long has to be copy-pasted directly into current aircraft lat/long position, as soon as you hit the rec button, that'd be all it's gonna take. After val, all waypoints as recognized by INS get shifted by the same offset vector w.r.t. flight plan wpts as the current deviation between your PREP selected flight plan wpt and your set position for that wpt (provided perhaps your rec value also has some minor error).

Now for radar correction it can be a little bit more complicated, depending on where the radar diamond is pointing and distance to that point.

I don't really understand DCS SDK coding but can it be really that difficult? Basically the PREP'd waypoint lat/long has to be copy-pasted directly into current aircraft lat/long position, as soon as you hit the rec button, that'd be all it's gonna take. After val, all waypoints as recognized by INS get shifted by the same offset vector w.r.t. flight plan wpts as the current deviation between your PREP selected flight plan wpt and your set position for that wpt (provided perhaps your rec value also has some minor error).

 

 

 

Now for radar correction it can be a little bit more complicated, depending on where the radar diamond is pointing and distance to that point.

I think you're right, even for radar correction we know there is a CCRP method that is choosing a location at the end of the day, which gets plotted on your HUD. I think the problem might be deeper than this. What if they're not modeling drift at all, rather just shifting the waypoints around to make it look like drift? This would explain why it's not done and why the waypoints resolve to the correct position. Would also explain why waypoint positioning in general in the Mirage is screwy.

Pure speculation of course. If they are actually modeling drift, I have no idea why they wouldn't finish the INS, because all of the hard parts are done already (designating positions, modeling actual drift, VAL function).

However, if drift is being "faked", this would explain it a bit better.

Still, 3 years for this is way too long. It's core systems functionality in the Mirage, not some edge case procedure.

rather just shifting the waypoints around to make it look like drift?