For what it’s worth, my gatway is now actually unusably broken for real use… The TTN thinks my gateway is online. The gateway thinks its online. The LED flashes when a LoRa packet is received and the counter goes up on the device. Yet nothing in the console.
This was pretty rock solid realiable, and right now it’s basically useless.
Time to start getting dirty and trying to debug this thing too I guess. Very disappointing.
You mean the gateway’s Traffic page in TTN Console? Maybe bad CRCs, I’d try another node.
8 Hours ago there was some problem on the backend (EU?). Packets where not displayed after 22:50 UTC. Packet forwarder log was ok…
Suspect there was something weird happening around that time as I noticed three collocated gws under test all showed different info. A laird & imst lite seemed in sync showing same packets & time stamps & count & were visible as “last seen” and connected. The ttn gw however kept disappearing with “last seen” often extending to 2 mins, 3 mins even 8mins+. This manifested as 3 open browser windows for each gw showing different packet received list. At one point the ttn node was only showing 1 in 6 and the counts seemed to get out of sync with the other 2 and time stamp for the ttn node showing count # against wrong time stamp value. Given my earlier post about suspecting a temp dependence on the ttn gw - temp in roof space obviously dropping as night went on - I assumed problem my end. Checked gw connection aro 12:30am as left office and could see solid 4 LEDs & regular enet port connection traffic. All 3 backhaul through same DSL hub & internet connection. Checked this morning and looks solid again.
Clarification - collocated as all at same premises, but only imst & ttn currently sharing roof space as laird only commissioned yesterday and on test in office b4 move to roof space later today…hence was looking carefully at comparative data 
Just for future reference: during the major EU region problems that were happening until a few moments ago, I also got into regular reboots with RQMQTT: Connection failed followed by MAIN: MQTT error and Reboot reason: 0x10.
At other times in the recent logs I see MQTT: Connection lost (rather than failed) like the following:
LORA: Accepted packet
MQTT: Sending UPLINK OK
LORA: Accepted packet
MQTT: Sending UPLINK OK
MQTT: Sending status packet
MQTT: Sending status succeeded: 1
MQTT: Connection lost
MAIN: MQTT error
…followed by many:
MQTT: GOT IP: 52.169.76.203
Connecting to: 52.169.76.203
MQTT: Opening socket timed out, restarting
MQTT: GOT IP: 52.169.76.203
Connecting to: 52.169.76.203
MQTT: Opening socket timed out, restarting
MQTT: GOT IP: 52.169.76.203
Connecting to: 52.169.76.203
MQTT: Opening socket timed out, restarting
So, it seems Connection failed (often) yields a reboot, but Connection lost makes the firmware try forever.
(Right now, without me interfering, it’s reconnected just fine again.)
@htdvisser, if possible, can you provide us with an update of the team’s current progress or status on the “reboot” issue(s)?
I’m not involved with the gateway firmware development, so I don’t know the details. The last thing I heard was that they’re working on changing the baudrate of the UART communication between the microcontroller and the LoRa module. It turns out that this requires more work and testing than expected, so we’ll just have to be patient.
Hi all,
The range of my TTN gateway (stock antenna) leaves a lot to be desired. I am looking for some reference to tell whether I need to adjust my expectations or something else… 
I am aware of how tricky radio transmission is with near-field effects, obstruction/reflection and what not. At the same time there are use cases with gateways in manholes with a reported usable range of 500 meters, sensors within shipping containers that reach up to 2 km (babbler.io). Surely my gateway in the attic behind (mostly) standard dutch roofing (hardboard with rooftiles) on most sides should do be able to provide a useable range of more than 500 meters?
I have one measurement at 500 meters, but it is an outlier, in most directions I don’t get near that.
I have done some RSSI measurements near the gateway using a Things Node and a Things Uno (-40 dBm at 1,5 m), but I don’t know if that means anything or not. Any suggestions, experiences?
[edited: typo in babbler.io URL]
I was doing some investigation by myself how difficult it should be to activate the external clock. According to the PIC datasheet it is a config word which need to be set.
REGISTER 25-1: RTCCON: REAL-TIME CLOCK AND CALENDAR CONTROL REGISTER
.
bit 10-9 RTCCLKSEL<1:0>: RTCC Clock Select bits
When a new value is written to these bits, the Seconds Value register should also be written to properly reset the clock prescalers in the RTCC.
11 = Reserved
10 = Reserved
01 = RTCC uses the external 32.768 kHz Secondary Oscillator (SOSC)
00 = RTCC uses the internal 32 kHz oscillator (LPRC)
When I search the firmware GIT repository, I was not able to find anything about RTC / RTCCON / RTCCLKSEL. However when I tried SOSC I got in the harmony/framework/system/clk/sys_clk.h file:
void SYS_CLK_SecondaryOscillatorEnable ( void )
This function enables secondary oscillator which can be used as a clock source for peripherals like RTCC, Timer etc… The SOSC requires a warm-up period of 1024 before it can be used as a clock source.
But this function is never used. It looks to me this function needs to be called 1024 clockcycles after the SYS_CLK_Initialize function is called in system_init.c (which is a precondition of this function) to fix the problem. Is that right?
That is a different clock. You should look for oscillator settings.
I don’t know if this is of any help. It documents my experience - where a Gateway that does set-up subsequently fails (in a sneaky manner)
You are right. But the document is saying to me that Microship is naming the external oscillator: “Secondary Oscillator SOSC”
That’s exact the same thing I am finding back in the description of the void SYS_CLK_SecondaryOscillatorEnable ( void ) function from the firmware. If I have some spare time in the weekend, I am going to try if using this function during system boot will solve the uart comm problem between the PIC and LORA module.
I have registered my TTN Gateway and try to activate it. I come til step 4 and than the Gateway tries to connect to the internet w/o success.
LED1 is on LED2 is blining slowly.
If I replace the WiFi by Ethernet it is the same.
What can I do?
I am no hardware guy,
FYI,
At 16:00 (GMT+1) today my Gateway stopped working; after EXACTLY 2 months continuous Up-time
I installed the Gateway on Friday, December 22nd (could well have been around 16pm)
16pm today (Friday Feb, 23rd) was the last HTTP Integration my Application received data.
TTN Console for Gateway and Applications did not show any traffic
Multiple Nodes happily showed the blue led every minute.
Powering down/up Nodes never connected; never showed a blue led.
Since TTN Status shows no issues, I pulled the power plug, and (gently) jammed it in again
(I said I am not a Hardware guy, what happens after power-up is always pure magic to me).
Gateway was up and running in minutes again.
Modified video with example of a TTN gateway setup success then failure https://youtu.be/quXQZ_9jGugupdated video
Some statistics - I’m up 25 days with 76 reboots … longest uptime 1 day 00:01:12 and 4 reboots at exactly 1 days 00:00:41 … shortest uptime 00:01:56 - automatic updates and beta software options are not active.
Have a look around in this topic. There are many other reports of the configuration process of the TTN gateway getting stuck at the point where it needs to activate over the internet, just after the network settings have been applied. Investigations and tweaking are ongoing. But there is no “end user worthy” fix available at this moment, as far as I know. My gateway suffers from the same. Since I can not spend the time required to seriously dive into the problem, I am checking this forum topic regularly for an update on status and outlook of the issue.
Mine is also stuck in reboot,
i tried installing the beta firmware from
github.
but i am only seeing version 1.0.1 :
Firmware name: AmazingAckermann, type: 0, version: 1.0.1, commit: facdef23, timestamp: 1518596182
Bootloader revision: 1, commit: 7167873a, timestamp: 1496411298
Build time: Feb 14 2018 08:16:44
and when i powercycle the logging starts immediatly (so no delay to indicate flashing the firmware from the sdcard). Anyone know wat version should be displayed when running the beta version?