Hi,
I am using a Kerlink-iFemtoCell-evolution gateway with chirpstack as network server .
Due to Coronavirus situation, I should leave it functioning in the office. I cant find any option regarding Duty cycle or interval of sending data in its configuration steps, and from the forum found that ChirpStack does not enforce duty-cycle control. I am using EU868 band
Is it possible that I face problem of regulations and limitations of Duty cycle based on ETSI or LoRaWAN specification if I leave it running in the office using ChirpStack?
To be specific: It is possible. How high that chance is, depends on your setup and the country/region you live in. See the regulatory agency has not enough “Vans” to drive around every single corner of a country. Someone with a network already operating might see more Noise and/Or see a degraded quality of service, as in “this devices used to send every 10 minutes, now we randomly get 1/3 of the traffic we used to get…” or have active monitoring of the radio-space itself, this includes LoRa or any other approved used of the radio-spectrum, in any case it will not happen overnight. This is more relevant as the number of devices/gateways increases in your region and/or the radio-spectrum gets more crowded.
LoRa is not WiFi, but imaging you put “bigger” antennas on your router, because you cant get WiFi in the basement. You were so “good” and now the whole Block of Houses around yours wont have WiFi. That will get a lots of people complaining to the ISP, which in turn might go look, and report you. Then the people in the van show up, and if you are lucky they might just tell you to “turn that off or …”
Lower the transmission power of the devices as low as you can, if you are just testing: try to isolate the gateway and device. Sometimes just keeping the windows shut (new buildings have metal-coated windows) will be enough. As long as you are not sending an uninterrupted stream, you should be fine.
This is by no means Legal advice. Be a good neighbor.
@chopmann
Thank you very much for your reply.
Is there any way that I can limit duty cycle in Kerlink gateway? because I don’t want to have problem or be concerned for that. I cannot find any option for duty cycle or interval of sending data in Kerlink iFemtoCell-evolution Gateway.
I would greatly appreciate if someone could advise me in this regard.
Hi,
There’s something I don’t understand.
Why are you trying to limit Duty of Cycle at Gateway level?
Duty of Cycle is usually setup in end nodes, that are the ones that produce transmissions.
The gateway cannot limit the transmissions produced by end nodes.
At maximum it could not transmit the messages to LoRa Server, but this is not the problem if I understood well @marii question.
1 Like
@pulidoj
Thank you very much for your reply.
I set Duty cycle and interval of sending data when I configured my sensor, and I thought there is no need for such parameter in gateway, but for a Multitech gateway, I saw Duty-cycle period, keep alive interval, stat interval and so on in the configuration of gateway, but I do not see them for my Kerlink gateway, and after searching I saw a topic about duty cycle and gateway in TTN forum and also asked about my kerlink gateway in a new topic and got this answer in TTN :
“Those parameters are used for the LoRaWAN backend build into the gateway. When using TTN that part of the software is not used because TTN provides the backend” and “The TTN backend will make sure your gateway stays within legal limits. (If you select the correct region when adding the gateway to TTN)”
but I am going to use ChirpStack and I have to leave my gateway functioning in the office due to coronavirus situation, and after searching I saw in a topic that “Chirpstack does not enforce duty-cycle control”. Is it possible I face legal problem if I leave my Kerlink gateway functioning in the office? and what can I do to prevent that.
I would greatly appreciate if someone could advise me in this regard
Hi,
all members of LoRaWAN must follow the duty cycle regulation, even the gateways. They are sending downlink data to multiple devices, so it can happen that the gateway is sending data outside of this regulation!
You are totally right. @marii I would not worry all that much. If you are not having 100s of devices all sending in 1 second interval with DR0 and Confirmed messages, you should be mostly fine. Configure all the 8 channels available on your gateway, set the devices on ADR. They should do “pseudo-random-channel jumping” which gives you plenty of Air Time.
@HofIoT, it makes sense for the duty cycle to be managed by the end-nodes, not gateways. Gateways might need to send confirmation messages (Un)ConfirmedDataDown upon receiving ConfirmedDataUp packets. In such cases, ensuring the gateway’s compliance with duty cycle requirements becomes a headache. We must adjust the duty cycle whenever the quantity of end-nodes changes.