FarmMesh Node

FarmMesh Node

An integrated hardware and software solution for farm-wide Mesh networking

English | 简体中文

Overview · Solution scope · A1 hardware · Features & targets · Architecture · Internal interface · Wireless research · Open decisions · Roadmap · Contact · References

Overview

FarmMesh Node is a hardware and software project for a complete farm wireless networking solution. Its scope includes node electronics, embedded firmware, communication protocols, Mesh networking, client and sensor access, and system integration and field validation. Hardware and software are developed together toward the same farm-wide service goals; the A1 PCB is the current hardware milestone within that larger project.

FarmMesh Node aims to provide farm-wide coverage using solar-powered infrastructure nodes that need no pre-installed power or network cabling, combining on-demand high-speed client access with distributed access for hundreds to approximately 1,000 low-traffic sensors. Inter-node links are intended to be entirely wireless. Solar supply, storage and node power budgets remain to be designed; this is not a claim of all-weather energy autonomy, and a gateway/uplink may still be needed.

The client-access design target is 50 Mbps of effective throughput after connecting to a Mesh node, available on demand wherever needed in the farm. The initial capacity assumption is 1–2 concurrent high-speed clients across the whole farm, not per infrastructure node and not a limit on the number of Mesh nodes or total clients. This does not require every location to receive 50 Mbps simultaneously. Measurement endpoints, direction and test conditions remain TBD; there is no guarantee of 50 Mbps across multiple Mesh hops or to the Internet.

Infrastructure nodes are intended to provide concurrent BLE or Wi-Fi access for several hundred to approximately 1,000 low-traffic, low-power sensors across the whole farm, distributed among multiple Mesh nodes. This is an aggregate planning target requiring capacity validation, not 1,000 direct BLE connections per node or simultaneous packet transmission by every sensor. End-device energy requirements and the infrastructure's solar-power budget are separate concerns; neither implies that the forwarding infrastructure must sleep. Low Wi-Fi traffic alone does not establish low power consumption, and BLE/Wi-Fi coexistence requires validation.

Each infrastructure node contains one RP2350B and three ESP32-C5 chips, implemented in A1 with three official ESP32-C5-WROOM-1U-N8R8 modules. The RP2350B is intended to aggregate and forward data inside the node, with an independent internal link to each C5. The separate preliminary 50 Mbps per internal link target is a hardware design input, not a demonstrated user throughput figure or proof that the access-service target can be met. Its directional and raw-rate/payload-rate definitions remain TBD.

Development is staged from the node hardware foundation through firmware and network software to full-system validation. The A1 prototype has eight schematic sheets, a four-layer PCB and a manufacturing package released for controlled engineering prototypes; its release record is RELEASE.md. Firmware and network software implementation remain pending. Coverage, user throughput, terminal capacity, power consumption and sustained internal-link performance have not been measured.

Solution scope and current progress

This repository currently contains the hardware release, system requirements and wireless research. Software will be developed as part of the same project; the table distinguishes the intended solution from what is already implemented.

A1 hardware prototype

A1 contains a 100 × 100 mm four-layer PCB, protected single-cell nominal 3.7 V Li-ion input, 3.3 V buck-boost supply, RP2350B, three C5 modules, independent parallel interfaces, UART download headers and RP USB/SWD. USB data disconnects in hardware when VBUS is absent, including ROM BOOTSEL operation. USB does not power or charge the board. Solar charging and storage sizing remain separate design work.

The C5 modules use external dual-band antennas. Their native USB pins are allocated to PARLIO; each C5 retains UART download and logging. No wireless transport or Mesh protocol is selected by the hardware. A fabrication-ready package does not establish RF, power or throughput performance.

Key features and performance targets

Targets below are planned requirements, not measured results. TBD means to be determined. Chip resource facts and candidate allocations are identified separately.

Architecture

Network concept

