My Meshtastic node and MeshCore node cannot communicate

My Meshtastic node and MeshCore node cannot communicate

This is one of the most common points of confusion for new mesh users: both Meshtastic and MeshCore run on similar LoRa hardware, operate in the same 915 MHz band, and can even share the same physical channel frequency — yet they cannot exchange messages with each other. Here is why, and what your options are.

Why they are incompatible

Meshtastic and MeshCore are completely independent software stacks. While both modulate data over LoRa radio, they differ in every layer above the physical radio signal:

• Packet format: Meshtastic uses Protocol Buffers (protobuf) serialized payloads inside its own envelope structure. MeshCore uses a different binary packet format with its own header fields, addressing, and payload encoding. A MeshCore node receiving a Meshtastic packet sees garbage bytes it cannot interpret, and vice versa.
• Encryption: Meshtastic encrypts channel traffic with AES-256 using a shared channel key. MeshCore uses its own encryption scheme. Even if a node could parse the outer envelope, it cannot decrypt the payload without the matching key material and algorithm.
• Routing logic: Meshtastic uses managed flood routing with hop decrement. MeshCore uses a different routing model oriented around repeater nodes and room servers. The routing metadata fields in each protocol are incompatible.
• Node identity: Meshtastic identifies nodes by a 32-bit node number derived from hardware MAC. MeshCore uses a public-key-based identity system. There is no translation layer between them.

There is no bridge — yet

As of the current date, no production bridge firmware or software exists that can transparently relay messages between a Meshtastic mesh and a MeshCore mesh in real time. Research and community projects have explored the concept, but none have reached a state suitable for general use.

Workarounds for cross-protocol communication

If your community includes both Meshtastic and MeshCore nodes and you need them to share information, the following approaches can help:

• Room server as intermediary: A MeshCore room server can be accessed over the internet by MeshCore users and, indirectly, by anyone with internet access via a web client. Meshtastic users with internet connectivity can participate in the same conversation via an IP-based interface, even if not over RF.
• Winlink as store-and-forward: Both communities can send and receive email-style messages through the Winlink network, which acts as a common store-and-forward layer. This requires a gateway node on each side but does not require any RF interoperability.
• Dual hardware stacks: Deploy two physically separate nodes at the same location — one running Meshtastic and one running MeshCore. A human operator or automated script on a co-located computer can relay messages between the two networks over their respective serial or Bluetooth APIs.

Recommendation

For a new community deployment, choose one protocol and standardize. Mixed-protocol communities incur significant coordination overhead. If you are integrating with an existing regional mesh, match whatever protocol that mesh uses.