uboats

it's known and under investigation. Everything was ok when we migrated to agm88 scheme before ob release. We dont know what has been changed in the scheme, and it's now broken after release.

Below SPI logic will be in upcoming OB update Air-to-Ground SPI logic principals and priority sensors: 1. Only one sensor can set SPI at the same time. For weapon TVIR (701) and onboard sensors (RDR, POD, HUD), the most recent one that enters tracking state is able to set SPI, and at the same time break lock of other sensors. If slave (SLV) mode is set in those sensors, then they will automatically slave to SPI. If snowplow (SP) mode is set, then the sensors will not be slaved, but will still break track. 2. Radar slaving behavior: If other sensor is commanding track, the radar will turn into ground stabilization state and follow the SPI constantly, even in EXP/DBS modes. 3. Two Exceptions: HUD TD Box will not be slaved to SPI, so the logic is identical to SP mode. And the ground stabilization state, a.k.a BUG state of the weapon TVIR sensor will not set SPI. 4. Sensor priority in setting SPI: The sensor that is currently in tracking state> AG radar in ground stabilization > current WPT. 5. When a sensor in SLV mode is slewed, it will be un-slaved to the current SPI and can be moved freely. A press or a second press of HOTAS S2 (unlock) can reset the sensor and make it slave to SPI again in SLV mode, or make it look forward again in SP mode. An example using radar and WMD pod: 1. When both sensors are in SLV mode, and both are in search state, SPI is set by either commanding Area/Point Track by the POD, or set a ground stabilization point or command FTT/SMTT/GMTT by the radar. 2. If the POD is currently setting SPI, switching SOI to radar and commanding ground stabilization will not move the SPI, because a tracking sensor has a higher priority than the ground stabilization state of radar. 3. Commanding FTT/SMTT/GMTT by the radar will break track of the POD, and make it slave to current SPI set by the radar. 4. Switch SOI to the POD again and commanding Area/Point Track, the SPI is set by the POD now, and the radar will break FTT/SMTT/GMTT track and enter ground stabilization state to follow the SPI. An example using radar and HUD: 1. When the radar is in SLV mode, we set a SPI by either commanding ground stabilization or FTT/SMTT/GMTT. The HUD TD Box will not be slaved to SPI due to the above SPI logic principals No.3. 2. Switch SOI to HUD and command a track on the ground, then the HUD is now setting SPI. The radar will go into ground stabilization state and follow the SPI. 3. Switch SOI back to the radar, and command ground stabilization, the SPI won’t change due to sensor priorities. 4. Commanding FTT/SMTT/GMTT by the radar will break track of the HUD, but will not make it slave to current SPI set by the radar. An example using 701 TVIR sensor, the radar and the POD: 1. All sensors are in SLV mode, and all are in search state, we set a SPI by commanding the radar to ground stabilize or FTT/SMTT/GMTT on a target. The 701 TVIR sensor and the POD will then follow the SPI. 2. We switch SOI to the POD, and command Area Track. The POD is now setting SPI, and the radar goes into ground stabilization state and follows the SPI. The 701 TVIR sensor is slaved to the new SPI set by the POD too. 3. Switch SOI to the 701 TVIR sensor, and command ground stabilize. The SPI won’t be affected due to SPI logic principals No.3. 4. Lock onto a target by the 701 TVIR sensor, and the TVIR sensor is now setting SPI. The POD will break track, and all sensors will slave to the SPI set by TVIR sensor. 5. After firing the 701 missile, the SPI is set by the radar currently because it’s in ground stabilization state and other sensors are not yet in tracking state. This also provide a means to store the SPI location locked by the last fired missile, so the next missile can look into this location right after.

should be fixed now

will check with ED

sorry, i didn't get it. can you record a video?

Trk?

Thanks a lot

Could you provide a simple trk we cannot reproduce it

There are several bugs reported (802AK LOS, bomb release sequence not match SMS selected pylons etc) Sorry that I'm quite busy with personal affairs this month, so might not have enough time to fix them. But I will try my best.

round up/down numerical error probably

manual in Doc includes such detail those filter for DL only

impact angle seems not work at this moment, only azimuth

Got it! Thanks

???

please remove all mods first and check

Yup, the official one update is still WIP. The target size is added in Chuck’s guide. You can read that first.

We will fix it.

Hi Colmillo, Please check Napillo’s comment. And Thanks, Napillo.

Hi AFAIK, there’s no laser IR.

Hi Do you have any video to show the issue please?

If you don’t mind, could you please record a video and share the ytb link?

checked manual again, SSLC=LCOS+SS so no need to change

? ant elev also determines scan zone in elevation for AG. by default, the ant elev at center of scan range or at SPI

far away from my computer, so if i understand correctly, if the bomb is very close to the target while you are just over the target, the bomb jitter and miss the target? if so, try to fly higher and see if it solves the problem. IIRC, it's due to the gimbal limitation that when pod is just over the target, the gimbal movement not smooth. We didn't have a very good solution at that very special position, but already improved it than before. will find a solution later. but at this moment, a workaround solution is to fly higher (to avoid bomb hit when aircraft just over the target), or turn as you did.