Contribute data

Turn your repeater into a network observer

The analyzer and the explorer are only as good as the data they are given. An observer node reports what it hears over WiFi, so the whole region gets a clearer picture of the mesh than any single node could see on its own.

Open the observer flasher Read the full documentation

Two routes

Pick the one your hardware allows

Both end with the same thing: your node reporting to our collector, authenticated with the key MeshCore already gave it. They differ in what has to be true of your board and your site.

Method A · Recommended

Observer firmware on the node

One ESP32 board does everything: it repeats, and it uplinks over its own WiFi. Nothing else to run. Needs a supported board and WiFi at the site.

You are on this page ↓

Method B · Advanced

Bridge it with meshcoretomqtt

A repeater stays wired by USB to an always-on Raspberry Pi or server, which does the publishing. Works with any board, including the nRF52 ones that have no WiFi at all.

Read the bridge walkthrough→

Read this first

An observer is a hungrier node than a repeater

Two things decide whether an observer is worth putting up. Neither is about the radio, and both are much easier to sort out before you flash than after the node is on a mast.

Constant power, not a battery budget

An observer keeps WiFi associated and an MQTT connection open around the clock. That is a completely different power profile from a plain repeater, which spends most of its life with the radio idle. Mains power is the right answer. If it has to be solar, size the panel and pack well beyond what the same board needed as a repeater, and assume several cloudy days.

Strong WiFi where the node actually lives

Marginal WiFi is worse than none. The node spends its time reconnecting instead of reporting, which burns more power than a healthy link and leaves gaps in the data. Check the signal at the mount point, not at the desk you configured it on, and add an access point or a directional link if the site is out at the edge of coverage.

If in doubt, don't convert your only repeater

A node that browns out overnight helps nobody, and a repeater that goes quiet takes its coverage with it. If a site is on a tight power budget, leave it as a repeater and put the observer somewhere with a wall socket and a good access point instead.

What an observer actually contributes

An observer is an ordinary MeshCore repeater running firmware with an MQTT bridge added. It keeps repeating exactly as before. The difference is that everything it hears, packets, signal quality, and its own health, is also published over your WiFi to a collector.

We run one at obs.comchan.net. It feeds the analyzer and the explorer, which is what turns a pile of individual receptions into coverage maps, link quality history, and an honest answer to “is this repeater actually being heard?”

You are not handing over credentials

Our broker authenticates with the Ed25519 keypair MeshCore already generated for the device. The firmware signs a token with the node's own private key, which never leaves the board. There is no account to create, no password to invent, and nothing for us to leak.

What gets published

Packet metadata and radio characteristics, not message contents. MeshCore's end-to-end encryption is unaffected by any of this, an observer sees the same ciphertext every other node on the mesh sees.

Link quality, measured

SNR, RSSI, and hop counts from a fixed, known point. That is what makes the analyzer's per-link numbers trustworthy rather than anecdotal.

Coverage that reflects reality

Every reception is a data point saying two places can hear each other. Enough of them and the explorer's maps stop being predictions.

Gaps you can point at

Observers spread across the region show where the mesh thins out, which is how we decide where the next repeater does the most good.

Top contributors

Who is feeding the network right now

The observers carrying the most traffic across the four Texas metros CoreScope tracks. If your node is not on here yet, the rest of this page is how it gets there.

Loading the current standings from the analyzer…

The data belongs to everyone who feeds it

Contributing is not a one-way transaction. Everything the observers above uplink is offered straight back out on a public broker, so you are not handing your data to us so much as pooling it with everybody else's.

Subscribe and you get the same live firehose the analyzer and explorer are built on. Build your own map, run your own analysis, wire it into Home Assistant, or just watch the mesh scroll past. No account, no application, no key to request.

What comes down the wire

Topics follow the shape below, so a metro is one wildcard away and a single node is two. status is each observer checking in with its health; packets is the live traffic, one message per packet heard, with the RF characteristics attached.

Connection details

Broker: mqtts://mqtt.comchan.net:8883
Username: mc_uplink
Password: mc_uplink
Topics: meshcore/{IATA}/{PUBLIC_KEY}/{type}

Those credentials are not a secret, they are the same for everyone and they are published here on purpose. They are read-only, the broker rejects any attempt to publish with them, so nobody can use them to put words in a node's mouth. TLS is required, it does not listen in the clear.

Try it in one line

Anything that speaks MQTT works. With mosquitto installed:

mosquitto_sub -h mqtt.comchan.net -p 8883 \
  --capath /etc/ssl/certs \
  -u mc_uplink -P mc_uplink \
  -t 'meshcore/#' -v

Narrow it to your own metro with -t 'meshcore/AUS/+/packets', or point a desktop client like MQTTX at the same broker if you would rather click around than pipe JSON.

Hardware

Devices that can run it

The observer firmware needs WiFi, so every supported board is ESP32-family. These three are the ones worth reaching for first, and they are far from the whole list.

Heltec V3 / V4

The boards most people on this mesh already own, and between them the most common observers on the network. Cheap, well supported, and the easiest to source. The V4 expansion-kit and OLED variants are all covered too.

RAK 3112

ESP32-S3 in the RAK ecosystem, so it drops straight into WisBlock enclosures and mounts you may already be running.

XIAO S3 WIO

Very small and inexpensive. A good pick when the observer has to tuck into a case that was never sized for it.

Plenty more are supported, Station G2 and G3, the Heltec Wireless Trackers, LilyGo T3 S3 and T-Beam, the Elecrow ThinkNode M7, and others. See the full device list on the flasher↗, which is the authority on what any given build actually supports.

nRF52 boards need the other method

