So to summarise it is an issue and there are what I see as 3 solution.
Keep the web socket Connections permanent open. - consumes resources.
Action by TTI on TTN Servers.
Keep sending traffic to node say every 20 seconds with short payload.This seem wasteful in air time and on TTN server resources but is the only option open to gateway / node owners.This is easy to set up with a spare node.
TTI Change server software to take account of the disconnect of web socket in regard to handling down links and intersection to the TTIG.- Action by TTI.
I hope TTI looks seriously at this issue and resolve it as it causes issues with ADR and Acknowledge responses and packet loss. To have all of the TTIG owner sending dummy traffic to keep gateway open is very wasteful on TTN.
Related to above when will there be update software for TTIG?
During Semtech’s Basicstation (workshop) presentation held at The Things Conference last January, it was mentioned that Basicstation itself is open source, but the implementation of the ‘Platform Layer’ and ‘Radio Layer’ building blocks for ESP8266 (used on the TTIG) are closed source.
This makes availability of an open TTIG project on Github less likely.
Is there a way to widen the RX window with LMIC library?
Well I guess the answer is yes and no… Search in the radio part of the code for the register LORARegSymbTimeoutLsb. It defines the timeout in RX1 and RX2 in terms of number of symbols. For instance in RX2, receiving SF9, if you set this value to 80 symbols, it will be about 300 ms for the LoRa module to timeout if no preamble is received. If you set a higher value, the LoRa module will search longer for a preamble, and would also capture a transmission that may have started somewhat late.
But remember you can’t shift RX2, it needs to start at 2 seconds after TX_ready, so the only thing you can do is extend the timeout. And the maximum would be 255 symbols.
Is there anything new on the subject? I came across this problem with my TTI Gataway. If my node sends an uplink every 10 minutes it is obviously too long and many values are lost. Now I have additionally installed a dummy node that sends every 2 minutes and now all values are transmitted without loss even at 10 or 15 minute intervals. But that doesn’t seem to be a really good solution to me, if you should actually keep the traffic low.
During the conference I got confirmation that work on ongoing on new firmware, however progress is very slow. TTN does not own the sources and can’t do the work themselves and they can’t release the sources to allow the community to improve things which is a shame as I know there are several avid ESP developers in the community that should be able to help out.
Hey @kersing/ @arjanvanb,
It is indeed the server that drops the connection. The TTIG currently runs 2.0.0 of the Basic Station packet forwarder which does not implement WS Pong. With the upgrade to 2.0.4 which we are planning, we’ll be able use this to not terminate active gateway connections.
Quick Note: We increased the keepalive time from 60s to 600s. So your gateways will now only reconnect every 10m if there’s no traffic through it.
Thats exactly the same what i have seen as well. My ISP resetted the internet connection (which always includes new IP addresses) in the night from 2020-01-29 to -30 and my TTIG became trouble. Before that date, ISP resets were never a trouble.
Such an ISP-reset of the internet line takes normally appr. 90 seconds to recover.
Hi, i own 3 TTIG, the devices disconnects a few times a day. A few month ago the ttig works very good. But now it is not usable. I see on ttnmapper there are many ttig with the same problem.
I haven’t made any updates to the bridge in a while so there aren’t any regressions.
The received status messages is a strong indication of how often gateways reconnect and based on the graph below, it’s non-periodic and non-synchronised (as I expect).
[Excerpt from our metrics for the last 24 hours]
The disconnection could be due to;
Client-side disconnects (need to check with the gateway guys)
Flaky internet connectivity (but I don’t think this is the case for all)
I’ll do some tests locally and revert.
In the meantime, a disconnection will not affect your ability to forward traffic when the gateways reconnect.
In our previous update, we re-wrote the connection logic with special attention to unclean client-side disconnects.
I tried testing this locally but I’m unable to reproduce it. Even with the shitty WiFi in my apartment, the TTIG does not disconnect periodically or when it does, comes back online and can route packets immediately.
@arjanvanb: What doesn’t match? The reconnection logic and server side WS pings work together and are not opposite features.
My debugging is not being helped by the fact that a lot of people are reporting (here and on Slack) that the gateways are disconnected with it’s only the NOC/Console not displaying the connection.
Can someone who’s facing multiple disconnections (i.e., the gateway LED rapidly blinking often before stabilising) please send me your EUI so I can trace it on the server?
But thank you for your addition!