lukeXIII

The ghost velocity vector does not appear in the VSTOL mode. If the vertical flight path marker, velocity vector and ghost velocity vector could all be displayed at once they would all appear on the same plane; for example in the image above they would all appear on the -6 degree plane. The vertical flight path marker has an exception below 60 knots however where it will show the decent rate instead of dive angle.

A1-AV8B-NFM-000 23.16 Navigation Master Mode -> 23.16.10 Velocity Vector "In the NAV master mode, the velocity vector is always caged to the vertical center line of the HUD." 23.17 VSTOL Master Mode -> 23.17.6 Vertical Flight Path Symbol "The vertical flight path symbol is caged laterally..."

In the VSTOL HUD mode, the velocity vector which is usually caged vertically is replaced with the Vertical Flight Path Symbol which should be caged laterally. Currently there is no difference between the NAV and VSTOL modes. Attached image shows how it currently behaves vs how it should behave.

Before the recent open beta patch the CCIP system was only using the radar altimeter altitude for height above target calculations which is why bombs were not landing on the pipper in varying terrain elevations. Post update the system has been updated to incorporate the DTS so now the pipper much more accurately shows where the bomb will hit. Unfortunately they did not keep the old implementation for the radar mode with the ALT SCE switch.

CCIP/CCRP modes behave exactly the same. The problems for each submode specifically: CCIP/AUTO: Not reverting to other submodes when a target is not locked. RCIP/*RAUT: RCIP only functioning correctly with no designation and VV not intersecting ground. RAUT not functioning correctly. *BCIP/BAUT: Pressure altimeter settings not affecting calculations. BCIP not functioning correctly when designation not present. *GCIP/GAUT: Not functioning correctly when designation not present. *Not working correctly according to the TACMAN. The TACMAN does not mention how DTED is implemented into munition delivery so how they should work could be different based on newer documentation. So far the specific information on the ARBS I've found is: -Target lock acquisition period: 160 ms -Minimum spin rate for accurate range calculation: 2 mr/sec -Ballistics iteration rate: 11 Hz (possibly 16 Hz) How did you determine what angular rates are "good enough"? i.e is it 1.2x the minimum rate? 3x the minimum rate? Unless there is data that suggests otherwise, just the minimum rate should be used. Likewise how many measurements are required to generate a range? The video below at 6:20 is the only source I can find that shows the TV tracker in operation (it's a gr7 but equipped with the same ARBS system). It's hard to tell exactly but it doesn't look like it takes a couple seconds to generate a CCIP solution

Attempting to use CCRP in a dive with unguided bombs results in bombs landing significantly past the target. a10c2_ccrp.trk

Fix works for me.

Off the top of my head: HUD/INS slew mode Weapons Release Data Page (WRD) Separate brightness/contrast settings for different types of MFD pages (e.g changing map gain should not affect maverick gain) CCIP pipper should occlude the velocity vector Designation box/diamond should be occluded by CCIP pipper Gunpod should not be able to function unless sufficient air pressure is supplied (determined by airspeed and rpm) Action/no-action slew functionality (only one is used atm) DMT TV slave to sidewinder

Been posted here and DECOY said RAZBAM are aware of it: https://forums.eagle.ru/showthread.php?t=278491 Seems to be related to the weird target designation point that gets created when using gbu 38s, and the DMT will try to slave itself to this "invalid" designation.

That makes sense, I'll update the main post to reflect that. If my understanding is correct you wouldn't need to use that method, as you already know the initial position of the aircraft (GPS/INS coordinates + barometric altitude), bomb trajectory and the DTS elevation map. You would just need to solve the bomb trajectory equation with the height map to get an impact location, and then use some trigonometry to determine the sight line angle (and hence the pipper location).

The DMT does not include FLIR. Theres a separate fixed view FLIR sensor that can be displayed on the hud. You could be thinking of the TPOD which has a FLIR option.

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?

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?

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.