[Heltec WiFi LoRa 32 V4] Need Help: Custom firmware TX reports success but RX never receives (Heltec V4 → Heltec V4)

[mitrozo]

Hello Community,

I'm working on a custom LoRa project with two Heltec WiFi LoRa 32 V4 boards and have run into a frustrating issue that I can't solve despite extensive testing. I'm hoping someone here can help me figure out what I'm missing!

The Problem
I have two Heltec WiFi LoRa 32 V4 boards that work perfectly with Meshtastic firmware (bidirectional communication, good RSSI/SNR values). However, when I use custom firmware (RadioLib + raw SX1262 initialization), the TX side always reports success but the RX side never receives any packets.

✅ With Meshtastic: Both boards communicate perfectly

❌ With custom firmware: TX reports ERR_NONE, but RX never sees packets

❌ This happens even at very close distance (< 1 meter)

This is a simple Heltec V4 → Heltec V4 point-to-point test, no other devices involved.

My Hardware Setup
2 × Heltec WiFi LoRa 32 V4 (ESP32-S3 + SX1262 + GC1109 front-end, EU868 version)

PlatformIO, Arduino framework, RadioLib 7.4.0, U8g2

Original 868 MHz antennas supplied with the boards

Both boards are identical hardware

LoRa Parameters (Identical on Both Boards)
I'm using the same parameters on both TX and RX:

Frequency: 869.525 MHz
Bandwidth: 250 kHz
Spreading Factor: 11
Coding Rate: 4/8
Sync Word: 0x12 (Meshtastic private network)
Preamble: 8
Header: explicit
CRC: enabled
TX Power: 22 dBm
Both boards call radio.begin(869.525, 250.0, 11, 8, 0x12, 22, 8) followed by radio.setCRC(true) and radio.explicitHeader().

Pin Configuration (from Heltec V4 documentation)

// SX1262 SPI pins
LORA_SCK = 9
LORA_MISO = 11
LORA_MOSI = 10
LORA_NSS = 8
LORA_DIO1 = 14
LORA_RST = 12
LORA_BUSY = 13

// GC1109 Front-end control
FEM_EN = 2 // CSD - Frontend enable (set HIGH)
FEM_PA = 46 // CTX - TX/RX switch (controlled by DIO2?)
My Initialization Sequence
Based on research in Meshtastic source code and community forums, I've implemented this initialization on both TX and RX:

1. Hardware Reset

Pull RST low, then high, wait for BUSY to go low

2. Raw SX1262 Commands (before RadioLib begin!)

SetDio3AsTcxoCtrl (0x97) // 3.3V TCXO, ~2.5ms delay
SetDio2AsRfSwitch (0x9D, 0x01) // Auto RF switch via DIO2
SetStandby (0x80) // STDBY_RC
SetRegulatorMode (0x96, 0x00) // DC-DC mode
Calibrate (0x89, 0x7F) // Calibrate all
CalibrateImage (0x98, 0xE1, 0xE9) // 860-880 MHz
SetPaConfig (0x95, {0x04, 0x07, 0x00, 0x01}) // High power
SetTxParams (0x8E, {0x1F, 0x03}) // 31 = 22dBm + 9 offset
SetBufferBaseAddress (0x8F, {0x00, 0x00})
3. GPIO Setup

digitalWrite(FEM_EN, HIGH); // GC1109 permanently enabled
4. RadioLib Initialization

radio.begin(869.525, 250.0, 11, 8, 0x12, 22, 8);
radio.setCRC(true);
radio.explicitHeader();
5. TX Loop

radio.transmit("HELTEC_" + String(count));
// Always returns ERR_NONE, realistic TX duration
6. RX Loop

radio.startReceive(); // Called once in setup()
// In loop():
if(radio.available()) {
radio.readData(msg); // Never called - available() is always false
}
What I've Already Tested
I've spent 15+ hours debugging this and tried:

Different TCXO voltages: 1.7V, 2.4V, 3.0V, 3.3V with various delays

Different SyncWords: 0x12 and 0x34, matching on both sides

With/without DIO2 RF switch: Manual GPIO46 control vs automatic DIO2

Different power levels: 0-22 dBm

Initialization order: Raw init before/after RadioLib begin

