# How Lambert Guidance Is Used in the Apollo 11 Lunar Module Software

> Discover how Lambert guidance in Apollo 11 Lunar Module software calculated optimal velocity changes for orbital transfers. Explore the P-31 program and the LAMBERT subroutine.

- Repository: [Chris Garry/Apollo-11](https://github.com/chrislgarry/Apollo-11)
- Tags: deep-dive
- Published: 2026-03-04

---

**The Apollo 11 Lunar Module software uses Lambert guidance via the P-31 General Lambert Aimpoint Guidance program to compute optimal velocity changes (ΔV) for orbital transfers by solving the Lambert problem in the `LAMBERT` subroutine of `CONIC_SUBROUTINES.agc`.**

The **Lambert guidance** system in **Luminary 099**—the Apollo 11 Lunar Module flight software hosted in the chrislgarry/Apollo-11 repository—provides the computational foundation for rendezvous and descent maneuvers. This implementation solves the classic orbital mechanics problem of determining the velocity vector required to transfer between two positions in a specified time of flight, enabling precise burns for lunar landing and ascent operations.

## What Is Lambert Guidance in Apollo 11?

**Lambert guidance** refers to the mathematical solution of the Lambert problem: calculating the conic transfer orbit that connects two position vectors given a specific time of flight. In the Apollo 11 software, this technique computes the exact **ΔV** (velocity change) required to move the Lunar Module from its current state to a target location.

The guidance system operates as a **conic-subroutine** (`LAMBERT`) that higher-level mission programs invoke for trajectory planning. Rather than embedding the algorithm directly into each mission phase, the software architecture separates the Lambert solver into a reusable module within `CONIC_SUBROUTINES.agc`, allowing multiple programs to share the same orbital mechanics engine.

## How the Lambert Guidance System Works

### Input Parameters and Target Setup

Astronauts initiate Lambert guidance calculations through **Program P-31** (`GENERAL_LAMBERT_AIMPOINT_GUIDANCE.agc`), which collects three critical parameters via the DSKY interface:

- **TIG** – Time of Ignition for the maneuver
- **RTARG** – Target position vector (where the spacecraft must arrive)
- **DELLT4** – Desired time of flight between current and target positions

These values reside in erasable memory until the program validates the inputs and prepares the computation environment.

### The Lambert Subroutine Execution

The actual solution occurs in the **LAMBERT** routine within `Luminary099/CONIC_SUBROUTINES.agc` (lines 161-180). This subroutine implements an iterative algorithm that handles multiple orbital revolutions and convergence checking to determine the required velocity vector **VG**.

Mission programs such as `P34-35_P74-75.agc` (lines 1179-1182) invoke the solver using a direct assembly call:

```asm
; Prepare inputs: position vectors, time of flight, etc.
...
CALL  LAMBERT          ; conic solver returns ΔV in VG

```

The subroutine returns the solution vector to the calling program, which then scales and formats the results for display and execution.

### Flag Management and State Control

The software uses two critical flags defined in `Luminary099/FLAGWORD_ASSIGNMENTS.agc` to track the Lambert guidance state:

- **XDELVFLG** (bit 037D, line 415) – Indicates whether the ΔV originates from an external Lambert computation or an internal burn-profile calculation
- **SOLNSW** (bit 087D, line 669) – Signals whether the Lambert iteration converged successfully

Before invoking the subroutine, the program clears `XDELVFLG` to mark the computation start. Upon successful return, the flag is set to indicate that the displayed ΔV represents a Lambert-derived value rather than a simple vector addition.

## Code Implementation Details

### Setting the External-ΔV Flag

The transition between computation phases requires precise flag manipulation in `GENERAL_LAMBERT_AIMPOINT_GUIDANCE.agc`:

```asm
CAF   XDELVFLG          ; clear external-ΔV flag
...
CALL  LAMBERT          ; compute Lambert ΔV
...
CAF   XDELVFLG          ; set flag to indicate Lambert ΔV was used

```

This sequence ensures that downstream burn execution programs recognize the velocity vector as a Lambert solution requiring specific processing logic.

### Handling Convergence Status

After the `LAMBERT` call returns, the software checks the **SOLNSW** flag to verify mathematical convergence:

```asm
; After LAMBERT returns
CAF   SOLNSW            ; clear convergence flag
...
; LAMBERT sets SOLNSW = 1 if it converged, otherwise 0

```

A non-convergent solution triggers alternative guidance paths or astronaut notification, preventing execution of invalid burn parameters.

### Processing and Displaying Results

Upon successful computation, `P34-35_P74-75.agc` (lines 1231-1240) stores the velocity vector in display registers:

```asm
STCALL VGDISP          ; Store velocity for display
GET.LVC                ; Load vector components

```

The program then limits altitude values for the 4-digit DSKY format using `MAXCHK` and populates `HAPO` (apolune altitude) and `HPER` ( perilune altitude) before `BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc` consumes these values to command engine ignition timing and thrust vectors.

## Key Source Files and Architecture

The modular design of Lambert guidance spans several assembly files in the Luminary 099 source tree:

- **`GENERAL_LAMBERT_AIMPOINT_GUIDANCE.agc`** – P-31 program that orchestrates parameter input and drives the Lambert computation workflow
- **`CONIC_SUBROUTINES.agc`** – Contains the `LAMBERT` iterative solver implementing the conic transfer mathematics
- **`P34-35_P74-75.agc`** – Mission phase programs that call the Lambert subroutine for rendezvous and descent calculations
- **`P40-P47.agc`** – Additional burn programs utilizing Lambert-derived velocity vectors
- **`FLAGWORD_ASSIGNMENTS.agc`** – Defines control flags including `XDELVFLG` and `SOLNSW`
- **`MAIN.agc`** (line 34) – Master program list that includes `$LAMBERT_AIMPOINT_GUIDANCE.agc` in the build

## Summary

- **Lambert guidance** in Apollo 11 solves the orbital transfer problem to compute precise ΔV vectors for lunar maneuvers.
- The **P-31 General Lambert Aimpoint Guidance** program (`GENERAL_LAMBERT_AIMPOINT_GUIDANCE.agc`) manages astronaut inputs and coordinates computation.
- The **LAMBERT** subroutine in `CONIC_SUBROUTINES.agc` performs the iterative conic solution, handling multiple revolutions and convergence checks.
- **XDELVFLG** and **SOLNSW** flags track computation state and validity across the guidance pipeline.
- Results flow through display registers (`VGDISP`, `HAPO`, `HPER`) to the master ignition routine for burn execution.

## Frequently Asked Questions

### What is the Lambert problem in orbital mechanics?

The Lambert problem involves calculating the velocity required to travel between two points in space along a conic orbit (ellipse, parabola, or hyperbola) within a specific time of flight. In the Apollo 11 software, solving this problem enabled the Lunar Module to determine exact engine burn parameters for rendezvous with the Command Module and for descent to the lunar surface.

### Which Apollo 11 software module contains the Lambert guidance algorithm?

The core algorithm resides in `Luminary099/CONIC_SUBROUTINES.agc` within the `LAMBERT` subroutine (lines 161-180). However, the user-facing interface is **Program P-31** in `GENERAL_LAMBERT_AIMPOINT_GUIDANCE.agc`, which collects targeting parameters and invokes the computational engine.

### How does the software handle Lambert guidance convergence failures?

The **SOLNSW** flag (bit 087D in `FLAGWORD_ASSIGNMENTS.agc`) indicates convergence status. The `LAMBERT` subroutine sets this flag to 1 upon successful iteration completion. If the algorithm fails to converge, the flag remains clear, alerting the calling program to abort the maneuver or trigger backup guidance logic rather than executing an invalid burn.

### What is the difference between XDELVFLG and SOLNSW in the Lambert guidance system?

**XDELVFLG** (bit 037D) distinguishes the source of the velocity change calculation—set when the ΔV comes from the external Lambert computation versus internal profile calculations. **SOLNSW** (bit 087D) indicates the mathematical validity of the solution, signaling whether the iterative Lambert solver successfully converged on a transfer orbit.