Jump to content

[NO BUG] INS degradation speed


Recommended Posts

I'm doing some tests about the INS, in particular Updates.

I realized that the INS degrades lat-wise very fast.

 

I did some tests and these are my findinds. I spawned airborne near Kutaisi at 10.000ft and I used its station to test the TACAN Δ. I was in Active Pause except for the last reading.

unknown.png

 

These are some shots, look at the timestamp.

 

bug-ins-latitude-1-40.jpeg

 

bug-ins-latitude-6-40.jpeg

 

bug-ins-latitude-11-40.jpeg

 

I posted the details of my tests here: https://flyandwire.com/2019/07/11/ins-drift-bug/

Check the screenshots slideshow, it gives quite a neat impression of what's going on.


Edited by IronMike

cropped-logo-2021-v1-bw-60px.png

FlyAndWire - A website dedicated to DCS and Arduino

132nd Virtual Wing - 108th vSq (F-14B) and 696th vSq (Ka-50)

VCB: ArmA3 British Army Light Infantry platoon

 

Link to post
Share on other sites

Good report. I haven't done any testing but in the last few days I was also suprised how quickly and massively the INS degraded. I assume this was introduced with the latest patch.

Link to post
Share on other sites

Thats interesting, however I would like to see some results from actual flying and not active pause. I'm a little confused though. How did updating your INS through Tacan fix get your plane several miles away from your original (i.e. true) posiiton?

I never payed much attention to INS accuracy but I will next time, because if this is true the INS needs some serious fixing

i5-8600k @4.9Ghz, 2080ti , 32GB@2666Mhz, 512GB SSD

Link to post
Share on other sites

