Wiznet makers

Summary

The WB-AV-4500-FC is a real-time rocket flight computer designed to collect sensor, IMU, and GPS data during flight while maintaining a reliable ground interface. By using a WIZnet Ethernet controller as a dedicated communication layer, the system cleanly separates flight-critical logic from networking tasks, ensuring predictable latency, high reliability, and safe operation throughout all flight phases.

Project Overview

WB-AV-4500-FC is a rocket avionics flight computer developed for the Whistler-Blackcomb rocket program. The board serves as the central control unit responsible for telemetry, apogee detection, state management, and coordination with multiple data acquisition subsystems.

From a system architecture perspective, this project is notable for treating Ethernet not as a convenience interface, but as a core ground communication axis. A WIZnet Ethernet controller is integrated directly on the main PCB and connected to the MCU via SPI, providing hardware TCP/IP offloading and deterministic network behavior. This design allows the flight computer to maintain a stable and testable communication path with the ground system without compromising real-time flight logic.

Why WIZnet Ethernet Is a Structural Requirement

In WB-AV-4500-FC, the use of WIZnet Ethernet is not an optional design choice—it is a structural necessity driven by real-time avionics constraints.

1. Real-Time Flight Requirements

A rocket flight computer must execute multiple time-critical functions concurrently:

High-rate sensor and IMU sampling

State machine evaluation for flight phase transitions

Data logging and safety checks

Communication with external systems

If network protocol processing were handled entirely inside the MCU, TCP/IP stack execution could introduce unpredictable timing jitter. Even small variations in task execution time can degrade the reliability of state transitions or sensor fusion during powered ascent.

By offloading TCP/UDP processing to a WIZnet Ethernet controller, WB-AV-4500-FC ensures that network traffic does not interfere with real-time flight tasks. The MCU remains focused on flight logic, while Ethernet communication runs as an isolated hardware function.

2. Identical Communication Path from Ground Test to Flight

WB-AV-4500-FC is designed so that the same Ethernet interface is used during:

Bench testing

Integration testing

Launch preparation

Post-flight data access

Instead of relying on temporary USB or UART connections during development, the system uses a production-equivalent wired Ethernet path from the beginning. This eliminates discrepancies between test and flight environments and significantly reduces integration risk.

The WIZnet Ethernet interface supports UDP-based telemetry, configuration queries, and diagnostic access, making it ideal for rapid ground interaction without modifying flight firmware.

3. Clear Role Separation with Radio Systems

The board architecture deliberately separates communication responsibilities:

Radio: long-range telemetry during flight

Ethernet (WIZnet): high-speed wired access before launch, after recovery, and during debugging

This dual-path design avoids overloading a single communication channel and improves system resilience. Ethernet provides reliable, high-bandwidth access when physical connectivity is available, while radio handles in-flight communication.

Firmware-Level Behavior (Conceptual Overview)

Although this repository primarily contains hardware design files, the associated flight software architecture is well defined and aligns tightly with the hardware design.

At a high level, the firmware is built around an RTOS-based multitasking structure combined with a deterministic state machine.

Text-Based Functional Block Diagram

In this structure:

The MCU executes all flight-critical logic.

The WIZnet Ethernet controller operates as an independent communication engine.

Network traffic never directly blocks or delays flight decision-making.

State Machine-Centered Flight Logic

The flight computer uses a state machine to manage all phases of flight. State transitions are explicit and constrained, ensuring that unexpected inputs cannot cause unsafe behavior.

Representative Flight States

Key architectural characteristics:

All state transitions are mediated through a centralized state transition structure.

External inputs (ground commands, sensor thresholds, radio messages) converge into controlled transition signals.

Communication latency does not directly influence state decisions.

Because Ethernet communication is hardware-offloaded, even heavy ground traffic during testing cannot destabilize the state machine.

Hardware Architecture: WB-AV-4500-FC PCB Perspective

WB-AV-4500-FC integrates all major avionics subsystems onto a single flight-rated PCB.

Major Hardware Blocks

MCU Block
Responsible for flight control, RTOS task scheduling, and state machine execution.

WIZnet Ethernet Block

SPI-connected to the MCU

Integrated hardware TCP/IP stack

Handles socket management and packet processing

Provides wired ground communication

IMU Block

High-precision inertial measurement unit (STIM300-class)

UART-based data interface

CAN Interface

Connects multiple pressure and temperature sensor boards

Enables distributed sensor architecture

Radio Block

Long-range telemetry during flight

Power and Protection Circuits

Designed for vibration, noise, and transient resilience

Ensures stable operation in harsh launch environments

In this design, Ethernet is not a secondary debug port. It is treated as one of the primary system interfaces connecting the flight computer directly to ground infrastructure.

WIZnet Ethernet Integration Model

From a system design standpoint, the WIZnet Ethernet controller functions as a standalone network processor.

The MCU generates application-level data (telemetry, status, configuration).

The WIZnet chip manages packet framing, TCP/UDP handling, and socket state.

Communication failures do not cascade into flight logic failures.

This isolation is critical in safety-sensitive embedded systems, where fault containment is as important as raw performance.

Key Takeaway for System Designers

WB-AV-4500-FC demonstrates how Ethernet can be safely and effectively integrated into a real-time rocket flight computer when implemented correctly.

By using a WIZnet Ethernet controller:

Real-time flight logic and networking are cleanly separated.

Deterministic behavior is preserved even under heavy ground communication.

Development, testing, and flight environments share a consistent interface.

System complexity and risk are reduced at the architectural level.

This project is a strong reference design for engineers evaluating Ethernet-based ground interfaces in high-reliability embedded systems.

FAQ

Q: Why is WIZnet Ethernet suitable for a rocket flight computer?
A: WIZnet Ethernet provides hardware TCP/IP offloading, allowing network communication to run independently from the MCU. This prevents network processing from introducing timing jitter or blocking behavior in real-time flight control tasks.

Q: What role does Ethernet play compared to radio communication?
A: Ethernet is used for high-speed, reliable wired communication during ground testing, configuration, and post-flight analysis, while radio handles long-range telemetry during flight. Each interface has a clearly defined role.

Q: How does this design improve system reliability?
A: By isolating communication processing in dedicated hardware, failures or delays in networking cannot directly disrupt the flight state machine or sensor processing logic.

Q: Is Ethernet used only for debugging in this project?
A: No. Ethernet is a core system interface used throughout the lifecycle of the vehicle, from bench testing to launch preparation and recovery.

Q: Can this architecture scale to other real-time systems?
A: Yes. The same separation-of-concerns principle applies to industrial control, robotics, and other safety-critical embedded systems that require deterministic behavior and reliable networking.


요약 (Summary)

WB-AV-4500-FC는 로켓 비행 중 센서, IMU, GPS 데이터를 실시간으로 수집하면서 안정적인 지상 인터페이스를 유지하도록 설계된 Flight Computer이다. 이 시스템은 WIZnet Ethernet 컨트롤러를 전용 통신 계층으로 사용함으로써, 비행에 중요한 로직과 네트워크 처리를 명확히 분리하고 예측 가능한 지연 시간과 높은 신뢰성을 모든 비행 단계에서 확보한다.

프로젝트 개요 (Project Overview)

WB-AV-4500-FC는 Whistler-Blackcomb 로켓 프로그램을 위해 개발된 항공전자(Avionics)용 Flight Computer이다. 이 보드는 텔레메트리 처리, Apogee 감지, 비행 상태 관리, 그리고 다수의 데이터 수집 서브시스템과의 연계를 담당하는 중앙 제어 장치 역할을 수행한다.

시스템 아키텍처 관점에서 이 프로젝트의 가장 큰 특징은, Ethernet을 단순한 편의 인터페이스가 아닌 **지상 통신을 위한 핵심 축(core axis)**으로 취급한다는 점이다. WIZnet Ethernet 컨트롤러는 메인 PCB에 직접 통합되어 MCU와 SPI로 연결되며, 하드웨어 TCP/IP 오프로딩과 결정론적 네트워크 동작을 제공한다. 이 설계를 통해 Flight Computer는 실시간 비행 로직을 훼손하지 않으면서도, 지상 시스템과의 안정적이고 반복 가능한 통신 경로를 유지할 수 있다.

