Build the mesh

The bare minimum

This chapter covers the bare minimum to bring your own repeater online in Brussels: install the software in the device, a few settings, mount it by a window. Everything uses the MeshCore Web Flasher and Config Tool in the browser: a simple web interface, no console or deep technical knowledge required. To go further, see Advanced configuration below.

Advanced configuration

Reference settings for fixed nodes (repeater, room server) and the CLI console. Section to go further: not required for a first balcony relay if the bare minimum is enough. Settings aligned with Belgian community recommendations.

Filtering by region is detailed in the Regional filtering section. The region def / region default be commands in the repeater card below reflect our local consensus (firmware ≥ 1.16.0 required): region table (with be-wal), scope be, and above all allowf * so unscoped traffic keeps being relayed. Shareable summary: Latest changes.

Generate a public key

MeshCore identifies nodes partly by the first bytes of their public key. Never reuse the key of a node already in service on the mesh: choose a free prefix and a new key (see public key and path hash collisions), except for a deliberate migration to another device (see below). USB procedure:

1. Connect the repeater via USB and open the MeshCore Config Tool in Chrome or Edge (Web Serial required).
2. Click Connect and select the device's serial port.
3. In the vanity key generator, enter a lightly used hexadecimal prefix spotted in the collision tool (1 to 6 characters; 2 characters often suffice). Avoid prefixes starting with 00 or FF: they are reserved by MeshCore.
4. Start generation and wait until a matching key pair is found (local computation in the browser).
5. Apply the generated private key to the repeater: via the apply button in the tool, or in the console with set prv.key <128_character_private_key> (128 hex characters, no spaces or quotes).
6. Restart the repeater (Reboot in the tool or reboot in the console).
7. Verify that the displayed public key starts with the chosen prefix, then export the configuration (Export) to keep a backup.

Back up the repeater private key

The private key is the repeater's identity on the mesh: same display name, different public key = different node to the network, observers and online maps (see Resources).

If you flash new firmware or replace the board without re-importing the same private key, the repeater gets a new identity. The old key remains visible for a long time as a "ghost" entry: the original node no longer transmits, but observers and mesh history still keep its old public key. You end up with two points on the map for one physical site.

Good practice: after initial configuration, export the full configuration from the Config Tool (Export) or at minimum note the private key (128 hex characters), name, admin/guest passwords and, if applicable, GPS position. Keep this backup somewhere safe (password manager, encrypted vault).

On hardware replacement or reflash: reconnect via USB, Import the JSON backup or reapply the same private key (set prv.key <128_character_private_key>), reboot, then verify the public key matches the previous one. The repeater resumes the same mesh identity without leaving an old ghost node.

Generate a new key only if you install an additional repeater or if you deliberately accept changing the node identity (after checking collisions via the listed tool).

To choose and buy hardware, see Suggested hardware on Join.

Transmit power (TX)

The Flemish #BEmesh community often suggests reduced transmit power, typically 14–17 dBm (~25–50 mW), for example via set tx 17. This advice is documented in the #BEmesh configurator and Radio-Actief guides (see Resources).

In Flanders, the MeshCore mesh is more mature and has reached critical mass: enough neighbouring relays that lowering TX makes sense. Messages hop relay to relay; power that is too high increases interference without net range gain. There, this setting is relevant.

Why not apply it in Brussels today

In Brussels (BE-BRU), the mesh is still nascent (see Discover: And Brussels in all this?). The immediate challenge is to reach the next relay: difficult urban radio (concrete, slopes, Senne valley). At commissioning, keep the device default power (often ~22 dBm): do not copy set tx 17 by mimicking the Flemish preset.

2-byte path hash should be prepared early because future Brussels density is anticipated (see Path routing). TX follows a different timeline: lower it when current density justifies it, not before.

When Brussels reaches critical mass

When several repeaters are close (same neighbourhood, local interference, neighbourhood saturation), adopt the same discipline as Flanders: gradually lower emissions (14–17 dBm, adjust case by case). Useful commands: get tx to read the current value, set tx 17 then reboot to apply.

MeshCore operates in the ISM band with a legal ceiling of 500 mW ERP (27 dBm) on the sub-band used; actual power also depends on antenna gain.

