How much INS deviation can we expect on a 500nm enroute or 45 mins of flight with GPS on?

[darkman222]

How much INS deviation can we expect on a 500nm enroute or 45 mins of flight with GPS on?

Situation as follows.

Date set to 2016 aka GPS active era. Air spawn, everything already setup correctly.

1. Spawn 10 nm of the target (middle building) no deviation.

2. Spawn 500 nm away. 45 mins flight. Deviation is about 400 ft. ( no copy of the F16 player unit, actually moving it, not touching the waypoint itself)

 

Why? GPS should correct for INS errors continously, or not?

The deviation gets worse the longer the flight or the travel to target. Its not too noticeably starting 100nm away, so I chose 500 nm.

 

Can someone explain?

Tracks attached.

 

Caucasus_10nm_no_deviation.trk Caucasus_500nm_400ft_deviation.trk

Edited April 26 by darkman222

[darkman222]

I tried the same mission now set to 1980 without GPS available, the drift is comparable. So I would expect that INS correction by GPS is currently bugged.

null

[Tarres]

AFAIK, GPS integration in the block 50 is not like the more modern nav systems (Hornet for example) where the system is designed with the gps from scratch. It’s a INS plus GPS in order to enhance navigation without break the budget (using the old ins system as a base)

Sorry for the short answer. Not at home now, I think it’s explained in the manual.

[darkman222]

So well, thats 400 ft drift with GPS on and 500 ft drift with GPS off. With that amount of drift, even with GPS on, Lockheed Martin could have saved a lot more money just not fitting the F16 with GPS lol. Can one of the moderators comment on this observation please? @BIGNEWY?

Edited April 26 by darkman222

[Moonshine]

with GPS, Bluefor Viper at around 40m and redfor (without unrestricted SATNAV active) 100m or more according to this post:

If even with gps you are getting 100+ m of deviation, then something is off as it does not match the „no more than 40m“ claim in the linked post.

there is also bugreports about SPI location drifting etc.. so might be a combination of things that lead to excessive perceived drift. Pretty sure TGP sight picture would not match Hud diamond (or TD box) placement in your track either

Edited April 26 by Moonshine

[ito21]

2 hours ago, Tarres said:

AFAIK, GPS integration in the block 50 is not like the more modern nav systems (Hornet for example) where the system is designed with the gps from scratch. It’s a INS plus GPS in order to enhance navigation without break the budget (using the old ins system as a base)

Sorry for the short answer. Not at home now, I think it’s explained in the manual.

It's not an EGI correct (sadly we missed EGI by a year since ED picked a 2007 era bird) however it's still a coupled nav system with GPS and INS talking to each other. EGI essentially took two LRUs and combined them into one and more tightly coupled them. Since the user also showed that flying pre-gps time frame and that the drift was roughly identical it's showing that in this modeling ED has chosing GPS and INS don't talk to each other like they should.

[darkman222]

As @Moonshine pointed out in the mini updates from 10 April 2024:

Which means that it should drift no more than 131 ft.

So the WPT has to be between the middle house and one of the surrounding houses like so:

 

Edited April 26 by darkman222

[Nealius]

While we don't have an EGI, the real manual for this system states that the Kalman filter continuously updates the RLG INU with GPS data as errors are accumulated, and that errors tend to accumulate in 84-minute cycles, with 16m spherical error probable on military GPS. With an 8-minute or less alignment that indicates RDY, CEP is stated as 0.8nm per hour. This is also valid for stored heading alignments. The Kalman filter with status HIGH has a position error less than 300ft, however the manual also states the same as the mini-update that GPS accuracy is 40 meters.  

The last time I tested, the Kalman filter/GPS was working and keeping error within 300ft. Using INS only drift rate was exceeding 0.8nm/hr, showing a drift of 0.8nm (going off the DED delta when doing a fix) after only 30 minutes of flight after a cold start, so drift rate seems to be twice as fast as it should be. 

400-foot drift with GPS on shows that the Kalman filter is no longer working.

