…how would you even prevent that?
I know I can’t… but I just want to be welcoming…
I left my gateway powered on once more during the night, eventually it gets online but I guess this happens when it stays running just long enough to register itself online, in the morning no contact was possible. So it seems the configuration is correct, right?
I have received and activated the gateway without problem with home ADSL but now I have to connect the gateway in my company network with ethernet cable.
I need to know how I have to configure the firewall for the needs of the things gateway and also an easy method to find the mac address of the ethernet interface will be usefull.
In Boston, which is comparable in size to Amsterdam, I may ask some well-situated individuals/companies whether they may wish to host a TTN gateway. I am guessing that some may want to know how much total traffic it would be expected to use, how much of their Internet resources it would consume. How should I best answer that? Is there a record of bandwidth utilized by Amsterdam TTN gateways that I could cite? Thanks.
@sronan I can tell from practical experience in our Apeldoorn community that our gateway does 10 Megabytes per day data.
Received my gateway today.
It has the 5 led on then reboot loop issue, caused by poor connection to the Microchip radio card.
I’ve managed to fix mine by removing the foam rubber piece under the radio card. I suspect this was a ‘quick fix’ addition at the factory to try and help with this issue but in my case the foam was too thick so that the radio card wasn’t parallel to the main board. Removing the foam has allowed me to keep the radio board parallel and it seems to be working much more reliably now.
Maybe it might help someone else?
OK. Spoke too soon. It still has the same issue
The rebooting problem seems to be solved by installating beta frimaware. This can be activated via the gateway console.
Stable for over 3 hours, before just a couple of minutes.
Note: Rebooting again
Maybe my gw shares the same cause, i tried to losen the two white pins on the lora board but i couldnt lift it from its socket as if it was glued to the mainboard. Was that the case in your gw as well?
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
FREQ: APP_URL_Buffer: https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870
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!
I want to fill this hole in the TTN coverage in my neighborhood for some years now…
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 https://activate.thethingsnetwork.org, 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:
FREQ: APP_URL_Buffer: https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870
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 https://account.thethingsnetwork.org/api/v2/frequency-plans/EU_863_870 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:
-
For WiFi I use an XS4ALL FRITZ!Box modem. This supports IPv6 but the gateway does not seem to use that, or prefers IPv4. The gateway’s information page can be reached at both http://things-gateway/info and http://things-gateway.local/info
-
For ethernet, I use some Ziggo/UPC Technicolor modem, IPv4 only. Its DNS needs the
.local
suffix; the gateway can only be reached at http://things-gateway.local/info -
When using ethernet, it seems the activation JavaScript relies on
things-gateway.local
to resolve. -
The http://things-gateway.local/info page will keep refreshing its details depending on its internal state. Like: “Config correct” might first show “false” but “true” later, “Region” might be empty first but become “EU_863_870”, and “Gateway Card” might change from “ND” (not detected?) to “868Mhz”.
-
When trying to use the Ziggo ethernet while the XS4ALL WiFi was still configured, the ethernet’s DHCP would just be too slow for the gateway to get a lease, so it would choose WiFi instead.
-
Not quite useful, but some URLs: http://things-gateway.local, http://things-gateway.local/info, http://things-gateway.local/id.cgi, http://things-gateway.local/status.cgi, http://things-gateway.local/settings.cgi, http://things-gateway.local/ssids.cgi
-
I am using PlatformIO on a Mac to append the serial output to a file, while prepending a timestamp to each line (and adding a date to the name of the log file). Like:
LOG="ttn-gateway-`date +'%Y%m%d-%H%M%S'`.log"; pio serialports monitor --raw -b 115200 | while read l; do echo "[`date +'%F %T'`] $l" | tee -a $LOG; done
-
I am using a Raspberry Pi to save the serial output to a file, while prepending a timestamp to each line.
I haven’t found a purpose for it yet, just wanted to mention there is a menu However you can then run help tcpip
, help wifi
etc to get more info.
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 google.com
:
Ping: resolving host: google.com
Ping: request sent to: google.com [172.217.20.78
Ping: reply from 172.217.20.78: time = 8ms
Ping: reply from 172.217.20.78: time = 7ms
Ping: reply from 172.217.20.78: time = 6ms
Ping: reply from 172.217.20.78: 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!