Last test has been done with no pause (the one at 15') and the INS was still visibly degrading. I have a 2h streaming (did it yesterday) confirming how fast the INS drifts especially latitute-wise. I think it's a quite recent thing, I didn't notice so much drift when I did the first tests months ago (but I may be remembering wrong).

 

 

How did updating your INS through Tacan fix get your plane several miles away from your original
Oh, I didn't even notice that, I was totally focused on the latitude. Yep, looks like something else is going on.

 

 

I never payed much attention to INS accuracy but I will next time, because if this is true the INS needs some serious fixing

I noticed it for two reasons:

1. massive lag during one sessions and we ended up bombing miles away from the target;

2. I'm working on manual GBU delivery procedures with no pod using altitude, dive angle, speed and range. The INS *must be accurate* otherwise it doesn't work.


Edited by Karon

cropped-logo-2021-v1-bw-60px.png

FlyAndWire - A website dedicated to DCS and Arduino

132nd Virtual Wing - 108th vSq (F-14B) and 696th vSq (Ka-50)

VCB: ArmA3 British Army Light Infantry platoon

 

Link to post
Share on other sites

It's the active pause that messes with your INS. The INS "thinks" that it's flying in some direction, and it applies all corrections necessary to keep the platform level, but it doesn't move so the correction is wrong. I've just checked it with my debug tools, and everything is ok until I hit ACTIVE PAUSE. I'll look for a solution to stop updating the INS with active pause in use.

 

Also, I wanted to mention that we model TACAN inaccuracy accordingly to the device specification, so I just wanted to warn you that comparing with that introduce some additional errors.

 

Finally, I wanted to reassure you that we haven't touched the INS for weeks and that I check the debug output regularly and we haven't observed any INS anomalies when the device is used properly.

Krzysztof Sobczak

 

Heatblur Simulations

https://www.facebook.com/heatblur/

Link to post
Share on other sites

Ah, that's interesting! Looks like that the mess caused by the active pause is still present even later. I did the last test for the exact reason of cutting the Active Pause out of the equation and the error instead carried on increasing.

 

Speaking of the TACAN, I assume the range is not ground but slant so don't compare such ranges directly usually.

 

I have two questions though:

I'm doing the same test again but with an active F-14. After 12' the Delta was LN 0°05'1 LW 0°00'6. That's 5nm, quite a lot when dealing with manual bombs release (the drift actually slows down after 10'-15'). Yesterday I had a similar degration (although smaller), that's why today I did more tests. What do you think is the cause of this drift? I tend to exclude the magvar because is shouldn't be more than ±1°.

 

What is the difference between changing the coordinates of the F-14 and following a complete INS Update update procedure? For instance pushing the latlogs through directly via a WP (assuming I can forecast the F-14 position and timing correctly) rather than following the VIS FIX procedure? In other words, does the INS Update change the latlongs only or it does something more?

cropped-logo-2021-v1-bw-60px.png

FlyAndWire - A website dedicated to DCS and Arduino

132nd Virtual Wing - 108th vSq (F-14B) and 696th vSq (Ka-50)

VCB: ArmA3 British Army Light Infantry platoon

 

Link to post
Share on other sites

There's nothing suspicious in the "mess" continuing after unpausing because it's directly linked to the velocity error which is introduced during the active pause period.

 

Yes, the range is slant; however, when applying the INS update, the difference between the aircraft altitude and the TACAN elevation is taken into account.

 

I'm not sure what is your procedure to prime the INS. Did you perform FINE GND alignment? Did you move during the alignment? Or maybe you entered a hot aircraft? There are many reasons leading to such drift. Moreover, it's not scripted, and it's not a simple function. Even when you perform the same alignment twice, each time the error of the alignment (and hence the drift) will be different.

 

Updating own position by editing it through CAP/TID or via VIS FIX should give the same results.

 

I think I don't understand what you call "manual bombs release". The INS should work fine for Computer Pilot or Computer Target but using it for anything else will probably fail.

Krzysztof Sobczak

 

Heatblur Simulations

https://www.facebook.com/heatblur/

Link to post
Share on other sites
I'm not sure what is your procedure to prime the INS. Did you perform FINE GND alignment? Did you move during the alignment? Or maybe you entered a hot aircraft? There are many reasons leading to such drift. Moreover, it's not scripted, and it's not a simple function. Even when you perform the same alignment twice, each time the error of the alignment (and hence the drift) will be different.

 

I spawned airborne and flown straight. I moved to the RIO seat, set up the WP and monitored the TACAN FIX. No active pause.

This is screenshot of the tacview track:

https://www.dropbox.com/s/4i3dh92wmgkw8xt/190711-Tacview.jpeg

And this is a in-game screenshot of the TACAN FIX delta.

https://www.dropbox.com/s/vgy1njn92txldzo/Screen_190711_152004.png

Could it be some anomaly in the MagVar of the map in that area? Because I don't really see any reason why the delta should behave in such way.

I can record and upload the test if you want.

 

 

 

 

No worries about the manual delivery, we can't post natops manual anyway. It's just that I need almost perfect INS precision to use such approach, so the whole point of my tests is understanding how to re-align it in the most efficient and precise way possible. But again, this is unrelated to the issue :)

cropped-logo-2021-v1-bw-60px.png

FlyAndWire - A website dedicated to DCS and Arduino

132nd Virtual Wing - 108th vSq (F-14B) and 696th vSq (Ka-50)

VCB: ArmA3 British Army Light Infantry platoon

 

Link to post
Share on other sites

