Help getting highest INS accuracy for pre-planned popups

[SpecterDC13]

1 hour ago, Nealius said:

The PR managers/beta testers/officials I was interacting with have all the terrains. Nowhere did I expect people other than them, nor specifically you, to have Kola. 

Ok and that is fine, but don't come at me for not watching your tracks. And when has the ED team ever been the only ones able to help people? 

[QuiGon]

I've been following this thread with quite some interest for a while now as I'm very curious about the current INS behaviour and accuracy. Unfortunately I feel like the thread is steering off topic by a lot now, as the original question by @Nealius was targeted at the accuracy and behaviour of the F-16s INS and its interaction with GPS, not about JDAM accuracy, so I don't really understand why there is all this talk and tests on JDAM accuracy now. As @Lord Vader has pointed out several times in this thread, JDAM guidance doesn't work properly as of now (at least if used with INS provided STPs) and is very much WIP atm.
tldr: JDAM accuracy is a different issue than the accuracy of the F-16s INS.

I would very much like to see this thread to go back to address the original question if the F-16s INS is actually doing what it's supposed to do and if GPS and manual fixes update it properly, so that it is possible to deliver unguided munitions precisely as described in the original post by @Nealius:

On 10/13/2024 at 7:45 AM, Nealius said:

I've been doing a lot of pre-planned pop ups as described in books like Vipers in the Storm, and I'm having trouble getting enough INS accuracy for the HUD symbology to get me on a good wire for the planned delivery. Everything ends up shifted some 200ft while the system tells me I have a delta of 0.00nm and accuracy high for both SYS and GPS. 200ft is fine for TGP work and guided munitions, but for pre-planned popups this shifts the VRP/VIP, the PUP, the pulldown (OA1) and the AOP (OA2), as well as the TD box, enough that major corrections are required to get on a good wire for delivery, when we should be able to line up the FPM on the OA2 triangle, on the wire intersecting the TD box, then switch CCIP without having to do so many last-second corrections. After all, that's the whole point of the VRPCCRP/VIPCCRP system, as I understand it from written pilot accounts. Prior to the new INS/GPS features, I was able to follow the popup symbology bang on and hit every number as calculated.

Setup: 2005 mission, unrestricted SATNAV, Kola, steerpoints on centerpoint of bridges for easy nav fixes, target not more than 100 or so miles from departure field, first STPT/fix point on center of bridge 35nm from target, second STPT/fix point on center of bridge 16nm from target. Running a fix on these two points should make sure everything's good, but for some reason it's not working for me.

When checking my first fix point, using the TGP the pod is exactly on the bridge centerpoint, FIX delta 0.00nm, SYS and GPS accuracy HIGH, so I don't run a fix yet. I go low, pulling no more than 3G perhaps, and when approaching the bridge the STPT diamond is shifted away from the centerpoint and on the end of the bridge, some 200ft off from where it should be. FIX delta still says 0.00nm, SYS and GPS accuracy HIGH, but I do a HUD fix by slewing the diamond over the bridge center and press ENTER (per Wag's YouTube tutorial), however the diamond snaps back to the edge of the bridge, as if the fix didn't take.

Approaching second fix point, same issue. STPT diamond in the HUD is shifted to the end of the bridge. Slew diamond over center point, hit ENTER for a HUD fix. Diamond reverts to old position. FIX still says delta 0.00nm, SYS and GPS accuracy HIGH.

Execute my pop, ID target, roll in and put the FPM on the AOP triangle, notice TD box is shifted a ways behind the target. Thus my AOP is shifted behind where it should be, my dive angle is shallower than it should be, and my track time (calculated to be 5 seconds) is now about 2 seconds because the symbology is so far off of the actual target. On egress, another one of my bridge waypoints was shifted about the same amount as well, this time checking the FIX as delta 0.00nm, SYS accuracy MED, GPS accuracy HIGH. 

An interesting pattern I noticed with this drift is that it always drifts in the direction of my origin airfield. E.g. if the target area is 150 from where I started, the symbology shift is roughly the reciprocal, 330, from the actual STPT. Starting from a field on the opposite side of the map, the drift is observed to also be opposite. 

Sometimes I think it's not the INS/GPS itself shifting, as the TGP seems to get on point just fine, and there are times where the TGP is right on a taret but the HUD/HMD TD isn't quite in the right spot, so it seems like the HUD symbology is the only thing actually being shifted. Is there something I'm missing to get the HUD symbology more accurately on my STPTs and/or targets?

 

@Nealius I would also appreciate it if you could use the Caucasus map to demonstrate the issues that you're seeing, not just because not everyone has the Kola map available, but also because the map itself might introduce issues (Kola has a very broad range of varying magnetic declination, which might play a role here). So it would be good to know if you experience the same issues using the Caucasus map.

Edited November 1, 2024 by QuiGon

