Skip to content

Conversation

@weebl2000
Copy link
Contributor

@weebl2000 weebl2000 commented Dec 20, 2025

Root Cause

UPDATE 23/12/2025:
Actually, we should just the SX1262 chip handle the RF path. Operating pin 46 as a TX switch is not the right way, it should be treated as CPS pin.

Key fixes:

  1. Removed double-control: Removed SX126X_TXEN=LORA_PA_TX_EN which caused both RadioLib and setTransmitEnable() to fight over GPIO46
  2. Corrected documentation: GPIO46 is CPS (PA mode select), NOT the TX/RX switch. DIO2 handles TX/RX path via CTX
  3. Added GC1109 datasheet control logic to variant headers

The GC1109 FEM (Front-End Module) chip requires specific control logic:
- PA_EN (pin 2): Must be HIGH for both RX and TX modes
- PA_TX_EN (pin 46): RF switch control - LOW=RX path (LNA), HIGH=TX path (PA)

The bugs prevented proper RX operation, causing 10-20 dB sensitivity loss.

🤝 Attestations

I haven't tested yet, but derived from HERE. But someone please do.

  • I have tested that my proposed changes behave as described.
  • I have tested that my proposed changes do not cause any obvious regressions on the following devices:
    • Heltec (Lora32) V4

@thebentern thebentern added the bugfix Pull request that fixes bugs label Dec 20, 2025
@thebentern
Copy link
Contributor

Great detective work! Thanks for the pull

Copy link
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 a critical bug in the GC1109 Front-End Module (FEM) control logic for Heltec v4 and Wireless Tracker v2 devices that caused 10-20 dB RX sensitivity loss. The root cause was incorrect initialization of the PA_EN pin, which must remain HIGH for both RX and TX operations, not LOW as it was previously set.

Key changes:

  • Fixed GC1109 PA_EN pin initialization from LOW to HIGH in SX126xInterface.cpp
  • Added RadioLib RF switch control definitions (SX126X_RXEN/TXEN) to both variant files
  • Improved inline documentation explaining GC1109 pin behavior

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
variants/esp32s3/heltec_v4/variant.h Added RadioLib RF switch control definitions and improved comments documenting GC1109 pin functions
variants/esp32s3/heltec_wireless_tracker_v2/variant.h Added RadioLib RF switch control definitions and improved comments documenting GC1109 pin functions
src/mesh/SX126xInterface.cpp Fixed critical bug by changing PA_EN initialization from LOW to HIGH, and added detailed comments explaining GC1109 FEM chip initialization

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@fifieldt
Copy link
Member

I vaguely recall there are several other Heltec v4 specific ifdefs in the code that toggle this - we might want to double check to see if they are still needed.

@starvald
Copy link

This is interesting swapping between my v4 and t114 at work the better rx on the t114 was noticed.

@weebl2000
Copy link
Contributor Author

This is interesting swapping between my v4 and t114 at work the better rx on the t114 was noticed.

With the regular firmware I'm guessing?

@starvald
Copy link

This is interesting swapping between my v4 and t114 at work the better rx on the t114 was noticed.

With the regular firmware I'm guessing?

yes regular, t114 = 2.6.11, v4 = 2.7.13.

v4 firmware flashed from
https://resource.heltec.cn/download/WiFi_LoRa_32_V4/firmware
i assume they are unchanged from MT directly.

@weebl2000
Copy link
Contributor Author

This is interesting swapping between my v4 and t114 at work the better rx on the t114 was noticed.

With the regular firmware I'm guessing?

yes regular, t114 = 2.6.11, v4 = 2.7.13.

v4 firmware flashed from https://resource.heltec.cn/download/WiFi_LoRa_32_V4/firmware i assume they are unchanged from MT directly.

If you want I can build meshtastic firmware that includes this fix for the heltec v4.

@starvald
Copy link

This is interesting swapping between my v4 and t114 at work the better rx on the t114 was noticed.

With the regular firmware I'm guessing?

yes regular, t114 = 2.6.11, v4 = 2.7.13.
v4 firmware flashed from https://resource.heltec.cn/download/WiFi_LoRa_32_V4/firmware i assume they are unchanged from MT directly.

If you want I can build meshtastic firmware that includes this fix for the heltec v4.

i'm fine thanks, not in a high pop area (Norfolk UK) were flat area and i'm using a sensecap 8dbi for my main base node.

Away from work now as it Christmas so i can't test a mobile node atm but i hope the patch gets pulled if it helps us.

@weebl2000 weebl2000 changed the title Fix LNA/PA power control for Heltec v4, wireless tracker v2 🔧 Fix LNA/PA power control for Heltec v4, wireless tracker v2 Dec 22, 2025
@weebl2000
Copy link
Contributor Author

weebl2000 commented Dec 23, 2025

Updated with the latest findings, GPIO 46 is not TX pin, it should be treated as the CPS pin. Just informing the firmware that the TX/RX path is handled by the SX1262 will make sure the proper RX/TX pathways are used. We shouldn't be trying to override ourselves.

@starvald
Copy link

starvald commented Jan 5, 2026

Hi @weebl2000 do you have a build i can test for the v4?

@weebl2000
Copy link
Contributor Author

weebl2000 commented Jan 5, 2026

Hi @weebl2000 do you have a build i can test for the v4?

Let me build that for you.

@starvald
Copy link

starvald commented Jan 5, 2026

Hi @weebl2000 do you have a build i can test for the v4?

Repeater, companion? There's a few links in the main post that are built against main. If you want I can link you a dev build too.

Meshtastic companion node. but scratch that, decided to have a go at compiling myself from your repo/branch.

EDIT: responds to traceroutes but doesn't seem to be accessible via bluetooth,

@weebl2000
Copy link
Contributor Author

Hi @weebl2000 do you have a build i can test for the v4?

Repeater, companion? There's a few links in the main post that are built against main. If you want I can link you a dev build too.

Meshtastic companion node. but scratch that, decided to have a go at compiling myself from your repo/branch.

EDIT: responds to traceroutes but doesn't seem to be accessible via bluetooth,

In my autopilot I thought this was a different repository. Weird that the Bluetooth isn't working. Does it work with the regular build?

@starvald
Copy link

starvald commented Jan 5, 2026

Hi @weebl2000 do you have a build i can test for the v4?

Meshtastic companion node. but scratch that, decided to have a go at compiling myself from your repo/branch.
EDIT: responds to traceroutes but doesn't seem to be accessible via bluetooth,

In my autopilot I thought this was a different repository. Weird that the Bluetooth isn't working. Does it work with the regular build?

reflashed from the web flasher and bluetooth worked again, i did check via web serial and wifi was off.

@weebl2000
Copy link
Contributor Author

weebl2000 commented Jan 5, 2026

@starvald

$ sha256sum .pio/build/heltec-v4/firmware*bin
b25a8460480c66b7aa5f7f950aa122d058593c7a82eaca78b8fbf6faf439e495  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.bin
fcf8207e79fd6ad8a6b5aebe28ed2b4aa3dd1c28b19ead8bb2531940a3b583fd  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.factory.bin

@starvald
Copy link

starvald commented Jan 5, 2026

@starvald

$ sha256sum .pio/build/heltec-v4/firmware*bin
b25a8460480c66b7aa5f7f950aa122d058593c7a82eaca78b8fbf6faf439e495  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.bin
fcf8207e79fd6ad8a6b5aebe28ed2b4aa3dd1c28b19ead8bb2531940a3b583fd  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.factory.bin
* https://x230.weebl.me/public/firmware-heltec-v4-2.7.18.38f0c895c.factory.bin (factory flash, erase)

* https://x230.weebl.me/public/firmware-heltec-v4-2.7.18.38f0c895c.bin (OTA update)

Flashed your OTA and bluetooth works, i'll give it a try.

@thebentern thebentern merged commit 6e11078 into meshtastic:develop Jan 8, 2026
72 checks passed
@woodpatz
Copy link

woodpatz commented Jan 10, 2026

@starvald

$ sha256sum .pio/build/heltec-v4/firmware*bin
b25a8460480c66b7aa5f7f950aa122d058593c7a82eaca78b8fbf6faf439e495  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.bin
fcf8207e79fd6ad8a6b5aebe28ed2b4aa3dd1c28b19ead8bb2531940a3b583fd  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.factory.bin
* https://x230.weebl.me/public/firmware-heltec-v4-2.7.18.38f0c895c.factory.bin (factory flash, erase)

* https://x230.weebl.me/public/firmware-heltec-v4-2.7.18.38f0c895c.bin (OTA update)

Thanks for the build. 👍 I flashed the OTA update but also encounter Bluetooth issues. - BT works with the factory FW.

I'd apreciate if someone has an idea why that is. Would be great to get a working V4.🙏

suteny0r added a commit to suteny0r/firmware that referenced this pull request Jan 10, 2026
…shtastic#9029)

The GC1109 FEM chip enable (CSD) must be HIGH for both RX and TX modes.
Previously it was initialized LOW, preventing proper RX operation and
causing 10-20 dB sensitivity loss.

Key changes:
- Set LORA_PA_EN (CSD) HIGH during init to enable GC1109 chip
- Added comprehensive GC1109 control logic documentation to variant headers
- Clarified that GPIO46 is CPS (PA mode select), not TX control

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@woodpatz
Copy link

woodpatz commented Jan 11, 2026

@starvald

$ sha256sum .pio/build/heltec-v4/firmware*bin
b25a8460480c66b7aa5f7f950aa122d058593c7a82eaca78b8fbf6faf439e495  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.bin
fcf8207e79fd6ad8a6b5aebe28ed2b4aa3dd1c28b19ead8bb2531940a3b583fd  .pio/build/heltec-v4/firmware-heltec-v4-2.7.18.38f0c895c.factory.bin
* https://x230.weebl.me/public/firmware-heltec-v4-2.7.18.38f0c895c.factory.bin (factory flash, erase)

* https://x230.weebl.me/public/firmware-heltec-v4-2.7.18.38f0c895c.bin (OTA update)

Thanks for the build. 👍 I flashed the OTA update but also encounter Bluetooth issues. - BT works with the factory FW.

I'd apreciate if someone has an idea why that is. Would be great to get a working V4.🙏

I switched on/off WiFi and Bluetooth again and now Bluetooth works with my V4. 👍

Now I was able to see an improvement in RX sensitivity but it’s still far off from what you would expect.

The received signal on the V4 is 2-4 times weaker than with another node (Wio Tracker L1 or a Heltec V3). The difference in my quick tests were within a range of 2dB to 6dB.

vicliu624 pushed a commit to vicliu624/firmware that referenced this pull request Jan 13, 2026
…stic#9029)

* Fix LNA/PA power control for Heltec v4, wireless tracker v2

* Stop using pin 46 as RF switch, just let DIO2 switch handle the RF path

---------

Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
ndoo pushed a commit to Meshtastic-Malaysia/meshtastic-firmware that referenced this pull request Jan 14, 2026
…stic#9029)

* Fix LNA/PA power control for Heltec v4, wireless tracker v2

* Stop using pin 46 as RF switch, just let DIO2 switch handle the RF path

---------

Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
@ascendr
Copy link

ascendr commented Jan 16, 2026

Flashed a Heltec v4 from develop commit 91dd39a (2.7.18). Flashed a second Heltec v4 with 2.7.15 beta. The 2.7.15 build RX performance was markedly better. Several TR tests to a node approx 1 mi. away and RX level on the 2.7.18 build was approx 1dB lower. TRs to a distant node I would consistently receive direct RX at approx -11 dB on the 2.7.15 build and never get a direct RX on 2.7.18. To ensure this wasn't hardware related I swapped the builds and re-tested. The lower RX performance followed the 2.7.18 build. Both hardware are Heltec V4 with kit antenna directly connected and powered via USB-C from the same source.

@Quency-D
Copy link
Contributor

@ascendr This is somewhat strange, because apart from adding some comments, the only real change made to this commit was this line on line 65.Could you try reverting this sentence back to its original form?

 digitalWrite(LORA_PA_EN, HIGH);
image

@ascendr
Copy link

ascendr commented Jan 17, 2026

I'm wondering if by setting to CSD (LORA_PA_EN) High in initialization inadvertently hit this constraint:
VBAT must be prior to CSD/CPS/CTX for the power on sequence
as VBAT/VCC on the GC1109 is tied to GPIO7 // VFEM (LORA_PA_POWER) on the Heltec v4 and set to High right before CSD. Could possibly be a race condition or perhaps the VBAT/VCC is at a lower voltage level than CSD for a few ms due to caps charging and triggering this constraint?
CSD/CPS/CTX voltage level must not exceed VBAT voltage.
I plan to test both reversing the logic of LORA_PA_EN as well as introducing a delay between LORA_PA_POWER and LORA_PA_EN.

@lindorffs
Copy link

lindorffs commented Jan 17, 2026

Looks like the GC1109 has a "turn-on time" of 1.5-3uS. I'm going to test with a 5uS sleep in between
digitalWrite(LORA_PA_POWER, HIGH);
and
pinMode(LORA_PA_EN, OUTPUT); digitalWrite(LORA_PA_EN, HIGH);

