I am using 865Mhz frequency in RN2483 Module because that frequency is only allowed in our place.(868Mhz is not in free range).
The default channels (0-2) are set to frequency 868Mhz and cannot be changed. Is it necessary to change the frequencies for default channels to 865 or is it ok to leave it to 868 Mhz.
If it needs to be changed then how to change. Because RN2483 module doesn’t allow to change the frequency of default channels(0-2).
You can set the frequency using something like:
mac set ch freq 0 868850000
mac set ch status 1 off
mac set ch status 2 off
Also, please check out https://www.thethingsnetwork.org/wiki/LoRaWAN/Frequencies/By-Country and let us know what frequencies are allowed in your region, then we can hopefully define an official frequency plan for your region.
@htdvisser
With regards to the frequency plan for India, did you see the announcement of LoRaWAN regional parameters rev 1.0.2B, it includes this:
(@stuartbinny321 mentions he is in India in another thread)
We have a preliminary gateway configuration for India, available on github. I expect it to be ready by the end of the week.
Hello,
What is the more convenient? a per sub-band duty-cycle limitation or per-channel?
Thank you.
I don’t think it really matters, if you follow the Fair Access Policy you will probably never send messages directly after each other.
If you do need to send multiple messages right after each other a per channel implementation will be faster. Since you can send on the 2nd while the first is still waiting. But that will only be faster if the number of messages you want to send is equal or lower to the number of channels in the band.
Else, if you send a message every few minutes, the only difference it will give is the implementation you have to do. Thus it would be your own judgement which is easier to implement. (If it is not already implemented by the chip/library you use.)
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.
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.
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.
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.