I don’t know clearly about dutycycle. ductycycle=1% means:
You’d wish, but no:
The duty cycle should be taken into account each time you send. It’s not some hourly or daily total, so you cannot send 36 seconds and then be quiet for the remaining hour. Instead, from the specifications:
The LoRaWAN enforces a per sub-band duty-cycle limitation. Each time a frame is transmitted in a given sub-band, the time of emission and the on-air duration of the frame are recorded for this sub-band. The same sub-band cannot be used again during the next Toff seconds where:
Toffsubband = (TimeOnAir / DutyCyclesubbband) - TimeOnAir
The duty cycle is meant to lower the chances that two nodes send simultaneously. (Which would cause collisions and data loss if that happens.) However, if each node would use the maximum 1% duty cycle (assuming they would never send simultaneously with some other nodes, and would do perfect channel-hopping using 8 channels), then a gateway could only support 800 nodes! (Okay, a bit more if nodes happen to use different spreading factors, but far less as nodes send randomly.)
In other words: the maximum duty cycle is the absolute minimum time a node needs to be quiet between two messages. But on average, you should be far below the maximum duty cycle.
The TTN Fair Access Policy nicely summarizes 1. and 2. by limiting air time to 30 seconds per node per day.
And as we all share the same radio frequencies: even when using different networks, nodes affect each other, so consider the reasoning for TTN’s limit when trying to circumvent it using another network. (See “Why?” in Limitations: data rate, packet size, 30 seconds uplink and 10 messages downlink per day Fair Access Policy.)
It is per node. Nodes do not know what other nodes did.
I don’t understand. Seems like this is answered above.
Thanks for your answer. I have more questions.
Assuming:
2.I am not sure how this works.
For sure it is not calculated by the gateway. The node has to do this. As far is I understand some nodes will automaticly obay the duty cycle (build in by the company who made it). Other nodes wil require you to do that, if you write your own software for the node, a library may do this for you.
You’re right, but from @htdvisser’s new Duty Cycle Wiki page:
As a per-channel duty cycle limit is easier to implement, you can also divide the sub-band duty cycle over the number of channels in that sub-band. So for example, in a sub-band with 8 channels and a duty cycle of 1%, each channel has a duty cycle of 1/8% (that’s 0.125%).
This method is also implemented by the RN2483 module, and as a result, instead of seeing the
no_free_chwhen you send too quickly after the first message you can send multiple messages before all 8 channels are “blocked” and the duty cycle is enforced.
The figure below shows enforcement on those same two bands, but enforced per channel
(Read the whole page to understand that image; Channel 1 is in one band and Channel 2 and 3 share another band.)
Is it correct to notice that in the image you include in your quote:
Hence: The PAUSE block on channel 2 and 3 will continue for 1 more time-unit after the image ends?
After that 1 more time-unit both channels 2 and 3 become available again at the same time?
No. With a per-channel duty cycle implementation, all channels in the same subband are given their own (smaller) maximum duty cycle, not affected by activity on any of the other channels:
So for example, in a sub-band with 8 channels and a duty cycle of 1%, each channel has a duty cycle of 1/8% (that’s 0.125%).
(In the image: if channel 1 is the only channel in the first sub-band, and channel 2 and 3 are the only channels in the second sub-band, and both sub-bands have the same maximum duty cycle, then both channel 2 and channel 3 will have to wait for at least 2 × 4 = 8 time units, because the second sub-band then has twice as many channels as the first sub-band. Or, if the second sub-band has, say, 8 channels, then each of channels 2 through 9 needs to wait for at least 8 × 4 = 32 units after sending. All regardless of any activity on any of the other channels.)
Hi I am new to LoRaWAN . I am using RN2483 module.
I have a doubt whether we can use same frequency for multiple channel
Eg: channel 3 freq-868850000
channel 4 freq-868850000
channel 5 freq-868850000
What Dutycycle should i use for these channels if i need to send a packet of 50 bytes per minute
When using OTAA, the RN2483 will configure the channels automatically, and enforce the maximum duty cycle as well.
That’s way too much.
While in SF7, SF8 and SF9 this would be below the maximum duty cycle, it would then need 118 ms, 215 ms and 390 ms respectively. But for TTN, you will only be allowed 30 seconds per day. So even in best conditions (SF7), with that large payload of 50 bytes you can only send 10 messages per hour (on average).
I am using ABP. So Can i use same frequency for multiple channel.Because i just have one frequency (868850000) for my gateway.
Should the dutycycle be less than 1% for all channels
No. Even when lowering the maximum duty cycle for each of the duplicate channels, the RN2483 might then quickly transmit on the same frequency like explained in the image above, which is an abuse of the regulations.
Please beware that the maximum duty cycle is really that: a maximum, to keep the network going, as we all share the same frequencies. You shouldn’t use it to push your usage to the limits. On average, you should be far below the maximum.
What would be the maximum dutycycle we can set to a channel?
Then the overall duty cycle for all channels must be what for 868MHZ.
If you say that you use the frequency 868.85, that means you’re in the g2 band (868.7 – 869.2) which has a maximum duty cycle of 0.1%. If you would have 3 channels between 868.7 and 869.2, you’d have to share that 0.1% with the three channels, giving you a per-channel duty cycle limit of 0.033%.
I am using 865Mhz frequency in RN2483 Module because that frequency is only allowed in our place.(868Mhz is not in free range).
The default channels (0-2) are set to frequency 868Mhz and cannot be changed. Is it necessary to change the frequencies for default channels to 865 or is it ok to leave it to 868 Mhz.
If it needs to be changed then how to change. Because RN2483 module doesn’t allow to change the frequency of default channels(0-2).
You can set the frequency using something like:
mac set ch freq 0 868850000
mac set ch status 1 off
mac set ch status 2 off
Also, please check out https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/By-Country and let us know what frequencies are allowed in your region, then we can hopefully define an official frequency plan for your region.
@htdvisser
With regards to the frequency plan for India, did you see the announcement of LoRaWAN regional parameters rev 1.0.2B, it includes this:
(@stuartbinny321 mentions he is in India in another thread)
We have a preliminary gateway configuration for India, available on github. I expect it to be ready by the end of the week.
Hello,
What is the more convenient? a per sub-band duty-cycle limitation or per-channel?
Thank you.
I don’t think it really matters, if you follow the Fair Access Policy you will probably never send messages directly after each other.
If you do need to send multiple messages right after each other a per channel implementation will be faster. Since you can send on the 2nd while the first is still waiting. But that will only be faster if the number of messages you want to send is equal or lower to the number of channels in the band.
Else, if you send a message every few minutes, the only difference it will give is the implementation you have to do. Thus it would be your own judgement which is easier to implement. (If it is not already implemented by the chip/library you use.)