paidforby
commented
4 years ago 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%).
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.