Repository navigation
Conversation
Powers off the GPS for the specified interval (in seconds) to save power. The GPS remains powered on for GPS_WAIT_SECONDS_WITH_VALID_FIX (default: 10 seconds with a valid fix) or GPS_TIMEOUT_SECONDS (default: 10 minutes) if no valid fix is acquired within the whole GPS_WAIT_SECONDS_WITH_VALID_FIX period. After this, the GPS powers off for the specified sleep interval and the cycle repeats. The GPS sleep interval is independent of other intervals. For example, if set to 10 minutes and the GPS acquires a valid fix, it stays powered on for 10 seconds and then turns off for 10 minutes. If a time sync event occurs after TIME_SYNC_INTERVAL (originally hardcoded to 30 minutes), time synchronization takes place at the next interval when the GPS is powered on (i.e., at most 10 minutes after the event is triggered in this case). CLI examples: Query GPS sleep interval: > gps sleep Set GPS sleep interval to 0 (i.e. disable this feature, behaviour like without this patch): > gps sleep 0 Set GPS sleep interval to 10 seconds: > gps sleep 10 Switch GPS on daily for 10 seconds (hardcoded) to synchronize the clock then power it off for 24 hours (86400 seconds) to save power: > gps sleep 86400 > gps on
|
TLDR: allows GPS synchronization of the clock daily/weekly/... with the GPS most of the time switched off to save significant amount of power. E.g. good for solar powered nodes. |
|
Running it for few weeks on multiple Sensecap Solar P1 Pro repeaters, the GPS is set to sleep for a day and so far so good. The time is still precise so it should prevent the problem when the time advances so far (e.g. tens of minutes during several months) that the repeater cannot be normally remotely controlled or rebooted. The battery level is also good, comparable to the state with the GPS off and it's cloudy here, i.e. the solar charging isn't much effective now. |
|
I have the patched firmware running for more than a week on my Sensecap Solar P1, that currently not even properly positioned to receive a lot of illumination and the clock is still fine & battery not drained. This seems to me to indicate that the patch indeed does keep the clock in sync, without causing any noticeable battery drain. |
|
implemented in gps refactor #3753 this refactor has been needed for a long time (I think about a year or so) before adding new gps functionalities ... now it's done don't refrain to propose other PRs (and don't hesitate to tag me or ask me for a review) |
Powers off the GPS for the specified interval (in seconds) to save power. The GPS remains powered on for GPS_WAIT_SECONDS_WITH_VALID_FIX (default: 10 seconds with a valid fix) or GPS_TIMEOUT_SECONDS (default: 10 minutes) if no valid fix is acquired within the whole GPS_WAIT_SECONDS_WITH_VALID_FIX period. After this, the GPS powers off for the specified sleep interval and the cycle repeats.
The GPS sleep interval is independent of other intervals. For example, if set to 10 minutes and the GPS acquires a valid fix, it stays powered on for 10 seconds and then turns off for 10 minutes. If a time sync event occurs after TIME_SYNC_INTERVAL (originally hardcoded to 30 minutes), time synchronization takes place at the next interval when the GPS is powered on (i.e., at most 10 minutes after the event is triggered in this case).
CLI examples:
Query GPS sleep interval:
Set GPS sleep interval to 0 (i.e. disable this feature, behaviour like without this patch):
Set GPS sleep interval to 10 seconds:
Switch GPS on daily for 10 seconds (hardcoded) to synchronize the clock then power it off for 24 hours (86400 seconds) to save power: