lukeXIII

Check the videos again, there is sufficient separation between the velocity vector and the pipper sight in both examples.

In regards to: https://forums.eagle.ru/showthread.php?t=275176 After investigating this issue I noticed that dropping bombs in CCIP resulted in consistently impacting above the pipper when trying to hit a target on a mountain and consistently impacting below the pipper when trying to hit a target in a valley. This behaviour seemed very similar to how the radar altitude source mode should work and led me to believe that the elevation being used in the calculations was from the DTS elevation directly below the aircraft instead of using the SPI set on the target. For reference, setting a manual steerpoint elevation resulted in bombs landing on target. Using a CCRP level drop also resulted in bombs landing on target indicating that the DTS elevation of the target is being used: As the A10c generates a markpoint for every weapon impact, this can be used to determine the bomb trajectory and hence what elevation data is being used. The following test was performed for CCIP drops where the Height Over Ground was greater than the Height Over Target and vice versa. Bombs used were mk 82 LDGP. • Create markpoint on target • Set markpoint as SPI with DTS as source • Drop bomb when pipper crosses target • Change steerpoint to generated impact markpoint (MRK Z) • Inspect MRK Z location compared to target location Case 1: Target on a mountain. Height Over Ground > Height Over Target Bomb impacted above the pipper, inspecting MRK Z showed that calculated impact point was inside the mountain and below the target. Figure 1 shows diagram of pipper and bomb trajectory. From this we can see that the elevation source being used was from the ground below the aircraft and not the target elevation. Case 2: Target below a dam. Height Over Ground < Height Over Target Bomb impacted below the pipper, inspecting MRK Z showed that calculated impact point was floating above and before the target. Figure 2 shows diagram of pipper and bomb trajectory. From this we can see that the elevation source being used was from the ground below the aircraft and not the target elevation. To conclude, the CCIP solution is incorrectly using the DTS elevation directly below the aircraft instead of the SPI DTS elevation. DTS elevation is able to be used at the SPI as seen in level CCRP drops which means there must be a bug or oversight preventing the CCIP from obtaining this same data. If this issue gets fixed, the current behaviour should be similarly implemented into the Radar Altitude Source mode as this is accurate behaviour for that mode. UPDATE: SPI not required for CCIP, however the results are still the same.

I've figured out what the problem is. The CCIP solution is not using the DTS elevation of any SPI but is instead using the DTS elevation directly below the aircraft. This is basically acting as the radar altitude source mode; bombs will land above the pipper when the relative height directly above the ground is greater than the relative height above the target, likewise bombs will land below the pipper when the relative height directly above the ground is lower than the relative height above the target. This seems like a huge oversight considering that the DTS elevation of the SPI will be used for a level drop in CCRP.

Any source for that? The only thing I could find was the following: "The switch has three positions: OUT, NORM and IN. The switch is spring loaded to NORM. When OUT is selected, the speedbrake extends. When IN is selected the speedbrake retracts" which isn't clear whether it is an "all or nothing" function or not. If it was "all or nothing" though why would it be a 3 position switch instead of a 2 position toggle switch?

For reference I have no issues on my end with the same method. I noticed that your altitude hold disengaged during your turn which indicated that there was a minor pitch input. Watching the input display closely you can see there was a minor nose down input which resulted in you going "downhill".

"The pilot can use the control stick and the manual trim switch to maneuver the aircraft and lock the AFC onto new pitch attitude, roll attitude and heading references without disengaging the AFC switch during the maneuvers."

If you had read the rest of this thread you would have seen that people were able to fix this problem by increasing their deadzones.

Re-calibrate your joystick and/or increase your deadzones.

It's straight out of thel A1-AV8BB-NFM-000 manual. "Automatic pitch and roll trim are provided the AFC mode. The automatic trim tracks the aircraft pitch and roll changes to keep the series servo actuators close to their neutral positions an effort to minimize disengage transients. On aircraft with departure resistance, the lateral stick to aileron interconnect may prevent the roll auto trim from keeping the aileron series servos near the center of the ±6° range. The automatic trim rates correspond to approximately 0.25° per second stabilator and aileron surface rates and cause the control stick to move in the direction the trim change."

The AFC automatically controls the trim to hold attitudes, so when you disengage the AFC the trim will be where it was set by AFC. This is correct behaviour. You should also always be trimming the aircraft out before engaging AFC. "Just as in SAS mode maneuvering, the pilot must trim out any stick forces prior to releasing the stick." That's how it's supposed to work, and as above you should always be trimming out the aircraft before engaging the AFC. "At airspeeds above 50 knots, the AFC will capture and hold pitch attitudes in the ±30° range and roll attitudes within ±60° which are outside of the ±5° range about wings level."

I also have the same issue, all rockets landing far past the target in CCIP mode. I've noticed that the gun also has this issue although not as severe. It's always had the TGT ELEV info, which is based off current waypoint elevation or target designation elevation. The min and max range refer to the range carets on the outside of the CCIP pipper, and does not affect the target elevation data. There is separate bug that causes it being set to zero: https://forums.eagle.ru/showthread.php?t=272326 If it says manual it means you've set a manual release setting with the knob on the far right of the ACP. This should almost always be set to NORM.

There is no calculation required for the pitch caret setting, it should always be set to 14 degrees for takeoff.

Using low drag mk82s with CCRP, releasing in level flight results in a generally accurate impact. However when I try to use CCRP in a dive the bomb impacts significantly past the target. Below are two videos for comparison. Theoretically the dive drop in this example should be more accurate as the bomb time of flight is lower (as bomb is released at a lower altitude and a higher speed) however this is not the case. What's causing this inaccuracy?

From the last patch notes: "Added ability for small stick movement to adjust AFC trim" Before this patch with AFC engaged it basically ignored stick input until you added enough stick input to break out of AFC (which hid any neutral stick issues). With the corrected AFC; even though your deadzone may be the same, it is not big enough and as a result is taking this minor "stick input" and constantly adjusts the trim.

@Victor3 Increase your axis deadzones

The only way i can reproduce this issue is to hold back slightly on my stick, trim the aircraft into level flight whilst still holding back on the stick, and then engaging AFC. This leads me to believe that your deadzones are not significant enough and you should increase them. (To test try setting the deadzones to something abnormally high so you can tell if it works or not.)

Hi Decoy, this is directly related to the GBU-38. Here's a video and track of a different method but same results: Test.trk

Nah I think he's on to something. High drag bombs seem to consistently land past the target for me as well.

The target designation was intentional to try to highlight the issue but I see I didn't explain it very well. The best way I've found to highlight the issue is to compare the RCIP in the AV8B to the CCIP in the A10C which is behaving correctly. A10C: Flying level towards the dam we can see that the CCIP pipper moves up and down as we fly over the ridge, and when we pass over the dam we can see a sudden and rapid change in the CCIP pipper as a result of the sudden change in radar altitude (we can even pinpoint where the lip of the dam is). Now compare this to the AV8B under very similar conditions: The RCIP is invalid the entire time we are in level flight, which is obviously not correct. Here's a similar test however the dive angle is changed so we can get a valid RCIP pipper: The pipper seems to be correct this time however as we fly over the dam there is no significant change in the pipper as a result of the sudden change in elevation, unlike what happened with the A10C. So what exactly is happening that is making the RCIP pipper so different to that in the A10C? Well let's try putting this into practice and try to bomb a target that is sitting at the bottom of the dam: The bomb is released as the pipper passes over the target, however when we inspect the bomb trajectory we can see that it landed significantly short of the target. Flying back around to the target we can see that the designation point that was generated was floating above and before the target. Why was this target designation point generated here and not on the target? The rough image I made below shows how this designation is created; the Height Over Target (HOT) is being calculated from where the velocity vector is intersecting the ground (or water in this case) which is resulting an RCIP pipper angle that is not related to our target. So to conclude; without a target already designated the RCIP is not using the radar altimeter height to calculate the HOT, but is instead using the velocity vector. (This behaviour is also the same if you switch RCIP to GCIP or BCIP.

The issue doesn't have anything to do with negative G's. Watch the start of the video again, I'm putting on positive and negative Gs and the pipper acts normally because the velocity vector is intersecting a similar elevation to the ground in front.

RCIP (BCIP and GCIP as well) is not functional. Here's a better representation: Notice how everything looks normal when the velocity vector is tracking along the ground and then immediately starts going weird as soon as the velocity vector tracks up the mountain. Also notice the behaviour when a target designation is placed at a higher elevation than the jet: the RCIP solution becomes invalid no matter how close you fly to the ground.

Example of said behaviour:

As others have said, high drag bombs are not precise and you shouldn't expect them to be pinpoint accurate. Going in depth: the logic RAZBAM uses to calculate the CCIP mode impact point WITHOUT A DESIGNATION POINT is very weird. It will attempt to use the elevation of whatever the velocity vector is pointed (e.g a mountain) at as the reference altitude. If this elevation is different to your target elevation then your bomb will fall short or long of the target (even though it will look like your pipper is on target). The solution to this is to always have your target designated beforehand until RAZBAM fixes this.

Also the UFC Display Brightness Control dial only switches the display on and does not affect brightness.

So further testing the brightness dials and mfd buttons only affect symbology and do not affect any sort of image or video that is displayed on either the MFDs or HUD (DMT, TPOD, MAP, MFD FLIR, HUD FLIR, IRMV).