TTN Gateway blocked

(Rhinoteknl) #1

I had a gateway installed on my TTN account and was working since last 3 months and now its now shown on ttn account , it looks like its blocked by the TTN.

Any has this kind of experience, or any solution


that’s not enough information.

(Rhinoteknl) #3

because if i ping it only answer " Request timeout"


you can’t 'ping a load balancer… it won’t answer

(Rhinoteknl) #5

ok, so i have one TTGO TBEAM 433mhz device, may i allowed to test it with TTN ,

(Jac Kersing) #6

TTN does not support 433MHz. Search the forum…

(Gbell In Oz) #8

Possiblye OT, but I’m missing something conceptual regarding your answer.

Why doesn’t @rhinoteknl’s 433 MHz device work with TTN? How does a PHY concern affect TTN?

I have a feeling it has to do with adaptive data rate and how those are specific to regions?

Similarly, for AU915, the TTN frequency document states

Note that The Things Network uses 2nd Sub-Band only (channels 8 to 15 and 65). You’ll need to
program the specific channels into the devices in order to make them work with TTN.

I had set my AU915 node’s channel mask to Ch0 (single channel gateway, unfortunately) before reading that, but TTN can see packets from my gateway just fine.

(Cslorabox) #9

If a gateway reports packets in, they might perhaps be seen (though they might be rejected if they didn’t match expected air settings).

But packets reported in with unrecognized air settings would probably not be eligible for any downlink MAC or application replies, including join accepts because how would the TTN servers know how to generate proper downlink air settings for an uplink inconsistent with the design specifications?

Theoretically someone could make a gateway that would map unsupported uplink settings to simulated supported ones, and the reverse in the downlink direction, but…

The real questions are:

  1. is 433 MHz allowed in the askers jurisdiction?

  2. do they want to go to the trouble of trying to get TTN modified to support this, or to do their own simulating translation

  3. would they rather run their own server

  4. or would it be easier to buy a node with a radio for a supported band?

In most cases #4 is the smart choice…

(Jeff Uk) #10

@rhinoteknl @gbell_in_oz @cslorabox. Many of the reasons & answers are on the forum over last couple of years. As @kersing suggests, please use search. For me it comes down to 3 potential issues… 1) fragmenting community effort via disparate freq plans ( no repeat of Australia please! ;-), 2) wait for LoRa-Alliance to define & implement plan to avoid dead ends or incompatibilities & 3) frequency band limits and risk of breaching regs wrt freq use.

If too lazy or not motivated to search then FTFY :slight_smile:

@cslorabox is spot on wrt #4 :wink: