Kerlink Downlink Problems in RX2 / Link Budget Calculation


(Faehrlich) #1

Hello everyone,

I am testing an end-device at the moment which is only able to reach the gateway when using SF12 (due to the distance and obstacles between them). Due to the TTN characteristics the corresponding downlink is not sent using SF12 as well as the uplink but instead is sent in the RX2 Window using SF9 and TX Power 27. This setting is correctly transmitted to the gateway (tcpdump shows powe: 27 for the received downlink) but the end-device is not able to receive the downlinks.

Regarding the setup:
I use a Kerlink gateway and a Feather board as end-device.

There are some other similar posts in this forum but non of them really helped me solve the problem.

Do I need to configure the end-device in a specific way to be able to receive the downlinks?
Or must I configure the gateway to make sure that the TX power is actually changed to 27?
Or is there another way to solve this problem?

I’m looking forward to any kinds of hints.

Greetings


Faulty LNA configuration leading to Kerlink downlink problems
(Jac Kersing) #2

As you observed TTN uses SF9 for RX2. If the node is unable to receive the data even at the higher transmission power the only solution would be to:

  1. try to improve the reception path (reposition node or gateway so a better path can be found)
  2. use a better antenna for the node

If both are impossible you are out of luck afaik.


(Faehrlich) #3

Thanks for the answer.

Regarding this, is there a way to make sure that the gateway actually transmits with the higher transmission power other than having a look at the downlink packages in the gateway’s tcpdump?

And furthermore is it designated by TTN that the downlinks are only sent in the second RX window? Or is there a possibility to trigger TTN to sent an anwser in RX1 using the SF of the uplink?


#4

What packet forwarder do you use?

What are RX2 setting on your end device now?


(Jac Kersing) #5

Depending on the packet forwarder used and its features that information might be visible in debug output if you are able to configure the software to show debug output. However, if you observed it with tcpdump and the signal strength of the incoming packets are not far better (making the back-end assume it can use less power) TTN will instruct the gateway to use maximum allowed power for transmission.

Last time I checked the code, SF12 replies were never transmitted in RX1 as the frequencies for RX1 have 1% duty cycle where the RX2 frequency has 10% duty cycle. SF12 transmissions require a lot of airtime. The gateway would not be able to use the RX1 frequencies (those are all in the same band so fall under one 1% duty cycle) for well over a minute for a trivial SF12 transmission.


Configure Downlink Frequency of a Gateway
(Faehrlich) #6

I’m using the the TTN packet forwarder (this one) as described in the Kerlink TTN Setup.

The RX2 value is set to SF9.


(Faehrlich) #7

After evaluating the given conditions I still can’t understand the fact that the downlinks are not received.

The RX2 value of the end-device is set to RF9. Testing the setup with a smaller distance in between is working.

By contacting Kerlink I verified that the downlinks are actually sent using 27 dBm. Furthermore I calculated the link budget for uplinks from the node to the gateway (LNS) and for downlinks from the gateway (LNS) to the node. This shows that the uplink’s link budget is equal to the downlink’s link budget (using SF9).

Link_Budget

In my opinion this indicates that the distance should not cause the problem since the downlink should be able to bypass the same distance as the uplink and therefor the downlink should be received by the node. But this is not the case. The downlink is not received by the end-device.

Does anyone else had the same problem and knows a solution? Or is there a major error in reasoning, for example in computing the link budget?


(LoRaTracker) #8

Couple of things, forget about the RSSI in a link budget calc, relate everything to SNR. The quoted figures for sensitivity are unlikely to be achieved in the real world. The max quoted sensitivity for a LoRa device is -149dBm, that would imply that the LoRa device would be receiving signals at 40-50dB below noise level (as seen by the LoRa receiver), whereas the maximum performance is 20dB below noise.

Second, ignore the antenna gains, they are both in use for RX and TX so it matters little what their respective gains are.

So we are left with power and SNR.

SF9 has an SNR performance of -12.5dB
SF12 has an SNR performance of -20dB

So with a 7.5dB SNR difference the SF9 end should only need 7.5dBm more power than the SF12 end for a symmetrical distance link. In other words the SF9 end should only been to use 14dBm + 7.5dBm = 21.5dBm to reach the SF12 end.

However, its entirely possible that either end of the link is being impacted by locally generated EMI, either from other transmitters or power supplies or processors. This EMI could loose one end the the link the 5.5dB performance.


(Faehrlich) #9

But if this is the case shouldn’t the uplink be affected int the same way as the downlink? In other words, if the node isn’t receiving the downlinks due to EMI’s, shouldn’t the node’s uplinks be affected by the EMI’s as well?


(LoRaTracker) #10

No.

A small amount of EMI near the RX end could easily affect its sensitivity for receiving signals.

But the EMI near the RX end is not going to have any affect on the TX end as its too far away.


(Faehrlich) #11

I meant the uplinks from the same device (node). The node sends an uplink using SF12 (TX Power 14 dBm) which is received by the gateway. The gateway forwards the answer from TTN using SF9 and TX Power 27 dBm.
The node is not able to receive the downlink but the uplink can be received by the gateway. So the EMI only affect the nodes receiving ability but not it’s uplink ability?


(LoRaTracker) #12

Yes.

EMI is at least one possible cause of the link difference.


#13

if UL freq != DL freq, then…


#14

If I were you I’d try to get SNR/demod. margin from end node’s LoRa module for this smaller distance case


(LoRaTracker) #15

I don’t understand, could you explain ?

(I understand the ‘expression’ but not the implication)


#16

I meant, if, for instance, there’s a number of devices working in g3 subband close to the end node, uplink will not be affected by “locally generated EMI”.