Can an Open Network Protocol Fix Live Audio Control? Proteus, Virgil and W5500

📌 오디오 전송 다음의 문제, “장비 제어”

Proteus는 live-sound 환경을 위한 모듈형 컨트롤러 플랫폼입니다.

프로젝트의 목적은 단순한 MIDI controller를 만드는 것이 아니라, 개발자가 별도로 설계하고 있는 Virgil protocol을 실제 hardware에서 개발하고 검증하기 위한 prototype을 만드는 데 있습니다. README는 Behringer X-Touch 같은 MIDI controller에 비유하면서, 완전한 오픈소스·모듈형이고 MIDI를 쓰지 않는다는 점이 다르다고 설명합니다.

Virgil은 Dante 기반 audio system에서 gain, phantom power, channel state 같은 audio device control information을 서로 교환하기 위한 companion protocol을 목표로 합니다. Dante는 오디오 전송만 다루고 제어 packet을 담지 못해서, 오디오 회사마다 독자 제어 protocol을 만들어 왔다는 것이 저자가 짚는 공백입니다.

별도의 Virgil repository에서는 현재 protocol을 TCP 위의 JSON message로 정의하고 있으며, controller discovery에는 mDNS를 사용합니다.

따라서 전체 개념은 다음과 같이 볼 수 있습니다.

Audio Transport → Dante
Device Control → Virgil
Hardware Prototype → Proteus

🧩 16개의 Module Slot을 가진 Controller

Proteus는 고정된 하나의 control surface가 아니라 module을 바꿔 사용할 수 있는 구조입니다. Controller에는 총 16개의 module slot이 있고, 전기적으로 슬롯은 동일하며 길이만 다릅니다.

Speculum

1.14-inch TFT display와 NeoPixel push button, NeoPixel continuous encoder를 포함하는 사용자 interface module입니다.

Cursor

B103 motorized fader를 사용하는 motor fader module입니다.

각 module은 RP2040 또는 RP2350 계열 MCU를 사용해야 하며 Motherboard와는 SPI로 통신합니다. README에는 버튼 module인 Ordo도 이름이 올라 있습니다. 즉 하나의 중앙 MCU가 모든 fader와 display GPIO를 직접 제어하는 구조가 아니라:

Motherboard → SPI Backplane → Intelligent Modules

형태에 가깝습니다.

🧠 Motherboard: RP2350 + W5500 + Wireless

Proteus의 중심은 RP2350 기반 Motherboard입니다.

여기서 WIZnet 관점에서 가장 중요한 부분이 W5500입니다. 회로도 Networking.kicad_sch에는 W5500(LQFP-48), 25 MHz 크리스털, Neutrik NE8FAH EtherCON 잭, PT61018PEL 마그네틱스, LINK·DUP·ACT LED가 있고, PCB에는 W5500_~{CS}, W5500_~{INT}, W5500_~{RESET} net이 있습니다.

Proteus.h의 board definition에서는 W5500용 pin이 명확하게 분리되어 있습니다.

// Networking SPI
#define PICO_DEFAULT_SPI             spi0
#define PICO_DEFAULT_SPI_RX_PIN      0   // NET_MISO
#define PICO_DEFAULT_SPI_TX_PIN      3   // NET_MOSI
#define PICO_DEFAULT_SPI_SCK_PIN     2   // NET_CLK
 #define W5500_CS_PIN                 45
#define W5500_INT_PIN                46
#define W5500_RST_PIN                47

Network SPI(spi0)와 W5500 CS, INT, RESET line은 firmware의 GPIO setup 과정에서 초기화됩니다. module 쪽은 별도의 spi1을 쓰므로 이더넷 traffic이 fader·display와 bus를 공유하지 않습니다. 무선 module도 자체 CS(GPIO 42), 인터럽트(43), 인에이블(44)을 가져 두 network path는 서로 독립적입니다.

즉 W5500은 단순히 future option으로 schematic에만 존재하는 것이 아니라 Motherboard hardware architecture와 firmware pin definition에 이미 포함되어 있습니다.

🌐 W5500은 Virgil의 Wired Network Path를 위한 Hardware

Virgil protocol은 TCP connection을 이용하도록 정의되어 있습니다. Message는 UTF-8 JSON 형태이며, 각 message 앞에는 payload length를 나타내는 4-byte unsigned big-endian value를 둡니다. 예를 들어 Virgil에서는 다음과 같은 message type을 정의합니다.

이 구조가 Proteus에서 구현될 경우 wired network path는 다음과 같은 형태가 될 수 있습니다.

Proteus UI Modules → RP2350 Motherboard → Virgil Application → TCP → W5500 Ethernet → EtherCON / Network

W5500의 Hardwired TCP/IP socket architecture는 이런 embedded TCP control endpoint를 구성하기에 자연스러운 hardware 구조입니다. 저자가 이유를 설명한 것은 아니므로 아래는 우리의 해석입니다.

• RP2350에는 이더넷 MAC이 없어 유선 네트워크에는 외부 컨트롤러가 필요하고, W5500은 SPI로 MAC/PHY와 TCP/IP 스택을 함께 맡아 줍니다.
• 컨트롤 서피스는 여러 장치와 오래 유지되는 TCP 연결을 갖습니다. 향후 W5500의 hardware socket을 사용한다면 TCP/IP 처리를 W5500에 맡길 수 있습니다. 다만 현재 repository에서는 해당 software architecture가 아직 정의되지 않았습니다
• W5500 INT가 GPIO46에 연결되어 있어 firmware에서 지속적인 polling 대신 interrupt 기반으로 network event를 처리할 수 있습니다.

다만 여기서 중요한 부분이 있습니다.

현재 공개된 Proteus firmware에서는 Virgil-over-W5500 TCP implementation까지는 확인되지 않습니다.

현재 code에서는 network SPI 및 W5500 control pin 설정이 확인되지만 TCP socket 또는 Virgil message processing 단계는 아직 구현 중인 것으로 보는 것이 정확합니다. 또 저장소는 하드웨어 socket을 쓸지, MACRAW + lwIP로 갈지도 정하지 않았습니다. (아래 관련 프로젝트에서 두 방식의 사례를 비교합니다.)

🎚️ Virgil은 무엇을 제어하려 하는가?

Virgil은 단순한 button command protocol보다 범위가 넓습니다. 현재 protocol에는 audio equipment에서 필요한 여러 parameter가 정의되어 있습니다.

Gain / Phantom Power / Pad / Polarity / Low-cut / RF Level / Audio Level / Battery State

등입니다. 또 Dante의 TX/RX channel에 대응되는 channel model과 별도로 aux channel 개념도 두고 있습니다. 이를 이용하면 Proteus와 같은 control surface가 향후 여러 audio device의 parameter를 하나의 interface에서 조작하는 구조를 목표로 할 수 있습니다.

🔌 Backplane: 16개 Module을 어떻게 연결할까?

Proteus Backplane은 16개의 module slot과 Motherboard 사이를 연결합니다. 핵심 구성은 SPI + Power + Reset + Detect + SWD입니다. 그 외에 GPIO 1개가 SPI interrupt용으로 컨트롤러에 직결되어 있지만, 확장성을 위해 이후 버전에서 제거될 가능성이 크다고 README가 적고 있습니다.

16개의 module chip-select를 만들기 위해 CD74HC154M96 demultiplexer가 컨트롤러의 CS mux 4선을 16선으로 나누고, module reset/detect에는 MCP23017T I/O expander 2개가 사용됩니다.

특히 재미있는 부분은 SWD입니다. 각 module의 SWD line을 switch할 수 있도록 module마다 SN74CBTLV1G125 buffer를 두고 CS line을 제어 신호로 써서, Motherboard에서 각 module MCU를 자동으로 program할 수 있는 구조까지 고려하고 있습니다. module 교체뿐 아니라 firmware management까지 중앙 controller에서 처리하려는 architecture입니다.

⚡ PoE까지 고려한 Power Architecture

Proteus는 power board도 Motherboard에서 분리하고 절연했습니다. 나중에 배터리 옵션을 넣고 싶지만 아직 BMS는 다루고 싶지 않다는 이유입니다.

현재 prototype power board는 PoE + 12 V barrel input을 대상으로 하며 3.3 V, 5 V와 motorized fader용 motor voltage(약 9–12 V, 정확한 전류는 테스트 후 결정)를 공급합니다. 이 보드는 자체 RP2350과 모든 레일의 전류·전압 센싱, 모터 레일의 smart power fuse, 전압 조정용 digital potentiometer도 갖고 있습니다.

Motherboard와 Power board 사이에는 PoE 및 USB-C PD(CC line 포함) 관련 signal이 전달됩니다. 이 역시 아직 최종 production power design이라기보다는 future battery / PoE / different power module을 고려한 modular architecture라고 보는 것이 좋습니다. 전원을 넣어 본 테스트 결과는 저장소에 보고되어 있지 않습니다.

📡 Wired + Wireless를 모두 고려

Motherboard에는 W5500뿐 아니라 Raspberry Pi Radio Module 2도 존재합니다.

W5500 → Wired Ethernet
Radio Module 2 → Wireless

두 network path가 모두 고려되어 있습니다. 하지만 현재 repository에서 automatic failover나 simultaneous hybrid networking 같은 동작까지 구현되었다는 근거는 확인되지 않습니다. 따라서 Maker 글에서는:

The motherboard includes both wired W5500 Ethernet and a wireless radio option.

정도로 표현하는 것이 안전합니다.

⚠️ 현재 프로젝트 상태

Proteus는 현재 완성된 commercial audio controller라기보다 개발 중인 hardware/protocol prototype에 가깝습니다. README도 스스로 hardware prototype이라고 부릅니다.

PCB(KiCad), enclosure STEP, 렌더링, BOM, Motherboard pin architecture 등은 상당히 구체적으로 공개되어 있지만, Code/Motherboard/Motherboard.cpp는 50줄짜리 Pico 예제 template(1 MHz SPI, I2C, "Hello, world!" 루프)이고 build는 hardware_spi, hardware_i2c, hardware_pio와 SD library만 link합니다. W5500 driver나 ioLibrary, Virgil 구현은 이 저장소에 없습니다. Virgil protocol repository에도 참조 firmware는 없습니다.

따라서 다음은 구분해서 봐야 합니다.

이 점을 명확하게 설명하면 오히려 프로젝트 성격이 더 잘 드러납니다. Proteus는 완제품 사례보다는 W5500이 포함된 차세대 modular audio-control platform을 어떻게 설계하고 있는지를 볼 수 있는 development project입니다. 개인 한 사람이 관리하는 프로젝트라는 점도 감안해야 합니다.

🔗 비슷한 WIZnet Maker 프로젝트와 비교

Proteus와 정확히 같은 Virgil/Dante controller는 아니지만, RP2040/RP2350 계열 + W5500을 이용해 real-time media/control network를 구성한 Maker 프로젝트들과 비교하면 특징이 더 잘 보입니다. 특히 각 프로젝트가 W5500을 어떻게 쓰는지(하드웨어 TCP/UDP vs MACRAW + lwIP)에 주목해 볼 만합니다.

Network MIDI 2.0 Bridge

Maker Project 보기

이 프로젝트 역시 RP2040과 W5500을 이용해 음악 관련 network protocol을 처리합니다. 특이하게 W5500의 TCP/UDP hardware socket을 그대로 사용하는 대신 MACRAW → lwIP → UDP → Network MIDI 2.0 구조를 사용하며, 페이지는 W5500을 "Ethernet MAC/PHY-facing hardware interface and frame buffer"로 쓴다고 설명합니다.

Proteus는 MIDI transport가 아니라 live-audio equipment parameter control을 목표로 한다는 점이 가장 큰 차이입니다. Proteus가 어느 방식을 택할지는 아직 열려 있습니다.

Core-Micro

Maker Project 보기

Core-Micro는 RP2040 + W5500 기반의 공연 조명 controller로 Art-Net, DMX, physical fader/encoder 등을 하나의 device에 통합하려는 프로젝트입니다. 다만 페이지는 fader 5개와 encoder 2개가 "계획" 단계이고 firmware도 DMX·Art-Net 검증용 최소 구현이라고 밝힙니다. Logic/Surface/DMX/Power 4개 board로 나눈 modular 하드웨어라는 점도 Proteus와 닮았습니다.

Physical control surface + W5500이라는 점은 Proteus와 매우 유사합니다. 하지만:

Core-Micro → Lighting / Art-Net / DMX
Proteus → Live Audio / Virgil / Dante companion control

이라는 차이가 있습니다.

SqueezeAMP PoE

Maker Project 보기