Role swap: Tested both boards as TX and RX

Frequency variations: 868.0 MHz, 869.525 MHz

Parameter variations: Different SF/BW combinations

CPS pin tests: Tried GPIOs 3, 4, 5, 6, 7, 45, 47 set HIGH (no CPS found in V4 docs)

Result: Always the same - TX reports success, RX never receives anything.

What Works vs. What Doesn't
✅ Works perfectly:

Meshtastic on both boards (bidirectional, good RSSI/SNR)

This proves the hardware, antennas, and RF path are functional

❌ Doesn't work:

Custom firmware on both boards (identical parameters)

TX side shows success, RX side shows nothing

No packets at any distance, even touching antennas

My Questions
I would really appreciate help with these questions:

Is there a known-good minimal example for Heltec V4 ↔ V4 point-to-point LoRa?
Even pseudo-code or key settings would help!

Is my SX1262 + GC1109 initialization sequence correct for V4?
Specifically the TCXO, DIO2, and PA configuration?

Is DIO2 really wired to GC1109 CTX on the V4?
Should SetDio2AsRfSwitch handle the TX/RX switching automatically?

Is there a hidden CPS pin or other GC1109 control pin I'm missing?
The GC1109 datasheet mentions CPS (power select) but I can't find it in V4 docs.

Could RadioLib be overwriting my raw SX1262 settings?
Is there a V4-specific way to use RadioLib that preserves the critical settings?

What TCXO voltage does the V4 actually use?
I've tried 1.7V, 2.4V, 3.0V, and 3.3V without success.

Additional Info
The boards are definitely functional - Meshtastic proves this

I've verified with a logic analyzer that SPI commands are being sent correctly

Status registers show no errors after initialization

Both TX and RX init sequences complete successfully

I'm clearly missing something that Meshtastic does correctly but I haven't replicated. Any insights, code examples, or schematic details for the Heltec V4 would be incredibly helpful!

Thank you in advance for any guidance! 🙏

[StevenCellist]

To address half of the post:

Could RadioLib be overwriting my raw SX1262 settings?

Yes, definitely. RadioLib takes full control over the radio to prevent people from doing whatever a GPT tells them to do.

To address the other half of the post:
As Nick pointed out on the TTN forum, the GC1109 needs some special care. You found half of it (the CPS pin), but the PA also has an enable pin.

I'm fortunate enough to have received a V4 and I did try it out at some point. The code is somewhere on my PC, I hope to remember to dig it up before going on holiday.
Until then, you can help yourself by looking at the schematic from Heltec and the GC1109 datasheet.

And a general remark: while you provide lots of useful details, your LLM of choice does repeat quite some stuff which makes it a bit confusing and harder to read. If at all possible, please read through the post as a user unknown to your problem before posting :)

[todormitrovic]

First of all, thanks a lot for your detailed reply and for clearly explaining that RadioLib takes full control over the SX1262 configuration – that fully answered my question about it potentially overwriting my raw register settings. The hint about the GC1109 front-end (CPS and PA enable) and your suggestion to study both the Heltec schematic and the GC1109 datasheet were very helpful and gave me a much better understanding of the hardware side.
​
Based on your feedback, I reworked my setup and now have a reliable Heltec V4 ↔ Heltec V4 point-to-point link running with RadioLib.
​
What changed / what works now
I stopped “fighting” RadioLib with custom SX1262 raw commands.
Initialization is now done by RadioLib only (no more manual SetDio… sequences before begin()).
​
Heltec V4 pins are configured as:
SX1262: SCK = 9, MISO = 11, MOSI = 10, NSS = 8, DIO1 = 14, RST = 12, BUSY = 13.
GC1109 front-end: FEM_EN (CSD) on GPIO2, set HIGH permanently to enable the front-end.
​
In RadioLib I use:
SX1262 radio = new Module(8, 14, 12, 13); // NSS, DIO1, RST, BUSY
radio.begin(869.525, 250.0, 11, 8, 0x12, 22, 8);

radio.setCRC(true);

radio.explicitHeader();

For testing, I started from the SX126x_Transmit_Interrupt and SX126x_Receive_Interrupt examples and only changed frequency, sync word, and payload.
​