People constantly complain about nav accuracy with JDAMs but the bigger issue, especially now with Cold War Germany, is that we cannot do pre-planned pops as the Viper was designed to do in that era because the nav system and HUD symbology is too inaccurate for weapons delivery. Sure CCIP gets your bombs on the target, but the VRPCCRP/VIPCCRP and OA1/2 plus TD box symbology is supposed to put you on a proper wire, which is dive bombing 101 fundamentals. The drift is too excessive and fixes too unreliable to get on a proper wire for the intended target.

Fixes don't even work well from a cold start aircraft. They work on an air start and when doing a fix almost immediately after mission start, but when doing a fix after cold start and a 30+ minute ingress, only the selected STPT gets fixed and the remaining STPTs on the flightplan do not get updated.

14 hours ago, ito21 said:

sadly we missed EGI by a year since ED picked a 2007 era bird

2003 Block 50 manuals have EGI. F-16.net discussions indicate Block 50s had EGI by 2005. Our INS+GPS supplement system I can only find in late 1990s manuals. Most likely they're modeling a specific tail number that was late to the upgrades.

Edited April 27 by Nealius

[ito21]

7 hours ago, Nealius said:

 

2003 Block 50 manuals have EGI. F-16.net discussions indicate Block 50s had EGI by 2005. Our INS+GPS supplement system I can only find in late 1990s manuals. Most likely they're modeling a specific tail number that was late to the upgrades.

The tctos for EGI from my knowledge show EGI being fully added in 2007 for AD birds(This is seen in the avionics power panel being changed at that time to reflect EGI installs) and not being fully completed till around 2010 ish. Guard units may have gotten them earlier as it seems they tend to get stuff earlier since they are a different pot of money compared to AD units

 

Needless to say ED choose a messy year to put as the reference for the 16

[AlexCaboose]

A greater than 300' error shouldn't be possible with GPS enabled.

[darkman222]

To sum this discussion up. We now have multiple approaches ( DCS F16 manual, Wags' Mini Update post) how INS drift of the F16 should be corrected in DCS. But none of them would allow for a drift of 430 ft as I investigated.

Can one of the moderators clarify, please? @NineLine 

 

 

[LesmoR]

2025/4/27 PM4点59分，ito21说：

The tctos for EGI from my knowledge show EGI being fully added in 2007 for AD birds(This is seen in the avionics power panel being changed at that time to reflect EGI installs) and not being fully completed till around 2010 ish. Guard units may have gotten them earlier as it seems they tend to get stuff earlier since they are a different pot of money compared to AD units

 

Needless to say ED choose a messy year to put as the reference for the 16

So our Viper doesn't get EGI as the Hornet does, despite the fact that ED is modelling a Viper operating several years after the in-game Hornet's service time?

 

[Tholozor]

5 hours ago, LesmoR said:

So our Viper doesn't get EGI as the Hornet does, despite the fact that ED is modelling a Viper operating several years after the in-game Hornet's service time?

 

[darkman222]

Can we take a shortcut in the discussion here? If out viper does not have EGI. What would be the maximum INS Drift possible until GPS together with the other implemented systems would correct it, to what allowable error?

If you guys want to discuss EGI in particular you can use the thread posted above.

 

 

 

Edited May 2 by darkman222

[Tholozor]

My understanding of real-world documentation that I've read (outside of the DCS manual) is that the system nav solution is raw INS info, plus master nav filter delta. If the delta exceeds 300 feet, it will then apply an update to the INS position. Based on this, I would assume that position errors should never exceed 300 feet provided SYS ACCUR and GPS ACCUR are both listed as HIGH on the NAV STATUS page.

If GPS ACCUR is HIGH, estimated horizontal error for Precise Positioning Service or Standard Positioning Service for the GPS satellites should be less than 300 feet (if at least four satellites are tracked).

[Muchocracker]

9 hours ago, Tholozor said:

My understanding of real-world documentation that I've read (outside of the DCS manual) is that the system nav solution is raw INS info, plus master nav filter delta. If the delta exceeds 300 feet, it will then apply an update to the INS position. Based on this, I would assume that position errors should never exceed 300 feet provided SYS ACCUR and GPS ACCUR are both listed as HIGH on the NAV STATUS page.

If GPS ACCUR is HIGH, estimated horizontal error for Precise Positioning Service or Standard Positioning Service for the GPS satellites should be less than 300 feet (if at least four satellites are tracked).

Would have to get raptor in here to clarify, but the last i time i asked him about it he described that the INS and GPS systems are more or less completely sepate and don't interact with eachother. With the MMC and its kalman filter creating a blended output of both solutions. The filter would kick in when the delta exceeds 300 feet and weight the GPS with a higher bias to confine the blended position error within that box. The system would be pretty much running that state from then on until the solution delta's are driven back under 300 feet (ala INS FIX)

Edited May 3 by Muchocracker

[Tholozor]

1 hour ago, Muchocracker said:

Would have to get raptor in here to clarify, but the last i time i asked him about it he described that the INS and GPS systems are more or less completely sepate and don't interact with eachother. With the MMC and its kalman filter creating a blended output of both solutions. The filter would kick in when the delta exceeds 300 feet and weight the GPS with a higher bias to confine the position error within that box. The system would be pretty much running that state from then on until the solution delta's are driven back under 300 feet (ala INS FIX)

That also matches documentation I've read that specifies the INU is updated "continuously" by the MMC Kalman filter through GPS data. Curious. Too bad we don't have INSM implemented yet as a sort-of "debug" we could use to monitor simulated data.

[Muchocracker]

Well as raptor described it's not actually updating the INS. It's rather just changing the weights of the blended solution to use the GPS more. The INS would keep drifting at its normal rate with no change continuously until a fix is performed. 

I guess another way to put it would be while the kalman filter is trusting the INS from 0 to 300 feet position delta it would be smooth. When it's blending the GPS in, the drift is going to a bit random (because GPS is noisy) but wont exceed 300 feet or error. 

20 minutes ago, Tholozor said:

Too bad we don't have INSM implemented yet as a sort-of "debug" we could use to monitor simulated data.

Yeah having a lot of the debug tools in general would be a nice to have.

[Mapi]

It's all interesting, but we don't have GPS satellites and I don't think we have a kalman filter, just a flat map: 0x/0y x nx/ny.  It's all just eye candy

[darkman222]

Here is a whitepaper ED released and it mentions the Kalman filter as well as a maximum allowable drift of 300ft:

https://www.digitalcombatsimulator.com/upload/medialibrary/941/fsjcbyvt707ib9q7s7szpsra373gxak7/F-16_INS_White_Paper.pdf

Although the Viper mini updates section in the forums state a maximum drift to expect is 40m or 131 feet.

Edited May 3 by darkman222

[Muchocracker]

26 minutes ago, darkman222 said:

Here is a whitepaper ED released and it mentions the Kalman filter as well as a maximum allowable drift of 300ft:

https://www.digitalcombatsimulator.com/upload/medialibrary/941/fsjcbyvt707ib9q7s7szpsra373gxak7/F-16_INS_White_Paper.pdf

Although the Viper mini updates section in the forums state a maximum drift to expect is 40m or 131 feet.

 

The wording of the whitepaper isnt the best which is why i included the clarification that i (fuzzy, admittedly) recalled from raptor. 131 feet drift number used there would be kind of a "nominal" random drift occurance from the increased weighting of GPS into the blended solution. It could at times be better than that or worse depending on conditons obviously. 300 is just the desired threshold to start using it.

Edited May 3 by Muchocracker

[skywalker22]

There is an interesting question how are the satellites modelued in DCS, since as far as I know, the maps in DCS are flat, they are not placed on a true spherical earth. Or am I wrong? I found some interesting video of Grim Rerapers from 5 years ago, where they tested how are satellites modeled, or embedded into the game. But they didn't come to the final conclusion.
It's quite difficult to replicate paths of the satellites which circle the earth, onto a game with flat maps, and bigger the maps, more complicated it gets. And three is another issue, the distances between 2 points are not the same on sphere and the flat map, as map projections cannot fully reflect the spherical shape of the earth.

[Muchocracker]

You can do some math to emulate all of the spherical earth stuff. Or at least most of it.