📡 HAMPDEN COUNTY MESH NETWORK
Guides / Mesh Networking

Nodes, Repeaters, and Observers

Mesh networks are easier to understand when the different device roles are separated clearly. A handheld node, a fixed repeater, an observer, a room server, and an MQTT uplink may all support the same community, but they do not all do the same job.

This page is a practical orientation guide. It is not a complete setup manual and it should not replace current MeshCore, Meshtastic, FCC, device, or regional community documentation.
Quick Summary Nodes Repeaters Observers Regional Settings Privacy

Quick Summary

Node

A device that participates in the mesh. It may be handheld, portable, vehicle-based, fixed indoors, or fixed outdoors.

Repeater

A fixed or semi-fixed device that forwards mesh traffic and helps extend usable RF coverage.

Observer

A device or system that listens and reports what it hears. It helps with visibility, maps, logs, and analysis, but does not automatically improve RF coverage.

MQTT Uplink

A bridge from local observed mesh traffic into web tools, dashboards, analyzers, or maps. It is for visibility, not a substitute for better repeater placement.

Nodes

A node is any device participating in a mesh network. In casual conversation, people may call almost any MeshCore or Meshtastic device a node, but the role matters.

Portable nodes

Portable nodes are carried, moved around, used during testing, or kept with a person. They are useful for learning, messaging, checking coverage, and finding out what can be heard from real places.

Portable nodes are not usually the backbone of a regional network because they move, go offline, run out of battery, or sit indoors where RF performance may be poor.

Fixed nodes

Fixed nodes stay in one place. They may be indoors near a window, outdoors on a mast, mounted at a workplace, installed at a volunteer site, or placed temporarily for a field test.

Fixed nodes are easier to document and compare over time. If a fixed node has good height, power, antenna placement, and reliability, it may become useful infrastructure.

Repeaters

A repeater is a mesh device whose job is to forward traffic. In MeshCore, this distinction matters because normal clients do not repeat traffic. Repeaters and room servers with repeat enabled are the devices that forward traffic.

A useful repeater is usually less about raw transmit power and more about placement. Height, antenna choice, coax loss, surrounding terrain, and stable power often matter more than simply turning power up.

Good repeater traits

  • High or clear placement
  • Reliable power, ideally with battery backup or solar where appropriate
  • Weather protection for outdoor installs
  • Antenna matched to the intended coverage area
  • Known firmware version and settings
  • Documented general location without exposing private addresses
  • Owner or maintainer who can update, reboot, or troubleshoot it

Repeater placement

Repeaters are most useful when they are placed where many other nodes can hear them. A repeater deep inside a building may work locally, but it may not help the wider area. A modest repeater on a good hill, ridge, tower, roofline, or clear window may outperform a more powerful device in a poor location.

Repeater path hash notes

MeshCore firmware 1.14 and newer supports 1-byte, 2-byte, and 3-byte path hashes. Longer path hashes help analyzers and mapping tools tell repeaters apart more reliably. This is especially useful when different repeaters would otherwise collide or look similar because only a short part of the public key is being shown.

For repeaters running current firmware, using 2-byte or 3-byte adverts can be a good regional practice. The CLI setting is: 

set path.hash.mode 1

That sets repeater adverts to 2-byte path hash mode. Using: 

set path.hash.mode 2

sets repeater adverts to 3-byte path hash mode. This setting controls the repeater’s own advert path hash size. It does not decide which packets a firmware 1.14+ repeater forwards.

Practical starting point: for a regional repeater, 2-byte adverts are a reasonable first choice when the device is on firmware 1.14 or newer. Moving companion messages away from 1-byte should be a regional decision, because older repeaters may silently drop larger-path packets.

Observers

An observer listens for mesh traffic and reports or records what it can hear. Observers are useful for logs, analyzers, live maps, coverage notes, packet visibility, and understanding whether nearby activity exists.

An observer does not automatically make the radio network stronger. If an observer only listens and reports data to a website, it improves visibility, not RF coverage.

