TTIG Problems, - no location data, wrong date/time, wrong channel and stability issues

This is why I did not answer yet :wink: . It needs some time, however I will do it soon.
However, I see there is definitely a batch of TTIGs with problems. Mine was one of the first, although not taken at the conference.

By the way, for me the NOC provides coordinates, metadata in packets do not.

I don’t see any problem on the TTIG side. Dropping the connection uncleanly and re-establishing it shortly thereafter is not an uncommon case in networking which the server should be able to handle gracefully.

@bei: full ack, server should be able to handle this …
I’m only in doubt, if there’s a need to reboot the hole gateway 1 sec after WLAN is lost …
is this behavior normal ?

Both events, a short powerl loss and also a short WLAN loss may occur sometimes in real life …
But those two events aren’t handled correct either by server or by gateway … thats my problem

Can’t find a workaround

Hi Guys,

i just installed my brand new TTIG and have problems with letting my Testdevice Join.

If placed in a location that only the TTIG can receive it, it doesnt Join, even if i can see in the console all the Join Requests and also the Accept answers.

Than i placed the device on a different location where it could be heard from other gateways and it could join there.
The only diference i can see that Date on my gateway is 1970… Could this be the reason for not able to Join?

(Before i came to this 1970 problem i created this post (sorry)

Thanks for help

TTN Mapper has been updated to use the gateway-data API and not the noc API. Things Indoor Gateways should therefore start to appear on TTN Mapper.


joining works flawlessly on my TTIG
I’ve joined a PAX-Counter without any problems

Yeah, very good quickfix solution :slight_smile:

@bei: if there’s no problem on the TTIG side, will the problem be fixed on server side in the future ?
Else I think of the following workaround: I’ll build a little ATTiny14 or something else into the TTIG, which listens to the Debug output. If it discovers a Reboot of the TTIG it will switch off the WLAN AP for about 10 seconds, so that the first reconnect fails … the second reconnect will then succeed and all is fine. Thats what i’ve tested manually. In german one would say: “Von hinten durch die Brust ins Auge … aber funktioniert”


Thanks for the fix, my TTIG showed up on just now (although it is still marked offline despite being online, but alt least it’s visible at all).
Edit; switched to online just now, so ttnmapper seems fine now.


My problem with “Joining” solved: i needed to set ATS220=3 on my Adeunis Tester.
(extend RX Windows Timing for Testhouse certification).

Now everything works fine with the TTIG (also can not see regulary reboots etc)


1 Like

I’d also like to know this.

This is why we’ve chosen to ‘wait’ and/or use something a bit more ‘robust’ like Laird Sentrius for indoor commercial applications…
There, I couldn’t read :smiley:

We asked them (TTI) why Ethernet was NOT an option for this little very nicely priced IG, we haven’t got an answer. Relying solely on WiFi as backhaul especially on the 2.4GHz very crowded RF space and all that WiFi’s unpredictability entails, IOHO, is not very wise, and it starting to show. I think the reasoning here, much like Semtech is doing with their new ‘kit’, is to follow the ‘in a Box’ biz model. We don’t think, again IOHO, that’s a very wise move. Add that to the ‘bugs’ everyone’s referring here, and well you get this long thread. Our Laird Sentrius are definitely more expensive, 2-3 times the price, but they work (ironically) right out of the ‘box’ the 1st time and no problems thereafter…

1 Like

Apart from TTIG bashing, what is your point?

The TTIG does not support wired ethernet because it is based on a cheap chipset that does WiFi. The hardware was designed some time ago for a different product and with new software re-released as TTIG at a very competitive price point. Redesign and re-certification (CE/FCC etc) would increase the price and add little (imho).


I find that insulting - who’s bashing anyone here? It is a valid, professional point that, bashing or not, is still pressing and very much relevant. As such, if it’s already giving so much headache, how can that be considered ‘competitive’? Sounds more like ‘rushed’ or ‘cheap’, which is very un-TTI-esque. We are very appreciative of TTN/TTI, extremely supportive and collaborative, so if you or anyone consider the sound based criticism as ‘bashing’ then maybe that’s something you need to work with - not us. :red_circle:


Ok, I should not have called it ‘bashing’, my appologies.

I think you could make your point differently. Posting a huge screenshot of a tweet where you could just as easily have posted a link to twitter and provided some context in the message does set the tone. Stating you prefer wired connections, which as we all know TTIG does not support and compare it with a product which is 2-3 times the price (and had issues with the first firmware release as well (frequent packet forwarder failures)) is not particulary helpfull for people with issues with TTIG. The Sentrius gateways have been availble for over two years so if anyone considered it an option they would have bought one and not waited for the hard to obtain TTIG. (And with the newer firmware I would certainly recommend the Sentrius gateways!)

With regards to the stability of TTIG, may-be it does need some time to mature? Brand new packet forwarder, not supported by the back-end (yet) and as a result needing a protocol bridge that does not scale well is not an advertisement for a mature product. Let’s face it, releasing a gateway that is not finished is very TTI-esque. Ask many backers of the original TTN gateway or read the messages on the forum regarding the problems people are (still) having.

TTI does a decent job providing the community back-end, however I’ve talked to several commercial customers that shy away from TTN lately because of the stability issues and outages. A year ago the back-end was a lot more stable. Once people start looking for alternatives the community looses gateways and coverage.


FW 2.0.0, build 2018-12-06. So I suppose the same. However, for some reason it runs. I do not know if different batches of gateways are assigned to different servers in the backend…

FW 2.0.0, build 2018-12-06.
Nothing changed until today …
short Power outage or short wifi outage terminates lora communication
as described in this thread by Kalle, me and others

will there be a fix in the near future ?

TTN shows continuous growing.