Nodes must have the same Primary Channels for Secondary Channels and DM's to work?

Support
1

Hello,

I am exploring the use of Meshtastic with some of the NPO’s I volunteer with, and came across an unexpected issue: If nodes do not have the same primary channel, then they can not communicate with each other at all, regardless if they DM, or have identical secondary channels. According to YouTube videos I have watched, this is not supposed to be the case. I have even seen on YT people going to conventions/expos, and communicating on secondary channels. Yet, it is what I am experiencing.

In this test environment, the default Primary channel was removed (I have over 300 nodes in my area, so needed some peace and quiet in my test env).

To make it easier to explain…

Nodes 1-3: Volunteers

Channel 0: Primary = Region9 // Primary Comms for R9 volunteers
Channel 1: Secondary = Bulletins // meshBBS node
Channel 2: Secondary = admin // testing remote admin

Node 4: BBS Node

Channel 0: Primary = Bulletins // meshBBS node
Channel 1: Secondary = admin // testing remote admin

All keys are identical. In this configuration, Node 4 does not receive messages in app, regardless in Group or DM. It does not ACK any messages. However, if I swap channel 0 and 1 on Nodes 1-3, then the BBS nodes receives all messages on both Bulletins, admin, and responds on DMs.

I have also created up to 5 channels, with some nodes only having 2 of the 5 channels. As long as the PRIMARY channels are the same, then they also receive group messages on the secondary channels, as well as DM’s.

Is this the expected result? Have I had the wrong understanding of how channels work?

Thanks for your help! :slight_smile:

Regards,
Tony W1LMS

CLI:
python 3.12.5
pip 24.2
meshtastic CLI 2.4.0

Client:
iOS 2.5.2

Firmware:
v2.5.0.ab7de7f

Nodes:
RAK4631
T-Beam v1
Heltec v3
T-Echo

1 Like
2

As I continue to research this, I did find something that might have solve this issue. I will try it out today.

On the doc pages: Channel - Role:

it says:

While you can have a different PRIMARY channel and communicate over SECONDARY channels with the same Name & PSK, a hash of the PRIMARY channel’s name sets the LoRa frequency slot, which determines the actual frequency you are transmitting on in the band. To ensure devices with different PRIMARY channel name transmit on the same frequency, you must explicitly set the LoRa frequency slot.

Will report back if this solves the issue.

1 Like
3

I can confirm this has solved my issue. :grinning:

1 Like
4

I am very green here and I was facing the same trouble. Can’t believe I missed that notice in the docs! Seems like it might be a more import admonition than just “note”.

Thanks for pointing this out!

1 Like
5

Me too! I had already read that page, but as I was searching through the docs again, it just jumped out at me. I just smh, LOL. Glad I was not the only one.

6

Agreed, I just ran into the same thing. I think most people are going to miss this.

7

Some additional details:
the command from the CLI is: --set lora.channel_num 20

Or whatever the Frequency Slot needs to be. (Frequency Slot = Channel Num)

1 Like