The diagram separates end-device access from the Mesh infrastructure. Dotted lines show intended service relationships and node membership, not physical radio links or packet paths. The service box is a logical grouping, not a central device. Inter-node topology, radio roles and Mesh protocol remain open; the measurement endpoint and gateway/uplink boundary are also TBD.

flowchart TB
    fast["High-speed clients / 高速客户端<br/>50 Mbps access target / 接入目标<br/>1–2 concurrent farm-wide / 全网并发目标"]
    low["Low-traffic sensors / 低流量传感器<br/>Hundreds to approx. 1,000 farm-wide / 全网数百至约千个<br/>Concurrent access goal / 并发接入目标"]
    mesh["FarmMesh infrastructure services / 基础设施服务层<br/>Logical grouping / 逻辑分组"]
    fast -.- mesh
    low -.-|"BLE or Wi-Fi / 计划接入"| mesh
    subgraph infra["Solar-capable Mesh nodes / 太阳能 Mesh 节点目标"]
        a["FarmMesh Node A"]
        b["FarmMesh Node B"]
        c["FarmMesh Node C"]
    end
    mesh -.- a
    mesh -.- b
    mesh -.- c
    deployment["No pre-installed power or network cables / 免预布电源线或网线<br/>Wireless inter-node links / 节点间纯无线目标"]
    deployment -.- mesh
    boundary["Measurement endpoint and gateway/uplink / 测速端点与网关或上联<br/>TBD / 待定"]
    mesh -.- boundary

Inside one node

Each line represents an independent internal data link. Clock and VALID directions are defined separately in the interface table below; the arrows here do not specify clock sources.

flowchart LR
    subgraph node["One FarmMesh Node / 单个节点"]
        rp["RP2350B · PIO + system DMA<br/>Data aggregation and forwarding / 数据汇聚与转发"]
        ca["ESP32-C5 A · PARLIO"]
        cb["ESP32-C5 B · PARLIO"]
        cc["ESP32-C5 C · PARLIO"]
        rp <-->|"Link A / 链路 A"| ca
        rp <-->|"Link B / 链路 B"| cb
        rp <-->|"Link C / 链路 C"| cc
    end

The three ESP32-C5 chips' wireless roles, channels and connections to other nodes are not assigned by this diagram.

Wireless coexistence boundary

Espressif documents shared RF resources with time-division and priority arbitration. Its current C5 coexistence table marks Wi-Fi SoftAP Connecting/Connected combined with BLE Scan/Advertising/Connected as C1 (supported, with unstable performance). This is a constraint to validate if a C5 is assigned both Wi-Fi AP and BLE roles; it does not establish that the three-chip node cannot meet its goals. Radio-role allocation and coexistence must be checked against the selected SDK and operating scenarios. Concurrent terminal service does not imply independent, simultaneous full-load radios on a single C5. See the official RF coexistence guide.

Per-node BLE capacity has an implementation-dependent limit, not one universal fixed connection count imposed by the BLE specification. The C5 controller and NimBLE host expose separate connection-limit settings in the official configuration reference. Connection-based access and connectionless advertising/scanning are different BLE roles and topologies; scanning advertisements must not be counted as persistent connections. Advertising/scanning terminal capacity needs its own validation. Select the access mode and three C5 roles before confirming per-node capacity; simply adding three chip-level limits does not establish node capacity.

Candidate internal interface

The selected hardware interface is ESP32-C5 PARLIO ↔ RP2350 PIO, using separate 4-bit TX and RX data buses. A1 freezes the physical connections; firmware and timing for concurrent bidirectional operation remain unvalidated.

Each C5 supplies both clocks. The RP2350 PIO follows an external clock in both directions, including when the RP2350 sends data to the C5.

This uses 12 signals per link: 8 DATA, 2 CLK and 2 VALID. Three links use 36 signals, plus a common ground reference. A1 freezes the prototype pin assignment in the schematics and C5 pinmap; firmware and hardware timing validation remain open.

PARLIO has separate TX and RX units. A shared-data, half-duplex alternative would require explicit output-enable, tri-state and direction-change handling. PARLIO must not be treated as an automatically reversing shared bus, and disabling TX does not by itself establish a high-impedance output.

Preliminary resource budget

These estimates do not constitute an implemented PIO program or validated timing design. A1 assigns the three interfaces to RP2350B GPIO0–35. Each PIO has a 32-GPIO window selected by GPIOBASE 0 or 16; the PIO configuration and instruction use still need implementation checks. Dedicated QSPI storage pins, USB and SWD do not consume the 48 Bank0 GPIOs. Other board functions use part of the remaining GPIO budget. The 30-GPIO RP2350A cannot accommodate this 36-signal candidate.

Processing responsibilities and timing boundary

• CPU: initialization, buffer preparation, transaction coordination and exception handling.
• PIO: beat-level sampling and output timing under the C5-provided clocks.
• System DMA: block transfers between PIO FIFOs and RP2350 SRAM, intended to avoid CPU byte-by-byte copying.

The C5 PARLIO RX documentation describes receive-clock output and VALID-based reception gating. C5 RX/GDMA transactions must be prepared before data arrives; VALID alone does not create a receive transaction. The RP must prepare the first beat and drive VALID correctly. Start/end behavior, sampling edges and gating timing still require a concrete design and validation.

Frame boundaries, DMA rearming and sustained operation also remain to be designed. A ring-address setting alone is not a guarantee of indefinite operation, and this draft does not claim CPU-free transfer management.

Wireless research status

The wireless link research notes record the 2026-09-22 review, official sources, version-specific binary observations and MTU/MSS constraints. No wireless transport has been selected. The client-access targets and internal hardware candidate above remain unchanged.

Open decisions

1. Define the client-to-Mesh-node 50 Mbps access test: measurement endpoints, uplink/downlink direction and conditions. Start with 1–2 concurrent high-speed clients farm-wide; multi-hop and Internet throughput remain outside any established guarantee.
2. Define each internal link's 50 Mbps target separately: one direction, both directions combined, or each direction; raw rate versus effective payload rate; and the capacity margin needed to support the user-service goal.
3. Establish three-link PIO feasibility, clock/timing constraints, GPIO mapping, instruction budget and required CPU participation. Define first-beat readiness, VALID behavior, receive-transaction preparation, frame boundaries and DMA rearming.
4. Validate the farm-wide planning target of several hundred to approximately 1,000 low-traffic sensors. Select connection-based BLE versus advertising/scanning roles, establish per-node limits and define activity duty cycles, traffic, latency and end-device energy targets. Radio roles/channels and BLE/Wi-Fi coexistence remain to be validated.
5. Design the solar supply, storage and infrastructure power budget for deployment without pre-installed power or network cabling. Later, decide Mesh protocol and routing, antennas, coverage area/terrain and deployment, gateway/uplink, environmental protection and the full BOM.

These decisions guide the complete hardware and software solution. The current repository establishes the A1 hardware foundation and records the software design inputs; firmware, network protocols, routing and system optimization are the next development stages.

Roadmap

Contact and participation

Interested in FarmMesh Node? Use GitHub Issues to discuss requirements, hardware, firmware, network software, system testing or ways to participate. You can also visit the project owner's GitHub profile.

References

Official sources for subsequent design checks:

• RP2350 datasheet — GPIO, PIO and system DMA resources.
• ESP32-C5 datasheet and technical reference manual — device and peripheral details.
• ESP32-C5 PARLIO RX driver — receive clock, VALID and transaction setup.
• ESP32-C5 PARLIO TX driver — transmit configuration and operation.
• ESP32-C5 RF coexistence — supported role combinations and shared RF scheduling constraints.

Differences in maximum full-duplex width descriptions across C5 documentation still need reconciliation. This draft considers only the 4-bit-per-direction candidate and makes no claim about wider full-duplex configurations. The ESP-IDF stable links can change; record the selected SDK and document versions when the implementation baseline is set.