What is the time between removing the power and reapplying it when it fails? Seconds/minutes/hours?
I am asking because I’ve got 7 TTIGs and never experienced this issue (yet).
The first time it was minutes without power. The following tests were just seconds, sometimes minutes without power. The TTIG always seems to boot normally and then get stuck with solid green LED. But is is responsive to the setup button. I don’t know if the setup button triggers a interrupt routine (this would explain why the button works, while the main routine seems to hang) or the button status is polled, that would mean that the loop is running. Or it is a timer interrupt which polls the button pin?
Perhaps there is a file or flag which was not set correctly during a recent power loss. And this flag or file never seems to be resetted, even after a reset button reset. This is one scenario how this could happen.Without the source code, it’s not possible to explain.
I will try to get the serial debug output, maybe it helps
Perhaps I am the lucky guy with a defective batch of TTIG hardware and this power loss behaviour is no firmware issue. But it is a repeatable problem. I will not install this TTIGs in places which are hard to reach, because a power loss will need to reboot by setup/end setup button.
There are really two classes of issue here.
One is that any little embedded product, especially one with wifi, is going to have both initial challenges in dealing with situations the developers didn’t anticipate, and ongoing challenges in dealing with the nature of the technology itself. It’s not unheard of, for example, for something to join a wifi network, get a few packets through, fall off the network, and take a while to re-associate. And that goes even for premium hardware from a company with a stylized piece of fruit on it.
The other problem is that closed firmware just isn’t viable in a community network, as it means there’s neither visibility to understand the causes of issues nor self-reliant repairability of bugs nor customizability
My take is these will become practical when and only when open firmware becomes available - most likely a third party firmware from someone frustrated enough to create it. (Given the reliance on wifi for backhaul, the box would not suit the projects I’m currently involved in, so I’m not going to buy one just to do that - but sooner or later someone probably will)
2 Likes
I made esp8266 and ESP32 software, and in the beginning i had this type of wifi problems. You must have a timeout in the connect routine, but most demos do not have one. It’s only a “while not connected, do try to connect” loop. If you get stuck there, this loop will never end. When esp wifi is caught in a strange mode you must disable/enable wifi and try again. If this also fails, then reboot. This way I never got wifi stuck again.
Maybe a timeout is missing in the TTIG wifi connect code?
I do not know in what differs my TTIG, however it is placed under the roof , sometimes in my house there is some power loss but I never needed to reset. And it shows coordinates.
This is very interesting. Can you check your firmware/core/hardware versions/ manufacturing date please?
You have to go to the roof to bring it into setup mode to see the data 
indeed, what yours, from the problem device(s) ?
My TTIG has
FW Build 2018-12-06 09:30:37
FW version 2.0.0
Core version 2.0.0 (minihub/debug).
Manufacturing date is about 2019-07, I can check this later, I am not at the place right now
ah, I forgot the screenshot I made… sorry
MFG date 2019-07-30 04:35:29
Serial number begins with TBMH100.
The other TTIGs data I do not have right now
On my indoor gateway i can see every around 55 Seconds the green LED begins to flash rapidly for around 10 seconds and comes solid for another 55 Seconds. This will repeat endlessly.
*** just to remind you - BoRRoZ 
**
Hi Guys,
We had a couple of issues last week regarding gateways.
-
UDP Gateways: It’s not as simple as someone mentioned here. UDP Load balancing is actually quite difficult. The number of gateways was so high that our server ran out of socket connections and we had to update kernel settings. As a matter of fact, debugging UDP traffic is way more difficult than any TCP based traffic.
-
Basic Station: The above-mentioned issue with the machine caused our bridge to break and required a little bit of work before coming online again.
We’re always looking to improve the experience with gateways which is one of the most vital bottlenecks of the LoRaWAN ecosystem. Over the course of the next couple of weeks, we’ll be replacing our temporary bridge with a high performant native bridge, which is tested to be more stable.
And so, I’d like to streamline discussions on TTIGs so that new comers can easily navigate this.
Here’s how I propose to do it:
- TTIG not connected: Check StatusPage(https://status.thethings.network/), Slack (Support/Ops) and report it there (if not already reported).
- Check the docs for Gateway Info (https://www.thethingsnetwork.org/docs/gateways/thethingsindoor/), a new FAQ section will be added soon.
- Performance related issues; report here TTIG Performance Discussion
I’m going to close this thread since it has almost 500 comments on a range of different topics.
Regards,
Krishna
PS: I saw that some of you are experiencing issues, I’ll try my best to check it but I can’t guarantee I can since it’s Sunday.
4 Likes
Showing my user data with the url above, the location is fine.
Unfortunately TTNMapper uses api data and there location is empty. Therefore I cannot contribute to the coverage map.
Ralf.
This behavior has been previously explained as expected. If the TTIG is not receiving any edge node transmissions, it resets its connection to the network.
Is there any solution for the TTIG gps coordinates problem ?
My TTIG has correct gps data in console and api
but not in noc and payload data
The coordinates have been set days ago
I need the data so that the gateway is displayed correctly in the ttnmapper.
please help
This and other errors were the reason for me to start this thread, see above.
I think we Users can do nothing but wait. This problems can only be solved by the TTIG and TTN server admins.
Thx @Kalle,
astonishingly there are some TTIG in the field which provide coordinates
Then we have to wait
Yes, some TTIGs seems to send location data. I don’t know one, I wonder what the differences are.
Do you know a TTIG admin with working location?