TTIG "not connected"

Gateways TTIG - The Things Indoor Gateway
206

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.

207

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.

208

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.

209

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 …

210

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
211

A post was merged into an existing topic: The things network indoor gateway Not connecting to LNS

212

@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
213

@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?

214

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
215

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 :man_shrugging:

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.

216

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.

217

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 :joy:

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.

218

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…

219

The account was suspended because of the use of inappropriate language. That is and won’t be tolerated from anyone.
The explicit request was to behave and keep this a friendly forum, in stead a very rude reply using inappropriate language has been received. That will result in silencing any account.

220

It’s a low-cost INDOOR gateway. Three enquiries were made to try to help resolve the issue but we did not yet understand the details. This is not an appropriate case for the TTI involvement and as the TTN community enjoy the many benefits of the free network run by TTI staff it seems unfair to ask them to debug it until we had the details.

We become moderators because other moderators & TTI staff feel we have shown enough forum & technical skills to be able to help guide the forum towards the goals of TTN. All the moderators are volunteers. We have a monthly conference call with our liaison at TTI on a range of issues which includes the workload that TTN creates for TTI.

As a user of TTN, a software & embedded developer that primarily builds devices & dashboards but still an owner of one TTIG as shipped and one TTIG modified for an external antenna & serial, multiple RAK, two custom OrangePi, a Dragino & a PyCom gateways, both external & internal antennas, a personal Chirpstack deployment and a TTN v3 stack account plus High Altitude Balloon LoRa experience, I’ve some experience at gateway/RF level. I don’t believe you have to design or build a product to be able to support it, otherwise my assistance with Arduino LMIC wouldn’t be valid as I didn’t make the ATmega328 or the LMIC, despite the multiple successes. So supporting the TTIG at the level of a low cost gateway with an internal antenna doesn’t seem too far fetched.

With this insight, I did not see it appropriate to get TTI to look at an edge case like this, so in this case, I’m more qualified to “chime in” than most. I have on numerous occasions tagged, directly messages & gone on to Slack to alert TTI personnel to an issue.

If we could unwind time, ideally @nowiresfil would have told us that he needed his TTIG to pick up his test nodes sooner and we’d not be where we are. It was only after my message that we actually understood the core issue.

Unfortunately his reaction to my post breached forum policy so was edited by another moderator. His response to that moderators message is unprintable in polite circles. He’s not suspended, just on a a timeout / cooling off period until tomorrow.

I can understand that Australia has it’s own deployment challenges. If a new topic is started to outline them, if there is any doubt that TTI are not hearing them, we would be happy to ensure they they do, so they can provide a response.

Here in the UK, which does not enjoy as much coverage as people think we should, I would look to deploy moderate costing gateways with a simple external antenna, as from my experience, a TTIG is not suited for covering anything other than a larger building and it’s immediate (250-500m) area.

Please, can we move on. We can point @nowiresfil to resources, either the known good external antenna mod or low cost gateways that have an external antenna from the outset.

221

Looking at your issues:

TTN did not create two frequency plans, the industry did. TTN supported the appropriate frequency plan from the start, however there weren’t manipulated devices available and there were a lot more for the Asian frequency plan and as a result people started using those devices.

Regarding TTIG, it has known issues where it will not show connected in the backend when there is no traffic. An easy way to mitigate this is by having a node within reach of the gateway transmitting every so often. Even when not showing connected it will receive traffic and forward it to the backend as soon as possible, that will however require building a new connection to the backend which will take some time (a few hundred milliseconds with a decent internet connection).

The symptoms described by nowiresfil are new. The behavior does not make sense given the way the software behaves elsewhere, but I trust things are as observed so it would be very interesting to get to the bottom of this. However that does require tests that can’t be performed by anyone but nowiresfil.

222

Can you please refrain from poking the fire.
You know nothing about me and my industry experience. and I suspect you know nothing about @noriresfil either and potentially most people on this forum.

you should distance yourself from replying and peacocking. for what its worth. after reviewing your concise history of why you are here I don’t think you are any more remarkable then most people I know … in real life on the subject, myself included.

