Why is RX_SLOT 1 not used?

TTN Network and Services
1

I created a simple gateway that can handle sending messages to nodes (download).

Right after the gateway has sent a rxpk message to the router, the router sends back a txpk message.

sent: {"rxpk:{“rssi”:-71,“stat”:1,“modu”:“LORA”,“rfch”:0,“tmst”:162072576,“datr”:“SF9BW125”,“lsnr”:-52.25,“time”:“2016-06-30T23:22:51.866064Z”,“codr”:“4/5”,“data”:“QHBhYUqABgABrMV/bv6WmQHDDT9bH4AjAzE=”,“freq”:868.099976,“chan”:0,“size”:26}]}

received: {“txpk”:{“rfch”:0,“modu”:“LORA”,“freq”:869.525,“data”:“YHBhYUoAAgABj9/clY414A”,“ipol”:true,“powe”:27,“codr”:“4/5”,“datr”:“SF9BW125”,“tmst”:164072576,“size”:16}}

I would expect the network to send a txpk for the first RX_SLOT first. This package should use the same frequency and data rate as the message received. The gateway doesn’t get that message.

The tx packet that is received is targeted at the second RX_SLOT: exactly two seconds after receiving the last byte (rxpk.tmst + 2000000) and using another frequency (869.525 Mhz instead of 868.1Mhz)

Why doesn’t my gateway get a txpk for the first slot?

2

This is done on order to save transmit-time on the gateway size or as it stated in this issue “for scalability reasons”.

The Rx2 channel has a 10% duty cycle limit whereas the other channels have a 1% duty cycle limit (per sub-band).

If the data rate is fast enough, the txpk used to be on the same channel - this might still be the case. But packets with a lower data rate will get the response on the Rx2 channel.

I am not sure if I agree with this; nodes that are on the edge of a gateway’s range may need to use SF12 in order to reach the gateway and since the gateway uses the same transmit-power there is a chance that a message send using SF9 can not be decoded by my node.
But I see why this is done. Messages send using SF12 will take 1-2 seconds and this will very quickly have gateways run out of transmit time.

3

That would indeed be a problem. Therefor, in RX2 we transmit at 27 dBm, and the increase in power (over the 14dBm uplink) offsets the loss of sensitivity going from SF12 to SF9.

2 Likes
4

But at Regional parameters, ex) EU863-870, Rx2 windows is fixed with 869.525MHz / DR0(SF12, 125KHz)
So, i checked the duty cycle of 869.525MHz.
At EN300.220, duty cycle of range with 869,400 MHz to 869,650 MHz doesn’t commented.

Q1. How can i know duty cycle of 869.525MHz is 10%?

if it is true,

Q2. isn’t Duty cycle adjusted at node’s Tx? What means of

5

Meanwhile, the preference has changed:

And like discussed above, for RX2 TTN uses SF9 (along with a higher transmit power), which is better than the default of SF12. (For OTAA Join Accepts, the LoRaWAN defaults are used as then the nodes don’t know any specific settings yet.)

6

In Slack, someone wrote that many gateways only support 20 dBm:

mco June 6th at 11:25 AM

Hello, it seems that by default, the network server expects a gateway to support 27dBm as its max output power. But it is not the case for all gateways, many of them only support 20dBm max.

Wouldn’t it be interesting to be able to specifiy gateway capabilities when registering one?

Or do you expect the gateway to use the closest output power it supports?

…

I understand the rational behind, but still, if the gateway cannot handle it, it is useless to ask it to use this output power. For example the first version of the Kerlink gateway only supports up to 20/22dBm.

It can be handled at the gateway side, use the closest available power to the one requested.

But I think it would be fair to have this kind of configuration available when registering a gateway, so that for example, the Network Server, could also select the gateway to be used for downlink based on this info? (even though it can be difficult to arbitrate between the gateway which has the best RX RSSI, and the gateway which has the best output power capability. :))

7

I also don’t understand how the 27dBm transmit power maintains compatibility with the (EU) legal restriction of max 14dBm transmit power in the 868MHz band. If I wouldn’t know better, I would conclude the TTN RX2 implementation breaks EU legal compatibility by design :confused: .

8

I guess this is about the line:
K1 869,400 - 869,650 MHz 500 mW e.r.p. 25 kHz2 < 10 %3
in https://www.agentschaptelecom.nl/sites/default/files/brochure-vergunningsvrije-radiotoepassingen.pdf ?

See also the wiki (band g3), or the forum, or Microchip

9

Ha, didn’t know about that tiny slice of spectrum there. Thanks :blush: .

10

Have a look at http://www.etsi.org/deliver/etsi_en/300200_300299/30022001/02.04.01_40/en_30022001v020401o.pdf
This is the official ETSI EN 300 220-1 specification. Page 29 of this document contains a table with all sub-bands within the 868 MHz band. The normal channels are spec’d at 25 mW (14 dBm) and the Rx2 channel at 500 mW (27 dBm).

Also have a look at page 30 where the term ERP is explained.
ERP is the Effective Radiated Power - note the word radiated. This means that this is not the output power of the transmitter but the output power of the antenna.

There are antennas with a 4 - 9 dBi gain. This means that the received signal has a gain of 4-9 dBi also giving you a larger usable distance between gateway and node. But this also means that your gateway must use less power while transmitting. A gateway with an antenna with 9 dBi gain may only use 5 dBm for the normal channels and 18 dBm for the Rx2 channel.

So although the received signal has a 9 dBi gain, the transmitted signal does not (or to be correct: is not allowed to …). This means that the chance that the gateway receives a perfectly good join request, the join response send by the gateway may never reach the node.
By using the Rx2 channel with a much higher power, the node will most likely receive the join response.

Using Rx2 instead of Rx1 therefor does make sense if you are looking at increasing the range of the gateways. As a positive side effect, the duty cycle on this channel is 10%, meaning that one gateway can handle 10 times the amount of join requests or downlink messages.

Rob

3 Likes