🔧 Fix GC1109 FEM LNA being used for Heltec v4 RX #1249
Conversation
weebl2000
force-pushed
the
heltec_v4_fix_RX_sensitivity
branch
from
7dcc916 to
d84784e
Compare
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
force-pushed
the
heltec_v4_fix_RX_sensitivity
branch
from
d84784e to
dcfea36
Compare
It'
@fschrempf It gets more tricky. But I think we actually might just need to set |
|
Updated with latest finding. I have tested for limited time but RX is heaps better, so others please do test! |
weebl2000
force-pushed
the
heltec_v4_fix_RX_sensitivity
branch
from
dcfea36 to
bc5e4be
Compare
The root cause was that RadioLib didn't know about the external GC1109 RF switch. Without the SX126X_RXEN/TXEN definitions, RadioLib never called setRfSwitchPins(), so it couldn't automatically manage PA_TX_EN during RX/TX transitions.
weebl2000
force-pushed
the
heltec_v4_fix_RX_sensitivity
branch
from
bc5e4be to
044505d
Compare
weebl2000
changed the title
|
I was asked to build the firmware, here you go for ble companion and repeater
realized heltec wireless tracker v2 uses same chip: |
|
The repeater is also a companion firmware:-( |
|
Oops let me check |
Try now. Same URL. |
Thank you! |
weebl2000
force-pushed
the
heltec_v4_fix_RX_sensitivity
branch
from
683ac76 to
2736011
Compare
|
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. |
The definition |
weebl2000
changed the title
This is the way I fixed V4'LNA problem, bypassed it. |
Did you use a flying wire? How did the test go? |
|
|
Would be interesting to see if you can notice a difference with the fixed firmware and no bypass vs the bypass. |
|
basically, there is no firmware fixed way |
Digged deeper, and made some changes. I think the logic is sound now. GPIO 46 was treated as a TX/RX switch, but it's not. It's simply CPS (PA mode select, low=bypass, high=full PA TX). DIO2 switch on the CX1262 chip is handling the TX/RX path automatically, so we shouldn't be messing with it ourselves. Updated the PR to reflect this. |
|
|
Tried to flash this H4 firmware for Repeater, finished with success but ends in a booting loop. Got back to official firmware and tried again this custom firmware but unfortunatelly same behaviour. |
That's strange. Can you verify the sha256sum? |
Yes, verified. It is correct. |
I've just rebuilt to make sure it's the correct one. Can you download again (incognito window to make sure), new sum:
|
|
|
Sorry, unfortunatelly on my device same behaviour. Tried it twice. Flashing is successfull. But after pressing RST Button I am in a boot loop. |
Do you see the meshcore logo when it boots or does it die before that? If the official firmware still works: what are your tx settings? (mainly tx power) |
Screen keeps black. Just hear my USB-Port disconnecting, connecting, disconnecting, connectiong, ... |
Can you check on a different USB power supply? Or perhaps different USB cable to make sure it's not a low-power issue. |
Ok, tried both. Different cable and port -> Same behaviour. Flashing back to official firmware also worked well with old cable and old port. Have to go off for today. Sometimes, best ideas arise from dreaming ;-) |
👍🏽 let me know if you have more time to troubleshoot, seems like an interesting find! |
|
@weebl2000 Love the fix and your debug process. I'm getting a Heltec v4 now, so I'm a bit worried. |
RX is very much improved with this fix! |
Of course, I will try again as soon as have my next free timeslot, maybe tonight. I also now have a second V4 for testing purpose and will try to flash it. Maybe it is/was a Hardware-Issue. Let me know which feedback and details you need. |
I think I've found the problem. We were holding pin 46 (connected to CPS on GC1109) during sleep, but that might cause issues when booting. It shouldn't be held anyway because the LNA doesn't care for CPS state during receive. Built new images, same links. |
Flashed with new custom firmware. |
Set pinmode output/input too to make sure
Made some more changes, now not touching pin 46 at all unless we want to TX. Working locally. Built it and updated the images + hashes. |
Still no change after flashing. Again boot loop. |
I've created a build that enables debug and waits 15 seconds before doing anything so you can attach to the serial monitor. Can you try flashing this https://x230.weebl.me/public/heltec_v4_repeater_debug_boot.bin and then attaching serial right after booting? You can use any serial monitor, like meshcore/meshtastic web flasher. 
Hopefully that helps narrow down the problem. |
Thank you for investing so much time in helping me. I flashed with your firmware and tried to connect serial. Unfortunatelly, there is not much time because between connect and disconnect there are only 1 - 2 seconds. But anyway I think this was a good idea. Looks like flashed file is not OK because SHA-256 comparison failed. This is what Serial console shows until disconnect: Welcome to MeshCore serial console.
|
Can you try erasing the ESP fully before flashing? (maybe backup your private key first using You can use esptool
|
Don't have Python installed. Is there also another way before I go installing it?? I did chose "Erase Flash" every time I used the Webflasher for this custom firmware. Isn't this the same? Btw. after flashing again now Console shows this. No problem with SHA256 comparison. Welcome to MeshCore serial console.
|
|
@stgruenbaum-hash Just to figureout if it helps |
This works !!!! Thank you very much for this hint! Great, will flash roof-top v4 next day and see if RX will get better. Thank you all for your support. |
|
Now its the question for @weebl2000 why a fresh install not work. Maybe generate keys. No idea I hope you/he will find |
|
Last version with sha256sum f5aebe63b2159b522768c9ef590bd30ae5a511e65f4c83dfa906a9b2e8782eb1 works very nice here. |
9 participants
I was experiencing very bad RX with my heltec v4 so I investigated and debugged.
**UPDATE 23/12/2025, latest findings **
The original implementation had incorrect understanding of the GC1109 FEM control pins. GPIO46 was incorrectly treated as a TX/RX switch, but it's actually the CPS (PA mode select) pin. The actual TX/RX path switching is handled by DIO2 → CTX directly on the PCB.
GC1109 Control Logic (from datasheet)
Pin Mapping
Summary of Changes
HeltecV4Board.cpp
platformio.ini
How It Works Now
- HIGH before TX → full PA enabled (+30dB internal, attenuated to ~+11dB net)
- LOW after TX → ready for RX (CPS is "don't care" in RX mode)
UPDATE 23/12/2025
Thoroughly reviewed against the GC1109 datasheet and WiFi_LoRa_32_V4.2.pdf. The same fix has been applied to Heltec Tracker V2 which uses the identical GC1109 FEM (CSD on GPIO4 instead of GPIO2).
Turns out everything handling the LNA/PA is completely fine, the only problem was the SX1262 boosted gain was enabled. If you disable this the RX is golden. 🥇UPDATE 23/12/2025
Having tested this myself I see excellent results with RX. Apart from that, multiple people have tested the firmware and notice a big improvement in being able to receive signals.
UPDATE 24/12/2025
Some users reported bootloop, this was probably caused by holding pin 46. We shouldn't hold that pin so removed that.
Update 2: avoid touching CPS pin at all unless we want to TX.
firmware to test, with latest changes 24/12/2025 - should fix bootloop issues