Improve GC1109 FEM pin handling for Heltec v4 and Tracker v2

[weebl2000]

Improves the GC1109 FEM pin management for Heltec v4 and Heltec Tracker v2. These are correctness and robustness improvements to how GPIO46 (CPS strapping pin) and deep sleep pins are handled - not a fix for the core TX/RX switching which was already working correctly via DIO2.

Note: The register patch (SX126X_REGISTER_PATCH=1) that was the primary RX sensitivity improvement has already been merged via PR #1398.

Changes

GPIO46 (CPS) strapping pin handling

GPIO46 is an ESP32-S3 strapping pin. Previously it was configured as OUTPUT at boot and left that way permanently. Now:

• Boot: GPIO46 is not configured - TX handlers are fully responsible for it
• onBeforeTransmit: Sets pinMode(OUTPUT) then drives HIGH (full PA mode)
• onAfterTransmit: Drives LOW then releases with pinMode(INPUT)

This avoids holding a strapping pin as OUTPUT when it's not needed (CPS is "don't care" during RX per the GC1109 datasheet).

Deep sleep pin management

• Now holds PA_POWER (VFEM LDO) during sleep in addition to PA_EN (CSD), so the GC1109 remains powered for RX wake capability
• Properly releases RTC holds for PA_POWER and PA_EN on deep sleep wake
• Separates cold boot vs deep sleep wake paths for clarity

Other

• 1ms delay after GC1109 power-up on cold boot to allow FEM to stabilise
• Moved PIN_BOARD_SDA/PIN_BOARD_SCL to the base [Heltec_lora32_v4] section
• Updated pin comments to reference GC1109 datasheet nomenclature (CSD, CPS, CTX, VFEM)
• Applied same changes to Heltec Tracker v2 (identical GC1109 FEM, CSD on GPIO4)

GC1109 Control Logic Reference

