KR920 SF5/SF6 (DR12/DR13) reception support on RAK7289V2 and RAK7268V2

LPWAN Industrial Gateways / Concentrators
1

Hello RAKwireless team,

I am testing the KR920 LoRaWAN data rates introduced in LoRa Alliance Regional Parameters RP002-1.0.5, released in October 2025:

  • DR12: LoRa SF6 / 125 kHz
  • DR13: LoRa SF5 / 125 kHz

My end device is a RAK3172 with my own firmware. Test uplinks use KR920 at 921.9 MHz, BW125, CR 4/5, explicit header, CRC enabled, normal IQ, a 12-symbol preamble, and sync word 0x12 for SF5/SF6.

RP002-1.0.5 explicitly specifies the LoRa PHY sync word by spreading factor: SF7 through SF12 use 0x34, while SF6 and SF5 use 0x12 (Table 112, LoRa physical layer settings). This is the LoRaWAN PHY configuration defined by RP002-1.0.5, not a proprietary/private-network setting.

Results:

  • RAK5146: SF5 and SF6 uplinks are received correctly when running the Semtech sx1302_hal packet forwarder directly.
  • RAK7289V2: SF5 and SF6 uplinks are not received at all.
  • RAK7268V2: SF5 and SF6 uplinks are not received at all.
  • Both RAK7289V2 and RAK7268V2 were tested with their latest available firmware.
  • With the same frequency and other PHY settings, SF7 uplinks are received normally on all tested gateways.

The issue occurs at the gateway packet-forwarder/RF reception stage: no local uplink packet is reported for SF5 or SF6 on RAK7289V2 and RAK7268V2.

Could you please clarify:

  1. Do RAK7289V2 and RAK7268V2 support SF5/SF6 reception at 125 kHz bandwidth?
  2. Does their gateway software support the RP002-1.0.5 SF5/SF6 sync-word rule (0x12)?
  3. If support requires a specific packet forwarder, concentrator configuration, or firmware build beyond the current latest release, could you provide the required steps?
  4. If this is not currently supported, is there a plan or timeline to support KR920 DR12/DR13 defined in RP002-1.0.5?

Thank you.

2

Hello @jsjeong ,

Which LNS are you using to test?
WisGateOS built in LNS is using RP003.

Regards,
Nikola Semov

3

Hello @Nikola,

Thank you for your reply. For clarification:

  • The LNS is the latest ChirpStack version, not the WisGateOS built-in LNS.
  • RAK7268V2 and RAK7289V2 are used only as packet forwarders connected to ChirpStack. Their built-in LNS is not used.
  • I am not aware of a published LoRa Alliance Regional Parameters document named RP003. The latest published Regional Parameters specification is RP002-1.0.5.
  • ChirpStack supports RP002-1.0.0 through RP002-1.0.5. Its Device Profile can be configured to allow the additional SF6/SF5 data rates, in addition to SF12 through SF7.

The question is whether RAK7268V2 and RAK7289V2 support receiving SF5 and SF6 at 125 kHz bandwidth. SF6 and SF5 are additional LoRaWAN data rates defined in RP002-1.0.5.

In my test, SF5/SF6 packets are not reported by the local packet forwarder on RAK7268V2 and RAK7289V2, while SF7 packets with the same frequency and other PHY settings are received normally. The same SF5/SF6 configuration is received successfully by a RAK5146 running the Semtech sx1302_hal packet forwarder directly.

Could you please confirm whether the current RAK7268V2 and RAK7289V2 packet-forwarder/concentrator firmware supports SF5/SF6 reception? If not, is support planned?

Regards,
Jongsoo

4

Hello @jsjeong ,

Sorry, my bad; it is a typo. I meant to write RP002-1.0.3.

RAK5146(which is used in both gateways) supports SF5 and SF6 as hardware, and the HAL(v2.1.0) version that they use supports it.
Can you send me system logs in DEBUG mode (while you have uplinks on SF5 and SF6)?
Also, can you see the uplinks on SF5 and SF6 in the packet capture?

Regards,
Nikola Semov

5

Hi @Nikola ,

Thank you for the clarification. I tested again with DEBUG mode enabled on a RAK7268V2.
I configured the RAK3172 to transmit one SF5 packet every second with the private syncword. The LoRa LED on the RAK7268V2 blinks for each transmission, and the gateway DEBUG logs repeatedly show the following:

Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=md evt=queue_update
Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=md evt=dispatch_event event_id=0 module_id=1
Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=gwBridge evt=udp_pkt cmd=0 len=384 gw_eui=ac1f09fffe08d587
Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=gwBridge evt=gw_seen proto=1
Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=gwBridge evt=push_data len=372
Wed Sep 16 04:23:35 2026 daemon.warn lora.ns[23722]: com=gwBridge evt=downlink_format sf=5 rc=220503
Wed Sep 16 04:23:35 2026 daemon.warn lora.ns[23722]: com=gwBridge evt=uplink_parse sf=0x00 rc=220506
Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=gwBridge evt=generate_uplink_protobuf msg=protobuf_size size=230
Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=mqttEv evt=publish com=[gwBridgeS Mqtt Client] plen=230 payload=" }"
Wed Sep 16 04:23:35 2026 daemon.debug lora.ns[23722]: com=mqttEv evt=logger desc='[gwBridgeS Mqtt Client]' msg='Client gwbridge-ac1f09fffe08d587 sending PUBLISH (d0, q1, r0, m5590, 'kr920/gateway/ac1f09fffe08d587/event/up', ... (230 bytes))'
Wed Sep 16 04:23:35 2026 daemon.info lora.ns[23722]: com=mqttEv evt=publish topic=kr920/gateway/ac1f09fffe08d587/event/up plen=230 qos=1

I also tested Packet Capture mode. With SF5, an error repeats continuously. At approximately 00:50 in the attached video, I change only the spreading factor to public SF7 while keeping the same frequency and other PHY settings. From that point onward, packets are received normally.

The RAK7268V2 is running the latest firmware.

Packet Capture video:

https://coxlabinc.sharepoint.com/:v:/s/RD/IQBp_qbMLUlhQpOTVMmncs2WAWYxwbzOwpuA3EtV_1YD_t4?e=RcYrca&nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D

Could you please check this behavior on the current RAK7268V2 and RAK7289V2 firmware and confirm whether SF5/SF6 reception is expected to work?

Regards,
Jongsoo