Downlink Freq RX2 // 869.525

Gateways
1

I was working on some downloads packets and have some results which I am puzzled about :slight_smile:

Setup

  • ABP node
  • Downlink message queued
  • Send uplink message (SF9)
  • Following downlink message received (as expected message is send on SF9 / 869.525)
{
  "gateway_id": "eui-b827ebfffee8c133",
  "config": {
    "modulation": "LORA",
    "data_rate": "SF9BW125",
    "counter": 122,
    "frequency": 869525000,
    "power": 27
  }
}

Now when I change the SF of the uplink messages (e.g. to SF7 / SF8) the gateway starts to send the downlink messages as follows (some examples below):

{
  "gateway_id": "eui-b827ebfffee8c133",
  "config": {
    "modulation": "LORA",
    "data_rate": "SF7BW125",
    "counter": 123,
    "frequency": 868100000,
    "power": 14
  }
}

{
  "gateway_id": "eui-0003ffff1d09ce86",
  "config": {
    "modulation": "LORA",
    "data_rate": "SF8BW125",
    "counter": 131,
    "frequency": 868100000,
    "power": 14
  }
}

The downlink now seems to send on 868.1? I have verified above with 2 different gateways - any idea where this comes from? For me it is not 100% reproducable ā€¦

2

TTN indeed uses 869.525 with SF9 and 27 dBm high transmission power for RX2, and in the early days preferred RX2. However, nowadays it prefers RX1:

RX1 uses the same settings as your last uplink, and regular 14 dBm transmission power. So, despite the title of your post, I assume youā€™re seeing RX1 in the last two examples above (and indeed RX2 in the first example).

2 Likes
3

Thanks for your reply. Indeed looks like RX1 (same SF, same freq) is used.

So today RX1 and RX2 are both used at TTN (and RX1 is preferred for reasons as mentioned above).
Is there a criterium when which RX window is used?

Anyhow I need to activate the node to listen in both windows (RX1 / RX2).
I will use ā€œreceive_delay1ā€ (1sec) and ā€œreceive_delay2ā€ (2sec).

4

Whatever seems to be used most often, it will (one day) also depend on the availability of gateways which have not exceeded their duty cycle yet. In other words: itā€™s something the TTN backend decides, and could change any timeā€¦

(I could imagine that SF7 and SF8 uplinks get downlinks in RX1; for SF9 it could be either RX1 or RX2, maybe also dependent on the uplink channel; for SF10 and up, RX2 seems more efficient, but then it can only use one channelā€¦)

5

@arjanvanb, does TTN in fact send a downlink confirmation from the network to the mobile device after each uplink, even if there is no ā€˜userā€™ downlink message? Like KPN does, so to say.
If TTN does, Iā€™m having a very hard time receiving it :sweat_smile:
I have a device that works perfectly well on the KPN network, receiving in RX1 and RX2. It follows the guides of the KPN network, i.e. in RX1 (1 sec delay), reception in the same channel as the uplink with an RX1DRoffset of value 3, and in RX2 (2 sec delay) on 869.525 MHz with RX2DataRate = SF12.
With these settings I receive absolutely nothing on TTN (sending SF12 to stay away from the RX1DRoffset uncertainty). I doublechecked my own gateway, the port forwarding on my network, etc. Everything seems fine and in the end I jumped in my car to test with other gateways surrounding mine. Same result.
Now I found out from this thread that TTN uses a SF9 on RX2. This still doesnā€™t explain why I didnā€™t receive anything in RX1, but anyway, I changed the setting for RX2 and still nothing.
Am I missing something here???

6

Absolutely not. That would be a colossal waste of airtime and does not scale in any way. (Gateways are subject to the same legal airtime restrictions)
I have a hard time believing KPN does this. I think the code for your KPN node uses confirmed uplinks, instructing the network to send confirmation. (Confirmed uplinks work on TTN by the way) keep in mind both KPN and TTN consider acknowledgments a downlink which eats into your budget.

7

@kersing, well if you use ADR, which KPN says you should, you always get this confirmation with the MAC command LinkADRReq in it. And while they are at it, KPN also packages other MAC commands like NewChannelReq and RXTimingSetupReq in this downlink. I donā€™t think this counts as a downlink for the budget because otherwise we would vastly outrun our bundle each month (which we donā€™t), and itā€™s just not logical.
How is a mobile node otherwise supposed to learn about settings and parameters that the network uses? Look at my case: I have to read here in the forum that RX2 uses SF9, where KPN just broadcasts this information in the downlink confirmation in MAC command RXTimingSetupReq.

About these confirmed uplinks: how do you request a confirmed uplink on TTN?

8

By using OTAA where all the information is provided when you get your session keys and node address.

From This ADR explanation :

LinkADRReq
This is 4 bytes long MAC command transmitted by network to request node to change itā€™s transmit parameters.

So you are getting new parameters for every uplink? May-be the code on your node needs tuning?
As I mentioned in my previous message, a gateway sending some kind of response for every uplink does not scale due to airtime limits for the gateway. And it is worse when using SF12 for those transmissions, it means the gateway canā€™t send for 10 seconds after each previous transmission. So the gateway can only ā€˜supportā€™ uplinks from 6 nodes a minute. Doesnā€™t make sense to me.

1 Like
9

Your node initiates confirmed uplink, you canā€™t request it from network side. (At least not without adding your own program logic to the node software)
How to request it on the node depends on the hardware and LoRaWAN stack used. The RN module protocol requires specifying confirmed/unconfirmed uplink when sending data. LMIC send command has a parameter for confirmed or unconfirmed.

10

I did a quick check with the spectrum analyzer, and the gateway does in fact confirm every uplink with a downlink reply in RX1 or RX2. Interesting thing is that it didnā€™t matter if I sent the uplink with MAC header 0x40 (Unconfirmed Data Up) or 0x80 (Confirmed Data Up). ADR was off in this test.