LunaNet Gateways
Listen up. As your Lead Systems Engineer, I need you to understand that the LunaNet Signal-In-Space Augmented Forward Signal (LSIS-AFS) Reference Implementation is not a typical web stack, this is a pure digital signal processing (DSP) pipeline. To build a system that can reliably transmit and receive navigation data from the Moon, we are executing this project using a strict "Gateway-based approach".
There are 9 gateways total (numbered 0 through 8), designed to enforce incremental validation so we catch complex DSP errors early. Here is the architectural logic, the pitfalls to watch out for, and the actionable execution plan for each gateway.
Gateway 0: Design & Architecture
- Focus: Designing the system architecture and establishing our cross-platform development foundation.
- Architectural Logic: This is your API design phase. You are defining the I/O interfaces between modular DSP blocks so that our transmitters and receivers can talk to each other seamlessly.
- Technical Skepticism: Do not over-engineer hardware dependencies. A common pitfall here is tightly coupling code to specific RF receiver hardware, which is strictly out of scope.
- Actionable Steps:
- Task: Set up version control (Git) and select open-source math libraries.
- Implementation: Draft the system architecture document and component interaction diagrams.
- Validation: Ensure the testing framework is established and the team is aligned.
- Compliance: The tech stack shall process specified data formats (Binary I/Q, CSV, JSON) and support standard open-source build tools.
Gateway 1: Spreading Code Generation
- Focus: Generating all spreading codes (Gold, Weil, Secondary) for PRN 1–210.
- Architectural Logic: These pseudo-random noise (PRN) sequences are the mathematical root of our Code Division Multiple Access (CDMA) signal. They allow the receiver to isolate our specific spacecraft's signal from the background noise of space.
- Technical Skepticism: Shift-register implementations are notorious for off-by-one errors. Pay strict attention to your polynomial generator seeds.
- Actionable Steps:
- Task: Build the sequence generators.
- Implementation: Code the 2046-chip Gold codes, 10230-chip Weil primary codes, and 1500-chip Weil tertiary codes.
- Validation: Match your output exactly to the reference hexadecimal values in Annex 3.
- Compliance: The system shall generate all spreading codes for PRN 1-210 in under 1 second per PRN.
Gateway 2: Forward Error Correction (FEC)
- Focus: Implementing BCH, LDPC, and CRC-24 encoders and decoders.
- Architectural Logic: FEC is what protects our navigation payload from the high bit-error rates of a 400,000 km cislunar RF link.
- Technical Skepticism: LDPC (Low-Density Parity-Check) decoding is computationally massive. A naive implementation will destroy our real-time performance budget. Watch your bit-endianness when calculating the CRC-24 checksums.
- Actionable Steps:
- Task: Build the error detector and correction algorithms.
- Implementation: Write the BCH, LDPC, and CRC-24 logic.
- Validation: Pass all provided test vectors with zero errors.
- Compliance: The implementation shall accurately encode and decode using BCH, LDPC, and CRC-24 protocols.
Gateway 3: Navigation Message Framing
- Focus: Building complete 12-second navigation frames.
- Architectural Logic: Here we pack our FEC-encoded data (like ephemeris, time of week, and maneuver alerts) into a continuous, structured digital stream.
- Technical Skepticism: Misaligning your payload fields by a single bit will corrupt the entire 12-second frame.
- Actionable Steps:
- Task: Construct the frame assembly system.
- Implementation: Multiplex the data channels and pilot channels into the correct frame structure.
- Validation: Generate mathematically valid 12-second frames.
- Compliance: The system shall format all messages according to the LSIS-AFS Volume A specification.
Gateway 4: Baseband Signal Generation
- Focus: Generating complex numerical I/Q baseband samples using BPSK modulation.
- Architectural Logic: This gateway converts your digital binary frames into a mathematical representation of radio waves, allowing us to simulate the physical transmission.
- Technical Skepticism: Floating-point precision loss is a massive risk here when generating I/Q samples. You must strictly control your sample rates and ensure the S-band carrier phase remains continuous.
- Actionable Steps:
- Task: BPSK Modulator implementation.
- Implementation: Apply the spreading codes from GW1 to the frames from GW3 to generate the baseband output.
- Validation: Produce binary I/Q signal files ready for receiver testing.
- Compliance: The system shall output properly structured baseband files representing the dual-channel BPSK signal.
Gateway 5: Frame Sync & Decoding
- Focus: Detecting and decoding frames from received signals.
- Architectural Logic: We are now transitioning to the "Receiver" side. You are building the logic to hunt for the AFS signal in the noise, lock onto it, and strip away the modulation to recover the raw bits.
- Technical Skepticism: Signal correlation peaks can easily be buried in the noise floor. Beware of phase ambiguities when demodulating BPSK, which can invert your entire data stream.
- Actionable Steps:
- Task: Build the acquisition and tracking loops.
- Implementation: Ingest the I/Q files from GW4 and establish frame synchronization.
- Validation: Successfully detect frames from clean baseline signals.
- Compliance: The receiver shall correctly synchronize with the 12-second frame boundaries.
Gateway 6: Message Parsing
- Focus: Extracting the raw navigation data from the decoded frames.
- Architectural Logic: This translates the raw, error-corrected bits back into usable telemetry data (like satellite attitude, clock data, and orbital parameters) for the end-user.
- Technical Skepticism: If your frame sync in GW5 was loose, your parser will pull garbage data. Validate your bit-masks rigorously.
- Actionable Steps:
- Task: Build message field extractors.
- Implementation: Parse subframes and extract values like the Time of Transmission.
- Validation: Accurately pull all navigation data from the frame.
- Compliance: The parser shall successfully extract standard LunaNet messages, such as MSG-G10 (Maneuver) and MSG-G11 (Ephemeris).
Gateway 7: Integration & Validation
- Focus: End-to-end functionality, interoperability, and compliance.
- Architectural Logic: This is the ultimate test of our DSP chain. We feed data into GW2, transmit it in GW4, and catch it in GW5 to ensure the pipeline operates seamlessly.
- Technical Skepticism: Latency bottlenecks hidden in your LDPC decoder or code generator will surface here and crash the system during real-time processing limits.
- Actionable Steps:
- Task: Execute full round-trip tests (encode → signal → decode → verify).
- Implementation: Run interoperability tests with other implementations and track Bit Error Rate (BER) vs SNR performance curves.
- Validation: Prove 100% round-trip data recovery accuracy.
- Compliance: The software shall process a full 12-second frame in under 1 second, and pass all LSIS compliance checks.
Gateway 8: Documentation & Examples
- Focus: Complete documentation for using and understanding the implementation.
- Architectural Logic: LunaNet is an open, international standard. Our code will be the foundation for future ESA and NASA engineers; it must be highly readable and strictly reproducible.
- Technical Skepticism: Do not let documentation rot. Ensure your API docs match the final refactored code exactly, otherwise, the next team will fail their integration tests.
- Actionable Steps:
- Task: Create user guides, API docs, and performance reports.
- Implementation: Build tutorial notebooks and clear setup instructions.
- Validation: Ensure a third-party developer can execute reproducible builds and run the test vector suite using just your README.
- Compliance: The repository shall include public API documentation and working usage examples for all components.