YET? any clues on what it could be used for?
I donāt think the TTN firmware will be using it. But if people flash their own software, one could use it just like one could use the other sockets. (But just guessing.)
Do we have the design details so we could actually do that?
It just arrived (yesterday)
Whoohoo, I managed to compile firmware from the github code, a few caveats to discover and tricks to apply.
Did anyone know what the filename must be for the update file on the sd card and/or how to trigger an update?
I tried it with update.zip, firmware.zip firmware.hex, things-gateway-cyberjunky-1.0-test.zip and simply booting, but no trace, maybe a button press is needed?
The files should be in a subfolder called /update/firmware.hex (about 2.8 MB) and /update/checksums (a few bytes).
(See also No LED, no UART output on TTN Gateway after reset for a note about possible formatting issues.)
Nice I got those:
-rw-rār-- 1 ron ron 79 feb 1 21:22 checksums
-rw-rār-- 1 ron ron 2767956 feb 1 21:22 firmware.hex
Back in a secā¦
It worked lol! I even got packets transmitted, I never had that yet, but the reboot loop is still there 
at least I can add debug messages and tweak stuff.
See also āCompile TTN Gateway Firmware on Ubuntuā in Building the TTN Gateway firmware from the GitHub code.
3 Likes
It seems the reboot loop (for me) is triggered by a watchdog timer. So we might be able to find the cause, or increase the timerā¦
(Or, in my case, it might actually be a proper WDT reset as it occurs after several LORA: Configuration failed, retry.)
See also https://github.com/TheThingsProducts/gateway/issues/1
1 Like
Yeah I tried to find what exactly can trigger the watchdog. But there can be a lot of different reasons.
I guess we need to enable SYS_DEBUG:
SYS_DEBUG(SYS_ERROR_FATAL, "WDT : REASON: %d\r\n", rebootReason);
1 Like
Three out of four gateways we ordered work just fine, but one is in endless reboot loop. Sometimes we can catch it via WLAN, but it stays up maybe one minute before it reboots. Also resetting does not help. Please advise what to do.
Can you check if there are differences between working an non working version when you look at lora board version, date/version/revision on main pcb other visual parts etc?
Are you willing to swap lora board, power adapter etc to see if the problem move with it?
Well, the three working ones are allready installed in a demo system, so no swapping components possible, but I have relatively easy access to one of them so I can take a pic and compare component versions. What should I particulary look at?
For ref, This is for my working gateway
Wed Jan 31 2018 15:56:36 GMT+0100 (CET) analyzing dump for historical events
Thu Feb 01 2018 02:02:03 GMT+0100 (CET) reboot detected, up 6 seconds, previously up for 0 days 15:29:06
Thu Feb 01 2018 14:05:04 GMT+0100 (CET) reboot detected, up 6 seconds, previously up for 0 days 11:56:07
Fri Feb 02 2018 05:53:05 GMT+0100 (CET) reboot detected, up 6 seconds, previously up for 0 days 15:38:59
Fri Feb 02 2018 08:53:06 GMT+0100 (CET) reboot detected, up 6 seconds, previously up for 0 days 02:58:05
Fri Feb 02 2018 11:57:06 GMT+0100 (CET) reboot detected, up 6 seconds, previously up for 0 days 03:02:01
My uptime is variable, longest since logging 15:29:06
Iām currently not at home so I cannot look at my gateway to see parts of interest.
Is the gateway with updated firmware still stable for you ?
The firmware that makes my gateway stable doesnāt exist yet I guess. The fw compiled from src and the latest beta donāt solve the rebooting.