rak3401: add -D RAK_BOARD so WisBlock RAK12500 (I2C u-blox) GPS compiles in

[Strycher]

Summary

The rak3401 variant is missing -D RAK_BOARD, so the WisBlock I2C GPS path — which drives the RAK12500 / u-blox ZOE-M8Q over I2C — is compiled out. A RAK12500 on any RAK3401-based board (e.g. the WisMesh 1W Booster, RAK10724) is therefore never detected, and the MeshCore app shows GPS as "not available."

Root cause

In src/helpers/sensors/EnvironmentSensorManager.cpp:

#if ENV_INCLUDE_GPS && defined(RAK_BOARD) && !defined(RAK_WISMESH_TAG)
#define RAK_WISBLOCK_GPS
#endif

RAK_WISBLOCK_GPS gates the entire I2C u-blox driver (RAK12500LocationProvider, ublox_GNSS.begin(Wire), rakGPSInit() / gpsIsAwake()), and it requires RAK_BOARD.

RAK_BOARD is defined by rak4631, rak_wismesh_tag, and the gat562_* variants — but not by rak3401 (which only defines -D RAK_3401). So rak3401 builds compile the #else branch, initBasicGPS(), which is UART/Serial1-only and never scans I2C → an I2C-only module (RAK12500) is invisible. This is a variant oversight: rak3401 was derived from rak4631 but dropped -D RAK_BOARD.

Fix

Add -D RAK_BOARD to the [rak3401] base build_flags in variants/rak3401/platformio.ini (mirroring rak4631). Applies to all rak3401 envs (companion BLE/USB, repeater, room server, sensor). One-line build-flag change; no logic change.

Hardware / verification

• First device: RAK10724 WisMesh 1W Booster (RAK3401 + RAK13302), companion BLE — see Flash new RAK10724 WisMesh 1W as BLE companion (MeshCore 1.15.0) #103.
• GPS module: RAK12500 (u-blox ZOE-M8Q), mounted in Slot C (Slot F is physically buried; A/B are poor layout; Slot D's socket isn't in the probe list). gpsIsAwake() walks WB_IO2(Socket A) / WB_IO4(Socket C) / WB_IO5(Socket F) — Slot C = WB_IO4 is covered.
• I2C (SDA/SCL on pins 13/14) is shared across slots, so detection at 0x42 should be slot-agnostic; the per-socket toggle just wakes the module.
• Note: on rak3401, WB_IO2 == PIN_3V3_EN (the 3V3_S + SKY66122 5V-boost enable), so the gpsIsAwake(WB_IO2) probe momentarily power-cycles the 3V3 rail during init. The same code runs on rak4631 in production (considered safe), but noted.

Acceptance

Build RAK_3401_companion_radio_ble, reflash, mount the RAK12500 in Slot C, enable GPS in the MeshCore app, and confirm a position fix outdoors.

[Strycher]

Correction — this is NOT a one-line -D RAK_BOARD fix; reverted.

Adding -D RAK_BOARD to rak3401 fails and is unsafe. Two findings:

1. Compile error

RAK_WISBLOCK_GPS pulls in gpsIsAwake(), which references PIN_GPS_EN — undefined in rak3401/variant.h:

EnvironmentSensorManager.cpp:711: error: 'PIN_GPS_EN' was not declared in this scope

2. The real blocker: pin collisions with the radio + power rail

gpsIsAwake() drives WB_IO2 / WB_IO4 / WB_IO5 as OUTPUTs (LOW→HIGH) to "wake the GPS." On rak4631 those are free slot pins. On rak3401 (WisMesh 1W = RAK3401 core + external RAK13302 radio module on the WisBlock IO lines) they are the radio/power control pins:

Macro	rak3401 pin	Actual function
WB_IO2	34	PIN_3V3_EN — 3V3_S rail + SKY66122 5V boost enable
WB_IO3	21	SX126X_POWER_EN (SKY66122 FEM enable)
WB_IO4	4	SX126X_RESET
WB_IO5	9 (PIN_NFC1)	SX126X_BUSY
WB_IO6	10	SX126X_DIO1

