Unless your GPS is being spoofed there isn't really a downside to
syncing more often with GPS.
I understand the RTC is very stable, but especially with powersaving now
clock drift is worse, we should sync more often.
- Change > to >= so stored value 1 means direct/0-hop only (liamcottle)
- Clamp max_hops to 63 on write since getPathHashCount() caps at 63 (robekl)
- Update comments to reflect encoding: 0=no limit, 1=direct only, N=up to N-1 hops
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Filter auto-add of new contacts by hop count (issues #1533, #1546).
Setting is configurable from the companion app via extended
CMD_SET/GET_AUTOADD_CONFIG protocol (0 = no limit, 1-63 = max hops).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
On the T114, GPS_RESET (pin 38) is the same pin as PIN_3V3_EN.
MicroNMEALocationProvider::begin() sets pin 38 HIGH (powering the 3V3
rail) but stop() never set it back LOW, leaving the GPS module powered
even when disabled.
Assert reset pin in stop() to mirror begin(), and guard
_location->loop() behind gps_active check.
Fixesmeshcore-dev/MeshCore#1628
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.
1. warm sleep
2. wake to stdby
3. Calibrate(0x7F) to reset all internal blocks
4. re-apply DIO2 RF / boosted gain & register patch to make sure
everything is as it was
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.
* companion: new field in CMD_SET_OTHER_PARAMS, path_hash_mode
* companion: CMD_SEND_SELF_ADVERT, cmd_frame[1] now holds the path hash size (0 = zero hop, 1..3 = flood path hash size)
