# LoRa-WindPower-Control

![](/Pictures/3D/LoRa-WindPower-Control_Plain.png)
![](/Pictures/3D/LoRa-WindPower-Control.png)

## Connection Overview

![](/Pictures/Block-Diagram/Block-Diagram.jpg)

## Pin Assignment

### LoRa WindPower PCB

#### Power Supply

Connector | Description
---------|---------
X3:1 | 24V
X3:2 | GND

#### Signals

Raspberry Pi | IC880A | External Signal | Description
---------|----------|---------|---------
K5:26 (GPIO7) | K6:13 | - | RESET
K5:23 (GPIO11) | K6:14 | - | SCLK
K5:21 (GPIO9) | K6:15  | - | MISO
K5:19 (GPIO10) | K6:16 | - | MOSI
K5:24 (GPIO8) | K6:17 | - | CS
K5:8 (GPIO14) | - | X10:2 | TXD (Serial Console); 3V3
K5:10 (GPIO15) | - | X10:3 | RXD (Serial Console); 3V3
K5:19 (GPIO10) | - | X8:1 | Shutdown Signal; 24V

> **Note:** check [Schematic-Design](/Documentation/Schematics/Schematic_Design.pdf) for more Informations

### Watteco IN'O

#### Power Supply

Connector | Description
---------|---------
EXT_POWER+ | 24V (CLASS-C Device only)
EXT_POWER- | GND (CLASS-C Device only)

#### Signals

Connector | Description
---------|----------
OUT1+ | Output Relay for Shutdown
OUT1- | Output Relay for Shutdown

> **Note:** check [Quick-Start-Guide](/Documentation/Component/Watteco/Quick-Start-InO-et-Pulse-SensO-002.pdf) and [https://support.nke-watteco.com/ino-2/](https://support.nke-watteco.com/ino-2/) for more Informations

## Setup Raspberry Pi and IC880A as a Gateway

Follow Instructions on The Things Stack  
[https://www.thethingsindustries.com/docs/gateways/models/raspberry-pi/](https://www.thethingsindustries.com/docs/gateways/models/raspberry-pi/)

## Add Watteco Device to TTN

Follow Instructions on Watteco  
[https://support.watteco.com/ttnv3-tutorial/](https://support.watteco.com/ttnv3-tutorial/)

## Modify Files

### Raspberry Pi Configuration

Add the following lines to the `/boot/config.txt` to activate SPI only for CS1 on SPI0:
```
dtparam=spi=on
dtoverlay=spi0-1cs,cs0_pin=8
```

### Change Reset Pin Number

In various files the reset pin has to be changed according to the reset wiring (GPIO 7).

In `/opt/ttn-station/bin/start.sh`:
```
SX1301_RESET_BCM_PIN=7
```

Then add the following lines:

```
"radio_init": "/home/support/basicstation/deps/lgw/platform-rpi/reset_lgw.sh start 7",
"RADIO_INIT_WAIT": "2s"
```

to the file `opt/ttn-station/config/station.conf` in section `station_conf`. This section should look like below after changing:
```
"station_conf": {
    "routerid": "dca632fffe296b69",
    "log_file": "stderr",
    "log_level": "DEBUG", /* XDEBUG,DEBUG,VERBOSE,INFO,NOTICE,WARNING,ERROR,CRITICAL */
    "log_size": 10000000,
    "log_rotate": 3,
    "CUPS_RESYNC_INTV": "1s",
    "radio_init": "/home/support/basicstation/deps/lgw/platform-rpi/reset_lgw.sh start 7",
    "RADIO_INIT_WAIT": "2s"
}
```

## LoRaWAN - MQTT Handler

To receive and send LoRaWAN messages, the MQTT integration of TTN is used. The [python-script](/Source/lora_mqtt.py) `lora_mqtt.py` in folder `Source` is handling the LoRa payload via MQTT. This script configures all LoRa devices within a LoRa application. All devices are configured to send periodically report messages (uplink) about the state of the relay output. If an external shutdown command is registered by the Raspberry Pi GPIO, a command (downlink) is send to trigger the relay output of the watteco device.

The script provide in this state no checking algorithm, that a downlink message was correctly received and executed by the device (no Acknolagement).

> **Note:** More informations about the MQTT integration, visit [https://www.thethingsindustries.com/docs/integrations/mqtt/](https://www.thethingsindustries.com/docs/integrations/mqtt/)

> **Note:** More informations about controlling digital ouputs (payload), visit [https://support.nke-watteco.com/onoff-cluster/](https://support.nke-watteco.com/onoff-cluster/)

The script can be autostarted by using systemd, e.g. [lora_mqtt.service](/Source/lora_mqtt.service). Adjust the path to the python script.

```
[Unit]
Description=LoRa-MQTT Handler
After=network.target ttn-station.service

[Service]
WorkingDirectory=/home/support/lora_mqtt
ExecStart=/home/support/lora_mqtt/lora_mqtt.py
SyslogIdentifier=lora_mqtt
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
```

Copy the systemd service file to `/lib/systemd/system/` and enable it:
```
sudo systemctl enable lora_mqtt.service
sudo systemctl start lora_mqtt.service
```

## Timing Problems with Class A Devices

For testing, a Watteco IN'O Class A device was used. Since a Class A device can only receive a downlink message for a certain time (few seconds) after sending an uplink message, the min/max reporting time for the relay output was set to 60s/120s, to reduce the timespan for sending a downlink messages. Depending on the **S**preading **F**actor (SF), this may result in a violation of the max airtime for a LoRa device per day. Without a reporting message being set, a Class A device will only send one void message per day, so only one time per day, a downlink message can be received by the device. So for production use case, a Class C device is recommended and the reporting time must be increased to achieve the specs of LoRa/TTN in termes of max airtime.  Class C device has the advantage, that it can continuously receive a downlink message, because it is not battery driven and doesn't need to be set into sleep to increase battery lifetime.

It is a good practice to precalculate the airtime per message, depending on SF, bandwidth and the amount of bytes per message. With the result, the correct reporting time can be set.

Use the calculator provided by TTN:  
[https://www.thethingsnetwork.org/airtime-calculator](https://www.thethingsnetwork.org/airtime-calculator)

Additional Informations:  
[https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/](https://www.thethingsnetwork.org/docs/lorawan/duty-cycle/)
[https://www.thethingsnetwork.org/docs/lorawan/spreading-factors/](https://www.thethingsnetwork.org/docs/lorawan/spreading-factors/)


> **Definition Class A (Sleeping Devices):** Downlink frames can only be transmitted after an uplink transmission by the sensor. Once the sensor sends an uplink frame, the end-device will open two receiving windows: RX1 and RX2, the network can then send on one of these windows a frame that will be taken into account by the sensor. When a sleeping device is not transmitting a frame it goes into a sleep mode where it does not listen to the network. This mode permits to reduce a lot the consumption of the sensor.

> **Definition Class C (Awake Devices):** The network can send at any time a frame; it will be received by the sensor. The device open receive windows continuously.