- 102 - The node to node implementation, on the other hand, does not make use of a gateway, and data is transmitted directly to a LoRa node which is essentially a transceiver. There are many off-the-shelf implementations of the LoRa PHY, but this research implements using the SX1276 LoRa radio module, open-source libraries for the sx1278 module is also adaptable to use with sx1276.
When implementing the code for the microcontroller to set up and implement the LoRa node, careful consideration must be given to comply with the guidelines/rules of the LoRa alliance.
The interface between the LoRa radio module and the microcontroller is SPI.
Figure 4.7: LoRa node receiver with IP/LoRa Bridge
- 103 - PHY format to IP, parsing the data in the required format for the SCADA device driver to handle. The serialisation of the data from LoRa to IP would be carried out by the microcontroller, which in this case is the STM 32 device interfaced with an ENC28J60 Ethernet module. The output of this Ethernet module is UDP.
The bridge is simply a high-performance device to connect two dissimilar or similar networks.
In this research, our specific need is to connect/ translate the format of the LoRa message to IP format for parsing the acquired data to the SCADA system. Once the data is presented to the SCADA system with the familiar format that the SCADA device driver can recognise, it can be further de-serialised /translated by the SCADA device driver to be processed by the SCADA system. The device driver of the SCADA system (Ignition in this research) will connect to one or more ports on a given IP address and bring in any data as a value of a tag.
For this research, we will parse the data as UDP data, and thus the device driver of the Ignition SCADA system will only listen/read the data from the LoRa device via the IP/LoRa bridge.
Figure 4.8: ENC28j60 interface used to connect LoRa Receiver to SCADA Server
Both LoRa and Ethernet have different frame formats and practice other MAC mechanisms and routing algorithms. Because we are using the LoRa node to node implementation (LoRa
- 104 - physical layer and not LORAWAN communication), there are no routing algorithms used as opposed to if we had to implement LORAWAN to IP bridge. The embedded code needs to consider CRC issues, arbitration, handling of errors, etc., and compliance with the LoRa specifications.
Special mention should be made to thoroughly understand the datasheet of the LoRa radio module and the SPI operation codes to implement the different configurable functionality.
The LoRa transceiver (receiver end) receives the LoRa format data from the transmitting LoRa device node. Both the LoRa radio modules SX1276 are interfaced to the microcontroller via SPI peripheral or interface. The low-level drivers/libraries move data either from the microcontroller buffer to the radio module in the transmitter or from the radio module to the microcontroller buffer in the receiver radio module. The data parsed to the microcontroller radio buffer is then encapsulated/serialised into an IP/UDP format by the LoRa to IP bridge.
The queued datagrams received from the LoRa receiver are presented as an IP/UDP frame, using the LoRa device as a unique network address and a dedicated SCADA port number.
This, however, is not a direct translation from the LoRa data buffer to IP. Still, initially, the data gets serialised from the LoRa module's buffer of the LoRa module by the microcontroller and parses this serialised data to the Tx buffer of the ENC28j60 controller.
The enc28J60 controller is interfaced with the microcontroller via the SPI. When data is available in the buffer of the microcontroller initiates (via an interrupt routine) the transfer of this data via SPI commands to the TX buffer of the enc28j60 controller. The controller then adds the Mac and PHY components to the data to implement an IP data frame.
There are numerous low levels of functions written to carry out this implementation and can be summarised as follows.
Initialisation the enc28j60.
Assigning a Mac address to the controller
Writing to the TX buffer
Sending the packets
- 105 - Figure 4.9: Device architecture of the ENC28J60
4.8.1 Testing and implementing The IP Bridge
Before implementing the IP wrapper, part of the designing process was to send some dummy data to the SCADA to understand how the SCADA would resolve the data and write serialisation routines for the IP/LoRa bridge to implement. This also indicated how to serialize the data at the LoRa node. To achieve this, we sent the data via the Sockets application program in the delimited format that the bridge would implement parsing the delimited data and a dedicated port number to configure the SCADA agent server to accept UDP data via this port number.
During the testing of the wrapper, we found a lot of packets with errors arriving at the SCADA system. There was a need to implement a packet manager or buffer to manage the packets arriving at the SCADA system. It was necessary to instate a packet manager and adapt to the LoRa/IP bridge to accomplish this. The packets leaving the bridge were configured to be destined for an assigned port number.
- 106 - Before passing the UDP packets to the SCADA, it is necessary to have implemented a packet manager/buffer. The purpose of this packet manager/buffer is to parse only packets in a certain format to the SCADA while discarding any non-compliant packets. This packet manager takes care of processes that UDP doesn’t handle. It also serves as a serialisation routine that formats the data in the format that SCADA drivers can handle/process.
Figure 4.10: Snapshot of outbound packets from packet manager to SCADA.