Board: SparkFun RTK Torch, UM980 firmware 11833
Firmware: RTK Everywhere firmware, ESP32 core 3.0.7 (self-built from the SparkFun_RTK_Everywhere_Firmware repo, on a Torch-specific branch)
Symptom: the ESP32 talks to the UM980 over its dedicated UART (serialGNSS, mapped to the UM980’s COM1) at a fixed target baud (921600, needed for 20Hz RTCM3). On every boot, a probe sweep (send VERSION, listen for a reply at each candidate rate) finds the receiver only answers at 115200 — never 921600 — so the firmware falls back to 115200 for that session, which isn’t enough throughput for what we need.
What’s odd: querying the receiver’s own saved config (CONFIG, which triggers the $CONFIG,COM1,… dump) shows COM1’s saved value already reads 921600:
Unicore Lib: Valid NMEA Sentence: CONFIG, 0x0024 (36) bytes
Unicore Lib: Known command response: $CONFIG,COM1,CONFIG COM1 921600*28
So the value we want is already persisted. But the port that’s actually active right now is demonstrably still 115200 (that’s the rate the probe sweep gets a response on, and the rate the rest of the session’s traffic runs at). SAVECONFIG itself succeeds cleanly when we issue it again ($command,SAVECONFIG,response: OK) — so persistence isn’t the problem, applying the persisted value to the live port is.
Tried, neither worked:
- Sending RESET to the receiver and waiting ~3s before re-probing. Docs describe RESET as clearing ephemeris/almanac/position, not necessarily a UART reinit, and that matches what we saw — still 115200 after.
- A full power-off/power-on of the Torch itself. Same result — receiver still comes back at 115200. This suggests the UM980 (or some domain of it) stays alive across the host board’s power cycle — is there a VBAT/backup-power behavior on this module that would explain that?
Question: what’s the actual supported way to get a UM980 to reload a saved COM port baud rate onto the live UART? Is CONFIG COMx only ever meant to take effect immediately on the port it’s issued on (i.e., is our SET call, which our code skips because the read-back already matches, actually the thing we’re missing — should we force-resend it even when the query says it already matches)? Or is there a real cold-boot/hard-reset path for the receiver itself (separate from the AT RESET command) that we’re not hitting because of that backup-power behavior?
Happy to post the fuller debug log (settings.debugGnss + settings.debugGnssConfig on) if useful.