A RAK WisBlock 4631, a XIAO nRF52, or a WisMesh Tag has no WiFi radio, so there is no observer firmware for it. They are not ruled out as observers, though, they just cannot do the uplinking themselves, bridge one from a Raspberry Pi instead.

Some boards need the merged firmware first

A few targets change the partition layout, and their first observer flash has to be the -merged.bin image so the bootloader and partition table are written together. Expect that flash to wipe stored settings, including WiFi and your node name. The documentation↗ lists which boards this applies to.

Walkthrough

Flash it, then point it at us

Everything below happens in a browser and a console. No toolchain, no build environment, and nothing to install.

01
Flash the observer firmware
Flashing uses the Web Serial API, so you need Chrome or Edge on a desktop. Phones and Safari cannot do it. Connect the board with a USB data cable, not a charge-only one, and make sure the antenna is attached before it powers up.
1. Open the MeshCore Observer Flasher↗ and make sure MQTT Observer Firmware is selected.
2. Pick your board from the device list, using the filter box if it is a long one.
3. Choose the Repeater role. Pick Room Server only if you also want this node hosting a chat room.
4. Leave the version on the current release, the one without a -dev suffix.
5. If you are converting a node that is already on the mesh, leave Erase device unchecked so it keeps its identity and settings.
6. Click Flash!, grant serial access when the browser asks, and leave it connected until it reports Flashing complete.
02
Open a console to the device
Every setting below is one console command. There are two ways in, and they accept exactly the same commands, so use whichever suits where the node is sitting.
Over USB
Click Console in the flasher header to open a serial console at 115200 baud over the cable you just flashed with. This is the one that always works, including when WiFi is misconfigured.
From the app
In the MeshCore app, open the node from your contact list, log in to Repeater Admin with its admin password, and use the Command Line tab. Handy once the node is already mounted.
03
Set the radio parameters
Only needed after a fresh flash or a full erase. If you left Erase device unchecked on an existing node, it already has these and you can skip straight to the next step.
```
set radio 910.525,62.5,7,5
set tx 22
```
The format is set radio <freq_MHz>,<bw_kHz>,<sf>,<cr>. These have to match the rest of the mesh exactly or the node hears nothing, so confirm the current values in the group before you commit to them, they are a property of the network rather than a choice you make per node.
04
Name the node and set its region code
The name is what identifies your observer in the analyzer, so make it something you will recognise in a list. The IATA code is the nearest airport, and it forms part of the MQTT topic the data is published under, AUS for Central Texas.
```
set name MyObserver
set mqtt.iata AUS
```
set name sets the MQTT origin at the same time, so there is nothing else to configure for identity.
05
Give it WiFi credentials
This is the uplink. The value is everything after the first space, so spaces in an SSID or password are fine.
```
set wifi.ssid YourWiFiNetwork
set wifi.pwd YourWiFiPassword
```
Do not put quotes around either value. They are stored literally and the node will fail to associate with a network whose name it thinks contains quote marks. The SSID maxes out at 31 characters and the password at 63. For an open network, type set wifi.pwd with a trailing space and nothing after it.
06
Point a broker slot at Comchan
This is the step that sends the data to us. The firmware ships presets for a long list of community brokers, but ours is not one of them, so the slot is configured as a custom broker instead.
```
set mqtt2.preset custom
set mqtt2.server wss://obs.comchan.net:443
set mqtt2.audience obs.comchan.net
```
The third line is the one that matters most. Setting audience switches the slot from username-and-password authentication to Ed25519 JWT, which means the device signs in with the keypair MeshCore generated for it. That is why there is nothing here for you to fill in, no credentials are issued and none are stored on the board.
Why slot 2
Fresh installs put analyzer-us in slot 1 and analyzer-eu in slot 2. The European one is no use from Texas, so slot 2 is the one to take. It also keeps you inside the limit that matters: boards without PSRAM support only two encrypted broker connections at once, because each one needs its own TLS stack. Slot 1 plus us is exactly two, which fits every board on the list above. Adding a third on a non-PSRAM board typically fails the connection rather than telling you clearly, so check get mqtt.status for any slot marked (inactive) if you go further.
07
Set the timezone, then reboot
Optional but worth doing, it makes the device's own logs readable. Published timestamps are always UTC regardless of what you set here.
```
set timezone America/Chicago
reboot
```
The reboot is not optional. Radio and WiFi settings are stored when you enter them but only applied on restart. After it comes back up it should associate with WiFi on its own and start uplinking.
08
Confirm it is actually reporting
Run these once the node has been up for a minute or two. Working through them in order tells you exactly where a problem is, WiFi first, then the broker.
```
get wifi.status
get mqtt.status
get mqtt2.preset
get mqtt2.server
get mqtt.iata
get bridge.enabled
```
get wifi.status reports the connection state, IP address, and RSSI. If that RSSI is weak, fix the WiFi before you look at anything else, the disclaimer at the top of this page exists because that is the most common reason an observer underperforms. get mqtt.status then shows each slot's connection state, which is where you will see our broker come up.
Once it is reporting, your node should start appearing in the analyzer. If it does not, say so in the group with the output of those two commands and somebody will recognise the symptom.

There is a great deal more this firmware can do

Per-broker packet filters, a browser-based configuration portal, neighbour discovery, SNMP monitoring, receive-only mode for nodes that should not forward, and the full CLI reference are all documented upstream. The walkthrough above is the short path to a working observer, not the whole surface.

Read the full documentation

Not sure your site can support one?

Ask before you flash. Power budget and WiFi reach are the two things worth talking through with somebody who has already done it, and they are much cheaper to get right on the bench than on a ladder.

Ask the group Set up the repeater first