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.
That’s correct. As stated in the FAQ above, emphasis mine:
inside pic here.
same desing, just change sx1301 for a sx1308 and saw filters for 868 or 915
Thanks! That confused me
I’ve tested mine yesterday and it worked with ttn. If you have 2 gateways in parallel this looses every third signal. If you use it alone, every signal will be received. I tested in very nearby installation. May be in longer distance you will loose signals due to the lesser channels. I will test that as well and inform.
if you are in config mode (pressed setup 10+ sec, light changes) you will see all relevant data:
Gateway EUI: 58-A0-AA-FF-FE-AA-AA-00
WiFi AP MAC: 58:A0:AA:AA:AA:00
WiFi AP Pass: xxxxxxxxx
WiFi STA MAC: AA:00:AA:00:AA:00
Serial Number: TBMH100868000943
MFG date: 2019-01-21 07:38:38
FW Build: 2018-12-06 09:30:37
FW Version: 2.0.0
Core Version: 2.0.0(minihub/debug)
take the Gateway EUI, but small letters without ‘-’. that should work. if not take with leading ‘eui-’.
after connecting to TTN your complete GW-EUI should look like:
eui-58a0aaffeaaaa00
When checking “I’m using the legacy packet forwarder” I cannot prefix any “eui-” and also all letters are uppercased on the fly. So I guess you did not tick that checkbox?
Also, where are you seeing those details? Care to post a screenshot?
Huh!?
This scares me a bit: it seems somehow the gateway gets some credentials, even when a gateway is not claimed through TTN Console, which are used to fetch the configuration and all? I wonder what “requires resetting the credentials on the server side” means, and if that needs intervention from the TTN team.
I understand, that you need to change your data in TTN console after a reset.
What data? (I’d not press that button until I understand…)
Are you looking at the TIG’s gateway Traffic page in TTN Console, or at the gateway(s) metadata you see when clicking an uplink in the application/device’s Data page?
(I wonder if maybe the TIG is just a bit slower, and de-duplication hides the uplinks it has received from the non-standard channels? Weird though…)
I just repeated setup to look. press the setup button not the reset button. connect to the new AP ‘MiniHub…’. on the bottom of the page 192.168.4.1 you will find the datas of your GW. scroll down the page.
after that you need to connect to your own network by clicking your wifi on the list. put in the credentials and save. after a reboot and some time the gw will be connected to your own router. then you can start in the TTN console as described in recent mails before.
I hope, you can figure all out.
I looked at the GW traffic page.
I wonder if given the new Basic Station software there is no need to configure a router/frequency plan in TTN Console, for a TIG to become fully operational? But maybe that needs V3, rather than V2 with some bridge?
Some statistics seem to show only few have registered their TIG so far. Too bad not everyone is using the same description
1 "Gemtek / TTN Node TTN 2019"
1 "Gemtek Femto"
1 "Gemtek GIOT InDoor FemtoCell "
1 "Gemtek IOT Femto Gateway"
3 "Gemtek Indoor Gateway"
1 "Gemtek IoT Femto Gateway"
1 "Gemtek Mini"
1 "Gemtek MiniHub MH100"
1 "Gemtek Minihub"
3 "Gemtek TBMH100"
1 "Gemtek TIG"
1 "Gemtek TTN GW Mini"
1 "Gemtek TTN Indoor gateway"
1 "Gemtek TTN Indoor"
1 "Gemtek TTN limited mini GW"
1 "Gemtek Tabs Mini Hub "
1 "Gemtek Tabs Mini Hub"
1 "Gemtek Tabs indoor gateway"
1 "Gemtek Technology Co. Ltd. MXF-MHB100 Tabs Mini Hub"
10 "Gemtek The Things Indoor Gateway"
1 "Gemtek The Things Network Indoor Gateway Conference Edition"
8 "Gemtek WLRGFM-100"
1 "Gemtek WLRGFM-100(EU)"
1 "Gemtek indoor gateway"
1 "Gemtek pico"
15 "Gemtek"
...
1 "The Things Industries Indoor"
1 "The Things Network Minihub"
1 "The Things Network ttnctl"
1 "The Things Products Indoor Gatway; 2019 The Things Conference Limited Edition"
1 "The Things Products TBMH100 (Gemtek Tabs / Mini Hub)"
2 "The Things Products TBMH100"
1 "The Things Products The Things Gateway (tabs)"
1 "The Things Products The Things Gateway Mini"
...
5 "The Things Products The Things Indoor Gateway"
1 "The Things Products The Things Mini-indoor Gateway"
I don’t know if http://noc.thethingsnetwork.org:8085/api/v2/gateways also shows TIGs that have been set up for some WiFi (and then are forwarding packets to TTN just fine), but have not been registered in TTN Console.
It works for me.
Just put the gateway onto power, push the button and connect to wifi.
You can put in 8 different wifi accesspoints as defaults.
Then register at TTN and a few minutes later i see traffic.
Nice that it is portable, so i can take it with me for demos.
Given problems reported in earlier post, can you extend on that? Like: does OTAA work? (Or more generic: do downlinks work?) Do you see it use more than 3 channels? Do you see all expected frame counter values, without gaps?
Hello Everyone,
We here at TTI are slowly recovering from our post conference fatigue. Thanks a lot for keeping this thread going and we’re very grateful for this amazing community.
Firstly, the channel config was a yaml reading mismatch between the way the CUPS server sends it the gateways use it. This has been fixed as of 5 minutes ago and the UL/DL should be on par with other gateways on TTNv2. The packet loss should be resolved now.
Secondly, we are working on official docs for configuring and connecting the TTIGs to the network (although you’ve figured out all of it… ). This will be useful for future users to quickly set things up. The docs will be available in a few hours.
Thanks for your support and let’s build this thing together,
Krishna on behalf of the TTI team
@Krishna Thanks for the information. Will there also be information/investigation if it’s possible to change a 915 device to 868?