🔧 Fix GC1109 FEM LNA being used for Heltec v4 RX

[weebl2000]

I was experiencing very bad RX with my heltec v4 so I investigated and debugged.

UPDATE 31/12/2025
After testing for a week on both companion and repeater with multiple people the overall conclusion so far is that this greatly improves the RX on Heltec v4.

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)

Mode	CSD (GPIO2)	CTX (DIO2)	CPS (GPIO46)
Shutdown	0	X	X
Receive LNA	1	0	X (don't care)
Transmit bypass	1	1	0 (~1dB loss)
Transmit PA	1	1	1 (full PA)

Pin Mapping

Define	GPIO	GC1109 Pin	Function
P_LORA_PA_POWER	7	-	VFEM_Ctrl - Powers GC1109 LDO
P_LORA_PA_EN	2	CSD (pin 4)	Chip enable (HIGH=on)
P_LORA_PA_TX_EN	46	CPS (pin 5)	PA mode (HIGH=full PA, LOW=bypass)
-	DIO2	CTX (pin 6)	TX/RX path (automatic via SX126X_DIO2_AS_RF_SWITCH)

Summary of Changes

HeltecV4Board.cpp

• CPS toggling in callbacks: onBeforeTransmit() sets CPS=HIGH for full PA mode, onAfterTransmit() sets CPS=LOW
• Deep sleep: Hold all three FEM pins (PA_POWER, PA_EN, PA_TX_EN) to maintain RX wake capability
• Wake-up: Release holds with rtc_gpio_hold_dis() for all pins

platformio.ini

• Removed SX126X_RXEN and SX126X_TXEN - these caused a conflict where both RadioLib and our callbacks tried to control GPIO46
• Kept SX126X_DIO2_AS_RF_SWITCH=true - this is correct and handles CTX (TX/RX path) automatically

How It Works Now

1. TX/RX path switching: Handled automatically by SX1262 DIO2 → GC1109 CTX (hardware)
2. PA mode selection: Handled by our callbacks toggling GPIO46 (CPS)
   - 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)
3. Power sequencing: GPIO7 (LDO) → GPIO2 (CSD) → GPIO46 (CPS) per datasheet requirement

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

a8463655cfa23522c5bb93f3dae69746d642034149b79b7103b9f217850e53af  heltec_tracker_v2_main+RX_fix_companion_radio_ble.bin
e50e7a9d8987802382d09d8e1ca2ca738c8ca0dbfd9e31d65b4a54254a2b302d  heltec_tracker_v2_main+RX_fix_repeater.bin
5877ecca96c036ecdf4c1e2e74b1f2c4a3b45c25a65ff05c7c9aa855719421f8  heltec_v4_main+RX_fix_companion_radio_ble.bin
f5aebe63b2159b522768c9ef590bd30ae5a511e65f4c83dfa906a9b2e8782eb1  heltec_v4_main+RX_fix_repeater.bin

• 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
• 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

