XIAO nRF52840 + Wio-SX1262 (LoRa-E5?) - Fails to Compile or Join LoRaWAN after Extensive Debugging

Excellent Forum Solutions XIAO
4

Hello,

Thank you for the suggestion. A community member provided me with a set of LoRa P2P (Point-to-Point) sketches to test the basic functionality of the hardware, independent of the LoRaWAN network.

I have tested these sketches, and here are the results and my analysis.

P2P Test Setup

  • Hardware: Two identical setups, each with a XIAO nRF52840 + Wio-SX1262 shield.
  • Software:
    • One board was flashed with the provided SX1262_XIAOs_P2P_TX.ino sketch.
    • The other board was flashed with the SX1262_XIAOs_P2P_RX.ino sketch.
  • Key Observation from Code: I noticed that these P2P sketches do not use the special RF switch configuration lines (radio.setDio2AsRfSwitch(true); and radio.setRfSwitchPins(...)). They rely only on the basic 4-pin Module constructor.

P2P Test Result

The P2P test failed.

  • The TX sketch runs and reports “TX success!” in the Serial Monitor.
  • The RX sketch runs but never receives any packets; it continuously shows “RX timeout!”.

This was tested with the devices placed right next to each other.

Updated Analysis & Core Problem

This P2P test failure, even with the simplified code, reinforces our main problem. The fact that my identical hardware works perfectly with Meshtastic proves that the hardware itself is not faulty. Meshtastic must be performing a specific, low-level initialization sequence or radio configuration that is missing from the standard RadioLib examples (both P2P and LoRaWAN).

The P2P code fails for the same reason our LoRaWAN code fails: the radio is not being correctly configured to transmit, even though radio.begin() and radio.transmit() report success. The RF signal is likely never leaving the antenna with sufficient power.

My original questions therefore still stand, but can be refined:

  1. What is the specific, low-level radio initialization sequence that Meshtastic uses for the XIAO nRF52840 + Wio-SX1262 combination that is missing from the standard RadioLib library examples?
  2. Is it confirmed that my shield contains a LoRa-E5 module? If so, why does a RadioLib SPI-based sketch (like the P2P example) even pass the radio.begin() check? An SPI library should fail to initialize a UART-based module. This is very confusing.
  3. We are also still facing a fundamental build environment issue on multiple computers where even a simple sketch fails to compile for the XIAO nRF52840 with an undefined reference to 'Serial' error. This prevents us from testing the UART/AT-command approach for the LoRa-E5.

It seems there is a deeper issue with either the RadioLib implementation for this specific hardware, or a fundamental problem with the Arduino board package for the XIAO nRF52840 that is causing both the RF issues and the compilation errors.

Any guidance on the specific radio configuration needed would be greatly appreciated.

Thank you.