reported Storing target points with the tads and laser, then slaving, they seem offset by quite a margin

[ked]

When I store target points as a CPG, using the tads and the laser. Then setting this TP as acquisition source and slaving to it. It seems like the point is offset by a margin of a few tens of meters.

It might be correct as is, which is why I haven't investigated more and provided a track, just wondering if this is bugged or not

[S. Low]

I’ve noticed this as well when playing as CPG. Not sure if bug. I think one of us is going to need to upload a track though for them to investigate 

[ked]

I probably won't be able to until sunday night ... But it is very easy to reproduce, happens to me everytime I store a target point as a CPG in MP (haven't tested in SP)

[Lange_666]

I'm having the same problem, happens in SP too. My offset in the TADS is always quite a bit to the right, on the TSD however, the cursor moves to the correct location.
Must be a bug. 

[frostycab]

I've noticed this too, with the stored point usually being several meters in front of the actual target, though I can kind of rationalise it in my head if I try:

The MGRS accuracy with 8 digits total gives you a square of 10m by 10m, so I would assume that when you lase and store a target point it's recorded in the database using that same level of accuracy. Thus, when you slave back to that target it's entirely feasible for the stored point to be anything up to 10m away from the actual point you lased. (Actually, up to 14m away if you allow for 10m in 2 directions.) That's fairly consistent with the offset I've seen when slaving back to a point, and that's not factoring in that the aircraft itself only knows where it is down to a few meters most of the time. If you compound the 2 then it all makes sense (to me.)

In any case, slaving to a target point usually puts me pretty close to the intended target. Close enough to make adjustments and shoot, anyway. I'd be amazed if the real system was flawless. 

[S. Low]

Track and video example of offset when slaving to target point. 

 

ah64testingtargetpoints.trk

[S. Low]

Bump. Track replay and video have been provided.

[ked]

Thank you for this @S. Low

I want to add that it seems like there isn't much drift but it's because it is close, if you do this at 5-6km you get a target point that is a lot further away from where you lase !

[pellelil]

On 4/2/2022 at 12:09 AM, frostycab said:

I've noticed this too, with the stored point usually being several meters in front of the actual target, though I can kind of rationalise it in my head if I try:

The MGRS accuracy with 8 digits total gives you a square of 10m by 10m, so I would assume that when you lase and store a target point it's recorded in the database using that same level of accuracy. Thus, when you slave back to that target it's entirely feasible for the stored point to be anything up to 10m away from the actual point you lased. (Actually, up to 14m away if you allow for 10m in 2 directions.) That's fairly consistent with the offset I've seen when slaving back to a point, and that's not factoring in that the aircraft itself only knows where it is down to a few meters most of the time. If you compound the 2 then it all makes sense (to me.)

In any case, slaving to a target point usually puts me pretty close to the intended target. Close enough to make adjustments and shoot, anyway. I'd be amazed if the real system was flawless. 

One thing is the accuracy of the coordinate stored in the database, but another issue is the accuracy when obtaining the position of the point to be stored (prior to storing it). The current position of the chopper is obtained from GPS/INS with the accuracy it provides. Then you have to use the azimuth of the laser, and the measured distance, and then from that the location (to be stored) is calculated.

Edited April 4, 2022 by pellelil

[S. Low]

Coding software is beyond me but a thought came to mind: if the laser is using a coordinate system to save target points, is it possible the laser or slave mechanic is not using the magnetic variance?

[pellelil]

Nothing is 100% precise. When doing GPS-calculation these (in most cases) expect the earth being a perfect sphere which it is not. I guess the laser is relative precise, however it does not know the elevation where it hits hence the point it hits can be measured to be closer/further away. The azimuth of the angle in relation to north is not perfect either. If you the measured angle (to north) is 1 degree of, at 8000 meters it would result in an inaccuracy of 139 meters (458 feet). I doubt its 1° off, but lets say the accuracy is 0.1° then it would be 13.9 meter/45.8 feet off.

However being able to pin-point a point 8000 meters out with an accuracy of 13.9 meters/45.8 feet is not bad, as long as it is only used to point the laser (almost) to the correct place

[BIGNEWY]

I've spoken with the team and a SME the offset is within tolerances.

We will keep an eye on it but for now it is correct as is. 

thank you

[jnr4817]

Experienced this last night. It was off by 20-200m in some instances. 

