Hi,
as the title suggest i was wondering if there is a duty cycle limiter implemented in the things stack that keeps track of the transmit time of each gateway. I’m running a private TTS V3 server on a RPI so the fair access policy does not apply for me.
Thomas
Technically correct but as I have often posted in the past you should think of them also as a good practice guide. Bottom line is that the rf spectrum we all use is a scarce public shared resource and just because legally you can bang away to local legal limits vs FUP limits doesn’t mean you should! If all users public, private, LoRa/LoRaWAN or legacy modulation acted selfishly and used what they wanted vs just what is really needed for a given application with perhaps a little extra for redundancy the airwaves would be jammed and poor utility to all. Remember as more systems and devices of all types are deployed congestion can only get worse….RF noise like all noise is additive in nature …… just saying… 
I agree with what you are saying but it is not really a answer to the question. I was just wondering if the Things Stack has a implementation that automatically limits the amount of down links that can be send by a specific gateway. I want to know this because for the application I’m planning on using LoRaWAN for also sending a high amount of downlinks to multiple devices spread across multiple gateways.
yes they have
experienced it
Which by itself is an indication this is not the right technology for the application. LoRaWAN is asymmetrical and transmission of downlinks makes a gateway unable to receive anything on its 8 listening frequencies.
Also, gateway positions are usually optimized for coverage (so high up) and as such transmissions will cause interference in a large area.
Due to all wireless devices the radio spectrum is becoming saturated and designers of wireless solutions should act responsibly to minimize interference.
Btw, your question is answered in the message above mine.
The main idea of the application is to monitor devices in a test setup. there could however be a possibility that there are settings that need to be changed, and thus when there is a chance that the max downlink time of a gateway is reached. since the test setup are down in a basement and the gateway(s) are there aswell there is no worry that a lot of interference is cause to neighboring lorawan users.
Thanks. do you know how the things stack reacts if you put something in the downlink queue with MQTT?
This is a non-sequitur - the fact they are in the basement has no bearing on how many downlinks might be needed. And you’ve not yet quantified anything, so your assumption about a lot may turn out to be inconsequential.
That’s not an assumption the community rolls with - given the LOng RAnge of LoRa you could be trashing the local municipal facilities - even with a radio survey all of the above comments about duty cycle, legal limits and being a good user of the airwaves still count.
Usual call out of a user who doesnt have experience or makes assumptions without risk mitigation, sorry! Never assume with RF - its not described as a black art for no reason!
Just to worry you I had an early client using LoRa (Long Range remember!), back in 2015 - before TTN was a twinkle in Weinke’s & Jon’s eyes - whose end customer had a BMS application suite over the pond (in Florida if I recall correctly). Most of the plant and equipment was on the 2nd and 3rd basement levels (parking, storage and plant rooms) in a 12? 14?, can’t quite remember, storey block… and as there were concerns as to penetration through the steel re-enforced concrete decision was put the GW function on 2nd sub level to ensure adequate coverage. They had spares if needed for infill coverage that never got deployed. There were a few devices in building reception that could be picked up ok as well as on 1st (ground floor - US remember) & 3rd floors. After core installation was done their customer realised they had several spare sensors on hand - in case of failure or other deployment needs, so asked if the installers could try a couple out in ‘the penthouse’ - the nickname for the plant room on the roof that also housed one of the towers lift mechanisms. Sure enough when deployed they were picked up just fine - suspicion was signals reflecting up & down the lift shaft(s) - down in the basement. More importantly that night the facilities manager drove home - some 8.5-9 miles as the crow flies out of town. Next day when reviewing data from the prior days deployment and overnight stability checks they were suprised to see that the 2 of the configured and powered up spare units that he had left in his car had sent data for part of his trip home and then merrily chirped away every half hour over night from his drive where car was parked out in the suburbs… both were running on SF9, sensing simple T&H payload with battery condition etc. Moral wrt LoRa is be prepared to be suprised and assume nothing! We suspect that the signal was being reflected by the building infrastructure with enough rssi/snr to ensure pick up from that specific location… 
Begs the question why look at LoRaWAN and not use WiFi if everything is local and relatively close. Infinity more bandwidth both up and down and no concerns about duty cycle limits for gateways or otherwise.
Or is this to test LoRaWAN devices you will be deploying later on?