lukeXIII

I believe that refers to the lurching that used to happen the moment you removed the wheel chocks.

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.

From the same manual: "After landing the laser code is set to the default code (1111). This occurs five seconds after a weight-on-wheels transition is detected." It's possible that 1111 is the "zeroed" value.

https://youtu.be/CoZC6PNubfQ Rounds not landing on pipper even well within range. Issue occurs with and without a target designation.

It seems there has been some misinterpretation on what the EHSD DESG button does. Pressing it should simply designate the selected waypoint (or offset, markpoint etc) and show whether a designation exists or not. It should automatically become boxed if any system designation is created, either from pressing the button or from designating a target through any other sensor (e.g TPOD, DMT, HUD). It does not seem to be a button used to “prepare the INS for AUTO deliveries” for every other sensor. It seems this confusion has come from the statement “no DESG, no AUTO”. Whilst yes this statement is true in that there must be a system designation present in order for the AUTO mode to work, a more clarified statement would be “no system designation present -> DESG is not boxed -> no AUTO drop available”. As Zeus pointed out, the CCIP to AUTO conversion “worked without the DESG being prepped” but couldn’t explain why. The CCIP to AUTO system works by creating a target designation on initial press of the bomb pickle. As a target designation has been created, AUTO delivery becomes available and DESG should be automatically boxed as DESG-TGT. This should also translate to every other system that generates a system designation. With the other systems this is also the point where you would want to hold WINC to convert the target point to a steer point. In short: If a system designation is present then AUTO delivery is also available. DESG is automatically boxed (as STP or TGT) if a system designation is present Creating a target designation though any sensor (other than pressing the DESG button directly) should cause the DESG button to become boxed as DESG-TGT Pressing NWS/Undesignate should remove any system designation and unbox DESG (excluding a certain TPOD case). The SOP as described by the SME is still valid and should be followed whenever possible

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

The bomb release cue should appear when a bomb toss with release prior to 45 degrees is possible. At the moment the cue appears at 6 seconds to release, which should only occur for high drag bombs. It doesn't say what g is used in the calculations, but I assume it's based off a 4g pull up like the PUC and LOFT modes. Reference: A1-AV8BB-TAC-000 section 2.5.1 low_drag_bomb_cue.trk

The TV sensor should not be roll stabilised in air to air mode. Reference: A1-AV8BB-TAC-000 section 1.10.4.1 Tried to show it as best I could in the track file with the mountain/horizon. DMT_AA.trk

The symbol should be roll stabilised. Reference: A1-AV8BB-TAC-000 section 1.10.5.2 DMT_HUD.trk

When in A/G mode and INS sensor mode, pressing TDC down creates a designation point at the caged velocity vector location instead of the non-caged position. INS_designation.trk

Fix works for me.

As ChickenSim stated, ARBS should not factor into this as it a) has not been selected as the altitude source and b) no target has been locked by the DMT. Here's a practical example of attempting to bomb a target at the bottom of a dam using RCIP and mk82 slicks: It can be seen that the bomb falls significantly short of the target. Doing a fly by of the designation point created at pickle shows that it is hovering in the air and before the target. The reason for why this designation point was created here and not on the target is because it used the elevation of where the velocity vector was placed which was on top of the dam. The attached images below shows how it is currently working and how it should be working. Also to note on the designation fly by: the RCIP is also affected by the designation point elevation (which is not correct behaviour) as can be seen with an invalid pipper. Just to sum up again: Pipper location is related to the Height Above Target (HAT) Current RCIP (no designation + VV not intersecting ground): HAT = RADALT (correct) Current RCIP (no designation + VV intersecting ground): HAT = Geometrical altitude - velocity vector intersection elevation (incorrect) Current RCIP (with designation): HAT = Geometrical altitude - designation elevation (incorrect) RCIP should be behaving the same with or without designation and regardless of VV, where HAT = RADALT for all cases (Side note: the "HOT" in the figures should be "HAT") RCIP_example.trk

A1-AV8BB-TAC-000 pg 270 (or 1-200) section 1.10.5 ARBS Management and section 1.20.5.1 ARBS/LST Designation -Laser code should be set to 0000 with weight on wheels (currently it initialises at 1111 which is considered a valid laser code) -The LST mode should not be able to be selected if a valid laser code has not been entered Valid laser codes: 1st digit: 1 2nd digit: 1-7 3rd digit: 1-8 4th digit: 1-8 -The LST mode should be able to be selected if there is a designation point; the scan pattern centred on that point if within gimbal limits (currently cannot be selected) DMT_LST.trk

This attached track is just to show that cycling through the different bombing modes results in no change to the pipper location (only change is designation/no-designation) meaning that all bombing modes are behaving exactly the same. av8b_all_bombing_modes.trk

TAC-000 pg 492 gives a summary of how the radar altimeter altitude is used for the "height above target". For RCIP the radar altimeter is the only altitude source used to determine the impact location, and hence line of sight angle and pipper location on the HUD. This means that the pipper angle should decrease (i.e it moves up the hud) if the radar altimeter altitude decreases and vice versa. Just to restate from the original post, the bug with RCIP is that the correct behaviour gets overridden when the velocity vector intersects the ground. The CCIP in the a10c currently behaves how the RCIP in the av8b should be. Attached are two similar profiles flying over the dam; the pipper in the a10 correctly moves up and down as it passes over the dam whereas it does not in the av8b. Also in the av8b track you can see that the pipper behaves oddly in a climb which is a result of the velocity vector giving a higher target elevation than the av8bs current altitude. For RAUT (the same TAC-000 page), how it should function is that it should take a single reading from the radar altimeter altitude when a target is designated to determine the "height above target" and then use barometric data for the rest of the run in. Currently the "height above target" is calculated from the exact target designation elevation and the exact geometrical altitude of the av8b which can be seen in bombs landing perfectly on target regardless of errors due to terrain. a10c_CCIP.trk av8b_RCIP.trk av8b_RAUT.trk

I should add that this behaviour is exactly the same for CCIP, BCIP and GCIP (which makes no sense for those modes). The only thing changing in game is the letters that show up on the hud.

Whenever the velocity vector is not intersecting the ground the RCIP pipper behaves as expected and moves up and down according to radar altimeter height (see video 1) However when the velocity vector is intersecting the ground, radar altimeter height stops being used. In the example below (video 2) there should be a rapid change in the RCIP pipper postion due to the sudden change in elevation flying over the dam however this is not happening. What I think is happening: Currently in game the DMT gets the exact elevation of whatever it is looking at. By default the DMT is slaved to the velocity vector, and so the elevation of whatever the velocity vector is looking at is being used in the bombing calculations. When there is an existing target designation, the height is locked to that elevation which makes the radar altimeter height meaningless. Radar altimeter height is not being used at all for RAUT; bombs land on target regardless of varying terrain.

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.