user error CCRP / GPS navigation not working?

[Homer79]

Hello everyone,

Navigation no longer works for me since the system was changed in the second to last patch.
If I set an attack point (waypoint) on a building to then attack it in CCRP mode, this point, like the other waypoints, is also quite far away from the desired coordinates. Accordingly, the attack in CCRP no longer works. I have attached a few screenshots and the track file.
Even if I carry out a NAV FIX on the last waypoint before the target, it doesn't improve things.

In the screenshots you can see:
Target point in the mission editor (the three buildings should be attacked with 4xMK-84)
In the HUD you can then see the deviation from the target point to the three buildings (these are in the red circle)
In the TGP you can see where the last waypoint before the target is (it should actually be exactly on the small bridge)
You can then see where one of the MK-84s hit and where the three buildings are (in the red circle)

Is this a bug or am I too stupid? Or is this a phenomenon that results from the fact that the development of the system is not yet complete.
I do the NAV alignment exactly as it should be done according to the instructions.

It would be nice if you took a look at it.

 

Best regards
Mario

Broken_CCRP.trk

[razo+r]

Sorry, I can't watch the track, I don't have the map. So I have to ask a few questions.

What's the altitude of the steerpoint at the bridge that is in your aircraft? Check on the STPT page on your DED for that. 

Did you then slew the TGP to correct for the offset? 

If yes, did you press CZ prior to commencing the bombing? 

Edited July 13, 2024 by razo+r

[garvr]

I am having a very similar issue in the Gamblers campaign. My nav is all out of whack and my steerpoints are miles from where they are supposed to be. Even when I enter coordinates manually they are wrong.

[zeufman]

same, unable to launch GBU in CCRP with TGP lock in area mode

[zeufman]

test & track with mk-84

confimr CCRP mode is broken

test-CCRP-ko.trk

[zeufman]

Same in DTOS mode, all is ok, except for the release bomb, nothing

just after, it is ok in CCIP mode. Seems CCRP and DTOS mode relase bomb is broken

 

EDIT : confusing loft cue and drop cue

all is correct, sorry

Edited July 16, 2024 by zeufman

[Homer79]

Hmmm, now my topic has simply been described as a user error and that's it????

It would be interesting to know where my error lies? Could I perhaps have an answer to that, instead of just describing it as a user error and not even explaining the error I'm making?

It could be that it's a mistake on my part. But someone should tell me so that I can do it right.

Otherwise I think it's a bit weak!

[Swift.]

6 hours ago, Homer79 said:

Hmmm, now my topic has simply been described as a user error and that's it????

It would be interesting to know where my error lies? Could I perhaps have an answer to that, instead of just describing it as a user error and not even explaining the error I'm making?

It could be that it's a mistake on my part. But someone should tell me so that I can do it right.

Otherwise I think it's a bit weak!

It might be that you also mentioned a bug with CCRP in this thread which was user error as you identified. Keeping it one bug per thread will prevent this type of hiccough.

As to your original bug, I am unable to open your track file (not sure whats wrong with it). But I suspect what you are experiencing is the new GPS+INS modelling:
ED have added appropriate positional errors to the GPS and INS simulations and applied a kalman filter logic, as the real jet uses, to combine the two systems. In short a GPS derived position will generally be in the right area, but will have a lot of jitter and uncertainty. Whereas an INS derived position will be smoother but can drift away from the actual location.

Combining the two you end up with a smooth location that is generally in the right area, but as you are experiencing it can sometimes be a few metres away from the actual location.

 

NB. remember that our jet doesn't have EGI, it has a more primitive INS+GPS which is why you might have been expecting a better performance out of the system? 

[Maxxox]

CCRP and DTOS with MK84 works for me as expected for a free fall weapon. Tested in 3500ft and 7000ft. Just said, accuracy as expected. I see no bug.

 

[Homer79]

So in short, placing a waypoint in the mission editor on, for example, a building and then attacking it with CCRP and unguided bombs doesn't work anymore?

[Swift.]

4 hours ago, Homer79 said:

So in short, placing a waypoint in the mission editor on, for example, a building and then attacking it with CCRP and unguided bombs doesn't work anymore?

