New gateway: The Things Indoor Gateway

Same here. I have the TIG up and running and it’s shown as connected in the console. I have serveral nodes running but there is no traffic on the TIG.When is start up a new node, I see join requests on the TIG but still no traffic. When I switch it off, the nodes have no problem joining TTN using a different gateway with a single request. Any ideas?

Update: I have 4 Nodes running here right now (ElSys ERS, PNI Placepod, Adafruit GPS Tracker and simple LoRa32u4). Only the packets sent by the LoRa32u4 are being forwarded by the TIG. All others are ignored. So the chosen router or the frequency plan shouldn’t be the problem. Also, all nodes are several meters away from the TIG.

Same here, roughly every second packet is missed by the TIG, but seen on my MatchX GW.
Both gateways are in ~20m distance.

I have similar behaviour. I see it ‘connected’ in the TTN console, and every now and then the ‘last seen’ counter jumps back to zero, but I don’t see any traffic, not even join requests.

I thought maybe it had something to do with the port forwarding in my firewall, because I already have a gateway in my network. So because I have the luxury of a fully redundant Internet connection, I set up my existing gateway on wifi network A, using internet access A, and the TIG on wifi network B using internet access B, and set port forwarding accordingly, but it makes no difference…

I have the same issue here. On the TTN gateway traffic tab I see join requests coming in from my node and 4 seconds later a response (join accept) leaving the gateway. This is never picked up by the node. There is no other traffic observed by the gateway (for all I know, there might not be any, as I am in a somewhat quiet place, with no other gateway coverage). The distance from node to gateway is approx. 10m.

I took my TIG offline. If i run it in parallel to my MatchX gateway, this causes serious join problems.
MatchX only: Join in 2-3 seconds.
MatchX & TIG in parallel: Joins take sometimes minutes!

Thanks for the great discussion guys!

Very interesting. Seeings that the antenna supports 915 MHz and there would have been some antendees from Australia and the US, would anyone be able to make the mod and test it for the frequency plan?

Also, when the board is released online, could someone post a link? Can’t wait to get it in my hands to do some of this testing as well.

For those comparing to another gw: what about RSSI/SNR? Thanks.

can you try changing the TIG position from horizontal to vertical (probably need some sticky tape :wink:)

Any idea about reach in km’s / miles? Tested in real life?

@humaxnerd or anyone having attached the UART: care to post some longer logs? (If only to see it indeed looks like the Basic Station logs, which would then probably use some Station to Packet Forwarder Protocol Bridge on TTN’s V2, which could also be the culprit of not getting all OTAA Join Accepts?)

Am I right to assume that TTN selected the TIG for the Join Accept downlink for the failures? Which gateway is selected upon success? And is it then always using the same SF on success? (Like: LMIC starts with SF7, likely to get the Join Accept in RX1, and increasing the SF after some failures; some other libraries simply always use SF12, often getting the Join Accept in RX2.)

Assuming all nodes nicely perform channel hopping: any details on differences in SF? And like @UdLoRa asked: what’s the differences in RSSI/SNR for the different nodes? (See also the details in TTN Console when clicking an item in the application/device’s Data page, or the gateway’s Traffic page.)

Well, given the shortage of EU868 devices, but not of US915, I’m quite sure that those won’t have to make any modification at all. :slight_smile:

Would you be able to clarify what you mean about the shortage? Did they hand out the US/AU915 version at the conference as well?

My main reason for asking about the mod was because I thought only the EU868 version was given out, therefore the mod would have to be done.

It’ll be interesting to see what the difference is between the two boards. If it was as simple as soldering the resistor in another spot, I don’t see why the US/AU915 is going to be released later in the year rather than now.

Just curious, how did you get this output? I understand what the pinouts are, but would you be able to explain these few things:

How did you read this data?
How did you connect the board via the pinouts to the computer? Was it an adapter of some type?
What software did you use?
Did you have to know which baud rate to use and if so, how’d you figure this out?

Would really appreciate it if you could answer those questions. At the moment, I’m not sure how you pulled it off.

Yes. Also to people who wanted EU868. On Slack:

Unfortunately at the end I went to pick up my gateway to discover they only had the US 915 MHz available. The guy behind the counter suggested me to reflash the firmware to make it work on the 868 MHz band.

(But that advice seems bogus, given the solder pads.)

Just like with the The Things Gateway: https://www.thethingsnetwork.org/docs/gateways/gateway/faq.html#q-i-want-to-get-in-depth-insightread-debug-messages-of-my-gateway-is-that-possible

Or: https://www.thethingsnetwork.org/forum/t/raspberry-pi-to-monitor-serial-output-of-a-node-or-tnn-gateway-and-alert-on-slack-or-telegram/13030 if the voltages match, but it seems they do:

1 Like

@ElectronicallyE, At the conference they said RS Online will start selling from next week. This may only be from their UK and US websites.

@TonySmith, this is for the US and EU.

Starting in February 2019, versions for EU and US are made available while India, Japan, China and Australia will follow in the first half of 2019. There are 4 different versions available - EU868, US915, AS923 and CN470.

Seeings Australia and United States use 915 MHz, I’m assuming they are referring to AS923 for the later release, not AU915.

The delay must mean that there are some hardware changes for AS923. I’ll be interested to see what these differences are.

Updated the image with pinouts, in order to document your finding:
UART

@humaxnerd which Baudrate did you use? is it the same (115200@8N) as in https://www.thethingsnetwork.org/docs/gateways/gateway/faq.html#q-i-want-to-get-in-depth-insightread-debug-messages-of-my-gateway-is-that-possible ?

Although I really want to get a UART connection running to this thing I’m lacking time today, thus I cannot provide the logfiles requested by @arjanvanb in https://www.thethingsnetwork.org/forum/t/69-gemtek-gateway-the-things-indoor-gateway/22049/126

2 Likes

I use 115200,8,n,1. You can use any terminal program. For example TeraTerm. For the connection to the computer I use a FTDI serial USB converter and you must set it to 3v3.
I will post some extra data captured from the serial port.

For whoever is into some more investigation: the Kickstarter gateway also allows for entering commands using the UART. Of course, the TIG is quite different, and I cannot quickly find any references to something similar in the code, but: maybe! :female_detective:

…but earlier you wrote the following; wouldn’t that make it unsuitable for outdoor use? (At least in Europe.)

Potentially yes but then depends on thermal management of the unit…issue is more at higher temps, a low temp sensor driving a simple heater (relay switching high wattage resistor over supply line?!) or using self heating if well insulated takes care of lower temp excursions so careful placement e.g. out of direct sunlight etc. likely mitigating the issue… outdoor in water proof housing can mean shorter feeder cables and easier placement (no drilling walls etc!) :wink:

At this price (~1/10th pre-built outdoor unit cost) if only 2 or 3 prove worthy out of 6 then still up on the deal…and outdoor failures still good for indoor deployment of course!

1 Like