TTIG : The Things Indoor Gateway

I have the same at the moment, however when its flashing its receiving data.
There are some instabillity problems with the server side handling of TTIG according to HTDVisser.

46%20PM

Am curious to know if others are seeing the flashing green LED on their TTIG? I’ve been looking at mine (sitting on my desk next to my monitor) and it seems to be doing this 2 or 3 times a minute now. I’m still seeing it pass traffic, but it’s difficult to know if there is a problem as I only have one edge device that reports every 15 minutes or so.

yes you’ve mentioned that before :roll_eyes:

I have it too and I’ve tested that, when it’s flashing green, it still is able to receive data from a node.
However I’m sure TTI is aware of this and we hope for an explanation / solution.

In response to the "flashing green LED " question:

Yes that’s normal behavior.

If there’s no traffic on your gateway for about 60s, the WebSocket(WS) connection to the network is dropped intentionally and the gateway will re-connect. During reconnection, the LED will flash green.

The reason for this to not have gateways actively connected to the network and taking up resources when there’s no traffic (since WS requires a persistent connection).

2 Likes

That could also explain the occasional delays I see between the node sending an uplink and the time I receive it in the backend.

3 Likes

Thank you - that was very helpful!

2 Likes

Which are the 2 rf connectors in the concentrator board?
One seems like an UFL MHF1, the other is a MMCX or something completely different?

Wouldn’t it make sense to increase the WebSocket(WS) timeout to 5 or 10 minutes or to adjust it dynamically?

I noticed that it takes ~2 seconds when the packet was received by the TTIG till it starts a new WS connection and another second till the connection is established and the packet get’s send. If the packet is received by multiple gateways deduplication doesn’t work anymore and the packet shows up as “retry” in the TTN console. Also in conditions where rx packet frequency is between 1 to 10 minutes it might cause more load in the backend then leaving the session established…

TTIG WS established -> immediate transmit of the packet to TTN
07:12:43.703939 IP LorixOne.44329 > 52.169.76.203.1700: RADIUS, Access-Request (1), id: 0x83 length: 243
07:12:43.711171 IP IC880a-RPi.41703 > 52.169.76.203.1700: RADIUS, Access-Request (1), id: 0x79 length: 243
07:12:43.734337 IP TTIG.17829 > 52.169.76.203.443: Flags [P.], seq 848:1221, ack 1814, win 5840, length 373#

TTIG WS NOT established -> 2 seconds till tcp connect:
07:13:45.816602 IP IC880a-RPi.41703 > 52.169.76.203.1700: RADIUS, Access-Request (1), id: 0x0a length: 243
07:13:45.818058 IP LorixOne.44329 > 52.169.76.203.1700: RADIUS, Access-Request (1), id: 0x18 length: 243
07:13:47.912911 IP TTIG.54858 > 52.169.76.203.443: Flags [S], seq 73142392, win 5840, options [mss 1460], length 0

image

2 Likes

Also to add, wouldn’t the Downlink listen window on the device be missed because of the large time delay between Uplink transmit and when the TTN servers received it? Therefore, unless another active gateway is in the area, you’d never be able to get a Downlink packet to the device.

2 Likes