SqueezeAMP PoE는 ESP32와 W5500, PoE++(IEEE 802.3bt, 최대 60 W)를 이용한 network audio amplifier입니다. 하나의 Ethernet cable을 통해 network와 power를 함께 공급합니다. 페이지는 TCP/IP를 W5500 offload가 아니라 ESP32의 lwIP로 처리한다고 밝힙니다.

Proteus 역시 Ethernet과 PoE를 고려하지만 역할이 다릅니다.

SqueezeAMP → Audio Endpoint
Proteus → Audio Control Surface

라고 볼 수 있습니다.

3D Joystick Controller

Maker Project 보기

ESP32와 W5500으로 조이스틱 입력을 읽어 OSC 메시지로 유선 이더넷에 전송하는 컨트롤러입니다. 입력 → 네트워크 메시지 → 외부 장치라는 흐름은 Proteus의 control surface 역할과 가장 가깝지만, 이쪽은 실제로 동작하는 firmware가 있고 기성 W5500 board를 씁니다. Proteus는 W5500을 커스텀 Motherboard에 직접 배치한 설계라는 점이 다릅니다.

w5500_mesaxyz

Maker Project 보기

Pico W에 W5500을 연결해 Wi-Fi와 별도로 wired Ethernet을 추가하는 기본 RP2040 networking project로, WIZnet의 ioLibrary_Driver를 씁니다. Proteus 역시 wireless module과 W5500을 한 Motherboard에서 고려하지만, 단순 connectivity demonstration이 아니라 modular live-sound controller라는 application 목적이 분명하다는 점이 다릅니다.

❓ FAQ

Q. Proteus에서 W5500이 실제로 사용되나요?
Motherboard hardware(회로도·PCB)와 firmware pin definition에 W5500이 포함되어 있습니다. 다만 현재 공개 firmware에서는 실제 TCP/Virgil networking까지 구현된 것은 확인되지 않습니다.

Q. Virgil은 audio streaming protocol인가요?
아닙니다. 프로젝트는 Virgil을 Dante의 companion control protocol로 정의합니다. Audio transport 자체가 아니라 gain, phantom power, channel linking, device status 같은 control information을 TCP/JSON으로 전달하는 것이 목적입니다.

Q. MIDI controller인가요?
Physical form은 motorized fader와 display/encoder를 사용하는 control surface와 비슷하지만, 프로젝트는 MIDI 대신 자체 Virgil protocol을 개발하기 위한 platform으로 설명합니다.

Q. W5500과 Wi-Fi를 동시에 사용하나요?
Motherboard에는 W5500과 Raspberry Pi Radio Module 2가 모두 설계되어 있습니다. 하지만 현재 source에서 automatic failover나 simultaneous network operation까지 확인되지는 않습니다.

Q. PoE를 지원하나요?
Power architecture에서 PoE를 고려하고 있으며 초기 power module도 PoE와 12 V input을 대상으로 합니다. 다만 현재 단계에서는 final production PoE implementation으로 표현하기보다 prototype design으로 보는 것이 안전합니다.

Q. 직접 만들 수 있나요?
KiCad 프로젝트, STEP 파일, BOM이 공개되어 있지만 저자는 이것을 prototype이라고 설명하고 firmware는 미완성입니다.

📌 Building the Control Layer Around Network Audio

Proteus is a modular hardware platform being developed as a prototype for the Virgil live-sound control protocol. The README compares it to a MIDI controller such as the Behringer X-Touch, with two differences: it is fully open source and modular, and it does not use MIDI.

The project is not intended to replace network audio transport itself. The gap the author points to is that Dante moves the audio but has no room for control messages, so each audio vendor ships its own proprietary control protocol. Virgil is designed as a companion control protocol for exchanging device parameters such as gain, phantom power, channel state, and status information.

The Virgil specification currently defines JSON-formatted messages over TCP, with mDNS used for controller discovery. The overall concept can therefore be summarized as:

Audio Transport → Dante
Device Control → Virgil
Hardware Prototype → Proteus

Generated diagram from the README, Proteus.h pin definitions and the Networking schematic sheet.

🧩 Modular Control Surface

Proteus provides sixteen module slots, eight on the upper section and eight on the lower section. The slots are electrically identical and differ only in length. Current modules include:

Speculum — 1.14" TFT display, illuminated (NeoPixel) button and rotary encoder.

Cursor — B103 motorized fader module.

