Setup
- Gateway: RAK7289V2 (16-channel, 2× SX1302 concentrators exposed as USB CDC-ACM:
usb:/dev/ttyACM0= slave-0,usb:/dev/ttyACM1= slave-1). - Firmware: WisGateOS_2.2.14_RAK.
- Mode: Basics Station → external ChirpStack v4 LNS over
ws://(plain), region AU915, 16 uplink channels enabled (ch 0–15). - The unit has been stable for ~12 days; load average ~0.5 (not overloaded).
Problem 1 — One concentrator has ~18–20 dB worse RX sensitivity than the other
Verified with the same node (same TX power), whose frames hop across both concentrators:
| Concentrator | Channels / freq | Same-node RSSI | SNR |
|---|---|---|---|
slave-0 / ttyACM0 (rctx0) |
ch0–7, ~915.4–916.0 MHz | −80…−87 dBm | +11…+13 |
slave-1 / ttyACM1 (rctx1) |
ch8–15, ~917.6–917.8 MHz | −98…−103 dBm | +9…+11 |
Aggregate over ~700 recent frames: rctx0 avg RSSI −97 (best −63); rctx1 avg RSSI −115 (best only −87). rctx1 never hears a strong signal, even from near nodes — pointing to a degraded RX path on that concentrator, not node distribution.
Supporting data:
[RAL:DEBU] [read_slave_pipe]|slave_index=0, crc_ok=4830, crc_err=412, crc_non=12 (~8% CRC err)[RAL:DEBU] [read_slave_pipe]|slave_index=1, crc_ok=9250, crc_err=1320, crc_non=5 (~12.5% CRC err)
dmesg shows the other port (ttyACM0, usb 1-1.2) re-enumerated once, while the degraded one (ttyACM1, usb 1-1.3) has been stable:
[972522.0] usb 1-1.2: USB disconnect, device number 6[972522.4] usb 1-1.2: new full-speed USB device number 7 using ehci-platform
Also seeing frequent GPS/PPS time-sync rejections (~37%, 402/1083) and MCU/SX130x drift up to ±20 ppm:
[SYN:INFO] MCU/SX130X drift stats: ... max: +20.5ppm - threshold q90: -16.2ppm[SYN:VERB] Time sync rejected: quality=933 threshold=850
Q1: Is a ~18–20 dB RX asymmetry between the two SX1302 concentrators a known hardware/firmware issue? How should we isolate it (antenna cable/connector/pigtail on that concentrator, USB, or the SX1302 module)? Is any per-concentrator RX calibration difference expected?
Problem 2 — After a UI reboot then a full power-cycle, the gateway is up but won’t reconnect (no LNS, no admin access)
To try to recover concentrator 2, we rebooted from the WebUI. The gateway reconnected to the LNS for ~2 minutes, then dropped. We then did a full power-cycle. Since then (>40 min):
- No Basics Station connection to the LNS (gateway
last_seenfrozen; zero uplinks). - No remote admin access (WireGuard tunnel down).
- On site: network LED green, unit booted, stable (no reboot loop).
- During the brief reconnect window, our LNS logged the gateway reporting an unexpected
region_id="au915_cds"alongside the normalau915_1— which makes us suspect a config reset on reboot.
So the unit is alive and link-up locally, but has no working path to the internet/servers.
Q2: Does WisGateOS 2.2.14 reset network/Work-Mode/region config on reboot or power-cycle? Is there a known config-loss issue where a Basics Station gateway comes back link-up but no longer connects (e.g., reverting out of Basics Station mode, or losing WAN/DNS/WireGuard config)? How do we recover a remotely-managed gateway without on-site reconfiguration?
Q3: We’re on 2.2.14. Would upgrading to 2.2.16 or the 2.3.1 major release address either the per-concentrator RX asymmetry or the reboot config-reset behavior? Recommended upgrade path for a 16-channel Basics Station deployment managed remotely?
Thanks in advance.