> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adsumnetworks.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Partner open hardware
> Hardware makers who publish their designs, and work with us so their devices arrive with the board details already written down and tested.
Hardware makers who publish their designs, and work with us so their devices arrive with the board details already written down and tested: pinouts, which M.2 card carries which radio, which connector programs which chip, and where a printed part number names something that is not fitted.
**Open hardware is why this works.** The designs are published, so what we write about a board can be checked against them rather than taken on trust. And the board runs your firmware, not a vendor's. Most industrial gateways in this class are sealed boxes that forward data to the cloud their maker chose.
**You do not need any of this to build on the device.** The [chip support](/supported-hardware) covers that.
What it removes is a specific two days. Every new board starts the same way: a vendor PDF that disagrees with the schematic, three connectors that look identical and are not, and a long afternoon finding out which one flashes which chip before a line of firmware gets written. An agent normally makes that worse rather than better, because pointed at a datasheet it will hand you a confident, plausible, wrong pin number, and you will not find out until the board is silent on the bench.
**So we do that work once, per board, by hand.** We read the schematic, bench-verify what it claims, write down what is certain separately from what is only expected, and the agent loads it when it sees that hardware. Not a PDF parsed at runtime: knowledge that was tested on the actual board. The result is that your prompt gets to be short. You describe the product you want, not your pins.
Live logs over RTT and serial, the HCI bus, and over-the-air capture. Behaviour, not just source.
Hardware knowledge written and verified by engineers, loaded per board, with what is confirmed marked separately from what is assumed.
SPDX SBOM from the real build, live CVE scan, and a secure-by-design posture review.
## The boards
Everything in that photograph is checkable. The board revision is printed on the PCB, the radios sit on M.2 cards you can lift out and read the part number off, and the programming headers are labelled for the chip each reaches. This is the IP65 build, for gateways that work outdoors. Fanstel publish the schematics and specifications, so our knowledge of this board is written against documents you can open yourself.
**A composable multi-radio gateway.** An ESP32 base with Ethernet and PoE, radios on swappable M.2 cards, IP65 so it goes outdoors. BLE scanning, Ethernet and Wi-Fi with failover, from a prompt that names no pins.
**A dual-MCU production gateway.** An nRF52840 with a power amplifier on the sensor-facing radio, an ESP32 on the uplink, talking over UART inside the box. Two chips from one written spec, then debugged over the air.
### The documents
The schematics, specifications and control code for both boards are [published by Fanstel](https://www.fanstel.com/download-opensource). We keep our own copy pinned to the exact revision each build was checked against, with the source URL and checksum of every file recorded beside it, because the filenames carry content hashes and a re-upload silently breaks a link.
That matters for a specific reason. The curated knowledge for the BWG840 records its LEDs and button as verified against schematic revision **V1B**. Because that document is published and pinned, the claim can be checked against the drawing it was made from rather than believed.
## How these pages are written
Every number on a device page names the artifact and the command behind it, and every page ends with the board revision, toolchains and extension version it was verified with. The hardware knowledge is written the same way: facts confirmed on the bench are marked separately from facts still only expected from a schematic.
Handing the same prompt to the agent will not reproduce our output byte for byte. A different model, a different SDK version and ordinary model nondeterminism all change the result. What we publish is the version we ran on hardware and stand behind.
## If you make hardware
The details that make a device quick to build on should come from the people who designed it. They know the board; everyone else is reading its schematic afterwards and guessing.
If you already publish your designs, you are most of the way there. We write this knowledge today because it did not exist, and because someone had to show it works. The way it is made is open too: each piece is versioned, tested on the board, and carries its author's name in every session that uses it. Any hardware maker can maintain their own, and their engineers appear on the [co-author roster](/about-and-contact) by the same rule as everyone else.
Fanstel is the first. It is not meant to be the only one.
What a partner gets, in practice: their engineers use the tool on their own boards, and what they learn on the bench becomes knowledge published under their own names, credited in every session that loads it. Knowledge for a board that is not yet public can sit behind an early-access group that we open per account, on request, so a partner's customers can start before the launch. For the LEW840x this already includes signed images and licensed source per module (see [gateway firmware](/gateway-firmware)).
If you build open IoT hardware and want your devices to work this way.