Indeed, but with a higher chance of interference.
Also, a lot of other applications seem to use g3 as well due to the power allowance.
1 Like
If i want to work with Lora in India,what are the frequencies i should operate and what are the duty cycle limitations…?
I have a question about the additional join frequencies.
They are set on frequency: 864.1 MHz (and more), which is supposed to be in g2.
However the band regulation parts say g2:
g2 868.7 – 869.2 MHz 0.1% or LBT+AFA, 25 mW
LoRaWAN specification also mentiones these 864 MHz frequencies with 0.1 % dc limitation.
Should I disable these frequencies in LMiC?
How is this band regulated? And do gateways listen on these frequencies?
The 864.x join frequencies are not used, and have been removed in the LoRaWAN 1.0.1 update. You can remove them from LMiC (both Matthijs and myself already did in our versions).
The 0.1% DC for joins is also based on the 1.0 specification, it is more restrictive the the band DC. This also has been relaxed in 1.0.1, you can use a 1% DC for joins in the first hour of joining. After that you need to back-off to 0.01% again.
1 Like
As LoraWAN specification clarifies channel hopping in order to stand with Time on Air restrictions, how is handled need of sending ACKs uplink packets by gateway? Time on Air of Gateway will be multiplicated by number of nodes?
It refers not only to ACKs, but to whole downlink…
It would, if all nodes would always use confirmed uplinks. But nodes should not do that; you can’t send all messages as ‘confirmed uplink’:
All devices have to comply with these regulations, so that includes gateways. As a result, downlink capacity of the network is even smaller than uplink capacity. This means that you should use unconfirmed messages unless you really need confirmed messages and send as little downlink data messages as possible.
Hi @Thomas
The wiki link does not seem to work anymore?
Is it the plan that the wiki-page comes back up?
Is there any way to get the actual time on air after a package has been sent from the RN2483? Or is it only possible to calculate it?
I’m a bit on doubt about how the duty cycle limitation is enforced (on the RN2483). When trying to transmit too often I get the “no_free_ch”. Is this the “legal limit” you can use (I know that this is not in compliance with the fair usage policy of TTN, this is just for testing) in the EU or do I still need to pay attention as to how often I transmit?
According to the calculator the time on air should be 61 ms, which should prohibit me from sending for the next 6 seconds. However the “no_free_ch” doesn’t occur before I’ve transmitted 8 times (rapidly after each other). I’ve read in another thread, that it is because I can send on 8 channels and it is only when I’m sending on the first one again, that the duty cycle is violated. However all of the transmission is in the same sub-band as far as I understand (868-868.6), so what am I missing?
2 Likes
hello mahe
i am facing the same issue here, i wonder if you have found any solutions to this problem and thanks.
Yes i am also wondering about this. I am able to send uplinks without any pause. And after some continuous uplinks i get this no free channel.
I don’t know clearly about dutycycle. ductycycle=1% means:
- Sub-band available on 36s/1h. In 36s. All nodes can use it or each node can use this time ?
- A node1 sent one frame on x second in sub-band A. Sub-band will off with only node1 on x*99 second ?
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.
2 Likes
Thanks for your answer. I have more questions.
Assuming:
- Sub-band (868 – 868.6) have 3 channel A,B,C and DC=1%
- I have 50 nodes. Node1 just transmitted a 0.5 s long frame on one default channel
1. (Sub-band) will unavailable for 49.5s with only node1 or all of 50 nodes ?
2. 0.5s and 49.5s is calculated by node1 or Gateway?.
I think that: Node1 know payload of data, SF,… => it will know 0.5s and it will not transmit until 49.5s next. Did i correct ?
And can node1 know auto transmitting on another channel in other sub-band ?
- Sub-band will be unavailable just for node1
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.)
2 Likes
Is it correct to notice that in the image you include in your quote:
- The tx block is 1 unit of time
- We see 1 time-unit of tx needs 4 time-units of PAUSE
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.)
1 Like
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).