I am trying to integrate an external gateway that pushes UDP packets to a third party lora gateway bridge. Is there any configuration within the RAK7249 that allows it to receive such packets?
Alternatively is there some documentaion/explanation as to how the RAK7249 Lora Server Stack works? I am assuming that the Lora Gateway Bridge is already embedded in to the gateway and then the gateway forwards the data through an internal MQTT bridge to the Built-In Lora server. Is this correct?
Thank you Nicholas for your quick response but I think I worded my question wrong. I’ll write it down in dot points and then maybe I can communicate it better with more information as to what I am asking.
My questions broken down in further points are:
Can those UDP packets be forwarded from another gateway to the Build-in Lora Server of the RAK7249 or is that something just not possible?
If not: Does that mean I would have to integrate both RAK7249 and gateway X to a system like the chirpstack network server so I can manage both gateways?
If yes: How would that be possible?
Dear Sebb,
I see what you mean. You want to make networking happen！
Please refer this web：https://doc.rakwireless.com/rak7249-macro-outdoor-gateway/rak7249-build-in-lora-server-multi-rak-gateway-mesh-rak811
Best regards！
While you can do this, typically in practice once you have multiple gateways it makes sense to run the lorawan network server component (which in this case is an older version of the project now known as Chirpstack) in the cloud rather than on the gateway.
One reason is that it’s typically easier to get Internet connectivity from a gateway to the cloud, than it is from gateway to gateway. Another issue is reliability - your node session data sits in the cloud and hopefully offline backups), not on a field deployed box which could be damaged or stolen.
An additional potential concern is that the other gateway currently forwarding to chirpstack via a bridge may be ending up with a newer version of the chirpstack MQTT bridge protocol than the server built into the 7249 may support. But you can try it, and if you really want to you can find a version of the gateway bridge component which speaks the older protocol.
@Nicholas Yes networking! (not my biggest strength) but I will try and give it a go using the guide however the brief reading I’ve done on that guide and from my understanding the lora network server works such that.
My point being is that I highly doubt gateway X has a Lora bridge configuration on the actual gateway because on the config.json file it expects to be given a server address with port 1700 which is the most “common” Lora gateway bridge port. Which then makes the external MQTT broker arrangement hard to make it work. Gateway X runs openwrt so I will try and install a mosquitto package and give it a go to see what happens, thank you for your suggestion and information.
@cstratton Thank you for your response as well and I think you have put forward some very valid points that makes taking care of the Lora server stack somewhere else other than the gateway as a preferred arrangement. Being reducing the risk of single point of failure host it somewhere else and interoperability of communication protocol versions as you mentioned. However I just have some queries in regards to part of your statement
In this scenario the gateways will be on the same network so gateway to gateway communication is not too much of an issue but I think I understand what you are saying, a “physical layer” of communication between gateways is not the easiest thing to achieve. That being said, you kept mentioning cloud installations but due to a limited internet connectivity of this deployment it might be difficult, hence why I was trying to leverage what was already there. Do you think a self hosted Lora network stack on a local server would be sufficient in this case?
This is actually fairly meaningless, as that’s the standard port for all of talking UDP to a network server, talking UDP to an external UDP-to-MQTT bridge, and talking UDP to an internal one.
Not at all. You’re likely to have more luck with an external bridge than trying to get one to run on your mystery box (Dragino?) and anyway, the bridge is entirely independent of the broker.
Your insistence on referring to Gayeway X rather than just telling us what it is, is going to hamper our ability to advise you?
I can’t imagine why you need to keep it’s identity secret.
And if it’s all on the same lan, why not run Chirpstack on a small device?
@cstratton Completely agree with you that the UDP port number is trivial therefore meaningless. Hence the quote marks on most “common” port. But it is however part of the gateway packet forwarder server settings which led me to assume that is how it works. And yes completely agree as well that it could very much be just a port where the data gets sent to and from there it gets distributed based on the network architecture. Which is kind of like how the RAK7249 seems to work when using the build in server. It binds the internal UDP communication port to a MQTT bridge that then talks to the built in server or at least that’s how I seem to understand it.
“gateway_conf”: {
“server_address”: “x.x.x.x.”,
“serv_port_up”: 1700,
“serv_port_down”: 1700,
“keepalive_interval”: 10,
“stat_interval”: 30,
“push_timeout_ms”: 100,
“forward_crc_valid”: true,
“forward_crc_error”: false,
“forward_crc_disabled”: false,
“gps_tty_path”: “/dev/ttyS1”,
}
Yes also agree, I may need more luck with getting the product developers to reply to any of my queries. But completely in line with your statement, and based on your previous advice I’ve already started working on the external solution.
I somewhat understand where you are coming from and I appreciate your help and knowledge. All I was trying to do was the whole let’s keep it professional and let’s not name and shame in the event of the other gateway was the issue. Having said that, their product documentation is not the best and I would say for an “off the shelf” product, it is designed such that you are expected to know a bit more than average about Lora (I am trying to get there slowly) or at least when you compare it to the RAK7249. I’ll give you a hint the name doesn’t vary much from what I’ve been referring to it, instead of gateway change it to something that you use to start a fire.
With @cstratton previous advice and stated in my last reply, that is what I am currently working on. I just wasn’t sure that was the right course of action.
