🔧 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
2 times, most recently
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 |
Why not? |
|
because there is no way to turn off that LNA by command |
|
Rather than soldering a bypass, why not try this PR first? I see a huge improvement on RX with this PR, and so do others. 🤔 |
Tried this fix and yes, it improved RX. But it is still far away from receiving ability of V3. I think it is hard to fix a problem which is caused by hardware-architecture. Meanwhile, I reverted my V4 repeaters back to V3, because I have much better values with V3. |
Can you do a side-by-side comparison of v3 and v4 with actual amount of packets received with identical antenna? I think this is the only way to compare the performance. Just looking at noise floor values and such is not the proper way to test this. |
I already did (see some posts above) but I stopped my tests with V4. It is not longer installed and won't install it again. |
Thanks for your efforts. It's still really strange you are observing these issues, the v4 hardware should be superior to v3 hardware. |
|
@weebl2000 @stgruenbaum-hash did you read this https://wiki.heltec.org/news/v4-receive-sensitivity/v4-receive-sensitivity Just to check if you are comparing the right values ;-) |
Thanks. I've noticed signal values are hard to compare, so I compared the amount of packets received between a v3 and v4, and with this fix I can see better reception for v4 vs v3 (especially for weak signals), so I am convinced this PR fixes the issue, even though the dB values might not reflect this. |
|
@pon-wessel thanks my v4 is still somewhere between me and the customs ;-) Would be happy to test when it got delivered. I'm just surprised this fix/correct way of using the LNA was not embedded in the original code, and its not merged yet? Did Heltec take a look into this thread? |
I've shared the PR with them, not sure if someone technical looked at it but they replied positively. |
Yes, agree. I will try to compare this PR vs. a bypass. |
|
how do we get this PR under the correct attention of MeshCore dev's? |
I did also some range tests. Had my V3 and V4 Repeater on roof-top (same antennas) and went out with my mobile client. On a hill about 15km away, I reached both repeaters. But receiving SNR of V4 was only about -8 (V3 about 1). At next location (about 20km away) I still had a stable connection to my V3, but I did not reach my V4 anymore. Then I moved to a hill about 30km away. I still reached my V3, but not the V4. For me it looks like the LNA is poor quality and not very good tuned to the required frequency. |
|
For anyone that is interested, here is a custom build with a register patch that might affect SX1262 receive sensitivity. This was suggested by Semtech. |
|
I have been running this version on a new V4 for a week or so after replacing a V3, unfortunately I didn't make a note of the metrics before the change but I've not noticed any degradation compared to the V3. Great work! |
Sorry I do need some more information before loading builds to my hardware, could you elaborate a bit more? Does this count for all the SX1262's out in the field, or does it only contribute to your LNA enhancements? Any link where we can read from the same source as you? |
I'm not sure what it does. But all that is different is an undocumented register is set to 0x01. I have no clue what this register does, I'm guessing only Heltec/Semtech knows - I can try to find out. |
|
@weebl2000 thanks for reporting back, if they wrote this tip to you it could be useful to ask further. Which register is changed? |
I reverse engineered it so I'm not 100% sure but I think it's 0x08B5 |
https://m5stack-doc.oss-cn-shenzhen.aliyuncs.com/1198/DS_SX1261_2_V2-2.pdf
Could it be 0x08AC? |
|
|
just like dt267 I know it's not very effective, but it works... yes V4 power and SX1262 reception
|
of course I used it, but the noise floor was never lower than -90dB... and the sensitivity did not exceed 0dB |
In what file are these changes? |
You wrote "V4 power"But... the CG1109 is boosting TX as well if I read well on Reddit, does that still work? The SX1262 is only capable of 20dBm if I recall well so who is pumpingup to 27dBm? |
CustomSX1262.h |
bypass only bypasses the receiving LNA |
tnx, I'll try it on the second v4 ps. and this doesn't sometimes turn off rx boost sx1262? I tried with a software fix: I didn't notice any improvement apart from a statistical error... for me only ByPass... what will I do in the second V4 best regards |
I'm not sure what it does exactly, the register is undocumented. I will try to find out. |
|
After a lot of tinkering the results are starting to look promising: 5 packets more received on the V4. But I will observe for longer. If anyone wants to test, I've just updated the link with the firmwarew I'm now running:
Test setup: |
In fact, it reads, modifies, and writes. Below is the location of the modification. It can be placed directly during initialization, or it can be placed before each reception cycle begins. uint8_t r_data = 0;
readRegister(0x8B5, &r_data, 1);
r_data |= 0x01;
writeRegister(0x8B5, &r_data, 1);int16_t SX126x::begin(uint8_t cr, uint8_t syncWord, uint16_t preambleLength, float tcxoVoltage, bool useRegulatorLDO) {
// BW in kHz and SF are required in order to calculate LDRO for setModulationParams
// set the defaults, this will get overwritten later anyway
this->bandwidthKhz = 500.0;
this->spreadingFactor = 9;
// initialize configuration variables (will be overwritten during public settings configuration)
this->bandwidth = RADIOLIB_SX126X_LORA_BW_500_0; // initialized to 500 kHz, since lower values will interfere with LLCC68
this->codingRate = RADIOLIB_SX126X_LORA_CR_4_7;
this->ldrOptimize = 0x00;
this->crcTypeLoRa = RADIOLIB_SX126X_LORA_CRC_ON;
this->preambleLengthLoRa = preambleLength;
this->tcxoDelay = 0;
this->headerType = RADIOLIB_SX126X_LORA_HEADER_EXPLICIT;
this->implicitLen = 0xFF;
// set module properties and perform initial setup
int16_t state = this->modSetup(tcxoVoltage, useRegulatorLDO, RADIOLIB_SX126X_PACKET_TYPE_LORA);
RADIOLIB_ASSERT(state);
uint8_t r_data = 0;
readRegister(0x8B5, &r_data, 1);
r_data |= 0x01;
writeRegister(0x8B5, &r_data, 1);
Serial.println("SX126x begin 0X8B5 enabled"); |
17 participants
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)
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