@lindorffs
Copy link

lindorffs commented Jan 17, 2026

There's also this in sleep.cpp

#if defined(USE_GC1109_PA)
    gpio_pullup_en((gpio_num_t)LORA_PA_POWER);
    gpio_pullup_en((gpio_num_t)LORA_PA_EN);
    gpio_pulldown_en((gpio_num_t)LORA_PA_TX_EN);
#endif

and

#if defined(USE_GC1109_PA)
    /*
     * Do not switch the power on and off frequently.
     * After turning off LORA_PA_EN, the power consumption has dropped to the uA level.
     *  // digitalWrite(LORA_PA_POWER, LOW);
     */
    digitalWrite(LORA_PA_EN, LOW);
    digitalWrite(LORA_PA_TX_EN, LOW);
#endif

In the sleep function in SX126xInterface.cpp. When CSD is pulled low on the GC1109 it enters shutdown mode, and when CSD is pulled high again, I can only assume the turn-on time applies.

@compumike
Copy link
Contributor

@ascendr @lindorffs Interesting:

Per the schematic at https://resource.heltec.cn/download/WiFi_LoRa_32_V4/Schematic/WiFi_LoRa_32_V4.2.pdf , VFEM_Ctrl (LORA_PA_POWER) toggles the enable input of a TLV75733PDBVR LDO voltage regulator.

The TLV757P datasheet lists a Startup time (tSTR) = 550 us. Figure 5-10 shows this for when VIN and VEN are both enabled at the same time. Figure 5-12 shows that when VIN is already high (as it should be on this board), then toggling VEN similarly results in a stable voltage output after about 500 us (which may depend on output capacitance).

image

So if you're testing this, you may want to try sleeping much longer, like 600us - 1000us, immediately after digitalWrite(LORA_PA_POWER, HIGH).

@ascendr
Copy link

ascendr commented Jan 26, 2026

My tests show LORA_PA_EN (purple trace) switching to high logic ~12.5us after VFEM / LORA_PA_POWER (yellow trace).
vfem_lora_pa_scopetrace

I am also looking at

digitalWrite(LORA_PA_TX_EN, txon ? 1 : 0); // CPS: 1=full PA, 0=bypass (for RX, CPS is don't care)

I'm not sure there is any advantage to switching LORA_PA_TX_EN low when not transmitting. The truth table states LORA_PA_TX_EN state doesn't matter for RX or Standby.

@starvald
Copy link

starvald commented Feb 8, 2026

Hi @weebl2000 does this patch include the undocumented register patch?

ssp97 pushed a commit to ssp97/meshtastic_fw that referenced this pull request Feb 8, 2026
…stic#9029)

* Fix LNA/PA power control for Heltec v4, wireless tracker v2

* Stop using pin 46 as RF switch, just let DIO2 switch handle the RF path

---------

Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
@weebl2000
Copy link
Contributor Author

Hi @weebl2000 does this patch include the undocumented register patch?

See #9571

weebl2000 added a commit to weebl2000/meshtastic-firmware that referenced this pull request Feb 8, 2026
The TLV75733P LDO powering the GC1109 FEM has a ~550us startup time
(datasheet tSTR). Wait 1ms after enabling PA_POWER before driving CSD
HIGH, per the GC1109 power-on sequence requirement that VBAT must be
stable before CSD/CPS/CTX.

Oscilloscope measurements showed CSD going HIGH only ~12.5us after
PA_POWER, well before the LDO output stabilises.

Reference: meshtastic#9029
weebl2000 added a commit to weebl2000/meshtastic-firmware that referenced this pull request Feb 8, 2026
The TLV75733P LDO powering the GC1109 FEM has a ~550us startup time
(datasheet tSTR). Wait 1ms after enabling PA_POWER before driving CSD
HIGH, per the GC1109 power-on sequence requirement that VBAT must be
stable before CSD/CPS/CTX.

Only applied on cold boot - on deep sleep wake the LDO was held on via
RTC latch so no delay is needed.

Oscilloscope measurements showed CSD going HIGH only ~12.5us after
PA_POWER, well before the LDO output stabilises.

Reference: meshtastic#9029
@lindorffs
Copy link

lindorffs commented Feb 10, 2026

Thanks for your work on this @weebl2000, looks like you've found some good stuff. Some of my tests with delays on startup seemed to result in better rx, #2f246ef specifically looks like what I had. I'll give this a test later this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix Pull request that fixes bugs

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants