No, a single channel gateway is not a gateway. It’s just a LoRa radio receiving messages on one channel.
With the sx1272/6 modules being used you will not be able to respond to any messages being received, so returning an ACK, a message or even OTAA is not possible.
Also remember that a node will do channel hunting and this gateway will only listen on one frequency with one Spreading Factor so it will miss a lot of messages being sent.
Hi all,
I also built the single channel kindof gateway, but as in the picture of platenspeler it says Packets forwarded 0. Shouldn’t packets get forwarded?
Has anyone ever tried the Long distance wireless 433/868/915Mhz Lora and GPS Expansion Board for Raspberry Pi to build a single channel gateway?
Hi there,
I’m the author of the nodemcu lora gateway PCB but I didn’t tested it. Just curious, anyone succeeded to talk to the RFM module with it so I can update the readme?
http://www.thethingsnetwork.org/forum/uploads/default/original/1X/e1e6941eee1bd422b87aa210324f08b8e40ab8df.png
By the way I created a new one for Wemos, may be cheaper, smaller, better.
Check out github repo for files.
Anyone can tell me where to find the ESP8266 code for RFM95 used for single channel GW ? I would like to try and adapt to this shield since I’ve got board mounted
Thanks
Looks great!
Any reason you didn’t test it? (probably too busy creating nice new boards ;-))
The code is at github (as mentioned a few pages above)
and I’m still waiting for the ‘small’ nodeMCU board, that fits on your PCB 
@Batilan
thanks, I’m kinda new on LoraWan, I’ll take a chance to test this code. I didn’t tested it because I’ve done it when I designed the RFM69 board that is working fine. I just changed the RFM footprtint for Lora but I don’t use them anymore because I prefer WeMos board that are smaller and much more reliable. you don’t have any idea on how many NodeMCU board I fried 
@BoRRoZ, yeah sorry about that, I should mention on github page, I got a old NodeMCU that does not fit but I had it for years, I wasn’t aware that they still sell this one. It’s easy to see which one is good, just look text space when ordering. The good ones have pinout really close to ESP12 module (no enought place for text between ESP12 and pin header of the board)
The good ones (horizontal text between header and ESP module)
The bad ones (vertical text between header and ESP module)
new single channel gateway for Raspberry Pi is ready now 
Link: http://wiki.dragino.com/index.php?title=Lora/GPS_HAT
Cheers.
Edwin
I build a SC GW this morning on a nodeMCU Gateway ver 1.2 board from a hallard board on OSH Park
Works fine… but some minor changes:
My Lat/Lon would over flow the clat, clon buffers below, so, I change the size from 8 to 12
char clat[12]={0};
char clon[12]={0};
#define _LAT 32.984709
#define _LON -117.178966
These I/O pin changes needed to be made:
// Note: nodeMCU LoRa Gateway board ver 1.2 has these settings
// SX1276 - ESP8266 connections
int ssPin = 2; // GPIO2, D4
int dio0 = 15; // GPIO15, D8
int RST = 0; // GPIO16, D0, not connected
I’m running a single channel gateway based on your fork. But after a day or so, the gateway will not receive any packets through the niceRF (SX1276) until I restart the process on the RPI.
Is this an issue in my hardware setup or could it be the software? Do you have similar issues?
The RPI have its own quirks, enough power etc… you will find tons of discussions just in this topic. I don’t have this board but my own setup, similar to this is just working.
In my humble opinion, “single channel gateways” is fun for learning, it works for me in this way but its an dead end! The TTN network with “real” gateways is an totally another thing, I will not try to explain all of the discrepancy between the real thing and a simple setup as mine 
But it is huge! Read the specs yourself and you will see To answer your question, I believe you have a RPI problem, not a TTN problem
/Greger
Yeah I’ve been reading up on the differences between a gateway and ‘hacks’ like the single-channel test devices.
I realise I’m going to need a real gateway in the future but coverage in my area is completely non-existent so at the moment anything is better than nothing.
When I can “sell” this network and it’s uses to my other half I’ll buy an iC880A-SPI for example. But meanwhile I’d like to run my single channel gateway to test ideas and come up with some good arguments to sell this 
“What’s that antenna doing on the roof?!”
I’ll swap out the RPI, especially the 1B models seem to lie everywhere
I totally love my RPI:s and also “the single channel gateway” in my projects. Your board should work as expected I think, my experiential setup and wiring with LMIC didn’t give me any problem, it is stable and working of shelf…
My setup is just for the neighborhood, and I have my own measurement equipment (from china)t to check the coverage, my setup for now is just for testing and solving an old problem, and its so good! But I am expecting “the real stuff” soon and then I will change from experimental to an real installation.
I expect (from china) and also from USA and Europe a lot of competition in this area, we will see sensors for peanuts and this is so cool. IoT in real life and this is a field I worked in for more than 20 years
“What’s that antenna doing on the roof?!” Antennas on the roof is my business, was my business before my retirement and the feeling of real freedom
/Greger
OK, I have a SCGW running on an ESP8266…
My node is a Arduino with an RFM95 radio (USA), firmware is: matthijskooijman/arduino-lmic
Below is the start up sequence, it connect to /#define _TTNSERVER “40.114.249.243”
My GW shows up green on the TTN map with a EUI
I appears that my NODE is sending data.
I’m using the NwkSKey of: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
The dashboard gave me a AppEUI of: 70 B3 D5 7E D0 00 03 8B
My DevEUI is: 00 04 a3 ff fe 31 00 01
My AppsKey is: 5E 93 5E B1 93 34 D0 D6 B3 80 32 E9 6C 29 9D 2A
I can login to the MQTT server…
The dashboard tell me that my device is not active…
So, I’m a bit lost here?? did I miss a step??
Its hard to debug when you have a lot of new moving parts!!
stat update: <219> {“stat”:{“time”:“2016-6-8 17:51:27 CET",“lati”:32.9847,“long”:-117.1789,“alti”:100,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“ESP8266”,“mail”:"tom@lafleur.us”,“desc”:“ESP Test Gateway”}}
sendUdp: sent 219 bytes
*** Packet RSSI: -35 RSSI: -108 SNR: 10 Length: 26
*** rxpk update: {“rxpk”:[{“tmst”:255867336,“chan”:0,“rfch”:0,“freq”:902.299987,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-35,“size”:26,“data”:“QAYA/wMASAEBdeUVwL79mn5SiQu1MGqdZMI=”}]}
sendUdp: sent 208 bytes
Received packet of size 4 From 40.114.249.243, port 1700, Contents: 1:46:29:1:
*** Packet RSSI: -36 RSSI: -98 SNR: 10 Length: 26
*** rxpk update: {“rxpk”:[{“tmst”:3149446152,“chan”:0,“rfch”:0,“freq”:902.299987,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-36,“size”:26,“data”:“QAYA/wMASQEBJRvxickmhILPycPLRBLLCMY=”}]}
sendUdp: sent 209 bytes
Received packet of size 4 From 40.114.249.243, port 1700, Contents: 1:4:B4:1:
stat update: <219> {“stat”:{“time”:“2016-6-8 17:51:57 CET",“lati”:32.9847,“long”:-117.1789,“alti”:100,“rxnb”:2,“rxok”:2,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“ESP8266”,“mail”:"tom@lafleur.us”,“desc”:“ESP Test Gateway”}}
sendUdp: sent 219 bytes
WifiServer new client
WifiServer new client
*** Packet RSSI: -37 RSSI: -108 SNR: 10 Length: 26
*** rxpk update: {“rxpk”:[{“tmst”:1748890672,“chan”:0,“rfch”:0,“freq”:902.299987,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-37,“size”:26,“data”:“QAYA/wMASgEBRWn0cJaw4645k83vS7JCYf0=”}]}
sendUdp: sent 209 bytes
Received packet of size 4 From 40.114.249.243, port 1700, Contents: 1:68:A7:1:
stat update: <219> {“stat”:{“time”:“2016-6-8 17:52:27 CET",“lati”:32.9847,“long”:-117.1789,“alti”:100,“rxnb”:3,“rxok”:3,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“ESP8266”,“mail”:"tom@lafleur.us”,“desc”:“ESP Test Gateway”}}
OK, I just got a node talking by setting it up as a ABP and NOT OTAA…
so, what is needed to do OTTA??
OTAA requires a full gateway. For OTAA you need downlink (data to node) which is missing in single channel gateways according to this issue.
A “single channel gateway” is just a “packet forwarder” and nothing more, a real Gateway can handle OTTA, scan all 8 channels, send data to actuators etc. LoRaWAN as an solution for future IoT applications demands real Gateways which complies to the LoRaWAN specs.
I believe that a lot of folks are trying to find a shortcut to more simple and cheaper solutions, and that is good as long as they understand the implications, lack of functionality is just one of them. A full Gateway is the key for good spectrum efficiency and this might be the most important thing for the future.
Relax It’ll be ok. I’m sure that when the normal gateways come online all these experimental stuff will be converted into a new cool project. How else can you test your nodes when you are not in reach of one of the few gateways that are present today.
Exactly what I did. The single channel gateway was nice to see that my node works and what the packet forwarder does. As soon as this worked I ordered a ‘real’ LoRa concentrator and the RFM95W module is now being used to develop a new node.
This is a technical limitation. The join accept is send exactly 6s after the reception of the join request. Exactly is within a 20 micro-second window. The LoRa concentrator measures the time in the radio baseband chip but with this single channel gateway that is not possible.
Just to explain, a “single channel gateway” is not a gateway, its just a packet forwarder and as such its working out of the box. You can have all of your experimental projects working, as I have, just out of the box But its one way only, no information from the network to your nodes, just information from sensors to your application. You can subscribe to data with MQTT and it works. The coverage is excellent in my opinion and I when I get my hand on the real stuff my antennas will be much higher and the coverage even better.
When using a RN2483 for nodes, it will by default use a number of channels and as the single-channel-gateway is only listening on one channel most of the messages will be lost. One way to handle this problem is to force (fool) the module to use the same frequency for channels 3 to 7, this can be done via MAC SET CHANNEL COMMANDS defined in the spec. RN2483 LoRa TM TECHNOLOGY MODULE COMMAND REFERENCE USER’S GUIDE.
