My suspicion would have been that it assumed a zero radius
I thought about it, but I dont see why.
Wp1 calculation
- Code: Select all
# the WP 1 aim HAC entry point depends of the angle we have to fly at entry of the HAC (radius from 4.5 Nm to 2.3 Nm)
TAEM_WP_1.set_latlon(TAEM_HAC_center.lat() + m_to_lat * wp1_vec[1] * hac_radius * hac_factor_wp1, TAEM_HAC_center.lon() + m_to_lon * wp1_vec[0] * hac_radius * hac_factor_wp1);
Hac radius is 4270m and hac factor is always greater than zero
- Code: Select all
<!-- hac-radius-factor-wp1 for TAEMguidance.nas Waypoint 1 distance from HAC center depending on Turn degree at entry// independant of MEP/NEP -->
<fcs_function name="systems/ap/taem/hac-radius-factor-wp1">
<function>
<table>
<independentVar lookup="row">systems/taem-guidance/turn-hac-degrees</independentVar>
<tableData>
90 1.0
180 1.21
270 1.52
359 1.87
</tableData>
</table>
</function>
</fcs_function>
It used to be computed at transition to TAEM phase
Yes, it is still the case, handled by stages.nas
- Code: Select all
#Distance/Mach trigger for TAEM (OPS3) // Entry traj 5 boundaries
if (((d_remain < 60.0) or (mach < 2.5)) and (deorbit_stage_flag == 3))
{
SpaceShuttle.compute_TAEM_guidance_targets();
glide_loop();
can you remind me why we have to reload the target manually?
I observed that sometimes ( actually for Large HACs and long distances), the waypoint1 calculation was slighty off when the Shuttle was still manoeuvring and acquiring the correct course towards the landing site.
To reload the TAEM target with item 41/3/4/6/7 in those case updates well the WP1 position and the course to it.
I dont remember if I observed that before, I will check on the stable version in same HAC conditions to see if it is new.