You can workaround ERC duty cycle limitations if you use AFA+LBT, which means Adaptive Frequency Allocation + Listen Before Talk. LoRaWAN doesn’t do these things, but in many cases it is possible to use a side band that does, and then use LoRaWAN to communicate basic information back to TheThingsNetwork at low duty cycle. This is a common use-case that Haystack Technologies implements over DASH7. For example, Assisted GNSS, fast OTA-FW, and indoor location. Perhaps others do this too, but I am only familiar with Haystack because it is my company and I know what we do!
Not exactly on topic: But i wonder how it will interfere when our drone guys use their new LoRa based remote controls near TTN-Gateways. http://www.miromico.ch/wireless-iot-158.html They say it is compliant and approved, but a remote control for drone racing is a bit opposite application than daydreaming sensors…
drone guys are not allowed in most city’s, there will be no problem, different technique.
long range drones are in most countries not allowed.
I am developing a product using LoRa in a completely private network (no LoRaWAN involved), with my own protocol, sending data between RFM9x modules, with simple wire antennas, line of sight, low to the ground. I would like to avoid creating issues for other LoRa users in the area and ensure I am operating within regulation. Can I use the 869.52 frequency, in EU, at +20dbm transmit power, with 10% airtime limit on the system, and be safely within spec? If not, how should I set up the protocol?
For the channels with <25khz bandwidth limits, am I able to use 62.5khz or 125khz with LoRa? Are these channel bandwidths and Lora bandwidths meaning the same thing?
Appreciate any help you can offer.
1 Like
Adam, your question is region dependant. You need to check the ISM radio regulations for your area. It is not just a TTN issue. There are other radio systems that operate in the ISM space.
1 Like
Hello all,
I’m working on a topic related to LoRaWAN
According to the setup done, we need to know the airtime of the single lorawan-packets in the uplink PLUS the airtime for the acknowledgement messages from the basestation to the sensor. Here’s the question: does ack messages have fixed spreading factors/coding rates? whats the airtime of a Downlink acknowledgement packet?
It would be really good, if someone could help me out with some reply.
Thanks
Hello,
I am not bale to access any of the sites its showing me an error page …I am working on calculating duty cycle - time on Air, it will very helpful if I have all the related formuals and the spread sheet *(http://www.semtech.com/apps/filedown/down.php?file=SX1272LoRaCalculatorSetup1'1.zip )
(http://www.link-labs.com/symphony-link/ ) can I please have access to this links !!
Thank you,
Best Regards
Suhas
ask the admin on that site… we can’t control that
what if I have 1000 end nodes(RN2483) and try to connect/send to single GATEWAY at same a time. and my end module will again send every 6hr.
please help me
Perhaps some more detail of the question ?
How would 1000 nodes be connecting to a gateway ‘at the same time’ ?
I mean to say " I have 1000 end nodes and single Gateway ", I’ll try to send data to gateway every 1 hour. what are the chances that all my 1000 end nodes get successful transmission to Gateway ?
I am going to set data transmission almost same time.
0%
You will suffer severe loss if you set all nodes to send at the same time.
You must use some algorithm to stagger transmissions over a period of time.
BTW, a node does not connect or send to a gateway, it just transmits and if you are lucky one or more gateways receive the data.
1 Like
Also, don’t forget that you’re using a shared radio spectrum. So, usage of the very same radio frequencies by others will affect your success too. Gateways that are deployed by you, will also receive LoRa traffic transmitted by others. (That’s why a single, large, public network is to be preferred over many private networks. But that’s a different topic.)
say example " I am having 8 end nodes and single gateway " and I am Transmitting almost same time and my time slot for transmisson is 1 hour , what are chances of successful transmission, if not how can I transmit it. and also for 1000 nodes.
Please stop asking the same question with different numbers. 8 nodes, 1,000 nodes, 1 hour, 6 hours, your question has been answered: you simply must make sure the devices do not transmit simultaneously. That’s all we can say. See also How many gateways are needed to support 1,000 nodes sending 10 bytes per 5 minutes? And for those calculations too: take into account that you’re not the only one using the shared radio spectrum, now or in the future.
When you send almost at the same time your interval of all nodes will disperse. In the end any transmission of your 1000 nodes will be practically random and there will be no correlation between any transmission. As a result of this, you will practically not suffer from packet loss due to your transmission scheme or strategy. To even further minimize the effect of correlation you can add little randomness to your hourly scheme.
Are you implying that the devices’ clocks are running slow or fast? Assuming that the clocks are okay, and 1,000 devices transmit on the hour (say one o’clock, two o’clock, and so on), then I’d say they will keep transmitting simultaneously forever?
Of course, when transmitting at a fixed interval (which might start at the time of installation), all devices will not transmit simultaneously.
(@vinayakmp, even when measuring on the hour or at other fixed times, a device does not necessarily need to transmit that measurement right away. Like when used for billing, a device has almost a full hour to get its reading to the server and still be in time to take the next hourly measurement. For measurements every 6 hours things are even better of course. And, as this is radio, there’s never a guarantee that you will get all measurements.)
Yes I do. The inaccuracy of average clocks and clock implementations ensures drift in practice.
When you equip all 1000 nodes with atomic clocks you will suffer for a long time of packet loss because they will send at the same time.
Btw did you consider the effect of difference in rssi for all nodes? I presume all 1000 nodes are received with the same (exact) rssi?
Hey folks,
dealing with implementing a duty cycle limit on Network-Server side, there popped up some questions marks. I’m mainly referencing European regulations, as I’m dealing with EU868 band.
-
I often read somethin like: When a device transmitted xxx milliseconds, then the channel is not available for another xxx milliseconds. I wonder where this regulation can be found? Neither from the ETSI standard nor from LoRaWAN specs I can understand this interpretation.
-
Wouldn’t sending 20 packets of 1560 ms airtime (SF11@125kHz) every 2 seconds (thus <0.5s between each transmission) followed by silence within 1hour be still following duty cycle limit of 1% ?
This point makes a huge difference in the implementation. Thanks in advance for hints.
In general the precise detail you are after is in the regulations of your particular country.
For the UK if I want to know the duty cycle allowed at a particular frequency I would check the IR-2030 document produce by Ofcom, the UK regulator. Those regulations do in turn reference the particular European standards.