Wiznet makers

NeuroFab Z1 Onyx: A W5500-Managed Distributed SNN Cluster Based on RP2350B

Overview

The NeuroFab Z1 Onyx Cluster is a neuromorphic computing research project designed to distribute Spiking Neural Network, or SNN, workloads across multiple RP2350B-based compute nodes.

The publicly documented V2 configuration consists of 16 compute nodes and one controller. Each compute node processes neurons and synapses, while the controller coordinates topology deployment, system monitoring, spike injection, file management, and firmware updates. Data between nodes travels over a custom 16-bit parallel Matrix bus, while communication between an external computer and the controller is handled by a WIZnet W5500 Ethernet controller. (GitHub repository)

The W5500 does not perform SNN computation or directly transport spikes between compute nodes. Instead, a project-specific W5500 driver provides the external Ethernet path through which users can configure, observe, and update the cluster as a unified system. From an architectural perspective, this interface functions as the management plane of the distributed computing platform.

Source snapshot — July 13, 2026
This article is based on the public GitHub repository and related documentation reviewed on July 13, 2026. GitHub currently shows four commits, with the latest identified commit dated February 12, 2026, adding OTA node application binaries. Because the repository uses inconsistent maturity terms—including Development Ready, Production Ready, and Functional Prototype—this article classifies the project as a functional research prototype, not as an independently validated production product.

About the Maker

Kevin Williams and TexElec

The repository was published through the TexElec GitHub account, texelec. The GitHub profile identifies the account owner as Kevin Williams and associates him with TexElec and Texas, United States. In addition to Z1 Onyx, the account contains projects related to retro-computer sound cards, RGB-to-HDMI boards, MCA expansion hardware, and STM32-based systems. (TexElec on GitHub)

According to Kevin’s official biography, he began working with electronics and computers at an early age, building XT- and 286-compatible PCs and installing Novell and ArcNet networks. He later worked at Microsoft in several roles until 2013 and describes networking and TCP/IP services as his primary areas of expertise. Around 2000, he began working with Atmel microcontrollers and assembly language before expanding into Arduino and custom board development. This background information comes from TexElec’s own published company profile. (About TexElec)

TexElec is a hardware development and retail group operated by Kevin Williams and Sara Williams. Its primary focus is helping users restore and extend vintage computers and gaming systems through finished products and DIY solutions. Its product range includes hardware for Commodore systems, IBM PCs and compatibles, PCjr, MCA, PS/2, Tandy, and Raspberry Pi platforms.

TexElec also states that it may consider producing or selling projects proposed by external makers. Sara participates in board assembly, product listings, packaging, customer support, and day-to-day operations. The group also attends community events such as Vintage Computer Festival gatherings, where it presents products and prototypes. (About TexElec)

What Is NeuroFab?

The repository’s root license and several source-code headers identify NeuroFab Corp as the 2025–2026 copyright holder. However, the public repository and TexElec website do not provide a separate official profile for NeuroFab, a team list, a business description, or a detailed explanation of its relationship with TexElec.

Based on the currently available information, the most accurate description is:

Repository published by Kevin Williams / TexElec, with NeuroFab Corp named in the project’s copyright notices.

The available public information is not sufficient to identify Kevin Williams as the sole developer or to describe NeuroFab as an established commercial neuromorphic semiconductor company. The project’s contributor roles and organizational relationship would need to be confirmed with the repository owner.

Project at a Glance

The repository describes the hardware as “Raspberry Pi Pico 2, RP2350B,” while also referring to external PSRAM, additional GPIO, and a custom backplane. Because the circuit diagrams and board design files are not publicly available, it is unclear whether the system uses standard Raspberry Pi Pico 2 boards or custom RP2350B hardware that follows Pico SDK and UF2 development conventions.

System Architecture

Two Networks with Different Responsibilities

The Z1 Onyx communication structure can be understood as two separate layers.

PC / Python CLI
        │
        │ Ethernet · HTTP
        ▼
W5500 + Z1 Controller
        │
        │ 16-bit Matrix bus
        ▼
Compute Node 0 ··· Compute Node 15

The first is the Matrix bus, which carries spikes and commands between the controller and compute nodes. The second is the W5500 Ethernet interface, which allows an external computer to access the controller.

The terms compute plane and management plane are used here as a curator’s architectural interpretation of the published data flow. They are not presented as terminology officially defined by the project developer.

Matrix Bus

According to the public documentation, the Matrix bus includes a 16-bit data bus, clock signals, read and write controls, and node-selection lines. A total of 26 signals are carried through PCIe x4-style connectors, although the system does not use the PCI Express protocol.

Frames contain source and destination node information, frame type, payload data, and CRC16. The protocol defines unicast, broadcast, acknowledgment, and control frames. Spikes generated by the SNN are also propagated to other nodes over this bus.

Each compute node examines the Global Neuron ID of an incoming spike. If one of its local neurons has a synaptic connection to that source, the associated weight is applied to the membrane potential. A neuron that crosses its threshold generates another spike, which is then transmitted over the Matrix bus.

How the W5500 Is Used

The W5500 is an Ethernet controller integrating a Hardwired TCP/IP stack with a 10/100 Ethernet MAC and PHY. Its official specifications include an SPI clock of up to 80MHz, eight independent hardware sockets, and 32KB of internal TX/RX memory. (W5500 product page)

The Z1 Onyx controller firmware connects the W5500 through SPI0 and initializes it with a 40MHz SPI clock. Of the eight hardware sockets provided by the chip, the public implementation activates four TCP sockets and operates an HTTP server on port 80. Socket state is handled through polling rather than the interrupt pin.

The published controller/w5500_eth.c file directly defines W5500 common registers, socket registers, block-select values, socket commands, and low-level SPI buffer operations. No use of the standard WIZnet ioLibrary socket API was identified in the reviewed public repository. Instead, the controller opens, listens on, receives from, and transmits through W5500 TCP sockets by directly reading and writing chip registers and socket buffers.

This is therefore a custom register-level W5500 integration rather than an ioLibrary socket implementation. The W5500 still supplies the Ethernet MAC, PHY, hardware TCP/IP engine, socket state machines, and internal TX/RX memory, while the project firmware implements its own driver and HTTP request handling around those hardware resources.

An external computer can use the W5500 interface to access the following functions:

The W5500 is not a neural-network accelerator. Its importance in this project is that its Ethernet and hardware TCP/IP resources—accessed through a custom register-level driver—make the multi-MCU computing system accessible and manageable from an external network.

Distributed SNN Processing

Each compute node implements a Leaky Integrate-and-Fire, or LIF, neuron model. Input spikes and synaptic weights affect the membrane potential, while leak and refractory-period rules determine whether a neuron crosses its firing threshold. A Global Neuron ID combining the node ID and local neuron ID is used for inter-node routing.

The repository includes an XOR topology example. The published description uses two input neurons, two hidden neurons, and one output neuron distributed across two compute nodes. Excitatory and inhibitory weights are combined to reproduce XOR behavior as a small-scale validation example.

The current source code sets compile-time limits of 16 neurons per node, 60 synapses per neuron, and a 256-entry spike queue. If the 16-neuron limit is applied across all 16 compute nodes, the current default configuration has a theoretical ceiling of 256 neurons.

This is a calculation based on source-code constants. It does not mean that a complete 256-neuron topology has been independently demonstrated on the physical cluster.

For this reason, describing the current implementation as a “large-scale neural-network accelerator” would be misleading. The 8MB PSRAM may provide room for future expansion, but storage capacity and the present execution limits should be treated as separate considerations.

The status of STDP is also inconsistent across the documentation. The main project documentation lists STDP implementation as future work, while a separate LIF package document refers to experimental STDP functionality. Because the available evidence does not establish a consistent, validated implementation, this article does not present STDP as a confirmed current feature.

Cluster Management and OTA Updates

The repository includes several Python command-line tools alongside the firmware.

