Jump to content

O/S drift?


theIRIEone

Recommended Posts

Hi,

ran into some issued trying to use O/S coordinates as STP for our SLAM-ERs, not sure if what we experienced is intended behavior.

Given was a designated waypoint with multiple targets around for a 2ship - we set up an O/S from that in this order:
1. hit UFC from according HSI/DATA format
2. hit O/S on UFCP
3. entered 30NM range
4. entered 145MAG and 235MAG for BRG respectively  as we wanted 45deg offsets from our inbound HDG of 010 to create separation between the missiles
5. We left the altitude blank as the intend was not to use the Offset as such, but to read the calculated O/S coordinates (GRID) from the HSI to use as creation for another waypoint in the sequence - which we then would use as STP for our SLAM-ERs.

That's where things went wrong: While writing down the given O/S GRID from the HSI/DATA/WYPT sub-format, the coordinates actually where slowly, but constantly changing aka the offset was drifting and not a fixed point in space (it was still roughly correct according to tacview as the SLAM-ER still took a turn at roughly 30NM and correct-ish BRG from TGT).

While i couldn't find any reports of this exact issue described on the forums, i found another user's entry that is marked 'solved' - their screenshots also show their O/S Grid drifting, but nobody in the comments mention this.
The marked solution there was "Check O/S Altitude" - which in that case made sense as they where trying to acquire a specific point on the ground with ATFLIR using F10 map shenanigans. - I'll leave their topic linked here for the screenshots, since i don't have own recordings of the O/S drift so far unfortunately.




Question boils down to: Should Offset always be a fixed point in space or start drifting when (deliberately) not entering altitude?
Considering WPT creation does not necessarily require altitude to be entered for the GRID to be stable, i would assume same logic applies for O/S creation (with the addition of offset logic such as BRG/RNG)?

Link to comment
Share on other sites

Don't quote me on that one but I think the elevation for O/S, if left blank, would be automatically entered by MC when within ranging limits. I have no idea whether DCS models it this way or any other way. The 'other' sim did.

Anyways, I don't think this would work with SLAMER's.

As far as continuing  from O/S, idk


Edited by Gripes323
Link to comment
Share on other sites

24 minutes ago, Gripes323 said:

Don't quote me on that one but I think the elevation for O/S, if left blank, would be automatically entered by MC when within ranging limits. I have no idea whether DCS models it this way or any other way. The 'other' sim did.

Anyways, I don't think this would work with SLAMER's.

As far as continuing  from O/S, idk

 


Thanks a lot for your input.

I would assume elevation blanks being filled by the MC would mean no drifting coordinates, but also an actual altitude input being present in the O/S data - i know that elevation data is not displayed when leaving elevation blank, but that doesn't mean it couldn't exist somewhere in the background.

To be clear this has nothing to do with SLAM-ERs really, they're just here for context.

Basically we wanted to write down the O/S coordinates, but that wasn't possible because they kept changing - and i am not sure what caused that drift, thinking it may be us not having entered altitude data - and if that would really cause the GRID to be drifting?

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...