Category
Hardware Compatibility
Hardware
Linux Native, Other
Firmware Version
2.7.26.54e0d8d
Description
Body
Hardware: RAK8623 WisMesh Station HP (RAK6421 HAT + RAK13302 1W module)
meshtasticd: 2.7.26.61-obs54e0d8d-beta (OBS beta channel)
OS: Raspberry Pi OS Trixie 64-bit, custom image, RPi 4
Summary
Requesting max txPower (30 dBm, US915) results in meshtasticd logging Requested Tx power: 30 dBm; Device LoRa Tx gain: 8 dB. The active config.d file's TX_GAIN_LORA table is:
[9, 9, 10, 11, 9, 8, 9, 10, 10, 10, 11, 12, 12, 12, 12, 12, 12, 12, 12, 10, 9, 8]
Gain value 8 sits near the bottom of this table (table peaks at 12, indices 11–18). A max-power request landing on a near-minimum gain value suggests a mapping/index bug between requested dBm and the corresponding TX_GAIN_LORA slot.
Ruled out
- HAT EEPROM detection: confirmed via
/proc/device-tree/hat/product → 6421 Pi Hat
- config.d loading: confirmed via journalctl, file active at startup
- GPIO enable state:
Enable_Pins [12, 13] confirmed out hi continuously via /sys/kernel/debug/gpio while daemon runs normally — PA enable is not the issue
Real-world symptom
Node is reliably outbeaten in range by a cheap SX1262-only tracker (no PA) on the same network, consistent with the 1W unit transmitting at bare-chip ceiling power rather than boosted output.
Config file
lora-RAK6421-13302-slot1.yaml, official RAK-shipped file bundled in meshtasticd package, unmodified.
Question
Is the 8 dB gain value correct for a 30 dBm request given this table, or is there an off-by-N indexing issue between requested power and the TX_GAIN_LORA array?
Cross-reference
Related RAK forum thread: https://forum.rakwireless.com/t/rak8623-wismesh-station-hp-rak13302-pa-not-engaging-at-full-1w-on-meshtasticd-2-7-15/17250
Relevant log output
INFO | 10:13:17 0 Requested Tx power: 30 dBm; Device LoRa Tx gain: 8 dB
INFO | 10:13:17 0 Set RX gain to boosted mode; result: 0
INFO | 10:13:17 0 Applied SX1262 register 0x8B5 patch for RX improvement
Category
Hardware Compatibility
Hardware
Linux Native, Other
Is this bug report about any UI (https://meshtastic.org/docs/configuration/device-uis/) component firmware?
Firmware Version
2.7.26.54e0d8d
Description
Body
Hardware: RAK8623 WisMesh Station HP (RAK6421 HAT + RAK13302 1W module)
meshtasticd: 2.7.26.61-obs54e0d8d-beta (OBS beta channel)
OS: Raspberry Pi OS Trixie 64-bit, custom image, RPi 4
Summary
Requesting max txPower (30 dBm, US915) results in meshtasticd logging
Requested Tx power: 30 dBm; Device LoRa Tx gain: 8 dB. The active config.d file'sTX_GAIN_LORAtable is:Gain value 8 sits near the bottom of this table (table peaks at 12, indices 11–18). A max-power request landing on a near-minimum gain value suggests a mapping/index bug between requested dBm and the corresponding TX_GAIN_LORA slot.
Ruled out
/proc/device-tree/hat/product→6421 Pi HatEnable_Pins[12, 13] confirmedout hicontinuously via/sys/kernel/debug/gpiowhile daemon runs normally — PA enable is not the issueReal-world symptom
Node is reliably outbeaten in range by a cheap SX1262-only tracker (no PA) on the same network, consistent with the 1W unit transmitting at bare-chip ceiling power rather than boosted output.
Config file
lora-RAK6421-13302-slot1.yaml, official RAK-shipped file bundled in meshtasticd package, unmodified.Question
Is the 8 dB gain value correct for a 30 dBm request given this table, or is there an off-by-N indexing issue between requested power and the TX_GAIN_LORA array?
Cross-reference
Related RAK forum thread: https://forum.rakwireless.com/t/rak8623-wismesh-station-hp-rak13302-pa-not-engaging-at-full-1w-on-meshtasticd-2-7-15/17250
Relevant log output