add heltec v4.3 board

[Quency-D]

1. This is the schematic diagram for v4.3.
2. The main difference between v4.2 and v4.3 is the different fem and the different control pins of the fem.
3. You can identify whether it is v4.2 or v4.3 by the default pull-up and pull-down resistors of GPIO2.
4. The fem control code is centralized into a single file.

[Quency-D]

Hi @weebl2000, I've tested and organized it, and I still think it's simpler to separate the fem control into a separate file. Do you have any other suggestions?

[weebl2000]

Hi @weebl2000, I've tested and organized it, and I still think it's simpler to separate the fem control into a separate file. Do you have any other suggestions?

Make sure the FEM keeps power when it's enabled and the ESP32 is sleeping. See also PR #1600, it's not merged to dev yet.

Other than that go for it. Let me know if I can help out reviewing!

[Quency-D]

Make sure the FEM keeps power when it's enabled and the ESP32 is sleeping. See also PR #1600, it's not merged to dev yet.

Other than that go for it. Let me know if I can help out reviewing!

Thanks for the reminder, I've added this feature.

void LoRaFEMControl::setRxModeEnableWhenMCUSleep(void)
{
    digitalWrite(P_LORA_PA_POWER, HIGH);
    rtc_gpio_hold_en((gpio_num_t)P_LORA_PA_POWER);
    if(fem_type==GC1109_PA) {
        digitalWrite(P_LORA_GC1109_PA_EN, HIGH);
        rtc_gpio_hold_en((gpio_num_t)P_LORA_GC1109_PA_EN);
        gpio_pulldown_en((gpio_num_t)P_LORA_GC1109_PA_TX_EN);
    } else if(fem_type==KCT8103L_PA) {
        digitalWrite(P_LORA_KCT8103L_PA_CSD, HIGH);
        rtc_gpio_hold_en((gpio_num_t)P_LORA_KCT8103L_PA_CSD);
        if(lna_enabled) {
            digitalWrite(P_LORA_KCT8103L_PA_CTX, LOW);
        } else {
            digitalWrite(P_LORA_KCT8103L_PA_CTX, HIGH);
        }
        rtc_gpio_hold_en((gpio_num_t)P_LORA_KCT8103L_PA_CTX);
    }
}

[weebl2000]

Regression Review vs #1857 and #1600

This PR adds V4.3 (KCT8103L) support via a LoRaFEMControl abstraction — nice idea to centralize FEM control. However, it regresses several critical behaviors established by #1857 and #1600. Details in the inline comments below.

Summary

#	Issue	Severity	Regression vs
1	KCT8103L stuck in TX mode during RX (no LNA)	CRITICAL	#1857
2	rtc_gpio_hold_dis before pinMode causes glitch on deep sleep wake	HIGH	#1600
3	Unconditional 1ms delay (includes deep sleep wake)	MEDIUM	#1600
4	Blanket hold release for all pins regardless of FEM type	LOW	#1857

[weebl2000]

Suggested fixes for the issues identified above.

[weebl2000]

Additional suggestions (header default + deep sleep path).

[weebl2000]

The pin holding isn't correct when sleeping. Other than that I highly suggest to always have LNA enabled by default. It should only be disabled if it's causing issues and AGC reset (see PR #1743) doesn't fix it.

[Quency-D]

Additional suggestions (header default + deep sleep path).

Could you elaborate a bit more? I didn't understand what you meant.

[AI7NC]

The pin holding isn't correct when sleeping. Other than that I highly suggest to always have LNA enabled by default. It should only be disabled if it's causing issues and AGC reset (see PR #1743) doesn't fix it.

So long as the user has the ability to disable the LNA in the settings. That's the primary benefit to this new variant of the v4.

@towerviewcams

[towerviewcams]

So long as the user has the ability to disable the LNA in the settings. That's the primary benefit to this new variant of the v4.

@towerviewcams

Not totally true, if you look at the release notes they have improved the ADC power systems for standby efficiency. improved reverse polarity bla bla and the KCT8103L has a better noise figure then the GC1109 did. It remains to be seen on all this, but, as you stated the LNA control alone makes this huge and turn key for less tech folks. Hopefully however there is more benefit. even just a couple of mA would be huge. fingers crossed