From the picture you posted, it looks that you are ~45NM from the TACAN, which is far for TACAN FIX. At that distance, the calculated mag var errors and the measured TACAN bearing inaccuracy (don't underestimate this) may introduce significant errors to your position updates. In other words, what you see on the TID, the delta, it's NOT the difference between the aircraft true position and the current position. It's the difference between what the INS thinks is the true position and the current position.

 

Back to manual delivery, we don't need to post any manuals here, but it would be useful to understand what you want to achieve. Because from your description it looks that you may be trying something that the F-14B couldn't do.

Krzysztof Sobczak

 

Heatblur Simulations

https://www.facebook.com/heatblur/

Link to post
Share on other sites

I recorded a test, unfortunately before your last reply:

 

 

I'm not used to use mouse and keyboard so it took me a bit to punch the coordinates so bear with me.

1'22: wp created as HB (Kutaisi AF);

4'00: Delta is good even at 50nm. As I ask Iceman to give me +30° the delta goes up mostly on the latitude.

7'00: Created a new WP for Tblisi and checked the delta. The Magvar in this case is 0°1 deg. I did some tests (cross-hooked WP, changed stations and so on. No impact on anything, as expected).

 

 

I find interesting that the delta increased after Iceman manoeuvred. Is that a coincidence?

Also, the manual reports the loss of precision due to magvar over 100nm as an example; hence I expected the TACAN to be reliable much farther than 45nm (I flew the Ka-50 since 2008 to the F-14 release, so the TACAN is a complitely new toy for me).

 

If that's the case, I guess we can conclude that the delta is mainly due to being to far from the TCN station to expect a reliable computation?

 

Back to manual delivery, we don't need to post any manuals here, but it would be useful to understand what you want to achieve. Because from your description it looks that you may be trying something that the F-14B couldn't do.

It's definitely something that the F-14 is not supposed to do. It works quite well if the INS is well aligned though.

 

 

 

 

 

Btw, I appreciate your patience and explanations mate :)

cropped-logo-2021-v1-bw-60px.png

FlyAndWire - A website dedicated to DCS and Arduino

132nd Virtual Wing - 108th vSq (F-14B) and 696th vSq (Ka-50)

VCB: ArmA3 British Army Light Infantry platoon

 

Link to post
Share on other sites

Are you trying to do manual bombing runs using the manual mode or using any of the computer modes? None of them use a waypoint as the basis for the drop calculations.

 

The inaccuracy of the INS is the reason for this and also why even the Computer/IP mode needs a visual fix before delivery.

Link to post
Share on other sites

I am using the distance from the IP together with the ballistic tables. I use CPTR PL for the sake of having hot trigger. I am aware it's not a supported engagement tactic although it works quite well and gives great results with a buddy-lasing asset. Computer IP will be the method of choice if the pod is not available since it works on an offset rather than latlongs.

 

 

 

Anyway, my issue here was with the INS, which affects AA as well and DL targets quite heavily. But it looks like that it is fine (active pause aside) and was the eccessive range from the TCN station to cause such delta readings.

cropped-logo-2021-v1-bw-60px.png

FlyAndWire - A website dedicated to DCS and Arduino

132nd Virtual Wing - 108th vSq (F-14B) and 696th vSq (Ka-50)

VCB: ArmA3 British Army Light Infantry platoon

 

Link to post
Share on other sites

Just FYI, the bearing accuracy of digital readout of the AN/ARN-84(V) - the TACAN - is between 0.5° (for signals stronger than -82 dBm) and 2.0° (below -90 dBm). And we model that in our TACAN receiver.

 

 

What you observed and recorded in the video is that TACAN inaccuracy together with possible mag var drift.

Krzysztof Sobczak

 

Heatblur Simulations

https://www.facebook.com/heatblur/

Link to post
Share on other sites
I am using the distance from the IP together with the ballistic tables. I use CPTR PL for the sake of having hot trigger. I am aware it's not a supported engagement tactic although it works quite well and gives great results with a buddy-lasing asset. Computer IP will be the method of choice if the pod is not available since it works on an offset rather than latlongs.

 

 

 

Anyway, my issue here was with the INS, which affects AA as well and DL targets quite heavily. But it looks like that it is fine (active pause aside) and was the eccessive range from the TCN station to cause such delta readings.

 

Ok, cool! The manual mode would work the same except for no hud indications at all, this is normally the mode I use when dropping from a LANTIRN on own aircraft and would work well in your case as well. Only difference from computer/plt is the lack of ballistic calculations ofc and thus no HUD indications.

Link to post
Share on other sites
Just FYI, the bearing accuracy of digital readout of the AN/ARN-84(V) - the TACAN - is between 0.5° (for signals stronger than -82 dBm) and 2.0° (below -90 dBm). And we model that in our TACAN receiver.

 

What you observed and recorded in the video is that TACAN inaccuracy together with possible mag var drift.

I also noticed that the delta increases during a manoeuvre then slowly decreases. I suppose that's because a sort of limited size array is filled over time and results are intepolated, hence the system is both more resilient vs noise and interference but slower to recover. If that's correct not using the TCN FIX during a turn but only later should result in a more accurate reading (I haven't tried).

Is that the case (if correct it'd be a big factor to taken into account)?

 

 

Ok, cool! The manual mode would work the same except for no hud indications at all, this is normally the mode I use when dropping from a LANTIRN on own aircraft and would work well in your case as well. Only difference from computer/plt is the lack of ballistic calculations ofc and thus no HUD indications.

Indeed! I use CPT PLT so the pilot (that includes me of corse :) ) as cue that reminds him the hot trigger :)

Jokes aside, I think it's a bit more flexible solution in case something goes wrong and a hasty delivery is required.

cropped-logo-2021-v1-bw-60px.png

FlyAndWire - A website dedicated to DCS and Arduino

132nd Virtual Wing - 108th vSq (F-14B) and 696th vSq (Ka-50)

VCB: ArmA3 British Army Light Infantry platoon

 

Link to post
Share on other sites

Ok, now I have to ask. I just flew a mission. Stored heading alignment on the carrier, launch, climb and cruise with a max G of 2.5. After 45 minutes of flight I had an INS drift of 20 NM. Is this normal? For full disclosure, the carrier was making a turn into the wind before the INS alignment started, which I know would make a stored heading alignment invalid. But I am not sure if this is modeled, since the INS seemed to align normally initially.

Link to post
Share on other sites

The INS has only a limited ability to detect alignment errors. More often it would be just true heading being wrong, and you can only verify it by checking the true heading through CAP+TID (or mag var, but that you'd expect to be off on a carrier). You can't tell if the true heading is wrong by just observing the BDHI or the VDI/HSD/HUD, because they are all magnetic and by design they are default driven from the AHRS. Moreover, even with a very bag alignment, initially the INS will show the correct position, as it's initialized at that position and the initial velocity is zero. However, it will catch some false velocity very quickly.

 

There's another possibility; if it was a multiplayer session with some heavy lags/desyncs, the INS could have sensed large differences between own velocity and the carrier velocity through SINS, leading to significant alignment errors.

Krzysztof Sobczak

 

Heatblur Simulations

https://www.facebook.com/heatblur/

Link to post
Share on other sites
The INS has only a limited ability to detect alignment errors. More often it would be just true heading being wrong, and you can only verify it by checking the true heading through CAP+TID (or mag var, but that you'd expect to be off on a carrier). You can't tell if the true heading is wrong by just observing the BDHI or the VDI/HSD/HUD, because they are all magnetic and by design they are default driven from the AHRS. Moreover, even with a very bag alignment, initially the INS will show the correct position, as it's initialized at that position and the initial velocity is zero. However, it will catch some false velocity very quickly.

 

There's another possibility; if it was a multiplayer session with some heavy lags/desyncs, the INS could have sensed large differences between own velocity and the carrier velocity through SINS, leading to significant alignment errors.

 

Is it possible that the deck sliding during alignment could be negatively effecting alignment quality? I've noticed that cold starting from a carrier with any sort of rocking leads to a far more rapid degredation than what I see from a land based start.

 

I'll try and get something more concrete, but my apocryphal example was error of greater than ten miles after taking off from the carrier, tanking, and flying 200 miles to a Target without incurring more than say 3G

Link to post
Share on other sites

Indeed! I was trying to communicate that I don't think anything I did while airborne would have caused the initial misalignment, at least to that magnitude.

 

Could the general DCS carrier deck sliding issue be causing misalignment? Is there anything we can do to prevent this besides taking off from land?

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...