Lora network server

[Gerben van Eck]

I see that the Lora Gateway / Server is combined in the Conduit. From the Lora theory I understand that one of the functions of the server is de-duplicating messages.
In the architecture I’m currently thinking of based on my current understand of Lora, the ‘lora server’ would proxy all messages to an application server ready for processing, and vice versa, the application server can send all messages to the lora server and it would take care of it being delivered to the correct gateway + node.
If I have multiple conduits receiving a message from a Lora node, would my application server receive it multiple times?
Is the Lora Network Server available and able to run on a regular server in a datacentre, or are there any production ready alternatives?

[Brandon Bayer]

Gerben,

It sounds like you have a good understanding of this!

If you set up multiple ‘stock’ Conduits all pointing to a single application server, then yes, the app server would receive duplicate packets if more than one Conduit received that packet.

As of network server version 0.0.9, it’s possible to configure one Conduit as the central lora network server with other Conduits configured as packet forwarders that forward packets to the server Conduit (all Conduits would need a high-speed internet connection).

Another option is to use a public lora network server such as Semtech’s.

-Brandon

[wojtek t]

Brandon,
Could you please elaborate on how to configure it to listen on the public interface and not only on the localhost address?
Wojtek

[Jeff Clemmer]

I’m also interested in how this is configured. I was told by someone from Multitech that this wasn’t possible, even in 0.0.9?

Thanks

[wojtek t]

Anyone?

[Jason Reiss]

This page describes the options available in the lora-network-server configuration. The “allowPublic” will open UDP ports on the external interfaces.

Conduit mLinux: Advanced LoRa Configuration

[wojtek t]

great,
However, I am having difficulty adding it on the AEP unit.

curl -m 5 -s 127.0.0.1/api/loraNetwork?method=PUT&data={“udp”:{“allowPublic”:true}}
returns unknown element.
and actually i don’t see it there:
admin@mtcdt:~# curl -m 5 -s 127.0.0.1/api/loraNetwork
{
“code” : 200,
“result” : {
“addressRange” : {
“end” : “FF:FF:FF:FE”,
“start” : “00:00:00:01”
},
“db” : “/var/run/lora/lora-net-server.db”,
“log” : {
“console” : true,
“level” : 100,
“path” : “”,
“syslog” : false
},
“lora” : {
“enabled” : true,
“frequencyBand” : 915,
“frequencyEU” : 869500000,
“frequencySubBand” : 7,
“maxTxPower” : 26,
“nodeQueueSize” : 16,
“rx1DatarateOffset” : 0,
“rx2Datarate” : 12
},
“mqtt” : {
“enabled” : true,
“host” : “127.0.0.1”,
“port” : 1883
},
“network” : {
“eui” : “02:00:….”,
“key” : “2b:7e……..”,
“leasetime” : 86400,
“name” : “”,
“passphrase” : “”,
“public” : true
},
“udp” : {
“appPort” : 1784,
“appPortDown” : 1786,
“appPortUp” : 1784,
“downstreamPort” : 1782,
“upstreamPort” : 1780
},
“whitelist” : {
“devices” : [],
“enabled” : true
}
},
“status” : “success”
}

Thanks
Wojtek

[wojtek t]

Just for clarification, I am still on 1.0.33, so perhaps it will be available with the latest 1.2?
Wojtek

[Jason Reiss]

I am seeing the issue using curl.

However if you web to the Conduit web gui.
When entered through the browser URL after logging in the query is accepted.

https://[AEP-IP]/api/loraNetwork?method=PUT&data={"udp":{"allowPublic":true}}

• This reply was modified 8 years, 9 months ago by Jason Reiss.

[Jason Reiss]

Here is a curl example that works.

curl 127.0.0.1/api/loraNetwork -X PUT -d '{"udp":{"allowPublic":true}}' -H "Content-Type: application/json"

• This reply was modified 8 years, 9 months ago by Jason Reiss.

[wojtek t]

Jason,
This is what I get with a browser:
{
“code” : 400,
“error” : “Error parsing URL JSON data [* Line 1, Column 2\n Missing ‘}’ or object member name\n]”,
“status” : “fail”
}

and this is what I get with curl:
admin@mtcdt:~# {
“code” : 400,
“error” : “path [loraNetwork] leads to an incompatible element. Path Element Type [OBJECT] Update Data Element Type [NULL]”,
“status” : “fail”
}

Again this is AEP version now upgraded to 1.1.2

[Jason Reiss]

The above posts had the ‘”‘ elements changed to not be quotes.
I have fixed the above posts. Let me know if it works now.

[wojtek t]

“udp” : {
“allowPublic” : true,

Thanks 😉
Wojtek

[Ashu Joshi]

While I think I get the difference between the lora-network-server and the pkt-forwarder – I am trying to dig deeper and understand it well. I had built a program that works well – it reads temperature and light sensor and is successful in sending it to the Gateway – see here: https://developer.mbed.org/users/AshuJoshi/code/mDot_LoRa_Connect_Example_GroveSensorTem/. It is basically an extension of the LoRa Connect Example published by Multitech.

I had set up a remote MQTT Broker and the Conduit is able to publish to the remote broker (the remote broker is mosquitto running on my Mac – and the Mac is on the same network as the Conduit).

What I tried doing was to go to the lora-network-server script in /etc/init.d and commented out running the pkt-forwarded – when I do that the above mentioned setup stops working.

So my two-fold question – is there a good explanation somewhere of what each do especially a visual kind of diagram? This gateway was previously setup to use with TTN but I went through all conf files to see if there is some setting that may collide or conflict. So is there description or details for how lora-network-server works? And has MT made it open source?

[Ashu Joshi]

I made another interesting observation with respect to my last issue which I am observing. I have been looking at the ports very carefully. It turns out that the basic_pkt_forwarder is not picking up the UDP ports from either global or local conf json files. I do know the files are working because it is correctly picking up the Gateway ID from the loca conf json file. Right now the UDP upstream port is 1780 and downstream to 1782.

My bad – was looking/editing the wrong conf file directory…

• This reply was modified 8 years, 5 months ago by Ashu Joshi.

[wojtek t]

Hi,
You always need a packet forwarder!
So, if you speak to TTN, you have a semtech bridge converting RF signal (Lora) to IP and packet forwarder sends it to the TTN LoraNetwork Server. If you use the server on your local conduit, its similar, except that you send it to the localhost for further processing. In case of 3rd party server, there is still no difference, you just agree on a port (udp 1700 for example) and configure your packet forwarder to speak on that port to your lora network server
Here is an example of 3rd party, http://loraserver.readthedocs.io/en/latest/

[wojtek t]

basic_pkt forwarder uses those ports for communication with the Network server,
so its SENDING packets out using those ports…unless you are referring to downlink which will only happen after you send a packet (class A)

[Ashu Joshi]

Thanks a ton … clear. Now I understand where the ports were configured – rather it makes sense now because the lora-network-server has to be listening on the same ports 🙂

[Author]

Posts