RX2 receiving rate problem in CN470-510 frequency band

  1. Does the CN470-510 frequency plan and the rate of RX2 strictly adhere to the following frequencies?
    486.3 - SF7BW125 to SF12BW125
    486.5 - SF7BW125 to SF12BW125
    486.7 - SF7BW125 to SF12BW125
    486.9 - SF7BW125 to SF12BW125
    487.1 - SF7BW125 to SF12BW125
    487.3 - SF7BW125 to SF12BW125
    487.5 - SF7BW125 to SF12BW125
    487.7 - SF7BW125 to SF12BW125
    506.7 - SF7BW125 to SF12BW125
    506.9 - SF7BW125 to SF12BW125
    507.1 - SF7BW125 to SF12BW125
    507.3 - SF7BW125 to SF12BW125
    507.5 - SF7BW125 to SF12BW125
    507.7 - SF7BW125 to SF12BW125
    507.9 - SF7BW125 to SF12BW125
    508.1 - SF7BW125 to SF12BW125
    505.3 - SF12BW125 (RX2 downlink only)

2、Is RECEIVE_DELAY2 under the RX2 frequency under the TTN platform fixed at 2S or something else?

  1. Where did you get that list? If the list you’re showing matches the TTN documentation, then: yes, of course, so RX2 will be using 505.3 SF12BW125, like you can tell from your own screenshot below. If your list is different, well, then TTN is not using that. You’re the only one having problems with the devices and gateways you don’t want to give us any details about. You might want to try joining at a better data rate (lower SF). The problem is in your secret setup.

  2. Following the standard, that’s 1 second for RX1 and 2 seconds for RX2, except for an OTAA Join Accept, for which it is 5 seconds for RX1 and 6 seconds for RX2. If you read other topics about that then you’ll see that the 5 seconds in your screenshot from one of your many other posts is to be expected for RX2, if that’s what you’re wondering about. See Join Accept transmitted after 4 or 5 seconds, instead of 5 or 6?

    Join Accept in RX2

That’s all we can tell from the little details you keep giving us.

So, why are you asking about the frequency plans and RX2? Apparently you suspect something is wrong, so: why not share those thoughts instead of only asking about some (possibly) related details? If you want proper help then, rather than posting the same things every few days, please explain where you got the information and why you’re asking these things.

Like I linked to earlier: devices not receiving the Join Accepts has been discussed many times before, and asking again is useless. If you want help for your specific case, then you’ll need to give us a lot more details 1) about everything that once worked and everything that still works, 2) about what you tried in the past three weeks, 3) about all your hardware, and 4) about your setup in TTN Console, for applications (including the selected handler), devices, and gateways (including the selected router).

thank you for your reply

  1. I got this list in the TTN frequency plan. I guess that the ABP uplink is successful. You can see the uplink data on the TTN platform, indicating that the equipment and gateway can connect to the platform normally. However, the ABP downlink was unsuccessful and the OTAA mode was also unsuccessfully connected, indicating that the key to the problem should be the unsuccessful step of sending the platform’s downlink data to the gateway. Based on this idea, I want to see if the rate plan of the downlink data matches the rate plan of the gateway and the device.
  2. My location is in China. The selected gateway is Ruixing Hengfang’s RHF2S024-470MHz gateway. The equipment is a Lierda development board. (These are gateways and devices in China)
  3. My recent work includes modifying the frequency of the gateway and equipment to adapt to the TTN platform according to the frequency plan of the TTN CN470-510MHz. I found that the problems were the same after testing. OTAA has been unable to connect.











Maybe it arrives too late at the gateway, due to large network latency. What handler are the applications registered to? What do the gateway logs tell you? All your gateway traffic shows SF12; can you try to use a better data rate? (SF10 or lower increases the chances that TTN will use RX1 rather than RX2. Of course, both RX1 and RX2 should work.)

The sole facts that the ABP device’s downlink does not work, and that the OTAA join does not work, do not prove that the problem is related to sending the downlink to the gateway. Maybe the downlink arrives at the gateway perfectly in time, but the gateway does not support the settings that TTN wants, like see ERROR: Packet REJECTED, unsupported RF power for TX - 24. Or maybe the gateway is actually transmitting it just fine, and the node’s timing is not sufficient accurate. You cannot tell unless you can peek in the logs of the gateway or do some actual measurements using an RTL-SDR dongle.

Then I’d very much recommend an RTL-SDR dongle anyway.