That answers the question if a simple firmware upgrade could change a US915 unit into a EU868 unit (while the antenna would be troublesome then). No, that would at least need some soldering as well:
2 Likes
Is that a 0 ohm resistor or a PCB trace (that will have to be cut)?
maybe it’s only a passive “DIP-Switch” which is read by firmware?
Given the distance from the antenna and its connector on the very same board, I’d guess it doesn’t change much in that antenna path. But this is not my area of expertise at all… Maybe some might be able to tell us if the chip sets would support multiple regions to start with?
As an aside, the “also available” made me laugh; apparently it needs to be mentioned separately?
I have followed these steps. After reboot how do i register it in the TTN console? thanks
Seems to be 0 Ohm resistor, as measured as 0 Ohm resistance.
Detailled photo might expose a UART Inferface:
5 Likes
ok finally got it. I found EUI in its page and add it in the console registration page! Now is online.
After this morning 
Online, get data from it. So it works
Now look how we get more info out off the GEMTEK-box
Powered over USB-C are 230 volt connection both are working well.
Thanks DMTH for the look inside
The four solder pads in a row certainly looks like a good candidate for being a UART interface.
Maybe the “also available” version is 433MHz, or whatever that band is. In an ideal world, there would be differences in passive components leading to the antenna and the antenna itself, between the US and EU versions, but it’s far from an ideal world these days. So many modules for sale that include 2.4ghz wifi antennas, instead of 900MHz antennas, according to actual tests run by people with rf equipment.
I have tested is and it is a UART. Some output.
019-02-02 14:49:46.264 [SYN:INFO] Avg MCU drift vs SX1301#0: 1.0ppm
2019-02-02 14:49:46.283 [SYS:DEBU] Free Heap: 19512 (min=17304) wifi=5 mh=7 cups=8 tc=4
2019-02-02 14:49:47.287 [SYS:DEBU] Free Heap: 19512 (min=17304) wifi=5 mh=7 cups=8 tc=4
2019-02-02 14:49:48.290 [SYS:DEBU] Free Heap: 19512 (min=17304) wifi=5 mh=7 cups=8 tc=4
2019-02-02 14:49:49.294 [SYS:DEBU] Free Heap: 19512 (min=17304) wifi=5 mh=7 cups=8 tc=4
2019-02-02 14:49:50.298 [SYS:DEBU] Free Heap: 19512 (min=17304) wifi=5 mh=7 cups=8 tc=4
2019-02-02 14:49:51.301 [SYS:DEBU] Free Heap: 19512 (min=17304) wifi=5 mh=7 cups=8 tc=4
Pin close to GND is TX from gateway
7 Likes
All gateways I know have (notch) filters so I doubt you can really get a worldwide gateway.
1 Like
I have added the wifi ap, selected the legacy packet forwarder and used the mac-address within in the middle part described above, but no connection. Could anyone help?
Or you place it on a small cardboard packing box. With a hole for the USB-c connector 
Then you can just put it on your desk
…stating:
ISM or ISM & BT or GPS Stamp Metal Embedded SMT Antenna
868 MHz, 915 MHz, 1.575 GHz, 2.4 GHz
So, it’s actually used/usable for both EU868 and US915?
(@dmth’s pictures with the part number 1002427 are for a EU868 model.)
I needed several attempts also, but now it is working.
Be sure to use the right MAC – not the WiFi STA MAC you can read on the label, but the WiFi AP MAC that is shown on the web interface page bottom. For me it reads “58:A0:xx:xx:xx:xx” in the second line, the first line being “Gateway EUI 58-A0-xx-FF-FE-xx-xx-xx”.
So I typed “58a0xxfffexxxxxx” (lowercase, no hyphens!) into the “Gateway ID” field. It then says “It looks like you are trying to register a gateway by EUI. This probably means you are using the legacy packet forwarder.”, so I checked the “legacy packet forwarder” checkbox.
Registration was no problem then.
2 Likes
I have almost the same, connected to the TTN but no traffic. Green led is most of the time on and so now and then blinking green. All looks fine only no trafic. My nodes are running and see the trafic from different other gw’s. What do I wrong? I see only many join requests when I reset my node on the Tabs, if I switch the Tabs off it needs only one join request. Who knows where I should look?
Just a wild guess: if OTAA Join does not work when the TIG is active, but works great when switching off the TIG, then apparently TTN has selected that TIG for the Join Accept. And somehow that Join Accept is not received by the node:
-
Maybe the selected router in TTN Console’s settings is not correct, adding too much latency for the downlink to arrive at the gateway in time?
-
Maybe the selected frequency plan is wrong (making TTN make wrong choices as for the Join Accept’s downlink settings)?
The above, plus “All looks fine only no trafic” makes me think you actually did not register the gateway correctly, so any configuration you made in TTN Console does not apply to the actual device: check and double-check the EUI?
Do you see any Join Accept in TTN Console, on the device’s Data page? If yes, is the TIG listed in the meta data of the gateways that received that Join Request? (Click on an item in the Data page for more details.)
Any experiences already with the gateway’s performance?
Having the TIG here and a DIY RasPi + IMST iC880A with a small stub antenna, all in the same room with two Heltec ESP32 LoRa nodes running different software (one is PAXcounter that constantly sends packets every 60 seconds after one join, the other is a sensor that wakens up, joins, then sends a packet and goes to sleep again).
Both nodes are received by both gateways. Looking at the Console’s gateway traffic, the TIG has about half as many entries as the RasPi does.
The TIG’s LED stays green mostly, but sometimes it flashes.