Wiki source code of How to improve LoRaWAN distance
Version 16.1 by Edwin Chen on 2022/10/31 23:38
Hide last authors
| author | version | line-number | content |
|---|---|---|---|
 |
8.1 | 1 | **Table of Contents:** |
| |
6.1 | 2 | |
| |
8.1 | 3 | {{toc/}} |
| |
6.1 | 4 | |
| 5 | |||
| 6 | |||
 |
10.2 | 7 | = 1. OverView = |
| |
5.1 | 8 | |
| |
10.2 | 9 | |
| |
5.1 | 10 | In real-world deployment for LoRa, distance is a common topic. We always want to have the longest distance. This chapter shows some instructions for how to improve this. |
| 11 | |||
| 12 | |||
| |
10.5 | 13 | |
| |
10.2 | 14 | = 2. Analyze at the software side = |
| |
5.1 | 15 | |
| |
10.2 | 16 | == 2.1 LoRa parameters that effect distance == |
| 17 | |||
| 18 | |||
| |
5.1 | 19 | Some settings in End Node will affect the transfer distance. They are: |
| 20 | |||
| |
10.4 | 21 | * (% style="color:blue" %)**TXPower: **(%%)This means the output power from End Node. There is a command [[AT+TXP>>url:http://wiki.dragino.com/xwiki/bin/view/Main/End%20Device%20AT%20Commands%20and%20Downlink%20Command/#H7.14TransmitPower]] can be used to set the output power. TXP parameters follow the LoRaWAN regional document (rp2-1.0.3-lorawan-regional-parameters.pdf). Set to (% style="color:#037691" %)**AT+TXP=0**(%%) is always has the maximum output, but (% style="color:#037691" %)**AT+TXP=0**(%%) has different value in different frequency bands. |
| |
5.1 | 22 | |
| |
10.2 | 23 | * (% style="color:blue" %)**Data Rate(DR): **(%%)This is a combination of Spreading Factor and Band Width. Lowest Data Rate (DR=0) always has the longest transmit distance in LoRaWAN protocol. |
| |
5.1 | 24 | |
| 25 | Below is the TXPower and DR table of EU868 Frequency band as reference. | ||
| 26 | |||
| |
10.4 | 27 | |
| |
5.1 | 28 | [[image:image-20221006185826-1.png]] |
| 29 | |||
| |
10.2 | 30 | |
| |
5.1 | 31 | [[image:image-20221006185826-2.png]] |
| 32 | |||
| 33 | |||
| |
10.4 | 34 | Set (% style="color:#037691" %)**AT+TXP=0**(%%) **and** (% style="color:#037691" %)**AT+DR=0**(%%) will always has the longest transmit distance. But note that different frequency band has different TXP and DR coding according to LoRaWAN regional settings. Below is example for EU868, US915 and AS923 compare for example. |
| |
5.1 | 35 | |
| 36 | |||
| |
10.4 | 37 | **End node actually value when TXP=0 and DR=0** |
| |
5.1 | 38 | |
| |
10.2 | 39 | (% border="1.5" cellspacing="4" style="background-color:#ffffcc; color:black; width:1002px" %) |
| 40 | |(% style="width:134px" %)**Frequency band**|(% style="width:400px" %)**Output Power in LoRa Module (consider 2dB antenna)**|(% style="width:362px" %)((( | ||
| 41 | **Spreading Factor(Higher SF can transmit further)** | ||
| 42 | )))|(% style="width:102px" %)**Band Width** | ||
| 43 | |(% style="width:134px" %)**EU868**|(% style="width:400px" %)14dBm|(% style="width:362px" %)SF=12|(% style="width:102px" %)125Khz | ||
| 44 | |(% style="width:134px" %)**US915**|(% style="width:400px" %)20 or 22 dBm (depends on max output of module)|(% style="width:362px" %)SF=10|(% style="width:102px" %)125Khz | ||
| 45 | |(% style="width:134px" %)**AS923**|(% style="width:400px" %)14dBm|(% style="width:362px" %)SF=12|(% style="width:102px" %)125Khz | ||
| |
5.1 | 46 | |
| 47 | |||
| |
10.2 | 48 | == 2.2 Adaptive Data Rate (ADR) and set max distance == |
| |
5.1 | 49 | |
| 50 | |||
| |
10.2 | 51 | **ADR** is the feature that Server will ask End Node to adjust the TXP and DR according to some rules in the server. This is for the purpose of Network Management and Optimize End Node battery life-time. |
| |
5.1 | 52 | |
| 53 | |||
| |
10.2 | 54 | By default, ADR is turn on((% style="color:#037691" %)**AT+ADR=1**) (%%)so End node ADR feature is enable. |
| |
5.1 | 55 | |
| 56 | |||
| |
10.2 | 57 | (% style="color:blue" %)**Normally, user can set the max distance by setting:** |
| |
5.1 | 58 | |
| |
10.2 | 59 | (% style="color:#037691" %)**AT+ADR=0** |
| |
5.1 | 60 | |
| |
10.2 | 61 | (% style="color:#037691" %)**AT+DR=0** |
| |
5.1 | 62 | |
| |
10.2 | 63 | (% style="color:#037691" %)**AT+TXP=0** |
| 64 | |||
| 65 | |||
| |
5.1 | 66 | This can be downlink via the LoRaWAN downlink command, see [[this link>>url:http://wiki.dragino.com/xwiki/bin/view/Main/End%20Device%20AT%20Commands%20and%20Downlink%20Command/#H8.2UseDownlinkCommandtosetafixuplinkDR]] for reference. |
| 67 | |||
| 68 | |||
| 69 | |||
| |
10.2 | 70 | == 2.3 Check for short distance problem == |
| |
5.1 | 71 | |
| |
10.2 | 72 | |
| |
5.1 | 73 | According to the above technology, if we have a problem on the distance, we can first check if the end node is trying to longest distance modulation already. We can see that from the LoRaWAN server. Below is an example from Chirpstack. |
| 74 | |||
| 75 | |||
| |
10.5 | 76 | We can see the traffic in gateway's page and know that the distance is SF12 / BW125. (note, server is not able to know Transmit Power settings from End Node) |
| |
5.1 | 77 | |
| |
10.2 | 78 | |
| |
5.1 | 79 | [[image:image-20221006185826-3.png]] |
| 80 | |||
| 81 | |||
| 82 | |||
| |
10.2 | 83 | == 2.4 Best software settings for the longest distance == |
| |
10.1 | 84 | |
| |
10.2 | 85 | |
| |
10.1 | 86 | Below are the settings for longest distance transmission. ( will reduce battery life) |
| 87 | |||
| |
10.6 | 88 | * (% style="color:#037691" %)**AT+ADR=0** (%%)~/~/ Disable ADR |
| 89 | * (% style="color:#037691" %)**AT+DR= 0** (%%)~/~/ Use the smallest DR | ||
| 90 | * (% style="color:#037691" %)**AT+TXP=0** (%%) ~/~/ Use max power. | ||
| |
10.1 | 91 | |
| 92 | |||
| |
12.2 | 93 | |
| |
12.1 | 94 | = 3. Analyze at the hardware side = |
| |
10.1 | 95 | |
| |
12.1 | 96 | == 3.1 Check if the antenna path is good ~-~- For LSn50v2 series end node == |
| |
5.1 | 97 | |
| |
12.2 | 98 | |
| |
12.1 | 99 | a) Open Enclosure and Check if the antenna connection to module is good. |
| |
10.2 | 100 | |
| |
12.1 | 101 | b) check if the connector match. |
| |
10.2 | 102 | |
| |
12.2 | 103 | |
| |
12.1 | 104 | [[image:image-20221016081725-1.png||height="426" width="706"]] |
| 105 | |||
| 106 | |||
| |
12.2 | 107 | |
| |
12.1 | 108 | = 4. Installation Guidelines = |
| 109 | |||
| 110 | == 4.1 Check the use environment == | ||
| 111 | |||
| 112 | |||
| |
9.1 | 113 | First , User should notice: Radio link quality and performances are highly dependent of the environment. |
| 114 | |||
| |
10.2 | 115 | (% style="color:blue" %)**Better performances can be reached with:** |
| |
9.1 | 116 | |
| 117 | * Outdoor environment. | ||
| 118 | * No obstacles. | ||
| 119 | * No high level radio interferes in the ISM band you use. | ||
| 120 | * At least 1 meter above the ground. | ||
| 121 | |||
| |
10.2 | 122 | (% style="color:blue" %)**Radio performances are degraded with:** |
| 123 | |||
| |
9.1 | 124 | * Obstacles: buildings, trees... |
| 125 | * Inner buildings environments. | ||
| 126 | * High ISM band usage by other technologies. | ||
| 127 | * Radio communication are usually killed with bad topographic conditions. It is usually not possible to communicate through a hill, even very small. | ||
| 128 | |||
| 129 | |||
| |
12.2 | 130 | |
| |
12.1 | 131 | == 4.2 Improve the Antenna == |
| |
10.2 | 132 | |
| 133 | |||
| |
9.1 | 134 | In some case, we have to install the device inside the chamber or next to a metal case. So the signal between the antenna and the receiver (gateway) is blocked by the metal. This will greatly reduce the signal. In such case, we can consider using antenna extend cable to extend the antenna to a better position. |
| 135 | |||
| 136 | |||
| |
5.1 | 137 | |
| |
12.1 | 138 | = 5. Some real-world case = |
| |
5.1 | 139 | |
| |
12.1 | 140 | == 5.1 Server reason cause end node has problem on Join. == |
| |
10.2 | 141 | |
| 142 | |||
| |
5.1 | 143 | In one case, the customer is using AWS IoT Core and gateway to connect to AWS via Basic Station Connection, Frequency Band is AU915 sub-band 2. For some unknown reason, AWS always set downlink power to 0dBm, which cause the gateway only emit a very low power and lead to a short distance for sensor. |
| 144 | |||
| 145 | |||
| 146 | Below is the output log in gateway side ( SSH Access to Gateway and Check Station log) | ||
| 147 | |||
| 148 | |||
| 149 | [[image:image-20221006185826-4.png]] | ||
| 150 | |||
| 151 | |||
| 152 | The fix of this issue is to set the output power to a high value even server ask to send out 0dBm. | ||
| 153 | |||
| |
10.2 | 154 | Reference Link: [[http:~~/~~/wiki.dragino.com/xwiki/bin/view/Main/Change%20Gateway%20Power/#H1.A0Overview>>http://wiki.dragino.com/xwiki/bin/view/Main/Change%20Gateway%20Power/#H1.A0Overview]] |
| |
5.1 | 155 | |
| |
16.1 | 156 | |
| 157 | == 5.2 Chirpstack Default settings to 64 channels which cause Signal Poor. == | ||
| 158 | |||
| 159 | |||
| 160 | In this case, User use a Chirpstack LoRaWAN server with default settings. The Frequency Band is US915 and default settings of Chirpstack has all channels ( All sub-bands , total 72 channels) enable. User use a LDS03A and a LPS8N LoRaWAN gateway for the test. | ||
| 161 | |||
| 162 | |||
| 163 | There is a strange issue: LDS03 has a very good RSSI ( RSSI=-40) during OTAA Join. But The LDS03A give a very poor RSSI after OTAA Join. After debug, it proves that the issue is with ChirpStack Frequency band settings. The ChirpStack server enables all 72 channels and the LDS03A will also use all channels after OTAA Join, but the LPS8N only can support 8 channels and set to Sub-Band2. When the LDS03A sends an uplink packet in the channel LPS8N doesn't support, because LDS03A is very close to LPS8N, LPS8N pick up this not support frequency and send to server. So in the platform we see a uplink packet with very poor RSSI. | ||
| 164 | |||
| 165 | |||
| 166 | Above issue was confirmed and solved after set the ChirpStack support channels to sub-band2. See below for photos during debug. | ||
| 167 | |||
| 168 | [[image:image-20221031233628-2.png]] | ||
| 169 | |||
| 170 | |||
| 171 | [[image:image-20221031233759-3.png]] | ||
| 172 | |||
| 173 | |||
| 174 | |||
| 175 | |||
| 176 | |||
| |
10.2 | 177 |