Hi everyone! Can I use LoRaServer to make my own private network on Dragino LG308 gateway? If it’s possible, can you give me reference to do this
Actually running the core components of LoRaServer on the LG308’s little AR9331 SoC which comes from a series of chips designed to be a cheap entry level wifi routers is probably too much of a stretch, especially given only 64 megs of RAM.
However, a more traditional setup (and really the only thing viable when multiple gateways are involved) is to run the server on traditional server infrastructure (often cloud instances) and just have the gateway fulfill the traditional role of a LoRaWAN gateway in being an RF-to-IP translator with no real “knowledge” of the information flowing through it. To do that, you would install LoRaServer in the cloud as usual, and point the gateway at it.
The remaining question is where to install the gateway bridge; it’s probably simplest if you put that in the cloud as well and use the Semtech UDP protocol over your Internet backhaul between the gateway and the server host(s). With some effort you probably could move the gateway bridge (or at least something filling that role) to the gateway itself (as is commonly done with gateways having more compute resources) but that’s a fairly advanced subject, and not a requirement to get things basically going.
Thank you for your response, How can I install LoraServer in the cloud? Can you give me the reference of tutorial to do this?
Follow the usual instructions as that is a completely normal install.
Oh I see. After installing LoraServer in the cloud, Do I still need internet connection to operate the gateway? The system will be used in the remote area which has no internet connection
You will need some means for your gateway to communicate with the network server. Whether that’s ethernet, cellular, or carrier pigeon is up to you.
In that case you should probably place a suitable embedded server beside the gateway.
A Raspberry Pi3 can do the job for a small network, but its use of an SD card doesn’t make it particularly reliable for something you cannot get access to in order to maintain. You could always prepare a few spare cards and tape them to the case to simplify maintenance by someone else if card corruption is suspected. It might be better however to use a compact PC - and again, recovery media would be good.
Can I use ethernet instead of Raspberry Pi3 to connect the gateway to the network server?
I have just released an IPK package of the ChirpStack Gateway Bridge which you can install on the LG308 gateway. Please see for instructions: https://www.chirpstack.io/gateway-bridge/gateway/dragino/.
@brocaar , why do I need the package? I setup the LG308 to send raw lorawan package through mqtt without installing any package and it seems to be working fine. This is how I set it up:
Is there any functionality I am missing by not installing the Gateway-bridge package?
What format are those payloads being forwarded in? It seems unlikely it’s the ChirpStack protobuf format, unless documented as such.
I’m not sure, bellow is screen-shot from MQTT explorer, topic gateway/a840411d15384150 contain data from Dragino LG308, the other two topics are contain data from 2 Kerlink gateways with GWB installed on them.
Just got an interesting interesting answer from Dragino support:
Do you want to use LG308 to send LoRaWAN packet through MQTT? it doesn’t support this feature yet.
Interesting, because I’m currently using it to send LoraWAN packages through MQTT to ChipStack server, so obviously it support that feature somehow.
I think I have an idea what happened.
What I thinks happen is that because MQTT sending is not yet supported, when selecting IoT Service “LoRaWan forward to MQTT server” it instead works as standard “LoRWan forward”, i.e. it sends the raw LoRaWan package to port 1700 on ip 10.0.0.232.
On ip-address 10.0.0.232 there is an active ChipStack gateway-bridge that will convert it to MQTT and put in on the MQTT-broker, i.e. what I see on the broker is from the gatwaybridge on 10.0.0.232, not from the dragino LG308.
That would explain why it is in the correct the common data-format (JSON and Protobuf) that allow the chipstack to receive the message.