Compute-node firmware uses a dual-partition design that separates the bootloader and application regions. New application images are delivered to the controller over HTTP and transferred to target nodes through the Matrix bus.

The documentation states that CRC32 is used to verify the transferred image and that the bootloader is designed to reject invalid applications. (GitHub repository)

The ability to discover, configure, deploy, and update multiple nodes through a single Ethernet interface—rather than connecting each node individually over USB—is one of the project’s most significant system-level features.

CRC32 verifies data integrity during transfer, but it does not authenticate the sender or protect the firmware image from unauthorized modification before transmission.

Reported Performance and Validation

The repository reports the following Matrix bus results:

These are developer-reported internal test results. The public materials reviewed for this article do not include complete raw measurement logs, detailed test-equipment configurations, extended load testing, voltage and temperature ranges, or independent reproduction.

For that reason, it is more accurate to state that no CRC errors were reported within the published test sample than to claim absolute “100% reliability.”

The README also states that the automated test suite passes. However, the public test script continues once at least two nodes are discovered. The SD-card test can also be treated as optional when the card is unavailable or unmounted.

Therefore, the reported 9/9 passing result should be understood as a self-test of the provided software workflow—not as proof that all 16 nodes have been validated under every operating condition.

Related Maker Projects

No existing WIZnet Maker project is identical to Z1 Onyx. However, three projects provide useful comparisons in the areas of distributed embedded communication, external system management, and separation between real-time control and Ethernet connectivity.

1. PSPL CMS Avionics

PSPL CMS Avionics is a distributed flight-computer and ground-support network developed by the Purdue Space Program Liquids team for a liquid rocket.

The Maker Site article describes several RP2040-based boards exchanging sensor data and commands through W5500 controllers and an Ethernet switch. UDP-based telemetry and TCP-based command and control operate over the same Ethernet network. (PSPL CMS Avionics)

Both Z1 Onyx and CMS distribute responsibilities across multiple embedded computers rather than concentrating all functionality in one MCU.

The main difference is where Ethernet sits in the architecture.

CMS Avionics
Flight Computer ← W5500 / Ethernet → Flight Computer

Z1 Onyx
Compute Node ← Matrix Bus → Controller ← W5500 / Ethernet → PC

In CMS, Ethernet serves as the internal communication backbone among the primary flight computers. In Z1 Onyx, spikes move over the Matrix bus, while the W5500 is focused on external management.

Together, the projects demonstrate two ways W5500 can be used in a distributed embedded system:

As a direct Ethernet backbone connecting multiple processing nodes

As a gateway in front of a dedicated internal communication bus

2. W5500-EVB-Pico Powers DLR’s Rocket Simulator

A Maker Site article on a DLR-related project describes the W5500-EVB-Pico as the controller for an MSMSv3 hardware-in-the-loop simulator used to test rocket-payload power, signal, and communication interfaces on the ground.

According to the article, the W5500-EVB-Pico handles Ethernet and USB communication, SCPI command processing, and bridging to RS-422 telemetry and telecommand interfaces. (DLR Rocket Simulator)

The DLR simulator and Z1 Onyx are similar in that both use W5500-based hardware as a control hub between external test or management software and embedded hardware.

The DLR example is closer to a single laboratory instrument that accepts commands and emulates interfaces. Z1 Onyx places multiple compute nodes behind one controller and translates Ethernet requests into internal Matrix bus commands.

This comparison focuses on the published HIL, SCPI, and communication-hub architecture. It does not treat the simulator as evidence of aerospace certification or space qualification.

3. BX39_MIRAGE_SED

BX39_MIRAGE_SED is a WIZnet Maker Site project describing a stratospheric methane-measurement experiment from Uppsala University for the BEXUS 39 program.

The article describes an ESP32-C5-based main MCU using a WIZ850io module to transmit science and housekeeping telemetry to the ground over UDP. Separate ESP32-S3-class controllers handle pressure and thermal control under the supervision of the main MCU.

The mission is described as targeting an October 2026 launch, so it should be treated as a planned project rather than a flight-proven system. (BX39_MIRAGE_SED)

MIRAGE and Z1 Onyx both divide time-sensitive local processing from external wired communication.

In MIRAGE, the WIZ850io primarily provides a payload-to-ground telemetry path. In Z1 Onyx, the W5500 supports monitoring as well as topology deployment, file management, configuration changes, and OTA updates. It therefore functions more broadly as a system lifecycle interface.

Comparison at a Glance

Why This Architecture Matters

Ethernet Beyond a Single IoT Endpoint

Many W5500 projects begin by connecting one sensor or controller to an Ethernet network. Z1 Onyx expands that role to the management of an entire multi-processor system.

The important message is not that the W5500 “runs AI.” Complex computing systems require more than processing performance. They must also be observable, configurable, updateable, and recoverable.

Z1 Onyx demonstrates how W5500 hardware can provide that operational path for a distributed embedded platform, even when the system uses a project-specific register-level driver rather than the standard ioLibrary socket API.

A Reference Point for RP2350 and W5500

WIZnet offers the W5500-EVB-Pico2, which combines an RP2350-series MCU with the W5500. There is no evidence that the board is directly compatible with the custom Z1 Onyx hardware, but the two platforms share a relevant technical direction: pairing an RP2350-family controller with a Hardwired TCP/IP Ethernet device. (W5500 product information)

With additional documentation or a future port from the maker, the project could lead to follow-up content such as:

• An RP2350 + W5500 cluster controller
• Multi-MCU firmware orchestration through the W5500
• Comparison between WIZnet ioLibrary and the project’s custom register driver
• Ethernet-managed edge-AI or accelerator nodes
• Authenticated local management protocols as alternatives to plain HTTP
• W5500 socket and SPI burst-transfer optimization

These are possible future directions inferred from the published architecture. They should not be interpreted as existing project features.

Potential Application Directions

Z1 Onyx is currently a functional prototype, but its separation of an internal real-time bus from an external Ethernet management interface may be relevant to several other fields.

Distributed Edge Computing

Multiple MCU or FPGA modules could execute different workloads while one controller manages models, configuration, status, and firmware.

Test and Measurement

The same structure could support laboratory instruments, HIL systems, or production-test fixtures in which several data-acquisition modules or devices under test are managed behind one Ethernet endpoint.

Robotics and Event-Based Sensors

Event cameras, acoustic sensors, tactile sensors, or distributed motor controllers could perform time-sensitive processing on a local bus while the W5500 manages configuration and monitoring.

Education and Research

The project combines distributed neuron placement, spike routing, custom bus design, HTTP APIs, and OTA updates. It may therefore be useful for teaching not only SNN concepts but also multi-MCU architecture and embedded networking.

These are potential applications derived from the architecture, not confirmed commercial deployments of Z1 Onyx.

Open Source, Reproducibility, and Operational Limits

The repository includes controller and node firmware, a project-specific register-level W5500 driver, the Matrix bus protocol, an SNN engine, bootloader code, Python management tools, prebuilt UF2 and BIN files, and API documentation.

The root repository uses the MIT License. (GitHub repository)

However, the reviewed repository tree did not include the following hardware-production resources:

• Complete schematics
• Original PCB design files
• Gerber files
• Detailed bill of materials
• Backplane assembly drawings
• Power-integrity or signal-integrity test data

The firmware and protocols can be studied or built, but it would be misleading to claim that the complete 17-node hardware can be reproduced from the repository alone.

Licensing also requires additional clarification. Although the repository root uses the MIT License, some source headers and LIF package documentation contain “All rights reserved” language. Anyone considering commercial reuse or derivative hardware should confirm whether the root license applies consistently to every included subcomponent.

Network Security

The controller exposes a plain HTTP API on port 80. In the reviewed request-routing code, no user authentication, request signing, or TLS processing was identified. The API includes endpoints for file upload and deletion, configuration changes, rebooting, and OTA updates.

This is a conclusion based on the reviewed public code. It does not prove that no separate or private security layer exists elsewhere.

