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:
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 (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.