왜 WIZnet Ethernet인가 (Why WIZnet Ethernet Is a Structural Requirement)

WB-AV-4500-FC에서 WIZnet Ethernet의 사용은 선택 사항이 아니라, 실시간 항공전자 시스템의 제약 조건에서 도출된 구조적 필연성이다.

1. 실시간 비행 요구 사항

로켓 Flight Computer는 다음과 같은 시간 민감 작업을 동시에 수행해야 한다.

고속 센서 및 IMU 데이터 샘플링

비행 단계 전이를 위한 상태 머신 평가

로깅 및 안전성 점검

외부 시스템과의 통신

만약 TCP/IP 프로토콜 처리를 MCU 내부에서 모두 수행한다면, 네트워크 스택 실행으로 인해 예측 불가능한 타이밍 지터가 발생할 수 있다. 이러한 미세한 지연 변화조차도 추진 비행 구간에서의 상태 판단이나 센서 융합 정확도를 저하시킬 수 있다.

WB-AV-4500-FC는 WIZnet Ethernet 컨트롤러를 사용해 TCP/UDP 처리를 하드웨어로 오프로딩함으로써, 네트워크 트래픽이 실시간 비행 태스크에 간섭하지 않도록 설계되었다. MCU는 비행 로직에만 집중하고, Ethernet 통신은 독립적인 하드웨어 기능으로 분리된다.

2. 지상 테스트부터 실비행까지 동일한 통신 경로

WB-AV-4500-FC는 다음 모든 단계에서 동일한 Ethernet 인터페이스를 사용하도록 설계되었다.

벤치 테스트

통합 시험

발사 준비 과정

비행 후 데이터 접근

개발 단계에서 임시 USB나 UART 연결에 의존하는 대신, 실제 운용 환경과 동일한 유선 Ethernet 경로를 처음부터 사용한다. 이를 통해 테스트 환경과 실비행 환경 간의 차이를 제거하고, 시스템 통합 리스크를 크게 줄일 수 있다.

WIZnet Ethernet 인터페이스는 UDP 기반 텔레메트리, 설정 질의, 진단 접근을 지원하여, 비행 펌웨어를 변경하지 않고도 빠른 지상 상호작용이 가능하다.

3. Radio 시스템과의 명확한 역할 분담

보드 아키텍처는 통신 역할을 명확히 분리한다.

Radio: 비행 중 장거리 텔레메트리

Ethernet (WIZnet): 발사 전·후 고속 유선 접근, 디버깅 및 설정

이 이중 통신 구조는 단일 채널에 대한 의존도를 낮추고 시스템 복원력을 향상시킨다. 물리적 연결이 가능한 구간에서는 Ethernet이 신뢰성과 대역폭을 제공하고, 비행 중에는 Radio가 통신을 담당한다.

펌웨어 동작 개요 (Firmware-Level Behavior)

이 GitHub 리포지토리는 주로 하드웨어 설계 파일을 포함하고 있지만, 연계된 Flight Software의 구조는 하드웨어 설계와 긴밀하게 맞물려 있다.

펌웨어는 RTOS 기반 병렬 태스크 구조와 결정론적 상태 머신을 중심으로 구성된다.
 

상태 머신 중심 비행 로직 (State Machine-Centered Flight Logic)

Flight Computer는 비행 전 과정을 상태 머신으로 관리한다. 모든 상태 전이는 명시적으로 제한되어 있으며, 예기치 않은 입력으로 인해 위험한 동작이 발생하지 않도록 설계되어 있다.

아키텍처적 핵심 특징은 다음과 같다.

모든 상태 전이는 중앙화된 전이 구조를 통해서만 발생

지상 명령, 센서 조건, 통신 이벤트는 통제된 입력으로 수렴

통신 지연이 상태 판단 로직에 직접적인 영향을 주지 않음