Edited April 4, 2022 by jnr4817

[Swift.]

Are we witnessing the DCS community's sudden introduction to TLE?

[BIGNEWY]

The team have asked me to create a report for it, they want to look closer at it. 

thanks

[dg6546]

Also, adding waypoint in tsd is way off too. I had a flight today and the waypoint is 50km off...

 

It started acting like this after the hot fix.

Edited April 4, 2022 by dg6546

[frostycab]

4 hours ago, dg6546 said:

Also, adding waypoint in tsd is way off too. I had a flight today and the waypoint is 50km off...

 

It started acting like this after the hot fix.

 

Using the cursor or by entering MGRS through the KEU? 50km sounds like it could be user error or an error in the kneeboard.

Edited April 4, 2022 by frostycab

[ked]

4 hours ago, dg6546 said:

Also, adding waypoint in tsd is way off too. I had a flight today and the waypoint is 50km off...

 

It started acting like this after the hot fix.

 

I have not experienced that, are you sure you entered it right ?

7 hours ago, BIGNEWY said:

I've spoken with the team and a SME the offset is within tolerances.

We will keep an eye on it but for now it is correct as is. 

thank you

Thank you, I wasn't sure if this was meant to be this way or just a bug

[BIGNEWY]

11 hours ago, dg6546 said:

Also, adding waypoint in tsd is way off too. I had a flight today and the waypoint is 50km off...

 

It started acting like this after the hot fix.

 

please make a new thread with a track replay showing the issue. 

thanks

[S. Low]

Thanks, BN.

[Scaley]

18 hours ago, Swift. said:

Are we witnessing the DCS community's sudden introduction to TLE?

I think so. The Apache is the first module that's had proper INS drift, and at the moment unless you manually re-cycle the INUs that drift builds up quite fast. It also varies during flight with some periods where the INUs sort themselves out.  I'm regularly seeing position errors of up to 30m (which is totally fine, but worse than other DCS modules that have unrealistically good INS). 

If you combine an 8 digit grid (10m accuracy) with a moving platform that has velocities that might be a few kts out and a position that might be 30m out you'll easily generate some errors of tens of meters, and maybe hundreds on a bad day if everything lines up against you.

[Swift.]

4 minutes ago, Scaley said:

I think so. The Apache is the first module that's had proper INS drift, and at the moment unless you manually re-cycle the INUs that drift builds up quite fast. It also varies during flight with some periods where the INUs sort themselves out.  I'm regularly seeing position errors of up to 30m (which is totally fine, but worse than other DCS modules that have unrealistically good INS). 

If you combine an 8 digit grid (10m accuracy) with a moving platform that has velocities that might be a few kts out and a position that might be 30m out you'll easily generate some errors of tens of meters, and maybe hundreds on a bad day if everything lines up against you.

The amount of modelling in the INU errors makes me wonder whether there are angular measurement errors being modelled in the TADS too. Might be quite interesting to see what kind of TLE you can expect under different conditions with the current modelling.

[S. Low]

I admit I don’t understand what you’re talking about with TLE or INU drift in the Apache, but the video and track I provided were from a single player instant action mission where i took off into a hover and began the test. I don’t think drifting gps over time plays into that? But to be fair I have no idea what plays into this, or if it’s even a bug lol. They’re investigating so I’m good with that 

[Swift.]

45 minutes ago, S. Low said:

I admit I don’t understand what you’re talking about with TLE or INU drift in the Apache, but the video and track I provided were from a single player instant action mission where i took off into a hover and began the test. I don’t think drifting gps over time plays into that? But to be fair I have no idea what plays into this, or if it’s even a bug lol. They’re investigating so I’m good with that 

TLE is just target location error. Its basically the error that will be shown in the location of the thing you are trying to target, based on cumulation of all the little inaccuracies in all the systems that are involved in targeting. 
Eg (made up numbers)
INS position is +- 50m
Laser range is +-10m
TADS angle is +-0.5 deg

Im not going to do the maths because maximum effort, but you can see how lots of relatively little errors in measurements can add up to produce what we are seeing in game: 30m displacement.

Of course this is all assuming that ED have modelled this effect deliberately and its not a bug.

[frostycab]

1 hour ago, Swift. said:

Of course this is all assuming that ED have modelled this effect deliberately and its not a bug.

<soft voice> “Just a happy little accident. Now let’s give our tree a friend…..”