With this setup, two Heltec V4 boards can reliably exchange packets on EU868 at short range, which shows that RF path and GC1109 control on the V4 side are working correctly.
​

In short: once I let RadioLib fully handle the SX1262 configuration and only managed the GC1109 enable line on GPIO2, the V4 ↔ V4 link became stable.
​

New behaviour with Waveshare SX1262
After that, I started testing with a Waveshare SX1262 module (868 MHz). The Heltec V4 side still uses the RadioLib setup described above, and the Waveshare side also runs RadioLib with matching LoRa parameters (frequency, SF, BW, CR, preamble, sync word, CRC).
​

The key tests and results are:

Heltec V4 (H1) → Heltec V4 (H2):
With the RadioLib configuration mentioned above, H1 and H2 communicate reliably in both directions.
​

Waveshare → Heltec V4 (H2):
When the Waveshare SX1262 module transmits, the Heltec V4 (H2) receives these packets successfully, as long as both sides share identical LoRa settings (frequency, SF, BW, CR, preamble, sync word, CRC).
​

Heltec V4 (H1) → Waveshare:
When H1 transmits, RadioLib reports RADIOLIB_ERR_NONE and the TX duration looks realistic, but the Waveshare module does not receive any packets: no payload, no IRQ, and no visible change in RSSI/SNR, even with the antennas very close together.
​

So at the moment the picture looks like this:

Heltec V4 (H1) → Heltec V4 (H2): works.
Waveshare → Heltec V4 (H2): works.
Heltec V4 (H1) → Waveshare: does not work.

This suggests that the Heltec receiver can handle both transmitters, but the Waveshare receiver has an issue with the signal produced by H1, even though the LoRa parameters are nominally identical.
​

Concrete questions
Given this behaviour, I would really appreciate your thoughts on a few points:

Is there anything in RadioLib’s SX1262 configuration that could implicitly assume a certain RF front-end / RF switch wiring (like the GC1109 on the Heltec V4) that might not match the Waveshare board layout?
​

Are you aware of any “gotchas” with Waveshare SX1262 boards when used with RadioLib, such as needing an explicit setRfSwitchPins() call or specific handling of DIO2 for RF switching?
​

Would you recommend a minimal RadioLib configuration or example that is known to work with a “plain” SX1262 module (no special FEM like the GC1109), so I can verify that the Waveshare module behaves like a reference design?
​

If you manage to find your Heltec V4 test code at some point, I would still be very interested in seeing how you configured the Module instance and any RF switch / FEM pins in that setup.
​

And regarding your remark about LLM-style repetition: fair point – I am trying to keep this post much more compact and focused compared to my original wall of text.

[StevenCellist]

Still on holiday.. hope to check out my code by end of this week.

The obvious question: did you try swapping H1 and H2 in the two latter tests? Maybe something happened to H1?

[todormitrovic]

Yes, I did that test as well – just to be sure nothing was “special” about H1.

When I swap the roles of the two Heltec V4 boards, Heltec ↔ Heltec still works fine in both directions.

And regardless of which Heltec board is used as the transmitter, the situation stays the same:

Waveshare → Heltec: works

Heltec → Waveshare: does not receive anything

So it does not seem to be a hardware issue with a specific Heltec board, but rather something about how the Heltec‑generated signal is interpreted (or not interpreted) by the Waveshare receiver.

Looking forward to your code once you’re back from holiday – enjoy the break in the meantime!

[StevenCellist]

What is the distance between your boards? Can you parse the RSSI and SNR in the working setups? Note that LoRa stands for Long Range, which may cause problems at Very Short Range.

It may be something with the code, but given that it mostly works, I'd also check out other stuff like this.

[iMRUM]

Have you tried Waveshare → Waveshare? Is the rx interrupt triggered?

[PFalko]

Same symptom on a Heltec V4.2 (GC1109) via the ESPHome sx126x driver: V4-as-TX decodes cleanly at a V3 peer, but V4-as-receiver gets 0 decodes on a ~360 m NLOS link even after porting the Meshtastic FEM state machine and the 0x8B5 patch — short/strong RX works, marginal long-range RX never locks. Reinforces the "test very short range" point here: I have not found any configuration where V4 RX matches a V3 at range.