Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possibility for frequency scanning and node linkup #83

Open
rawesomeawesome opened this issue Aug 15, 2020 · 2 comments
Open

Possibility for frequency scanning and node linkup #83

rawesomeawesome opened this issue Aug 15, 2020 · 2 comments

Comments

@rawesomeawesome
Copy link

The starting frequency of the individual nodes can be varied, so why not instead have a "beacon" frequency and upon startup begin scanning adjacent frequencies for other beacons. By switching frequencies and communicating with other nodes, it could be determined that all nodes should be on 433mhz or 986 for instance, and so all nodes would switch their beacon channel to that frequency and use it for communication as well as to tell additional nodes where to connect to. Rather than simply having nodes with incorrect frequencies unable to connect. This would lengthen boot times but be better for long term network stability in the case of individual users.

@paidforby
Copy link
Contributor

paidforby commented Aug 16, 2020

Are you talking about spreading factor or about frequency?

If frequency, there are limited frequencies on which devices are supposed to transmit LoRa signals and these are regulated by region. (i.e. 433 MHz, 868 MHz in Europe, 915 MHz in Australia and North America, and 923 MHz in Asia). So there isn't really an ability to "channel-hop" because in any given region there is only one (or at most two) frequency at which other LoRa devices should be operating.

However, if your are talking about spreading factor, then there could be a use case for this sort of "channel-hopping". The spreading factor is a variable of a LoRa signal. It can be loosely thought of as the "distance between chirps". This ends up working a little bit like a channel except that changing the spreading factor has a significant impact of the range of a LoRa transceiver.

I'm not sure I see the value of a complicating the boot procedure to automatically find what spreading factor neighboring nodes are using. Also by adding a "beacon" spreading factor or frequency, you are cutting in to the airtime (and precious bandwidth) that a LoRa device can use (airtime is also regulated by region, in the EU I believe talk time at 868Mhz is 10%).

@paidforby
Copy link
Contributor

Thinking about this more, in the US, you may be able to use any frequency between 902 and 928MHz (from this source https://www.mokosmart.com/lora-frequency/). I think bandwidth can be adjusted, but defaults to 125KHz. i think that gives you something like 64 channels.

I'm not sure if there are any hardware requirements for using a wider range of channels.I haven't tried any channel besides 915MHz.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants