Skip to content

Muzi Base SuperIO: GPS mode switch ignored at boot #3760

New issue
New issue
Open
Open
Muzi Base SuperIO: GPS mode switch ignored at boot#3760

Description

@jaonoctus
jaonoctus
opened on Nov 4, 2026

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_SWITCH1. The SuperIO docs list the GPS module as part of the board2.

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 changes5, 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

Footnotes

  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 ↩

Activity

  1. jaonoctus commented on Nov 4, 2026

    @jaonoctus
    jaonoctus
    on Nov 4, 2026
    Author

    I've flashed the firmware with the proposed fix, it works.

    Image

  2. nGoline commented on Nov 4, 2026

    @nGoline
    nGoline
    on Nov 4, 2026

    I applied the proposed fix on a Muzi Base Uno + SuperIO (muzi_base_uno_superIO_companion_radio_ble, main @ 81dbae5). It fixes the boot state: with the switch up, the GPS page shows gps on after a power cycle. But the GPS still never got a fix (no fix, pos 999.0000 999.0000 after several minutes by a window), so there's a second problem.

    Second cause: the ATGM336H can be left with all NMEA output disabled

    I logged the GPS UART with MicroNMEALocationProvider's diagnostic counters. After each power-up the module sends only its boot banner, then nothing:

    $GPTXT,01,01,02,MA=CASIC*27
$GPTXT,01,01,02,HW=ATGM336H,0005094565257*1C
$GPTXT,01,01,02,IC=AT6558-5N-31-0C510800,FH32CKJ-F1-030174*5D
...
[gps] sw:1 active:1 en:1 ub:326 ua:39031 ok:8 bad:0 na:39032 sat:0 fix:0 ...

    The checksums are valid, so the baud rate (9600) and pins are fine. The enable pin stays high, and restarting Serial1 without touching GPS power brings no data, so the MCU side isn't stuck either.

    Meshtastic gets a fix on the same unit. Its probe for the AT6558 family sends $PCAS03,0,0,0,0,0,0,0,0,0,0,,,0,0 (all NMEA sentences off) and then re-enables only GGA and RMC (GPS.cpp). The module keeps that config across power cycles on the enable pin. MeshCore never configures the module, so once it's in that state it stays silent.

    Fix

    After each GPS power-up, wait for the module to boot and re-enable GGA + RMC:

    --- a/variants/muzi_base/target.cpp
+++ b/variants/muzi_base/target.cpp
@@ void MuziBaseSensorManager::loop() {
       if (sw == HIGH) start_gps(); else stop_gps();
     }
   }
+  // the ATGM336H keeps its nmea output config across power cycles (backup
+  // supply), and other firmware may have turned every sentence off. re-enable
+  // GGA + RMC after each power-up, once the module has booted.
+  if (gps_active && !_gps_was_active) _gps_cfg_at = now + 1000;
+  _gps_was_active = gps_active;
+  if (_gps_cfg_at && gps_active && now > _gps_cfg_at) {
+    _gps_cfg_at = 0;
+    _location->sendSentence("$PCAS03,1,0,0,0,1,0,0,0,0,0,,,0,0");
+  }
 #endif
    --- a/variants/muzi_base/target.h
+++ b/variants/muzi_base/target.h
@@ class MuziBaseSensorManager : public EnvironmentSensorManager {
   int _last_gps_sw = -1;
   unsigned long _next_sw_check = 0;
+  unsigned long _gps_cfg_at = 0;
+  bool _gps_was_active = false;
 #endif

    It triggers on the rising edge of gps_active, so it also covers GPS being turned on from the UI or the app, not just the switch. MicroNMEA::sendSentence() adds the checksum.

    With both changes, NMEA arrives every second and I got a fix with 7 satellites about 4 minutes after power-up. Builds for both muzi_base_uno_superIO_companion_radio_ble and muzi_base_duo_superIO_companion_radio_ble.

    Switch positions

    On my unit, top is GPS on (P0.12 reads HIGH); middle and bottom are off. The Meshtastic variant labels SWITCH_MODE2 (P0.12) as the middle position, which doesn't match what I see. The issue's steps say "middle position (GPS on)", so it may be worth confirming on another unit.

    I can open a PR with both fixes if that helps.

  3. fdlamotte commented on Nov 4, 2026

    @fdlamotte
    fdlamotte
    on Nov 4, 2026
    Collaborator

    please report and do your tests around the current gps refactor #3753

    I saw strange things in the muzi port, but don't have the hw, it would be great if you could help me with it

    You can propose PRs on top of the branch of the refactor gps branch

    Thanks !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions