Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by lukeXIII

  1. 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.
  2. https://youtu.be/CoZC6PNubfQ Rounds not landing on pipper even well within range. Issue occurs with and without a target designation.
  3. 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
  4. 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
  5. Attempting to use CCRP in a dive with unguided bombs results in bombs landing significantly past the target. a10c2_ccrp.trk
  6. 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
  7. The TV sensor should not be roll stabilised in air to air mode. Reference: A1-AV8BB-TAC-000 section Tried to show it as best I could in the track file with the mountain/horizon. DMT_AA.trk
  8. The symbol should be roll stabilised. Reference: A1-AV8BB-TAC-000 section DMT_HUD.trk
  9. 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
  10. 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
  11. A1-AV8BB-TAC-000 pg 270 (or 1-200) section 1.10.5 ARBS Management and section 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
  12. 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
  13. 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
  14. 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.
  15. 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.
  16. 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
  17. 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.
  18. 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).
  19. 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.
  20. Check the videos again, there is sufficient separation between the velocity vector and the pipper sight in both examples.
  21. 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.
  22. 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.
  23. 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?
  24. 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".
  • Create New...