Single Channel Packet Forwarder part 3 [Deprecated]

[bluejedi]

Disclaimer

Single channel packet forwarders are NOT supported by The Things Network and we condemn their use.

---

Single Channel Packet Forwarders are not LoRaWAN compliant gateways.

They negatively impact proper operation of gateways and end devices (nodes) in their area which means they negatively impact The Things Network and its users, but they also impact other LoRaWAN operators. Not only now, but also in the future when new nodes and new gateways are added in the area.

Single Channel Packet Forwarders are often called Single Channel Gateways which is incorrect, confusing and misleading. They shall not be called gateways.

Be aware that some vendors will try to sell Single Channel Packet Forwarders as a gateway which they are not. These cannot be used as gateway for The Things Network.

NOT supported also means that single channel packet forwarders may no longer work after the community network will be migrated to V3.

Only LoRaWAN compliant gateways are supported by The Things Network.

History

Years ago in the early days of The Things Network, LoRaWAN gateways were very expensive and out of reach for many. In those days a Single Channel Packet Forwarder was an affordable alternative to start experimenting with the technology and The Things Network.

During recent years much cheaper and much more affordable gateways have become available. The Things Indoor Gateway costs around €85 (VAT included) and there are many options for both DIY and commercial gateways in the price range from €120 to €200.

In the last years many gateways have been deployed worldwide and network coverage has become available in many areas on the globe. The effect and importance of the negative impact of Single Channel Packet Forwarders on successful operation of the network and its users has substantially increased with the growth of the network. Therefore use of Single Channel Packet Forwarders is now deprecated and is condemned by The Things Network and on this forum.

(end of disclaimer)

---

Example hardware: Raspberry Pi Zero + RFM95 hat + Wifi dongle

For previous parts of this topic see:
Single Channel Packet Forwarder part 1 [Deprecated]
Single Channel Packet Forwarder part 2 [Deprecated]

List of single channel gateway implementations

Below is a list of actual, up-to-date RFM9x / SX127x-based single channel gateway implementations:
(List was last updated on: 2017-12-05)

For Raspberry Pi

• https://github.com/hallard/single_chan_pkt_fwd
  Supports ABP activation, single frequency and single spreading factor. Configuration via separate configuration file (configuration changes do not require recompilation but require the software to be re-started). (Written in C++.)

For ESP8266

• https://github.com/things4u/ESP-1ch-Gateway-v5.0
  Supports ABP and OTAA activation, downstream messages(?), single frequency with multiple spreading factors, Web interface, WifiManager, OTA, I2C OLED display and ‘use gateway as a node’. Configuration is (partially) hard-coded (some configuration changes require recompilation while others can be changed via web interface, if enabled). (Written in C++.)

• https://github.com/JaapBraam/LoRaWanGateway
  Supports ABP and OTAA activation, downstream messages and single frequency with multiple spreading factors. Configuration via separate file (but file also contains code). (Written in Lua.)

For ESP32

• https://github.com/kersing/ESP-1ch-Gateway-v5.0
  This fork of ‘things4u ESP-1ch-Gateway-v5.0’ for ESP8266 has added support for ESP32 and (Heltec) Wifi LoRa 32 modules.
  Supports the same features as things4u’s implementation but currently does not support WifiManager and OTA. (Written in C++.)

• https://github.com/pycom/pycom-libraries/tree/master/examples/lorawan-nano-gateway for the LoPy (ESP32 board running MicroPython interpreter).
  Supports ABP and OTAA activation, downstream messages, single frequency (not clear if multiple spreading factors are supported), configuration via separate configuration file that can be uploaded via USB or FTP. Lacks description / instructions / readme. (Written in MicroPython.)
  .

NOTES:

• Don’t forget: each implementation requires that you configure the software with your own gateway parameters (and your own LoRa module wiring pin numbers) before compiling and/or running the software.
• Hallard’s Raspberry Pi version installs flawlessly (but supports the least features).
  The other implementations may require some tweaking.

[Somsak]

This is mine with Pi0w.

[Somsak]

ESP32(WeMos D1 Mini) + RFM95w + Oled

[clarisse]

I have the Heltec and can’t get it to compile. Everything from wpa.h seems to be broken or missing.

[clarisse]

