Flagrum

Every other week someone accidentally posts there, but I don't think anyone still runs 2.0 ...

it's likely a bug. see https://forums.eagle.ru/showthread.php?t=277769

I haven't found out the exact pattern here, but something is broken with AUTO deliveries of dumb bombs when switching priority stations with the STEP function. The EFUZ setting seems to get lost sometimes if the QTY is changes before or after switching the priority station with STEP. The delivery options and fuze settings apply to all stations, it is not a setting per station/bomb, correct? So if I pickel several times, the aircraft itself switches subsequently through the stations and effectively all releases use the same EFUZ setting and all bombs explode on impact. But if I change either QTY or (or maybe both, not sure here) STEP to another station before pressing pickle, the newly selected station(s) sometimes do not respect the EFUZ settings (i.e. go dumb and don't explode). This seems to be only related to AUTO delivery, CCIP seems to work ok in this regard. Also this seems to be only a problem, if I manually STEP - if the aircraft switches stations, it seems to be ok as well. AUTO EFUZ 1r.trk AUTO EFUZ 2r.trk AUTO EFUZ 3r.trk

I tend to agree that CCIP can be more accurate than CCRP - given that the symbology is exact. In CCIP, you always see exactly where the wepon will impact. Slight corrections of the aircraft attitude result in precise adjustments of the pipper. In CCRP however, you only have your velocity vector that you have to a align properly in respect to the bomb fall line. Slight attitude corrections are barely visible due to the thickness of the lines of the symbology. One degree deviation is maybe a visual difference of one pixel but it would be clearly visible in fractions of an inch with the CCIP pipper. But maybe this thread isn't the right place to discuss this ...

The PTRK offset cursor (ATRK not tested) does not stay ground(?) stabilized at the with TDC depress designated position. Instead it is "DDI stabilized", meaning, it's absolute position on the DDI screen does not change. (The red box ensures that the lines are parallel to the DDI frame. ) In both pictures, the right border of the red rectangle goes through the offset cursor and the right side of the attitude indicator, although the video feed has changed as we got closer to the target. Note: a) the actual target designation with the offset cursor (tank on the left) is correctly maintained! This becomes evident when switching from PTRK to OPR: the target diamond is then correctly placed where the designation was (and not where the offset cursor cross was in the end). b) Zoom and FOV scale the position of the offset cursor correctly on relation to the video feed. I.e. as the image gets smaller when zooming out, the reticle moves accordingly as well - but is still in it's wrong relative position. TGP offset cursor.trk

"presume", "may be" ... hrm. If we all don't really know, what is wrong with asking? I, too, find this behaviour a tad bit ... strange. It is really no big deal, but it seems to be somewhat "backwards"? Or at least less intuitive? I mean, we have one button that performs one function in this context: undesignate. What do we gain, if we add another function, that even perform two tasks (1. undesignate + 2. enable VVSLV)? Why not keep it simple: 1 x for undesignate (no ambiguities here), and when in snowplough: 1 x to enable VVSLV? I could easily be convinced that the documentation says something like "to enable VVSLV, depress UNDESIGNATE twice". ED interprets this then as double-click, but it could also be very possible that my solution was actually meant. The only differens for the pilot is the timing of the two depresses - instead of click-click only click, click ...

The calculated range should be quite the same if I measure the bottom or the top end of a larger target, right? Perhaps the slant range is a few ft shorter at the top, but that is negligible here. The follwing pictures were taken when in Active Pause (so that the overall range does not change). The TPOD is telling us, that the slant range difference is 0.2 nm between top and bottom of the water tower!? This is rather the difference between the bottom of the target and the point on the ground behind it. (Also, after PTRK-->OPR, when the TPOD slews to a new position, designated using the offset cursor, the range information is not updated. Only after moving the reticle a bit, the range info is updated. But this is probably a different issue.)

Yeah, I just re-watched it. But there are some interesting details in that scene: - LST/R is not shown during that process, so I assume the laser wasn't even armed? - At least shortly during/after TDC depress I would expect LST/R to be shown _and_ flashing as indication that the laser was doing something - the range shown was updated continously as the aircraft came closer to the target. I assume, this is just the calculated (slant?) range, probably based on the initial laser ranging. In the A-10, the aircraft utilizes the digital map data to calculate the slant range, even without lasing first. What I try to say here: just because a range is displayed does not mean that lasing must have happened initially. So, my bet is on "still WIP" here. Slant range calculation + display works, but the initial laser ranging is probably not implemented, yet.

Indeed. I found three different threads that the issue is known WIP / maybe fixed / related to a different WIP issue: Hrm, I might experiment a bit with realistic TDC slew on / off ... edit: and just now this So it might be related to wether it is the first Maverick being selected and fired or subsequent ones. In my case, I have probably only restarted the test mission with CTRL+R (SHIFT + R?) several times to eventually produce the .TRK. So, maybe there is some global initialization issue with the MAVF code? I'll check that as well.

Can I get a [REPORTED] here pretty please? ;D

I think, laser ranging is not implemented, yet.

Afaik single press to undesignate which will cause the TGP go to snowplough. Double press enables VVDSG.

The LTD/R switch at the sensor control panel activates (ARM) with LMB and deactivates/SAFE with RMB. All other switches use the opposite binding (i.e. forward/up = RMB, back/down = LMB).

After some research, I am now convinced that the constant updating of the coordinates is correct. Also the behaviour that all respective weapons in case of QTY > 1 get updated with the same coordinates seems to be legit as well. Source: ### self redacted, see 1.16 ###

To replicate this bug: make sure that no target designation exists (i.e. TPOD shows no target diamond in OPR). For example, right from snowplough mode.

Regarding step 7 - yeah, I fell into that trap when I experimented with your procedure. If you have QTY selected, the coordinates will be updated for all selected JDAMs. And that, no matter what procedure you follow. STORES page or individual TOO MSN page, all selected bombs will update their coords. But if you select QTY after setting individual coords, they keep them (unless you mess up with not undesignating at the end). This seems to be some somewhat inconsisten behaviour. Why should it matter _when_ i select a certain option? One could say, this is a quick way to deliver multiple weapons at the same target - similar to rippling a few dumb bombs. But why can I then step between the QTY selected weapons, if I can't change their setup individually? Makes no sense to me ...

When uncageing the MAVF, the seeker head automatically slews to the designated target and tries a lock-on. But if there are other objects in the path the seeker head traverses, the missile will lock-on those instead. Track, s. attachement. Here I briefly inspect the targets with the TPOD. Then I designate TGT2 with the TPOD and the uncaged MAVF slews to it perfectly. But when the designated target is TGT1, then uncaging the MAVF will result in a lock onto a random building of the village between boresight and TGT1: What I would expect: the missile should only attempt to lock somethig after establishing the desired seeker head position, i.e. after slewing is finished. MAVF lock after uncage.trk

Hrm, I tested it just a few hours ago - while the MAVF slews to the designated target, it locks on random objects on it's way. So, that is at least not fixed (or broken again). Visually it looks as if the MAVF seeker head / the reticle stops half way between bore-sight position and designated target position. Are you sure that this is not the problem this thread is about?

The issue seems to be that the MAVF is locking the first suitable object that it sees while it slews the seeker to the designated target after uncageing. So, at the extremes of the gimbal limits, the way it has to slew the seeker is long and chances are high that it encounters a random bush or hut that it then locks on to. If you point the borsighted MAVF as close as possible to the intended target, then only minimal slewing is necessary and thus a higher probability that it only sees the intended target and also locks on to it. --> MAVF should only start to attempt a lock after the seeker head has reached its final position over the designated target. (maybe all this is a side effect of not having "realistic TDC slew" enabled? Would the MAVF only attempt a a lock, if TDC-depress is released? And without "realistic TDC slew" the TDC is always in a "depress released"-state?) edit: (no, "realistic TDC slew" has no effect on the MAVF behaviour in this case. just tested it - it still locks on at any random object along the way the seeker head is slewing to the intended tgt)

I think what he means is this: your TPOD remains centered on the general target area, but you can designate several targets around the original target point. But, as I seem to have learned today, just slewing the offset cursor does nothing. You need to designate a different target with TDC depress. You will then stay in the offset cursor mode while the TPOD is still centered at the original point. From there you can continue to slew and designate the next targets with the offset cursor. Only if you leave that ATRK/PTRK mode, the regular designated tgt diamond will be slewn to the last designated point.

No, that is not what I meant. I am atm just focussing on the regular TPOD reticle. This shows the reticle when there is no tgt designation (i.e. snow-plough). A cross, a bit smaller than the ATRK cross. Then I moved this reticle and designated a point on the ground with TDC depress: The "designated target" diamond is still slewable, but now the JDAM coordinates are constantly updated. Wherever the "designated target" diamond is, the designated target is - and thus transferred to the JDAM. As I said, right now, I am only concerned with this, not the offset cursor. I only mentioned that earlier, because on the TPOD page, the offset cursor is not a diamond and I concluded that that is the reason why no coordinates are transferred ... as the current designated tgt point is not changed just by slewing the offset cursor. Instead, it needs a TDC depress to alter the position of the designated target point.

Starting from snow-plough mode with no designated target, I ground stabilize the TPOD reticle with either ATRK or PTRK mode. If i press UNDESIGNATE, the TPOD returns to snow-plough mode. But that works only if the point on the ground is still visible for the TPOD. Once I fly past that point and the TPOD stows itself (shows "MEM" at the TGP page + no video feed), UNDESIGNATE does not work anymore and the TPOD does not return to snow-plough. If a designate a target point with TDC depress (in either mode, OPR/ATRK/PTRK), UNDESIGNATE works in both cases - tgt point visible or not. tpod stowed no undesignate.trk

Regarding [CANNOT REPRODUCE, TRACK PLEASE] - see attachment. In this track you see me trying to slew, starting from snow-plough. I cycle through OPR (works), ATRK (no slewing, as expected), PTRK (no slewing, as expected) and then OPR again - but here slewing should be possible again, but isn't. I then do the same once more, ATRK, PTRK and back to OPR, but there still no slewing possible. Then I designate a target (TDC depress), the reticle changes from the small cross to the designated tgt diamond and then slewing is possible again. Cycling + trying to slew though ATRK and PTRK once more and in the end back to OPR. There the designated target diamond is still active and slewing is also still possible. In short, when returning from PTRK to OPR with no designated target, slewing the "no designated target" reticle does not work for me. tpod cycle modes.zip

I think, I found something out now ... There is the small cross that is slewable in OPR, if no target designation exists (i.e. snow-plough mode). No coordinates are transfered in this case. When designating with TDC depress, the TPOD reticle changes to the regular tgt diamond. Now this coordinate is transferred to the JDAM. But as the tgt diamond remains active when slewing now, the coordinates are constantly updated. I wasn't really aware that there are two different reticles in OPR mode, lol. When designating a tgt while in ATRK or PTRK with the offset cursor, only at TDC depress the coordinates are transferred. Which makes some sense, as the offset cursor is not the "currently designated target diamond" So, as such, this seems to be consistent. If I now have a WPDSG tgt, the TPOD slews to it and shows already the designated tgt diamond. If I slew the reticle away from that position, it is switched to the "no tgt designate" (small cross) reticle - until I designate a new one with TDC depress. The reticle changes to the diamond and from now on the JDAM coords are updated constantly. And here is one small bug, I think: WPDSG is still enabled, although there is a newer designation present. And besides all that, I still find it weired that the "designated target" diamond reticle, can not be reverted back to the "no active designation" cross somehow (without completely undesignating everything and starting over from scratch).

WAD? And no, I mean something different: Situation: no target designation exists, TPOD is in snow-plough mode Step 1: TPOD=OPR, I can slew the reticle without problem Step 2: Cycle to TPOD=ATRK, I do nothing as I can not slew anyways. Step 3: Cycle to TPOD=PTRK, again, no slew, but I don't even want to slew. Step 4: Cycle to TPOD=OPR. Now slewing should work again, right? But it does not. (Step 5: VVSLV + UNDESIGNATE --> continue at Step 1)