Got a singe channel gatway based on the lorago dock up and running.
wanted to use the internal sensors to display some data.
got not get that working 
The is data send to ttn i see payload dont know what to do with it and dont know what it is,
anybody got some experience with that ?
Since some day, my ESp8266+RFM95, previously working well, no more connects to my WiFi. I am getting mad because nothing changed. Furthermore, it connects to the hotspot of my iPhone if enabled (and configured). But home wifi, nothing, either from WiFiManager and by setting it in wpa. Any hint? Thanks.
A WlanStatus:: DISCONNECTED, IP=0.0.0.0
(by the way: I get better SNR with ESP8266+RFM95 than with Heltec Lora32…).
Did you power cycle the router?
Yes, in fact in the last days I had some instability on the ADSL line, so I had to switch off a couple of times, and I also found a post elsewhere that mentions some vaguely similar issue. However, phones, tablets and computer at home connect without issues now. The final post about 5GHz seems not valid for me, since the router is a somewhat old D-Link DSL 2640b, 2.4GHz only.
I can add some info: I tried to reformat SPIFF (by setting _SPIFF_FORMAT 1), and when reformatting, it apparently connects to WiFi. But then resets automatically and if I set back to _SPIFF_FORMAT 0 , everything is as before.
Of course this is not a TTN related issue, but I mention this for other singlechannelers (and I will mention the solution, if any).
I have seen exactly this behaviour with the ESP8266+RFM95 in my case it is a Netgear router. I did not find the root cause but resetting the router enabled the ESP8266 to reconnect. I do have a couple of theories which are related to DHCP. When a client, such as the ESP8266 acquires a DHCP request, it actually proposes its previous (or current) IP address in the DHCP request. In theory, if a router has that address available, it should return that address in the response. If however the address has already been leased to another end point the router will respond with a new address. When an end point receives a DHCP address from the router, it is then supposed to do a reverse ARP using that address and listening for any reply. If the end point receives a reply to the reverse ARP, meaning another device is already using the address, it is supposed to reject the address and restart the DHCP address request.
I suspect it is the corner cases that the ESP8266 is getting hung up on, which could be not accepting the alternative address, failing on the reverse ARP and requesting again the same address, or simply failing to continue the DHCP process when it does not have a valid DHCP address.
Thanks - I was leaning towards something similar, though not so clear and precise. I had a DHCP address reserved for the gateway, to simplify access through the web interface; after the first times, I changed it to another address, thinking at it remaining busy, and lately simply removed the reservation, but nothing helped. By the way, I have also a long lease time that may give further complexity.
On the ESP8266 side, I expected that formatting SPIFF and reloading the sw would refresh everything, but maybe it is not. Now I could try to totally reset the router and see (not sure how it is different from switching off, but in this precise computer science we are used to these black magic rituals 
).
Update: the router reset did not help. However, in a IDE menu I never looked with attention I found a way to erase flash contents (Tools/Erase Flash), and this seemed to help, although at first it seemed not. In particular, after erasing, the node was still not able to directly connect to the network specified in the wpa[] array, but was indeed able through WiFiManager (fair enough for me). I tried WiFiManager only after Erase all flash content, but it could function also after Erase Sketch + WiFi settings (I saw it was not connecting directly, so I went for erasing all).
This will not help in future events: the gateway was under the roof, and ideally I would avoid solutions where you have to physically access it. I will try to use an ESP32 + external LoRa chip (not a complete platform, since the Heltec I have seems less sensible than Esp8266 + RFM95).
Learnt the hard way with a single channel gateway! Pain in the ass as the nodes rotate their frequency = missing data
You can use you mobile phone to share wifi hot spot. Test your ESP8266 with mobile hotspot.
We use Dlink pocket wifi to provide Internet Access for my Single gateway.
My gateway is running on battery and Solar power.
It is working 7/24 for several month now.
Somsak
@mid-walesha: I know, the issue here was different.
@Somsak: as I also wrote in the first post, I did test it with the hotspot and was running. The issue was with the specific network to which I wanted it to connect, and at the end I solved by erasing flash (likely something remained set too permanently).
From time to time the gw disappears, likely loosing connection due to distance from wifi AP, but it seems able to recover.
I may also add that I have also an ESP32 in the same setting that never lost connection (although with worst Lora performance).
In my mailbox today there were a Wemos and a pure ESP32 platform (no LoRa), I will try with these too to find a reliable and efficient combination.
The nodes will only rotate their frequency if that is how you have setup the nodes. The problem is not only related to single channel gateways. What if you have nodes that are configured to operate with a 16 channel gateway, such as a Cisco gateway, but the only gateways in range of the nodes support 1, 2, 4, or 8 channels? Messages will be lost.
You could say, what if as part of the initial registration process, the node is told the number of channels supported by the gateway that is forwarding the registration replies from the LoRa Server to the node? The challenge is that such a mechanism only works if the specific gateway does not fail. If the gateway fails and the other gateways in range of the node do not support the channels used by the node, then messages will be lost.
I believe in the UK setting a node to a static frequency is technically illegal. All the commercial nodes we have prevent this. But I understand for home experiments the cost savings etc. All multi-channel gateways on TTN should follow their rules configuration wise - 8 channels / correct frequency. The nodes we use allow switching from 16 to 8 channels. I just ensure everything complies with the TTN rules.
Hello
I had successfully setup an Heltec Wifi LoRa 868 MHz Esp 32 board with this software gateway version dedicated in the past to 8266. https://github.com/things4u/ESP-1ch-Gateway-v5.0
Today the uptodate version is 5.3.3 (August 25, 2018) and ESP32 board as TTGO are supported .
It’s easy to add another ESP32 board as Heltec ( few parameters to modify in ESP-sc-gway.h and loraModem.h files).
This version has an improved Downlink function. Work for SF8-SF10. Does not work reliable for SF7, SF11, SF12.
I have tested successfully with TTN server uplink and downlink with ttb-abp software (ABP LoRa device from examples of LMIC-arduino library https://github.com/matthijskooijman/arduino-lmic)
As stated in version 5.3.3 notes, download is not fully reliable
By performing a dump on the output interface of my Raspberry I see the traffic being forwarded to the Handlers, the ones do not have a valid Radius request response in my understanding.
20:56:03.683957 IP 192.168.88.243.55983 > 13.76.168.68.1700: RADIUS, Access-Request (1), id: 0x79 length: 237
20:56:03.684575 IP 192.168.88.243.55983 > 52.62.83.250.1700: RADIUS, Access-Request (1), id: 0x79 length: 237
20:56:04.053008 IP 13.76.168.68.1700 > 192.168.88.243.55983: [|radius]
20:56:04.125858 IP 52.62.83.250.1700 > 192.168.88.243.55983: [|radius]
20:56:10.090125 IP 192.168.88.243.55983 > 13.76.168.68.1700: RADIUS, Access-Request (1), id: 0x3b length: 236
20:56:10.090841 IP 192.168.88.243.55983 > 52.62.83.250.1700: RADIUS, Access-Request (1), id: 0x3b length: 236
20:56:10.463806 IP 13.76.168.68.1700 > 192.168.88.243.55983: [|radius]
20:56:10.535532 IP 52.62.83.250.1700 > 192.168.88.243.55983: [|radius]I found a solution! I am working with Raspi and the single_chan_pkt_fwd application to send to the TTN handlers, well, since Rasp has two network interfaces (eth0 and wlan0) I deleted my gateway record in TTN with the eth0 network card MAC and made a new one Register with the MAC of the wlan0 card, now the Gateway is online!
Hope it helps our friends!
Did any of you connected single channel gateways with GSM module to Internet? Do you have some schematics and code?
I want to make that if my board (ESP32, ESP8266) doesn’t have WiFi connection, turns on GSM module (SIM800L), and connects with it on server.
Thanks 
That’s not really a question/related for this topic… ’ connecting your single channel gateway with 800l chip ’
I suggest to open a separate topic for this subject.
Hi everyone !
I had successfully setup a RasperryPi+RFM95W single channel gateway with the code from https://github.com/hallard/single_chan_pkt_fwd but i am stuck on a problem with The Things Network. Btw my end node (for testing purpose) is an im880b and i am using the ABP activation. This node is sending messages at 3 different frequencies 868,1MHz, 868,3MHz, 868,5MHz. But i take into account only the one at 868,1 because my gateway is set at 868,1 with SF7BW125.
The problem is that i dont see any messages in the application console on TTN ! I checked on the TTN gateway console and I noticed that my DevAddr are almost all the time wrong. It’s supposed to be 26 01 19 08 :
I am really lost on where the problem can come from. I tried my ABP activation with a multi channel gateway (sx1308 picocell gateway from semtech) and everything is working fine (the DevAddr is never wrong) so i suppose the problem doesnt come from my end node and comes from the gateway. Maybe there is a frequency to set for the udp transmission in the single_chan_pkt_fwd code ? If someone can helps me it would be nice because i really dont know what to do now.
Thank you all !
How close is the node to the gateway? You need at least some meter.
Around 7 meters, do you think it’s not enough ? Do you think the problem only come from the distance and there is no mistake about DevAddr or a UDP frequency to set in the code ?
Thanks I will try to test with a longest distance this afternoon !