New gateway: The Things Indoor Gateway

@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

Just thinking of POE and a weather proof enclosure. I’m not too proud to use a ufl to SMA/N adapter. :wink: I can already see that I’m going to have to buy one of those inexpensive network/SWR analyzer tools so that I can make my own collinear antennas.

That might also explain the following?

Maybe TTN always selects the TIG to transmit the Join Accept (which then somehow is not transmitted, or not received by the node), until the node happens to hop to a channel that is not received by the TIG? TTN Console should reveal that in the application/device’s Data page and the gateway’s Traffic page.

1 Like

Are you sure that your nodes send on more than 3 channels? :wink:

I can confirm that for my gateway.

They are already in Europe. Compliancy checks are now on the critical path

1 Like

I checked it against my parallel running MatchX gateway:
indeed the EU-TIG seems to receive only 3 channesl 868.1, 868.3 and 868.5, while i see the MatchX receiving data on other channels from same set of nodes.

This explains why i see such a huge packet loss on the TIG :frowning:

Seems the channel plan inside the gateway is unsuitable for TTN?

5 Likes

Luckily, I’m quite sure the configuration is fetched from the remote CUPS (and if not, then the firmware is checked daily, as noted in “The LNS connection breaks down every 24 hours and comes back afterwards. Is this normal?above).

(But then: it should obviously be able to transmit a Join Accept, even if only listening to those 3 channels…)

LBT is part of the newer hardware (recent SX1301 and SX1308) by default.

2 Likes

@Verkehrsrot, thanks for having a look.

Maybe its obvious, but if the three numbers of @humaxnerd’s US-gateway are 915 one can distinct the US from the EU version by the number (21) on the sticker.

Yes it’s 915. So you can see it on housing.

wifi Password is on the sticker as WiFi PW:

Hi arjanvanb,

Thanks for your reply and options. The selection through which gateway the down message will go is standard with the gateway with the best rssi. In this case all other gateways has a rssi from around -100db and the TIG -43db, so it is a logical selection to use the TIG. I have also double checked the selected region and that one is also correct and is already running successful for other gateways.

With kind regards,
Chris

I had the same problem: Gateway did not appear as connected with fffe’d EUI in the console.

I have sent some test packets and suddenly saw that they were received by my IMST gateway (as expected) and another gateway, which must be really nearby (from RSSI) but has a completely different EUI. I then tried to register this EUI and it was immediately connected. I have now confirmed that this really is my TTN Indoor Gateway (by moving around and sending more test packets).

But the EUI is not related to the Wifi MAC at all:

  • my Wifi MAC starts with 68:c6:3a:…
  • my EUI that appears on Console and now works starts with 58:a0:cb:…

This tells me for my situation: EUI is not derived from the Wifi MAC. The Wifi MAC printed on the device is the same as show on my Unifi Access Points, so that’s consistent.

My suggestion: look at the packets you send and find out if another Gateway receives them nearby. This could be the EUI of your TTN indoor GW.
It seems the Gateways send data to TTN as soon as they have Internet connection, even without being registered within TTN console.