What observers are good for

  • Showing recently observed activity
  • Helping confirm whether a test message was heard
  • Feeding analyzer or map tools
  • Supporting coverage reports and field testing
  • Documenting whether activity exists in a general area

What observers are not

  • They are not automatically repeaters
  • They are not proof of complete coverage
  • They do not show every private or independent node
  • They should not be used to expose exact private locations

Room Servers, Hubs, and MQTT Uplinks

Some mesh systems can connect to supporting services. These services may provide logging, analyzer feeds, web maps, room-server behavior, dashboards, or other tools.

Room servers

A room server is a shared message or bulletin-board style service available to compatible MeshCore clients. Depending on configuration, room servers may also be able to repeat traffic.

Meshcore-Hub style systems

A local Linux system can be used as supporting infrastructure. It may store logs, run scripts, host local services, collect observer output, test MQTT, generate status files, or prepare data for the public website.

MQTT uplinks

MQTT uplinks are best understood as reporting paths into tools, not as magic coverage extenders. A fixed node or observer may report local traffic into a broker so that analyzers, maps, and dashboards can show what was heard.

If the RF side of the network cannot hear an area, an MQTT dashboard may still show useful information from other places, but it does not replace the need for good repeater placement, antennas, and field testing.

Regional MeshCore Settings Notes

Regional settings should be verified before flashing or reconfiguring devices. MeshCore, nearby communities, and local practice can change over time.

Common nearby MeshCore settings

Nearby MeshCore communities commonly reference the USA/Canada recommended preset. Greater Boston Mesh currently lists: 

Preset: USA/Canada (Recommended)
Frequency: 910.525 MHz
Bandwidth: 62.5 kHz
Spreading Factor: 7
Coding Rate: 5

These settings are useful regional context for Hampden County because local activity may overlap with the broader New England mesh environment. Still, verify current settings before changing a working node.

BDL / Windsor Locks regional context

Hampden County activity may be seen as part of the wider BDL / Windsor Locks regional environment, especially when using regional analyzers, MeshMapper-related tools, or nearby community infrastructure.

This does not mean every observed node is operated by Hampden County Mesh. It means Hampden County is part of a wider regional RF and mapping picture.

Companion node caution

Companion nodes should generally stay on settings that match the regional mesh. If most regional repeaters are not confirmed to support newer path-hash behavior, avoid changing companion message path hash size just because a repeater advert setting was changed.

Useful external references

Coverage vs. Visibility

A repeater can improve RF coverage by forwarding traffic over the air. An observer or MQTT uplink can improve visibility by showing what was heard. These are both useful, but they are different jobs.

Improves Coverage

Good repeater placement, better antennas, height, clear paths, and reliable power can help more nodes reach each other over RF.

Improves Visibility

Observers, logs, analyzers, dashboards, MQTT uplinks, and maps help people understand what was heard or reported.

Privacy and Public Notes

Public infrastructure notes should be useful without exposing private homes, exact coordinates, credentials, private keys, Wi-Fi details, or information someone did not agree to share.

Safe public notes

  • Town or general area
  • Public landmark or broad terrain description
  • Device role, such as portable node, repeater, or observer
  • General antenna type
  • Firmware family or major version when useful
  • Whether the node is fixed, mobile, temporary, or experimental

Avoid publishing

  • Exact home addresses
  • Private node coordinates without permission
  • Private keys
  • Admin passwords or broker credentials
  • Private IP addresses or Wi-Fi details
  • Photos that reveal a private location unintentionally

How to Describe a Setup

A useful node or repeater note does not need to be complicated. The goal is to help others understand what role the device plays and what it may contribute to the area. 

Role: Repeater / Observer / Portable node / Fixed node
System: MeshCore / Meshtastic / Other
General area: Town, neighborhood, landmark, or broad region
Frequency/preset: If known and safe to share
Antenna: Type, placement, and approximate height
Power: USB, battery, solar, wall power, backup power
Firmware: Version or approximate date, if known
Status: Testing, active, temporary, offline, planned
Notes: What it hears, what it reaches, or what it is meant to support

For public reports, general descriptions are often enough. More exact details can be shared privately with trusted infrastructure maintainers when needed.