Enable GPS time synchronization across all variants by passing
&rtc_clock to MicroNMEALocationProvider. When GPS gets a valid
fix, the RTC clock is now updated automatically every 30 minutes.
Updated 16 variants: rak4631, lilygo_tbeam_SX1262, rak_wismesh_tag,
lilygo_tbeam_supreme_SX1262, thinknode_m3, heltec_v4, thinknode_m1,
lilygo_tbeam_SX1276, meshadventurer, nano_g2_ultra, heltec_v3,
promicro, xiao_c3, heltec_tracker_v2, keepteen_lt1, heltec_mesh_solar.
Pin mapping verified against HTIT-Tracker V0.5 schematic:
- GPIO35 (GPS_EN): N-ch MOSFET drives P-ch high-side switch, active HIGH
- GPIO36 (GPS_RST): hardware reset, active LOW
- GPIO33/34: UART TX/RX
Delegates power management to MicroNMEALocationProvider begin()/stop()
which independently controls GPS power via GPS_EN and shares VEXT with
the display through RefCountedDigitalPin.
The RAK13302 1W module uses a Skyworks SKY66122-11 front-end module with
three digital control pins (CSD, CTX, CPS) that must be actively driven
by the host MCU. The previous code only managed CTX (GPIO 31) — toggling
it for TX/RX — but never initialized CSD (GPIO 24) or CPS (GPIO 21),
leaving them floating with no pull-up/pull-down resistors on the PCB.
With floating CSD and CPS, the SKY66122 was in an undefined operating
mode:
- The 30 dB TX PA may not have been reliably engaging
- The 16 dB RX LNA was never reliably active, degrading receive
sensitivity
The GC1109 FEM needs its VFEM_Ctrl pin held HIGH during deep sleep
to keep the LNA active, enabling proper RX sensitivity for
wake-on-packet. Without this, the LNA is unpowered during sleep
and RX wake sensitivity is degraded by ~17dB.
Release RTC holds in begin() after configuring GPIO registers
(not before) to ensure glitch-free pin transitions on wake.
Trade-off: ~6.5mA additional sleep current for significantly
improved wake-on-packet range.
This change addresses two issues. The first is that the
LilyGo_TLora_V2_1_1_6_terminal_chat build would try to compile
simple_repeater/MyMesh.cpp. All other examples of terminal chat
targets are instead building simple_secure_chat/main.cpp . This
change would align this build to the rest of the builds.
The second issue, found during the course of investigating the
first, stems from simple_repeater/MyMesh.cpp using the
MAX_NEIGHBOURS #define to control whether the neighbor list is kept.
Repeaters that keep this list must define this value, and if the
value is not defined, then all neighbor-related functionality is
compiled out. However, the code that replies to
REQ_TYPE_GET_NEIGHBOURS did not properly check for this #define,
and thus any target that compiles simple_repeater/MyMesh.cpp
without defining MAX_NEIGHBOURS would get an undefined variable
compilation error.
As a practical matter though, there are no targets that compile
simple_repeater/MyMesh.cpp AND do not define MAX_NEIGHBOURS,
except this build due to the first issue. As a result, the
second issue is addressed only as a matter of completeness. The
expected behavior with this change is that such a repeater would
send a valid reply indicating zero known neighbors.
