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.
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.
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.
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.
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
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.
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.
We know little of most users on the forum and vice versa but whoever you are and whatever your experience, disrespectful behavior as quoted above is not tolerated on this forum!
You are welcome to contribute and discuss but will have to watch your language and behavior.
For personal (off-topic) discussions use private messages instead.
If you want to discuss the features or perceived quality of the TTIG then you can create a new topic for that but don’t do it here and stay on topic.
See our Code of Conduct.
I have purchased a TTIG and the product drops out of connection and “last seen” have never updated properly. I have a node in the same room which has been able to connect on other third party gateways but my TTIG. I would like to recheck that the Legacy Packet Forwarder Option is correctly selected, but I have not been able to find a way to check this. Is there any way that this setting can be checked on the console?
Has the TTIG ever relayed any uplinks at all?
The “Last Seen” is known to be unreliable so should not be used to verify anything all all - the acid test is traffic through the gateway.
No unfortunately. I have never been able to see a single packet even though I have a node in the same room as the gateway.
There can be issues with having them too close, so a simple thing to try is to put one of them in another room or about 5m+ away.
Are there any gateways near you that you could test the device is uplinking OK?
What is this device?
If I take to module upstairs, I can connect with a handful of gateways which are a fair distance away (13Km). I use the TTN mapper app which confirms the gateway connections.
The issue resides with my TTIG gateway.
Just a quick note to let you know that the problem has been resolved. A feature needs to be enabled which can be requested on the TTIG AU915 support thread.
Hello! I have the same Problem…solid green LED and the Status is “not connected” and there is noch traffic.
The Gateway ID is eui-58a0cbfffe80332f
Can somebody help me solve this issue?
Thanks in advanced
Andreas
Today the Gateway ist connected, its received Messages but didnt transmitt the Data.
Any idea?
Thanks! Andreas
It is good to let know that your issue has been solved, but not providing any details about the solution will not help other users with similar issues at all.
This forum is a community of volunteers helping each other and sharing information. It is not a helpdesk operated by support employees. So please share the details of your solution so others can also benefit from it.
Sharing a link to that topic and be more specific than “a feature needs to be enabled” will be helpful.
Start reading from the very top of this topic all the way down to the end.
Hi,
I saw the posts regarding gateways being disconnected from 2019. I’m having a very similar issue with my TTIG that I successfully installed and sent a few packets before it disconnected. I rebooted it and it connected again but then disconnected like 30 min later. This happened 4 times the first day. Then it disconnected over night and never came back online. It’s been down a couple of days (“not connected”). Are you able to check status?
eui-58a0cbfffe80326c
Thanks,
Win
Same problem here. Been working great over the last month and since 10am this morning 13/04/21 it stopped working. Turned it off and on again and status is still showing as ‘not connected’