im relatively new to TTN and LoraWan but in my opinion it is a great system which we need to support.
In my area was nearly no gateway infrastructure so i decided to setup my own gateway.
A few days ago i received my new RAK7258 Indoor Gateway, attached an Delock 3dBi outdoor antenna and placed it on the roof of my House.
The geateway is working fine exept one bad issue. Maybe someone here can give me a hint how to fix this.
The Uplink is WIFI für the Gateway and i installed the latest firmware available at RAKs Website.
The Problem ist that the Gateway stops to deliver received Data to TTN multiple times a day and i need to reboot the Gateway. In this state the Gateway is still shown as ONLINE in TTN but the LAST SEEN counter will not be reset. And the Time grows on. Until i reboot the Gateway.
In this state the Network Conection of the Gateway ist fine. Im able to access webinterface. I can see received lora data on the gateway. Within an SSH Session i can Ping to the Internet and DNS is working to. I can resolve router.eu.thethings.network without a Problem.
You should probably try to get a shell on the gateway, either by wiring up a USB-RS232 Serial cable compatible with the extra RJ45, tapping into the 3v3 logic level UART signals internally at the corner of the processor, or seeing if you can enable SSH in the LuCi web configuration pages.
Once you are in, try logread and logread -f to see if you can figure out if there are any useful error messages when things stop working.
RAK’s “commercial” (as they call them) gateways are closed source (they seem to overlook the license requirement to provide source for the Linux underpinnings…), but they previously published on github sources for building a LoRaWAN gateway around their MT7628 experimentor module and those will also work on the complete gateways if you want to learn about building OpenWRT. At that point you’d have a fairly vanilla and current Semtech packet forwarder modified only with workarounds for some quirks of the processor’s SPI engine, and to slow down the SPI clock on account of there being a very ill-chosen and completely unnecessary level shifter in the radio card that was apparently put there to let it work with another system that it’s basically never used in.
It’s also probable that even without replacing the software install you could add some sort of watchdog script that would restart the packet forwarder if needed. In problems of this type (with other systems) the issue has often turned out to be that a glitch either in communication with the packet forwarder chip, or connectivity up to the network servers has thrown things off, and the necessary retries or restarts haven’t happened to get them going again.
Typically when a gateway is working correctly there is a lot of ongoing log traffic indicating such. So in effect what would be “suspicious” would be the lack of normal log activity about packets received and the communication with the servers.
Possibly RAK’s closed source builds are now quieter - didn’t really run them very long before replacing with a build of their open source repo.
Just a little post, to say i noticed the same with RAK2243.
IT worked fine for few months, since begining of december, i started to play again with LORA and my nodes to see that it has been 9 days the GW was disconnected, no traffic at all in the ttn console.
It is surprising as far as there 4 or 5 actives nodes in my area, pushing data every minutes.
Several reboots succeeded to put it back online. I also upgraded to the latest firmware.
I was away last week, and when i came back yesterday, it was same story, i had to reboot two times to get it back online.
It is connected to wifi, no physicall rj45.
sadly i didnt find any way to monitor ttn uplink, which would helps me to detect disconnection and automate reboot.
To do this automatically on the gateway, look for missing push/pull acks, in the logs, perhaps by packet sniffing, or by rebuilding the packet forwarder.
I think there’s at least something of a python environment.
Personally I ended up rebuilding everything from source - the sources they published for their kits like the WisAP work on the finished gateways too.
While rebooting a box like that is cheap, it may not be a very precise fix - I’d primarily worry about stuck state of the packet forwarder, or problems with the backhaul connectivity.
If you are customizing, give yourself a remote access solution, too.
Hi all, one week ago i switched from wifi uplink to wired uplink and all problems are gone. Looks like the UDP Connection hates my Wifi link. For me it is ok now.