# Can I run MeshCore and Meshtastic simultaneously on the same hardware?

## Can I Run MeshCore and Meshtastic Simultaneously on the Same Hardware?

The short answer is: **no**. You can only run one firmware at a time on a given LoRa node. However, there are practical workarounds if you need coverage of both protocols at one location.

### Why only one at a time

Both MeshCore and Meshtastic are compiled firmware images flashed directly to the microcontroller (ESP32, nRF52840, RP2040, etc.) on your LoRa board. When you flash a firmware image, it replaces whatever was there before. There is no multi-boot capability, no virtual machine layer, and no way to timeshare the LoRa radio hardware between two independent firmware stacks. The LoRa transceiver (SX1276, SX1262, LR1121, etc.) is a single physical peripheral that can only be driven by one firmware at a time.

Additionally, even if you could somehow run both, they would need to use the same LoRa radio simultaneously - which is physically impossible without two separate radio modules. Each transmission requires exclusive use of the transceiver.

### Switching between firmwares

You can re-flash a node from MeshCore to Meshtastic (or vice versa) at any time using the appropriate web flasher or CLI tool. The process takes a few minutes and requires a USB connection. However, you lose all configuration from the previous firmware when you do so, making it impractical to switch frequently.

### Running both protocols at one location

If your community or deployment site genuinely needs to participate in both a MeshCore mesh and a Meshtastic mesh, the practical solution is two separate physical nodes:

- **Node A:** Running MeshCore (REPEATER\_FIRMWARE or ROOM\_CLIENT\_FIRMWARE as appropriate)
- **Node B:** Running Meshtastic firmware

Both nodes can be co-located at the same site and connected to the same power supply, but each should have its **own separate antenna**. Do **not** share one antenna between two transmitting nodes with a passive splitter: a splitter provides no port-to-port isolation, so each radio couples transmit power directly into the other's receiver front-end (risking damage to the LNA/PA), and it also adds roughly 3+ dB of insertion loss in each direction. Co-located 915 MHz transmitters instead need adequate physical antenna separation (ideally several feet of vertical or horizontal spacing) to limit desense and protect the receivers; sharing a single antenna between two transmitters requires a proper RF combiner or cavity duplexer, not a splitter. Many community infrastructure operators run exactly this dual-node, separate-antenna configuration at hilltop repeater sites to serve both ecosystems.

### The future: software-defined gateways

Community developers have discussed building a software gateway that runs on a host computer (Raspberry Pi, etc.) and uses two LoRa radio modules - one for each protocol - to bridge messages between the two networks at the application layer. As of today, no such gateway exists in a production-ready state. Any such project would also need to handle the fundamental differences in addressing, encryption, and routing described in the cross-protocol FAQ page.

### Recommendation

For most communities, the right answer is to **choose one protocol and standardize**. Mixed-protocol communities face ongoing friction in coordination, troubleshooting, and user experience. If your regional mesh has already standardized on one platform, matching that choice eliminates the need for dual-protocol coverage entirely.

If you are starting a new community from scratch and expect to attract users from both ecosystems, deploying two nodes at each infrastructure site is a legitimate and manageable approach - the hardware cost of an extra node (~$30 - 60 USD) is usually worth the dual-network coverage it provides (note: the two networks still cannot exchange messages with each other - each node simply lets you participate in its own network).