And how to do it for digital agriculture step by step.
I talked about different communication options for digital agriculture in the previous article. Among few choices we have selected LoRa LPWAN.
What is the difference between GPRS and LoRa from point of view of the end user and company? Well, everything is different.
Switching from GPRS to LoRa means almost complete redevelopment of the product line. But more important is the changing of business concept.
GPRS installation is relatively plug and play And can be done by customer. LoRa needs installation of gateway, authorisation of every device and adjusting of radio communication. Big network needs planning of toplogy. How many gateways and where need to be installed. This needs special installation engineers or education of customers. Quality of radio signal can be changed by time because of appearance of different natural and artificial obstacles such as plants or constructions.
In case of GPRS, GSM technology has taken care of all these problems.
The need of gateway
Gateway is one of the most complex and expensive parts of LoRa network. In fact it replaces GSM tower if we compare to GPRS based system. Price of industrial grade outdoor gateways easily reach 1000 USD. In agriculture, LoRa network is relatively sparse meaning we have few devices scattered over big area. Assuming 2 gateways cover 10km in rural areas, it would require 2 gateways per 300 Ha. Let’s round up and take 2 gateways per 200 Ha.
The need of Internet connection
Gateway needs permanent Internet connection. It could be landline, 4G or WiFi.
The need of power
Permanent Internet connection requires lot of power. Most of gateways are designed to work with power lines and not optimised for power consumption.
Typical 4G gateway would consist of LoRa gateway and 4G router.
The need of LoRa server
Contrary to what you might think, having the end device and gateway still not enough. Software of the gateway is very simple. Basically it can only forward the packets between Web server and end device converting from LoRa protocol to HTTP and back. All intelligence takes place at the servers side in a special tier called LoRa server. LoRa server has many functions to control the whole network and pass data to our application server. Among other functions, LoRa server removes duplicate packets, decides about communication channels and sending power of the nodes, stores data packets from network and server. In other words, gateway is a dummy packet forwarder between the end devices and LoRa server. This design solution has its advantages and disadvantages. It should keep the gateways simple, compatible and economical. Yet the former isn’t true by some reason. Hopefully price will drop when more products appear on market.
Because server software is very complex and not easily available, in many cases it might be better to use 3rd party commercial servers as service. There are quite many offers on market such as the things network and Loriot. Many new are coming. They may charge per number of gateways or end devices per months and offer different services. Application server may communicate with 3rd party LoRa server via HTTP API or MQTT.
The need of MQTT
Another new player on the LoRa scene is MQTT (Message Queue Transport). Strictly speaking it’s not a standard part of LoRa protocol and is optional. MQTT is a lite weight message broker with very small code footprint. It can be used in any system to allow message exchange between devices and software modules. Module can subscribe to MQTT broker and exchange the messages with other modules.
All existing implementations of LoRa server can exchange data with application servers via HTTP API and MQTT. So what is wrong with the HTTP API and why we need MQTT? The problem is that HTTP is polling API server and application must be pulling it to check for new data. This is very ineffective. We want LoRa server to push data to the uset applications immediately upon arrival. This is exactly what message broker can do. Application subscribers for certain types of message and broker will push these messages automatically using message queue. As mentioned above, LoRa server already supports MQTT. We need to add MQTT client to our application.
This is the todo list of walking from GPRS to LoRa.
From development point of view
- Develop the end device with LoRa class C communication
- Choose a gateway suitable for your application
- Install LoRa server or buy subscription from 3rd party server
- Add MQTT support to your application
From business point of view.
- Add cost and procedure of installation of 1-2 gateways for every 5 km and registration of end devices
- Prepare technical support department for installation and technical support of LoRa network
- Find solution for permanent Internet connection. It could be, for example, 4G router with Ethernet port.
- Find solution for power of gateway and 4G router. In most of the cases gateway can be installed at nearest building that has power line. In special cases solar panel and rechargeable battery could be used. It should provide at least 3-10 Watt depending on gateway and router.
It seems much more complex compare to GPRS but most of work is one time development. Regular extra cost is gateway hardware, installation of network and technical support.