First of all, I am making tests in an RF screen room. I have a RAK7248 Gateway. I can set it up as a EU868 gateway talking to nam1.cloud.thethings.network - and i can get a connection but no node to connect. @US915 it all works. Does any one know if the US servers can manage the EU frequencies??
If i try to set it up to eu1.cloud.thethings.network I can’t get a connection. Does ttn block connections from the US to the europen servers for gateways??
Are you using the same hardware for US915 and EU868? Because of the band filters on the (at least for most) concentrator boards that probably won’t work. The attenuation for EU868 when using US915 hardware is too much to get the RF to work.
The servers are named by location, they can all do the same thing in LoRaWAN terms but the Identity Server (for you to login in as a person, not the hardware) is in the EU and is irrelevant.
So you can setup a gateway that does 868MHz and choose the EU settings and have a device that does 868MHz all on NAM1 which would be better for internet transit time.
I do the reverse, in the EU I run a TTIG & devices on 915 for AU & US bands for checking channel settings before shipping. Works for me just fine.
Hi
I have the same situation I want to test devices prior shipping them to Ca. I do have a custom frequency list. The customer makes use of chirpstack server but I want to configure my test-gateway US915 to ship the data to TTN (I do have already a parser and know the backend). When I send a lot of messages some of them reach the backend but the downlink is missing. I changed the frequencies in the gateways configuration file on the gateway but had to select a Regional Parameters “US_902_928_FSB_1” where I am not familiar with. If the GW is configured using a custom frequency list is it mandatory for the backend to have the same? I cannot believe this.
The NS will need to know what the frequency list is to match the gateway - given that the gateway doesn’t really have a frequency list as a concept, it’s just a media converter - electromagnetic radiation to UDP packets with some CRC checks in the middle.
The device may be told a custom list, but the gateway doesn’t store the info on the uplink so it’s down to the NS to be able to figure out what to tell the gateway.
I can totally believe this as this, AFAIK, is how LoRaWAN works. Anyone that needs something special needs to know all the stuff so they can configure the special …
The gateway only listens at the frequencies specified. That means the gateway must match the frequencies the node uses. Also TTN backend must know which frequencies the node uses to make sure it transmits at the right frequencies.TTN will reject data from nodes when the reported uplink frequency does not match the active frequencies for the node. For regions where the join frequencies are a subset of the full range of frequencies used that means any join request on a non standard join frequency will be ignored by TTN.
That’s really a mistake - both because it’s not going to work, and more importantly because you want your testing to more closely reflect what your customer is going to experience, so that you get a chance to anticipate the issues they are going to experience - and ultimately, TTN’s servers aren’t meant to support private off-air testing anyway, but only the shared public network.
Get the customer to spin up a chirpstack interface and work with that, it’s not hard.