Ethernet 통신이 하드웨어 오프로딩되어 있기 때문에, 지상 테스트 중 통신 부하가 크더라도 상태 머신의 안정성은 유지된다.

하드웨어 아키텍처 (WB-AV-4500-FC PCB 관점)

WB-AV-4500-FC는 주요 항공전자 서브시스템을 단일 비행용 PCB에 통합한다.

주요 하드웨어 블록

MCU 블록
비행 제어, RTOS 태스크 스케줄링, 상태 머신 실행 담당

WIZnet Ethernet 블록

MCU와 SPI로 연결

하드웨어 TCP/IP 스택 내장

소켓 관리 및 패킷 처리 담당

지상 시스템과의 유선 통신 제공

IMU 블록

STIM300 계열 고정밀 IMU

UART 기반 데이터 인터페이스

CAN 인터페이스

다수의 압력·온도 센서 보드 연결

분산 센서 네트워크 구성

Radio 블록

비행 중 장거리 텔레메트리 담당

전원 및 보호 회로

진동, 노이즈, 트랜지언트 환경 대응

발사 환경에서도 안정적 동작 보장

이 설계에서 Ethernet은 단순한 디버그 포트가 아니라, Flight Computer와 지상 시스템을 직접 연결하는 주요 시스템 인터페이스 중 하나이다.

WIZnet Ethernet 적용 모델 (Integration Model)

시스템 설계 관점에서 WIZnet Ethernet 컨트롤러는 독립적인 네트워크 프로세서로 동작한다.

MCU는 애플리케이션 레벨 데이터 생성 담당

WIZnet 칩은 패킷 처리, TCP/UDP, 소켓 상태 관리 담당

통신 장애가 비행 로직 전체로 전파되지 않음

이와 같은 격리 구조는 안전이 중요한 임베디드 시스템에서 매우 중요한 설계 원칙이다.

시스템 설계자를 위한 핵심 시사점 (Key Takeaway)

WB-AV-4500-FC는 Ethernet을 올바르게 사용했을 때, 실시간 로켓 Flight Computer에 어떻게 안전하게 통합될 수 있는지를 보여주는 사례이다.

WIZnet Ethernet을 사용함으로써:

실시간 비행 로직과 네트워크 처리가 명확히 분리되고

높은 통신 부하 상황에서도 결정론적 동작이 유지되며

개발·테스트·실비행 환경이 동일한 인터페이스를 공유하고

시스템 복잡도와 리스크가 아키텍처 차원에서 감소한다

이 프로젝트는 고신뢰 임베디드 시스템에서 Ethernet 기반 지상 인터페이스를 검토하는 엔지니어에게 강력한 레퍼런스 설계 사례가 된다.

FAQ

Q: 로켓 Flight Computer에 WIZnet Ethernet이 적합한 이유는 무엇인가요?
A: WIZnet Ethernet은 하드웨어 TCP/IP 오프로딩을 제공하여, 네트워크 처리가 MCU의 실시간 비행 제어 태스크에 지터나 블로킹을 유발하지 않도록 합니다.

Q: Ethernet과 Radio는 어떤 역할 차이가 있나요?
A: Ethernet은 지상 테스트, 설정, 비행 후 분석을 위한 고속 유선 통신을 담당하고, Radio는 비행 중 장거리 텔레메트리를 담당합니다.

Q: 이 설계가 시스템 신뢰성을 어떻게 향상시키나요?
A: 통신 처리를 전용 하드웨어로 분리함으로써, 네트워크 지연이나 오류가 상태 머신이나 센서 처리 로직에 직접 영향을 주지 않습니다.

Q: 이 프로젝트에서 Ethernet은 디버깅용 인터페이스인가요?
A: 아닙니다. Ethernet은 개발부터 발사 준비, 회수 이후까지 전 주기에 사용되는 핵심 시스템 인터페이스입니다.

Q: 이 아키텍처는 다른 실시간 시스템에도 적용 가능한가요?
A: 가능합니다. 동일한 분리 원칙은 산업 제어, 로보틱스, 안전 필수 임베디드 시스템에도 그대로 적용할 수 있습니다.