Skip to content

CLI: gps interval to set and persist the GPS read interval - #9

Open
mmmorks wants to merge 1 commit into
staging/meshcore-devfrom
pr/10-gps-interval-cli
Open

CLI: gps interval to set and persist the GPS read interval#9
mmmorks wants to merge 1 commit into
staging/meshcore-devfrom
pr/10-gps-interval-cli

Conversation

@mmmorks

@mmmorks mmmorks commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Staged on the fork for review. Final destination: meshcore-dev/MeshCore dev (or the fork; to decide). Base here is staging/meshcore-dev so the diff shows only this change.

Summary

Adds a gps interval [seconds] command to CommonCLI, and makes the repeater re-apply the persisted interval at boot. NodePrefs::gps_interval already existed and was serialised (gps.int), and EnvironmentSensorManager already honoured a gps_interval setting, but nothing outside the companion app's CMD_SET_CUSTOM_VAR path could set it, and simple_repeater's applyGpsPrefs() never pushed the stored value back to the sensor manager after a reboot.

What changed

  • src/helpers/CommonCLI.cpp: gps interval reports the stored value; gps interval <n> sets it (0–86400 s, 0 = firmware default of 1 s), forwards it to the sensor manager and saves prefs. The argument must be all digits — _atoi() reads a typo like abc as 0, which would silently reset the pref instead of reporting the mistake. The prefix match checks for a delimiter after interval, otherwise gps intervalX would parse past the X as its argument instead of falling through to the generic gps handler and being rejected.
  • examples/simple_repeater/MyMesh.h: applyGpsPrefs() applies a non-zero stored interval at boot, matching companion_radio.
  • src/helpers/sensors/EnvironmentSensorManager.cpp: comment recording why gps_interval is deliberately settable-but-not-enumerated (enumerating it would change CMD_GET_CUSTOM_VARS's wire payload on every companion build) and not gated on gps_detected (every example's applyGpsPrefs() calls it at boot regardless).
  • docs/cli_commands.md: documents the command.

At the 1 s default the two lat … debug lines printed on every read dominate a debug log on a node with a fix; this is the knob for that too.

How it was tested

  • pio test -e native passes (on macOS this needs the <stdlib.h> include from the small-fixes PR to compile at all; the suite is otherwise unaffected by this change).
  • Compiled for WioTrackerL1_repeater (nRF52) and heltec_tracker_v2_repeater (ESP32-S3).

Dependencies

Independent. Applies to dev. (Touches the gps handler region of CommonCLI.cpp a few lines away from the NULL-check fix in the small-fixes PR; both apply cleanly in either order.)

NodePrefs::gps_interval has been persisted in the prefs blob (and the
"gps.int" key) since it was added, but nothing outside companion_radio's
CMD_SET_CUSTOM_VAR path could write it: CommonCLI's get/set commands are a
hand-written chain that never reaches the ConfigSerializer tree, and
simple_repeater's applyGpsPrefs() pushed only "gps" to the sensor manager
and never the interval. The stored value was loaded, saved, and ignored,
leaving EnvironmentSensorManager on its 1 s default -- which on a node
with a fix prints two lat/lon debug lines per second.

Add "gps interval [seconds]" in the shape of "gps advert": the bare form
reports, the argument form applies and persists, capped at 24 hours, with
zero keeping the firmware default of 1 s at both ends. The argument must
be all digits, since _atoi() reads a typo like "abc" as 0 and would
silently reset the pref while answering "ok". The prefix match requires a
delimiter after "interval": memcmp(command, "gps interval", 12) matches
"gps intervalX" too, which would then read its argument from past the 'X'
-- an empty string, so 0 -- instead of falling through to the generic
"gps" handler and being rejected. Trailing spaces read as the bare query.

Teach simple_repeater's applyGpsPrefs() to re-apply a non-zero stored
interval at boot, matching what companion_radio already does.
simple_room_server and simple_sensor have the same gap in their own
applyGpsPrefs() and are left alone here.

gps_interval stays settable-but-not-enumerated in
EnvironmentSensorManager, and the comment there records why: the
enumeration calls also build RESP_CODE_CUSTOM_VARS's wire payload on every
companion build, so listing it would change what every embedded companion
node sends. It is also deliberately not gated on gps_detected, because
every example's applyGpsPrefs() calls it at boot regardless.

Documented in docs/cli_commands.md.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXSCjgNEbJfHwLjD2WSHW4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant