Jump to content

Frederf

Members
  • Posts

    6248
  • Joined

  • Last visited

  • Days Won

    3

Community Answers

  1. Frederf's post in HUD change? was marked as the answer   
    ILS command steering cue, the mode when the airplane hasn't captured the glideslope from below and is getting lateral guidance.
  2. Frederf's post in ATFLIR - Is this a bug or just me ? was marked as the answer   
    Double undesignate enters both VVSL and then again to enter a mode that doesn't have an explicit name. It's "OPR" but a stabilized vector at infinite distance. I'm going to call the FLIR states: slaved, INR/direction, INR/point, SCENE, and AUTO. What you're calling "snowplow" I'm referring to as INR/direction. I'm going to use sensor control switch (SCS) to mean castle.
     
    From slaved (WPDSG) state you have three options to have a slewable FLIR picture
    With FLIR selected, TDC depress to command a new FLIR target designation. It will be essentially at the previous slaved waypoint since FLIR LOS was already pointed at it. Mode will switch from slaved to INR/point. With or without FLIR selected, undesignate x2 to enter INR/direction. FLIR will drift off waypoint since FLIR is fixed in direction. Slewing (with FLIR diamond'd) is then possible in this INR/direction state. With FLIR selected, SCS right for SCENE. The reason that the FLIR LOS returns to the waypoint when you use option #3 and cycle through the modes is because the target designation has not been changed and FLIR is still slaved to the waypoint-target in the blank-labeled slaved-to-target mode. As long as you TDC depress while in SCENE or AUTO (or INR) before you SCS right rotary back to the slaved-to-waypoint mode then FLIR will remain as you rotary through the INR/SCENE/AUTO modes.
     
    So try the following:
    WPDSG SCS right once (or twice) to scene (or auto) slew TDC depress slew SCS right twice (or once) to return to blank/INR Omitting the step "TDC depress" has behavior that advancing past AUTO in the rotary selection will cause the FLIR to resume the slaved-to-target-waypoint behavior.
  3. Frederf's post in Air to Air TGP Questions was marked as the answer   
    TGP for AA missile employment is the sort of thing that gets updated frequently over the lifespan of F-16. A 1985, 1995, 2005, 2015 airplane are going to have significant differences in capability.
     
    Let's look at what are the theoretical sources for missile cueing for the AIM-9 and AIM-120 respectively. Those options are:
    Nothing (boresight) Radar TGP Helmet cue Datalink As of M2 tape it's been possible to slave AIM-9 to TGP LOS. The TGP may track an AA target independent of the FCR. A dotted TLL is shown on the HUD. Laser rangefinding to AA target is possible. AIM-9 will be slaved to TGP LOS automatically if TGP is tracking and SOI (thus priority over FCR) and AIM-9 is set to SLAVE (not BORE) on SMS. While TGP is not tracking the missile is slaved to boresight. With FCR ACM and TGP AA tracking TMS right commands FCR to track along TGP LOS (instead of normal 30x20 pattern) provided SOI is either FCR or TGP. Correlation of missile and aiming sensor (radar, optical) and caged status is indicated by TLL display on the HUD. This allows prosecuting TGP tracked AA targets with AIM-9 which are off HUD. Since there's no range when using TGP cueing the HUD DLZ and flashing "shoot" diamond are not shown. I don't think they come back if laser rangefinding is provided (since only range, no closure info?).
     
    TGP-cued AIM-9 attack is absolutely a thing either without or in concert with FCR. I don't know about AIM-120. In general AIM-120 won't let you initiate a launch without good data (no coast/notch) although it will let you continue a launch which has lost those requirements. Maddog I don't believe if every cued in any direction except BORE straight ahead. Maybe helmet can cue the boresight direction similar to AIM-9. I don't know. TGP AIM-120 engagement I don't believe is a thing except by cueing ACM FCR with TGP LOS and then attacking as normal, same HMCS.
  4. Frederf's post in Anyone notice weird issues while trying to use the targeting pod and mavericks together? was marked as the answer   
    Here's a less than 10 minute track of a ramp start, boresight, and attack with two Maverick against two targets.
    F16 Maverick Boresight and RP2 Attack.trk
  5. Frederf's post in So what happened to JHMQS in A-10CII was marked as the answer   
    Scorpion is a Thales (acquired from Gentex,  Visionix division; also Raytheon was join with Gentex) product which fulfilled the HMIT military program requirement. It is a HGU-55 (in A-10) helmet fitted color monocular device. The Thales change of owner changed the magnetic to an optical-inertial tracking system.
     
    JHMCS is an Elbit Systems/Rockwell Collins (collaboration division Rockwell Collins ESA Vision Systems LLC) product. It is derivative of DASH III and Kaiser Agile Eye by VSI. Unlike Scorpion it's not monocular and requires modification to the HGU-55 helmet. Instead of being merely compatible with also wearing NVDs the JHMCS replaces NVD function as an internal capability.
     
    Scorpion is better than JHMCS especially for AG. JHMCS's big deal was AIM-9X integration. It's older.
  6. Frederf's post in Can't lock Link 16 targets and how to display wingman was marked as the answer   
    "Lock" is a funny word when it comes to radar. I don't know if there is an agreed upon definition of what is and is not a lock in the F-16. I would recommend using the more common terms like "track "bug" "STT" and similar. Unless there is functionality I'm unaware of, it's not possible to bug any contacts which are known exclusively to the datalink. To bug any contact (i.e. make it target of interest) the radar must have contact with the target.
     
    Due to the display of the FCR it can be confusing or even impossible to know what state the contact object is in and how to proceed. Here is what a single IL-76 looks like with MIDS on and TWS but the radar is aimed (or too far) so that it does not see the contact.
    L16 contact without radar detection is hollow.
    Radar aimed down to see target and at first a contact is displayed near L16 object because not enough information is available to make a track file.
    After a few scans the target becomes a track file. At the same time it is correlated with the L16 track becoming a filled triangle.
    Turning MIDS off to see radar without L16. It's a non-steppable/non-snappable tank track*. Normally L16 remains on but this shows what's happening better.
    With cursors over track TMS forward the first time. Azimuth narrows to "A2" and cursors snap to object. Track is "system type"*.
    TMS forward a second time. Now you can see the track is bugged by the circle around it.
    TMS forward a third time. This commands STT which is signaled by the cursors and all other tracks disappearing.
     
    Now I will do the exact same process again but leaving L16 on.
     
    Radar can't see L16 track
    Radar contact next to L16 track
    Radar makes track, correlates with L16 track
    MIDS remains on.
    TMS forward once, cursor snaps to target, azimuth narrows "A2"
    TMS forward second time. Target is bugged.
    TMS forward third time. Target is STT.
     
    *Since the last time I looked tracks were shown (with MIDS off) as solid for tank-type and hollow for system-type. That is no longer the case. Currently tank-type and system-type look identical. The difference is that tank-type cannot have cursors snapped to them nor will they appear in the TMS right short rotary stepping through tracks.
     
    The radar should be understood fully without L16 first. The addition of L16 information is very confusing because sometimes it correlates with radar data and sometimes not.
×
×
  • Create New...