Skip to content

Fix RAK13302 1W FEM control: drive SKY66122-11 CSD/CPS/CTX directly#9742

Closed
weebl2000 wants to merge 6 commits into
meshtastic:developfrom
weebl2000:rak13302-sky66122-11-fem-fix
Closed

Fix RAK13302 1W FEM control: drive SKY66122-11 CSD/CPS/CTX directly#9742
weebl2000 wants to merge 6 commits into
meshtastic:developfrom
weebl2000:rak13302-sky66122-11-fem-fix

Conversation

@weebl2000
Copy link
Copy Markdown
Contributor

The RAK13302's SKY66122-11 FEM has three control pins (CSD, CPS, CTX) that must be actively driven by the MCU. The existing code only managed CPS via SX126X_POWER_EN and relied on DIO2 for TX/RX switching, but R25 (DIO2→CTX) is NC by default, leaving CSD floating and CTX undriven. This put the FEM in an undefined state — the PA wouldn't reliably engage during TX and the 16 dB RX LNA was never active.

Add USE_SKY66122_FEM support (following the existing USE_GC1109_PA pattern) to explicitly initialize, sleep, and toggle all three FEM pins for correct TX/RX/shutdown modes.

See also meshcore-dev/MeshCore#1836.

I don't have a RAK13302 device so I cannot test this myself.

References:

rak13302-schematic rak13302-power-explanation

@github-actions github-actions Bot added needs-review Needs human review hardware-support Hardware related: new devices or modules, problems specific to hardware labels Feb 25, 2026
@weebl2000 weebl2000 force-pushed the rak13302-sky66122-11-fem-fix branch 2 times, most recently from e2e3feb to 3de6a5b Compare February 25, 2026 00:59
@weebl2000
Copy link
Copy Markdown
Contributor Author

Fixed formatting

@weebl2000 weebl2000 force-pushed the rak13302-sky66122-11-fem-fix branch 2 times, most recently from 5a33bae to 7b456bb Compare February 25, 2026 02:58
Copy link
Copy Markdown
Member

@caveman99 caveman99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's more or less identical patterns for both PA's Why don't aggregate them user USE_LORA_PA or something similar and only differentiate in the sleep call to not switch off the power for one of these?

I really don't like duplicate code blocks that do almost the same.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes the SKY66122-11 Front-End Module (FEM) control for the RAK13302 1W module on the RAK3401 nRF52840 variant. The existing code only managed the CPS pin via SX126X_POWER_EN and relied on DIO2 for TX/RX switching, but the RAK13302 hardware has R25 (DIO2→CTX) as NC (not connected) by default, leaving the FEM in an undefined state where the PA and LNA were not properly controlled.

Changes:

  • Add explicit MCU control of all three SKY66122-11 FEM pins (CSD, CPS, CTX) following the existing USE_GC1109_PA pattern
  • Remove SX126X_POWER_EN define (pin 21) and repurpose it for SKY66122_CPS control
  • Implement proper initialization, TX/RX switching, and sleep mode shutdown for the FEM

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
variants/nrf52840/rak3401_1watt/variant.h Adds USE_SKY66122_FEM support with pin definitions for CSD (24), CPS (21), and CTX (31), and comprehensive documentation of the control logic
src/mesh/SX126xInterface.cpp Implements FEM initialization in init(), TX/RX path switching in setTransmitEnable(), and power-down in sleep()

@weebl2000
Copy link
Copy Markdown
Contributor Author

I'm not sure if it would be clearer if we unified the FEM logic: https://github.com/weebl2000/meshtastic-firmware/pull/1/changes

Thoughts?

@weebl2000 weebl2000 force-pushed the rak13302-sky66122-11-fem-fix branch from 985a9e1 to 0f0f1ea Compare February 25, 2026 21:24
Wessel Nieboer and others added 2 commits February 26, 2026 09:12
The RAK13302's SKY66122-11 FEM has three control pins (CSD, CPS, CTX)
that must be actively driven by the MCU. The existing code only managed
CPS via SX126X_POWER_EN and relied on DIO2 for TX/RX switching, but R25
(DIO2→CTX) is NC by default, leaving CSD floating and CTX undriven. This
put the FEM in an undefined state — the PA wouldn't reliably engage
during TX and the 16 dB RX LNA was never active.

Add USE_SKY66122_FEM support (following the existing USE_GC1109_PA
pattern) to explicitly initialize, sleep, and toggle all three FEM pins
for correct TX/RX/shutdown modes.
@weebl2000 weebl2000 force-pushed the rak13302-sky66122-11-fem-fix branch from 0f0f1ea to 991ad92 Compare February 26, 2026 08:56
@thebentern
Copy link
Copy Markdown
Contributor

I'm not sure if it would be clearer if we unified the FEM logic: https://github.com/weebl2000/meshtastic-firmware/pull/1/changes

Thoughts?

Looks cleaner to me

@weebl2000
Copy link
Copy Markdown
Contributor Author

Looks cleaner to me

updated PR to include the unifying

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Comment thread src/mesh/SX126xInterface.cpp Outdated
Comment thread variants/nrf52840/rak3401_1watt/variant.h Outdated
Comment thread src/sleep.cpp
@weebl2000
Copy link
Copy Markdown
Contributor Author

weebl2000 commented Feb 27, 2026

That's more or less identical patterns for both PA's Why don't aggregate them user USE_LORA_PA or something similar and only differentiate in the sleep call to not switch off the power for one of these?

I really don't like duplicate code blocks that do almost the same.

Addressed this, please review again! @caveman99

@weebl2000
Copy link
Copy Markdown
Contributor Author

Actually, I think it's already correct, closing this!

@weebl2000 weebl2000 closed this Mar 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

hardware-support Hardware related: new devices or modules, problems specific to hardware needs-review Needs human review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants