Frequency in EU868 RX1 downlink does not match uplink

End Devices (Nodes)
1

I have problems with sending confirmed packets.
when I send a packet, the answer is correct except the frequency convention: same frequency, + data rate for response, I get back a different frequency.
the timestamp + 1000000 used with immediate = false ist correct, it falls into the first rn2483 window.

example:

JSON up: {"rxpk":[{"tmst":621008780,"time":"2018-03-09T07:55:30.443603Z","chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF8BW125","codr":"4/5","lsnr":8.3,"rssi":-17,"size":25,"data":"gCsUASYAAAAD0tZkFIJQe3hUyIGv298vvA=="$

answer:

Info [receive] length 181, {"txpk":{"imme":false,"tmst":622008780,"freq":867.1,"rfch":0,"powe":14,"modu":"LORA","datr":"SF8BW125","codr":"4/5","ipol":true,"size":12,"ncrc":true,"data":"YCsUASYgAwAnJ0er"}}

An explanation I have:
the rn2483 sends several packets with different frequencies an some packets are lost?

2

For EU-868 it should indeed be the same, for RX1. Are the region settings in your application okay?

Why would you think that is happening? What does TTN Console show you for the uplink(s)?

3

Looking at backend logs filtering by DevAddr around that time, I see the following:

time                gateway_id           f_cnt bandwidth spreading_factor frequency  payload_length rssi snr
----                ----------           ----- --------- ---------------- ---------- -------------- ---- ---
2018-03-09T07:55:22 eui-b827ebffffac52bf 0     125       7                868500000  25             -73  -4
2018-03-09T07:55:22 eui-b827ebffffac52bf 0     125       7                867700000  25             -75  -3.3
2018-03-09T07:55:22 eui-b827ebffffac52bf 0     125       7                868100000  25             -17  9.8

Looks like your gateway is receiving messages from that device on multiple channels, so there’s either something very wrong with your gateway or you’re just too close to your gateway.

1 Like
4

Just curious: would all those show in TTN Console?

5

Yes, they should show up like that in both gateway traffic and application traffic metadata.

6

I found the cause. When sending the confirmation packet from Concentrator to device I check the status of the Concentrator before sending. I did only send confirmation telegrams when status was TX_FREE. In most cases the status was TX_SCHEDULED so without confirmation the RN2483 does retransmits on other frequencies. Now I send even if status is TX_SCHEDULED and all works fine.

7

On the exact same time, in microseconds, "tmst":621008780? Weird.