Thanks very much @johan for the explanation. Can we fairly estimate this kind of delay?
Furthermore, It is trivial that duty cycle would impact the energy consumption in the uploaded image. But could you please explain, what is the relationship between used duty cycle in the LoRa calculator and Energy calculations in the right bottom of the screenshot?Formula to calculate this consumption?
I’m not familiar with that calculator and I can’t think of a reason other than that the device polls every x ms for data, within the set duty cycle, so the duty cycle would drive the polling interval and therefore energy consumption. But that’s just guessing.
@arjanvanb Can you provide a similar detailed list of restrictions/specifications that TTN enforces on US915 networks ?
I ask because I presume some duty cycle related specifications would be different for US915.
Thank you
Zoheb
There is no duty cycle in US915, but there is a so-called “dwell time”. If you keep individual transmissions under 400ms, there are no other legal restrictions.
TTN’s fair access policy still applies, but this is currently not enforced in any way.
@arjanvanb I didn’t found that info in TTNmapper FAQ, do you know which packet rate (nb of seconds between packets, or packets/min) is authorized in SF7 (BW125) in Europe when performing mapping (and only mapping of course)? As for R&D, I imagine it’s higher than what is defined in Fair Access Policy? Because it’s hard to map with 5 minutes or so between packets with a moving node…
Thanks for your help.
For mapping and any R&D, any duty cycle regulations for one’s region would still apply as usual.
The Fair Access Policy is a daily maximum of 30 seconds. As even a zero byte application payload would be fine for mapping, you could send 647 packets in SF7, with a delay of 4.6 seconds† (assuming a 1% maximum duty cycle). So, you could be mapping for almost an hour without hitting the Fair Access Policy either. Even more, it’s not enforced yet.
† Same values for 1 and 2 bytes application payloads (plus the 13 bytes header)
Hello
When a ‘Link Check commands’ is used, the TTN send an Downlink with empty payload.
Is this downlink is count in restriction ( 10 downlink per day ) ?
Thank for response
All downlinks count, also downlinks sent in response to requests sent by the device. This includes ACKs to confirmed uplinks and responses to MAC requests such as LinkCheck for example.
In Brazil we use the AU915, which is quite similiar to the US915.
Most recent regulation stands that for bandwiths less than 250kHz the transmision should hop through at least 35 different frequencies and the mean dwell time should be under 400ms within a 14s interval.
For bandwiths greater or equlas to 250kHz it should hop through at least 17 different frequencies and the mean dwell time should be under 400ms within a 7s interval.
Is this the same restriction applied in the USA by FCC15? Or does this 14s (or 7s) window actually defines a duty cycle, also?
Anyway, this clearly limits the SF usage, prohibiting the usage of SF12/BW125 since the 1byte payload message would take about 600ms. Is this correct? @htdvisser did such a great job explaining the duty cycle here (https://www.thethingsnetwork.org/docs/lorawan/duty-cycle.html), I would like to have a clear picture about those other restrictions as well.
Could you share (a link to) the official documents here?
https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html 
P.S. BTW, for Russia, freq. plan and the reference to the regulatory document are incorrect.
Hylke knows where to find the TTN documentation, he needs links to the official documentation as provided by the appropriate authority for a country.
You state the information for Russia is incorrect, it would help if you point to the correct information (preferably in English)
I did quite catch him.
GKRCh (State Comission for Radiofrequencies allocation) Decision #07-20-03-001, Appendix 11 (NOT Appendix 10):
864-865 MHz: EIRP 25 mW, duty cycle 0.1% (or LBT, note that there’s no need in AFA), may not be used close to airfields.
868.7 - 869.2 MHz: EIRP 25 mW, no duty cycle limitations.
Also, you may take a look at LoRaWAN regional settings doc:
Yes, sure! I recently updated the links here: https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html
And the official docs are availabel (only in Portuguese 
) here:
http://www.anatel.gov.br/legislacao/resolucoes/2017/936-resolucao-680
http://www.anatel.gov.br/legislacao/atos-de-requisitos-tecnicos-de-certificacao/2017/1139-ato-14448
The dwell time definitions are at the “Act 14448” document, section 10.2
Docs attached, here.
ANATEL - Resolution 680.pdf (94.5 KB)
ANATEL - act 14448.pdf (186.9 KB)
If you need help translating, just ask me!
Regards.
Yes !
I just updated those docs reference about 2 weeks ago. It was incorrect, linking to the old regulation that was revoked by this ones.
@htdvisser, please note that was an error on my annotation. The correct section at “Act 14448” related to LoRa is 10.3. This is the section related to Chirp Spread Spectrum (CSS). 10.2 is related only to FHSS.
Hi all! I have a doubt in the Fair Access policy of TTN and usage policy. Here I’m using Gateway (sx1308, Multichannel, antenna dB: 2dB) and Node (sx1276) for LoRaWAN application at Indian frequency of 865-867Mhz with a range gap of 500 meters between the node and a Gateway. In our project, we need to send an uplink message for 5 minutes once and downlink message for 10 minutes once (from TTN). We have recently tested and get to know the issue like we didn’t receive a downlink message for 500 meters gap only we able to get the confirmed message instead of confirmed ack but for the nearer range we able to get downlink messages with acknowledgment. Now my doubt is…
The limitations are not related to the distance. However, if to get the longer distance you’re using a lower data rate (a longer time on air for the same number of bytes) then you’re obviously using more of the limits for each transmission.
Yes, on the public (free) The Things Network is applies to all users (per node). However, it’s not yet enforced, so any problems you’re seeing are not related to this policy. It could be that the gateway is busy though, but then you’d get an error saying “no gateways available for downlink”.
When enforced in the future, it will likely be per 24 hours. So it might very well be some sliding window, unrelated to a calendar day. If you use all the limits right now, then you cannot use anything for the next 24 hours, regardless in which time zone you’re operating.
Again, your problems are not related to the Fair Access Policy. But you’re definitely exceeding the limits. A downlink every 10 minutes is really, really, not nice. That’s 144 per 24 hours, during which the gateway that’s transmitting those cannot listen to any uplinks. The same applies to confirmed uplinks. So, you’ll need to rethink your use case.
Just an observation but though the regulations (FUP not withstanding) say you 'may’ use up to 1% dc that doesn’t mean you should/can plan on such high utilisation…if you do then potentially just 100 end nodes could swamp a sub band, and that is without allowing for the GW to go deaf whilst doing its ownTx’s e.g. ack’s, join accepts etc. When developing your application look to use perhaps 1/10th or possibly 1/100th of the available limit to be socially acceptable and play nice with all the other boyz & gurlz! 
Look carefully at what you send and how often + how well data compressed (please as others have said on forum threads never send values a ‘text’ fields! 
), is full data value needed or can you average for a period and send less often, perhaps with excursion limits added for compliance checks etc. Can you just send deltas? if no change can you just send a null payload as a watchdog/network check in? Better yet stay silent and only send in ‘alarm’ conditions (unusually rapid rate of change in values or exceeding some some excursion limits etc.) and just check in once in a while so end application knows you are still available on the network etc. Obviously whilst testing & evaluating running closer to dc limit may be ok - for a few minutes/hours but not as a defacto operating mode.
Remember it doesn’t matter whether you are on the public TTN (with potential FUP issues) or TTI (more relaxed?!) or a private instance or even on a totally different network (Loriot, Orbiwise, Comcast, private…etc.) as you don’t ‘subscribe to’ or join with a specific GW (access point) rather your signal is picked up (and potentially forwarded to associated network server) by ALL GW’s in range of your transmission…you might not be running high dc but add in all the other users in range and you can potentially be saturating any given GW instance! 
It is also a good test to consider how your specific application and architecture will behave if you deploy in range of less socially responsible users…can you cope with packet loss & interference etc.?
…consider also might you need to help ‘densify’ the network by dropping additional GW’s in the area where you are deploying to help share the load and distribute access hence helping more nodes to run on short/lower SF’s hence taking less time on air and helping mitigate dc limit issues. I know of many users who are just focused on deploying nodes/sensors in paces where they can see a GW and don’t stop to think hey maybe I should contribute some GW’s at same time…just saying! If someone doesn’t want to get into GW deployment/management contact others in the area you are targeting who do deploy/run GW’s and perhaps offer to contribute hardware or otherwise help fund/sponsor their efforts… 
