Hampden County Mesh

MeshCore Basics

MeshCore is the main mesh system used by Hampden County Mesh. Learn how messages move, what the different node roles do, and where local activity can be viewed.

What MeshCore is

MeshCore is a lightweight messaging and packet-routing system for compatible LoRa radios. Devices can communicate directly or through fixed repeaters without depending on normal cellular service or an internet connection.

A basic setup can remain simple: one supported radio, companion firmware, a phone or computer, the correct antenna, and radio settings that match the regional mesh.

One companion radio is enough to begin. Ordinary companion devices do not repeat traffic for other users, so wider regional paths depend on separately operated repeater infrastructure.

How messages move

MeshCore uses both flooding and directed paths. The distinction helps it reach unfamiliar destinations without making every later message travel through every available repeater.

  1. Nearby radios may communicate directly. No repeater is needed when the two devices can already hear each other.
  2. A new direct message can begin as a flood. Repeaters help the first message find the destination when no known path is available.
  3. A successful delivery report helps establish a path. Path information returned with the report lets later direct messages follow a more selective repeater path rather than flooding the entire reachable mesh.
  4. Group-channel messages use flood routing. Channels do not have one defined destination, so repeaters forward them according to the limits and regional rules they are configured to use.

Flooding still happens entirely over the radio network. It does not mean the message is being carried through the internet.

Watch these steps happen in the interactive MeshCore simulator → Start with a first direct message, then compare the learned path with a channel flood.

MeshCore roles and supporting infrastructure

These roles and supporting systems serve different purposes. Treating them as interchangeable can lead to poor placement decisions or the assumption that every device improves coverage.

Start here

Companion

A personal radio connected to a phone or computer. It manages contacts, direct messages, channels, adverts, and normal day-to-day use.

Companion devices send and receive messages but do not relay ordinary traffic for the rest of the mesh.

Relay infrastructure

Repeater

A fixed radio that forwards eligible MeshCore packets and helps create paths between devices that cannot communicate directly.

Height, terrain, antenna quality, power, and placement matter more than simply adding another repeater at ground level.

Stored group messages

Room Server

A small bulletin-board-style server that stores room history so users can connect later and retrieve messages they did not hear live.

A room server serves a different purpose from a repeater. Separate devices are generally preferable for the two infrastructure roles.

Supporting integration

Observer

An observer setup reports activity heard by participating infrastructure to logging, mapping, or packet-analysis software.

Observation improves visibility into the mesh. It does not by itself improve the radio path between two devices.

In practical terms: companions are used by people, repeaters extend radio paths, room servers retain group posts, and observers help document what participating infrastructure hears.

Adverts and contacts

An advert announces that a node exists. Depending on the node and its configuration, an advert can include its name, public key, node type, and optional location information.

A zero-hop advert is heard only by radios that can receive it directly. A flood advert may be forwarded by repeaters, allowing the node to become visible across a wider portion of the mesh.

Companion applications use adverts to populate or refresh contacts. An advert is not itself a chat message, and seeing a contact does not guarantee that a working route currently exists.

Location included in a public advert may be displayed by compatible apps or mapping systems. Do not attach a precise private location unless you intentionally want to publish it.

MeshCore channels

Channels are used for group messages. All channel traffic uses flood routing because there is no single destination from which to learn a directed path.

Public
The built-in public group channel. Anyone using the standard public channel configuration can receive its messages.
Hashtag channels
Topic or regional channels such as #test. Their keys are derived from their names, so they should be treated as public rather than secret.
Private or shared-key channels
Channels created with a randomly generated secret. Anyone who has the channel name and secret can participate and read messages sent through that channel.

Local channel use

Use #test for routine test traffic where it is configured rather than repeatedly testing in the broad Public channel.

Current local channel conventions are kept in the HCM Discord so they can change without leaving obsolete channel instructions scattered across the website.

A channel name is not a geographic boundary

A town, county, or regional name helps organize conversation, but it does not physically confine radio traffic to that area. Repeaters may carry the channel beyond the place named in it.

Public and hashtag-channel messages should be written as though they may be received, logged, or repeated beyond the immediate local area.

Maps and observed activity

Hampden County Mesh operates public tools that display MeshCore activity heard through participating observer systems.

Observed activity is not a complete inventory of every MeshCore device in the region. A node must be heard by participating infrastructure, and usable location information must be available for it to appear geographically.

Seeing a node or path on a map also does not prove that your radio can reach it directly from its current location.

MQTT and personal nodes

HCM uses MQTT behind some observer, map, and analyzer systems. Normal MeshCore users do not need MQTT to send messages or participate through LoRa.

If a MeshCore device seems quiet

  1. Confirm that the regional frequency and modem settings match.
  2. Confirm that the correct companion firmware was installed.
  3. Make sure the correct antenna is attached securely.
  4. Check that the phone or computer remains connected to the companion.
  5. Leave the radio powered long enough to hear normal activity.
  6. Try a window, outdoor location, vehicle, or higher ground.
  7. Send or request an advert when appropriate.
  8. Change only one setting at a time while troubleshooting.
A visible contact may be old, and a quiet test location may simply have a poor radio path. Neither result alone proves that the device is defective.

Where to go next

Ask before you get stuck

Bring the device model, firmware version, antenna, current settings, general testing area, and a short description of what you already tried.