Yes, all DL are visible in console, none missing, even those who are never received at node side. Small amount of UL are being lost, that’s in the acceptable range for LoRa.
About LMIC, I have played around that MAX ERROR, and now it’s on 1%, could not find any other value to make the results more consistent. Sorry for off-topic, I’ll make another thread.
If this is the cause (which must for the moment be considered unproven), the way to combat is probably not to alter behavior of real nodes, but rather to do something like make a dummy node set to minimum power with a resistor in place of an antenna which periodically sends a packet that is valid LoRa, but invalid LoRaWAN and so will be passed by the gateway but quickly ignored by the backend servers. Though first start with an actual node with those power reducing measures, and verify if it improves performance of the other nodes. The point is that if you need something to work around a bug and keep the gateway connected, you only need one such thing, you shouldn’t need to have all your nodes chattering away at a high rate consuming battery and bandwidth.
Of course the only real solution is for the firmware source of the TTIG to be released so that the community can fix it. The fact that this did not happen at the time of product release is grotesquely in conflict with everything TTN would appear to stand for. That’s an issue regardless if gateway bugs are to blame for this particular situation, or not.
That’s somewhat dubious, this would simply not work in a network with a 1-second RX1, so if it is happening, it is probably unforeseen behavior of components used rather than an intentional feature.
I changed TX_INTERVAL to 180 seconds and suddenly all works fine. Mystery!
Maybe all this fuss was just because of LMIC’s example code default time interval - 60 sec, who by some coincidence conflicts with TTN?
Taking into account that a GW reconnects almost immediately, and TLS handshake consumes a lot of resources server-side… It seems to be a pretty questuionable optimization.
Are you sure they have an access to the sources (developed by TrackNet and/or Gemtek)?
But it seems this issue can be resolved at server side.
2019-05-30 13:41:06.522 [AIO:DEBU] ssl_tls.c:6546 MBEDTLS[1]: mbedtls_ssl_read_record() returned -30848 (-0x7880)
2019-05-30 13:41:06.526 [AIO:ERRO] Recv failed: SSL - The peer notified us that the connection is going to be closed
2019-05-30 13:41:06.532 [AIO:DEBU] [2] WS connection shutdown...
2019-05-30 13:41:06.543 [TCE:VERB] Connection to MUXS closed in state 4
2019-05-30 13:41:06.551 [TCE:INFO] MUXS reconnect backoff 1s (retry 0)
(log’s taken from Hacking the TTI Indoor Gateway - Tinkerman )
So it seems to be the server what closes connection.
So to summarise it is an issue and there are what I see as 3 solution.
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.
Actually the maximum is 1023 but the upper two bits are in a different register.
Aha, I see, they are mapped in RegModemConfig2
Never noticed it and never needed it 
But thank you for your addition!
Indeed, but for, e.g., the closed source NOC, integrations and TTN Console in V2, issues could be reported on Issues · TheThingsArchive/ttn · GitHub
@KrishnaIyerEaswaran2 (@laurens, @rish1), is there any place where possible bugs for the TTIG can be reported?
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.
Too bad. Thanks anyway for the answer and the information.
Do you happen to know if this implies that it might not be the server that is causing the WebSocket connection to be dropped?
Or, @KrishnaIyerEaswaran2, could you tell us who’s dropping the connection?
Sorry, no. I would have to speculate so let’s wait for an authoritative answer.
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.
I guess you’re keeping an eye on Basic Station Integration: Race condition in re-connection handling causes permanent failure of uplink forwarding · Issue #1730 · TheThingsNetwork/lorawan-stack · GitHub but just to be sure: this introduced new problems with internet providers that reset the connection every 24 hours (and maybe also assigns a new IP address lease). From Slack:
Every morning the same problem The TTIG Gateway does not transmit data anymore
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.
Hey yeah indeed.
We (TTI) should improve how we communicate these changes.
We’ve deployed a potential fix here: TTIG Problems, - no location data, wrong date/time, wrong channel and stability issues
We’ve currently deployed the update only to the US West cluster. EU soon to follow.
If you still have issues, please post your observations in this thread (not in the one I posted).
Thanks,
Krishna
Krishna, apparently this does not work for all TTIGs, or some regression has occurred since February? A few instances that seem related:
…for which on Slack some more details are given:
@Martin_Kautenburger 2020-05-07 11:31 PM
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.
