Same here: still no valid time on my TTIG (firmware 2.0.0) 
The invalide time is a known issue.
1 Like
Is there any fixing ongoing, ETA known?
Hi,
i want to use TTIG with TTN Mapper. But the Gateway did not send the correct location Data.
@RainerWieland shows:
Try “wget http://noc.thethingsnetwork.org:8085/api/v2/gateways/<THE-EUI_FROM_TTIG>” on your linux-console like
wget http://noc.thethingsnetwork.org:8085/api/v2/gateways/eui-58a0cbfffe8020ca
You resolve in json:
<==snip==>
{
“timestamp”:“2019-09-04T20:49:49.809608067Z”,
“uplink”:“536”,
“location”:
{
},
“frequency_plan”:“EU_863_870”,
“gps”:
{
},
“time”:“1567630189809608067”,
“rx_ok”:536
}
<==snap==>
So i think all TTIG send to the ttn server the same position information.
I think the problem is, in the local_conf.json of TTIG the settings are false.
The thread from @jpmeijers https://www.thethingsnetwork.org/forum/t/gateway-gps-configuration-in-local-conf-json/6176 it show the right configuration:
if the settings:
“gps”:true
“fake_gps”:true
the gateway and ttn server use the location set in ttn console.
Is there a way to fake or fix this data without changing the ttig firmware?
So we must not wait until the ttn guy fix the firmware bug 
The TTIG uses totally different software. The configuration you show is for ‘packet_forwarder’, not for ‘basic station’ which TTIG uses. On the TTIG there is no such thing as local_conf.json.
For devices like TTIG that do not have local GPS the TTN back-end should add the location data as set in the TTN console. In the application packets such added locations can be recognized by looking for “location_source”:“registry” in the meta data of the gateway.
Perhaps @KrishnaIyerEaswaran2 can explain why the location data is not added on TTIGs that have been setup recently.
5 Likes
Hi, i’m also a frustrated user of a TTIG …
same issues as described in Post #1 by Kalle
GW bought from german RS Components some days ago
After complaining there they sent me a second GW
same behaviour as the first one …
I’ll post more infos after activating the Debug Port …
Would be great to have a roadmap on issues / errors and fixing progress.
Would be even greater if everyone could contribute to this process.
Why do you think I referenced a TTN core member in the message?
1 Like
Hi Guys, i’ve managed to activate the USB Debug Port, here some lines of normal Debug Output:
2019-09-08 09:44:05.891 [SYN:INFO] Time sync qualities: min=1049 q90=1070 max=1079 (previous q90=1071)
2019-09-08 09:44:06.684 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:07.688 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:07.997 [SYN:VERB] Time sync rejected: quality=1079 threshold=1070
2019-09-08 09:44:08.692 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:09.696 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:10.700 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:11.705 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:12.708 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:13.712 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:14.716 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:15.723 [S2E:VERB] RX 867.1MHz DR5 SF7/BW125 snr=9.5 rssi=-31 xtime=0xFA00033E3CA40B - updf mhdr=40 DevAddr=26011CB2 FCtrl=80 FCnt=28611 FOpts=[] 0199235D mic=-1920876201 (16 bytes)
2019-09-08 09:44:15.734 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:16.740 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:17.744 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:18.748 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:19.752 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:20.755 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:21.759 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:22.763 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:23.767 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:24.771 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:25.774 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:26.778 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:27.782 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:28.786 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:29.790 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4…
and then a failure:
2019-09-08 09:44:29.790 [SYS:DEBU] Free Heap: 18872 (min=17072) wifi=5 mh=7 cups=8 tc=4
9-09-08 09:44:34.809 [SYS:DEBU] Free Heap: 17272 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:35.813 [SYS:DEBU] Free Heap: 17272 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:36.817 [SYS:DEBU] Free Heap: 17272 (min=17072) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:37.821 [SYS:DEBU] Free Heap: 17272 (min=17072) wifi=5 mh=7 cups=8 tc=4
bcn_timout,ap_probe_send_start
2019-09-08 09:44:38.824 [SYS:DEBU] Free Heap: 17272 (min=16680) wifi=5 mh=7 cups=8 tc=4
2019-09-08 09:44:39.828 [SYS:DEBU] Free Heap: 17272 (min=16680) wifi=5 mh=7 cups=8 tc=4
ap_probe_send_over, rest wifi status to disassoc
state: 5 -> 0 (1)
rm 0
pm close 7 0 0/1080320871
2019-09-08 09:44:40.832 [SYS:DEBU] Free Heap: 18320 (min=16680) wifi=4 mh=7 cups=8 tc=4
reconnect
scandone
no FRITZ!Box 7590 AC found, reconnect after 1s
reconnect
2019-09-08 09:44:41.835 [SYS:DEBU] Free Heap: 18320 (min=16680) wifi=1 mh=7 cups=8 tc=4
2019-09-08 09:44:42.004 [SYS:INFO] Restarting
scandone
del if0
usl
sul 0 0… and a reboot
ets Jan 8 2013,rst cause:1, boot mode:(3,7)
load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8
2nd boot version : 1.6
SPI Speed : 80MHz
SPI Mode : QIO
SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000
~r��b�����b��blb���b|r�l��lb��n��nn����l��lll�����l`�n������bll�r�b����bl�b�lrl����n��r��n|�llll`�mode : sta(2c:f4:32:50:bf:bb)
add if0
1970-01-01 00:00:02.150 [SYS:INFO] FSCK found section marker A0
1970-01-01 00:00:02.162 [SYS:INFO] FSCK section A: 83 records, 12164 bytes used, 1011836 bytes free
1970-01-01 00:00:02.632 [SYS:INFO] FSCK section A followed by erased flash - all clear.
1970-01-01 00:00:02.643 [any:INFO] HW pipe bound with fd=0
1970-01-01 00:00:02.645 [any:INFO] AIO registered for HW pipe &aio=0x3ffeea30
1970-01-01 00:00:00.006 [SYS:DEBU] ======= VER ======
1970-01-01 00:00:00.008 [SYS:DEBU] Station Version 2.0.0(minihub/debug)
1970-01-01 00:00:00.010 [SYS:DEBU] Version Commit e17c5af
1970-01-01 00:00:00.014 [SYS:DEBU] Station Build 2018-12-06 09:30:37
1970-01-01 00:00:00.020 [SYS:DEBU] Firmware Version 2.0.0
1970-01-01 00:00:00.025 [SYS:DEBU] FW Flavor ID semtech0
1970-01-01 00:00:00.031 [SYS:DEBU] Model minihub
1970-01-01 00:00:00.041 [SYS:DEBU] ======= SYS ======
1970-01-01 00:00:00.042 [SYS:DEBU] CPU Freq 80 / 80000000 / 80000000
1970-01-01 00:00:00.048 [SYS:DEBU] Random Number -1915626743
1970-01-01 00:00:00.053 [SYS:DEBU] Reset cause 4
1970-01-01 00:00:00.058 [SYS:DEBU] Booting USER_BIN 1
1970-01-01 00:00:00.063 [SYS:DEBU] FW start addr 0x00001000
1970-01-01 00:00:00.069 [SYS:DEBU] SDK version 2.0-dev(9ec59b5)
1970-01-01 00:00:00.075 [SYS:DEBU] Free Heap Startup 56160 bytes
1970-01-01 00:00:00.081 [SYS:DEBU] ======= MFG ======
1970-01-01 00:00:00.086 [SYS:DEBU] SN TBMH100868003850
1970-01-01 00:00:00.092 [SYS:DEBU] MTIME 2019-07-16 06:53:48
1970-01-01 00:00:00.101 [SYS:DEBU] PERSO_HASH 0xfcd3e0c8
1970-01-01 00:00:00.104 [SYS:DEBU] AP_PW MEw6pHTD
1 Like
From LoRaWAN perspective neither the time nor the gps data of the gateway is critical. Your nodes can send and receive data using the gateway without issues while these bugs are present.
The power-up issue can have more impact as this requires manual intervention, however this looks like it could be an issue with TTIG in combination with certain Wi-Fi access points. (I do not observe this issue with Ubiquiti APs)
Not having gateway GPS data does impact TTNmapper, that is inconvenient if your primary use case would be mapping the gateway, however that is of course not a real use case.
The Attached Reboot contains Firmware Version and Build Date, maybe it’s useful for someone
The issue happens on a FritzBox 7590 and also on a Cisco 25315 …
I’ll use a WRT54G but this will last a while because i have to reactivate this old thing with OpenWRT or ddWRT
Sorry, I’ll read the formatting guidelines and will use them in the future…
Don’t know if my findings are interesting enough for the community …
maybe it’s only a problem of my WLAN environment and i have to use another GW
But My RasPi 1ch GW and the rest of my WLAN is working without any problems
@kersing: As you mentioned time and gps issue aren’t a problem. The only critical thing is the power up issue Imho. I’ll verify that with that old WRT54GL and in the future with a mobile hotspot, i have to buy.
After verifying the formatted posts above … there’s a lost line between the first two lines of the second log, here’s the original line:
2019-09-08 09:44:30.300 [S2E:VERB] RX 867.3MHz DR5 SF7/BW125 snr=9.8 rssi=-33 xtime=0xFA00033F1AF0FB - updf mhdr=40 DevAddr=26011CB2 FCtrl=80 FCnt=28612 FOpts=[] 018C458F mic=1566300477 (16 bytes)
Before receiving this packet the free heap reduces from 18872 to 17272.
Something strange happened here
Could you boot the gateway and leave it in error mode for 30 minutes to see if it recovers by itself?
ok, I’ll boot the gateway again and leave it in the failure state fo min 30 min. I’ll report it
I’ve done that some times in the past, but the GW didn’t recover
only pressing setup 10 sec, waiting some secs until blinking slowly red and then pressing setup for 5 sec did recover it
@kersing: TTN Console reports: Last Seen 35 minutes ago for this GW
it didn’t recover …
I’ll compare the bootlogs for a “good” boot with GW alive and a “bad” boot with GW not forwarding any packets …
2 Likes