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.
Is The Things Industries Indoor Gateway (TTIG) is a stable device? How many here have 3+ devices so that you can report back if they work stable or have issues. I have seen issues listed in this post but can’t figure out are these issues generic ones or just few devices have some problems.
If you wouldn’t recommend TTIG which gateway would you recommend for TTN?
Is The Things Industries Indoor Gateway (TTIG) is a stable device?
There have been ample reports here which seem to indicate that the combination of the gateway software and the protocol translation servers it connects to is unreliable at present. And being closed source, there’s essentially nothing you can do to improve the situation.
which gateway would you recommend for TTN?
Something where you can rebuild the system software from source, and (if it’s going where it’s at all hard to get at) where the base computer is not a Raspberry Pi and does not depend on an SD card (though if it’s going to be where you can pop in a new card if it eats itself, a pi can be an easy path to initial success). Most of the more “commercial” platforms like Multitech, TTOG, etc have their own chosen compact flash-based Linux. Overseas vendors seem to be doing good things with the Atheros and Mediatek OpenWRT router platforms - for example I have a RAK 2758 box running a built from source stack and several prototypes of a fully custom design using the same Mediatek SoC and concentrator card integrated in a way that hopefully better fits specific needs of where they will be installed, also have several of what are essentially pi gateways using an emmc-based OrangePi instead which now have nearly a year of shakedown on them to understand the rare issues. If you want to use post-UDP connectivity protocols some work combining packet forwarders supporting those with sources vendors have modified to work around SoC SPI oddities may be needed, but it all ultimately traces back to the same origins in Semtech’s version so that should be quite doable as a merge. Getting a bit far from the topic of this thread however…
1 Like
I’m still wondering if it’s possible to get the TTIG timesynced via NTP.
It is sending a time in metadata meanwhile, but does not sync via NTP.
Any ideas how to solve this?
{
"gtw_id": "eui-58a0cbfffeXXXXXX",
"timestamp": 158969515,
"time": "1970-01-01T00:00:01.575482652Z",
"channel": 0,
"rssi": -84,
"snr": 11.25
},We probably will have to wait until availability of TTN V3 before this gets solved.
TTIG uses an implementation of the new Basic Station LoRa packet forwarder.
If I remember and understand correctly:
- Basic Station will require a V3 backend.
- Time is synchronized via the LNS protocol (not NTP) by the LoRaWAN Network Server.
- For TTIG currently an intermediary system is used to make it work with TTN V2
(which likely does not support all V3 features).
This may explain why TTIG’s (reported) time is currently incorrect.
How is firmware update done with TTIG? Does this happen automatically, triggered by TTN?
In Basic Station firmware updates are handled by the Configuration and Update Server via the CUPS protocol. How exactly this will be managed and how updates will be initiated I don’t know.
My personal guess is that we may have to wait for availability of TTN V3 before TTIG firmware can be remotely updated (but I may be wrong).
For more information see Basic Station Docs
1 Like
A post was split to a new topic: Does TTN Mapper show gateways when it only received “experimental” data?
What is the status regarding the time element in the received gateway data?
Is it considered as bug which will get fixed - if yes till when?
BTW: Is there something like a roadmap what will happen software wise in the TTIG?
{
"gtw_id": "eui-XXX",
"timestamp": 3076547067,
"time": "1970-01-01T00:00:01.576063743Z",
"channel": 0,
"rssi": -36,
"snr": 10.25
}Same question here, any status on the time field issue? Or when a TTIG get’s next firmware update?
Curious: why is that gateway wall time so important to some of you? I don’t think one can expect a great accuracy anyway? (Even if it would use NTP every hour or so, I doubt it’s useful for, e.g. triangulation?)
Did you truly use the USB connector (rather than soldering something to the UART connector)? If yes: how?
According TTIG : The Things Indoor Gateway I’ve placed a 470 Ohm SMD Resistor on the spare R86 position … this enables the (initially disabled) CP2102 and you get Debug Output on the USB Interface, it’s an alternative to using a RS232 / USB Bridge.
4 Likes
@bei: " A wild guess at the root cause" … there was an error in the parameters of my Arduino node. It violated the “fair use policy”, sending a packet every 14 secs. I’ve corrected this mistake … and voila … connection resets gracefully in case of power or wlan loss. It’s ok for now, but theres potential for Denial of service attack to TTIGs.
Sorry, forget my last post … after forwarding my Arduino Temp Sensor without problems for the whole weekend my TTIG hangs again …
… seems not the same issue as mentioned above, after 23 Minutes it begins forwarding packets again. The hang seems not persistent as it was in the past.
I’m sorry, but for my environment the TTIG isn’t a reliable solution, what’s about the LG308 ? Maybe the better solution ?
Curious: why is that gateway wall time so important to some of you?
Missing data is one thing, but _wrong_data should be fixed. I don’t like a product which sends wrong data to my backend. I can’t fix it by myself, I have to wait till TTN fixes the product they sold. Up to now I found no resources explaining what will be fixed when. That’s some kind of after sales support I expect when I buy a product.
Last time I checked TTN didn’t sell any gateways. RS Components and several dealers do sell gateways. Your supplier should be the first port of call when something does not work as described.
However TTNs name is associated with the product, so some improvements or comments would be useful. @wienkegiezeman?
OK, that’s not so easy for a beginner. The TTIG is not provided by The Things Network (TTN). Got it. It is advertised by “The Things Industries” and offered on “The Things Industries” homepage as product, (distributed via RS-Components). Now I’m wondering, if this is not the right form for the TTIG, where can I file an issue for The Things Industries …
After running my TTIG now for some time without greater problems, I think @bei’s wild guess in his post on Sept 3rd is right. Since I’ve corrected the sending interval in my Arduino Node my TTIG forwards all my sensors flawlessly. A break in my WiFi Connection or a Power Fail isn’t a problem anymore.