Every module must carry an RP2040/RP2350-class controller and communicates with the main system through SPI. The README also names a button module, Ordo. The result is a distributed architecture rather than one central MCU directly controlling every display, encoder and motor.

🧠 RP2350 Motherboard with W5500

The Proteus Motherboard is based on an RP2350 (16 MB flash). It includes:

• WIZnet W5500 Ethernet
• Raspberry Pi Radio Module 2
• EtherCON network connector
• USB-C and SWD for programming
• microSD over SDIO
• Backplane interfaces

The Networking.kicad_sch sheet contains the W5500 (LQFP-48) with a 25 MHz crystal, a Neutrik NE8FAH EtherCON jack, PT61018PEL magnetics, and LINK, DUP and ACT LEDs. The PCB carries nets named W5500_~{CS}, W5500_~{INT} and W5500_~{RESET}. The firmware board definition Proteus.h assigns the pins:

// Networking SPI
#define PICO_DEFAULT_SPI             spi0
#define PICO_DEFAULT_SPI_RX_PIN      0   // NET_MISO
#define PICO_DEFAULT_SPI_TX_PIN      3   // NET_MOSI
#define PICO_DEFAULT_SPI_SCK_PIN     2   // NET_CLK
 #define W5500_CS_PIN                 45
#define W5500_INT_PIN                46
#define W5500_RST_PIN                47

The network SPI and the W5500 control pins are configured during hardware setup. The module bus is a separate spi1, so Ethernet traffic does not share a bus with the faders and screens, and the radio module has its own chip-select (GPIO 42), interrupt (43) and enable (44). This confirms that W5500 is part of the intended motherboard architecture rather than only a conceptual network option.

🌐 W5500 as the Wired Path for Virgil

Virgil defines persistent TCP communication with UTF-8 JSON messages, each prefixed by a 4-byte unsigned big-endian length. Its documented message types include parameterCommand, statusUpdate, statusRequest, channelLink, channelUnlink, deviceInfoRequest, and subscribeMessage.

A future Proteus implementation can therefore follow a path such as:

Control Modules → RP2350 → Virgil → TCP → W5500 → EtherCON

Generated diagram of the control path described in the Virgil README. The Proteus firmware does not implement it yet.

The author does not explain the choice of W5500, so the following is our reading of the design:

• The RP2350 has no Ethernet MAC, so wired networking needs an external controller; the W5500 attaches over SPI and takes the MAC/PHY side and the TCP/IP stack with it.
• A control surface keeps long-lived TCP connections to several devices.  If Proteus later uses the W5500 hardware sockets, they could offload TCP/IP processing from the RP2350. The current repository does not yet define that software architecture.
• W5500 INT is connected to GPIO46, allowing firmware to handle network events through interrupts instead of continuous polling.

However, the current public Proteus firmware should be described carefully.

W5500 hardware and pin-level initialization are present, but a complete Virgil-over-W5500 TCP implementation is not yet visible in the repository. The repository also does not say whether it will use the W5500's hardware sockets or MACRAW with lwIP; the related projects below show both approaches.

Proteus is therefore best presented as a platform being developed for Virgil, rather than a finished Virgil Ethernet controller.

🎚️ What Virgil Aims to Control

The protocol defines parameters such as gain, phantom power, pad, polarity, low-cut, RF level, audio level and battery state, plus a channel model matching Dante TX/RX channels and a separate aux channel concept. A control surface like Proteus could eventually operate several devices' parameters from one interface.

🔌 A Backplane Designed for Intelligent Modules

The Backplane distributes SPI, power, reset, detection and SWD signals to the sixteen module slots. A CD74HC154M96 demultiplexer expands the Motherboard's four CS mux lines into sixteen module chip-selects, while two MCP23017T expanders provide reset and detection I/O. One GPIO goes straight to the controller as an SPI interrupt, which the README says will likely be removed to scale across more modules.

A SN74CBTLV1G125 per module switches that module's SWD lines, using the CS line as the control signal, so the central controller can program every module automatically.

⚡ Power and PoE

Power is separated onto its own isolated board so that different power architectures can be developed independently. The author wants a battery option later without taking on a BMS yet.

The current prototype power module is designed around PoE and 12 V input and supplies 3.3 V, 5 V and a motor rail of roughly 9–12 V, with the exact current to be determined by testing. It carries its own RP2350 with current and voltage sensing on every rail, a smart power fuse on the motor rail and a digital potentiometer to adjust it. PoE and USB-C PD signals, including the CC lines, are passed from the Motherboard to the power board. The repository reports no powered test results.