Mode	CSD (GPIO2/4)	CTX (DIO2)	CPS (GPIO46)
Shutdown	0	X	X
Receive LNA	1	0	X (don't care)
Transmit bypass	1	1	0
Transmit PA	1	1	1

TX/RX path switching is handled automatically by SX1262 DIO2 → GC1109 CTX (SX126X_DIO2_AS_RF_SWITCH=true). This was already the case before this PR.

[fschrempf]

According to @jbrazio here, it depends on the antenna whether RX boosted gain is benefitial or not. So if you disable it, it might help you but make things worse for others. If that's true, then we should leave this as is an go for the solution in #1164.

[weebl2000]

According to @jbrazio here, it depends on the antenna whether RX boosted gain is benefitial or not. So if you disable it, it might help you but make things worse for others. If that's true, then we should leave this as is an go for the solution in #1164.

Yeah maybe, I haven't tested with a lot of antennas yet. There's definitely something funky going on with the PA/LNA and the RX gain though.

[weebl2000]

According to @jbrazio here, it depends on the antenna whether RX boosted gain is benefitial or not. So if you disable it, it might help you but make things worse for others. If that's true, then we should leave this as is an go for the solution in #1164.

It'

According to @jbrazio here, it depends on the antenna whether RX boosted gain is benefitial or not. So if you disable it, it might help you but make things worse for others. If that's true, then we should leave this as is an go for the solution in #1164.

Yeah maybe, I haven't tested with a lot of antennas yet. There's definitely something funky going on with the PA/LNA and the RX gain though.

@fschrempf It gets more tricky. But I think we actually might just need to set SX126X_DIO2_AS_RF_SWITCH=false since we are handling the TX/RX mode on the PA/LNA. But I am getting variying results with improvements or not. I will try running tests for longer to really see a difference 👀

[weebl2000]

Updated with latest finding. I have tested for limited time but RX is heaps better, so others please do test!

[weebl2000]

I was asked to build the firmware, here you go for ble companion and repeater

• https://x230.weebl.me/public/heltec_v4_main+RX_fix_companion_radio_ble.bin
• https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin

realized heltec wireless tracker v2 uses same chip:

• http://x230.weebl.me/public/heltec_tracker_v2_main+RX_fix_companion_radio_ble.bin
• http://x230.weebl.me/public/heltec_tracker_v2_main+RX_fix_repeater.bin

[dt267]

[perry99]

I was asked to build the firmware, here you go for ble companion and repeater

• https://x230.weebl.me/public/heltec_v4_main+RX_fix_companion_radio_ble.bin
• https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin

The repeater is also a companion firmware:-(

[weebl2000]

Oops let me check

[weebl2000]

I was asked to build the firmware, here you go for ble companion and repeater

• https://x230.weebl.me/public/heltec_v4_main+RX_fix_companion_radio_ble.bin
• https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin

The repeater is also a companion firmware:-(

Try now. Same URL.

sha256sum *bin
14f0617247fb9599d66e2f93796dbca628f82a0f0b4590b548eba18f10eac134  heltec_v4_main+RX_fix_companion_radio_ble.bin
41fa50ff5d1dd33bdd6367d6ebbcee2df464ac650717a27897caa195a7b103e3  heltec_v4_main+RX_fix_repeater.bin

[perry99]

I was asked to build the firmware, here you go for ble companion and repeater

• https://x230.weebl.me/public/heltec_v4_main+RX_fix_companion_radio_ble.bin
• https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin

The repeater is also a companion firmware:-(

Try now. Same URL.

sha256sum *bin
14f0617247fb9599d66e2f93796dbca628f82a0f0b4590b548eba18f10eac134  heltec_v4_main+RX_fix_companion_radio_ble.bin
41fa50ff5d1dd33bdd6367d6ebbcee2df464ac650717a27897caa195a7b103e3  heltec_v4_main+RX_fix_repeater.bin

Thank you!

[Heronimonimo]

For those running the observer uplink firmware, there is a version to test compiled with this fix: https://discord.com/channels/1343693475589263471/1417491962675593296/1452383493295439903

Running that here but don't see a significant difference yet.

[weebl2000]

For those running the observer uplink firmware, there is a version to test compiled with this fix: https://discord.com/channels/1343693475589263471/1417491962675593296/1452383493295439903

Running that here but don't see a significant difference yet.

For observer firmware, if you never enable the TX path I would guess the LNA stays properly enabled and you wouldn't see much difference.

If I kept TX low always I also saw great reception with the current firmware. Only after sending once would the RX deteriorate.

[Heronimonimo]

For those running the observer uplink firmware, there is a version to test compiled with this fix: https://discord.com/channels/1343693475589263471/1417491962675593296/1452383493295439903
Running that here but don't see a significant difference yet.

For observer firmware, if you never enable the TX path I would guess the LNA stays properly enabled and you wouldn't see much difference.

If I kept TX low always I also saw great reception with the current firmware. Only after sending once would the RX deteriorate.

Observers are repeater firmware with mqtt uplink. So they do use TX a lot. Will keep monitoring the effect on my repeater.

[weebl2000]

For those running the observer uplink firmware, there is a version to test compiled with this fix: https://discord.com/channels/1343693475589263471/1417491962675593296/1452383493295439903
Running that here but don't see a significant difference yet.

For observer firmware, if you never enable the TX path I would guess the LNA stays properly enabled and you wouldn't see much difference.
If I kept TX low always I also saw great reception with the current firmware. Only after sending once would the RX deteriorate.

Observers are repeater firmware with mqtt uplink. So they do use TX a lot. Will keep monitoring the effect on my repeater.

Ah okay. Only easy way to test is having two devices next to each other or otherwise testing with nodes at the edge of your reach.

[Quency-D]

@fschrempf It gets more tricky. But I think we actually might just need to set SX126X_DIO2_AS_RF_SWITCH=false since we are handling the TX/RX mode on the PA/LNA. But I am getting variying results with improvements or not. I will try running tests for longer to really see a difference 👀

The definition SX126X_DIO2_AS_RF_SWITCH=false seems problematic because it requires controlling the CTX pin to ensure proper transmit/receive switching. The PA_TX_EN (CPS) pin is only for controlling transmit bypass.

[dt267]

This is the way I fixed V4'LNA problem, bypassed it.

[Quency-D]

This is the way I fixed V4'LNA problem, bypassed it.

Did you use a flying wire? How did the test go?

[dt267]

Two weeks ago, running fine up to now, one repeater and one companion

[weebl2000]

Two weeks ago, running fine up to now, one repeater and one companion

Would be interesting to see if you can notice a difference with the fixed firmware and no bypass vs the bypass.

[dt267]

basically, there is no firmware fixed way

[weebl2000]

basically, there is no firmware fixed way

Why not?

[dt267]

because there is no way to turn off that LNA by command

[weebl2000]

But if you could share the whole dev fix with this pr fix and the semtech fix together in a different way. I would be grateful and flash it too test before adding the cavity.

turtle_3_semtech+rxfix.bin.zip

[tpp-at-idx]

Hello all

Just wanted to do a quick chime in on this issue. Two days ago I applied the fix from https://github.com/weebl2000/MeshCore/tree/semtech_patch ( whitch afaik integrates the semtech patch and the LNA patch ) and the reception on my V4 greatly improved. Sadly, all I can do for you now is to share this anecdotical truth as I have no hard data to back this up, but hopefully it helps.

The long story with background. I went to update my clients from the heltec v3 to the v4. Using the stock firmware i noticed that on the spot i do usually charge the devices the v3 reports noise floor about -105 and the v4 about -70. I quicky read up upon this that the LNA does this and went with it. Then I discovered that there is a reception difference between the two devices side by side. The v3 gets all the messages and the v4 does not. This was strange because the mesh here is great and neither the v3 nor my other wismesh tag had any problems on the same spot but the v4 did. After some digging i found this PR and gave it a spin, after 2 days of testing i can say that the v3 and the v4 get the same messages and the v4 did not miss any.
Shout out to @weebl2000 for his digging and work and a big Thank you. first i thought that my v4's are a dud and not useable for me at all but now i can work with them

[spiralshapeturtle]

Thanks @tpp-at-idx so you compare messages at the samen location between v3 and v4.

One or two days back @weebl2000 posted 3 releases with a clear file naming. Are you able to distinct the difference between the Semtech register patch and the LNA patch? By comparing these two, I.e not the running the combined build.

My main concern is that heltec is supporting the register patch from Semtech but does not commit on the LNA functionality. If we want to get this merged into a real MC releases we need to try to get the difference of both clear. And file one correct PR probably only the Semtech register patch.

[tpp-at-idx]

@spiralshapeturtle Sure, i can try to do some simple A/B testing and see how it goes, but sadly, the files posted in #1249 (comment) do not work for me, my node ended up bootlooping. I went on to the repo i have already cloned from https://github.com/weebl2000/MeshCore/tree/semtech_patch and edited platformio.ini for the heltec v4 to comment out the SX126X_SEMTECH_PATCH variable, so that should leave me with the LNA patch only to try for a few days as per my inderstanding of the code. I will run this for a few days and report how it goes. After that i will have to figure out how to disable the LNA patch and leave the semtech patch as i do not see a simple straight way how to do it but that is a problem for another day;)

That said, and please forgive my coding and embedded device inexperience from the limited knowledge i have and from the knowledge that @weebl2000 shared in this PR i have the assumption that the LNA patch is somewhat correct and the way to do the PA/LNA switching regardless wether it fixes the receive issue or not and should be implemented regardless ( but maybe in another PR )

[weebl2000]

i have the assumption that the LNA patch is somewhat correct and the way to do the PA/LNA switching regardless wether it fixes the receive issue or not and should be implemented regardless

💯 fully agree.

[spiralshapeturtle]

@spiralshapeturtle Sure, i can try to do some simple A/B testing and see how it goes, but sadly, the files posted in #1249 (comment) do not work for me, my node ended up bootlooping. I went on to the repo i have already cloned from https://github.com/weebl2000/MeshCore/tree/semtech_patch and edited platformio.ini for the heltec v4 to comment out the SX126X_SEMTECH_PATCH variable, so that should leave me with the LNA patch only to try for a few days as per my inderstanding of the code. I will run this for a few days and report how it goes. After that i will have to figure out how to disable the LNA patch and leave the semtech patch as i do not see a simple straight way how to do it but that is a problem for another day;)

That said, and please forgive my coding and embedded device inexperience from the limited knowledge i have and from the knowledge that @weebl2000 shared in this PR i have the assumption that the LNA patch is somewhat correct and the way to do the PA/LNA switching regardless wether it fixes the receive issue or not and should be implemented regardless ( but maybe in another PR )

I agree that the logic written by @weebl2000 makes sense. However, I would really appreciate it if Heltec, via @Quency-D, could provide a formal company statement confirming whether this code is technically correct and acceptable from Heltec’s perspective. Ideally, the code would be reviewed and validated by Heltec’s own developers, and if approved submitted as a PR with their written endorsement for merging by Wessel.

Some testing is available above @Quency-D and below as requested here

With the cavity in place, I find it difficult to measure real-world differences. I also assume, as @tpp-at-idx mentioned, that the main benefits are achieved in scenarios where no cavity is installed and the receiver is oversteered with strong signals. That may explain why @Quency-D is unable to test this properly due to being located in a non-urban area, but we could help from our urban area's. Nevertheless, Heltec should still be able to confirm the correctness and validity of the proposed LNA code enhancement. Take responsibility and reach out for the current V4 issues out in the field, and help us by getting this fix into the new MeshCore release in the near future.

From my own observations, the results also appear positive in my setup @weebl2000 at least my SNR on the v4 is strong and stable with the cavity.

I killed my RS232 myself so it stopped unfortunately without noticing, let's grab the lines logged. Things to conclude from the units, the V4 +cavity is decoding more packets at the same point of time. with the V4 with turtle_3_semtech+rxfix.bin its running very well. Im just seeking for the guidance of Heltec in this matter.

T114 McGill 9dBi antenna (30 cm lower mounted than the RAK)
V4 -> Sysmocom Cavity -> RAK 8dBi antenna

V4

T114

SNR to compare from the same Adverts
T114 low SNR

V4 strong SNR

---

Shall I run it without cavity, would that help? My first plan was to run it with the LNA fix only the next 24hours.

[Socalix]

Thanks a lot for your elaborate testing. Not sure if you're up for more testing but it would be great if we can compare the registerpatch vs. this PR without it, to test if this register actually makes a change.

I ran same test configuration as before again with the PR builds - both with and without the register patch by @weebl2000 (register value 1). This confirmed again that PR without register patch is not different from the existing v1.11.0 firmware in terms of RX reception.
I also tested with another build where I applied the register patch as decribed by @Quency-D (with LSB=1) on the original v1.11.0 firmware, with and without the RX Boosted Gain flag.
The build with boosted gain had similar results to this PR with register patch, but the build without boosted gain showed much better RX results.

I then reviewed again the code changes in this PR against v1.11.0 and I found there's a significant discrepancy between the code change itself and the PR summary at the top:

• There is no difference in the sequence of setting up the GC1109 on boot (turning on PA_POWER, PA_EN, then PA_TX_EN) except that now it's not setting PA_TX_EN at all until the first advert transmit. I think setting value is better than not.
• onBeforeTransmit and onAfterTransmit are toggling CPS PA_TX_EN to high/low as the original v1.11.0, except now there's extra pinMode setting which I do not believe is needed.
• Original v1.11.0 already enabled DIO2 control for the CTX and not other pins like SX126X_RXEN and SX126X_TXEN.
• The only additional change here is holding and releasing pins related to deep sleep, which I do not exactly see when/how it gets into this mode.

I now created a new PR #1398 that only includes the register patch and no RX boosted gain in case others want to test as well.

Test Sample:

RAK4631 v1.11.0	Heltec v4 PR1249 w/o RegPatch	Heltec v4 PR1249 w/RegPatch	Heltec v4 v1.11.0 w/RegPatch and no Boosted Gain
-4.25	err	4.75	5.5
err	err	err	6.25
-2.75	err	2.75	err
3.75	3.5	err	4.25
1.75	5.5	2.0	5.5
3.0	err	6.0	4.75
err	err	err	1.25
1.75	4.75	err	7.75
4.0	3.25	-0.25	err
4.75	3.0	1.75	2.5
-7.5	4.25	5.0	2.0
6.75	4.25	2.25	err
err	err	err	5.5
6.25	err	4.0	0.25
3.75	err	-0.75	err
20% err	55% err	33% err	25% err

[Quency-D]

I agree that the logic written by @weebl2000 makes sense. However, I would really appreciate it if Heltec, via @Quency-D, could provide a formal company statement confirming whether this code is technically correct and acceptable from Heltec’s perspective. Ideally, the code would be reviewed and validated by Heltec’s own developers, and if approved submitted as a PR with their written endorsement for merging by Wessel.

We have been testing and verifying the modified register version. We have also arranged tests to assess the effects of modifying the GC1109 control pins, which are currently underway and may take some time.

[spiralshapeturtle]

I agree that the logic written by @weebl2000 makes sense. However, I would really appreciate it if Heltec, via @Quency-D, could provide a formal company statement confirming whether this code is technically correct and acceptable from Heltec’s perspective. Ideally, the code would be reviewed and validated by Heltec’s own developers, and if approved submitted as a PR with their written endorsement for merging by Wessel.

We have been testing and verifying the modified register version. We have also arranged tests to assess the effects of modifying the GC1109 control pins, which are currently underway and may take some time.

Thanks for the update good to hear that Heltec is actively testing and validating the modified register approach.

For clarity, I want to restate the terminology used in this PR, as multiple mechanisms are being discussed:

Semtech register patch
A radio register change (LSB = 1) that ensures the SX126x and GC1109 FEM correctly return to RX state after TX. Based on both testing and Heltec’s feedback, this appears to address the root cause of the RX degradation.

LNA pin enhancement
GPIO-based control of the GC1109/LNA to force RX behavior after TX. While testing of this approach is ongoing, current results suggest it behaves more like a workaround than a structural fix.

RX boosted gain
An optional SX126x RX gain mode that increases reported RSSI but does not consistently improve real-world RX performance and can complicate comparisons.

While I appreciate that Heltec is still evaluating the GC1109 control-pin behavior, I do have some reservations about relying on the LNA pin enhancement as a final solution. Given Heltec’s reputation as a technically strong and fast-moving hardware vendor, the fact that the register-level fix is already being validated suggests this is likely the intended and more robust approach, with pin-level changes remaining secondary until proven otherwise

[tpp-at-idx]

Hello guys
I've run some tests as promised
Thease are all based on the BLE companion firmware. With one reference node in a good RF environment, out of the window, which is persumed to receive all messages, and with the testing node being a V4 placed in my "rf hellhole" ( noisy monitors, PC's, noise floor about -70 to -75 ).
The test was to receive ~ 300 messages on the reference node and then compare how many messages were lost on the tested node. Take this with a grain of salt, I've tried to make it as scientific as possible but the methodology may be flawed upon factors i can not really control and it is all i could do with my limited resources

Stock firmware: Reference: 296 messages, V4 received: 284, loss: 4 %
TXRX lna patch: Reference: 239 messages, V4 received: 229, loss: 4,1 %
Semtech only patch : Reference: 307 messages, V4 received: 302, loss: 1,6 %
RXgain off +semtech patch ( PR 1398 ) : Reference: 266, V4 received: 252, loss: 5,2 %

[JvM-nl]

Stock firmware: Reference: 296 messages, V4 received: 284, loss: 4 % TXRX lna patch: Reference: 239 messages, V4 received: 229, loss: 4,1 % Semtech only patch : Reference: 307 messages, V4 received: 302, loss: 1,6 % RXgain off +semtech patch ( PR 1398 ) : Reference: 266, V4 received: 252, loss: 5,2 %

Where did you find the "Semtech only patch"?

[Quency-D]

HI, @JvM-nl You can refer to this. #1398

[trisweb]

Seems like the links to the compiled firmwares aren't working... maybe you could host them on an alternate mirror? Thanks! Looking forward to trying this out.

[pon-wessel]

Seems like the links to the compiled firmwares aren't working... maybe you could host them on an alternate mirror? Thanks! Looking forward to trying this out.

I can do that later this evening. If you can't access it you are most likely blocking Tor networks (unifi does this, you can untick it somewhere in settings, darkweb filter or something). The machine it runs on is also a Tor node (non-exit fyi).

[beachmiles]

Looks like the register only fix is the correct fix.
Also @Socalix synced his fix up to 1.12 and fixed the battery issue where the screen was staying on.
#1398

Edit. Missed the deep sleep fix you had to keep the LNA on during deep sleep. Glad it got merged.

[tpp-at-idx]

Soo, i noticed that #1398 was merged into dev today..
Now the question arises what to do with this PR. I tested this and I also tested the latter, performance wise the semtech patch won, but I must admit that my usecase was somewhat special and your results may vary. I also note that the technical information jn this PR makes sence to me and my logic suggests it should be merged but I admit that my knowledge is very limited in this matter and it is possible that I miss something that speaks against it.
so, it is open to discussion wether this is still a valid pr and one should pursue testing and verifying or wether this is a "dud" and one should drop it

[Socalix]

Soo, i noticed that # 1398 was merged into dev today..
Now the question arises what to do with this PR.

As I mentioned here #1249 (comment) before opening PR # 1398, the actual code changes in this PR do not align with the PR summary at the top.
After carefully reviewing the code here, the only change from v1.11.0 is related to holding and releasing pins for deep sleep and switching pin modes, which I do not see exactly when/how this is relevant and I did not hear anybody having issues that require these changes.

[weebl2000]

Superseded by #1600 — stripped down to just the PA_POWER deep sleep fix.