My gateway doesn’t run long enough to be able to update to beta fw I guess, I have that feature enabled a few days, but versions stay the same.

It was glued with a piece of foam underneath.

After some more testing, I think this might be a temperature related problem with the LoRa card. If my gateway is powered off for a while, it works for a few minutes but once it’s gone faulty it won’t work until I let it have a ‘rest’ again. A short power cycle doesn’t cure it.
The LoRA card gets very warm very quickly - is that normal?

If you switch off gateway for a long time and start it. it gets connected to ttn console once.
But after that it fails (ie the last seen time increases) My lorawan card is warm but not hot, it’s inside it’s normal working temp I think.
Some questions what does reboot reason 0x13 mean?

*   The Things Network   *
*      G A T E W A Y     *
Firmware name: AmazingAckermann, type: 0, version: 1.0.0, commit: 917719b9, timestamp: 1498499973
Bootloader revision: 1, commit: 7167873a, timestamp: 1496411298
Build time: Jun 26 2017 19:59:53
Reboot reason: 0x13

Maybe this is a valid reason, but some time after that it reboots in the middle of the test CNFG: Load onlin (notice it’s truncated) it does this every time at same spot.

CNFG: Load online user config state change to 6
HTTP: Starting connection
HTTPS: Connection Opened: Starting TLS Negotiation
HTTP: Wait for TLS Connect
HTTP: TLS Connection Opened: Starting Clear Text Communication
HTTP: Got 1232 bytes
HTTP: Connection Closed
HTTP: Close active socket 1

CNFG: Load onlinSNTP: State change from 0 to 0

Looking at that last line, could it also be NTP related? Maybe it corrects the time wrongly (too big step or backwards) after the first reboot causing a software error or watchdog issue.
Will try to block the request and see. Maybe SNTP doesn’t stand for Simple Network Time Protocol in this case? We need the sourcecode in a github repo!

Hi there,

Thank you for the great project! I was happy to get my packages in the mail this week (through Skynet), and couldn’t wait to unbox the gateway, uno’s and node.

Unfortunately, I haven’t be able to connect to the TTN network yet. As a few others mentioned above, I am able to connect it to my local WIFI network (and after that, i’m even able to connect to read out the /info page on the by our DHCP provider ip adress of the gateway), but it enters a reboot loop after the third LED started blinking for a few seconds, stops, and then all LEDS start to blink and the gateway starts to reboot.

I’m waiting for my UART cable to get some more information from the serial port.

For now: i’m not in a hurry, I wish you a good conference, but if you need me for some testing, just know that i’m there to supply extra debug information or to test any new firmware builds (if that would be a solution).

Welcome to the club of backers who made this all possible in the first place but must wait for support.
Perhaps we need to find a good banner maker, and organize a protest outside the conference! :triumph:

I want to fill this hole in the TTN coverage in my neighborhood for some years now…


1 Like

Aha, that’s a new option!


But, would “Beta firmware can be unstable, use at your own risk” have any implication when I brick it?

Yes. We were also sceptical, but both Semtech and Microchip assured us that it’s within normal parameters.

We are working on getting everything ready for Github. They promised us that we could publish it during the conference.

The firmware update does not overwrite the bootloader of the gateway. If things go terribly wrong you’ll be able to flash firmware from an SD card.


Enabling “Beta Updates” in TTN Console does not show anything different than my earlier log. In other words: I don’t see it trying to download the firmware, maybe as it never successfully completed Step 4 of its initial activation.

Also, erasing the serial flash (holding down the “mode” button while powering up) and then using ethernet rather than WiFi in Step 3 of, makes no difference: I still see it fetching some frequency configuration from the internet, soon followed by LORA: Configuration failed, retry (sometimes two times) and then rebooting.

Unlike I thought earlier, the reboot reason is not only Reboot reason: 0x13 but often shows Reboot reason: 0x53. I don’t know which one is shown why.

In the earlier and today’s log I noticed HTTP: Got 1232 bytes (I assume decimal?) for both WiFi and ethernet in:

HTTP: Starting connection
HTTPS: Connection Opened: Starting TLS Negotiation
HTTP: Wait for TLS Connect
HTTP: TLS Connection Opened: Starting Clear Text Communication
HTTP: Got 1232 bytes

…but shows Content-Length: 3309 (decimal, excluding any HTTP headers). Could that difference in size indicate some problem?

Of course, maybe those lines in the log are very much unrelated. Or maybe the gateway gets it in some gzip’d transfer encoding, while my Chrome does not.

…apparently being the following, which I don’t know how to use:

------- Supported command groups ------
 *** tcpip: stack commands ***
 *** wifi: Wi-Fi commands ***
---------- Built in commands ----------
 *** reset: Reset host ***
 *** q: quit command processor ***
 *** help: help ***

Did you find something more?

And some asides:

I haven’t found a purpose for it yet, just wanted to mention there is a menu :wink: However you can then run help tcpip, help wifi etc to get more info.

1 Like

Ah, I figured I needed to prefix commands with tcpip or wifi, but no. As help tcpip shows the following, one can just enter those commands without the prefix:

