Ben MeadorsandWayenWeng d4bb6eea91 fix(gps): wake AG3335 from software RTC sleep (#11889)
* fix(gps): wake AG3335 from software RTC sleep

On the Airoha trackers, GPS_HARDSLEEP simply dropped PIN_GPS_EN. Cutting VCC
with no prior command leaves the receiver in hardware RTC mode, from which
nothing in the firmware ever brings it back: the only Airoha wake sequence
that existed, wakeAirohaForActiveProbe(), is reachable from probe() alone and
never from the normal GPS_HARDSLEEP -> GPS_ACTIVE transition. The tracker
stops producing fixes until it is rebooted.

Park the receiver in software RTC mode with $PAIR650,0 before the power cut,
and pulse GPS_RTC_INT after VCC comes back to bring it out again. The receiver
may already have auto-slept and missed the first command, so it is resent
until it acks, bounded at 400 ms rather than repeated a fixed number of times:
setPowerState() runs on the GPS thread and from the notifyDeepSleep observer,
and every mesh thread shares loopTask on nRF52, so an unconditional wait here
stalls LoRa servicing, the screen and buttons for its full duration on every
sleep cycle, on top of holding the receiver powered that much longer.

The RTC_INT pulse becomes a shared helper so the probe path and the power
state machine no longer carry separate copies, and the wake is guarded on
GPS_RTC_INT as well as GNSS_AIROHA, since the family flag is not a promise
that the board routed that line.

Also drops the raw digitalWrite(PIN_GPS_EN, LOW) calls that followed
writePinEN(false) in GPS_HARDSLEEP and GPS_OFF, and the one in
toggleGpsMode(). writePinEN() already drives the pin through the GpioVirtPin
chain built in createGps(); the raw writes duplicated it while bypassing both
that abstraction and the RAK4631/WISMESH_TAP guard inside writePinEN().

Affects tracker-t1000-e, seeed_mesh_tracker_X1 and wio-t1000-s.

Co-Authored-By: WayenWeng <jinyuan.weng@seeed.cc>

* fix(gps): keep the $PAIR650 retry inside its stated budget

The while-condition was evaluated after getACK, so a final attempt starting
just under the budget could add another ack window on top of it. Stop starting
attempts once a whole window no longer fits, which makes 400 ms a real ceiling
rather than a soft one.

* fix(gps): gate the AG3335 park on a wake path, the probed model, and a miss count

Review found three holes in the soft-RTC park, all from review by Thomas
Goettgens.

The sleep was guarded on GNSS_AIROHA while the wake was guarded on
GNSS_AIROHA && GPS_RTC_INT, so a board that did not route RTC_INT would have
been parked with no way back out - worse than the bare power cut this is
meant to fix. Both now derive from a single HAS_AIROHA_SOFT_RTC, so they
cannot be guarded separately again.

The retry stamped 'start' from raw millis() but tested it with
Throttle::isWithinTimespanMs, which reads Time::getMillis(). Under
Time::setTestMillis() the two diverge and the loop either falls through or
never exits; getACK just below already uses the injectable clock.

The park was gated only at compile time, so a probe that fell back to
GENERIC_NMEA would still be sent PAIR650 and block for the full budget every
cycle. It now checks the probed model the way the constellation setup at
L975 does, and gives up after three consecutive unacked sleeps so a receiver
that is present but wedged cannot stall loopTask indefinitely.

* fix(gps): drive the Airoha probe wake from the capability, not the board

Requested by Manuel Verch. wakeAirohaForActiveProbe() asserted EN and pulsed
RTC_INT only under TRACKER_T1000_E, so seeed_mesh_tracker_X1 and wio-t1000-s
got a bare $PAIR382 during probe even though both route the same pins. Keying
it on HAS_AIROHA_SOFT_RTC gives every board that routed RTC_INT the physical
wake, which is what the probe's own hardware reset needs undone, and lets a
future variant opt in by declaring the pins rather than by name.

The 1000 ms $PAIR382 repeat loop goes with it: it was compensating for the
pulse being absent at this point, so a single command after the pulse is
enough, and T1000-E boots a second sooner.

A board that declares GNSS_AIROHA without routing RTC_INT keeps the bare
command. Waking and parking must match, per the previous commit, but probing
only reads, so it cannot strand the receiver the way the park can. The EN
write is guarded on PIN_GPS_EN the way createGps() already guards its own.

---------

Co-authored-by: WayenWeng <jinyuan.weng@seeed.cc>
2026-09-20 17:18:01 +00:00
2026-09-20 04:11:18 +00:00
2021-10-09 17:15:12 +11:00
2026-09-01 18:00:06 -04:00
2024-09-24 15:24:08 -05:00
2026-09-18 16:41:30 +02:00
2026-07-01 19:01:27 -05:00
2026-01-29 10:06:58 -06:00
2024-11-28 06:26:51 -06:00
2024-09-04 15:33:28 -07:00
2026-07-28 11:09:40 +00:00
2026-01-29 10:06:58 -06:00
2026-01-29 10:06:58 -06:00
2026-07-01 19:01:27 -05:00
2025-01-13 12:24:05 +08:00
2026-01-29 10:06:58 -06:00

Meshtastic Logo

Meshtastic Firmware

GitHub release downloads CI CLA assistant Fiscal Contributors Vercel

meshtastic%2Ffirmware | Trendshift

Overview

This repository contains the official device firmware for Meshtastic, an open-source LoRa mesh networking project designed for long-range, low-power communication without relying on internet or cellular infrastructure. The firmware supports various hardware platforms, including ESP32, nRF52, RP2040/RP2350, and Linux-based devices.

Meshtastic enables text messaging, location sharing, and telemetry over a decentralized mesh network, making it ideal for outdoor adventures, emergency preparedness, and remote operations.

Get Started

Join our community and help improve Meshtastic! 🚀

Stats

Alt

S
Description
No description provided
Readme GPL-3.0
249 MiB
0 Stars 1 Watchers 0 Forks
Languages
C++ 73.1%
C 22.1%
Python 2.7%
Shell 1.5%
Batchfile 0.2%
Other 0.2%