ThinkNode M6 GPS not supported — CASIC L76K (AT6558) needs $PCAS config; UART TX hangs with SoftDevice active

[benskigomez]

Summary

On the Elecrow ThinkNode M6, the MeshCore companion app reports the device has no GPS / GPS not supported, even though the M6 has a GPS module and it works correctly on Meshtastic (confirmed real position fixes with 8 satellites on the same unit). This is a firmware gap, not a hardware fault — and it almost certainly affects the ThinkNode M1 and M5 as well (same GPS family).

Root cause

The M6's "L76K" GPS is an Airoha AG3335. It does not auto-stream NMEA on power-up — it stays completely silent until it receives a UART wake command ($PAIR382,1*2E), and it must be baud-probed (9600 / 115200 / 38400) and then configured for NMEA output.

Meshtastic handles all of this in src/gps/GPS.cpp (the GNSS_AIROHA path: wakeAirohaForActiveProbe() sends $PAIR382,1, followed by $PAIR021 identify and the NMEA-output config commands).

MeshCore's MicroNMEALocationProvider only powers the module (EN pin) and reads — it assumes the GPS free-runs NMEA. On an Airoha chip nothing ever arrives, so EnvironmentSensorManager::initBasicGPS() sees no data, sets gps_detected = false, and the GPS feature is hidden from the app/CLI.

Evidence (on-hardware)

• With the GPS powered and PIN_GPS_EN / PIN_PWR_EN / PIN_GPS_STANDBY / PIN_GPS_RESET driven in every combination, there is zero serial activity on any GPIO at any baud — confirmed by both UART reads (15 s) and a baud-agnostic GPIO edge-count scan across all pins.
• Sending the Airoha wake ($PAIR382,1) at 9600/115200/38400 from a standalone sketch did not elicit a response either, so the full Meshtastic probe/config sequence (not just the wake) appears to be required.
• Meshtastic, which performs that sequence, gets fixes on the same board and pins (GPS EN = pin 6, RX = pin 3 default).

Implementation note / caveat

A naive port that switches the GPS UART baud (Serial1.end()/begin()) inside the companion BLE firmware hangs the nRF52 — re-initializing the UART while the SoftDevice is active locks up. So the Airoha bring-up needs SoftDevice-safe baud handling, not a quick patch.

Affected boards

ThinkNode M6 (confirmed), and very likely M1 / M5 (all L76K / AG3335).

Suggested fix

Add Airoha / AG3335 support to MeshCore's GPS bring-up: send the wake ($PAIR382,1), probe baud, and issue the NMEA-output config commands — portable from Meshtastic's GPS.cpp, with care around UART re-init under the SoftDevice. Happy to test on an M6.

[benskigomez]

Correction + new findings: it's a CASIC L76K (AT6558), not Airoha

Captured the Meshtastic boot log on the same unit (Meshtastic GPS works fine on it). The detection sequence is conclusive:

[GPS] Trying $PAIR021*39 (Airoha Family)...     <- no response
[GPS] Trying $PCAS06,0*1B (L76K)...
[GPS] L76K detected                              <- responds here
[GPS] Use GPIO3 for GPS RX
[GPS] Use GPIO2 for GPS TX

So the M6 GPS is a CASIC part (the AT6558 visible in the FCC teardown), not Airoha. It ignores the $PAIR (Airoha) commands and responds to $PCAS06,0*1B. Confirmed: RX = GPIO3, TX = GPIO2, 9600 baud (detected on the first baud — no baud hunting needed).

Correct bring-up (from Meshtastic's L76K path)

1. $PCAS06,0*1B — identify (chip replies)
2. $PCAS04,7*1E — GNSS mode (GPS+BDS+GLONASS)
3. $PCAS03,1,0,0,0,1,0,0,0,0,0,,,0,0*02 — enable NMEA output (GGA+RMC)

MicroNMEALocationProvider sends none of these, so the chip never streams NMEA → gps_detected stays false → GPS hidden.

Implementation obstacle (important for whoever fixes this)

Naively adding those Serial1.write() calls to initBasicGPS() in the companion BLE build hangs the boot. The Adafruit nRF52 Uart::write()/flush() block on a FreeRTOS semaphore (_end_tx_sem) that's released by the UARTE TX-complete interrupt — and with the SoftDevice active that release doesn't happen in this path, so the write blocks forever. (A standalone build with no SoftDevice sends the bytes fine but the GPS still doesn't respond there, suggesting the standalone UART TX isn't reaching the chip either.)

So the real fix needs SoftDevice-safe UART TX for the GPS config — which Meshtastic handles correctly. This is a careful, hardware-iterated change, not a one-line patch.

I have an M6 and can test candidate fixes.

[benskigomez]

Update — corrected root cause. After bench testing on the (sealed) M6, the original premise of this issue was wrong: the L76K does not need $PCAS config, and the SoftDevice UART-TX behaviour is not what blocks detection.

The actual cause is that pin 29 (PIN_GPS_RESET, the module's REINIT line) is driven HIGH, which holds the L76K silent so it emits no NMEA at all — detection sees zero bytes and the GPS is hidden.

Passive NMEA capture at 9600 baud, changing one variable at a time:

pin 29 state	result
driven HIGH (current firmware)	0 bytes
floating (INPUT)	full NMEA stream

The GPS streams standard NMEA at 9600 by default. Fix submitted in #2863: define GPS_RESET (-1) and stop driving pin 29 in the M6 variant (matching the Meshtastic M6 variant, which leaves that pin floating). Confirmed on hardware — GPS now detected, app shows live coordinates/altitude/map position.