Muzi Base SuperIO: GPS mode switch ignored at boot

Open Beginner friendly
  • Is something wrong?
#3,760 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
embedded-iot

Research direction

Start in MuziBaseSensorManager::begin() and loop() in variants/muzi_base/target.cpp, then the companion's startup order around applyGpsPrefs() in examples/companion_radio/main.cpp. The proposed change leaves _last_gps_sw at -1 so the first loop() applies the switch position after prefs are set. Done means the GPS page reads gps on after a power cycle with the switch in the middle position, and you have checked whether variants/thinknode_m1/target.cpp has the same ordering problem. Hardware is needed to confirm the fix.

Written by the indexing model from the issue text.

Description

Description

On the Muzi Base (Uno/Duo) with the SuperIO, the companion firmware ignores the 3-position mode switch when the device boots. If the switch is already in the GPS position (Mode 2, middle) at power-on, GPS stays off. It only turns on after the switch is moved away and back.

Meshtastic uses the same switch for GPS on/off: SWITCH_MODE2 (P0.12, middle position) is defined as PIN_GPS_SWITCH[^1]. The SuperIO docs list the GPS module as part of the board[^2].

Cause

MuziBaseSensorManager::begin() reads the switch and calls start_gps()/stop_gps()[^3]. But in the companion, sensors.begin() is followed right away by the_mesh.applyGpsPrefs()[^4], which sets GPS from the saved gps_enabled pref (off by default). That overrides the switch state.

After that, loop() only reacts when the switch changes[^5], so the initial position is never applied again.

Steps to reproduce
  1. Flash muzi_base_uno_superIO_companion_radio_ble (or the Duo equivalent).
  2. Set the mode switch to the middle position (GPS on).
  3. Power cycle the device.
  4. Open the GPS page on the display: it shows gps off(sw) instead of gps on.
  5. Move the switch away and back: GPS turns on.
Proposed fix

Let the first loop() apply the switch position, so it runs after applyGpsPrefs():

--- a/variants/muzi_base/target.cpp
+++ b/variants/muzi_base/target.cpp
@@ bool MuziBaseSensorManager::begin() {
   pinMode(PIN_GPS_SWITCH, INPUT);
-  _last_gps_sw = digitalRead(PIN_GPS_SWITCH);   // initial gps state from the switch
-  if (_last_gps_sw == HIGH) start_gps(); else stop_gps();
+  // leave _last_gps_sw at -1 so the first loop() applies the switch position.
+  // applying it here would be overridden by applyGpsPrefs(), which the
+  // companion runs right after sensors.begin().
+  _last_gps_sw = -1;

The ThinkNode M1 uses the same pattern (variants/thinknode_m1/target.cpp) and may have the same problem.

Environment
  • Board: Muzi Base Uno + SuperIO
  • Firmware: main @ 81dbae5 (v1.18.0), env muzi_base_uno_superIO_companion_radio_ble

[^1]: Meshtastic muzi_base variant, mode switch pins: https://github.com/meshtastic/firmwa6fdd4cd659498d28d8bd153/variants/nrf52840/muzi_base/variant.h#L64-L66
[^2]: Meshtastic docs, muzi ᴡᴏʀᴋꜱ Super IO: https://meshtastic.org/docs/hardware/devices/muziworks/muzi-base/super-io/
[^3]: https://github.com/meshcore-dev/MeshCore/blob/81dbae592ffad40b4212bc0b37e82b38da08f4bct.cpp#L44-L45
[^4]: https://github.com/meshcore-dev/MeshCore/blob/81dbae592ffad40b4212bc0b37e82b38da08f4bc/examples/companion_radio/main.cpp#L278-L281
[^5]: https://github.com/meshcore-dev/MeshCore/blob/81dbae592ffad40b4212bc0b37e82b38da08f4bc/variants/muzi_base/target.cpp#L63-L65

Dominant language
C
Stars
3.9k
Forks
1.5k
Avg merge
2d 20h
Merged PRs (30d)
36

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from meshcore-dev/MeshCore

All issues in meshcore-dev/MeshCore

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.