Single Channel Packet Forwarder part 3 [Deprecated]

My Respberry Pi 3B is useful enough for programming my Single Channel gateway.
Clipboard03

I spent 3 hours trying to compile ESP-1ch-Gateway-v5 with TTGO ESP32 Lora v2, but ring no bells.
There are no instructions also for building for ESP32.

PS. Finally hacked libs and build the firmware.

PPS. What are safe settings for gateway and client both on TTGO Lora v2? CAD? HOP? Frequencies? SFs?
I got strange behaviour, my node cant register with otaa, and even worse, sometimes gw does not receive packet from the node. I reset the board, wait some time, if no packets are showed on the GW, I reset again, sometimes on node reset gw receive packet and show on OLED, sometimes not.

How can I debug this?

Hi All,
I’m running the 1Ch GW with Lua firmware today. I looking for a version in C/C++ which handle downlink. I’ve tested some versions without success. Can you advise?

Regards,
Luis Viola

ESP-1ch-Gateway-v5.0 usually handle downlinks.
But if you are trying Plan Frequency 915 the code have a bug on the downlink.
The downlink Bandwidth needs to be 500k but the code uses the same 125k instead.
I fix this issue and submit a Pull Request.
Check my fork if you have interest.


See ya!

2 Likes

Great news, let me check it now.
Thanks

1 Like

Thank you, single channel GW working OK with this code on Heltec Lora32 v2 and TTGO Lora32 v2.0!! Best

1 Like

Hello,
I’m building an PiZero Gateway with an adafruit RFM95 Breakout and I’m using the software from https://github.com/hallard/single_chan_pkt_fwd described above.
All is working well, despite of that the gateway Id I receive wenn start single_chan_pkt_fwd is 00:00:00:FF:FF:00:00:00 and I cannot register this at ttn as a gateway, because it’s already in use.

grafik

What can I do? Can I change the gateway id in my rfm95? Would be nice, if anyone could help.

Sorry, I’m a beginner and likely my question is one of those of beginners…

Regards,
Michael

You have to change the network interface from “eth0” to (I guess) “wlan0” in your source and recompile.

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 :frowning_face:
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 :slight_smile: ).