RNS Logo

rns.recipes

◈ 9ce92808be498e9e05590ff27cbfdfe4
Guest posting from WWW mirror disabled. Ident on Nomad @ 9ce92808be498e9e05590ff27cbfdfe4 or sign up to post

US and the mess of FCC 15.247(a)

Started by kabi-chan b0d7fee56924dd72... ·

kabi-chan 3b98ca3ce4b95e60...
#1

I've seen a lot of talk about this regulation that's gone entirely unnoticed by most of the mesh networks until recently. TL;DR: everything operating in the 915MHz ISM band in the US cannot use anything narrower than 500kHz unless they use frequency hopping. This has caused a heck of a panic in the 'tastic and core communities, but I haven't seen any talk of it in the RNS space. Since all of the most popular settings in the US use 125kHz, this also affects us. Has anyone done any testing with the 500kHz minimum, and if so, what are your thoughts?

GRNCH 06d6fffbb0373c26...
#2

I haven't actually taken a look into it yet but this might clash with some of those other networks depending on what presets are being used no?

kabi-chan 3b98ca3ce4b95e60...
edited #3

Yeah, it's a bit of a mess. Meshtastic changed their default to LongTurbo (centered on 908.75MHz) and the meshes on MeshCore are kinda flailing (I know of at least three different settings just on the east coast alone). Someone wrote up a good article on everything and the problems people have already ran into by acting too fast. https://beala.substack.com/p/the-fcc-want-me-to-use-more-bandwidth

Zenith
#4

kabi-chan wrote:

I've seen a lot of talk about this regulation that's gone entirely unnoticed by most of the mesh networks until recently. TL;DR: everything operating in the 915MHz ISM band in the US cannot use anything narrower than 500kHz unless they use frequency hopping. This has caused a heck of a panic in the 'tastic and core communities, but I haven't seen any talk of it in the RNS space. Since all of the most popular settings in the US use 125kHz, this also affects us. Has anyone done any testing with the 500kHz minimum, and if so, what are your thoughts?

 

I haven't heard about this in any Meshtastic circles. Sounds like a serious case of FUD.

 

Unless I can see some explicit evidence that this is a requirement thats being enforced, , I could not give a shit. Great news for people who sit around all day looking for problems though.

 

If you want something to forever be a toy network where you can send a few "HI!!!" messages back and forth, start worrying about what the FCC says.

Zenith
edited #5

Also I really like the logic here. There's over 140,000 Meshtastic/MeshCore devices in the US, almost all are probably using a preset with lower than 500 kHz bandwidth.

 

The FCC, the only governing body or party in the matter that could do something, said nothing, did nothing. Made no comment even in the decade these type of LoRa modules existed and were being used with sub-500 kHz presets.

 

But now it's suddenly an issue because some random MT (a great example of what happens when you have a design-by-committee project: it all goes to shit) developer said it isn't allowed based on their own interpretation? Okay lol. Some sound logic there.

 

Maybe when hell has frozen over, you'll be a target for the FCC. Right after all of the lids yapping on 7200

Alledegly_noderunner 2a323a0ad8734e73...
#6

Might drive a bit of innovation? FH is pretty common for the LORA based FPV protocols and its resistance to jamming and lower probability of intercept is becoming slightly taboo. Could get interesting.

Zenith Admin
edited #7

Alledegly_noderunner wrote:

Might drive a bit of innovation? FH is pretty common for the LORA based FPV protocols and its resistance to jamming and lower probability of intercept is becoming slightly taboo. Could get interesting.

 

FHSS is resistant to a very specific type of jamming which is narrowband interference.

 

It is not, in any way, resistant to modern deliberate jamming techniques of the past 50 years if that is something you are taking into account with a threat model.

 

Traditional LoRa is not FHSS. LoRa is CSS, or chirp spread spectrum. ExpressLRS and stuff like CRossfire has firmware level FHSS to avoid congestion but isn't designed for "jamming resistance".

 

and lower probability of intercept

 

LoRa has a fixed, well documented preamble that can be detected by anyone, even someone with a $30 RTL-SDR. FHSS does not change this.

 

The ISM allocations where LoRa is (legally) allowed in most jurisdictions, and where most off-the-shelf LoRa modules operate are teeny tiny. You could just fill the entire band.

 

If this is something in your threat model the only tool that can help you with anything that's line of sight RF is directionality. Two mobile sites, using point-to-point yagis or some other means. Or skipping LoS all together and using skywave propagation with HF, with careful consideration of the groundwave component and radiation pattern of the antenna.

Alledegly_noderunner 2a323a0ad8734e73...
#8

Agree, but less trivial to intercept and wide adoption might count for something in a permissive environment were just about any networked consumer device can become part of the dragnet.

K8 - Mobile d8a95477de4323a1...
#9

LR-FHSS seems interesting for running more dense networks, but as far as I've been able to find there's barely any receiver hardware available for it, and the gatways that do support it range from very expensive to "call for quote". I don't think that Semtech even publishes their reference designs for it except to say that it requires an FPGA and DSP. The SX1262 transceivers can only transmit it, so it's not really suitable for the kinds of mesh applications we need.

Dayle M0OUE 4b7ab14b6b855d6c...
#10

The FCC doesn't care. Stop worrying and start building networks.

Post a Reply

Supports Markdown: **bold**, *italic*, `code`, ```code blocks```, [links](url)

Log in to upload images

Quote
Copied to clipboard