📡 Wired and Wireless Hardware

The motherboard includes both W5500 wired Ethernet and a Raspberry Pi Radio Module 2. This gives the platform hardware support for both wired and wireless networking. However, the current repository does not yet demonstrate automatic failover or simultaneous hybrid networking, so those behaviors should not be assumed.

⚠️ Development Status

Proteus is currently a development platform rather than a finished commercial controller; the README itself calls it a hardware prototype.

The KiCad projects, enclosure STEP files, renderings, BOM and motherboard pin architecture are published. The public Motherboard firmware, however, is still at an early bring-up stage: Code/Motherboard/Motherboard.cpp is the 50-line Pico example template (1 MHz SPI, I2C, a "Hello, world!" loop), and the build links only hardware_spi, hardware_i2c, hardware_pio and an SD library. There is no W5500 driver, ioLibrary or Virgil implementation in this repository, and the Virgil repository describes no reference firmware. It is also a single-maintainer project.

That makes Proteus particularly interesting as a design-in-progress reference for combining RP2350, W5500, modular control hardware and a new network control protocol.

🔗 Related WIZnet Maker Projects

Network MIDI 2.0 Bridge

View Maker Project

This project also combines RP2040 and W5500 for a music-related network protocol. Instead of the W5500's hardware TCP/UDP sockets it runs MACRAW → lwIP → UDP → Network MIDI 2.0, using the W5500 as the Ethernet MAC/PHY-facing interface and frame buffer.

Its focus is network MIDI transport, while Proteus targets live-audio equipment parameter control through Virgil. Which of the two W5500 modes Proteus will use is still open.

Core-Micro

View Maker Project

Core-Micro combines RP2040, W5500, physical faders and encoders for Art-Net/DMX lighting control. Its page describes five faders and two encoders as planned and the firmware as a minimal DMX/Art-Net verification build, and the hardware is split into Logic, Surface, DMX and Power boards, much as Proteus separates its boards.

Its physical control-surface concept is close to Proteus, but the application domains differ:

Core-Micro → Lighting / Art-Net / DMX
Proteus → Live Audio / Virgil / Dante companion control

SqueezeAMP PoE

View Maker Project

SqueezeAMP PoE uses ESP32, W5500 and IEEE 802.3bt PoE++ (up to 60 W) for a network audio amplifier, and its page states that TCP/IP runs on the ESP32's lwIP rather than the W5500 offload. Proteus also considers Ethernet and PoE, but serves a different role:

SqueezeAMP → Audio Endpoint
Proteus → Audio Control Surface

3D Joystick Controller

View Maker Project

An ESP32 reads two 3D joysticks and sends the values as OSC messages over a W5500 wired link. The input-to-network-message flow is the closest to Proteus's control-surface role, but it has working firmware on a ready-made W5500 board, while Proteus places the W5500 on its own custom motherboard.

w5500_mesaxyz

View Maker Project

This project adds W5500 wired Ethernet to a Pico W using WIZnet's ioLibrary_Driver. Proteus also combines wireless capability with W5500 Ethernet, but uses them within a larger modular live-sound control architecture rather than as a general connectivity demonstration.

❓ FAQ

Is W5500 actually part of Proteus?
Yes. It is included in the Motherboard hardware design (schematic and PCB nets) and firmware pin definitions. A complete TCP/Virgil implementation, however, is not yet visible in the public firmware.

Is Virgil an audio-streaming protocol?
No. Virgil is described as a companion control protocol for Dante-based systems, carrying device-control information such as gain, phantom power, channel linking and status over TCP/JSON.

Is Proteus a MIDI controller?
Its physical form resembles a modular control surface with faders, displays and encoders, but the project is intended to prototype the Virgil protocol instead of MIDI.

Does it already use W5500 and Wi-Fi together?
The Motherboard includes both W5500 and a Raspberry Pi Radio Module 2, but the current source does not demonstrate automatic failover or simultaneous hybrid networking.

Is PoE finished?
PoE is part of the power architecture and the current prototype power module is designed for PoE and 12 V input, but it should still be described as a development-stage power design.

Can I build one?
The KiCad projects, STEP files and a BOM are published, but the author describes it as a prototype and the firmware is incomplete.