RAK7267 Multi-SF demodulator fault

LPWAN Industrial Gateways / Concentrators
1

Hey all,

I’ve got a RAK7267 (SOHO Pro) that I’m fairly sure has a faulty concentrator, but posting here before I go through support in case anyone has seen this.

Setup: private (non-LoRaWAN) network, LR1110-based nodes (Seeed T1000-E), NZ 915–928. 8 multi-SF channels 916.0–917.4 at 200 kHz, std channel 916.8 SF10/BW250, WisGateOS_2.3.1_RAK. Everything on the std channel works perfectly. Any SF10/BW125 uplink on a multi-SF channel: detected but never decoded — rxnb counts it, rxok stays 0, basically 100% CRC fail. I’ve tried −30 through −70 dBm, private AND public sync word, both radios, three different channels. Node TX verified clean on an SDR (carrier +0.8 kHz, occupied BW bang on 125 kHz, no spurs).

The kicker — I stopped the packet forwarder and ran the Semtech test tools that ship on the gateway itself in /usr/bin/sx130x:

./test_loragw_hal_rx -u -d /dev/ttyACM0 -r 1250 -k 0 -a 916.8 -b 917.1 -m 1 -n 8 -z 16

(-m 1 parks all 8 channels on 916.4, right where my node transmits, ~−40 dBm)

It detects the packet on up to SIX chains at once, SF right (datr: 10), RSSI right, SNR right (+9…10)… and every single one comes out size: 0, codr: 0 with “ERROR: wrong coding rate (0)” spam. Two minutes of beacons every 10 s = 0 CRC OK. Meanwhile if I point chan_Lora_std at the exact same freq/SF/BW it decodes 100% all day, simultaneously.

test_loragw_reg passes both sweeps, so the register interface is healthy — whatever this is, it’s behind the registers.

Has anyone seen a multi-SF bank do this while the std path works? Or is this as dead as it looks? Keen to hear if there’s something I’ve missed - this thing has had three days of my life!

Cheers!

2

Hi @MattJam12
Thank you for the detailed explanation and thorough analysis!
Could you share:

  1. Which library/driver you are using for the LR1110 (e.g., RadioLib, Semtech LoRa Basics Modem)?
  2. The end-device configurations currently set in your code for:
  • sync_word
  • header_type
  • coding_rate (cr)
  1. Do you have an older SX1262 or SX1276 LoRa device available that you could test against the same multi-SF channel configurations?

BR

3

Heya @velev,

Thanks for taking a look - answers below.

Driver: Semtech’s official LR11xx driver, SWDR001 v3.0.0, vendored verbatim (no modifications to the Semtech sources), with a thin shim of our own to bind it into Zephyr. Not RadioLib and not LoRa Basics Modem - the radio is configured through direct lr11xx_radio_* calls.

End-device config on the failing tests:

  • sync_word: private, 0x12 (lr11xx_radio_set_lora_sync_word(0x12); our SX1262 bench receivers use the equivalent 0x1424) — and importantly, I re-ran the whole test with public 0x34 on both ends and the failure is identical, so it’s not a sync-word mismatch
  • header_type: explicit (LR11XX_RADIO_LORA_PKT_EXPLICIT)
  • coding_rate: CR 4/5
  • Also: CRC on, standard (non-inverted) IQ, preamble 16 symbols, SF10/BW125, 45-byte payloads, measured carrier offset at the gateway ≈ +1.3 kHz (~1.4 ppm)

SX1262/SX1276: no SX1276 on hand, but I do have SX1262s (RAK13300/RAK13302 modules and a RAK4631). Happy to run the exact same multi-SF channel test with an SX1262 as the transmitter and post the result?

Cheers, Matt

4

HI @MattJam12 I will highly apriciatte to run the same tests with any of the SX1262s units.

5

Hey @velev

SX1262 control test done **the gateway detected zero of ~13 on-air-verified SX1262 beacons

Setup: RAK4631 (nRF52840 + SX1262, Zephyr loramac-node driver — different silicon AND different driver stack from my LR1110 node) sending the identical 45-byte frames: SF10/BW125, 916.400 MHz, private sync, CR4/5, explicit header, CRC on, every 10 s, antenna fitted, a few metres from the gateway. RTL-SDR watching the whole time.

