FCR air-to-ground sighting options
-
I have read all the documentation I can find, read forum threads, and I have no idea how to properly use sighting options.
I select air-to-ground master mode, GM, or GMT, CCRP, enter values for OAP1 and OAP2, but no rotary options appear. I have done the same with either VIP or VRP with the same result.
I have no idea what it is that I’m not doing, though I’m sure it should be obvious.
-
If anyone has an idiots guide to sighting options, I would be very glad to learn from someone who has mastered the mysteries of this obscure and intriuging art.
-
Supanova, see if this link helps… never have used them, but saw this some time ago…
It’s for the “older” version… don’t know if anything changed
-
Supanova, see if this link helps… never have used them, but saw this some time ago…
I was making the schoolboy error of not adjusting steerpoint on the DEST page. I now have that hurdle overcome, at least for OA’s.
-
I’m going to look at one thing at a time.
Steer points may have up to two offsets, each defined as a true bearing and range from the steer point and each with a separate elevation. If an offset aim point has zero range, it is skipped in the sighting point rotary. If OA1 or OA2, all sensors are pointed to the offset position; however, the steer point defines the target location. As a result, weapons may be delivered against a target that presents a poor radar return by aiming at a radar-significant object. Offset aim point sighting is provided in preplanned submodes (CCRP in this case, since LADD and ULFT are not implemented) only. The OA symbol is an isosceles triangle 12 mr high and 6 mr wide. It is displayed in NAV and A-G mastermodes.
I understand how you might use Offset Aimpoints as visual references in NAV mode. But I don’t understand their use with CCRP.
When using OA’s in CCRP mode, are you just setting one OA? I’m surmising you place OA1 on an object with a clearer radar signature than the target, and sensors take that as a reference point to the actual target? I can’t see how that could work if you set both OA’s.
-
I understand how you might use Offset Aimpoints as visual references in NAV mode. But I don’t understand their use with CCRP.
Lining-up with a runway, or a column of vehicles you know the heading of. You’ll drop 6 bombs with a spacing of 500 ft and you want them to disperse over the column, as you would when you set an azimuth on JSOW. Using the radar as a reference to line-up is not really easy, visual cues are easier to refer to.
-
Lining-up with a runway, or a column of vehicles you know the heading of. You’ll drop 6 bombs with a spacing of 500 ft and you want them to disperse over the column, as you would when you set an azimuth on JSOW. Using the radar as a reference to line-up is not really easy, visual cues are easier to refer to.
I understand the visual element, but the BMS and official documentation refers to using OA’s as a sensor reference point, and I’m not sure how that works in a practical sense, unless I’m correct that you just set one OA, and the sensors remain achnored to that while still retaining the steerpoint as the actual aim point.
-
I’m pretty sure BMS has this modeled wrong. The steerpoint should ALWAYS define the target location, the two OA’s are used to point sensors, FCR mainly, in cases where the target would not generate a radar return directly. When you select OA1, you slew the radar cursors over the pre-planned radar significant point and using the offset distance and range this defines target location. The actual CCRP solution cue/box will still lay over the intended target (the steerpoint). You can plan two offsets OA1 and OA2, but the the steerpoint is always the target.
BMS treats the OA’s as SPI’s and you can see the CCRP solution cue moving to the OA position as if you want to attack it (the OA). This is wrong.
-
I’m pretty sure BMS has this modeled wrong. The steerpoint should ALWAYS define the target location, the two OA’s are used to point sensors, FCR mainly, in cases where the target would not generate a radar return directly. When you select OA1, you slew the radar cursors over the pre-planned radar significant point and using the offset distance and range this defines target location. The actual CCRP solution cue/box will still lay over the intended target (the steerpoint). You can plan two offsets OA1 and OA2, but the the steerpoint is always the target.
BMS treats the OA’s as SPI’s and you can see the CCRP solution cue moving to the OA position as if you want to attack it (the OA). This is wrong.
That is interesting. That might also explain why this information is so hard to find.
I’d be interested to hear more input on this to confirm incorrect implementation. Perhaps it’s on a todo fix list if it is indeed not working as intended.
-
I feel like I’m flying in the 90s here… Why is this so complicated in BMS? With most targets you have coordinates. If it’s mobile like a vehicle, then throw a steerpoint down and slew your TGP to it (can be done with stationary targets too). The only situation this may become tricky is in DEAD. Real world we never use the A/G radar; it’s terrible (some people have never even used it). We have better technology like a TGP.
-
I think that’s the point. We are flying in the 90’s.
After all, MLU-M1 was current on the original F4 release, and it contains the same information in the BMS documentation.
-
I feel like I’m flying in the 90s here…
I mean the BMS Viper is like 6 tapes behind its real world counterpart so the 90s is probably an accurate assessment of the current state of the avionics (aside from having a few newer items cherry picked from later tapes like HMCS, JDAMs, etc).
-
Real world we never use the A/G radar; it’s terrible (some people have never even used it).
Do you think that will change once you guys have fancy new APG-80s or APG-83s?
-
I feel like I’m flying in the 90s here… Why is this so complicated in BMS? With most targets you have coordinates. If it’s mobile like a vehicle, then throw a steerpoint down and slew your TGP to it (can be done with stationary targets too). The only situation this may become tricky is in DEAD. Real world we never use the A/G radar; it’s terrible (some people have never even used it). We have better technology like a TGP.
I mean the BMS Viper is like 6 tapes behind its real world counterpart so the 90s is probably an accurate assessment of the current state of the avionics (aside from having a few newer items cherry picked from later tapes like HMCS, JDAMs, etc).
In fairness, there is no RF or true thermals modeled in BMS so the A/G radar is significantly more useful/effective in BMS than the real world counterpart, and the TGP significantly less so. Odds are if the real world radar were 50% as effective as the BMS version, the TGP may have been developed in an entirely different fashion; specifically tailored to the A-10s and other platforms which rely heavily on visual acquisition, and then adopted to the F-16s to provide guided munitions support, instead of the other way around.
-
OAPs are designed with an intentional offset between sensor and target as Adam106 suggests. The idea is that your OAP is the orphanage and the target is the bad guy bunker. You point your sensors at the orphanage (OAP) but the bombs drop on the bunker, the offset being programmed into the jet. The bombs should never be dropped on an OAP. BMS (wrongly) changes your weapon aiming along with your sensor aiming causing bombs to fall on the orphanage.
This somewhat changes the utility of OAPs. You can use them as “alternate DMPIs” but if you want to use them for their intended purpose you have to rotary back to target after refining system deltas with the OAP as the aiming location or risk delivering weapons on the OAP instead of the target.
I’ll see if I can do a write up using a default training mission as a basis to demo OAPs and IP/RPs. It’s not that complicated in total but initial access to understanding isn’t so easy. Some of the features like automatic switching of navigation and sighting locations aren’t working 100% and there are a few bugs which are obstacles as well.
-
I feel like I’m flying in the 90s here… Why is this so complicated in BMS? With most targets you have coordinates. If it’s mobile like a vehicle, then throw a steerpoint down and slew your TGP to it (can be done with stationary targets too). The only situation this may become tricky is in DEAD. Real world we never use the A/G radar; it’s terrible (some people have never even used it). We have better technology like a TGP.
The 90s? That’s way too modern for my brain.
But to be serious if you use the Recon map and Target Steerpoints it is pretty darn easy to deliver 7 JDAMs in one pass and I use TGP just to confirm that the target is still there (sometimes ADBs move and sometimes buildings are already destroyed – bc I don’t check the entire ATO to see if someone is going to beat me to the target by 1 to 90 minutes). Even with dumb bombs it’s the same story. GMT mode is great though for locating movers, but then I lay down a reference markpoint (in case I accidentally touch something that slews my TGP off into space) and switch to TGP prosecution. If the cloud base is below 11 to 14k depending on the enemy, I don’t chase movers. But I can usually find an area that looks relatively safe to drop down below the clouds and get the TGP verification that I like, but if the area is too hot I just race in and drop from high altitude. I would think that’s pretty close to 2010 and forward tactics?
I got to believe that all the modern fighter jets have at least Garmin 100 colored GPS scrolling map capability, I mean for Pete’s sake you can get them through Walmart?
And as much as I enjoy doing low altitude lofts I am guessing that is not implemented very often in real life. At some point its just smarter to toss a Tomahawk or a drone/hellfire at targets. Tomahawks have been around for a long time and the drones I think have been around since the second gulf war. And in a case where it’s just too dangerous due to whatever (including weather) these high risk missions that are so fun would probably be considered stupid risks in the real world.
Oops sorry for the ramble.
-
CCRP Sighting Option Familiarization
I. Sortie Preparation
Commit TE433_10_GPbombs
Select steerpoint 6
ICP-AG
Freeze simulation for data entryII. Data entry
A. OAP data entry
ICP-LIST, ICP-1 for DEST
NEXT/PREV to STPT 6
SEQ to OA1
RNG 2000, ENTR, BRG 900, ENTRB. VRP data entry
ICP-LIST, ICP-9 for VRP
ICP-0 to enable TGT-TO-VRP
VRP NEXT/PREV set target steerpoint to 6
RNG 4000 ENTRIII. Ingress
Verify VRPCRP or CCRP HUD text depending on VRP use.
Use TMS right or FCR OSB 10 to cycle rotary options
Note OAP position 2000’ left (east) of target
Note RP position 4000’ near (north) of targetVI. Notes
OAP2 use is identical to OAP1.
VIP function similar to VRP.
OAP and IP/RP use is independent; use either or both.
VIP and VRP functions are mutually exclusive.
OAP/IP/RP are incompatible with snow plow (points are relative to select steerpoint and not snowplow’s pseudo-steerpoint).
VIP-to-PUP bug displaces the PUP as entered relative to TGT instead of IP.
OAP and IP/RP data can be stored in the data cartridge from mission planning. -
Gents:
Okay I checked the -1 and I am not finding an explanation as to the theory behind VIP and VRP and PUP. I don’t even know what those acronyms stand for, nor why they would be useful?
Maybe this is why @Fox3TwoShip feels like we’re stuck in the 90s? I mean that technology isn’t really utilized anymore? Even so, I like flying old school so I am still curious what this is all about. I understand using OAPs to get a visual cue in your HUD (i.e. a runway layout if clouds obscure TGP). But the VIP, VRP, and PUP stuff is greek to me, if someone has a moment or two to flesh that out or point to an article on it that would be much appreciated.
@Frederf typo as to bearing?
-
BMS1-F16CM-34-1-1
Sighting Options
p.27And real world:
MLU_M1
SECTION 5 AIR-TO-GROUND RADAR
p.153Both provide about the same scope.
-
With regard to Offset Aimpoints:
weapons may be delivered against a target that presents a poor radar return by aiming at a radar-significant object
The problem appears to be that the implementation in BMS isn’t accurate and the offsets are treated as the target itself.
With that in mind, I’m not clear how OAs are used in BMS without compromising the attack.