So the generic detection would reset the radio and cut its boost on every GPS probe. This is why the variant author deliberately left RAK_BOARD off, and the simple flag is the wrong fix. Reverted.

Proper fix (re-scoped)

A rak3401-specific GPS path that:

1. Defines or guards PIN_GPS_EN so it compiles.
2. Does not toggle WB_IO2/IO4/IO5 (radio/power) — initialize Wire and probe the u-blox at 0x42 directly. The GPS is already powered by the always-on 3V3_S rail.
3. Hardware-verify the RAK12500 in sensor Slot C: confirm its reset/standby line doesn't tie to the radio's WB_IO3/IO4 net (Slot C IO is WB_IO3=21/WB_IO4=4, both consumed by the RAK13302). May require leaving GPS reset floating/pulled and relying on I2C only, or schematic confirmation.

Acceptance (now requires bench test)

Build, flash, mount RAK12500 in Slot C, enable GPS in app, AND confirm both (a) a position fix and (b) the LoRa radio still TX/RX normally (no reset/boot-loop from the GPS init touching radio pins). Cannot be validated by compile alone.

Alternative that needs NO firmware change: RAK12500 in Slot A over UART

The current build already reads a UART-NMEA GPS on Serial1 (initBasicGPS(), PIN_GPS_RX/TX = 15/16; the variant comment literally references "RAK1910 GPS plugged into Port A"). Per RAK docs, Slot A = UART. A RAK12500 in Slot A, emitting NMEA over UART @ 9600 (ZOE-M8Q default), is detected with zero code change and zero risk to the radio (this path never touches WB_IO2/3/4/5). Trade-off: Slot A layout (operator prefers Slot C).

Device companion firmware (no GPS) remains flashed and working in the meantime (#103).

[Strycher]

Option A (Slot A / UART) ruled out — Option B (I2C) confirmed required

Operator moved the RAK12500 to Slot A and full power-cycled (GPS detection latches at boot, so a power cycle was required and was done): the app still reports GPS not supported/detected. This empirically confirms the RAK12500 (u-blox ZOE-M8Q) does not present as a UART-NMEA GPS on Serial1 in Slot A with the current build — the I2C path is required.

Decision: the module will live in Slot C; implement Option B. Deferred to a future bench session — the companion (#103) ships GPS-less for now and is working.

Implementation plan (Option B), for pickup

• Do NOT just define RAK_BOARD: its gpsIsAwake() drives WB_IO2/IO4/IO5, which on rak3401 are the RAK13302 radio's RESET/BUSY and the 3V3+boost enable — it would reset the radio on every probe.
• Add a rak3401-scoped, I2C-only GPS init: bring up Wire (slot I2C, pins 13/14), ublox_GNSS.begin(Wire) at 0x42, and use the existing RAK12500LocationProvider. No WB_IO toggling. Define/guard PIN_GPS_EN so it compiles.
• Cleanest shape: a new define (e.g. RAK3401_I2C_GPS) gating a no-toggle I2C-probe branch in EnvironmentSensorManager, instead of reusing the generic RAK_WISBLOCK_GPS path.
• Bench acceptance (operator, at the bench): build RAK_3401_companion_radio_ble, flash, RAK12500 in Slot C, enable GPS in app → confirm (a) a position fix AND (b) the LoRa radio still TX/RXes (GPS init must not disturb the radio).

Status → deferred (revisit at bench with hardware present).

[Strycher]

Re-homed under the GPS feature #144 — linked as a child of both the Companion (#145) and Repeater (#147) GPS epics. The -D RAK_BOARD / RAK12500 fix is board-level, so it serves both rak3401 builds. Status moved deferred → backlog.

[Strycher]

Shipped in offband-v1.0.0 — RAK12500 (u-blox ZOE-M8Q) I²C GPS enabled in Slot D. Companion + repeater verified a position fix.