mirror of
https://github.com/meshtastic/firmware.git
synced 2026-10-09 14:41:19 -04:00
d4bb6eea912c2c4d24a0c33fb10737a30bb868d6
* 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>
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
- 🔧 Building Instructions - Learn how to compile the firmware from source.
- ⚡ Flashing Instructions - Install or update the firmware on your device.
Join our community and help improve Meshtastic! 🚀
Stats
Languages
C++
73.1%
C
22.1%
Python
2.7%
Shell
1.5%
Batchfile
0.2%
Other
0.2%
