Hi, can I ask anyone who has tested to join Rak811 to MultiTech conduit, or used mDot join to RAK LoraWAN? Since they are different specification, I like to know how good the compatibility between them and the performance.
The first thing to realize is that a LoRaWAN node joins a network run by a network server, not a gateway.
The gateway in use should be irrelevant, as the gateway is merely a transparent translator between LoRa air modulation and IP-network backhaul.
If you use the built in LoRaServer (now “Chirpstack”) server that can run as an optional feature on the computer contained in some of the RAK gateways, then what you really have is a question about interacting with that software, not about the gateway.
Thanks for explanation the meaning of server and gateway. My project is proposed using a private LoraWAN server not on TTN.
What I want to do is to verify the mDot connect to RAK server because I can use mBed to make program with PWM and multicast in mDot, to test RAK server with end Lora nodes. I don’t know if it is feasible?
I have found RAK sever lost Application all setting with all devices information for unknown reason, do you have a way to make backup of the Lora gateway setup? If that is a issue you may need to rise attention because it is a serious flawed.
Realistically speaking, running a network server inside a gateway is mostly suited to demonstration and “would this work for our need” evaluations. It’s convenient to be able to just plug a box in and register some things in a web gui, but limited.
For one, it doesn’t really work once you have a network with more than one gateway, which (even simply as a matter of redundancy) would be most real-world networks - even if the server will accept external connections from other gateways, most readily available Internet access subscriptions don’t readily permit incoming connections, so moving data between boxes almost invariably involves bouncing it off the cloud (ie, putting the MQTT broker there).
At that point you might as well put the server itself in the cloud, where it is more easily administered and backups can be more readily made.
With LoRaServer / Chirpstack there are some specific redis settings necessary to persist session information, and you’d also want to be sure you are handling the postgres database of node records suitably. That’s especially true if you run them in docker containers which may not be default have storage that persists across runs at all.
Exactly, the only thing in the real task is when you deal with hundreds of Lora end devices (lights), the response time delay using public LoraWAN will be a problem, such as when you want to turn on the light one by one without using multicast. While in other cases if your area has a network server and only for demo purposes (such as TTN) then it better to use it and save money for buying a gateway. For me, it is an issue when RAKWIRELESS platform development still in-completed, it is difficult to develop an application base on it.
LoRa Network Servers don’t really cost much money. You need a relatively low-end server instance somewhere - until your network is large a cheap cloud instance would do - as evidenced by the fact that you can run one on the truly tiny Linux SoC contained in a gateway itself.
For me, it is an issue when RAKWIRELESS platform development still in-completed, it is difficult to develop an application base on it.
While some of the reliability issues may be due to how it is integrated in the gateway and especially the limited options for storage there, the server in the box is not actually RAK’s software - it is merely their build of an external open source project, Chirpstack.
An instance of that running in the cloud would be one of the leading candidates for an external server, too - and in that case you take on the responsibility of correctly configuring it to avoid the problems you have been seeing.
Exactly, the only thing in the real task is when you deal with hundreds of Lora end devices (lights), the response time delay using public LoraWAN will be a problem, such as when you want to turn on the light one by one without using multicast.
If this is your goal, LoRaWAN may not be the right choice. It’s not a question of public versus private networks, it’s that LoRaWAN has a rather limited downlink capacity compared to its uplink one.
That is why I need Multicast. Multicast sends one downlink msg to all nodes in the multicast groups.
I get this https://www.chirpstack.io/gateway-bridge/gateway/multitech/
which introduce upgrade MultiTech Conduit firmware to Chirpstack gateway bridge, I don’t know if anyone actually did this, but it is interesting. The problem I think it will be the hardware in the conduit which only have 400Mhz cpu and small memory, limited the performance of itself running in AEP firmware as well in Chirpstack firmware.
I am using Conduit for Multicast download but it very long delay when increased number of end nodes. That is why I am looking for alternative gateway like RAK server. I would like to try multicast in RAK server but lack of documentation such as sample code, hope someone will open source to share.
That is why I need Multicast. Multicast sends one downlink msg to all nodes in the multicast groups.
Maybe
I get this Multitech - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server
which introduce upgrade MultiTech Conduit firmware to Chirpstack gateway bridge
That is straightforward. But the RAK gateways already have the gateway bridge. Or you can point their UDP protocol at a copy of the gateway bridge running in the cloud.
The problem I think it will be the hardware in the conduit which only have 400Mhz cpu and small memory, limited the performance of itself running in AEP firmware as well in Chirpstack firmware.
This is not an issue if you run Chirpstack in the cloud rather than on the gateway.
I am using Conduit for Multicast download but it very long delay when increased number of end nodes.
That problem is likely inherent in the scheme, changing the gateway is unlikely to make any difference. It’s also possible you aren’t actually accomplishing multicast.
That is why I am looking for alternative gateway like RAK server.
You seem to again be confusing the role of gateway vs. server
I would like to try multicast in RAK server but lack of documentation such as sample code, hope someone will open source to share.
Since multicast is a function of the server and not of the gateway doing this with a RAK gateway is no different than doing it with a Multitech one - just point it at the same server.
But it is also not likely to lead to any different result, because your issue is with the goal and the way the server and nodes implement that, not with the gateway.