Thanks for the updates… As someone anticipating getting a shipping notice some day soon, I’m eager to know solutions for the type of problem you’re encountering and hope that the core team will be in touch with you shortly to attempt a solution, if that hasn’t commenced already. Will be grateful to know details if and when a solution is found.
1 Like
My gateway did the exactly the same thing.
I then connected my sparkfun basic breakout module to read the debugging output from the uart. In the output I found that the reboot occurred when the gateway was reconfiguring the lora-card.
Then Marten wrote:
In my case applying some force was the solution, in your case the loraboard might be bad.
I would try to readout the uart debugging and determine at what step the device reboots, that does greatly improve pinpointing the cause of the problem. (see description in faq). If you need help doing this, let me know.
2 Likes
thanks @Leondegeling, all debugging tools available here. judging from the bend the radioboard needs in order to be lifted from the studs, it might very well be hairline fractures caused by the assembly process. Considering the cost, its going for RMA, and i’m rethinking other solutions.
Hi @wienkegiezeman,
I have the same problem with not possible to activate. WIFI connection seems ok. But third LED is slowly blinking then stops and after 1-2 sec it reboots.
I hope there are other options I can try out.
Thanks!
Perry
Another hint not mentioned before, when i managed to load the /info url in the browser, i only once saw it displayed at : “Gateway Card:”. The rest of the time it showed “Gateway card: ND”. So i guess the communication with the card is not what it should be. Also seen @PerryVanDerMeeren.
One positive observation on TTN Gateway: It does only forward ttn packets. On my multitech conduit forwarder there are forwarded any packets where less than 10% are addressed to ttn. Will check how filtering is possible at multitech forwarder.
the TTN gateway drops the non TTN packets ?? that’s new info… so how you think roaming will work in the near future @kersing
1 Like
Roaming can be a good thing. But i have no interest to let some commercial networks use my resources. In my region there are more commercial nodes and gateways than TTN.
Strange that must be a firmware update because mine (tested last week) forwards all traffic. (Currently off-line while I focus on other things)
Neither MP forwarder, polyforwarder nor the multitech provided software provide filtering options.
BTW TTN also explicitly stated Filtering should not be done at gateway level.
According to @htdvisser gateway owners will be able to configure if they want to allow their gateways to participate in roaming. So no need to worry.
Made a test over several minutes (not so busy when i need it) and see still foreign networks but only on Multitech.
Multitech:
TTN-Gateway: 
Seems like the “filtering” is on SF7 rather than on DevAddr… (And that would be a problem.)
There has been no firmware update for The Things Gateway. The current version is from 917719b9 at Jun 26 2017 and there is no logic in there to filter traffic, neither on DevAddr, nor on SF or BW.
Could you inspect the RSSI and SNR values of the messages received by the Multitech vs TTGw?
2 Likes
Hi,
I’m trying to activate a TTN Gateway but it never activates. I’ve tried connecting via wifi and via ethernet. It seems like it might be rebooting periodically. It cycles from 1.5 LEDs to 2.5 LEDS then briefly to 3 LEDs before all 4 LEDs flash and it starts the cycle over.
Any advice would be greatly appreciated.
Right now the /info page is giving me the following:
Network
Uptime: 26
Connected: true
Interface: Ethernet
Wifi SSID: Things-Gateway-001EC03AF409
Configuration
Activation locked: true
Config correct: true
Region: US_902_928
Gateway Card: ND
Packet forwarding
Broker connection: false
Packets up: 0
Packets down: 0
Thank you
Definitely rebooting - I’m getting the following from the UART:
CNFG: Configuring LoRa module
LORA: Changing state from 2 to 4
LORA: Starting reconfiguration
LORA: version: 02
LORA: Configuration failed, retry
LORA: Starting reconfiguration
MON: SYS Stack size: 2873
MON: heap usage: 152KB (234KB), free: 187KB
LORA: version: 00
LORA: Configuration failed, retry
LORA: Starting reconfiguration
LORA: version: 00
LORA: Configuration failed, retry
LORA: RESET MODULE
LORA: Changing staSNTP: State change from 0 to 0
SNTP: State change from 0 to 0
**************************
* 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
BOOT: (persisted info) 6F 72 72 65 01 03 5C 02 DC 8A F4 01 D1 5C C1 20
It continues to loop through this process always with a reboot reason 0x13. Does anyone know where I might be able to look at the errors codes?
1 Like
If you haven’t had a chance yet, take a look at December postings in “The Gateway central” thread, particularly the exchanges involving Leondegeling_ and ttnkasteel6d
https://www.thethingsnetwork.org/forum/t/ttn-gateway-central/10976/7?u=sronan
If I understand all that correctly, your Microchip LoRaWAN board is likely not fully and properly attached and communicating (hence the “Gateway Card: ND”)… If that’s indeed the case it would be good to get advice from someone with more expertise than I can offer in respect to whether/how you should try to adjust/fix that.
2 Likes
like hdtvisser stated… 'check RSSI and SNR, probably one gateway with an outdoor antenna compared to the indoor TTN gateway, that would explain the SF 7.
hope @bsiege can elaborate on his findings.
Now i placed both gateways with similar antenna (original). I see that the radio reception is slightly better with multitech, but now i have more packets from foreign nodes on TTN-GW too. The filtering seems to be a false assumption on my side. But the thematic is the same. I do not want to forward commercial networks over my internet access. Since they have already 100% coverage here. Best would be if we could do a granular setting for denying/allowing different networks. If not possible at least a switch for “TTN-only”.
1 Like
filtering is always done in the backend and not in the gateways.
So there is no way to prevent a packet ‘travelling’ through your internet access.
Commercial networks will receive your packets too and drop them in their backends.
May be technically correct. But i think i support a free network and nothing else. I am not interested on wasting ressources only to be dropped in some server far away. It is another thing when there are real peering/roaming agreements with third parties. Are there any yet? It is not only about uplink, there will also be a downlink. And even then: In a free network there should be only opt-in for such functions.
then lorawan is probably not the platform for you … 
1 Like