How to Run Meshtastic Store & Forward on a Public Channel: A Hybrid Approach

Category: Meshtastic Tutorials | Tags: Store & Forward, Heltec V4, Configuration, LongFast, Private Mesh

If you have been experimenting with Meshtastic’s Store & Forward (S&F) module, you might have run into a common dilemma: you want the reliability of offline messaging for your private group, but you don’t want to isolate yourself from the wider public mesh (LongFast).

In my previous coverage of Store & Forward, we looked at setting up a completely private ecosystem. While secure, it was lonely. Today, we are taking a deep dive into Part 2 of our testing series. We will demonstrate a "Hybrid Configuration" that allows you to keep your nodes on the public frequency, chat on LongFast, but utilize a dedicated Store & Forward server for a secondary private channel.

Here is the step-by-step breakdown of the hardware, the configuration logic, and the successful test results.

The Hardware Setup

For this test, reliability and memory are key. Store & Forward requires the server node to hold messages in memory until a client requests them. Therefore, hardware selection matters.

• The Server: A Heltec V4 equipped with PSRAM.
  • Why PSRAM? The Store & Forward module is memory-intensive. Standard ESP32 chips can run out of RAM quickly. The Heltec V4 with PSRAM allows the server to act as a robust storage locker for text messages.
• The Clients: Two Heltec T114 nodes (Identified in the test as 884f and 26d8).
  • These are standard client nodes used to send and receive messages.

 

???? Screenshot timeline from Video

Blog Post Image Placeholder	Video Timestamp	Visual Description to Look For
1. The Hardware Setup	00:36	The three devices sitting on the desk (Two Grey/Green clients and the Green Server).
2. The Hybrid Diagram	02:24	The slide titled "Public & Private Channel" showing the channel mapping.
3. Client Settings	04:30	The phone screen showing the Channel list: 0: LongFast and 1: SF.
4. Server Settings	05:21	The phone screen showing the Server Channel list (note how it is different from the client).
5. The Isolation Test	05:44	Close up of the grey device (884f) showing the "Shutting down" progress bar.
6. Server Receiving	06:36	Close up of the green Server (9040) showing the "Hi there" message on its tiny OLED screen.
7. Verifying Public Traffic	07:48	The phone screen showing the "LongFast" conversation list populated with messages.
8. The Retrieval Command	08:18	The phone screen showing the user typing SF into the direct message field to the server.
9. Success/Delivery	08:43	The phone screen showing the stored message "Hi There" finally appearing in the chat history.

The Evolution of the Configuration

To understand why this specific setup is a breakthrough for many users, we need to look at how we arrived here.

Test 1: Private Everything ( The "bunker" Method)

In our first attempt (covered in Part 1), we changed the actual LoRa physical frequency and used a private Primary Channel.

• Pros: Total privacy.
• Cons: You disappear from the public mesh. You cannot verify coverage using public nodes.

Test 2: Private Channel, Public Frequency

We moved to the standard US frequency (906.875 MHz) but kept Channel 0 as a private encryption key.

• Pros: Better connectivity potential.
• Cons: You still cannot communicate with the general public on LongFast because your primary channel doesn't match theirs.

Test 3: The Hybrid Solution (Public & Private)

This is the configuration we are testing today. The goal is to exist on the public mesh but have a "side channel" that supports Store & Forward.

Configuration Deep Dive: The "Secret Sauce"

The success of this test relies entirely on how you map your channels. The configuration for the Clients and the Server must be different for this to work effectively.

The Client Settings (Nodes 884f & 26d8)

We want these devices to act like normal Meshtastic nodes for 90% of the time.

1. LoRa Frequency: Standard Public (e.g., US 906.875, Slot 20).
2. Channel 0 (Primary): LongFast (The default public channel).
3. Channel 1 (Secondary): A private channel named SF (or whatever you choose) with a custom PSK (Pre-Shared Key).

This allows the client to see all public traffic on LongFast while keeping the S&F traffic on a separate, encrypted band.

 

The Server Settings (Node 9040)

This is where the magic happens. For the Store & Forward module to prioritize and store the correct messages, we flip the channel mapping.

1. LoRa Frequency: Standard Public (must match the clients).
2. Channel 0 (Primary): SF (The private channel).
3. Channel 1 (Secondary): Not strictly necessary for S&F, but can be LongFast if you want the server to see public traffic (though it won't store it).

 

By making the private channel the Primary channel on the Server, we ensure the S&F module logic focuses its storage resources on that specific encrypted conversation.

The Live Test: Does it Work?

To prove this concept, we performed a live "Store, Drop, and Forward" test.

Step 1: Isolation

We connected to Client 1 (26d8) and ensured it was live. We then simulated a power outage or out-of-range situation by physically turning OFF Client 2 (884f).

 

Step 2: Sending the Message

From Client 1, we sent a message—"Hi There"—on the private SF channel.

• Result: The message was sent.
• Verification: We checked the Server (9040). The message arrived at the server. Crucially, because Client 2 was off, the message had nowhere to go, so it remained stored in the Server's PSRAM.

 

Step 3: Verifying Public Traffic

While waiting, we checked the LongFast public channel on Client 1. Messages from other random nodes in the mesh were still coming through. This confirms that our Hybrid Config is working: we have private S&F capabilities without losing public mesh awareness.

 

Step 4: The Retrieval

We turned Client 2 (884f) back on. Once it booted up and connected to the mesh, it did not receive the message immediately (Store & Forward is not always push-instant; it often requires a query).

To force the retrieval, we sent a direct message from Client 2 to the Server (9040) with the command: SF.

Step 5: Success

Immediately after sending the command, the Server responded. The message history history window opened, and the stored message "Hi There" populated on Client 2.

 

Summary of Findings

This test confirms that you do not need to choose between privacy and public participation.

1. Hybridization Works: You can mix Public (LongFast) and Private (Store & Forward) channels on the same device.
2. Channel Order Matters: For the best results, your Clients should have LongFast as Primary, but your S&F Server should have the Private Channel as Primary.
3. Public Traffic is Ignored by S&F: The server will not waste memory storing "LongFast" messages; it only stores messages for the private channel it is configured to manage.
4. Hardware is Critical: Using a Heltec V4 with PSRAM provided a stable experience. Older ESP32 boards may struggle with the memory overhead of this configuration.

This setup is ideal for groups of friends, hiking parties, or emergency prep groups who want their own reliable "answering machine" service while still helping repeat signals for the wider community.

Frequently Asked Questions (FAQ)

1. Can I use Store & Forward on the public LongFast channel?

Technically, you could try, but it is highly discouraged and often disabled. The sheer volume of traffic on LongFast would fill up the RAM of even the best Meshtastic device in minutes, causing it to crash or overwrite messages immediately. Store & Forward is designed for private, lower-volume channels.

2. Do the Client and Server need to be on the same LoRa frequency?

Yes. Absolutely. If your Client is on Slot 20 (906.875 MHz) and your Server is on a private frequency, they cannot hear each other. They must share the physical layer settings (Frequency, Spreading Factor, Coding Rate).

3. Why does the Server need the Private Channel as "Channel 0"?

Meshtastic firmware often prioritizes the Primary Channel (Index 0) for specific module tasks. By setting the private channel to Index 0 on the server, you ensure the Store & Forward module explicitly listens to and manages that specific encryption key.

4. How do I request my messages from the server?

You can wait for the server to attempt a delivery (based on your History Return Max and History Return Window settings), or you can force a check. To force a check, send a Direct Message to the Server node containing the text SF.

5. Do I strictly need a device with PSRAM (like the Heltec V4)?

For a Server? It is highly recommended. A standard NRF52 or ESP32 device has very limited RAM. Without PSRAM, the device might only be able to store a handful of messages before running out of memory. If you want a reliable server that can hold history for hours or days, get a device with PSRAM.

Have you tried setting up a Store & Forward server on your mesh? Let us know in the comments below!