TTN Gateway blocked

[rhinoteknl]

Hi,
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

[BoRRoZ]

that’s not enough information.

[rhinoteknl]

because if i ping router.eu.thethings.network it only answer " Request timeout"

[BoRRoZ]

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

[rhinoteknl]

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

[kersing (Jac Kersing)]

TTN does not support 433MHz. Search the forum…

[gbell_in_oz]

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]

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]

@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

https://www.thethingsnetwork.org/forum/t/proposal-for-eu-433-frequency-plan/13090/11

RAK831 with 433 MHz frequency plan

Hi Ferrero, I do see a problem here! The 433 MHz ISM Band allows you to transmitt between 433,05 MHz and 434,79 MHz. That means, that any LoRa chirp should not exceed that frequency range! For the lower end 433,05 MHz that means that the lowest frequency you are allowed to set up is 433,050+BW/2. For BW125: 433.050+0,0625MHz = 433,1125 MHz. For the upper end 434,790 MHz that means that the highest frequency you are allowd to set up is 434,790-BW/2. For BW125: 434,790-0,0625MHz = 434,7275 MHz …

433 MHz band support and alternatives

It seems you’re out of luck: @johan We’re not planning to support EU433 officially. With V3, this will be much easier to do for private networks. In EU, on the public network, we stick to 863-870 MHz. For Israel, https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html#i shows no plan yet: Country Frequency Plan Regulatory document … … … Israel EN 302 208 The latest LoRaWAN 1.1 Regional Parameters is the first to mention Israel: Country name Band / c…

@cslorabox is spot on wrt #4