[SpecterDC13]

3 hours ago, PawlaczGMD said:

Looking at the briefing for that mission:

- 14 Apr 2015 on Syria

- altitude around 20-25k ft, speed around 300-350 kts IAS, I release at around 10-20% into the max "dynamic launch zone" or whatever it's called for JDAMs. It's a GBU-31.

- normal weather with heavy clouds

- no sensors used, because of full cloud coverage. Just release on STPT that is preloaded from the mission ( I didn't need to enter it manually)

- I assume GPS is available. I think I remember checking INS accuracy and both INS and GPS were very high. I switched it on.

 

Syria GBU31.trkIt worked for me. How long are you flying before you drop? And are you doing any hard maneuvering like pulling more than 6+Gs and if so, how many times?

34 minutes ago, QuiGon said:

I've been following this thread with quite some interest for a while now as I'm very curious about the current INS behaviour and accuracy. Unfortunately I feel like the thread is steering off topic by a lot now, as the original question by @Nealius was targeted at the accuracy and behaviour of the F-16s INS and its interaction with GPS, not about JDAM accuracy, so I don't really understand why there is all this talk and tests on JDAM accuracy now. As @Lord Vader has pointed out several times in this thread, JDAM guidance doesn't work properly as of now (at least if used with INS provided STPs) and is very much WIP atm.
tldr: JDAM accuracy is a different issue than the accuracy of the F-16s INS.

I would very much like to see this thread to go back to address the original question if the F-16s INS is actually doing what it's supposed to do and if GPS and manual fixes update it properly, so that it is possible to deliver unguided munitions precisely as described in the original post by @Nealius:

@Nealius I would also appreciate it if you could use the Caucasus map to demonstrate the issues that you're seeing, not just because not everyone has the Kola map available, but also because the map itself might introduce issues (Kola has a very broad range of varying magnetic declination, which might play a role here). So it would be good to know if you experience the same issues using the Caucasus map.

 

Yeah there are quite a few posts already about the JDAM and Ive been trying to tell people that it is still work in progress as told by Lord Vader multiple times. But they still want to argue about the JDAM stuff for some reason. Currently about to test the original stuff now.

[SpecterDC13]

On 10/12/2024 at 10:45 PM, Nealius said:

I've been doing a lot of pre-planned pop ups as described in books like Vipers in the Storm, and I'm having trouble getting enough INS accuracy for the HUD symbology to get me on a good wire for the planned delivery. Everything ends up shifted some 200ft while the system tells me I have a delta of 0.00nm and accuracy high for both SYS and GPS. 200ft is fine for TGP work and guided munitions, but for pre-planned popups this shifts the VRP/VIP, the PUP, the pulldown (OA1) and the AOP (OA2), as well as the TD box, enough that major corrections are required to get on a good wire for delivery, when we should be able to line up the FPM on the OA2 triangle, on the wire intersecting the TD box, then switch CCIP without having to do so many last-second corrections. After all, that's the whole point of the VRPCCRP/VIPCCRP system, as I understand it from written pilot accounts. Prior to the new INS/GPS features, I was able to follow the popup symbology bang on and hit every number as calculated.

Setup: 2005 mission, unrestricted SATNAV, Kola, steerpoints on centerpoint of bridges for easy nav fixes, target not more than 100 or so miles from departure field, first STPT/fix point on center of bridge 35nm from target, second STPT/fix point on center of bridge 16nm from target. Running a fix on these two points should make sure everything's good, but for some reason it's not working for me.

When checking my first fix point, using the TGP the pod is exactly on the bridge centerpoint, FIX delta 0.00nm, SYS and GPS accuracy HIGH, so I don't run a fix yet. I go low, pulling no more than 3G perhaps, and when approaching the bridge the STPT diamond is shifted away from the centerpoint and on the end of the bridge, some 200ft off from where it should be. FIX delta still says 0.00nm, SYS and GPS accuracy HIGH, but I do a HUD fix by slewing the diamond over the bridge center and press ENTER (per Wag's YouTube tutorial), however the diamond snaps back to the edge of the bridge, as if the fix didn't take.

Approaching second fix point, same issue. STPT diamond in the HUD is shifted to the end of the bridge. Slew diamond over center point, hit ENTER for a HUD fix. Diamond reverts to old position. FIX still says delta 0.00nm, SYS and GPS accuracy HIGH.

Execute my pop, ID target, roll in and put the FPM on the AOP triangle, notice TD box is shifted a ways behind the target. Thus my AOP is shifted behind where it should be, my dive angle is shallower than it should be, and my track time (calculated to be 5 seconds) is now about 2 seconds because the symbology is so far off of the actual target. On egress, another one of my bridge waypoints was shifted about the same amount as well, this time checking the FIX as delta 0.00nm, SYS accuracy MED, GPS accuracy HIGH. 

An interesting pattern I noticed with this drift is that it always drifts in the direction of my origin airfield. E.g. if the target area is 150 from where I started, the symbology shift is roughly the reciprocal, 330, from the actual STPT. Starting from a field on the opposite side of the map, the drift is observed to also be opposite. 

Sometimes I think it's not the INS/GPS itself shifting, as the TGP seems to get on point just fine, and there are times where the TGP is right on a taret but the HUD/HMD TD isn't quite in the right spot, so it seems like the HUD symbology is the only thing actually being shifted. Is there something I'm missing to get the HUD symbology more accurately on my STPTs and/or targets?

 

Just set something up on Caucasus. INS Drift HUD & JHMCS sym.trk this was with unrestricted SATNAV and 2005. Setup was about the same distances as you mentioned give or take. During the flight I monitored my NAV page on the DED and at some point, during the flight the SYS ACCUR turned to MED. Did a FIX on the first STPT which was not over where I had put it, it changed back to HIGH after fix taking. On my way to STPT two my SYS ACCUR turned back to MED. Did another FIX on STPT 2.

On the way to the target none of my points were where they should've been. Afterwards, I stuck around and looked at each point and each one was in a different place if I was looking through the JHMCS or the TGP. Seems like some type of an issue with symbology alignment maybe. So, if I took a fix using the JHMCS then the TGP wouldn't line up to the same spot. If I took it with the TGP then the diamond in the JHMCS wasn't in the same spot. I think this misalignment between the two is what is causing the issue. So, no matter if you actually need to take a fix or not the symbology is not going to match each other resulting in a weird sighting error. 

Pretty sure that wherever the diamond is looking should be the same spot that the TGP is looking. If they didn't match each other then you are going to get what we are discovering here. And since the TGP can control the SPI placing the TGP over a TGT and then looking through your JHMCS the TD BOX or diamond should be over the same spot. I feel like that is just fact. 

It definitely through me for a loop when looking out the cockpit and saw my TD BOX away from the tgt. Caused me to overshoot my pulldown height and because the TD BOX was closer to me than it should've been I came in shallower once I lined up for the target. 

 

Point of the matter seems to be:

- The HUD/JHMCS indicates small to large drifts.

- Unrestricted SATNAV at least in the year 2005 in the ME seems to make the SYS ACCUR go to MED randomly (seems not right? especially after a very short period of time)

- Sensors don't line up with each other it seems like causing confusion on where you are supposed to be looking

So really, I don't think it is so much the drift being the issue rather than the sensors (TGP and HUD/JHMCS) not matching each other. If I look through my HUD or JHMCS and notice my diamond for example isn't where it should be then when I go to take a FIX and I move the diamond over where it should, if I notice the delta exceeds the 300ft (~0.06NM) when I take that FIX ALL sensors should be looking at the same spot then. They shouldn't be looking in different areas like they are cross-eyed.

"In order to perform a FIX/update certain factors must be met, and they can include: SYS ACCUR, GPS ACCUR, and GPS TRK/NOTRK. Now assuming normal GPS values of <50 feet and GPS in track, the Blended KF will have more confidence in GPS-aiding than a 300ft fix/update. But once the SHE exceeds 300ft for whatever reason, then a fix/update on a known stpt may be recommended. The position delta is estimated from the coords of the stpt. That delta is displayed to you on the FIX page."

[Nealius]

@QuiGon When I have time to prioritize unpaid beta testing on Caucasus I will revisit this. For the moment I need a break from tedium.

Edited November 2, 2024 by Nealius

[PawlaczGMD]

23 hours ago, SpecterDC13 said:

Much appreciated. I will test this out. But in the meantime, read this and try adjusting and let me know your results please.

Go into the mission briefing area before going into the mission and make sure the stpt is at the base of the target (so at whatever side of the building you will be coming from). Also verify the coordinates both in the mission brief and on your DED Nav page to ensure they match to include elevation.

So the max range for the GBU-31 is 15NM under the right conditions (doing about 450-475 KCAS @25000ft, and hopefully no headwind). If you are doing 300-350 you are making that distance shrink down to about 5 to 8nm, so I would have to guess you're dropping inside that? Which is fine if you are trying to achieve a top-down attack on the target. I would still suggest bumping the speed up though and you can still drop at no less than 6NM. 

So it would look like this:

-25000ft MSL

-450-475KCAS (I know damage to weapons isn't implemented but try not to exceed .98 Mach if you can help it lol)

-set your Impact Angle on the control page to 75-80 degrees. (This will ensure a more top-down attack. If you set this and try release at 10nm the bomb will not achieve these angles on impact)

Try that and let me know the results please. I will test your scenario out in the meantime. 

 

TBH I'm not going to refly this mission, I just took the L and points deduction and moved on.

I know that higher speed will give me a greater range, but this is not the issue here - I'm releasing in range based on HUD cues the a/c calculates.

The STPT would definitely move from the building due to drift - that's the issue. I know I can use TGP to move it back on, but my problem is that it's not always possible, and shouldn't be necessary.

[LastRifleRound]

It's pretty sad this thread dead-ended because no one wanted to directly address the primary questions at hand.

1. Is 240m of drift within 1/2 hour of normal (no extreme maneuvers) flight with GPS on acceptable? It is undoubtedly happening, the evidence posted in this thread and the work @Nealius put in demonstrate this clearly.

2. Why does FIX not update subsequent waypoints, with our without GPS on?

You guys need to go with preponderance of evidence. This clearly isn't right. Either you shouldn't have made videos telling people to use FIX, or FIX isn't working properly, and I'd bet my house FIX isn't working properly. There is no way on God's green earth that FIX only updates the single waypoint you use it on. There is no way the Kalman filter filters out fixes because it weighs LITERALLY every single INS data point the same. It doesn't. There is no way the Kallman filter rejects nav fixes because they don't exceed 300m, but doesn't reject also the INS data that induces drift under 300m. The logic itself is incoherent.

Out of curiosity @Nealius have you tried using ACCAL for your first fix with GPS off?

[Nealius]

On 1/31/2025 at 2:33 PM, LastRifleRound said:

Out of curiosity @Nealius have you tried using ACCAL for your first fix with GPS off?

I have not, I'm not familiar with ACCAL. I haven't tested since my last test because I'm tired of trying to report bugs to developers who think they're infallible and refuse to consider they aren't. Most of my bug reports in other modules get completely ignored or conveniently moved to "wish lists" without anyone bothering to investigate.

Edited February 2 by Nealius

[Nedum]

Is there only a guessing of how often, and when, the pilot has to start to "fix" the GPS/INS drift?

Is there no documentation about this procedure? 

Like: After a flight time of yy minutes, you will get a shift of xx to xx feet. To minimize the drift, you have to start the "fix" every yy minutes of the current flight time.

Till now, I have the feeling, even ED doesn't know the answer! Would be nice to have something more than guessing!

For me, it's hard to believe that CCIP bombing (if it would work ;)) is the most accurate and less dangerous way to drop bombs with the F16.

 

[Nealius]

11 hours ago, Nedum said:

For me, it's hard to believe that CCIP bombing (if it would work ;)) is the most accurate and less dangerous way to drop bombs with the F16.

For unguided bombs CCIP is, scientifically, the most accurate way to drop bombs. As already explained multiple times in this thread, the F-16's VIPCCRP/VRPCCRP>CCIP flow and the OA1/2 HUD symbology are specifically designed for pinpoint popup strikes using unguided bombs, to which the USAF specifically trained all the way up to the first conventional strikes in Desert Storm.

[BossBearFace]

Related question but not contributing to the debate: what year does DCS assume we move to the GPS era?

[razo+r]

7 minutes ago, BossBearFace said:

Related question but not contributing to the debate: what year does DCS assume we move to the GPS era?

28.3.1994 is the magical date.

Edited March 17 by razo+r

[Furiz]

So I'm wondering how did they execute pre planned attacks in real world using 2007 F-16C? 

I mean in DCS during cloudy day you can not rely on GPS + INS cause it has drift which you can not fix if you don't see some landmark, but you don't need to cause there is Kalman filter which will blend the data of INS and GPS which will result in error of <300 feet if I got this right?

So how did real pilots correct for these errors? cause atm I can't get an accurate drop without using TGP.

[BossBearFace]

2 hours ago, razo+r said:

28.3.1994 is the magical date.

Thank you.  Appreciated. 

[Nealius]

11 hours ago, Furiz said:

So how did real pilots correct for these errors? cause atm I can't get an accurate drop without using TGP.

Assuming JDAM's, those would be using data from GPS satellites which have no INS drift. A 300ft discrepancy in the jet's position would be too small to matter.

Edited March 18 by Nealius

[Furiz]

4 hours ago, Nealius said:

Assuming JDAM's, those would be using data from GPS satellites which have no INS drift. A 300ft discrepancy in the jet's position would be too small to matter.

I guess when JDAMs are completed it will be better regarding pre planned attacks.

Edited March 18 by Furiz

[Dragon1-1]

Also, JDAMs aren't as accurate as LGBs, and that's a well documented limitation IRL. They are accurate, but not pinpoint weapons. That's why LJDAM exists, and why it makes sense to bring regular LGBs with our Viper if that's what you need. Cloud cover may be a problem, though.

[QuiGon]

On 3/18/2025 at 12:14 PM, Furiz said:

I guess when JDAMs are completed it will be better regarding pre planned attacks.

Yes, JDAM GPS guidance is still WIP as of now.