need track replay Slaving TADS to Location previously generated by TADS results in offset TADS LOS

[Swift.]

When using the TADS to lase and store a target, and then slave back to that stored target, the TADS will no longer point at the initial location.

In the following video, notice how the TADS indicated LOS on the TSD correlates with the location of the target (T04) when it is stored, but when slaved to T04 the TADS indicated LOS on the TSD shifts noticeably away from the point. This is also seen in the TDU itself where the LOS shifts several hundred meters to the right and closer.

I do not have a track at this time, because I've so far only experienced it during 3 hour sorties. I shall be attempting to reproduce in the coming days and will update here.

[admiki]

For me only first stored target went haywire. 5 others worked fine.

Edited to add: another test, all stored points work fine.

Edited September 11, 2022 by admiki

[NeedzWD40]

I've noticed on cold start aircraft in multiplayer, any coordinates generated will be off by greater than 10m. I can input coordinates for a unit and the actual coordinate location will be offset to the tune of hundreds of meters, even though my alignment is good and my positional accuracy is very narrow. I don't see this same issue in single player or hot starts.

[Scaley]

Replicated again online today, and track equally huge and likely not useful. We tested it by lasing and storing a point 1000m directly in front of the aircraft. The stored point was fine, but when commanded to slave the TADS slaved to a location that was NOT the point shown on either the pilot and CPG TSD. Error seemed to be around 200m. One observation was that all the errors for multiple stored points appears to be the same vector, so it's possible it's a coordinate system issue somewhere. (This was NTTR map for reference)

nullThe screen grab shows the result of slaving the TADS to T03. TSD is panned and centred over T03, North up, and aircraft is 1.5km north of T03.

Edited September 12, 2022 by Scaley

[BIGNEWY]

If possible please attach a short as possible track replay example, we will also try to reproduce 

thanks

[Scaley]

Just done some more tests and can't reproduce it reliably. One attempt to slave back to a stored point resulted in an offset between the TADS LOS and the acq source cueing cross, but most of the attempts were very close. What seems odd is the TADS never quite lines up with the acq source when you slave it back (when the acq source is a point). Even in the TADS video it shows the acq source slightly off centre while it's slaved. 
We also observed a possibly related event, where the TADS got stuck slaved to one source (in our case PHS) and the only way to get it to not follow PHS was to select another acq source. De-slave didn't work. More oddly that bug only showed up for the pilot, while on the CPG side the de-slave worked correctly and the TADS stopped following the PHS. 
In another related bug we got the TADS into a condition where it was showing as slaved to the GHS and panning around, but this wasn't showing on the PLT side, who saw the TADS as fixed forward. In this case the external model was showing the pilot's version of events with the TADS turret not moving even in the CPGs DCS external view.
To summarise, it seems like there are many and varied ways to get the TADS to de-sync between the CPG and PLT, and between the TSD and TADS. The bugs layer up in a way it may be very hard to isolate one problem. 

One note is that from all this testing it looks like DCS net code is pushing inputs not states, so once the TADS gets out of sync it will stay out of sync indefinitely unless there is some user interaction. 

If we can get a clean track file with any of the TADS bugs showing we'll post it, but it's proving hard to track down.

Edited September 13, 2022 by Scaley

[Swift.]

Adding this to the report, again no track because 3 hour mission, but its very very clear what's happening here.

It almost seems like the TADS position fixing is from a different source to the aircrafts. Makes me wonder if that INU drift bug we used to see is still 'exhibiting' in the TADS, even though we have no indication of it.

[NeedzWD40]

The INU drift is still present from what I gather, as I just put in an hour and my position coordinates were off by hundred of meters despite INU reporting accurate and aligned (along with GPS correction). Longitudinal drift was in the realm of 300m while Latitude was 30m.

[Swift.]

6 hours ago, NeedzWD40 said:

The INU drift is still present from what I gather, as I just put in an hour and my position coordinates were off by hundred of meters despite INU reporting accurate and aligned (along with GPS correction). Longitudinal drift was in the realm of 300m while Latitude was 30m.

Now that is interesting, because that could well be what's causing this.

[Swift.]

19 hours ago, NeedzWD40 said:

The INU drift is still present from what I gather, as I just put in an hour and my position coordinates were off by hundred of meters despite INU reporting accurate and aligned (along with GPS correction). Longitudinal drift was in the realm of 300m while Latitude was 30m.

Can you go over the steps to reproduce that drift? I'm trying now in a mission and it doesnt look like its drifting.

[NeedzWD40]

For me, it was a multiplayer mission with a cold start aircraft. Started up, waited until INU aligned, rearmed and refueled, then performed a deep strike on an enemy FARP. Returned back to my own FARP, set down, zoomed in the TSD and turned on the cursor info bar. Hovering the cursor over my ownship icon, I compared the readout with the external view data. This was all in approximately one hour real time.

[Swift.]

51 minutes ago, NeedzWD40 said:

For me, it was a multiplayer mission with a cold start aircraft. Started up, waited until INU aligned, rearmed and refueled, then performed a deep strike on an enemy FARP. Returned back to my own FARP, set down, zoomed in the TSD and turned on the cursor info bar. Hovering the cursor over my ownship icon, I compared the readout with the external view data. This was all in approximately one hour real time.

Alright perfect, and was this MC or just single pilot?

[NeedzWD40]

Single crew with the crash test dummy balancing the front.

[NeedzWD40]

So thought I'd bring this up to show an oddity: It seems that the L/L decimal is pretty accurate, but the MGRS coords are offset quite a bit in the longitudinal axis, to the tune of ~250m compared to the world coordinates. Latitude is off by about 20m, which is a bit large but not quite as bad.

On the instant action Caucasus runway start mission I cross referenced this with starting position and waypoint entry.

Because of this, I can't help but wonder if part of the issue could be some kind of coordinate conversion error and why manually entering coordinates seemingly gives huge offsets.

[Scaley]

That's super interesting, and seems to support the behaviour we are seeing where it looks like some parts of the aircraft avionics are cueing to one location, and other parts are going somewhere different. Maybe there are two coordinates systems/references in use, and some systems using one and some the other.

[Scaley]

This bug is still present, and still only appears on MP servers so is very hard to get a track of. One things that is absolutely reproducible is that when this happens it is associated with the TADS slaving back to a point different to that marked by the ACQ Source dashed cross marker. When you slave the TADS you see the TADS move to point at the incorrect location, but simultaneously it is showing correct cueing information (dashed cross and cueing dots) to the correctly stored location. The pilot always sees the correct location, and in their version of the sim the TADS is pointing the correct location. The offset between the stored location and where the TADS slaves to is a fixed offset (in our last test around 680m) and this offset remains constant with repeatedly storing points and slaving to them. In all cases the point is stored in the correct location, but when the TADS is slaved it points to a location offset from the stored point. 

[Scaley]

Bug still present, and still only appears to be happening on MP servers and after at least an hour of flight time, rendering tracks basically useless. Screenshots below show the TADS being slaved to 2 points that have been entered into the aircraft via the KU. No lase/store was involved, so there can be no error created by poor techniques when storing points. In both cases the TADS is slaving a point that is different to where the point is displayed on the HDU and on the TSD. The horizontal offset in both cases is identical (around 200m), and different target ranges and azimuths create a slightly different angular offset in the TADS. This leads me to believe it's a coordinate error. Given the aircraft clearly know where the point is, and can display (accurately) the difference between where the TADS is pointing and where the target is this also isn't a TLE error. If it were the TADS would point at the location the aircraft thought the target was, but the actual ground object might be some distance away. 

 

Edited January 14, 2023 by Scaley

[Loophole]

Bug is still present in Feb 2024 - encountered while trying to STORE a target selected using the TADS from about 4km away.  The stored position was consistently several hundred meters west of the targeted spot (ownship heading roughly 180 at the time).  This is in the latest Open Beta build at the time.

[Zarma]

Noticed it also in MP missions. Tried a SP mission to provied a track and it was OK. Strange.

[Swift.]

25 minutes ago, Zarma said:

Noticed it also in MP missions. Tried a SP mission to provied a track and it was OK. Strange.

Pretty sure this is related to multicrew.

[Zarma]

10 hours ago, Swift. said:

Pretty sure this is related to multicrew.

The two last time it happened, I was alone in the heli as my pilot failed me, but on a MP server.

[Zarma]

Any news ? Easy to reproduce, just log to a MP server, fly a few minutes, store a target point and slave to it => TADS is offset from the previously aimed point

[Zarma]

Not corrected.