[Feature request] NiceRF LoRa2021 (LR2021 Gen 4) variant support

[c03rad0r]

Use Case

I have working MeshCore firmware running on the NiceRF LoRa2021 module (Semtech LR2021 Gen 4 chip) paired with an ESP32-C3_Mini_V1 development board. I would like to contribute this as a new board variant.

Hardware

• NiceRF LoRa2021: 19.72x15mm module, Semtech LR2021 Gen 4 chip
• Dual-band: Sub-GHz (150-960 MHz) + 2.4 GHz LoRa/FLRC/GFSK
• ESP32-C3_Mini_V1: Maker go, 22.52x18mm, USB-C, 4MB flash, ~$4
• Total cost: ~$8 (MCU + radio module)

RadioLib Support

The LR2021 uses RadioLib's LR2021 class (extends LRxxxx → PhysicalLayer). This is already in RadioLib v7.6.0 which MeshCore depends on.

Important: This is a different RadioLib class from LR1121 (extends LR11x0). The LR2021 and LR1121 are separate chips. PRs #2696 and #2198 add LR1121 support — this request is for LR2021, which is additive.

Test Results

I have this running on real hardware:

• ✅ Radio init succeeds
• ✅ Noise floor: -102 dBm stable
• ✅ Companion connects via meshcore-cli v1.5.7
• ✅ Ed25519 identity generated
• ✅ Advert TX verified
• ✅ All build targets compile (companion, repeater, chat, KISS, room server)
• ✅ No regressions on reference builds

Implementation

Following the established pattern (CustomLR1110.h + CustomLR1110Wrapper.h + variants/):

class CustomLR2021 : public LR2021 {
    // irqDioNum = 9 (LR2021 uses DIO9 for IRQ, not DIO1)
    // getPacketLength() override (header error handling, like LR1110)
    // std_init() with tcxoVoltage=0 (XTAL, not TCXO)
};

Key differences from SX1262:

• IRQ on DIO9 → irqDioNum = 9 + setDioFunction(9)
• setRxBoostedGainMode(uint8_t 0-7) vs bool
• No DIO2-as-RF-switch (NiceRF module handles RF switching internally)
• Crystal oscillator, not TCXO

One Notable Deviation

Arduino's SPIClass returns all-zero responses on the ESP32-C3_Mini_V1 with non-default SPI pins. Direct ESP-IDF spi_bus_initialize() works fine. My variant includes a custom EspIdfHal.h that uses ESP-IDF SPI directly. I am happy to investigate this further or remove it if there is a better approach.

Ask

Would you accept a PR adding this variant? I have clean code ready targeting the dev branch, with all builds passing and hardware testing done.

Related: #2678 (2.4 GHz — LR2021 also supports this), #2441 (multi-radio — LR2021 is dual-band)

[c03rad0r]

Update: I have successfully tested the LR2021 variant with the Berlin MeshCore community mesh. I discovered community relays and contacts, and interacted with users multiple hops away via the public group channel. This confirms multi-hop flood routing and interoperability with the existing MeshCore infrastructure on standard EU PHY settings (869.618 MHz, SF8, BW62.5, CR4/5).

[carlhodder]

I'm also testing this out (LR2021) and have a few things I'd mention in case we want to discuss them further.

1. The maturity of the RadioLib implementation
   e.g. just last night the main branch patched a bug that meant it would reject any packets larger than the last successful transmitted packet with a CRC error.
   Should we wait for a signal of maturity from the team there?

2. Potential clock issues
   Do we want to block some configurations from repeater builds? e.g. urban areas using the 62.5KHz BW may start to get into trouble with outdoor units at temperature extremes without either a TCXO, or the NTC temp compensation enabled (which the base niceRF module does not populate, I removed the shield to check).

3. Sticky interrupt issues
   The other issue I've yet to solve is around interrupts. What I'm observing is that an incomplete packet can set the preamble and header valid bits without reaching the RX done while in RX mode which would clear the interrupts. This means that the following TX event will timeout waiting for a clear channel before transmitting as these flags are set which I imagine is not good for the network if it can't properly time transmissions.

[axhoff]

Pushing this issue because I would love support for the LR2021 chip as the MeshTracker X1 is being shipped soon.