As per my post 6D ago above its not unknown for the wrong type to ship so double check you have a 915Mhz vs 868Mhz version. If it shows connected in the TTN Console then being wrong freq would mean its ‘deaf’ to your 915Mhz nodes and no data coming through and is one of the possibilities to consider… 
Worth checking to eliminate possibility just in case…good luck! 
Maybe a stupid question, but how can I buy it? I can’t find any links.
Not sure where in the world you are but sales are through RS Components/Allied.
Single units: https://uk.rs-online.com/web/p/radio-frequency-development-kits/1843981/
Back in stock 17th June?
I have both a TTIG and a RAK2245.
For test, I send a message every minute with a Steval-STRK01 Lora sensor.
With a message every minute, the RAK2245 got all messages, but the TTIG got only one message over two.
I have now repeated the experiment with a message every two minutes.
Now both TTIG and RAK2245 get all messages.
The sensor is in the house, but far away from the gateways
RAK2245 :
“rssi”: -67,
“snr”: 10,
TTIG:
“rssi”: -69,
“snr”: 10.75,
but variations occur. the rssi of both gateways are comparable.
Not so much, but I am also sure some packet is lost. Which SF do you use? However, as I had the impression that the gateway was not listening for some time after receiving a packet, I did a test as suggested by @LoRaTracker, with a node set for sending every 7 seconds (but ended sending every 12, LMIC takes some time for completing). This at SF7. Almost all packets were received. I would replicate at SF12, but I have to set two nodes for sending one some second after the other.
Hey, we’ve just opened pre-orders for TTIG at Connected Things Store. We have our first units arriving mid-June, so we’re taking orders now and will ship out ASAP.
We can take orders from companies or individuals and ship anywhere in Europe (and wider), so hopefully that will help with some of the supply issues!
You can pre-order here: https://connectedthings.store/gb/lorawan-gateways/the-things-indoor-gateway-868-mhz.html
Give me a shout if you have any problems ordering from the link above and I’ll see if I can help out!
Cheers,
Al
Tom, where’d you get it?
Allied Electronics & Automation.
DHL shipment 6185827244
I was on TTN wait list.
Got e-mail to say “Available now”
Clicked on all the links… whatever…
Purchased.
Arrived.
Obviously a U.S. version.
It’s fine by me.
I only give information in case someone’s interested in process improvement.
I installed a new Indoor Gateway in my house a couple of days ago. The installation went smoothly and TTN says the gateway is connected and receiving and transmitting messages. The documentation says this about the green LED:
GREEN - blinking 1 sec - [GW Mode] WiFi STA not connected
GREEN - blinking 1/4 sec - [GW Mode] WiFi STA connected,establishing connection to LNS, configuring radio
GREEN - solid - [GW Mode] WiFi STA connected, GW connected to LNS, radio listening
Since I installed it, my gateway has been alternating between Green-solid and Green-blinking-1/4-sec. It’s solid for about 55 seconds and then blinking for 10-20 seconds. The WiFi at the installation location is strong and I’ve also tried two other locations with good WiFi. My Internet connection seems stable.
Is this behavior normal? I wouldn’t be too concerned except that I have a device that doesn’t seem to be receiving messages. According to TTN it is succesfully activating but the device doesn’t seem to think so. I also see pulses on the DI1 pin which the LMIC doc tells me is called RxTimeout and the device is acting as if its activations requests are timing out.
Hi All,
We have The Things Indoor Gateway:
MFG date2019-01-21 22:33:33
FW Build2018-12-06 09:30:37
FW Version2.0.0
Core Version2.0.0(minihub/debug)
But we’re facing a problem that the led is not always green. Sometimes it blinks for 30-60 seconds, then it’s green again.
Is anyone of you facing the same problem. We tested it on multiple wifi access points, all have the same behavior.
Regards, Peter
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.
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 
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).
That could also explain the occasional delays I see between the node sending an uplink and the time I receive it in the backend.
Thank you - that was very helpful!
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
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.
Has anyone did a coverage testing on TTIG? IS more than 10Km?
