Hey mvdswauw,
that it! Thank you very much! I didn’t know, that the gateway id has nothing to do with the rfm95.
Thanx again,
Michael
Hi folks!
I am new one at LoRa things.
I tried to make my own WeMos D1 mini single channel board from this tutorial:https://github.com/hallard/WeMos-Lora and I did it.
I am using this code: https://github.com/SensorsIot/ESP-1ch-Gateway
I added my GW to console, but I get GUI when my GW was not connected to WiFi. If my GW is connected to WiFi then I have this in my serial monitor:
Packet RSSI: -157 RSSI: -105 SNR: 0 Length: 0 21:24:16.400 -> rxpk update: {"rxpk":[{"tmst":2309970632,"chan":0,"rfch":0,"freq":868.099975,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":0,"rssi":-157,"size":0,"data":""}]} 21:24:16.435 -> Packet RSSI: -157 RSSI: -106 SNR: 0 Length: 0 21:24:16.435 -> rxpk update: {"rxpk":[{"tmst":2343263632,"chan":0,"rfch":0,"freq":868.099975,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":0,"rssi":-157,"size":0,"data":""}]} 21:24:16.476 -> Packet RSSI: -157 RSSI: -105 SNR: 0 Length: 0 21:24:16.476 -> rxpk update: {"rxpk":[{"tmst":2358912632,"chan":0,"rfch":0,"freq":868.099975,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":0,"rssi":-157,"size":0,"data":""}]} 21:24:16.476 -> Packet RSSI: -157 RSSI: -104 SNR: 0 Length: 0 21:24:16.476 -> rxpk update: {"rxpk":[{"tmst":2379120632,"chan":0,"rfch":0,"freq":868.099975,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":0,"rssi":-157,"size":0,"data":""}]} 21:24:16.503 -> Received packet of size 4 From 52.169.76.203, port 1700, Contents: 0x01:46:29:01: 21:24:16.503 -> Packet RSSI: -157 RSSI: -104 SNR: 0 Length: 0
and over and over.
OLED Display info:
Time: time is runing
RSSI: -157 and not changed.
SNR:0 and not changed.
LEN:0 and not changed.
What can be the problem?
I solved my problem. I tried latest version on gitgub but again was an error with ip adress. Then I got a code from other user and all works perfectly.
Hi, there’s a lot of useful information here already - so thanks for that!
Have an issue and wonder is someone else has had a similar experience and can offer some debugging tips / advise.
I’ve setup a 1ch gateway using the Heltec LoRa ESP32 dev board, version 2 (http://www.heltec.cn/project/wifi-lora-32/?lang=en) and the 1ch gateway v5 code. So far I’ve tried two versions of the v5 gateway code - the things4u version, which seems the original and the best. And to check against my issues, the kersing version because it specifically mentioned the Heltec board.
I have 2 test nodes, which are BSFrance 32u4 II Lora boards (https://bsfrance.fr/lora-long-range/1345-LoRa32u4-II-Lora-LiPo-Atmega32u4-SX1276-HPD13-868MHZ-EU-Antenna.html). I have tried these so far using just LoRa (works fine) and now LoRaWAN with TTN with both ABP and OTAA modes.
I found that ABP works fine with the gateway set to the same channel as the nodes (channel 0) and CAD (Channel Activity Detection) turned off. OTAA I’ve had much more trouble with.
My main issue seems to be that with CAD turned on, the 1ch gateway misses almost all of the messages on the same frequency. I’ve only successfully managed reproducible results with CAD on SF12, which is far from ideal.
Has anyone had similar experiences with CAD on the 1ch gateway - particularly with this Heltec V2 model? Did you manage to improve the sensitivity to recognise other SFs more reliably?
Hi! I tried to run single channel gateway on my RPi Zero W from https://github.com/hallard/single_chan_pkt_fwd, but it looks like it does not support downstream messages (tx).
Does it mean that my downlink will not work? And nodes will never activate via OTAA?
Yes, in the Hallard docs downlinks are among the missing features. However, there is another version of the same software that supports them:
This is a dual channel version, but with a trick it can be used as single too:
(by the way, this could be added in the software list at the beginning of the thread)
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]