TTIG already uplinks periodic messages, however these go to an intermediate process that handles connections for TTIG to the V2 stack as V2 does not support the protocol used by TTIG.
As I mentioned before on another topic, upon uplink the connection is re established automatically so there is nothing you need to do. Granted it would be nicer to have the connection status reported correctly.
You can of course install a node that uplinks a few times each hour to make sure the status stays green…
I found that it takes a significant time to establish the connection. As i approach the gateway I get within 2km before it starts relaying, but when driving away heard upto 14km away.
The annoying thing is when the gateway is “not connected” it gets removed from TTNmapper
Surely this is an easy fix for TTIG… every other gateway I use reflects correct status.
Can you expand on this - it sounds like a more complicated setup than just a TTIG going quiet on the dashboard - what’s up with the driving?
No one product, particularly at this price point, can satisfy all needs. There may well be a very good reason TTI chose to let this happen. The lowest cost solution is to get a small device a few meters away to uplink every 15 minutes.
Can you also expand on your test method - are you testing at a distance from fixed locations or moving (Driving?). If a long way from GW and Node cant get through it will try gradually higher SF’s, esp if previously connected when close to the GW, depending on device and code/library.
If running at SF11 or SF12 it likely wont connect straight away as IIRC there is a rule to stop nodes joining straight off at high SF’s. Also at higher SF’s the on air time is significant. E.g. a basic GPS tracker may be on air for 1.2-1.8sec at SF12 and during that time if moving there is a good chance you may find signal is lost behind terrain masking issues, buiding clutter etc. esecially if moving laterally (normal to LOS) wrt GW position) Also if moving at any speed you should also be aware of the concept of Signal Coherency (also called out in other forum threads) whereby the ability to hold lock on a signal deteriorates with increasing speed and increasing SF. Again IIRC SF7 is good for connections to >160-180kmph, whilst SF12 may struggle at <45kmph poss as low as 25kmph. (Especially if moving normal to the GW - i.e along direct line of sight). That is not to say signal wont get through just there there is increased chance of symbol/packet loss leading to failed MIC/CRC checks and hence rejected packets leading to loss of connection, depending on specific node & GW build standards and tolerances, use of TCxO’s etc. As you get closer the prospect for connection improves and that is what you may be seeing 
If doing wide area coverage checks whilst moving (war driving) I slow down and stop occasionally to check SC isnt causing a problem, especially at sites of specific coverage interest, and reducing coverage results just in case 
Your device does not connect to a gateway but to the LoRaWAN network. If you are using OTAA you might run into issues where the device needs to be close to the gateway to have it receive the join request and for the device to receive the join accept packet transmitted by the gateway. In this handshake packet loss in any direction will make it fail while for war driving some packet loss is expected and acceptable.
Have you tried starting close to the gateway where it works, increasing the distance to 12km and driving back (possible other route back) to see if that makes a difference?
The TTIG is installed at a commsite I manage, on a hill in a small regional town, 70km from my home. I have 10x OTAA GPS nodes of various manufacturers installed in my vehicle.
(All nodes previously OTAA’d and TXing to other gateways in my home town as I drive away, destined for TTIG town)
- When driving into TTIG town, I get within 2km of the gateway before its portal status changes to “connected” and it starts relaying nodes packets
- When driving around town, nodes packets are relayed as expected. Gateway-Node distance 0-7km
- When driving away from town (via same route as step1) gateway continues to relay traffic out to around 14km (the point when mountains obstruct the RF path)
The lowest cost solution is for the faulty TTIG firmware to be fixed and correctly report its status.
Not for TTI, as we don’t have hordes of people on here asking for this feature to be fixed - so the lowest cost solution is for you to put a node 20m away from it as the time taken to try to get TTI to change the firmware is likely to far exceed the cost of a small device.
Or get a gateway that doesn’t have this feature.
As frustrating as it is, the TTIG works when devices are present around it. Given its price point and the extra server load that it comes with, it’s not unsurprising that it takes the load off the central infrastructure if it’s not being used. But I totally concede it should wake up a bit quicker.
My AU915 TTIG has been connected all day today, without any active uplinks.
Seems that TTI have implemented the “stats” message as was suggested above… The gateway “last seen” timer is now always under 60sec whenever the gateway is online and connected, regardless of whether there is node traffic or not.
I should have kept my mouth shut… as shortly after I made the above post it reverted to the original behaviour. Then after an hour it went back to disconnected.
I very much doubt they even saw the message and if they did, it’s clear from past rollouts of firmware updates that it’s not something they do on a short timescale without a public beta test cycle, as seen on a recent update.
It’s more likely you’ve been hit by the global TTIG downtime, if you look at other recent forum entries.
We never really got to the bottom of why you drive around hoping your TTIG will connect sooner as you drive towards it …
Hey, I just saw this thread;
There are three related items here
a. Gateway connecting to the backend and forwarding messages.
b. The network reliably knowing that the gateway is connected.
b. The green button the console indicating that the gateway is connected.
- Item a: There should be no issues with item a. We had a recent issue in the EU region and that has been sorted. Your gateway will forward packets when it receives it, if there’s internet connectivity.
- Item b: The “standard” method of knowing whether a gateway is connected or not is by using status messages. This is usually sent every 30s by the gateway. The LoRa Basic Station protocol does not support this message. So the only way to reliably know if a gateway is connected is when it forwards traffic. Also it’s not trivial to use the TCP connection state as a source for “connectivity”. There are possibilities of stale connections (which is what occurred in the incident yesterday) where the gateway is “connected” on the TCP layer but the Packet Forwarder does not know there’s an issue and does not disconnect. So once again, unless there’s an outage, your gateway will forward traffic when it receives it if the internet connectivity works. The backend will detect connectivity based on this.
- Item c: This item has been discussed numerous times on Slack/Forum. We have issues in our NOC (the component responsible for aggregating and forwarding connectivity information). This would require a rewrite of this entire component and related services. Since we are going to migrate the entire community network to V3, we decided not to fix this bug. So the green dot on your console is flaky and may not reflect the actual state of connectivity.
Regards,
Krishna
1 Like
@KrishnaIyerEaswaran2, thanks for emphasising this - we are still not clear what the OP is hoping for by driving at his TTIG with 10 GPS enabled LoRaWAN devices when it was originally reported as being a local devices not connected issue.
1 Like
@descartes I gave a practical example of the fault I’m experiencing and a practical solution. I have 10x GPS units of various manufacture as am evaluating the best allround node performance. I noticed that the TTIG was slow to wake up when driving towards it, however worked as expected when driving away… simples… Whats the point to your reply?
Do you have any practical experience with AU915 reg domain, the au specific meshed tti/ttn portal and specifically the AU915 TTIG?
< redacted by moderator >
Are you part of TTI? Or just a forum regular?
Saving TTI staff members spending time on an issue that hasn’t been defined. On the 3rd Dec you were asked by two of us to help us understand what the driving element was about in relation to TTIG not showing connected in the console, with a suggestion from another forumite. Reply there was none.
We now understand from this post that you are looking to evaluate 10 GPS enabled LoRaWAN devices which was being held up by the TTIG going quiet until you got close to it.
Given the internal antenna and target use of being an indoor gateway, I’d suggest this is not an appropriate unit for this sort of evaluation, even if you have altered it with an external antenna, regardless of where in the world it may be.
1 Like
Wdym? Id say that nowiresfil gave some very good real world examples (actually probably the only real world examples) out of all the 200 odd posts and replies on the issue with this gw 
Anyway glad I didn’t end up buying one to evaluate. I guess the v3 fix cant come soon enough for the people suffering with this.
Once I’d figured out what the main issues was, it appears not to be a very good use case for the TTIG which was designed for in-building reception. So whilst the “not connected” for all gateways is an issue with the v2 stack, if you want a gateway for general use, the TTIG is perhaps not the one you are looking for.
If it doesn’t work on top of hill for reception in the above examples id definitely suggest the end users stick to 2.4ghz wifi for any indoor communication requirements then 
I have plenty of gw’s though thanks for your concern. I do buy many products also to test and evaluate as i stated above. This one had my interest but glad i managed to miss it so far.
It should not matter why, nor should someone be chastised for ensuring the best node is bought for the purpose they intend. It is narrow minded to assume you are in control of who or what is relaying your packets. If the TTIG is indeed a poor product for the reasons @nowiresfil is having issues, then it stands to reason it is a incredibly poorly engineered product. Which will only make TTN/I integration here in Australia more of a challenge.
People from other parts of the world need to understand, Australia is different with different requirements. Not only has TTN/I fragmented our spectrum by supporting and advocating two Different frequency plans, but they release and don’t adequately support their own hardware. And also the meshed deployment here is crippled. It has its own configuration pages for instance. And it appears to drop packets of ‘busy’ nodes.
All the gateways meshed have deployed for DPI where the tender docs say for community use, don’t actually appear to work at all. Liverpool council doesn’t work for the community either.
Australia is a place with vast distances between regional centres, I know I’d be trying to squeeze all the performance out of an indoor gateway so a tracker can complete a join as soon as possible. So as to begin tracking. And I also know most hobbyists here would rather spend $100 on their own indoor deployment.
I don’t know why the TTN forums seem to be another place of alienation. It would be nice if there was some sort of constructive discussion. Instead of suspending accounts because a unqualified mod wants to “save the TTI guys time”. If you didn’t design or build the product how do you hope to even be able to contribute. It’s a bit like performing brain surgery blindfolded. Just because your a mod, doesn’t mean your the right guy to chime in on an issue.
If Things network doesn’t put some time into resolving their Australia issues, iot in Australia will be out of reach of the hobbyists and be 100% commercial controlled. Here we have one telco with awesome coverage, and two others with marginal. If you are ~100km away from a metro area. You don’t really have a choice.
It would be pretty crap to only have one choice, which was inflexible and cost a bomb…