TTIG : The Things Indoor Gateway

(bluesensing) #358

may be this is a feature, inspired by K. Lagerfeld - Chanel
be serious: this doesn’t seem a problem. Because today my t-beam was detected by 3 gateways as shown below, using 3 different “channels” 2,5, and 0. Why not? There are 8 of them in each gateway


TTIG is a fine device!



I agree, TTIG is a quality, well build device.
But this seems a little backend bug.

(Arjan) #360

I’d say that if all gateways use the same frequency plan, then the metadata should show the same channel.

(bluesensing) #361

i also lost TTIG connection … hmmm lunch time??

(bluesensing) #362

maybe they are numbered in a different way in each concentrator :drooling_face:

(Arjan) #363

Ah, I assumed that TTN determined the channel number given a frequency, SF and bandwidth. But maybe you’re right that the gateway determines and passes the number, and TTN simply shows the number it has been given.

(Bryansmith) #364

US915 here: TIG has been down for 3 hours :expressionless:


yes, OPS are working on it

(bluesensing) #366

The problem with using nodes too close to a gateway is that the gateway receives the same packet on multiple frequencies (cross-talk).

(bluesensing) #367


(Lag Compensator) #368

How close is “too close to a gateway”? The distance from most of my nodes to my gateways are ~1-4 km.

On all the messages I’ve looked at, I’ve never seen anything else than channel 0 used on my mini gateway.
Also, I don’t trust the SNR/rssi values from the mini gateway. For example the numbers I gave in my previous post.

(Jac Kersing) #369

TTN stack V2 does not implement the new Basic Station protocol. Somewhere in between your gateway and the TTN stack there is a process running to translate the new protocol back to the ‘old’ Semtech UDP protocol. The sources of the Basic Station packet forwarder include python code for this purpose and a quick glance does not reveal any code handling the channel.

The channel number is based on the configuration. The frequencies defined in the configuration block is matched. So any gateway using a configuration with frequencies defined in a different order will report a different channel.

(bluesensing) #370

“So any gateway using a configuration with frequencies defined in a different order will report a different channel.”

that’s what i imagined myself


everyone entering this topic to ask again if there is a problem … YES THERE IS

but … please be patient …

(Depl0y) #375

Sorry BoRRoZ, but I’m new to LoRa and we couldn’t get it working, hard debugging such a small device :slight_smile:

There was nothing here: maybe it needs to be updated?



(Mhruska) #377

Completely agree. Very discouraging. I was going mad.

(Remko) #378

Note form my side on TTIG connectivity: Although the led is continous green console says disconnected for 20 hours. Laste maasge received was yesterday 13:01.
Curious to see how they will manage when TTIG sales start coming days (as being announced) and console is not working.


I expect now it will be fixed tomorrow morning because yesterday afternoon it didn’t work out (from a moving train :wink: ) for us its a free gateway and a free to use network- we don’t have an SLA!


Here the same, they all stop working a 21 hours ago. (i got two under my view)
Maybee a Sales, marketing trick to put back online a 550 TTIG’s on the sales day :slight_smile:
But it shall bee some thing in the centrall part off managing off these device’s. 12 days ago there was a look a like problem with only on US915 config’s
Maybe some body off TTI can inform us here (Krishna where are you :slight_smile: )