missing track file SPI Location Moving When Rolling In On A Target

[melchionda]

Hi,

Let me know what I am doing wrong here...

- I'm flying the A10CII in orbit around some ground targets...

- I set the targeting pod to SOI and lock in on a ground target with point track.

- I use the laser designator to get a more precise reading of the distance.  At this point it looks like I have created a SPI on the ground target with the TPod.

- Next I make my Maverick SOI and then slave the Maverick to my SPI. Now because I am still in orbit I reach the gimbal limits of the Maverick before I can see the ground target through the Maverick missile, however the missile is definitely attempting to lock onto the SPI.

- Next I roll into the target and in doing so my wing momentarily masks the target from the TPOD view.

 

PROBLEM....

When I finish my roll-in maneuver I will then see that the SPI point has moved and is now a few meters from the spot that I put it; and the Maverick is now slaved to the new spot, and so its no longer aiming at the target.  In order to hit the target I have to go back to the TPOD, move the SPI back to the ground target and then go back to the Maverick to slave it to that spot and fire the missile.

 

Moreover, sometimes when this happens I can look through the HUD and I can actually watch as the SPI point moves a few meters as I roll in.

 

I would think that because I have created a SPI on the ground that it would stay put regardless of whether or not the view of that spot was momentarily masked by my wing.

 

Sometimes I try to turn in using just the rudder so that the wing doesn't mask the TPOD... when I do that the SPI point stays put... however rolling in using just the rudder takes forever and it probably not the right way to do it.

 

What am I dong wrong here?

 

 

Edited February 25, 2021 by melchionda

[BIGNEWY]

Hi, 

 

do you have a short track replay showing an example, we are happy to take a look.

 

My advice first would be not to uncage the maverick until you start your run, do it at the start of your run and in range you should get a good lock then. 

 

thanks

[twistking]

37 minutes ago, melchionda said:

Hi,

Let me know what I am doing wrong here...

- I'm flying the A10CII in orbit around some ground targets...

- I set the targeting pod to SOI and lock in on a ground target with point track.

- I use the laser designator to get a more precise reading of the distance.  At this point it looks like I have created a SPI on the ground target with the TPod.

- Next I make my Maverick SOI and then slave the Maverick to my SPI. Now because I am still in orbit I reach the gimbal limits of the Maverick before I can see the ground target through the Maverick missile, however the missile is definitely attempting to lock onto the SPI.

- Next I roll into the target and in doing so my wing momentarily masks the target from the TPOD view.

 

PROBLEM....

When I finish my roll-in maneuver I will then see that the SPI point has moved and is now a few meters from the spot that I put it; and the Maverick is now slaved to the new spot, and so its no longer aiming at the target.  In order to hit the target I have to go back to the TPOD, move the SPI back to the ground target and then go back to the Maverick to slave it to that spot and fire the missile.

 

Moreover, sometimes when this happens I can look through the HUD and I can actually watch as the SPI point moves a few meters as I roll in.

 

I would think that because I have created a SPI on the ground that it would stay put regardless of whether or not the view of that spot was momentarily masked by my wing.

 

Sometimes I try to turn in using just the rudder so that the wing doesn't mask the TPOD... when I do that the SPI point stays put... however rolling in using just the rudder takes forever and it probably not the right way to do it.

 

What am I dong wrong here?

 

 

 

 

if you have the tpod on point track it is absolutely dependent on LOS, so having LOS masked for a short time can indeed throw off your SPI. easiest way to solve this is to put the tpod in inertial track if you expext masking and switch back to point as soon as the tpod is clear again.

 

alternatively you could transfer the SPI to a different sensor that is not LOS dependant (HUD TDC, HMCS, Markpoint...) and slave the maverick to that.

Edited February 25, 2021 by twistking

[Hive]

Try area instead of point track. 

[Emmy]

Try working with Mark Points for targeting.  Much easier and more reliable to slew all to a Mark Point as Steerpoint for bringing weapons to bear.

[jaylw314]

The TGP has a dead spot directly forwards where the lateral gimbal hits its stops.  If you watch your HUD, you'll see the TGP diamond spin around that point as the longitudinal gimbal tries and fails to track.

 

Try not to pull your TGP target through that dead zone when you roll in.  I've been making a habit of rolling in with the HUD centered 5-10 degrees above the target, which is fine for Mavericks.

 

Edited February 26, 2021 by jaylw314

[Caldera]

melchionda,

 

That very thing has been happening to me also.  It is not off by much, but the ground reference point has moved.  Like you, I figured that I was doing something wrong to cause it.  And it has happened enough to be really noticeable.

 

The same thing occurs for laser guided rockets. 

 

It seems I have kept repeating the same mistake over and over.  Typically I use point mode and try to set the SPI near the ground of the vehicle.  Just to say, it does not happen if I am changing targets in single attack run.  But for example, if I orbit to find a target then maneuver to attack.  The TGP can move off of the target vehicle for some reason.

 

Sometimes if I set the SPI on a target and then manually pan the TGP to look at something else, things go wrong.  By that I mean if I then try to re-slave the TGP (all sensors) to SPI it gets lost and I have to manually reset it back on target.

 

I have no movie.

The TGP may or may not be SOI when I see it occur.

The TGP diamond in the HUD may or may not be near the cage position.

I have never used the TGP laser to get a more accurate distance.

 

twistking,

 

How do you change the TGP to inertial track mode?

 

Caldera

 

[Ziptie]

13 hours ago, Caldera said:

 

 

How do you change the TGP to inertial track mode?

 

Caldera

 

TGP SOI
TMS AFT SHORT (verify INR below gates on TGP display)

Roll in, once you have nose on target, TMFS to gain a point track (if desired)

 

To others:  For those who are using point track on a target that isn't moving - you don't need to do that, and shouldn't do that.


Cheers,

 

Ziptie

[Fri13]

The point and area tracking modes are contrast based. One try to track a small area ("point" as size of a that small box) and other tries to track the whole scene.

 

Done by memorizing the contrast on moment of lock (switching to mode) and then tracking the subtle change in it (that can be generated by example when circling around or flying toward) and comparing it to previous frames as history.

 

If the scene change to quickly as happens when masking, the tracking is lost as original memory doesn't match the masked scene.

 

As the targeting pod generate the inertial coordinates from the scene, it still shouldn't use coordinates to track area as it is a visual locking to generate the coordinates.

 

One more wiser can explain that does the TPOD require a laser ranging to get the slant range and so on generate the coordinates from that, comparing to aircraft position and where TPOD is looking. Or can it generate it by assuming a TAMMAC provided altitude in rough estimation and angle?

 

But the inertia (INR) mode should be usable any moment to avoid masking problems, but if TPOD doesn't know the slant range then it can not know exactly how much turn the pod relative to aircraft position and attitude as target might be 3 nmi or 15 nmi away and so on it is inaccurate if pod doesn't know coordinates where it should look at.

 

So while the contrast based tracking is accurate, you can't mask it. And you should be losing lock now and then, especially if no contrast. And inertia tracking should be inaccurate and move around the target, requiring corrections, but it doesn't care about contrast changes and so on is solid for masking.

 

The slant range is key to acquire the coordinates of the target. Aircraft position is known with few meters accuracy. So is TPOD direction known, and if TPOD can perform the ranging then it knows target range and so on coordinates.

 

But once the pod knows target coordinates, in what modes should it use that information?

 

Of course a area tracking or point tracking would be useless if coordinates would be used as contrast changes like a large ship (area) or small car (point) when moving wouldn't be tracked as coordinates would insist that target stays stationary.

And Masking wouldn't be problem at all if coordinates would be used instead contrast locking.

Why we have different modes, where pilot is required to use his judgment on situation that what is best mode and required mode as there can't be one that does it all.

 

But, we do have automatic laser turn off when 5 degree from masked line of sight. And there are different mask profiles for different stations, depending is there a fuel tank or specific weapon category.

So one could think that why not automatically switch to INR mode when laser is turned off before masking?

 

Of course if there is no accurate coordinates (and there isn't) then INR mode would still shift slightly as it does anyways without area or point tracking based contrast.

 

These can be seen in various targeting pod videos how they will shift, float and shake, requiring pilot to manually adjust them.

 

But there are major problems in the targeting pod simulation by them being too perfect.

 

[Caldera]

Ziptie,

 

Thanks!

 

11 hours ago, Ziptie said:

Roll in, once you have nose on target, TMFS to gain a point track (if desired)

 

I just started doing that for a test.  You are right.  I have better luck with that method.  The TGP in point view mode likes to jump off to trees / buildings and such.  Usually at the worst of times.

 

Back to melchionda's topic.  As he says, or some reason I think that the SPI does mysteriously move.   I do not know why.

 

Yesterday I was attacking a tank with guns.  The tank was sitting on top of the SPI.  (About the only way I can find gun targets).  On my first pass I hit the tank, but did not kill it.  The tank appeared to be disabled, because from what I could tell it did not relocate.  I generally have to watch tanks on the TGP so that I can make sure that I attack from the rear.   Anyways, as I was circling around I was watching the tank when I could using the TGP.  It was not moving.

 

For my second attack I was, of course, watching the tank on the TGP.  Suddenly, the TGP moved off target.  I tried to re-slave it to the SPI and and the TGP did not move.  I continued my attack.  As I looked through HUD with full zoom, the SPI marker was no longer under the tank nor was the tank anywhere in my view. 

 

This flub cause a muffed attack so I went around again.  I manually slewed the TGP back to the tank.  As a test, I then re-slaved the TGP back to the SPI.  The TGP then moved off the tank to the SPI.  The SPI was out in Nah-Nah land. 

 

Elevation problem? 

 

Confusing...

 

Caldera

[ZeroReady]

What's happening is that A SPI created on the ground is made via the INS. As such it can be thrown off by maneuvering or going outside the gimbal limits. Just as a gyro compass will accumulate errors over time and must be recalibrated via a magnetic compass after a while, or even after heavy maneuvering. A markpoint however is independent of the aircrafts INS and avionics. It is a physical spot on the ground given as coordinates that never change. A markpoint will always be where you made it, it will never move.

 

Just get in the habit of making a markpoint on anything you plan on attacking. 

[Caldera]

ZeroReady,

 

Well... 

 

I can see how the TGP could get thrown off due to its simulated mechanical nature.  But what baffles me is why would the SPI suddenly change locations?  It only seems logical to me that by re-slaving to SPI it should re-orientate the TGP back to the SPI. 

 

Sometimes...  

 

The mark points can stack up on themselves and I can't figure out where from or when to after a bit.  This is made really horrible with allot of concentrated targets.  Too many mark points in a small area can be just as trouble some.

 

 

All,

 

Let me clarify, I don't really know how the TGP actually works and I don't know how a SPI is actually made.  I am only trying to learn the DCS TGP and DCS SPI.

 

I notice that the SPI seems to move by its own prerogative in DCS.   But, I am probably just wet behind the ears.

 

 

This is what the DCS manual (that I have) says about the TGP Track Modes:

 

• AREA

The TGP has been space stabilized on an overall scene but is not tracking a specified object. If AREA track cannot be maintained due to aircraft masking, it reverts to INR-A mode and will return to the AREA track location if track can be reestablished by unmasking.

• POINT

The TGP has established a track on a specific object/target and is stabilized on it. It will continue tracking even if the target is moving. When tracking in POINT mode, a box is drawn around the edge of the object being tracked. The object does not need to be bounded and the box will not expand to encompass the entire object—it remains a fixed size. If the object cannot be tracked due to aircraft masking, it will revert to INR-P mode, but will return to the POINT track if track can be reestablished by unmasking.

• INR-A

If the TGP is tracking in AREA mode and is masked, Inertial Area (INR-A) is displayed. The TGP will attempt to re-track the area lost when the mask constraint has been eliminated.

• INR-P

If the TGP is tracking in POINT mode and is masked, Inertial Point (INR-P) is displayed. The TGP will attempt to re-track the point lost when the mask constraint has been eliminated.

• INR.

When in Inertial (INR) mode, the TGP will remain fixed on a geographic reference point.

 

 

My point, no where does it say how it does this.  But it does say very clearly "and / but will return to the AREA / POINT track location if track can be reestablished by unmasking".  Believe me, I unmask the TGP whenever I can.  And frankly, if literally taken, the TGP should do the same thing coming out of gimbal faults or exactly head on flight attitudes.

 

 

On 2/25/2021 at 7:30 AM, twistking said:

 

 easiest way to solve this is to put the tpod in inertial track if you expext masking and switch back to point as soon as the tpod is clear again.

 

 

This is good advice and I believe that he means put it in INR mode. 

 

It seems from the description above that AREA and POINT use a picture reference point and INR uses a geographical reference point.   Could one deduce something from that?  Maybe could it be that the INR-A and the INR-P are using the last best guess of the INR position just before the TGP was masked?  All this is seems pretty darn complicated for a game to simulate.  I am wondering if that everything is based off of a three axis coordinate system crunching numbers in the simulated 3d space we fly in.

 

Back on topic...

 

 So let me ask one last question, basically is an INR track point and a MARK point more or less the same thing?  Where one is temporary (INR) for immediate use and one is held in memory (MARK) for later use?

 

Thank you for all your help,

Caldera

Edited February 28, 2021 by Caldera

[jaylw314]

1 hour ago, Caldera said:

It seems from the description above that AREA and POINT use a picture reference point and INR uses a geographical reference point.   Could one deduce something from that?  Maybe could it be that the INR-A and the INR-P are using the last best guess of the INR position just before the TGP was masked?  All this is seems pretty darn complicated for a game to simulate.  I am wondering if that everything is based off of a three axis coordinate system crunching numbers in the simulated 3d space we fly in.

 

Back on topic...

 

 So let me ask one last question, basically is an INR track point and a MARK point more or less the same thing?  Where one is temporary (INR) for immediate use and one is held in memory (MARK) for later use?

 

I think you are correct.  There are a couple twists, though

• In INR-P mode, the TGP continues to track a point in 3d space PLUS it's calculated movement before it got masked.  If you're in POINT tracking a moving vehicle, when it goes to INR-P, the crosshairs will remain centered on the vehicle, but if it turns or changes speed, the crosshairs will drift off.
• In inertial modes, there can be ambiguity due to terrain, e.g. the TGP doesn't know if you're pointing at the hillside or the valley behind it because its line of sight hits the terrain in more than one place.  POINT and AREA are unambiguous, in theory, so the TGP should know you're pointing at the hillside in front.  This can cause some wonkiness going from POINT/AREA to INR-P/INR-A, the TGP can start tracking the wrong terrain location

[Fri13]

I think it is fairly easy.

 

Everything that is contrast based tracking can be used to generate SPI (or Markpoint etc) if you can get a slant range to it.

 

When a SPI/MKP is created, it is memorized to system as coordinates. It is relative to INS system or literally coordinate value.

 

When the INR mode gets activated, manually or automatically by TGP detecting it reach predetermined masked area, it needs to either generate a coordinates or it needs to just track the aircraft movements and counter them. But it requires slant range so it knows how much it needs to turn, as target being 5 nmi is different than one being 2000 ft away.

 

So the masking from aircraft is not problematic as system can detect that. The masking from terrain is problematic as system can't detect why scene changed and it just needs to track that. So pilot flying behind a hill or building appears front of the target, then the TGP should start to track those.

 

So only way to keep TGP pointing a proper area is to use INR mode manually with proper slant range like laser ranging or inputted GPS coordinates (Markpoint etc).

As contrast based systems can go crazy.

 

Now, when you have created SPI and system is slaved to SPI, it might be just one time movement there, not locking continually to it.

But when TGP knows it goes gimbal roll, it should after that return to previous position and not generate a new SPI by it movement as roll happens to somewhere else if it is slaved to SPI.

 

But if it is in contrast tracking mode, shouldn't it try to just track it, and hense generate a new SPI if ordered so?

So only NRI mode would avoid redesignation that contrast system would generate automatically as camera returns to previous position.

 

So does the TGP generate a SPI where ever it looks at, or does it generate it only when commanded?

 

The POINT track mode of course does so, as it keeps updating SPI while tracking moving target. As well area.

 

But what happens when gimbal limit appears? Between starting and stopping I would think a SPI generation is stopped.

[silverdevil]

i can confirm this happens to me once in a while. common enough to wonder what the issue is, either my fault or a system fault. i will just abort the run and start over. i believe it is the pod optics getting to the extents of the axes. there are three just like the plane. pitch, roll and yaw. if any get to the end of its movement then i think this is when it moves. but it does not really make sense to me.

 

[Animal66]

Hi all,

 

I got the same problem and as far as I can recall, I hadn't this problem with the A-10c and believe that it has to do with the new APKWS.

 

I spot a target, make it SPI through the TGP, choose a laser guided weapon, fly in a straight line to the target while activating the laser and then out of nothing the TGP looses track. This happens 75% of the time. Sometimes I see without any reason that the TGP camera is shortly moving by itself, sometimes coming back to the target but most of the time it is pointed let's say 10-30 metres away from it.

 

I can imagine that when you make a turn and the TPS looses direct sight, that te TPS can be off target. I can't imagine that this is normal when the TGP has full sight.

 

[rapid]

I too have seen this phenomenon As above, doing a straight run and the TGP lock will move. 

[Nealius]

Happens to me every single time I roll in on a target that's opposite the direction of my pod station. If my pod is on the right wing and I roll in to the left, SPI shifts every single time. Other modules don't exhibit this behavior with the same frequency, but other modules also have the pod mounted closer to the aircraft's roll axis as opposed to way out on a wing. 

 

I just can't figure out how to get around this without limiting my roll-in headings to whatever is on the same side as my pod, or how to deal with moving targets since it always happens in Point track. 

[Taco-Taylor]

Used to happen to me constantly while turning in for APKWS shots until I started doing this,
During your roll-in point your velocity vector just a bit above the horizon (and therefore above the target) then once on heading just pointing your nose down if required
This from what I understand means the targeting pod has to do less multi axis slewing since it just needs to slew right or left, stop, and then down which avoids the gimbal going crazy and losing its track.
 

[Caldera]

Hey all,

 

It has not happened to me since I started placing the TGP in INR mode if I think that it will be totally masked.

 

In fact, of late I have almost exclusively been using INR mode even over POINT mode.  As POINT mode tends to jump to jump off my target to trees and buildings usually at the worst time.

 

I am having better luck. 

 

For some reason it seems that if the TGP jumps off of the SPI it call pull the SPI with it.

 

Caldera 

[Caldera]

Hey All,

 

OK, still learning...

 

Admittedly I just made a new discovery which is an old discovery by this games standards.  For me, this game always feels like it is tomorrow, but in reality it is last month.  My apologies.

 

I guess I was confused about the SPI and how it worked.  I had thought that the SPI was simply a 3D data point saved into the onboard computer and then displayed on the HUD HMD etc.

 

Maybe it is and maybe it isn't...

 

Coolie Hat Forward Long --> Slave all to SPI

 

This statement made me believe that it was true for all sensors.   However, the TGP  is exempt because the TGP will not slave to the SPI.   More correctly, the SPI has been slaved to the TGP. 

 

Move the TGP --> Move the SPI

 

Wax On <-- --> Wax Off

I have no real proof of this, but I suspect that if the TGP waxes out then the SPI reverts to a steer point.

 

My head hurts...  Might explain why some stuff might miss for rooky clueless reasons.

 

Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point   Mark Point  

 

 

 

Onward HO!

 

 

 

Now I would like to discuss TGP modes.  Something goes on that I do not fully understand.  Please let me know where I write something incorrect. 

 

The default mode for the TGP is AREA and INR-A.  You can manually switch to POINT, INR-P or just plain ole INR.  The switch to INR-A and INR-P is an automatic function if the current mode is AREA or POINT respectively.  Like wise, the switch to AREA and POINT is automatic if the current mode is INR-A or INR-P respectively  The switch to INR is always manual.  Additionally, the TGP will automatically switch to AREA or INR-A from INR.   (I did not expect that to happen)  Masking is what causes the TGP to shift to INR-A and INR-P.   Unmasking is what causes the TGP to switch to AREA and POINT. 

 

I suspect that unmasking (fully or partially) causes the automatic switch from INR to AREA or INR-A.  Is this correct?

 

Caldera

 

[SJBMX]

On 2/27/2021 at 10:26 PM, Caldera said:

The mark points can stack up on themselves and I can't figure out where from or when to after a bit.  This is made really horrible with allot of concentrated targets.  Too many mark points in a small area can be just as trouble some.

 

Pro-Tip: Unless you're in a situation that doesn't afford you a chance to do so, always label your markpoints.

[Ziptie]

On 3/23/2021 at 12:15 PM, Caldera said:

Coolie Hat Forward Long --> Slave all to SPI

 

This statement made me believe that it was true for all sensors.   However, the TGP  is exempt because the TGP will not slave to the SPI.   More correctly, the SPI has been slaved to the TGP. 

 

Wax On <-- --> Wax Off

I have no real proof of this, but I suspect that if the TGP waxes out then the SPI reverts to a steer point.

 

 

Your problem might be, that you are saying (and possibly using Coolie Hat Forward Long)

 

CHINA HAT forward long slaves all sensors to SPI.

 

CHINA HAT FL absolutely slaves all sensors (including the TGP) to SPI.

 

Also, double check that your SPI isn’t TGP (indicated on bottom left of HUD).  If SPI is TGP - CHINA HAT FL won’t slave your TGP anywhere other than where it is currently “looking.”

 

 

Cheers,

 

Ziptie

[Nealius]

On 3/24/2021 at 11:08 AM, SJBMX said:

Pro-Tip: Unless you're in a situation that doesn't afford you a chance to do so, always label your markpoints.

 

I've been trying to name my markpoints by typing the name, then pressing the corresponding LSK, but always get "input error." Can't figure out what I'm doing wrong.

[Caldera]

Ziptie,

 

17 hours ago, Ziptie said:

Your problem might be, that you are saying (and possibly using Coolie Hat Forward Long)

 

CHINA HAT forward long slaves all sensors to SPI.

 

Yes I meant China Hat (left thumb forward) and one day may I stop getting Coolie and China confused...

 

EDIT: Flight Manual Page 409

 

• Targeting Pod (TGP).

Like the Maverick, when the TGP is SOI and the "set sensor as SPI" function is selected, the line of sight point at ground intersection marks the SPI with a TMS Forward Long. This will be the same coordinates and elevation displayed in the TGP display.  As the TGP crosshairs are slewed, the SPI will move along with it.  To un-assign the SPI from the TGP, you may either use the "reset SPI to steerpoint" function or assign the SPI to another sensor.  (example:) China Hat Aft Long.
 

Sorry, more confused than ever.  I did it to myself...

 

Before my above post I spent some time re-reading this section in the manual.   Then I went and flew so I could test this out.  Lo and behold, as I watched the TAD the SPI was locked on to the TGP LOS.  If I slewed the TGP then both the TGP LOS and the SPI  moved together.  Now, I can't seem to reproduce.

 

Can I borrow a sharp stick or a maybe a pencil? 

 

Caldera

Edited March 25, 2021 by Caldera