perhaps instead of being the biggest voice in the school yard stop trying to hard to assert your dominance, and control over the forum. A moderators job is to govern remember.

anyway I don’t post much in forums, I tend more to be a lurker. differences of opinions and diversity of ideas is something most forum members get horribly wrong…

For what it is worth on “indoor equipment”. indoor equipment at the hardware level should be comparable with outdoor equipment. I have a RAK “indoor” gateway in a “outdoor” enclosure. and it gets 15km easy. it is no more remarkable then a “outdoor” model it just bought in a box.

223

its good to know where the product comes up short. I might buy one knowing the problems before going in and any potential fixes.

Its probably not a requirement of such a device to send such a STAT packet, if v3 supported it because the STAT packet is really only useful for moving gateways / or gateways with a GPS.

What I would like to get from this discussion is whether. there will be a keep alive mechanism in the future when the issues in the backend are resolved, and whether there will be a firmware update to address the issue if the backend is not the complete cause. i.e a missing subroutine in the firmware to trigger a keep alive packet.

I think either way, if I were to deploy one I could put a cheap node within range of the device to simulate a keep alive, but then that would only increase traffic for the purposes of sending a more lean ‘im still here’ packet

224

That depends on the design. The components used in the TTIG and its design will result in reduces performance when compared to other designs and components.

The new protocol is TCP based and does not require the keep alive the UDP protocol uses. TTN redesigned how things are handled in V3 (partly because the console didn’t scale well) and there shouldn’t be any issues. However I can’t test as there are LoRaWAN packets every few minutes at my test location, even when I shutdown all my devices.

In several topics on the forum you’ll see the advice to deploy such a canary anyway. It helps to detect any issues and pinpoint the probably cause of issues when they happen.

225

The history of this GW is that it was originally developed by/for and marketed by tracknet.io (as the TABS GW) - since reaborsobed back into Semtech - with the model of building the network from the inside out vs classical GW’s outside looking in. As such it is engineered to high volume low cost, with yes some corners cut and behavioural issues on the (Patched into) V2 TTN stack/back end. It is designed to be used inside/deep inside buildings in a benign internal environment, using indoor vs outdoor rated components, and using the reduced spec version of the SX130x GW baseband chip. It is engineered to a cost point not a performance point.

If it gives you (and @nowiresfil ) any confidence I use many of them personally as do some clients (I have 10 deployed as part of my personal contribution to the TTN community network - 9 ‘as is’ & one (soon to be 3) hacked to support an externally mounted antenna), and plan to deploy more in the new year. I consider these as ‘infil’ GWs vs being core network systems - adding extra coverage and some redundancy in areas more widely covered by higher spec/higher perfomance GWs typically based on the SX1301, either as indoor or industrial systems re-housed in outdoor housings, with appropriate protections, or using design for use outdoor units. As noted in this community article here https://www.thethingsnetwork.org/community/bourne-end-and-cookham/post/pop-up-trials-for-ttig-in-marlow and referenced here https://www.thethingsnetwork.org/community/bourne-end-and-cookham/post/its-back-ttig-longer-term-deployment-in-marlow

these are good devices for covering a few hundred meters to a few kilometers around a poorly served area and where (typically teraain or building clutter) masking may limit practical use out to many 10’s km. THey are typically in areas where there are enough active nodes to keep them online/connected or I accept they may drop occasionally, or if needed I deploy with a canary device or a function device running often enough to ensure ‘keep alive’.

Whilst the Marlow GW above was intended to cover an area roughly 100m - 2km from deployed site (working with other GW’s in the area), yesterday whilst out doing some coverage tracking tests along the Thames Valley/Clivden escarpment using RAK and Dragino based GPS trackers I saw some signals picked up which I am sure (red circle) in one case and 2 highly probable (green elipse) signals on the Dragino LGT92 (Havent had chance to check the GW meta data to confirm), which were collected by the GW some 5-6+km away on elevated locations.

image