MeshCore: Difference between revisions
No edit summary |
|||
| (50 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
MeshCore | == MeshCore == | ||
As we gather more tips, we'll reformat this page to be more cogent. | As we gather more tips, we'll reformat this page to be more cogent. | ||
If you want to know about LoRa radio things, go [[Mesh_Networks|here]]. | |||
MeshCore is an open source mesh network that runs on top of [[Mesh_Networks|LoRa radio technology]]. It is low bandwidth and only suitable for text messaging. It is also very low power and long range (10's of miles) line-of-sight. It is different from [[Meshtastic]] in that it relies on dedicated repeater hardware. This hardware is still owned by individuals and deployed as they see fit. Because Meshcore repeaters are dedicated devices they tend to stay in one place and can be used to route messages instead of always flooding a message. | |||
There is a Python version that runs on RPi class hardware. Called [https://docs.openhop.dev/projects/openhop-core/ OpenHop] | |||
== Documentation == | == Documentation == | ||
* [https://meshcore. | * [https://meshcore.io Official MeshCore site] | ||
* [https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md The official FAQ] is very informative | |||
* A good [https://www.73mesh.com/2025/11/19/RoomServers.html overview of room servers] and MeshCore in general. | * A good [https://www.73mesh.com/2025/11/19/RoomServers.html overview of room servers] and MeshCore in general. | ||
* [https://deepwiki.com/meshcore-dev/MeshCore The Deep MeshCore Wiki] | * [https://deepwiki.com/meshcore-dev/MeshCore The Deep MeshCore Wiki] | ||
* [https://swaits.github.io/meshcore-spec/latest/ Protocol Specification] | |||
* [https://analyzer.letsmesh.net/observer/onboard?type=companion Observer Nodes] feed the analysis sites | * [https://analyzer.letsmesh.net/observer/onboard?type=companion Observer Nodes] feed the analysis sites | ||
* [https://zindello.com.au/meshcore-regions-what-they-are-how-they-work-and-why-they-matter/ Regions: What they are and how they work] | |||
== Community == | |||
* [https://discord.gg/WPZPFE86 Bay Area Discord Server] has a lot of good dialog and help | |||
== Live Analysis == | == Live Analysis == | ||
| Line 23: | Line 39: | ||
== Misc Info == | == Misc Info == | ||
=== Random Things === | |||
: If your clock is off try '''clock sync'''. If it complains about "going backwards" then to '''clkreboot''' and then '''clock sync'''. | |||
=== Radio Tips === | |||
Read our [[Mesh_Networks|tips here.]] | |||
=== Hardware === | |||
==== Station G2 ==== | |||
Transmit power of 10 = 1 watt | |||
If the G2 experiences a brief power outage it will come back in a low power state (all the LEDs are not lit up). Power it down for 60 seconds or so, then power it up. | |||
The G2 pulls a lot of power. Make sure you have a USB power supply that can supply the current - the inexpensive ones will not and the three LEDs will not light up, showing that the power amplifier is not working. | |||
Update a G2 over WiFi: | |||
1) download the non merged firmware binary on your phone or computer. Do this with [https://flasher.meshcore.io flasher.meshcore.io] | |||
2) connect to a companion and then log in to the repeater via the mesh | |||
3) open the command line and type "start ota" - note the web address provided. The G2 will become a WiFi access point. | |||
4) on phone or computer, connect to the Meshcore-OTA wifi | |||
5) use a browser to go to the provided web address from step 3 | |||
6) choose the binary file downloaded in step 1 - it will reboot automatically | |||
==== Heltec V4 ==== | |||
Transmit power of 22 = 650 mW | |||
The V4 doesn’t reboot after losing power without a physical reset button press. | |||
Make sure you have a USB power supply that can supply the current - the inexpensive ones will not. You won't know it, but you won't be transmitting at 650 mW. You can see this yourself with a USB current monitor. Hook it up and then send a message. You should see the current jump up considerably. If not, your power supply is not strong enough. | |||
=== Repeaters === | |||
: Adverts are sent by repeaters just to help the analysis of the mesh. We could have the entire mesh set up without repeater adverts and it would work fine. | |||
: You used to worry about using the same key prefix of someone near you. You would admin via your companion to set an unused prefix. [https://analyzer.letsmesh.net/nodes/prefix-utilization Prefix Utilization grid]. But router prefix collisions do not affect message delivery, just the effectiveness of off-line mesh analysis. So it was polite to pick an unused prefix. | |||
: As of 1.14 multi-byte path support makes this unnecessary. Instead, use any two digit prefix you want to generate your repeater's keys. Connect to your repeater and '''set path.hash.mode 1''' | |||
: (Leave your companion at the default 1-byte support until all the routers in your area are up on 1.14 or later.) | |||
: set advert.interval 240 (for 0 hop adverts, in minutes) | |||
: set prv.key <key> | |||
: set owner.info <info> | |||
: for a G2 - set agc.reset.interval 4 | |||
: Paths both ways get cached and if a route is bad you might get a message to the destination but the ack may not get back. If you have a repeater you own in the path force a flood by hard pressing the logon button. The path back might still be wrong so go to the console and send “reboot” 3 times … you don’t need a confirmation just spam it 3 times | |||
: Outdoor node. [https://store.rokland.com/products/wismesh-repeater-mini-reliable-coverage-expansion-for-smart-networks This is a nice one.] | |||
: Duty Cycle. Can be set in 1.16+. After each transmission, the repeater enforces a silent period proportional to the on-air time. You are responsible for choosing a value appropriate for your jurisdiction (e.g. EU 868 MHz requires 10% duty cycle). | |||
: set dutycycle 80 | |||
: Loop Prevention. If a path has a loop in it (1a, e6, 9f, e6, 9f, 2c) messages loop around. In single byte paths this kind of thing might be legitimate because different routers could have the same byte id. Going to two or three byte path modes makes these collisions unlikely. Repeaters can be set to stop loops with loop.detect. The values show how many times a given id is allowed in a path. For example, minimal allows 4 duplicates in a 1-byte path, 2 duplicates in a 2-byte path, and no duplicates in a 3-byte path: minimal is 4,2,1; moderate is 2,1,1; strict is 1,1,1. | |||
: set loop.detect moderate | |||
==== About Two Byte Routing ==== | |||
[https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md#39-q-what-is-multi-byte-support--what-do-1-byte-2-byte-3-byte-adverts-and-messages-mean the FAQ] | |||
With one byte routing a big network will have repeaters with duplicate ids. This makes offline analysis of the mesh very difficult. It can also lead to a bit higher mesh utilization because a router that shares an id with a router in the path will also repeat the message, but that is a marginal improvement. [https://github.com/meshcore-dev/MeshCore/blob/main/docs/faq.md#36-q-the-first-byte-of-my-repeaters-public-key-collides-with-an-exisitng-repeater-on-the-mesh--how-do-i-get-a-new-private-key-with-a-matching-public-key-that-has-its-first-byte-of-my-choosing see the FAQ] | |||
If your companion is set for two byte routing and the message hits a repeater that is not up on 1.14 then that repeater will not forward your message. Once your area's repeaters are up on 1.14 then you can move your companion to multibyte. | |||
=== Companion === | |||
: Hold down on a message and find the "heard repeats" button, it will give you more info what repeaters it hit | |||
: Seems a lot of folks turn off auto-add contacts and just add devices out of the discovery tab manually. Some leave on auto add Repeaters so that they will show up in the application map. | |||
Are you connecting to the mesh? | |||
: Receiving: Tools > Rx Log will show messages coming to you. | |||
: Transmitting: To see if you make it to the mesh, add the #test channel. Post a message and look for the number of repeaters. Also try posting !path and look for a pathbot to reply. | |||
Traceroute | |||
: Only works to repeaters. | |||
: Tools > Trace Path - Using Map Select repeaters by tapping on them. Your companion has to hear from the last one in the path so you might tap on the same nodes to make the path go out and back. | |||
Remotely connect to a repeater: Tap the repeater in your contacts list. Long press the connect button and select Flood. | |||
Regions | |||
: open a channel convo > 3 dots > set region scope > 3 dots > discover regions | |||
==== Staleness ==== | |||
Staleness is based on last heard — the most recent time any traffic was seen from that node (not just adverts). | |||
Thresholds: | |||
{| class="wikitable" | |||
|- | |||
! Role !! Goes "stale" after | |||
|- | |||
| Repeater || 72 hours | |||
|- | |||
| Room Server || 72 hours | |||
|- | |||
| Companion || 24 hours | |||
|- | |||
| Sensor || 24 hours | |||
|} | |||
Visual cues: | |||
* Nodes list: green dot → white dot, label changes from "Active" to "Stale" | |||
* Static map: full color → grayed out (70% opacity + grayscale) | |||
* Live map: full color → heavily dimmed (opacity 0.25) | |||
Repeaters advertise every 12-24h, so 72h allows several missed cycles before flagging. Companions/sensors get | |||
24h since they go quiet more often by design. | |||
=== Observer === | |||
Help the analysis of the mesh by dedicating a device to being an Observer. | |||
Use a Heltec v3 [https://www.lorameshdevices.com/blog/meshcore/how-to-build-a-meshcore-observer-with-heltec-v3.html to be an Observer] | |||
=== War Driving === | |||
Download the MeshMapper app on your phone. | |||
Make sure your radio has joined #wardriving unless you want repeater discovery only. | |||
== Unexplained Things == | |||
None at this time. Add an item if you can't find the answer. | |||
== Open Questions == | |||
* Ping Warning | |||
: You know 2 repeaters or room servers with prefix <61>. Unfortunately we won't know which of them replies to this ping request. Dismiss/Confirm. | |||
: This means that the companion can't be sure if the ping actually makes it to the repeater the user intends to test. Suppose you want to ping a repeater on your map to see if you can reach it. You send the ping to <61> and perhaps a different repeater that also uses <61> replies first. Your companion thinks the target repeater is directly reachable, but this test has not proven that. | |||
* Repeater Clock | |||
: The clock resets after each reboot. (verified on my G2 and my RAK Wisblock) | |||
: Login remotely and in the repeater settings -> Sync Clock | |||
:: on the Wisblock it worked | |||
:: on the G2 the time was displayed wrong in the status page but the Sync Clock command thought it was ok | |||
== Other Experiments == | |||
Sydney. Busy mesh. Something like 1300 nodes, and they seem to be doing well getting repeaters on top of tall buildings. They split into two presets 775kHz apart, one 62.5/SF7 and the other 250/SF11, and bridge between them, though it looks like the "narrow" is predominant. They have a txdelay scheme that groups repeaters by peer count and recommends different delay factors according to how well connected a node is and whether it bridges regions or just local area. When more info is available we will update this section (or remove it). | |||
Latest revision as of 11:09, 18 July 2026
MeshCore
As we gather more tips, we'll reformat this page to be more cogent.
If you want to know about LoRa radio things, go here.
MeshCore is an open source mesh network that runs on top of LoRa radio technology. It is low bandwidth and only suitable for text messaging. It is also very low power and long range (10's of miles) line-of-sight. It is different from Meshtastic in that it relies on dedicated repeater hardware. This hardware is still owned by individuals and deployed as they see fit. Because Meshcore repeaters are dedicated devices they tend to stay in one place and can be used to route messages instead of always flooding a message.
There is a Python version that runs on RPi class hardware. Called OpenHop
Documentation
- The official FAQ is very informative
- A good overview of room servers and MeshCore in general.
- Observer Nodes feed the analysis sites
Community
- Bay Area Discord Server has a lot of good dialog and help
Live Analysis
- Analyzer 00id Map of Nodes and other things.
- Analyzer LetsMesh Another map of nodes and other things
- Baus Meshmapper San Francisco Bay Area
Misc Info
Random Things
- If your clock is off try clock sync. If it complains about "going backwards" then to clkreboot and then clock sync.
Radio Tips
Read our tips here.
Hardware
Station G2
Transmit power of 10 = 1 watt
If the G2 experiences a brief power outage it will come back in a low power state (all the LEDs are not lit up). Power it down for 60 seconds or so, then power it up.
The G2 pulls a lot of power. Make sure you have a USB power supply that can supply the current - the inexpensive ones will not and the three LEDs will not light up, showing that the power amplifier is not working.
Update a G2 over WiFi:
1) download the non merged firmware binary on your phone or computer. Do this with flasher.meshcore.io 2) connect to a companion and then log in to the repeater via the mesh 3) open the command line and type "start ota" - note the web address provided. The G2 will become a WiFi access point. 4) on phone or computer, connect to the Meshcore-OTA wifi 5) use a browser to go to the provided web address from step 3 6) choose the binary file downloaded in step 1 - it will reboot automatically
Heltec V4
Transmit power of 22 = 650 mW
The V4 doesn’t reboot after losing power without a physical reset button press.
Make sure you have a USB power supply that can supply the current - the inexpensive ones will not. You won't know it, but you won't be transmitting at 650 mW. You can see this yourself with a USB current monitor. Hook it up and then send a message. You should see the current jump up considerably. If not, your power supply is not strong enough.
Repeaters
- Adverts are sent by repeaters just to help the analysis of the mesh. We could have the entire mesh set up without repeater adverts and it would work fine.
- You used to worry about using the same key prefix of someone near you. You would admin via your companion to set an unused prefix. Prefix Utilization grid. But router prefix collisions do not affect message delivery, just the effectiveness of off-line mesh analysis. So it was polite to pick an unused prefix.
- As of 1.14 multi-byte path support makes this unnecessary. Instead, use any two digit prefix you want to generate your repeater's keys. Connect to your repeater and set path.hash.mode 1
- (Leave your companion at the default 1-byte support until all the routers in your area are up on 1.14 or later.)
- set advert.interval 240 (for 0 hop adverts, in minutes)
- set prv.key <key>
- set owner.info <info>
- for a G2 - set agc.reset.interval 4
- Paths both ways get cached and if a route is bad you might get a message to the destination but the ack may not get back. If you have a repeater you own in the path force a flood by hard pressing the logon button. The path back might still be wrong so go to the console and send “reboot” 3 times … you don’t need a confirmation just spam it 3 times
- Outdoor node. This is a nice one.
- Duty Cycle. Can be set in 1.16+. After each transmission, the repeater enforces a silent period proportional to the on-air time. You are responsible for choosing a value appropriate for your jurisdiction (e.g. EU 868 MHz requires 10% duty cycle).
- set dutycycle 80
- Loop Prevention. If a path has a loop in it (1a, e6, 9f, e6, 9f, 2c) messages loop around. In single byte paths this kind of thing might be legitimate because different routers could have the same byte id. Going to two or three byte path modes makes these collisions unlikely. Repeaters can be set to stop loops with loop.detect. The values show how many times a given id is allowed in a path. For example, minimal allows 4 duplicates in a 1-byte path, 2 duplicates in a 2-byte path, and no duplicates in a 3-byte path: minimal is 4,2,1; moderate is 2,1,1; strict is 1,1,1.
- set loop.detect moderate
About Two Byte Routing
With one byte routing a big network will have repeaters with duplicate ids. This makes offline analysis of the mesh very difficult. It can also lead to a bit higher mesh utilization because a router that shares an id with a router in the path will also repeat the message, but that is a marginal improvement. see the FAQ
If your companion is set for two byte routing and the message hits a repeater that is not up on 1.14 then that repeater will not forward your message. Once your area's repeaters are up on 1.14 then you can move your companion to multibyte.
Companion
- Hold down on a message and find the "heard repeats" button, it will give you more info what repeaters it hit
- Seems a lot of folks turn off auto-add contacts and just add devices out of the discovery tab manually. Some leave on auto add Repeaters so that they will show up in the application map.
Are you connecting to the mesh?
- Receiving: Tools > Rx Log will show messages coming to you.
- Transmitting: To see if you make it to the mesh, add the #test channel. Post a message and look for the number of repeaters. Also try posting !path and look for a pathbot to reply.
Traceroute
- Only works to repeaters.
- Tools > Trace Path - Using Map Select repeaters by tapping on them. Your companion has to hear from the last one in the path so you might tap on the same nodes to make the path go out and back.
Remotely connect to a repeater: Tap the repeater in your contacts list. Long press the connect button and select Flood.
Regions
- open a channel convo > 3 dots > set region scope > 3 dots > discover regions
Staleness
Staleness is based on last heard — the most recent time any traffic was seen from that node (not just adverts).
Thresholds:
| Role | Goes "stale" after |
|---|---|
| Repeater | 72 hours |
| Room Server | 72 hours |
| Companion | 24 hours |
| Sensor | 24 hours |
Visual cues:
- Nodes list: green dot → white dot, label changes from "Active" to "Stale"
- Static map: full color → grayed out (70% opacity + grayscale)
- Live map: full color → heavily dimmed (opacity 0.25)
Repeaters advertise every 12-24h, so 72h allows several missed cycles before flagging. Companions/sensors get 24h since they go quiet more often by design.
Observer
Help the analysis of the mesh by dedicating a device to being an Observer.
Use a Heltec v3 to be an Observer
War Driving
Download the MeshMapper app on your phone. Make sure your radio has joined #wardriving unless you want repeater discovery only.
Unexplained Things
None at this time. Add an item if you can't find the answer.
Open Questions
- Ping Warning
- You know 2 repeaters or room servers with prefix <61>. Unfortunately we won't know which of them replies to this ping request. Dismiss/Confirm.
- This means that the companion can't be sure if the ping actually makes it to the repeater the user intends to test. Suppose you want to ping a repeater on your map to see if you can reach it. You send the ping to <61> and perhaps a different repeater that also uses <61> replies first. Your companion thinks the target repeater is directly reachable, but this test has not proven that.
- Repeater Clock
- The clock resets after each reboot. (verified on my G2 and my RAK Wisblock)
- Login remotely and in the repeater settings -> Sync Clock
- on the Wisblock it worked
- on the G2 the time was displayed wrong in the status page but the Sync Clock command thought it was ok
Other Experiments
Sydney. Busy mesh. Something like 1300 nodes, and they seem to be doing well getting repeaters on top of tall buildings. They split into two presets 775kHz apart, one 62.5/SF7 and the other 250/SF11, and bridge between them, though it looks like the "narrow" is predominant. They have a txdelay scheme that groups repeaters by peer count and recommends different delay factors according to how well connected a node is and whether it bridges regions or just local area. When more info is available we will update this section (or remove it).