What the SDR proves was on the air (burst analyzer, one row per burst):

t=  5.96s dur= 642ms center= 916.401500 MHz  bw~124.0 kHz
t= 16.11s dur= 642ms center= 916.401500 MHz  bw~125.0 kHz
t= 26.26s dur= 642ms center= 916.401500 MHz  bw~124.0 kHz
t= 37.27s dur= 642ms center= 916.401750 MHz  bw~124.5 kHz
t= 47.42s dur= 642ms center= 916.401500 MHz  bw~124.0 kHz
t= 57.57s dur= 642ms center= 916.401500 MHz  bw~124.0 kHz
t= 67.72s dur= 642ms center= 916.401500 MHz  bw~124.0 kHz

642 ms is the exact SF10/BW125 airtime for 45 bytes. Carrier +1.5 kHz. Occupied BW bang on 125 kHz. No spurs above the −43 dBc modulation skirt.

What the gateway did with it** (test_loragw_hal_rx -m 1, all 8 chains on 916.4, fresh start, 2¼ min): 58 packet blocks — 56× datr:5 and 2× datr:6 noise phantoms, ZERO datr:10, 0 CRC OK. No detection of the control signal.

Tests so far:

Run TX Signal at gateway Detected Decoded
1 LR1110, preamble 16 −40 dBm, dead-centre every beacon, up to 6 chains all size:0 codr:0
2 LR1110, preamble 8 −40 dBm 2 beacons (4+6 chains) → then SF10-deaf 5 min all size:0 codr:0
3 SX1262, preamble 16 bench distance, SDR-verified clean zero of ~13 —
ref random neighbour’s AU915 SF12 uplink −107 dBm, SNR −18 all 8 chains header parsed fine: codr 4/5, size 64
ref thermal noise −110 dBm constant SF5 “packets” some even pass CRC

Raw blocks, side by side - same gateway, same hour. My clean −40 dBm SF10 beacon:

  size:     0          <- nothing
  datr:     10         <- SF classified correctly
  codr:     0          <- invalid (not a transmittable value)
  freq_hz   916400000
  snr_avg:  9.0        <- perfect SNR
  rssi_chan:171.0      <- ~ -40 dBm

A random stranger’s public SF12 uplink at the sensitivity floor, same channel:

  size:     64         <- full header parse
  datr:     12
  codr:     1          <- CR 4/5 read correctly
  freq_hz   916400000
  snr_avg:  -17.8      <- at the SF12 demod floor
  rssi_chan:101.0      <- ~ -107 dBm

So the multi-SF bank reads a whisper from a device it’s never met, seems to hallucinate SF5 packets out of thermal noise, and produces nothing from a clean, strong, dead-centre signal — from either chip vendor — and it’s got progressively worse across the evening (detect-all → detect-2-then-deaf → detect-0). That also matches the good/bad ratio drifting over hours from my first post.

Meanwhile the std channel (chan_Lora_std) still decodes these exact frames 100% when configured to the same freq/SF/BW.

Lawd help me I have no idea if i’m looking at this completely wrong or if I have something configured weird but i’ve tried everything I can think of.

Cheers, Matt

6

So on a fresh set of eyes…

Our (non-LoRaWAN) nodes were transmitting 16-symbol preambles. The SX1302/03 multi-SF demodulators won’t header-decode BW125 frames with preambles longer than the standard 8 - they detect fine (correct SF/RSSI/SNR) then output the size:0/codr:0 husks from my earlier posts.

Tested it with a matrix cycling preamble/payload-size/TX-power: preamble 16 = 0% decoded on BW125, preamble 8 = 100% — power and length irrelevant.

Flipped the fleet to preamble 8 and all 8 multi-SF channels now decode at 100% on the same gateway. (The std channel never cared — different demod — which is what made it look like broken hardware.)

Two traps for others: preamble > 8 on a private network mimics a dead concentrator at BW125; and test_loragw_hal_rx hardcodes lorawan_public=true, so it can’t test private-sync nodes as-is.

So looks like it might be ok! I’ll get back to you soon.

7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.