RAK8623 (WisMesh Station HP): RAK13302 PA not engaging at full 1W on meshtasticd 2.7.15

WisBlock
1

Product: RAK8623 WisMesh Station HP (RAK6421 HAT + RAK13302 1W LoRa module)
Firmware: meshtasticd 2.7.15.48~obsd18f3f7~beta (Debian/meshtasticd apt beta channel)
OS: Raspberry Pi OS Debian 13 (Trixie) 64-bit, custom image (not RAK-provided image)
Firmware version (AT+VER): Not applicable — meshtasticd on Linux does not use AT commands. Version confirmed via apt-cache policy meshtasticd and meshtastic --info (firmwareVersion: "2.7.15").
Source code: No custom firmware. The config.d file referenced below (lora-RAK6421-13302-slot1.yaml) is the official RAK-shipped file included in the meshtasticd beta package, renamed from .disabled to active.
How often: Consistently, across multiple reboots

Background

I am running a custom Trixie image on the RAK8623 with meshtasticd installed from the official beta apt channel. The node is configured as a fixed indoor gateway in Ohio, US915 region. I chose the custom image path deliberately to maintain control over the OS and certificate infrastructure.

Problem

The RAK13302 power amplifier does not appear to be engaging at full 1W (30 dBm). meshtastic --info consistently reports txPower: 30 (requested) but femLnaMode: DISABLED. RF behavior and SNR values from neighboring nodes suggest the node is transmitting at the bare SX1262 ceiling (~22 dBm) rather than the boosted 1W output.

What I have tried

1. meshtasticd 2.7.25 alpha (apt alpha channel)

With the alpha firmware and no config.d file active, the node reported:

  • femLnaMode: NOT_PRESENT
  • hwModel: RAK6421 (correct EEPROM detection)
  • Node ID drifted on every reboot (separate alpha bug)

Enabling the config.d override (lora-RAK6421-13302-slot1.yaml.disabled → active) fixed the gain table but caused hwModel to revert to PORTDUINO and suppressed EEPROM autodetection entirely, also causing node ID drift. Both issues confirmed as alpha firmware bugs.

2. meshtasticd 2.7.15 beta (current)

Downgraded to 2.7.15 beta. Node ID is now stable across reboots. hwModel reports PORTDUINO (expected on Linux). The config.d file lora-RAK6421-13302-slot1.yaml is active and confirmed loading at startup via journalctl:

Jun 22 12:55:02 hostname meshtasticd[1098]: Also using "/etc/meshtasticd/config.d/lora-RAK6421-13302-slot1.yaml" as additional config file

Contents of active config.d file:

Meta:
  name: RAK6421 + RAK13302 Slot 1
  support: official
  compatible:
    - raspberry-pi
Lora:
  Module: sx1262
  IRQ: 22
  Reset: 16
  Busy: 24
  Enable_Pins:
    - 12
    - 13
  DIO3_TCXO_VOLTAGE: true
  DIO2_AS_RF_SWITCH: true
  spidev: spidev0.0
  TX_GAIN_LORA: [9, 9, 10, 11, 9, 8, 9, 10, 10, 10, 11, 12, 12, 12, 12, 12, 12,
12, 12, 10, 9, 8]

Current meshtastic --info output (relevant fields):

"txPower": 30,
"femLnaMode": "DISABLED",

HAT EEPROM is readable at the OS level:

$ cat /proc/device-tree/hat/product
6421 Pi Hat

Question

Is femLnaMode: DISABLED the expected and correct behavior for the RAK13302 on meshtasticd when using Enable_Pins in config.d — meaning the PA is hardware-controlled via those pins and the firmware field is intentionally disabled? Or does DISABLED indicate the PA is not engaging?

A user in an existing thread (RAK6421 + RAK13302 not outputting 1W) reported a similar symptom using pyMC_repeater and suggested a gpioset systemd daemon to hold GPIO 12 and 13 high persistently. Is that workaround also required for meshtasticd users, or should Enable_Pins in config.d be sufficient to engage the PA?

I want to confirm whether I am actually transmitting at 1W before filing this upstream with the Meshtastic project.

More broadly: this is stock, unmodified hardware. What is the correct and complete meshtasticd software stack RAK recommends to achieve reliable 1W output on the RAK8623 with a custom OS image? Is there an official reference configuration — config.d file, systemd services, GPIO setup — that I should be matching?

Thank you.