I believe the part you are looking for is the LG8271 or 9271 (region dependent) or some close variant - when I looked before Xmas at usual suspects (Mouser/Farnell/Digi-Key etc.) I couldn’t find stock but haven’t checked recently.
See pdf LG8271_9271_Gateway_Board_Manual.PDF (550.9 KB)
The error messages on the FAQs of TTN web page says to check to see if the UNO connected to the gateway. The link you sent is not an issue I am facing. I have lights and it shows that everything is working on the UNO however, it can’t complete OTAA.
On a side note the gateway keeps rebooting, any ideas there?
Thanks. I’m not finding them for sale anywhere.
Speak for yourself 
Would like to get the gateway operational in the first place.
I guess the fix for this logged defect is the one we are waiting for?
Did you have any success to capture the logging to find out if there is any particular point when your gateway crashes?
Several people shared their logs here, or the LED status. We probably need another approach, driven by TTN who have knowledge about the gateway hardware and software. I cannot imagine that 10’s (or more) gateways have issues here and they never saw a gateway with a similar issue in their lab.
Did anyone visiting the conference had a try to ask twtg what the plan and possible fault reasons are?
Today I received my 2nd TTN gateway. Unlike my 1st gateway this one has been operating flawlessly for at least 6 hours now (whereas the 1st one never succeeded in maintaining a stable connection with the TTN network for longer than 20 minutes before descending into the reboot loop).
I have been receiving messages from my TTN node and a SODAQ One without any problems during this period.
This 2nd gateway is operating under virtually the same conditions (i.e. location, setup, even using the same wall socket 
) as the malfunctioning 1st gateway (albeit that I did not install the beta firmware on the 2nd gateway that I installed (in vain) on the 1st gateway).
This strengthens my belief that the 1st gateway is suffering from some fault in assembly or component.
It strikes me as curious that the gateways do not have a serial number?! This would have been helpful in identifying a possible bad batch of malfunctioning gateways.
I talked to them and they told that they had 20 gateways running to reproduce the failure and have not been successful so far. It seems time to send them faulty ones I think.
@TheThingsNetwork just let me know and I can bring my gateway to your office in Amsterdam when going to work. 
Same for me. If I can help by delivering my faulty TTN-gateway to your office, I would be happy to do so.
Why don’t they ship the 20 working ones to us then?
In this forum there are 56 different users reporting that their NTT gateway is in the loop. If you add mine that has the same problems we are at least 57 identified users with a none working gateway !
greetings from Luxembourg
Maybe swap them out with people who come bring their bootlooping gw for testing?
Different types of reboot-problems have been reported. As long as it is not clear what exactly is causing this, a link with the environment can not be completely ruled out. The gateway could decide to reboot after the response to a a network request times out. It is therefore important that problematic gateways are brought into the lab for additional testing.
I’m activating my new TTN gateway. I have followed the steps but my gateway restart after the activated step.
LED1 and LED2 are on, LED3 is blinking slowy and become on but after few seconds LED3 switch from on to off to on and after gateway restart. ( in video it’s more easy https://youtu.be/Rb-KZeLbR-0 )
I have tried to reset from factory the gateway but I arrive on the same step every time.
Any advice to fix this ?
Thx
Hi all.
I was replying to Arjan’s post about reboot reason 0x13 on the FAQ page, but I found out this was not the right page. So I replace it to here.
Hi Arjan,
I have this same issue, so I did a small investigation to, and I think it is indeed an bitwise OR.
As I did see a file called “wdt_p32mz2048efm144.h” in the github source I assumed the equal controller being used in the gateway is the pic 32mz2048efm144. The datasheet can be found here: https://www.mouser.com/ds/2/268/60001320D-967555.pdf.
Figure 6.1 in this document shows it is all combined to an or.
Heading 16 is telling is more about the WDT. In here I read the software on the controller must give a reset to the wdg timer within the wdg timer prescaler value called WDTPS. On github the file TTN_Gateway_v1/system_init.c contains a value called WDTPS so I am pretty sure this is the controller used on the board.
I will look futher into this tomorrow to find out why the WDT is triggered, but it looks like a software hickup on the controller and not something with the LARA module.
Edit:
So looking into the gateway I can confirm the controller is the PIC 32m2048efm144.
I found another interesting document about the wdt: http://ww1.microchip.com/downloads/en/DeviceDoc/61114E.pdf
So the #pragma config WDTPS = PS8192 in the firmware system_init.c could be according to the above document a post scale ratio divider of 1/8192. Which sets the watch dog timeout to 8,192 seconds. Now we only need to find out why the processor is being interupted for 8,192 seconds.
According to my UART log, the last thing the gateway is doing is inside the static void restart_lora_configuration(void) function in firmware/src/app_lora.c
Edit 2:
Ok so I found out WDT timeout is being reset every time “MON: SYS Stack size: xxxx” is being print to the UART log. This is done in the same function.
So there seems to be 2 issues.
1: LARA configuration is failing. The PIC 32m2048efm144 and the LORA module can communicate though, because it can retrieve the LARA version from the LORA module.
2: after 3 configuration tries, the software will perform a hardware reset to the LORA module. The WDT timeout seems to be to tied to successfully reset the LORA module.
OK, looks like my gateway is officially STUFFED!!! NOW!! after a few days powered off, I power on today and only the first (Power) LED is solid with the second LED flashing rapidly, and its been like this for hours!?
I’m rapidly losing faith with this hardware and the teams ability to communicate/resolve this in a timely manor
What does it mean when your gateway’s connected to the “Network” but “Broker Connection” is false? (as per the info page)