WAYFINDER, a communication terminal brand by LINKGUARD

DEVELOPMENT

Development

The latest progress and changelog for CORE and WAYFINDER OS, plus a week-by-week plan through December 2026.

Latest progress · October 11, 2026

CORE carrier board first-pass layout complete. WAYFINDER OS reaches M0.

Next up: lighting the display and showing the interface on October 20. The first 3 engineering samples are expected to be completed in March 2027.

View changelog →

UPDATES

Changelog

LoRa page →

  1. First engineering samples

    Expected completion of 3 first-revision CORE units, followed by full-device power, range, and environmental testing.

    Planned

  2. Light the display, show the interface

    The display lights up and shows the WAYFINDER interface. At this stage the screens are for demonstration only and are not yet fully operable.

    In progress

  3. New LoRa page

    Published LoRa design targets, preliminary specifications, and development progress.

    Published

  4. CORE carrier board first-pass layout complete

    The six-layer carrier board completed its first-pass layout to the OSM v1.2 Size-L standard pinout. It goes to prototype fabrication once the vendor's pin table and mechanical drawings are confirmed.

    Completed

  5. WAYFINDER OS reaches M0

    The M0 milestone was completed and tagged in the QEMU emulation environment, ahead of the original October schedule. Next: porting to a physical development board.

    Completed

  6. CORE compute module decided

    An OSM Size-L Genio 720 compute module (industrial-grade MT8391). Memory and SoC are integrated on the module, so the carrier board focuses on power, communication, and interfaces.

    Decided

  7. LoRa range targets decided

    10 km on flat terrain, 2 km in harsh mountain terrain. Priority given to an internal LoRa antenna.

    Decided

  8. First-revision configuration settled

    First-revision wireless: LoRa (LR2021 ×1), LTE with eSIM, GNSS, and Wi-Fi/Bluetooth. No UWB. NFC and a second LoRa radio have reserved footprints.

    Decided

CORE / SEPTEMBER–DECEMBER 2026

Foundations first. Then a full prototype.

Revised goals · All results pending acceptance

Through December, the focus is WAYFINDER OS M0 / M1 and a power proof of concept. The M2 prototype, with display, touch, storage, and UI, will be scheduled separately. Actual dates will shift with staffing, funding, access to documentation, and hardware verification.

October 11 update: M0 was completed on September 27, ahead of the October schedule below. October now centers on the October 20 interface demo and M1 preparation. The original week-by-week plan below is kept for reference.

Revised to match the latest in-house OS scope: the earlier goal of a "fully operable prototype in December" has changed to foundational verification and a milestone demo. There is no release or delivery date yet.

Weeks are this plan's own scheduling segments; the listed dates are authoritative. Expected outcomes for each week do not mean the work is done. M1 can proceed only once boards, documentation, and boot firmware are available.

09

September | Confirm scope, platform, and resources

First, confirm we can obtain what is needed to boot, and draw the line between our own code and external firmware.

  1. September, week 309/14–09/20

    Define M0 / M1 acceptance scope

    Document the in-house scope, toolchain, and how runtime code will be checked. List available staffing and existing resources.

    Expected outcome

    Acceptance checklist, code-provenance rules, resource inventory

  2. September, week 409/21–09/27

    Review Genio 720 boot prerequisites

    Confirm the terms for obtaining boards, DDR initialization, BL31, boot media, and register documentation. Differences for MAX are listed separately.

    Expected outcome

    Platform feasibility table, firmware and documentation gaps

  3. September, week 509/28–09/30

    Arrange funding and priority purchases

    Compile quotes based on M0 / M1 and power-measurement needs, closing gaps in boards, documentation, and essential tools first.

    Expected outcome

    Itemized draft budget, delivery and equipment-loan arrangements

10

October | Build the M0 emulation foundation

Prioritize reproducible core tests. Success in emulation does not replace verification on real hardware.

  1. October, week 110/01–10/07

    QEMU boot and debug output

    Set up minimal loading, UART, and exception output on QEMU virt, and check the link sources of the final image.

    Expected outcome

    Reliably bootable M0 prototype, link-source record

  2. October, week 210/08–10/14

    MMU and memory basics

    Set up page tables, basic memory allocation, and page fault handling, with documented fault-injection and reporting steps.

    Expected outcome

    Memory and exception test records

  3. October, week 310/15–10/21

    Interrupts, timers, and scheduling

    Verify interrupts, the timer, and a minimal scheduler on the emulated platform, logging context switches and error states.

    Expected outcome

    Scheduling and interrupt test cases

  4. October, week 410/22–10/28

    EL0 processes and isolation

    Build minimal user processes, system calls, and isolation tests, prioritizing reproducible failures.

    Expected outcome

    User process demo, isolation test list

  5. October, week 510/29–10/31

    SMP and M0 gap check

    Check multi-core boot and basic coordination, and list the M0 items that still fail.

    Expected outcome

    SMP test records, list of open M0 issues

11

November | Advance M1 dev board verification

Requires boards, firmware, and documentation in hand. If the platform blocks progress, the hardware verification dates are revised first.

  1. November, week 111/01–11/07

    M0 regression and M1 entry check

    Consolidate reproducible emulation tests, and check dev board power-up, wiring, boot media, and external firmware versions.

    Expected outcome

    M0 regression summary, M1 prerequisites checklist

  2. November, week 211/08–11/14

    UART output on the Genio 720 dev board

    Once the necessary documentation is in hand, bring up boot and serial output on the real board, logging each boot blocker along the way.

    Expected outcome

    Board UART demo, boot issue log

  3. November, week 311/15–11/21

    GIC, timer, and GPIO

    Verify interrupts, timers, and basic pin control item by item against the Genio 720 register documentation.

    Expected outcome

    Board basic-interface test records

  4. November, week 411/22–11/28

    I2C and platform initialization cleanup

    Verify available I2C peripherals and organize clock and pinmux settings.

    Expected outcome

    I2C verification, initialization and platform-difference table

  5. November, week 511/29–11/30

    M1 reproducibility and gap review

    Check that cold boot through UART and basic interfaces is repeatable. No claim is made at this point of booting a full UI.

    Expected outcome

    M1 milestone summary, failure rate, and to-do list

12

December | Demo foundations and power proof of concept

Centered on reproducible M0 / M1 results, with power-off standby evaluated in parallel. The M2 fully operable prototype is scheduled separately.

  1. December, week 112/01–12/07

    Main power control proof of concept

    Using available hardware, check always-on control, main SoC power switching, and signal isolation. Record the actual test configuration.

    Expected outcome

    Power control tests, isolation and standby measurement records

  2. December, week 212/08–12/14

    Wake events and energy model

    Test wake strategies one by one with the available always-on controller, RTC, and LoRa module, measuring missed events, latency, and boot energy.

    Expected outcome

    Wake tests, revised energy budget; unfinished items listed separately

  3. December, week 312/15–12/21

    Evaluate the M2 integration path

    Based on documentation and board test results, estimate the work for display, touch, storage, and file system, and confirm staffing needs.

    Expected outcome

    M2 work breakdown, documentation gaps, and effort estimate

  4. December, week 412/22–12/28

    Prepare the milestone demo

    Demonstrate the M0 / M1 and power concept tests actually completed, listing limitations, resources used, and acceptance items still open.

    Expected outcome

    Milestone demo video, test summary, and resource usage record

  5. December, week 512/29–12/31

    Set the next-phase schedule

    Schedule M2 based on acceptance results, parts delivery, and available hours. M3 / M4 will be scheduled once core operation is in place.

    Expected outcome

    Next-phase scope, resource needs, and revised timeline

Acceptance results decide the next phase.

Code and external firmware

Confirm provenance rules, the linked image, and the terms for obtaining and using DDR and BL31 before starting platform work.

Boards and documentation

If funding, parts delivery, or boot documentation stalls, keep QEMU verification and testing on available equipment going, and reschedule M1.

Fully operable prototype

M0 / M1 is not a usable device. M2's display, touch, storage, and UI must be integrated and accepted separately.

About the M0–M4 milestones →See the support we need now →

Current decisions

Decided choices

Product roles

CORE centers on a portable phone form factor. MAX centers on a landscape tablet and field collaboration.

CORE architecture

Main compute is an OSM Size-L MediaTek Genio 720 (MT8391, industrial-grade) compute module, paired with a six-layer carrier board, a 1S battery, eSIM, and LR2021 (923 MHz). The operating system is built in-house.

MAX architecture

Compute platform under selection. Takes nano-SIM and eSIM, and offers more room for maps and information.

To be verified

From design to hardware

The items below still need to be confirmed.
They do not indicate passed tests.

  1. Hardware revisions and interface integration

    Align the new schematic, bill of materials, module pinout, and display and communication interfaces.

  2. Battery, power consumption, and charging

    Confirm the cell configuration, power draw in each operating state, charging conditions, and overall battery life.

  3. System boot and functional verification

    Step by step, confirm the boot flow, drivers, messaging, positioning, and map operation.

  4. Mechanical and field testing

    Verify thermals, grip, contacts, antennas, and environmental resilience, producing traceable test data.

About this information

How to read product information

"Design decision" means a configuration the team has chosen but not yet verified on real hardware. "To be verified" means it still needs to be confirmed through actual integration and testing. Neither is a shipped product specification.

Product images on this site are exterior concept illustrations. Battery life, protection, size, weight, and performance will be determined by later decisions and measurements.

Compiled from the WAYFINDER master design sheet and project selection records. Older configurations in past documents are not current product commitments.

Join the discussion

Bring your needs into development.

Share how you work, the constraints you face, and the questions worth testing.

Contact the team