Path routing and path hash

To reach a distant contact or node, MeshCore does not "know" an IP address: it remembers paths, i.e. the relay sequence a message successfully took. Your companion reuses that path until it fails; hence the usefulness of Clear Path in the app (see Join: First contact).

Path hash: short identifiers on the path

Each relay on the path is summarised by a path hash: a short identifier added to routing. Its size fixes the address space: the longer it is, the less likely two nodes share the same identifier.

• 1 byte: set path.hash.mode 0 (default): 256 possible values, roughly 1 in 256 chance a new identifier collides.
• 2 bytes: set path.hash.mode 1: 65,536 values, roughly 1 in 16,000.
• 3 bytes: set path.hash.mode 2: over 16 million values, even lower collision risk.

On a dense mesh like Brussels, 1-byte mode saturates quickly. We recommend 2 bytes on the repeater (set path.hash.mode 1, app label: Path hash mode) and 2 bytes in the companion's Network settings (Path hash size). See settings in Join the mesh and the companion Q&A.

Public key and path hash collisions

MeshCore identifies nodes partly by the first bytes of their public key. If several repeaters share the same hexadecimal prefix, maps, observers and analysis tools can confuse two distinct nodes: ambiguous paths, duplicate map entries, hard debugging. Before first commissioning, check which prefixes are already saturated on the mesh.

Two nearby repeaters with the same first byte of path hash (or colliding public key prefixes) can also disrupt routing and mesh maps. The two notions are linked: the public key prefix identifies the node, the path hash summarises it on mesh paths.

In the collision detection tool (Resources page), matrices show for each hash size (1, 2 or 3 bytes) which prefixes are free, lightly used or in collision. Look for an Available or One node cell rather than a collision cell. As we recommend a 2-byte path hash, pay particular attention to the 2-Byte matrix in addition to the 1-Byte matrix (which also reflects real conflicts observed in traffic).

Shortcut: path hash Q&A.

Room server

A room server is a fixed node that stores recent messages (up to 32) for authorised people: an asynchronous mailbox on the mesh. In the app, you join it like a contact with a password (often hello by default). See Join: Private channels and room server for companion-side usage.

Creation and configuration

1. Flash a device compatible with the room server role (same hardware base as a repeater; see hardware).
2. Connect via USB, open the MeshCore Config Tool and select the Room server preset (or equivalent depending on version).
3. Apply the radio settings as for a repeater (set radio 869.618,62.5,8,8, set path.hash.mode 1, etc.): the Advanced configuration section lists reference CLI commands.
4. Set an access password other than the default if the node is exposed.
5. Power the device from mains rather than battery: a room server cannot save energy like a repeater.

After commissioning, send a manual advert so the mesh knows the node, then set auto-advert intervals as for a repeater (see the Q&A "How often should my repeater advert?").

Regional filtering

MeshCore associates each message with a region (Brussels: be-bru, see the region configurator). On a repeater, whoever manages it defines the region tree and what is relayed for the whole neighbourhood; the recommended transmit scope remains be (Belgium) for now; switching to a region code (be-bru / be-wal) comes later.

Since 1 August 2026, the Flemish #BEmesh community has tightened messages without a region (unscoped). In Brussels, cutting unscoped too early breaks reach. Locally: region tree (including be-wal), repeater scope be, home be-bru (province in Wallonia), and above all allowf * + flood.max.unscoped 64.

Local consensus

On the repeater: region def tree (eu → bx → be → be-bru / be-vlg / be-wal…), region default be (Belgium; region/province later), region home be-bru (in Wallonia: province code), region allowf *, then region save. The critical point: keep relaying unscoped. Full CLI blocks by area: Advanced configuration and Catch-up.

Default stays be (Belgium) in Brussels and Wallonia; home is be-bru in Brussels and the province code in Wallonia. A packet that is already scoped is only relayed if the repeater has that region in its list, hence the region def tree (with be-wal).

We keep region allowf * and the default unscoped ceiling (set flood.max.unscoped 64). Unlike Flanders, we do not prescribe region denyf * or a low value like 5. See the flood unscoped Q&A.