*** netinfo: Get network information ***
*** defnet: Set default network interface ***
*** dhcp: DHCP client commands ***
*** dhcps: Turn DHCP server on/off ***
*** zcll: Turn ZCLL on/off ***
*** setip: Set IP address and mask ***
*** setgw: Set Gateway address ***
*** setdns: Set DNS address ***
*** setbios: Set host's NetBIOS name ***
*** setmac: Set MAC address ***
*** if: Bring an interface up/down ***
*** stack: Stack turn on/off ***
*** heapinfo: Check heap status ***
*** dhcpsinfo: Display DHCP Server Lease Details ***
*** ping: Ping an IP address ***
*** arp: ARP commands ***
*** dnsc: DNS client commands ***
*** macinfo: Check MAC statistics ***

Like: ping

Ping: resolving host:
Ping: request sent to: [
Ping: reply from time = 8ms
Ping: reply from time = 7ms
Ping: reply from time = 6ms
Ping: reply from time = 6ms
Ping: done. Sent 4 requests, received 4 replies.

It’s a bit hard to type the command while it’s rebooting all the time, and to read the output between the regular log lines. But: might be useful indeed!

If anyone with a trouble-free gateway hooks up a serial cable, can you please let me know what URL and size you get in the following part?

HTTP: Starting connection
HTTPS: Connection Opened: Starting TLS Negotiation
HTTP: Wait for TLS Connect
HTTP: TLS Connection Opened: Starting Clear Text Communication
HTTP: Got 1232 bytes

Hi There,
Received my GW, was hoping as read here to have setup in less than 5 min (not my 1st GW setting, but first one with the TTN one) :

  • First boot, 1st led fix, 2nd fast blink, great expected, so I went to TTN install portal but stuck to connect to GW
    Ok let’s see, OMG no Wifi AP seen on my Computer Windows 10, ok let’s see with my mac, same thing, my iphone, same thing, Wifi AP does not seem to start (or at least seen), power off then GW Power on with reset switch, to force AP, same thing no WiFi!
  • Ok plug Ethernet cable into GW, TTN portal see gateway and continue configuration, I setup to use Wifi, My Office Wifi is seen by setup, I select it and put password.
  • GW configuration is continuing GW seen on console, everything works. got it !
  • Remove Ethernet cable, reboot the GW to be sure and it’s down, 1st led fix, 2nd slow blink heuuuuu
  • Ok, needed to wait some minutes, but that’s it all is working :wink:

Anyway, just amazing I never saw the GW as an AP as setup mention, if anyone is experiencing this, just plug network cable, will remove you some headache

1 Like

Where can one download the firmware, and what would be the process to flash it onto the device?

1 Like

Here is my status… still no luck.

Version Info	
Hardware:	    v1
Bootloader:	    r1-7167873a (2017-06-02T13:48:18Z)
Firmware:	    v1.0.0-917719b9 (2017-06-26T17:59:33Z)
Uptime:	    265
Connected:	    true
Interface:	    WIFI & Ethernet
Wifi SSID:	    ...
Activation locked:	    true
Config correct:	    false
Gateway Card:	    ND
Packet forwarding	
Broker connection:	    false
Packets up:	    0
Packets down:	    0
External storage:	 false

Any idea how to progress ?

One extra piece of information from the web server error message:

the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.

Maybe I must note that I tried with switch-router and with ttn-router-eu , my ISP is UPC and I am based in Switzerland.

My gateway has the same problem - stuck in a loop.

Has anyone any suggestions how to get this working?

Yesterday the gateway arrived - but unfortunately, same story here. Initial setup through wifi - ending up in boot loop. Second try using ethernet, same story - also after full reset. The device does register on the local network, below the screenshot of the /info page - and also of the console, showing the device never managed to connect. Hoping for a solution as much as everyone else here!


I can’t get my gateway ready to work. After resetting, everything look to go smooth including configuring the gateway. But after a short while, it keeps rebooting. Also no packets are being sent.
Tried to reseat the lora board, but no success. See my configuration page of the gateway that looks correct during some time between reboots.

1 Like

Gateway has been seen by TheThingsNetwork for a short while:

In TTN they ought to be able to see how many people are registering a Gateway, and how many Gateways are successfully connecting… so as to get a view on the scale of the problem. Most people posting here are posting messages of frustration, but it’s hard to tell if DOA (also known as ‘doorstop’) is the norm or the exception…

Anyway… to those out of luck… I feel your pain!

Yes, please. Many have asked, and that list alone might be so helpful, if only to decide to just wait rather than spending time trying to decipher the serial output (like what does HTTP: Got 1232 bytes refer to?), or rather than trying all kinds of different ways to activate the gateway.

Why does it take TWTG more than 40 days to publish that list?

When ready earlier, please, please just publish it and not wait for the conference? There are many smart people around here who might find the flaw that makes some/many gateways reboot—I’d say that such would make an even better announcement at the conference! :slight_smile:

Some people here might even find a fix, if the following is documented too: