English is currently available.
LoRa & LoRaWAN DISCUSSION
My LoRaWAN sensor in the EU868 band sends a 10-byte payload every 30 seconds during testing. It works next to the gateway at SF7, but I read that the band has a 1 % duty cycle limit and that public networks add their own fair-use rules. When I move the node far away and it switches to SF12, the stack starts refusing to send.
How do I work out the allowed message rate for a given spreading factor, and how should the application be designed around it?
The duty cycle limit is a regulatory rule for the sub-band, not a LoRaWAN invention. The three default EU868 channels, 868.1, 868.3 and 868.5 MHz, sit in a sub-band that allows 1 % transmit time, which is 36 seconds in any hour. After a transmission of length T the device must stay off that sub-band for 99 × T.
LoRaWAN adds at least 13 bytes of header, port and integrity code, so your 10-byte payload is a 23-byte frame. At SF7 and 125 kHz that is on air for about 62 ms: the wait is about 6 s and roughly 580 frames per hour are possible. At SF12 the same frame takes about 1.48 s, the wait is 147 s and the limit is about 24 frames per hour. A 30 s interval is legal at SF7 and impossible at SF12, which is exactly when the stack starts refusing.
Network policy is usually stricter than the law. The Things Network's community fair use policy, for example, allows 30 seconds of uplink airtime per device per day and at most 10 downlinks per day; check the current wording for whichever network you use. With the 23-byte frame that means about 486 uplinks a day at SF7, one every 3 minutes, but only about 20 a day at SF12, roughly one every 70 minutes.
So a 30 s reporting interval is a bench-test setting. Production devices on shared networks typically report every 10 to 60 minutes.
Design so that the node rarely needs a high spreading factor. Enable adaptive data rate for nodes that do not move: the network server looks at the SNR margin of recent uplinks and tells the device to use a lower spreading factor or less power when there is room. A better antenna position at either end is worth several dB and often brings a node from SF12 down to SF9 or SF10.
Shrink the payload too. Send binary values rather than text or JSON: a temperature as a signed 16-bit integer in 0.01 °C steps, a battery voltage as one byte. At SF12 each extra byte costs tens of milliseconds.
In the application, send on change or on a slow timer instead of fast polling, and do not request confirmed uplinks for routine data. A confirmed uplink makes the network send a downlink, and gateways are bound by duty cycle as well; while a gateway transmits it cannot receive. If the stack reports that no channel is available, queue the newest reading and drop older ones rather than retrying in a tight loop.
Also note that the limit is per sub-band. Networks normally add more channels, for example 867.1 to 867.9 MHz, that belong to a different sub-band with its own 1 % allowance, and a compliant stack tracks the time-off for each band automatically.
For readers in other regions, the rules differ. US915 has no duty cycle limit but restricts dwell time to 400 ms per channel with frequency hopping, which is why the slowest uplink data rate there is SF10 at 125 kHz with a small maximum payload, not SF12. Other regions have their own combinations of duty cycle, dwell time and listen-before-talk. Use the regional parameters document for your band and let a certified stack enforce the limits instead of hard-coding delays.
Back to LoRa & LoRaWAN community
