Issue: RAK free cloud LoRa server for testing
Setup:
Server:
Details:
Hello
I have a RAK7204, (LoRa Environmental Sensor), and a Kerlink gateway, and I would appreciate it if you could let me know 1) whether I can use RAK free cloud LoRa server for testing my RAK7204 with my Kerlink gateway?
and 2) about the maximum duration of this account
3) I also cant reach http://docs.rakwireless.com/en/LoRa/RAK2245-Pi-HAT/Application-Notes/Get_Start_with
_RAK2245&RAK831_RPi_LoRa_Gateway.pdf
about ';How to register my LoRa gateway", error 404 apperars.
4) RAK free cloud LoRaServer for testing! is closed for requesting an account
Best regards,
ANY and ALL gateways hear the transmissions of anything LoRa in the area. If it’s a properly formed LoRaWAN packet It then forwards it to the network server to process.
So you can do scalability testing but it won’t mean much if you end up deploying your gateway where there is already a lot of radio traffic.
Also, to meaningfully test a gateway you are going to need a fair number of devices, all potentially exceeding the local legal limits - or a few thousand devices to stay in the limit.
TTN has NOTHING to do with radio traffic in your local area. It would be the same if you used any other provider, if the RAK server was still available or if you ran your own server. It’s all about any radio transmitter on the 868MHz unlicensed band in the area you deploy your gateway.
Unless you have hundreds of devices or some implementation that means they all transmit at the exact same time, then changing uplink intervals is academic. Same for packet size although the smaller the better as it reduces the chances of interference.
There is no latency with radio waves. Once the gateway receives an uplink, it passes it on with its timestamp and the network server adds a timestamp. Overall I see uplinks being heard and processed in a matter of milli-seconds and isn’t a factor unless you are on a mobile internet connection.
These questions, which I answer all the time on the TTN forum, are best answered when we get some actual hard facts, like how many devices you expect to deploy, rough indication of how often they would uplink and size of payload.
Regardless of what network server software or instance you use, in most places it would not even be legal to operate a single or even small handful of nodes in a manner which actually caused a scaling problem.
You likely need to spend more time understanding the issues in concept, before you consider running any on-air tests.
@cstratton
even if I use my gateway? and do you know where I can read about this type of legacies for my place? because my teacher wants me to determine maximum and minimum interval transmission and set that as much as possible. you mean it would make problem for me? I have only one device (RAK) to test and one gateway
You appear to have removed a post to which I replied, please don’t do this, it makes a nonsense of the flow of the topic.
Yes, it’s not about traffic on your gateway, it’s the legal limits of using the various radio bands, perhaps some Googling to find out the EU law?
Very very hard to respond to this because you removed the post about testing the number of devices.
I think your teacher should perhaps consider if they are about to land their student in some legal difficulties. And perhaps a little more about the basics of LoRaWAN.
The overall question you’ve put this time is answered completely and simply by using this calculator:
Hi @nmcc,
sorry, I removed them because I thought my previous explanation regarding the test made misunderstanding about the number of devices because currently I only have one RAK7204, and I mentioned that in the post after that. After your reply I read more regarding LoRaWan and understood the limitations for interval of sending data should be considered for each device, and the number of end devices does not matter, and I should consider the limitations and regulations for interval of sending data with one sensor if I want to do scalability test (of course not in TTN) (I should mention the purpose for scalability test was to know that the allowed interval of sending data is suitable for our use case or not and we need another network). Thank you very much @nmcc and @cstratton for informing me. As I ’m new on this, these days I studied more regarding that, and I decided not to do scalability test on LoRaWan until my knowledge get improved and consider the precise limitations. Hence, I only want to connect my RAK7204 to the TTN, and I greatly appreciate if you could advise me regarding some questions:
In the “quick start guide” on RAK’s website: Quick Start Guide | RAKwireless Documentation Center
to configure the sensor and connecting that to TTN, It is not mentioned to use the AT command: “at+set_config=lora:send_interval:X:Y” in serial port tool to set interval of sending data 1) Is it use a default interval? 2) and if yes how much is the default number for interval of sending data? ( I know it is based on payload size and duty cycle, but I get confused whether it is necessary to set an interval for configuration or not?)
are those steps on that document enough and it is not needed to set that?
3) is ADR function open by default? 4) and is it better to open ADR to achieve better battery life? is it needed to set a specific SF for example SF7 for better battery life? or some settings to get some SF off is needed based on regulations for EU868?
5) If I connect my RAK7204 to the TTN (with OTAA mode), can I connect that to ChirpStack latter? I mean disconnecting to the TTN by deleting application and resetting the device?
I deeply apologize for many questions, and thank you very much for your help and advice.
No LoRaWan network (not Chirpstack or TTN or any other) is a “fog” system, because LoRaWan fundamentally requires centralized knowledge and tracking of nodes and their interaction state (session secrets and uplink and downlink frame counters). No meaningful computation occurs on LoRaWan gateways, but only on the network server, which by fundamental design must be centralized in terms of knowledge and real-time coordination.
If you use multiple local instances of Chirpstack, then your node has to be registered with one particular locality (it must never be registered with more than one!!!). As such you lose the redundancy of how LoRaWan’s feed to a central server is designed to combine the reception capability of all gateways in range, and you lose the ability of a node to move between the coverage of different gateways, since it would be rejected as unknown traffic by any server instance (Chirpstack or otherwise) other than the one (and only one) with which it was registered.
You need to be approaching this project as one of coming to a theoretical understanding; there’s very little use for actual experiments, and no point at all to experiments designed or conducted in the absence of understanding.
Once there is an understanding, pretty much all research papers on the scalability of LoRaWan and related schemes use modeling, not real world tests - because models are scalable, while experiments are not.
@cstratton thank you very much for your response. Yes I know they are not a fog system, and I should use a predesigned specific platform for that deployment in which ChirpStack is used, and I want to know that if I connect my RAK7204 to TTN, is it possible to change that latter and my RAK7204 joins another network Server (a deployment of a specific platform in which chirpStach is used).
My personal opinion would be to recommend that you not try any experiments with actual physical devices until you’ve read enough about how LoRaWan works to understand the answer to that question on your own - starting from clarity over exactly what it means to “connect” or “join” in the context of LoRaWan.
If you were trying to use a LoRaWan system for an actual purpose, that recommendation might be different. But you’re trying to do academic research, and that makes experiments, choosing devices to purchase, etc entirely pointless without a sound understanding to be designing meaningful experiments.
thank you @cstratton
You right, I read how LoRaWan works, and thank you for your recommendation I will continue doing that, but at the moment I can not be sure about my answer as I have no practical experience, and unfortunately my time is being expired and is extremity limited for implementing a cloud deployment as the purpose of project is that platform. I guess it would be ok if I delete the application in TTN in which I added my device and reset RAK7204 configuration, and then configure the device for the new deployment to join new network server. am I right? I would truly appreciate if you could advise me regarding those questions for cloud deployment.
That’s why you need to make sure you spend your time doing something meaningful, and not in setting up meaningless experiments.
The scientific method is to decide what you wish to measure, then design a meaningful experiment to effectively measure that.
Most LoRaWan research papers use simulated networks, not real ones, because simulation is the only realistic way in terms of time/money/regulations to have an experiment which approaches capacity limits.
Experiments with physical devices are necessarily on a smaller scale and so would be limited to testing assumptions of a model. Sometimes you can also take a data set and re-analyze it to gain insight into how a different type of system would have behaved. For example, if you have a LoRaWan network where the feed from gateways is combined, you could examine the gateways recorded as reporting in each packet, and determine how much worse things would have worked out if each of those gateways had its own independent chirpstack running its own single-gateway network, instead of being one combined network in the way that LoRaWan is designed to work.
If someone else wishes to answer your specific question, they may chose to.
It is for an actual purpose of gathering sensor data for a environmental purpose, but with that platform, but before that they want me to deploy cloud implementation with TTN. Thank you very much if someone could help me regarding those questions.
As Chris says, you can hardly run any form of practical trials to supplement your theory if you don’t control as many parameters as you can. So why not just set the interval, you have to use the Serial Tool to setup the LoRaWAN settings, so it’s not a huge step to do that as well. Maybe someone from RAK knows what the default is but as suggested, it’s not relevant.
As above, just set it, it’s five seconds to set to something you know.
This is all about you learning LoRaWAN.
These devices are not sentient - just change the settings to suit. Or not, as the same settings will work on ChirpStack as your gateway will be pointing at that rather than TTN. But it would be preferable to change the AppKey to save any possible confusion with another gateway connected to TTN hearing the uplinks.
Do NOT delete anything on TTN until you know what the effects will be as some configurations can not be re-entered once they have been deleted. There is no need, if you want to differentiate between networks, change the device.
For TTN I’d suggest you review the following as a minimum:
The concepts are universal, much of the configuration is specific to TTN but there will be similar configurations required on ChirpStack.
If you have to do this work in the next couple of months I’d look to using TTN v2 as it is somewhat simpler but if this will run in to summer by which time v2 will be discontinued then I’d look at TTN v3.
hi @nmcc
Thank you very much for your reply, explanations and recommendations, I appreciate them.
I want to configure RAK7204 and connect it to TTN.
in order to calculate the airtime and interval of sending data for configuration, I guess RAK7204’s payload size is 19 bytes and I donot know whether I should add 13 bytes overhead to this or not, I mean considering payload size= 32 bytes in calculator or 19 contains the overhead.
I want to set D5 because my gateway and device are close, so there is no need to open ADR. other parameters are Class A, OTTA and EU868.
Considering payload size 19 bytes, the interval of sending data=207 Is it ok that I set 210 s for configuring the device? (3.5 m)
do you think this configuration is ok based on regulations and TTN ?
and I do not want to set the type of messages as confirm or unconfirm because I am not sure which one I is better for this configuration considering the interval=210.
is setting the power(dBm) needed for this configuration?
thank you very much and I greatly appreciate your help and advice.