Custom frequency plan

Is it possible to use a different frequency plan other than the standard TTN? I use the one for EU (Denmark), and want to change it from

channel 0: 868100000 (868.1)
channel 1: 868300000 (863.3)
channel 2: 868500000 (868.5)
channel 3: 867100000 (867.1)
channel 4: 867300000 (867.3)
channel 5: 867500000 (867.5)
channel 6: 867700000 (867.7)

to e.g

channel 0: 868100000 (868.1)
channel 1: 868300000 (863.3)
channel 2: 868500000 (868.5)
channel 3: 868700000 (868.7)
channel 4: 868900000 (868.9)
channel 5: 869100000 (869.1)
channel 6: 869300000 (869.3)
channel 7: 869500000 (869.5)

I think I probably will have to both configure my gateway and end device to use the new frequencies? I have tried do it on a SODAQ ExpLoRer, but it seems that every time I join OTA, TTN will overwrite my settings. The reason I want to change it, is because I have a lot of interference from RFID which is using 865.6 Mhz - 867.6 Mhz

You should look at tracking down the RFID problem as TTN is based on us all using the same frequencies across a region.

It’s not really possible. It’s allowed to transmit with up to 2W

I have made this plot that shows where the channels are


The way we are trying to solve this, is to make them turn off the 2 right channels and then move our 5 channels to end of of the spectrum.

Have you asked?

Do they really need to pollute the local airwaves at full power or did they just get it installed without any thinking - it is a shared spectrum after all.

Have you tried with a higher DR to see what the uplink loss actually is - the longer chirps may well bypass some of the interference.

Any change to the normal channels is going to take you off the TTN plan …

They are using it to track beds at a Hospital. I think they have it mounted in the doors/ceilings, so it need a certain amount of power to reach the beds. I don’t think they ever thought about it, but it’s also strange that the EU has approved it to begin with.

So what you are saying, is that if we use a custom channel plan we can’t use TTI even though is part of 863-870 Mhz spectrum?

Not while using TTN. It wouldn’t make sense as other gateways in the region are using the TTN plan and your nodes and gateway would not match the community network settings effectively becoming a separate LoRaWAN network.

That’s the plan. We are setting up our own gateways (indoor) at all locations (right now), where we are using our sensors. We are not dependent on using other gateways other than our own.

We have our own NS on TTI

This ETSI-standard is made for RFID-systems and has imho nothing to do with SRD or LoRaWAN. The standard, the frequencies and the power described there is not applicable for the devices we use.

@wolfp, these are the regulations that are causing local interference.

So if it’s in the regulations and it’s not on TTN, then I guess you can do as seems best.

Or you could talk to the hospital about their pollution of the local airwaves to see what happens.

You are right. The interrogator-channel 13 is the same as our uplink-channel 6. This could cause some incompatibilities in the future.

I don’t really think they understand it or maybe not care. They just want a system(s) that works. The challenge is, if the company decide to move their RFID system to other hospital/locations where we already have sensors installed. Then we are gonna have the exact same problem again.

So just to be clear, it is technical possible to use our own custom frequency plan on TTI within the 863 - 870 Mhz spectrum (if we don’t care about using other gateways, other than our own) ?

So now would be a good time for a friendly approach - at worst they just tell you to go away, at best they work with you and turn down the power. I’m just the guy that thinks it’s worth an ask.

I’m not a lawyer - @kersing or @Jeff-UK would be other non-lawyers but understand gateways better than me.

It’s the hospital (customer) that don’t understand it (I think). We are already having meetings with the company who has installed the RFID system, to see if we can find a solution. The plan atm. is to make them turn off 1-2 channels (if they don’t need them) and then move our 5 channels on the left to the end of the spectrum. Hopefully this will give us enough room, that there won’t be too much interference in the future.

You will have to ask TTI. We can’t speak for them.

I though TTI just was an enterprise version of TTN. Are they both not using The Thing Stack? If I’m using an end device set up on TTN, I can still use a gateway connected to TTI.

The use of higher powered RFID in this band has been a potential issue and known problem for at least 8-10 years that I can remember - it’s a shared spectrum after all for ISM use cases. Most commonly I heard of this in the context of gantry entrances -big enough to scan vehicles - vans and trucks where the reach demanded such a high power to excite the tags and allow detection. Is this a ‘real world’ problem @JakobDTU or are you trying to head off a theoretical/potential problem? This sounds bit like someone ‘adopting’/‘adapting’ to the door based monitoring location…where frankly such high power isn’t needed or justified so 1st approach should be to ask (nicely) for the RFID installer (who may not be cognisant of consequences) to dial down their Tx power. Also if nodes/gw for LoRaWAN are far enough away from the RFID station then even though channels overlap it should be possible for the devices and gw to discriminate the LoRaWAN modulation and still pick up the datagramme. It all depends on proximity and power…you should be good if LoRaWAN even in the noise provided you can get somewhere better than 20-22db margin vs the interferer. Can you position your nodes to get a bit more separation for yourselves? I assume the hospital is mutual customer? Even getting the other end of a corridor or other side of absorbers such as walls can help. Without conducting a detailed and precise wireless survey and heat map it’s a challenge to debug such installations.

Going custom in a private instance is one way to solve - given availability to you of spectrum in the band - but takes you away from standards and even the L-A implementation recommendations, which can cause other problems in the future. Personally I would always look to resolve at source…even if they need to provide additional screening to shared environment away the immediate doorway RFID environment. Basic principle is the interfering organisation has the responsibility to ‘fix’ for a shared resource…just because legally you ‘can’ does not mean socially you ‘should’ and it may be that you need to get the hospital onside to re-enforce this message…how will the hospital deal with the next problem this system causes? You might also want to ask how any patient/monitor moved through the doorway on a bed with say a 7 or 12 wire ecg unit attached and or (or staff!) pacemaker fitted handle this higher powered doorway (in reality quite resilient) but remember rf noise is additive and can only increase over time so best the hospital enforces mitigating measures now, right? :wink: principle (again) should be set to use enough power for the task, not the max allowed (as per good practice for all RF devices :slight_smile: )


Only if that TTI has packet forwarding setup / turned on AND everyone is on the same channels.

Yes both use the same base, however TTI enables features not available on TTN. I haven’t checked the V3 code but in V2 certain changes to a channel plan required code changes. TTI would know if that applies to V3 as well and whether they would be willing to offer services based on alternate channel plans with the required changes in the backend.

It’s not a theoretical problem, but a real problem right now that we have at one of our installations. I’m not sure what their Tx power is atm., and if it’s possible to lower it. They are of course not transmitting with 2w, but only within the limit of what is allowed at a hospital (because of pacemakers etc.). We did a RF spectrum analysis outside the hospital at the parking lot, and you could clearly see the 4 channels.


It’s not possible to move our nodes, because they need to measure at those exact locations. All of our nodes are using batteries, and it is draining our batteries really fast because of low data rate.