RISC-V

For forty years the defense and aerospace industry has been locked into two proprietary instruction sets: x86 and ARM. Both are brilliant engineering achievements. Both are now strategic liabilities. x86 is a 1970s museum piece carrying half a century of backward-compatibility baggage: variable-length instructions, complex addressing modes, segmented memory ghosts, and a privilege-ring model that has been the root cause of Spectre, Meltdown, and an endless parade of side-channel exploits. It is fundamentally uncertifiable at DO-178C DAL-A without heroic tool qualification and runtime mitigation layers that burn watts, cycles, and schedule. ARM is cleaner, but it is owned and controlled by a foreign company headquartered in Cambridge, England, now majority-owned by Japanese capital. Every Cortex-M33, M55, and future M85 shipped into a U.S. weapon system, satellite, or drone carries a perpetual license encumbrance, export-control risk, and the quiet possibility that a future boardroom decision in Tokyo could raise royalties, restrict availability, or revoke architectural licenses overnight. RISC-V is different — deliberately, legally, and permanently.

• Open ISA, governed by a Swiss non-profit with U.S.-dominated board seats and U.S.-person technical steering committees. No single nation, company, or shareholder can hold it hostage.
• Clean-sheet 2010 design: fixed 32-bit instructions (or 16-bit compressed), three-operand load-store architecture, no legacy modes, no condition-code flags, no delay slots, no microcode backdoors.
• Designed from day one for static analysis, formal verification, and safety certification. Every behavior is specified; there is no “implementation-defined” escape hatch that vendors hide behind.
• Built-in extensibility that lets MRT add classified custom instructions for encrypted packet processing, constant-time crypto, or real-time sensor fusion — without paying royalties or asking permission from a foreign licensor.
• Physical memory protection (PMP) and upcoming enhanced PMP/ePMP give hard memory isolation in far fewer gates and with far less power than ARM TrustZone.
• Code density with the C extension routinely beats ARM Thumb-2 by 15–30 %, meaning smaller flash, fewer writes, longer life in radiation environments, and lower overall system cost.

And if you ever want to read some inspiring technical documentation, see the RISC-V specification at https://docs.riscv.org/reference/isa/unpriv/intro.html. Seriously - it is a rare blend of rigor, humility, and earnest desire to educate.

LoRa

LoRa is a low-power, wide-area network (LPWAN) technology designed for IoT applications requiring extended range, minimal energy consumption, and reliable data transmission in challenging environments. LoRa stands out for its ability to transmit data over distances up to 10-15 kilometers in rural areas or 2-5 kilometers in urban settings, all while using ultra-low power—ideal for battery-operated devices in remote or hostile locations.

At its core, LoRa leverages chirp spread spectrum (CSS) modulation, a technique borrowed from radar systems that spreads the signal across a wide bandwidth to achieve exceptional resistance to interference, jamming, and multipath fading—critical for contested aerospace and defense operations where GPS-denied or electronic warfare scenarios demand resilient comms. This PHY layer robustness, combined with adaptive data rates (from 0.3 kbps to 50 kbps), allows LoRa nodes to dynamically optimize for range versus throughput, ensuring mission-critical sensor data gets through even in noisy RF environments.

Bare-Metal Programming

Computers are fantastically complex, and become moreso every day. Unfortunately, computer performance and reliability have not grown nearly as rapidly. There are many opinions on why. This is ours -> programmers have become enamored with “elegant” solutions that are brutally brittle. They seek quick Results, but give up long-term Control.

This comes in many forms, but the most pervasive and pernicious is the tangle of third-party imports, libraries, frameworks, etc. upon which most current software is built. Such tools are tremendously useful in certain situations:

• Education - Where abstracting away some details allows you to better focus on others.
• Portability - The higher the diversity in target platforms, the higher your programming paradigm needs to rise.
• Freedom of Implementation - Allows the creator of a software capability to change how something is done without changing what is done.

These are extremely powerful concepts, and much of the awesome technology in the world was built on them, but these benefits come with costs:

• Shallow Learning - Standing on the shoulders of giants is great - but can you find a way to solve your problem when you have 512kB for your code? For developers who never venture far from 1GB-per-browser-tab Javascript apps that rely on 7 Github repositories, low SWaP-C systems are a real challenge.
• Opaque Systems - “It just works” often leads to “it’s not working, and nobody knows how it works, let alone how to fix it.”
• Code Bloat - Using OPC (Other People’s Code) can be a good way to test a concept, but code that is broadly used needs to cover a lot of bases in terms of hardware (x86, ARM, RISC-V, 32 bit, 64 bit) and software (Linux, macOS, Windows, ZephyrOS) - and that means more code.

That is why MRT prefers to create our own resources. There is, of course, a practical limit to this view.

“If you wish to make an apple pie from scratch, you must first invent the universe.” - Carl Sagan

We are not in business to make toys from “scratch” or cobbled together from a bunch of Github repos - we are in business to create tools that impress warriors and delight buyers. Bottom-line: expect to see a lot of hand-rolled C (not C++) and Assembly in our products.