terrillmoore
commented
3 years ago Not really allowed to do that, according to FCC, other national, and LoRaWAN specs. FCC wants random; other national want random with collision avoidance (listen before talk, or LBT); LoRaWAN specifies random. LoRaWAN tests further essentially require this by requiring that all channels be covered in a minimum number of uplinks. For example, all 8 uplink channels in US must be hit within 17 uplinks. Markov chain analysis indicates that the only way to do this reliably is to use a shuffle (random selection without replacement). If you search the bug reports, you'll see where I discussed this and addressed it. It's unfortunate that you're seeing interference, but it's unlicensed spectrum. In the markets where LBT is used, the common approach is to drop the transmit if an uplink hits a busy channel (just as if there'd been a collision over the air).
Recently some of my company's gateway received a large amount of SF12 uplink on 923.2Mhz (Channel 0, AS923), probably someone who is testing or doesn't know what they are doing. We deal with this problem by manually setting some of your critical end devices to not use channel 0.
Which make me have an idea, what if the channel selection is also determinded by TX channle success rate? (Previously failed to ACK (maybe that channel is being flooded) will have less chance maybe -20%? being selected) This will allow the end device to select a better (in theory) TX channel for uplink and avoid channels that are flooded
Not sure if this is allowed in LoRaWAN's spec but it seems to be a reasonable idea. If everyone is selecting channels randomly, it will all be good, however, in the real-world it's not that ideal.
Just for ref, gateway being flooded, we have some frequency flooded at >20% duty cycle On another gateway, we have some unknown nodes with DevAddr 01xxxxxx sending SF12 almost every 10 seconds only on 923.2Mhz