It works, but like all measurements there are tolerances.

You can't expect to be hitting the exact atom you planned for, IRL or in DCS.

[bladewalker]

On 7/24/2024 at 1:27 AM, Swift. said:

It works, but like all measurements there are tolerances.

You can't expect to be hitting the exact atom you planned for, IRL or in DCS.

Understandable…….. BUT……….

So the bottom line to all this, is the difference in the way the F16 and the F18 process / handle their steerpoints, and NAV system. Basically the F16’s steerpoint wanders like a stray dog, while the F18’s steerpoint is as solid as a rock.

In the coming screenshots, you’ll see what I mean…..

I have placed two steerpoints in the ME in the identical position at the base of a tanks tracks, both at ground level altitude. 1 steerpoint is an F16, and the other is a F18. This is an air start test with both aircraft starting 27nm away from the steerpoint. The TGP’s are purely there for reference. The F16’s TGP is defaulted to the current steerpoint, with NO slewing done at all. Likewise with the F18, with the TGP slaved to WPTDSG for steerpoint 1.

You’ll see as the F16 gets closer to the steerpoint, the point gets further away from the initial point defined in the ME. If you reference the lat long in the TGP window, you will notice that the numbers do not deviate at all, but the crosshairs and by association, the steerpoint on the ground change quite considerably from the position defined in the ME, and this is over a mere 27nm / 4mins or so.

If this is to be signed off as the new modeling of the GPS/INS system and the inherent errors associated with it, then why is the F18’s system bang on the “Atom”? What is the difference between the RL systems that make the f18 so superior? An aircraft that is of similar age to the F16?

 

[Swift.]

@bladewalker

Remember in you testing that FA-18 hasn't received the new GPS simulation yet (unless I've missed something in the changelog). So if will for sure behave differently to F-16.

Also remember that our FA-18 should have a full blown EGI, rather than the 'rudimentary' INS+GPS that our F-16 should have. So even when both are fully modelled, they shouldn't be behaving identically.

[falconzx]

Just for adding more clarifications, just because i read you are pointing out in the images the fact the coordinates are not changing on TGP:
If your INS is DRIFTING, it's absolutely normal that your TGP is showing the same coordinates you preplanned but the point in the real world is "drifting" to a different location.

The FIX procedure commonly adopted to fix the drift, it's exaclty done to resolve this. So you are telling the INS wich is the correct position in the real world for that specific steerpoint. And indirectly you are telling the INS which is your correct position in the world space.

What i ask at this point is, why the coupling with GPS is not doing anything to correct this? what would have happened if you have waited more and traveled even more? is that drift going to increase, more and more? Shouldn't be any type of warning or notice? At least in the NAV DED page where the accuracy is rated with HIGH/MED/LOW words? 
At a certain point our INS pos is going to differ a lot from the GPS readings, is it correct that the GPS is doing anything to fix that, and if yes why? why is needed a manual fix then? By common sense the system could have a delta threshold to establish how much drift is tolerated before applying a fix(around the GPS CEP maybe?).

Edited July 25, 2024 by falconzx

[Homer79]

On 7/24/2024 at 12:27 AM, Swift. said:

It works, but like all measurements there are tolerances.

You can't expect to be hitting the exact atom you planned for, IRL or in DCS.

....hitting the exact atom????  In the following screenshot you can see how I would miss a 40 meter long hanger by 40 meters!
I understand that there is a drift... but that it is so big, even though a nav fix was carried out a minute before... I'm not really sure whether such a fix has any effect at all.

 

Edited July 26, 2024 by Homer79

[Swift.]

17 hours ago, falconzx said:

Just for adding more clarifications, just because i read you are pointing out in the images the fact the coordinates are not changing on TGP:
If your INS is DRIFTING, it's absolutely normal that your TGP is showing the same coordinates you preplanned but the point in the real world is "drifting" to a different location.

The FIX procedure commonly adopted to fix the drift, it's exaclty done to resolve this. So you are telling the INS wich is the correct position in the real world for that specific steerpoint. And indirectly you are telling the INS which is your correct position in the world space.

