As of 9/25/2026, I’ve started playing with MeshCore in SoCal. There is one heck of a repeater network and enthusiastic deployment here. I’m in San Diego, and I should be able to reliably communicate with anyone in SoCal (from the Mexican boarder to the mountains NW of LA) that is on “the mesh” (assume I’m always taking about “MeshCore”).
Below is my configuration, testing, experience / issues today. I’ll be updating this as I go along.
(Click on images for larger)
MeshCore
Meshcore relies on grass roots effort to populate an area with repeaters, creating a mesh network similar to cell towers allowing users to send texts to each other, put messages into “rooms” for later pickup (which can be private), and to “channels”, which are typically public spaces. All traffic is digital encrypted and probably signed using LoRa long range communication. The protocol has forward error correction built-in so if your message arrives, it’s probably intact. Currently, all of the traffic is limited to texting. I like that you have to have the other person’s device in your address book before they can send you a direct message (DM). It’s a pain, but it eliminates spam from unknown users (doesn’t apply to channels). Anything that lowers SPAM from the get go is a bonus.
You can setup a repeater which does exactly the same thing a radio repeater does (repeats what it hears and best if mounted up high). Next are client nodes, called companions, that you use to communicate, which are tiny radios that are controlled by your smartphone app which looks similar to other messaging apps. Using the client app on your phone you can send DMs to another user, post to a “channel”, or drop messages in a room server if you have the password. Because this is a “bare metal” mesh, if your device is not reachable, you won’t be able to send or receive messages. Users receive a after they send to you which is a sort of ack.. FYI, messages are stored in volatile memory, so if your device looses power before your phone syncs with the device, poof, the messages are lost.
The hardware to run all of this is identical for the most part. For the hardware to be a repeater, vs. a companion, you just have to load different firmware so that it knows what it’s supposed to do. Obviously, if you are going to put a repeater outside in the elements, that device should be weather proof and, most of them have built-in batteries hooked up to a small solar panel for charging.
I should mention that there is a similar technology that can use the exact same radios called Meshtastic. In short, Meshtastic client nodes also act as repeaters, eliminating the need for separate repeaters. This is cool until there are too many client/repeaters in the same area, over-saturating the frequency. In a metropolitan area, Meshcore makes more sense. If you are in the back-country with friends, Meshtastic might be more sensible. The same hardware works for both by the way.
Meshcore and Meshtastic depend on LoRA radios. LoRa (from "long range") is a physical proprietary radio communication technique based on spread spectrum modulation. LoRa can be thought of as a radio signal technology, similar to Wi-Fi or cellular. The technology is primarily used for applications where small amounts of data need to be transmitted infrequently from hard-to-reach locations. (Wikipedia)
My Gear & Config
Repeater
I figured that if I wanted to use the 900 Mhz network from my house, I should put a repeater on the roof to ensure I can get out from inside and it contributes back to the community.
I’m using a Seeed Studio SenseCAP Repeater with Solar Power unit.. After watching HRCC, I added an ALFA Network AOA-915-5ACM 5 dbi Omni Outdoor 915 MHz antenna to improve performance, and the associated short cable to connect to the repeater. Flashing it with the latest MeshCore firmware and configuring it was extremely easy. I used the recommended settings from the SoCal community at wcmesh.com and was up and running quickly. Yes, I learned from others on Youtube but it’s pretty strait forward, just choose the correct channel settings for your area.
Installing on the roof was straightforward but it was brutally hot that day. After goofing around finding the correct nut / bolt combo to mount it on the same pole as my 2m antenna. The completely self-contained unit was fully operational from out of box to install in an hour. If I need to move it to a different location, like a different mast, it would be easy.
I have a fantastic view from the roof, so performance should be pretty good. Initial testing shows the repeater is being heard 96 miles away in Long Beach and I’m guessing it has good reach to the east and south as well. (picture at top of page). I need to check to see how much my repeater is being used by others but for now this is complete. (I’m still learning here).
Companion Node
Companion nodes are the small device that you use that contains the LoRa radio and the smarts to connect using blue tooth) to be accessed by your smart phone or tablet running the client software. It’s used to send and receive direct messages (DMs) to others, send and receive messages to channels and Room Servers. You also use that app and radio to connect remotely to Repeaters and Room Servers that you own to configure them, which is pretty cool. The options for radio devices are massive and the size is governed more by how big a battery and antenna you use than the tiny PCB inside. Some devices can be as small as couple of credit cards stacked together. You’ll need to carry the companion radio with you to interact on the mesh since that radio takes the place of your cellular radio to communicate.
The mesh devices are cheap. You can purchase pre-built units with pre-made / 3D printed cases or buy the parts and make your own. I’m trying several. RAKwireless sells “wismesh” devices for kit building or you can purchase complete units from Rockland and others. They generally reference “Meshtastic”, but you can load the Meshcore firmware onto any of these units if there is a build for it. You can also go to eBay and buy kits that using a Heltec display and radio board that includes battery management for an attached USBC chargeable battery (components are the size of a grain of rice.
My favorite is a Mesh Note T096, built for me by K6ARK in a custom slender green case with a carabiner on it.
Room Servers
As mentioned above, Room Servers act as a off-line place to drop messages to anyone that has access to the room. Because there is no “store-and-forward” capability in Meshcore, this can serve that purpose. You can think of it as a private chat room. The hardware used for these “Room Servers” is the same as repeaters or companions, it just runs different firmware. I’m currently using a ESP32 V3.2 device (orange) to perform that duty during my testing.
Experience and Issues So Far
This is the section I expect to update the most.
Setup, Configuration, and Basic Use
The community has made it extremely easy to install and configure a device. Once flashed, a device is configured and used by a smart phone or my iPad using bluetooth. Using the client app is intuitive. I’d say the one thing you need to understand is what “flood” is and when to reset the route to a room or user when you can’t connect. A video describing the important settings clears this up quickly. The first thing I did was disable the auto-add of other users and rooms when they are detected on the mesh. I favorite the contacts I care about and then filter out everything else.
Sending a message to another user or room is pretty obvious, and you get confirmation that it was delivered (or not). Same for rooms. Posts to a channel is another story.
Posting to Channels
This is like any social media posting app and is super simple. According to a person in Burbank, I made it in 6 hops. I’d like to know more about how channels works. I’m currently guessing that it’s a broadcast and nodes that hear it, will display the message. I don’t think there is any infrastructure behind this. This probably differentiates it from a “room server” which will hold the messages for users that are out of range until they access the mesh.
Issues so Far
#1. Reliability of DM and room posts. I’ve sent DMs and posted messages to rooms with small amounts of success. These have been located a few miles away, to all the way in LA. I can understand a message not going through because of traffic collisions but my success can be less than 25% at times and not consistent at all.
A post to a public # channel doesn’t really give you a confirmation but I think that’s because it’s more a less a broadcast (like a UDP broadcast). Stations either hear it or they don’t. (see below research)
Why isn’t my repeater being used? There is a way to see how a message is being delivered and there are lots of times when my Repeater (right above me) isn’t being used for direct messages. I find that strange, especially when when it has such great view angle toward my destination. I can understand that at times it may be busy with other traffic this happens too often on DMs and Room access. However, it’s almost always mentioned that it hears my post to a channel (not routed, just a flood remember).
My client is programmed to switch to “flood” mode if it fails to send a DM or room post three times, which should work most of the time. I've tried to reset routing so that it floods from the beginning but that doesn’t seem to help. It works but not as consistently as it should.
Scratching my head regarding reliability here.
#2 - Room Servers
According to my research, room servers can only hold 32 messages (probably FIFO stack). In addition, they are stored in volatile memory, server looses power and you are toast. Given the power needs of the controller, an external USB-C brick will probably hold it for weeks, if not months, but a firmware crash will nuke it.
I’d like to find a way to connect to non-volatile memory on a pi device or something.
More to come.
Supporting Info
How Channels and Rooms Work
(Pulled from Internet research)
In MeshCore, a channel is a group chat defined by a shared encryption key. Anyone who has the key can read and post, and everyone else only sees encrypted packets.
The key is the channel
Each channel uses a 16-byte pre-shared key. Any device with the same key can decrypt that channel's messages. There's no server and no membership list. If you know the key, you're in.meshcoreopen
Three channel types
How messages travel
Channel messages are flood messages. Instead of following a set route like direct messages do, they spread through all the repeaters across the mesh. The Public channel can flood up to 64 hops.github+1
You get no delivery confirmation. You can see which path a message took to reach you, and which nearby repeaters passed on your message.meshcore
Repeaters don't need the key to pass messages along. Your companion device does the decrypting.
Good practice
Since every channel message floods the whole mesh and uses shared airtime, local groups suggest using hashtag or private channels over Public where you can, and not broadcasting things that don't need to reach everyone.github
Channels differ from room servers, which store messages so people can catch up on them later. Channels don't store anything, so if you're offline when a message goes out, you miss it.
No comments:
Post a Comment