This topic is for technical info / questions about TTIG
The Things Indoor Gateway - what is it ?
The Things Indoor Gateway is designed to be a fully compliant, ultra low-cost LoRaWAN gateway, with WiFi as the backhaul. The gateway comes with a wall plug, and can be powered over USB-C (900 Ma)
Features:
An 8 channel LoRaWAN indoor gateway at a price of ~$69.
One of the first gateways to support the state-of-the-art BasicStation Protocol.
Supports LBT.
Simple setup steps taking lesser than 5 mins.
Can connect to any network backend of choice.
Setup and Connectivity over WiFi.
Can be powered up via a USB-C cable or via an elegant connector to the power outlet.
Finally here, later than expected but it’s my fault (not seen two notices in the mailbox… and I also never received a tracking number from RS).
Superquick configuration, it’s already online (for testing, then this one will go home).
Did a crude set up in a friendly town center office for a couple of days and this is what I saw in walk about/driving tests (just a sample). TTIG was placed on 1st floor windowsill facing NNE, Many similar buildings around and at similar heights masking signal outdoors esp E, W and to South.
Near 100% coverage in walk about’s within approx 500m W/SW of GW, though coverage South East of A4155 and part of High Street was poorer and patchy (50-85%) due to building clutter
Topology of area and some additional signal paths:
Just installed a other TTIG (TTN-TTIG-02)
It is one from the get free from the event in Amsterdam. the owner send it to me, and have make the setup for him.
Again +1 off the totall from xxx is online
In the main time i will modify it with a external antenne (so no warrenty). on the same way as above mentiond with a few foto’s. Bring the antenne connection outside the box with a SMA pigtail
This TTIG will moved to a office in amsterdam on the port side.
If I go work to it, i will take picture’s, and do some measurment’s on the antenne.
In the cold light of morning with the knowledge that problem was likely the build standard on a mis-shipped unit I took a closer look at the non-functioning unit and compared more closely with the previous four.
Dho! Why didnt I check earlier…
This is lable from the bad unit:
Note the device part number (not the model number which is consistent TBMH100) - TBMH100**915**xxxxx
Another clue is the FCC ID - might expect on a generic part but should have been a clue on a supposed 868Mhz EU unit.
Checking the other four they all look similar to:
Note correct device part number - TBMH100868xxxx
My error was in setting up the 1st 2 units and configuring onto TTN I looked at the label (2nd type) for the EUI # (the 58A0C…) for Console set-up and registration. I then realised that the web view on the device during set up/conf shows all the device details - inc the EUID - so for 3rd onward I just looked at web interface and copied/pasted the EUID from there into the TTN console.
That worked fine for the 1st 4 units but of course the 5th was this US build and I never got to see the label to spot the change
Lesson is - check ALL units shipped form RS Components on receipt & double check labels and build standards as you configure and deploy. Just because they came in same batch doesn’t mean they are the same device…
I received my 915 MHz TTIG from RS this afternoon. The USA power adapter was included in the box. Things Network registration succeeded on the first attempt.
This is just the 9th registered gateway in New Jersey, USA (population 9 000 000). We need to better proselytize LoRa on this side of the pond
Is there any chance the TTIG aggressive disconnect/reconnect logic could be relaxed a little?
I have a single TTIG that I use for testing various end nodes. One node in particular reports once an hour. It’s the only Lora device around and there are no other gateways in reach. The problem is that if the TTIG is in the middle of reconnecting, it seems to drop or not hear the node. This happens quite frequently.
I guess I could do some sort of keep alive node, but that seems a bit of a kludge.
Yeah well we could try to increase the disconnect time. But this still means that if your nodes send data while it reconnects, you will still miss packets.
(for testing, then this one will go home).
