Over the last several days, the Heltec Mobile build has moved well beyond “MeshRoute firmware running on a development board.” It is becoming a self-contained field terminal: a roaming LoRa endpoint with its own display, one-button controls, team messaging, local settings, battery readout, and a deliberately cautious emergency flow.
The hardware is the Heltec WiFi LoRa 32 V3: an ESP32-S3, an SX1262 LoRa radio, a 128×64 OLED, and one user button. The interesting work is not simply drawing text on that screen. It is making a tiny interface tell the truth about a changing radio network while staying out of the radio’s way.
A mobile is a distinct network role
The heltec_mobile firmware profile is built for a personal endpoint rather than a fixed relay or gateway. It removes the remote-management subsystem from this physically portable and therefore more easily captured device. The mobile is expected to be managed locally, through its onboard interface today and through an appropriate companion transport in the future.
A mobile keeps a stable cryptographic identity while the fixed network gives it a temporary local address. A fixed node that can currently hear the mobile becomes its home and performs the last hop for incoming traffic. The attachment may change as the person moves, but the identity does not.
Making home attachment something the device can trust
A major part of the recent work has been making that home relationship explicit and testable. Receiving an offer is not enough. Sending a claim is not enough either. The mobile now treats a new attachment as provisional until the selected home sends a roster that echoes the same cryptographic hash, assigned local ID, and registration epoch.
That distinction closes an uncomfortable gap: previously, a mobile could report itself as registered even when its claim had never reached the home. The mobile and the app could believe in an attachment that the fixed node did not actually know about. Now the “registered” state has to be earned by confirmation from the other side.
Once attached, the mobile checks the home periodically. Only a probe that the local transmitter actually accepted may count as an unanswered check. If the radio was too busy even to send the probe, the firmware does not blame the home for being silent. Lost claims use a bounded re-claim process; a genuinely lost home eventually tears down the stale attachment and returns the mobile to discovery.
The firmware also keeps observations of alternative homes, including their freshness and link quality. The current roaming policy is intentionally conservative: a weak but consistently responding home is retained. A broader proactive search was measured to create too much roster traffic and additional collisions, so proactive switching before connectivity begins to fail is still being refined rather than presented as finished.
A complete one-button interface
The onboard interface now has five main screens: Status, Team, Inbox, Send, and Settings. A short press moves through screens or list rows. A double press activates the selected item. A long press is reserved for the emergency interaction, from any screen.
The Team screen shows the teammates the mobile can currently route to, with a stable selection tied to the teammate’s identity rather than a row number. If the roster changes while somebody is selected, the interface refuses the action and asks the user to choose again instead of silently sending to whoever moved into that position.
Without a keyboard, the mobile uses a deliberately small set of canned messages for direct replies and team-channel posts. It is not intended to replace the iPhone companion for long conversations. Its purpose is immediacy: see the state, check recent activity, acknowledge a message, and perform important actions without taking out another device.
Emergency behavior that avoids false confidence
The emergency gesture sends a fixed encrypted team-channel message—“I’m in danger”—and attaches location only when a position fix is actually available. A missing fix must never suppress the alarm itself.
The flow arms before firing, can be cancelled before commitment, and uses a bounded budget of three accepted transmissions. The screen distinguishes blocked, failed, picked-up, not-heard, and reply outcomes. Most importantly, those outcomes are correlated with the specific send. An unrelated channel post must not be allowed to complete an emergency transaction or create a comforting but false success message.
The latest transmission work goes one step further: a locally originated message remains QUEUED until the SX1262 reports that it actually aired, and only then may the interface say SENT. Delivery or relay confirmation remains a separate, later fact. This hardware-completion path is implemented in the current development tree and still needs its final real-radio bench confirmation.
The inbox is now useful on the device
The Heltec display can browse recent direct messages and channel posts, open a message into a paged detail view, and deliberately delete an individual entry. Direct messages and channel traffic receive separate space so a busy channel cannot evict every direct-message preview from the display.
On ESP32 this inbox is currently a bounded RAM ring with 32 records per kind. It works during the running session and reports a new storage epoch after a reboot, but its history does not yet survive power loss. The durable flash backend remains future work, so the article does not call the Heltec inbox persistent.
Settings without a serial console
A new Settings screen makes several important choices available through the same button: default direct-message encryption, automatic key attachment during introductions, mobile auto-registration, and entry into provisioning. Values are edited in a RAM draft first. The user can save, discard, go back, or reload when another configuration writer has changed the underlying record.
The interface exposes conflicts and reboot requirements instead of hiding them. Unsaved changes are marked, a conflicting external change produces a reload warning, and a saved value that takes effect only at boot leaves a visible “RESTART NEEDED” reminder.
There is deliberately no Bluetooth setting on this Heltec screen today. The phone-facing companion transport is compiled for the nRF52840 target, not the ESP32-S3 Heltec build. Showing a control that cannot affect the device would be another false promise.
Battery measurement without a permanent drain
The battery field is no longer just a placeholder. The board layer now samples the Heltec battery circuit in an eight-reading burst, enables the voltage divider only while measuring, and parks it again immediately afterward. It probes the control-line polarity rather than assuming that every board sold as “V3” uses the same electrical revision.
Readings outside a plausible one-cell LiPo range are reported as unavailable instead of displayed as a believable number. The remaining work is physical validation: the ADC scale and detected polarity still need comparison with a multimeter on the exact board revision in hand.
The screen must not interfere with the radio
The OLED is updated through a 128-byte page buffer instead of one large blocking frame. Painting proceeds in small pieces, waits for the radio state to permit it, throttles visible updates, and blanks the panel after inactivity. Gesture meaning, send attribution, inbox selection, and settings behavior live in board-independent code that can be exercised by native tests; the Heltec-specific layer only owns the display, button, power rail, and battery pins.
What Heltec Mobile is—and is not—today
Heltec Mobile is now recognizably a field device rather than a board that requires a laptop beside it. It can attach to a fixed MeshRoute network, participate in an encrypted team, show network and message state, send a small set of useful responses, edit key settings, and expose an emergency interaction directly on the radio.
It is still pre-release engineering on test hardware. The inbox is volatile, the Heltec does not yet provide the iPhone companion’s Bluetooth transport, proactive roaming away from a weak-but-working home is incomplete, and several battery and transmission behaviors still require metal verification. The emergency interface is carefully designed and heavily tested in software, but it is not a certified safety device.
That is the progress worth sharing: not just more features, but clearer boundaries between what the device requested, what the radio transmitted, what another node confirmed, and what remains unknown.
Follow the project status or inspect the current source and development history on GitHub.
Leave a Reply