Documenting a Node

Why Documentation Matters

A mesh network is not just hardware. It is also notes, testing, maintenance, local knowledge, and people who understand how the pieces fit together.

If a node works well, documentation helps others learn from it. If a node fails, documentation helps people troubleshoot it. If a node disappears, moves, or changes firmware, documentation helps the community understand what changed.

This is especially important for shared infrastructure like fixed repeaters, observers, solar nodes, community-hosted devices, and test equipment used during field work.

What Counts as a Node?

For documentation purposes, “node” can mean a few different things. The exact label matters less than clearly explaining the role.

Portable node

A handheld, pocket, vehicle, or temporary device used for field testing, messaging, or moving around the county.

Fixed node

A device that usually stays in one place, such as a home, workplace, club, library, garage, window, or other regular location.

Repeater

A device placed to help extend coverage. Repeaters benefit from good height, antenna placement, reliable power, weather protection, and clear documentation.

Observer

A device that listens for activity and helps document what can be heard. Observers are useful for logging, mapping, and understanding what can be heard over time.

Hub or support system

A computer, script, logger, broker, dashboard, or other backend system that supports the project. These should be documented too, but they do not need to be public-facing in the same way.

Minimum Useful Information

A basic node note does not need to be fancy. Start with the details someone else would need to understand what the device is doing.

• Node name.
• Device model.
• Role: portable node, fixed node, repeater, observer, or hub.
• General area or type of location.
• Antenna type and placement.
• Power source.
• Firmware or software version, if known.
• Service or network: MeshCore, Meshtastic, GMRS, ham, or other.
• What it can hear or reach.
• Known problems or maintenance needs.

If you do not know every detail, write down what you do know. Partial notes are better than no notes.

Location and Privacy

Useful documentation does not require exposing private addresses. For most public notes, use a general location description.

Usually okay for public notes

• Town or neighborhood.
• General landmark area.
• “Near Mount Tom,” “downtown Westfield,” or “Springfield riverfront.”
• “Residential window,” “tree-mounted,” “vehicle roof,” or “library parking lot.”

Avoid unless clearly intentional

• Exact home addresses.
• Private property coordinates.
• Someone else’s workplace or residence.
• Photos that reveal private details unintentionally.

The goal is to understand coverage and infrastructure without making people uncomfortable or exposing more than necessary.

Node Documentation Template

Use this as a starting point for Discord posts, GitHub notes, local files, or project documentation.

MeshCore Notes

For MeshCore devices, it is helpful to record the role clearly. A companion device, repeater, observer, and room server do not all do the same thing.

• Device name used on the mesh.
• Device model, such as Heltec, Wio Tracker, or SenseCAP Solar Node.
• Role, such as companion, repeater, observer, or room server.
• Firmware build or version, if known.
• Frequency, spreading factor, bandwidth, and coding rate, if relevant.
• Public ID or key only if it is appropriate to share.
• Observed logs, reachable nodes, or coverage notes.

For public-facing pages, avoid getting too deep into backend services. People usually need to know what the node does, where it generally helps, and whether it is currently useful.

Meshtastic Notes

For Meshtastic devices, useful notes may include the device model, region, channel settings, antenna, placement, role, and whether it is portable or fixed.

• Device model and firmware version.
• Region and channel settings, if appropriate to share.
• Role: client, router, repeater, or other.
• Antenna and power setup.
• General operating area.
• Known nodes heard or reached.

Be thoughtful about privacy settings and public maps. Not every device needs to expose its exact location.

Photos

Photos can help a lot, especially for antennas, mounting, field tests, and hardware setups. They also need a little care.

Useful photos

• Device on a workbench.
• Antenna setup.
• Solar or battery setup.
• General field test location.
• Public hilltop, park, or terrain view.

Before posting

• Check that the photo does not reveal private addresses.
• Remove location metadata when needed.
• Avoid showing keys, passwords, private screens, or personal details.
• Use a general caption that explains why the photo matters.

A good photo should help someone understand the setup, not expose more information than intended.

Maintenance Notes

Fixed infrastructure needs occasional checking. A node that was working last month may not still be working now.

• Last date checked.
• Battery or power status.
• Weather damage or mounting issues.
• Firmware changes.
• Antenna changes.
• Observed traffic or lack of traffic.
• Anything that needs repair, replacement, or retesting.

Maintenance notes help prevent “mystery infrastructure” where nobody knows what is still online, who maintains it, or what changed.

Sharing Node Notes

Node notes can be shared in Discord, kept in GitHub documentation, added to local files, or summarized on public coverage pages.

Keep public notes readable. Deep technical logs are useful, but most visitors need a plain summary first: what the node is, what role it plays, and whether it helps the local network.

Good First Goals

• Write a short note for one device you already use.
• Add the model, role, antenna, power, and general location.
• Record the last time it was checked.
• Share one useful coverage result.
• Take one safe, non-private photo of the setup.
• Update the note when the device moves or changes firmware.

Start with simple notes. Documentation can get more detailed as the network grows.