# Activation not valid - no gateways available

**URL:** <https://www.thethingsnetwork.org/forum/t/activation-not-valid-no-gateways-available/5649>\
**Category:** MultiTech Gateways\
**Created:** [February 24, 2017, 4:51pm UTC](https://www.thethingsnetwork.org/forum/t/activation-not-valid-no-gateways-available/5649 "2017-02-24T16:51:24Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\
**Post date:** [February 25, 2017, 12:48pm UTC](https://www.thethingsnetwork.org/forum/t/activation-not-valid-no-gateways-available/5649/8 "2017-02-25T12:48:15Z")

</div>

I guess meanwhile you see the design flaw in using a clock to determine when to send (and above all: when to join, as that needs downlinks that are very limited by the gateway’s duty cycle, like explained by kersing). So just for the sake of completeness:

> [@mark-stanley](#):
>
> I don’t think it is practical for me to change SF or frequency for each device - I can’t control the devices that are in range of my gateway or when the devices will send data

As LoRaWAN nodes do not perform any activity detection before they start sending, nor do any collision detection while sending, LoRaWAN-compliant nodes _must_ [adhere to duty cycles and hopping frequencies](https://www.lora-alliance.org/portals/0/specs/LoRaWAN%20Specification%201R0.pdf#page=7) (emphasis mine):

> **1 Introduction**

> […]

> End-devices may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected:

> - **The end-device changes channel in a pseudo-random fashion for every transmission.** The resulting frequency diversity makes the system more robust to interferences.
> - The end-device respects the maximum transmit duty cycle relative to the sub-band used and local regulations.
> - The end-device respects the maximum transmit duration (or dwell time) relative to the sub-band used and local regulations.

However, they should not change SF to avoid collisions, but only increase SF if they cannot reach any gateway otherwise.

Disputed; will try to find a source or peek into the LMiC-code later on…:  
~~Beware: while joining, a node will increase its SF for each retry, until it receives a Join Accept. Next, for subsequent uplinks, it will keep using the SF that resulted in a successful join, unless your software sets it explicitly, or until instructed otherwise by the network (Adaptive Data Rate), or until it somehow determines it can use a better SF (maybe using Link Check commands?). So, if your node cannot join due to collisions, it might eventually join using a high SF and then (while still hopping channels for each transmission) use that high SF for uplinks, which will quickly eat [your maximum allowed air time](https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300).~~

---

_[View the full topic](https://www.thethingsnetwork.org/forum/t/activation-not-valid-no-gateways-available/5649)._