Not 915MHz default for US?

1

Forgive me for a lengthy post but I’m a little confused by something.

In my QRP radio experience, all elements - transmitter, receiver and antennas all needed to be tuned to an exact matching frequency, especially when using low power, for optimal results. Apparently Meshtastic utilizes a complex channelized system of frequencies - probably to reduce network congestion.

Throughout my Meshtastic journey the term 915 MHz has been referred to consistently as assigned to US region operations, however under Meshtastic.org/About/Overview/Radio Settings it explains that…

Meshtastic uses the full spectrum frequency range designated to LoRa technology per region. This allows for several hundred possible frequency channels in the US region alone.

Then…
North America Frequency Bands

915 MHz (ISM Band)
The band range is from 902 to 928 MHz.
There are 104 channels defined with the standard radio preset LongFast. After factory reset the radio will be set to channel [slot] 20 with a center frequency of 906.875 MHz…

What? The factory default frequency for LongFast (the predominant use freq) is 906.875 MHz?

Then under Radio Config/LORA, it says…

Frequency Slot

This setting controls the actual hardware frequency at which the radio transmits, represented by a frequency slot between 1 and NUM_SLOTS (the maximum for the current region and modem preset)…

In other words, a slot variable of 104 different frequencies that we can choose? What criteria would we use to make this selection? If you pick slot 1 (902.125) and I pick slot 104 (927.875) will our radios even connect?

My point, if the full ISM band range is 902 to 928 MHz, why would the default slot (20) be at 906.875 MHz instead of slot 52 which results in 914.875, almost the exact center frequency for 902 to 928 MHz radios and antennas. Giving Meshtastic users the ability to randomly select frequencies yields inconsistency and “detunes” the RX and TX signals because we can’t anticipate what frequency slots other nodes are set to. If the mesh system needs a complex array of possible frequencies by design, the optimum frequency usage should be determined by the mesh masters and implemented and not left as a user variable without better explanation on how or why to select different slots.

Finally there is this, another variable…

Override Frequency

This parameter is for advanced users and licensed HAM radio operators. When enabled, the channel calculation will be ignored, and the set frequency will be used instead (frequency_offset still applies). This will allow you to use out-of-band frequencies…

Who is a (self-determined?) advanced user? So I can transmit and receive on whichever in or out-of-band frequency I want after all? Undoubtedly there are advanced users among us who welcome this degree of flexibility but my first impression of Meshtastic was easy radio for everybody, like volksradio.

It’s also possible that I don’t understand radio theory for the 900 MHz band that tolerates reliable Lora communications even if we’re using different frequencies.

Meshtastic signals are incredibly weak and users desire reliability and range above all. There are lots of fixed settings in Meshtastic already, in my opinion frequency usage should be among them, or at least much better guidance provided for non-radio oriented users when selecting frequencies is absolutely necessary.

2 Likes
2

You have interesting questions. I am a HAM and understand your thoughts. The use of frequencies in LoRa is complex. Perhaps you are aware of channels (freqs) in wifi. But devices on different wifi channels do communicate. To understand either protocol requires some study. You can find Youtube videos and other sources that dive into these. Achieving the ‘long range’ took some sophisticated techniques. Kind of how they did ‘magic’ in FT8 digital mode to dig signals out of noise.
I am just glad there are those very smart people helping the rest of us. :wink:

3

Hi Doug,
I am a ham too and agree that the mesh approach neccecitated some doing compared to the QRP ops I am used to. While I was waiting for my M devices to arrive I used my VNA to trim my antennas to exactly 915 and was surprised that the default freq was not that after all.

4

I think tuning to the center of the band is a good idea. Usually, the SWR stays good over the whole band doing that. Another challenge is that the antenna sweet spot can move significantly just by having a change in where the antenna is position. That is enough to move out of the band and it is hard to measure exactly where the antenna will be used. Even standing close to the antenna has an affect. We do the best we can😉

5

Meshtastic chooses bad defaults on the regular, and once chosen apparently it’s really, really hard to undo or even admit to the mistake.

I believe channel 20 was simply the result of the prior channel name hashing function. Totally random.

This is totally coincidental and not at all a result of careful deliberation, but there also happens to be a lot on this band. Like I think every water meter in my neighborhood is sitting on 912MHz, so again as a totally random coincidence, being at 902MHz might help get us away from that noise.

6

That’s a good point.
I think with 1 watt Meshtastic devices being announced, if we are all not on exactly the same frequency, at what point do we just become QRM for other low (standard) power nodes on neighboring frequencies?

7

I agree it’s confusing.

Not sure why the default is actually 906.875 but changing that now would be painful.

One thing I’ve struggled with is fixing that frequency after changing channel info. As noted, it seems to pick one based on name.

Say you want your first channel 0 to be friends or family. Maybe one for another group. admin channel. Then “longfast” (iOS leaves the name as channel 3 in this case unless you name it BTW. Android doesn’t actually name it, but the app will default to that as a display name but that’s another story)

So you have 0-3. 4 channels. The radio changes the frequency to something based on the first, “Primary” that is now different frequency.

This is beneficial if you ONLY want a friend’s or family channel, and it doesn’t use the same default “channel” to clog up airspace. Where that lands I don’t know.

It is, however, detrimental if you want to also participate in “longfast.”

So, if you want the latter you force the frequency back to default. Problem solved in that case.

For hams, think of it like this. Default channel is 146.52. everyone’s sharing that to make contacts. Some are also sending encrypted traffic to their own nodes for a friends or family type of channel if they want. The airtime is shared, and everyone can hear the traffic. Is 146.52 exactly 2 meters or right in the middle? It really isn’t. So, in that example the default mesh channel here isn’t all that different as far as frequency is concerned.

Direct messages are “encrypted” with the default, built in key. It is able to be decrypted by anyone else if they want to go through the trouble of capturing every packet they get, but it’s kind of unlikely anyone cares. Still, it’s not “secure” in the sense that it’s actually as private as a channel you set up with your own key and only share with select nodes. It’s a common misconception that it’s secure by default.

Now this is where it gets tricky, as if the above isn’t confusing enough to some.

Say you want to securely message a node who also shares private keys.

This is where I’m actually still not clear on this and have not had time to fully confirm it.
From one thread here, the way I understand it is that if 2 or more nodes have a channel, say channel 0 as “family” or whatever, they will only use their secure key if they see each other on that channel.

What does that mean if they’re also using longfast on, say, channel 3? I don’t know. What does that mean if the channels are all actually still using the same frequency as long fast at 906.875? The assumption is that the channel number is the “ID” that the nodes see each other on and use their secure key. That seems to be what’s been said in a post here, anyway, though I need to understand some of that a little better myself.

Edit - on the topic of admin channel. If you add admin channel for a node, it will only control that node if you have the right key. That would indicate that even if you’re using the same longfast frequency that it’s passing that key through other nodes in the same way a private family channel would work.

Sorry for the long tangent into encrypted channels but maybe it’ll help someone.

8

This is not always the case. DMs use the key of a channel you share with the recipient. If you both have the default channel, yes, it might be it uses the default key. If you only have a private channel in common, it will use the private channel.

Please note that the LoRa channel number will be called “frequency slot” from now on to avoid confusion. Your device will only use one frequency, regardless of which channel you send to. The frequency slot is indeed based on the primary channel’s name (to avoid different private networks eating up each other’s bandwidth), or you can manually fix it e.g. to 20 if you want to keep using the default in the US.

1 Like
9

I think there’s a lot of good points being made here.

I guess the root of my original posting was that I have been always told (in references from manufacturers and vendors) that 915 MHz was the assigned frequency for ops in the US. Apparently that is not necessarily true for Meshtastic per their own docs.

And yes, I thought you could create a new channel without having the channel utilizing a different freq. regardless of encryption. Wasn’t this packet transmission after all?

The point is, why make the Channel slot a user selectable variable when the overall span of frequencies is so great.

GUVWAF you said “or you can manually fix it e.g. to 20 if you want to keep using the default in the US.” Well is channel 20 actually the default if Meshtastic usually defaults to Channel slot 0?
Also with regard to “Your device will only use one frequency, regardless of which channel you send to.” I think they are telling us the opposite. Each of the channel 104 slots for LongFast operates at a different frequency between slot 1 (902.125) and slot 104 (927.875). After factory reset the radio will be set to channel slot 20 (906.875 MHz).

I guess I’m just an old radio guy but this all seems strange when I know how important antenna tuning and TX - RX frequency matching is with low power signals.

10

Good point!

What is the signal strength of all of those water and power meters compared to the output of our M. radios?

They must have fair power as they did not have to utilize a “Chirp” technique to be able to be perceived out of the noise floor like Meshtastic did…

11

Hi Duug,

Sorry for calling you Doug last time…

I wish these tiny antenna SWRs were flat. My VNA dips on some of these were really sharp and I over trimmed the crap out of some of them. Will have to solder some back on match 906.875 MHz. This is not the only time in life I have come up short…

12

The default of 0 (actual slots are from 1 to 104) means the firmware will calculate a frequency slot based on the primary channel name, which will be 20 for the default LongFast in the US.

With that I meant “one frequency at a time”, based on either the primary channel’s name or a fixed frequency slot if you configure that. You can have multiple channels (message groups), but you’ll only transmit on one frequency.