[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

[Quency-D]

Thanks! @Quency-D Just to confirm: from Heltec’s point of view, the LNA control-pin fix is not the solution, the register patch is the only correct path forward, right?

@spiralshapeturtle Modifying the registers can improve V4 reception, which we have tested extensively. However, we are not entirely certain whether modifying the LNA control pins is effective; further testing is needed to rule out any randomness.

[pon-wessel]

Thanks! @Quency-D Just to confirm: from Heltec’s point of view, the LNA control-pin fix is not the solution, the register patch is the only correct path forward, right?

@spiralshapeturtle Modifying the registers can improve V4 reception, which we have tested extensively. However, we are not entirely certain whether modifying the LNA control pins is effective; further testing is needed to rule out any randomness.

The main change in the LNA control is this we are not trying to fight with radiolib on the control of it.

[weebl2000]

@weebl2000 im more than happy to test when the 2nd V4 arrives could you hand me 3 repeater builds: 1 only with the register patch 1 only with the PR LNA fix 1 combined register and PR LNA fix

One more thing: could you also take a look at the disconnecting RS232 ports? You mentioned compiling with the USB flags discussed last week. As far as I know, RS232 might be enabled by default and only the packet logging flag needs to be set ad advised by letsmesh.net? So: is it correct that my RS232 disconnects are not caused by the extra compile flags?

Sure, I can build those.

Regarding the debug output intermittency, I haven't experienced this myself. What platform are you running on, Linux, Windows, Mac?

The v4 doesn't have a CP2102 USB <-> Serial converter like the v3 does. Instead, it uses the internal USB Serial/JTAG controller built into the ESP32. It behaves differently and will drop/reconnect when you reset the ESP32.

[spiralshapeturtle]

Thanks! @Quency-D Just to confirm: from Heltec’s point of view, the LNA control-pin fix is not the solution, the register patch is the only correct path forward, right?

@spiralshapeturtle Modifying the registers can improve V4 reception, which we have tested extensively. However, we are not entirely certain whether modifying the LNA control pins is effective; further testing is needed to rule out any randomness.

The main change in the LNA control is this we are not trying to fight with radiolib on the control of it.

Thats a nice overview! Thanks the only missing part is the "what does the register setting" from @Quency-D ?

---

Hope you are able to fulfill my wish below in a moment of spare time.

@weebl2000 im more than happy to test when the 2nd V4 arrives could you hand me 3 repeater builds:

1. 1 only with the register patch + -D MESH_PACKET_LOGGING=1
2. 1 only with the PR LNA fix + -D MESH_PACKET_LOGGING=1
3. 1 combined register(the correct way) and PR LNA fix + -D MESH_PACKET_LOGGING=1

One more thing: could you also take a look at the disconnecting RS232 ports? You mentioned compiling with the USB flags discussed last week. As far as I know, RS232 might be enabled by default and only the packet logging flag needs to be set ad advised by letsmesh.net? So: is it correct that my RS232 disconnects are not caused by the extra compile flags?

---

My second test which might contain #2 from the list above if im right Wessel?

Used heltec_v4_repeater_observer_mqtt-v1.11.0-localdev-respfix-e754317c.bin from here
The uptime counter is the moment of flashing, no big changes keep a note on the regular day/night flow of airtime.

[weebl2000]

One more thing: could you also take a look at the disconnecting RS232 ports? You mentioned compiling with the USB flags discussed last week. As far as I know, RS232 might be enabled by default and only the packet logging flag needs to be set ad advised by letsmesh.net? So: is it correct that my RS232 disconnects are not caused by the extra compile flags?

Locally I haven't had any issues with debug flags enabled. Can you check my post above: which platform are you reading the USB port from?

[spiralshapeturtle]

@weebl2000 im more than happy to test when the 2nd V4 arrives could you hand me 3 repeater builds: 1 only with the register patch 1 only with the PR LNA fix 1 combined register and PR LNA fix
One more thing: could you also take a look at the disconnecting RS232 ports? You mentioned compiling with the USB flags discussed last week. As far as I know, RS232 might be enabled by default and only the packet logging flag needs to be set ad advised by letsmesh.net? So: is it correct that my RS232 disconnects are not caused by the extra compile flags?

Sure, I can build those.

Regarding the debug output intermittency, I haven't experienced this myself. What platform are you running on, Linux, Windows, Mac?

The v4 doesn't have a CP2102 USB <-> Serial converter like the v3 does. Instead, it uses the internal USB Serial/JTAG controller built into the ESP32. It behaves differently and will drop/reconnect when you reset the ESP32.

It's connected to a Pi5 or Pi4 with Raspbian, with the regular letsmeshbuild they are both (T114 and v4) solid regarding RS232.

This is the build-yourself-guide

[weebl2000]

It's connected to a Pi5 or Pi4 with Raspbian, with the regular letsmeshbuild they are both (T114 and v4) solid regarding RS232.

I was also reading them from a rpi 3 and pi zero 2W, which didn't have issues of the USB serial disconnecting. Can you run sudo dmesg -w while you:

1. connect heltec v4
2. run meshcoretomqtt
3. wait for it disconnect
4. share the logs?

Btw: I've switched to using the serial port of the rpi now to try and reduce USB bus noise.

[spiralshapeturtle]

It's connected to a Pi5 or Pi4 with Raspbian, with the regular letsmeshbuild they are both (T114 and v4) solid regarding RS232.

I was also reading them from a rpi 3 and pi zero 2W, which didn't have issues of the USB serial disconnecting. Can you run sudo dmesg -w while you:

1. connect heltec v4
2. run meshcoretomqtt
3. wait for it disconnect
4. share the logs?

Btw: I've switched to using the serial port of the rpi now to try and reduce USB bus noise.

-T -w its an old log
[Sat Jan 10 19:42:16] usb usb1-port1: over-current change #1
[Sat Jan 10 19:42:16] usb usb3-port1: over-current change #1
[...]
[Sat Jan 10 19:43:56] usb 3-1-port4: cannot reset (err = -71)
[Sat Jan 10 19:43:56] usb 3-1-port4: Cannot enable. Maybe the USB cable is bad?
[...]
[Sun Jan 11 15:58:05] usb usb1-port2: attempt power cycle
[Sun Jan 11 15:58:11] xhci-hcd xhci-hcd.0: Timeout while waiting for setup device command
[Sun Jan 11 15:58:11] usb 1-2: device not accepting address 28, error -62

I could use these probably?

usbcore.autosuspend=-1
usbcore.use_both_schemes=y

But its stable with the letsmesh build, to be honest I don't think its related to my setup as the are now feeding all the data for 24hr plus without a glitch. I need to reflash the v4 to reproduced it, I can do but the file names does not clearly state which enhancements are embedded, which makes me guess which file relates to bullet 1,2,3.

My assumption is that it working fine if you only enable the packet logging in the new builds. Could that be the way forward, if it then does not work I can collect the logs instantly.

[spiralshapeturtle]

@weebl2000 analyzed some older logs:

your build
usb-Espressif_USB_JTAG_serial_debug_unit_90:<cut>-if00

letsmeshbuild
usb-Espressif_Systems_heltec_wifi_lora_32_v4__16_MB_FLASH__2_MB_PSRAM__90<cut>-if00

[weebl2000]

@weebl2000 analyzed some older logs:

your build usb-Espressif_USB_JTAG_serial_debug_unit_90:<cut>-if00

letsmeshbuild usb-Espressif_Systems_heltec_wifi_lora_32_v4__16_MB_FLASH__2_MB_PSRAM__90<cut>-if00

I'll build without DEBUG enabled, see if that fixes it for you. Which device did you configure in meshcoretomqtt .env? /dev/xxx

[weebl2000]

1. 1 only with the register patch + -D MESH_PACKET_LOGGING=1
2. 1 only with the PR LNA fix + -D MESH_PACKET_LOGGING=1
3. 1 combined register(the correct way) and PR LNA fix + -D MESH_PACKET_LOGGING=1

You can find them here

1. https://x230.weebl.me/public/turtle_1_semtech_only.bin
2. https://x230.weebl.me/public/turtle_2_rxfix_only.bin
3. https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin

$ sha256sum turtle*
2e4f79799b8471d8cb54376e5524c2f1ec2ebc41c99dd9253ca1f2ef70fbcc19  turtle_1_semtech_only.bin
282b33ca6d00e49ae0cec10980cff9ae023664639801b0bbab42ed015a0c54f3  turtle_2_rxfix_only.bin
30ef63fad262f9e7cd41bc8b693e3021a400c419be076d6d06390c28caa4d348  turtle_3_semtech+rxfix.bin

[spiralshapeturtle]

1. 1 only with the register patch + -D MESH_PACKET_LOGGING=1

2. 1 only with the PR LNA fix + -D MESH_PACKET_LOGGING=1

3. 1 combined register(the correct way) and PR LNA fix + -D MESH_PACKET_LOGGING=1

You can find them here

1. https://x230.weebl.me/public/turtle_1_semtech_only.bin

2. https://x230.weebl.me/public/turtle_2_rxfix_only.bin

3. https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin

$ sha256sum turtle*

2e4f79799b8471d8cb54376e5524c2f1ec2ebc41c99dd9253ca1f2ef70fbcc19  turtle_1_semtech_only.bin

282b33ca6d00e49ae0cec10980cff9ae023664639801b0bbab42ed015a0c54f3  turtle_2_rxfix_only.bin

30ef63fad262f9e7cd41bc8b693e3021a400c419be076d6d06390c28caa4d348  turtle_3_semtech+rxfix.bin

Your the best! Let met test tomorrow when I'm home 👍

[mark-veenstra-ait]

Hi my repeater is certainly deaf at the moment with an Heltec v4 in it. I am not able to test a v3 and v4 besides each other but I can flash this change on my repeater. At the moment I do not have a filter attached but I will as well. Can I flash this repeater software to test it: https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin? And can I do this through OTA with erase device disabled?

[pon-wessel]

Hi my repeater is certainly deaf at the moment with an Heltec v4 in it. I am not able to test a v3 and v4 besides each other but I can flash this change on my repeater. At the moment I do not have a filter attached but I will as well. Can I flash this repeater software to test it: https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin? And can I do this through OTA with erase device disabled?

Yep, that works. Optionally you can try this one, it includes all dev changes and also has the register patch: https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin

It's working pretty good for me so far.

[mark-veenstra-ait]

Yep, that works. Optionally you can try this one, it includes all dev changes and also has the register patch: https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin

It's working pretty good for me so far.

The link https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin does not work for me the other https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin does work. Is the non-working link wrong?

Does it matter if powersaving is on?

[weebl2000]

Yep, that works. Optionally you can try this one, it includes all dev changes and also has the register patch: https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin
It's working pretty good for me so far.

The link https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin does not work for me the other https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin does work. Is the non-working link wrong?

Does it matter if powersaving is on?

Strange, the link works for me. Powersaving doesn't matter much (unless you want to save power, heh)

[spiralshapeturtle]

Hi my repeater is certainly deaf at the moment with an Heltec v4 in it. I am not able to test a v3 and v4 besides each other but I can flash this change on my repeater. At the moment I do not have a filter attached but I will as well. Can I flash this repeater software to test it: https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin? And can I do this through OTA with erase device disabled?

Yep, that works. Optionally you can try this one, it includes all dev changes and also has the register patch: https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin

It's working pretty good for me so far.

I flashed it today with turtle_3_semtech+rxfix.bin. What does the version button tell you in the meshcore app? Mine still shows v1.11.0 November 2025, is that OK?

[weebl2000]

I flashed it today with turtle_3_semtech+rxfix.bin. What does the version button tell you in the meshcore app? Mine still shows v1.11.0 November 2025, is that OK?

Yes, for these builds I didn't bother changing the version numbers.

[spiralshapeturtle]

I flashed it today with turtle_3_semtech+rxfix.bin. What does the version button tell you in the meshcore app? Mine still shows v1.11.0 November 2025, is that OK?

Yes, for these builds I didn't bother changing the version numbers.

Thanks ;-) I need to document it myself, no problem but I forgot which one I flashed this morning gehehe

The USB RS232 is rock solid now!

[mark-veenstra]

Yep, that works. Optionally you can try this one, it includes all dev changes and also has the register patch: https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin
It's working pretty good for me so far.

The link https://x230.weebl.me/public/turtle_3_semtech+rxfix.bin does not work for me the other https://x230.weebl.me/public/heltec_v4_main+RX_fix_repeater.bin does work. Is the non-working link wrong?
Does it matter if powersaving is on?

Strange, the link works for me. Powersaving doesn't matter much (unless you want to save power, heh)

Indeed strange. Really can't download it always a 404 no matter which browser or wget command. Just not reachable. So I flashed the main+pr fix. It does not give me a different result as the normal release. Also not worse. I am situated 450meters from a gsm antenna. Once the weather is better I'll add a cavity as well. 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.

[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