What i ask at this point is, why the coupling with GPS is not doing anything to correct this? what would have happened if you have waited more and traveled even more? is that drift going to increase, more and more? Shouldn't be any type of warning or notice? At least in the NAV DED page where the accuracy is rated with HIGH/MED/LOW words? 
At a certain point our INS pos is going to differ a lot from the GPS readings, is it correct that the GPS is doing anything to fix that, and if yes why? why is needed a manual fix then? By common sense the system could have a delta threshold to establish how much drift is tolerated before applying a fix(around the GPS CEP maybe?).

 

The GPS is fixing the drift, its just the GPS is noisy enough that it still induces errors.

I've been trying to find some videos or such of an equivalent situation in real life so we can report any errors in magnitude of the effect. But pretty much everything I find is for an EGI jet, which is clearly going to perform better than what we have.

[buceador]

12 minutes ago, Swift. said:

But pretty much everything I find is for an EGI jet, which is clearly going to perform better than what we have.

Is there a plan to implement EGI on our version of the Viper?

[falconzx]

1 ora fa, Swift. ha scritto:

The GPS is fixing the drift, its just the GPS is noisy enough that it still induces errors.

This is not what @bladewalker just showed in his tests and supplied images. That was not the correct way to report a bug, but if what we all see there is the current GPS->INS fixing implementation, then there is presumably a bug and someone should do a proper report.

From what is my understanding the GPS CEP is that noise you're referring to. As the acronym says it's a circular error probability, so it's constant, under the same conditions it's something shouldn't increase overtime.

What he experienced is an error increasing overtime. (typical INS behaviour)

That error was visibly greater than GPS CEP.
My deduction then is that GPS is not fixing the drift there.

Edited July 26, 2024 by falconzx

[Swift.]

11 minutes ago, falconzx said:

This is not what @bladewalker just showed in his tests and supplied images. That was not the correct way to report a bug, but if what we all see there is the current GPS->INS fixing implementation, then there is presumably a bug and someone should do a proper report.

From what is my understanding the GPS CEP is that noise you're referring to. As the acronym says it's a circular error probability, so it's constant, under the same conditions it's something shouldn't increase overtime.

What he experienced is an error increasing overtime. (typical INS behaviour)

That error was visibly greater than GPS CEP.
My deduction then is that GPS is not fixing the drift there.

 

I'll need to sit down and run some tests myself then. He executed a 4 minute test, which is not exactly long enough to see a trending behavior over time. Especially considering the first minute is spent acquiring GPS signals.

Do this test yourself, put yourself in an orbit for a long enough time, lets say 45 mins. And observe how the positional error never exceeds a certain amount but rather wonders around the true location.

[falconzx]

yep I'll do it soon too, i'll post my results.

[falconzx]

My tests went pretty good.

I used a runway number just to have something very detailed to look at and on a plain surface. I used TGP to fine check and doublechecked the behaviour on HUD/HMCS. Mastermode NAV, so only diamond on hud.

My results:
GPS is fixing correctly the drift, the errors caused by the GPS CEP leads to a mis-aligning of the correct STPT by a CEP of maximum 20m. I've seen fluctuations between 5m and 20m, on average it's most of the time off by 10m.
I don't know if this is the desired behaviour but that's what it is now.
 
At the end i also did a different test, i tried to perform a bad manual fix, by around 0.25nm of delta off. Then putting back the autofix, just to see how it was going to behave fixing a big error. The system in around 3-4 min (probably because of the kalman filter) gently moved the point on the correct spot(~10m) again. That was very good.

Another thing i didn't like so much is the graphical drifting of the diamond on HUD. Initially i thought it was a bad aligning on HMCS (even if i aligned it almost perfectly using max zoom). But no, that happens on the HUD also.

The point seems to be on the same spot where the TGP is pointing ONLY at very close distances(less than 100ft). When you increase the distance (very visibile already at 4nm) the diamond shifts, like the point where is centered is not at the center of it.

Because of this issue when the TGP is off by around 10m, the diamond is off by 20-50m at 3-4nm and if you go even further away it's even worse.
 

Edited July 26, 2024 by falconzx