The current public version is therefore more appropriate for a trusted laboratory LAN or isolated VLAN than for direct exposure to the public internet.

Connecting with the Maker

TexElec states on its official website that it may consider projects proposed by external makers for production or sale. Its contact form also includes a dedicated Project Idea category, providing a public route for proposing interviews or technical collaboration. (About TexElec)

An initial discussion could focus on:

• The exact relationship among Kevin Williams, TexElec, and NeuroFab
• The designers and contributors behind the physical Z1 Onyx hardware
• Photographs of the RP2350B boards, W5500 interface, and backplane
• The test scope and raw measurements for the complete 16-node configuration
• Plans to publish schematics, BOMs, or PCB files
• The reasons for choosing the W5500 and implementing a custom register-level driver
• Whether WIZnet ioLibrary was evaluated during development, and why its socket API was not used in the public implementation
• Future authentication or encryption for the management interface
• Interest in a W5500-EVB-Pico2 or ioLibrary-based reference implementation

Because TexElec designs, assembles, and sells physical hardware and has an established networking background, the project may provide opportunities for a technical interview, design review, or follow-up reference content.

This is a potential outreach direction based on TexElec’s public activities and contact channels. It does not imply that the maker has already agreed to collaborate.

Summary

The NeuroFab Z1 Onyx Cluster is a distributed SNN research project connecting 16 RP2350B-based compute nodes and one controller through a custom Matrix bus.

Each node executes LIF neuron and synapse processing, while the W5500-equipped controller provides topology deployment, monitoring, file management, and node firmware updates through an HTTP API.

Its most distinctive architectural feature is the separation of node-to-node spike processing from external Ethernet communication.

Given the current code limits, incomplete public hardware documentation, and scope of the reported testing, the project is best described as an Ethernet-managed distributed neuromorphic computing prototype, rather than a completed commercial neuromorphic accelerator.

Z1 Onyx is a notable example of how W5500 hardware can be integrated through a custom register-level driver to configure, observe, and maintain a multi-processor embedded computing system, rather than serving only as the network interface of a single IoT endpoint.

FAQ

Q. Who is the author of this project?
A. The repository was published through Kevin Williams’ TexElec GitHub account. NeuroFab Corp is named in the root license and source-code copyright notices, but the full contributor list and division of responsibilities are not public. Kevin should therefore be described as the repository publisher or maintainer, not automatically as the sole developer.

Q. What kind of work does TexElec do?
A. TexElec is a hardware development and retail group operated by Kevin and Sara Williams. It develops and sells expansion cards, repair components, and DIY boards for vintage computers and gaming systems. It also participates in community events and may consider manufacturing or selling projects proposed by external makers.

Q. Does the W5500 perform the SNN computation?
A. No. SNN processing is performed by the RP2350B-based compute nodes. The W5500 connects the controller to an external computer and provides the HTTP API, file transfer, monitoring, configuration, and OTA update path.

Q. Are spikes transferred between compute nodes over Ethernet?
A. No. Spikes and internal commands travel over the custom 16-bit Matrix bus. Ethernet is used as a separate external management and deployment path.

Q. Is the project production-ready?
A. The repository uses inconsistent maturity descriptions, including Production Ready, Development Ready, and Functional Prototype. Because independent testing, complete hardware documentation, and product certification are not publicly available, Functional Prototype or Development Ready is the more appropriate classification.

Q. Is the OTA update system secure?
A. CRC32-based image-integrity checking is documented. However, authentication and TLS were not identified in the reviewed public HTTP-routing code. The current implementation is therefore more suitable for an isolated local network. CRC32 should not be interpreted as sender authentication.

Q. How does Z1 Onyx differ from similar WIZnet Maker projects?
A. CMS Avionics uses Ethernet as a direct backbone between embedded computers. The DLR simulator uses W5500-based hardware as a test-equipment control hub, while MIRAGE uses WIZ850io primarily for telemetry. Z1 Onyx separates its internal Matrix bus from a single W5500 controller responsible for cluster deployment, configuration, monitoring, and updates.