I have the Heltec Lora Oled board and can not seem to get the 1 channel gateway compiled for the life of me. It seems like anything to do with dependencies in wpa.h are failing. I have installed the tool chain from both Espressif and Heltec and both seem to be missing things like c_types.h and the rest of the includes. So looking though the various distributions I found some of the files in the esp idf github and finally got to the point where the compiler was starting to wine about various redefinitions and undefined enums.

I am presuming I have my libraries installed wrong. I can load things like the display test and other things just fine but the gateway stuff seems to continue to evade me. I don’t happen to have an esp8266 with a lora module or I would use that. Any help would be greatly appreciated.

I am using the Arduino 1.8 ide.

[Verkehrsrot]

Better use PlatformIO on Visual Studio Code as IDE. It managed libraries much better than the Arduino IDE. I had no problems to compile the single channel gateway an run it on the Heltec.

[clarisse]

@Verkehrsrot

PlatformIO

Thank you I have it installed I will try tomorrow to compile.

[clarisse]

In file included from E:\Users\ehren.platformio\packages\framework-arduinoespressif32\cores\esp32/Arduino.h:188:0,
from e:\users\ehren\appdata\local\temp\tmpcsm4zv:1:
E:\Users\ehren.platformio\packages\framework-arduinoespressif32\variants\heltec_wifi_lora_32/pins_arduino.h:28:22: note: ‘const uint8_t SCK’ previously defined here
static const uint8_t SCK = 5;
^
In file included from d:\arduino\wpa.h:20:0,
from src\ESP-sc-gway.h:250,
from E:/Users/ehren/Documents/PlatformIO/Projects/180122-084201-heltec_wifi_lora_32/src/ESP-sc-gway.ino:30:
e:\Users\ehren\Documents\GitHub\arduino-esp32\Arduino\variants\generic\common.h:52:22: error: redefinition of 'const uint8_t A0’
static const uint8_t A0 = PIN_A0;
^
In file included from E:\Users\ehren.platformio\packages\framework-arduinoespressif32\cores\esp32/Arduino.h:188:0,
from e:\users\ehren\appdata\local\temp\tmpcsm4zv:1:
E:\Users\ehren.platformio\packages\framework-arduinoespressif32\variants\heltec_wifi_lora_32/pins_arduino.h:30:22: note: ‘const uint8_t A0’ previously defined here
static const uint8_t A0 = 36;
^
In file included from d:\arduino\wpa.h:23:0,
from src\ESP-sc-gway.h:250,
from E:/Users/ehren/Documents/PlatformIO/Projects/180122-084201-heltec_wifi_lora_32/src/ESP-sc-gway.ino:30:
d:\arduino\wpa_common.h:180:3: error: conflicting declaration ‘wpa_ptk STRUCT_PACKED’
} STRUCT_PACKED;
^
d:\arduino\wpa_common.h:163:3: note: previous declaration as ‘wpa_eapol_key STRUCT_PACKED’
} STRUCT_PACKED;
^
d:\arduino\wpa_common.h:209:3: error: conflicting declaration ‘wpa_ie_hdr STRUCT_PACKED’
} STRUCT_PACKED;
} STRUCT_PACKED;
^
d:\arduino\wpa_common.h:163:3: note: previous declaration as ‘wpa_eapol_key STRUCT_PACKED’
} STRUCT_PACKED;
^
d:\arduino\wpa_common.h:240:3: error: conflicting declaration ‘rsn_ie_hdr STRUCT_PACKED’
} STRUCT_PACKED;
^
d:\arduino\wpa_common.h:163:3: note: previous declaration as ‘wpa_eapol_key STRUCT_PACKED’
} STRUCT_PACKED;
^
d:\arduino\wpa_common.h:260:2: error: ‘be16’ does not name a type
be16 mui;
^
d:\arduino\wpa_common.h:261:2: error: ‘be16’ does not name a type
be16 error_type;
^
d:\arduino\wpa_common.h:262:3: error: conflicting declaration ‘rsn_error_kde STRUCT_PACKED’
} STRUCT_PACKED;
^
d:\arduino\wpa_common.h:163:3: note: previous declaration as ‘wpa_eapol_key STRUCT_PACKED’
} STRUCT_PACKED;
^
In file included from src\ESP-sc-gway.h:250:0,
from E:/Users/ehren/Documents/PlatformIO/Projects/180122-084201-heltec_wifi_lora_32/src/ESP-sc-gway.ino:30:
d:\arduino\wpa.h:40:13: error: ‘ETH_ALEN’ was not declared in this scope
u8 addr[ETH_ALEN];
^
d:\arduino\wpa.h:85:17: error: ‘ETH_ALEN’ was not declared in this scope
u8 own_addr[ETH_ALEN];
^
d:\arduino\wpa.h:87:14: error: ‘ETH_ALEN’ was not declared in this scope
u8 bssid[ETH_ALEN];
^
d:\arduino\wpa.h:107:33: error: use of enum ‘wpa_alg’ without previous declaration
void (*install_ppkey) (enum wpa_alg alg, uint8 *addr, int key_idx, int set_tx,
^
d:\arduino\wpa.h:116:15: error: ‘ETH_ALEN’ was not declared in this scope
u8 h_dest[ETH_ALEN];
^
d:\arduino\wpa.h:117:17: error: ‘ETH_ALEN’ was not declared in this scope
u8 h_source[ETH_ALEN];
^
d:\arduino\wpa.h:118:5: error: ‘be16’ does not name a type
be16 h_proto;
^
d:\arduino\wpa.h:119:3: error: conflicting declaration ‘l2_ethhdr STRUCT_PACKED’
} STRUCT_PACKED;
^
In file included from d:\arduino\wpa.h:23:0,
from src\ESP-sc-gway.h:250,
from E:/Users/ehren/Documents/PlatformIO/Projects/180122-084201-heltec_wifi_lora_32/src/ESP-sc-gway.ino:30:
d:\arduino\wpa_common.h:163:3: note: previous declaration as ‘wpa_eapol_key STRUCT_PACKED’
}} STRUCT_PACKED;
^
In file included from src\ESP-sc-gway.h:250:0,
from E:/Users/ehren/Documents/PlatformIO/Projects/180122-084201-heltec_wifi_lora_32/src/ESP-sc-gway.ino:30:
d:\arduino\wpa.h:190:28: error: use of enum ‘wpa_states’ without previous declaration
void wpa_sm_set_state(enum wpa_states state);
^
Compiling .pioenvs\heltec_wifi_lora_32\FrameworkArduino\esp32-hal-misc.o
Compiling .pioenvs\heltec_wifi_lora_32\FrameworkArduino\esp32-hal-sigmadelta.o
Compiling .pioenvs\heltec_wifi_lora_32\FrameworkArduino\esp32-hal-spi.o
Compiling .pioenvs\heltec_wifi_lora_32\FrameworkArduino\esp32-hal-time.o
E:/Users/ehren/Documents/PlatformIO/Projects/180122-084201-heltec_wifi_lora_32/src/ESP-sc-gway.ino: In function ‘int WlanConnect(int)’:
E:/Users/ehren/Documents/PlatformIO/Projects/180122-084201-heltec_wifi_lora_32/src/ESP-sc-gway.ino:522:37: error: ‘wpa’ was not declared in this scope
for (int j=wpa_index; j< (sizeof(wpa)/sizeof(wpa[0])) ; j++) {
^
Compiling .pioenvs\heltec_wifi_lora_32\FrameworkArduino\esp32-hal-timer.o
*** [.pioenvs\heltec_wifi_lora_32\src\ESP-sc-gway.ino.o] Error 1
Compiling .pioenvs\heltec_wifi_lora_32\FrameworkArduino\esp32-hal-touch.o

[bluejedi]

It is not very useful to dump a long list of output this way and without any accompanying questions or remarks.

The more specific (and better prepared) your questions are the better others can help (and are willing) to try answer them.

[clarisse]

I think I have found that all of the problems that I had involved how the libraries were installed. What I posted were mainly examples where the compiler was telling me that either things were being redefined or where never defined.

I am new to this development environment and was and am somewhat confused about setup of vs code, platform io and the 1 ch gateway source tree.The directions for the source tree are easy to understand but the rest was not intuitive for me.

[Somsak]

Did you success to compile?

[clarisse]

No, actually, it seems to have a ton of problems. I get a lot of message from the compiler suggesting that things are being redefined. I am not sure I have the right libraries or may have duplicates. I clearly am missing something.

[Ryanteck (Ryan Walmsley)]

Hi,

While I have setup a multi channel gateway where I live as the range doesn’t still quite reach where I wanted. While I’m looking at improving it I still doubt it’d reach the few locations I want it to.

There has been some discussion about Single Channel Gateways and weather they should be used for the fact that then nodes programmed for use by them are fixed to the same frequency, And while the multi channel gateways have come down a lot you can build a SCG for around £10 for a ESP8266, RFM95 & PCB.

I was wondering if say I was able to get a few setup, what the procedure is seeing that they aren’t supported by Lora Wan. Should we register them in TTN Console etc?

[bluejedi]

@Ryanteck

Should we register them in TTN Console etc?

If you want to use it with TTN then yes, you will have to add it as a gateway to the console.

[Ryanteck (Ryan Walmsley)]

Just finished assembling this, A PCB that houses both the ESP8266 and RFM95 module on one PCB. Awaiting USB Connectors.

Designed to be a slightly more compact solution to plug into a USB Power socket on a phone charger.

Just need to figure out the software fully on it and do a few tests.

EDIT: All fully working using the V5 ESP Firmware. Should be ideal for a few development cases. I might have some spare boards and kits up for sale soon.

[Ryanteck (Ryan Walmsley)]

Update, Working great! Still awaiting the USB connectors.

SF auto switching seems to work perfectly fine. I’ll get the Eagle BRD File up on github Monday if anyone wants to get their own made. Around £10 for 3 PCBs from either OSH Park or Aisler Total build cost per unit around £10. (£3 PCB, £4 Hope RF, £1.50 ESP, £1.50 Misc)

[fblanc92]

Hello people. I’ve implemented the single channel gateway with a SX1276 (specifically Dragino Lora Bee).
Right now the Raspberry shows the following receptions (attached). In the capture I receive a packet with a working node that contains the word “PONG” but I’m not seeing exactly that. Another thing is the node is sending this packet every 3 seconds but the gateway receives every 15 minutes or more.

I don’t really know if this is the correct functioning.

Please sorry my not-experience about all this but I’d really appreciate your help.

[Ryanteck (Ryan Walmsley)]

@fblanc92 , Single channel gateways are not “proper” gateways, most SCGs run on “Channel 0” or 868.1Mhz. A LoRa Wan compliant gateway can listen on 3 channels with most listening on all 8 for full compatibility.

At the same time nodes can transmit on any of the 8 channels, of which your gateway can only receive on the one channel.

As of this if your node is deciding to transmit on other frequencies more often then your gateway won’t be recieving them.

As of now there’s currently no way I know that allows a single channel gateway to listen on all 8 channels. However for development only you can force your node to transmit on only 868.1 Mhz. It’s only recommended that you do this while developing / don’t have coverage with a full gateway.

How to do this will depend on what you’re using as your node.

[fblanc92]

@Ryanteck

As of this if your node is deciding to transmit on other frequencies more often then your gateway won’t be recieving them.

As of now there’s currently no way I know that allows a single channel gateway to listen on all 8 channels. However for development only you can force your node to transmit on only 868.1 Mhz. It’s only recommended that you do this while developing / don’t have coverage with a full gateway.

Ryanteck thank you so much for your clear explanation.
The SCG implementation is only for demonstration of a simple protocol implementation.

I’m transmitting at 868MHz actually because is the allowed frequency by the fabricant library (Semtech), with a 500Khz bandwidth, using SF7 and coding rate 4/5.

I’m trying to find the way to transmit at least a char sequence because the coded result is not usefull at all for me (I did it with two end devices, and I want one of them to become a gateway with a RPI).

For what you said to me the key is on the end device, so I’ll keep working on that.

Thank you, again.

[arjanvanb (Arjan)]

@fblanc92

In the capture I receive a packet with a working node that contains the word “PONG”

If you’re sending text (don’t) then your packet should be about 17 bytes: 13 bytes LoRaWAN overhead, plus 4 characters. What you’re showing are a whopping 126 and 40 bytes. So chances are those are not your node’s packets.

(Too bad you posted a screenshot of the terminal output, which does not allow us to copy the payload for further investigation/help. Please post text next time.)