Most LoRa mesh nodes have two chips: a radio transceiver, and a microcontroller that runs the mesh firmware and tells the radio what to do. A new reverse-engineering write-up argues that, at least for Semtech's LR2021, the second chip is mostly there to load code into the first. In a post published on 2 November 2026 titled "Your node doesn't need a microcontroller", Alex Beal describes a general-purpose CPU inside the LR2021 that the datasheet does not describe. He compiled his own C code for it and loaded it into the chip's patch RAM. The results are an on-chip FFT waterfall and a MeshCore repeater that keeps running on the radio after a host has loaded it.

Hackaday covered the work on 7 November, describing an on-board microcontroller with updatable firmware. (Hackaday spells the author's surname "Beale". His own Substack and GitHub use "Beal" and "beala", and this article follows him.) The notes, tools and findings are public in the beala/lr2021-re repository on GitHub.

The CPU the datasheet leaves out

According to Beal, the LR2021 contains a 32 MHz Synopsys ARCv2 EM core with 16 core registers and a 3-cycle multiply. The datasheet does describe a 4 KB patch RAM (PRAM), and tells users to load Semtech-provided patches into it before using the radio. The patch is an opaque binary blob sent over SPI. Beal's work rests on one observation: whatever executes those blobs is a CPU, and a CPU can run other code.

The repository lists what he had to map out first. The ROM was read over SPI and disassembled. The repo then documents a full host command map that includes 38 undocumented commands, a CPU memory map, and the hook points Semtech's own PRAM patch uses. Other findings include an AGC gain register, a hidden raw IQ capture mode, and a software LoRa receiver with a MeshCore decoder that works on raw IQ. The repo says it does not contain Semtech's ROM image, the disassembly or the datasheet.

Both the Substack post and the repo say the work builds on an earlier project. SAMS0N1TE's lr2021-sdr found undocumented command 0x0290 and the capture engine behind it, which turned the LR2021 into a SoapySDR-compatible receiver covering 100 MHz to 2.74 GHz, with transmit through 0x0293. That project used the radio as an SDR front end and moved the IQ samples off the chip. Beal's work does the opposite: it runs code on the radio itself.

There is one methodological caveat. Beal used an LLM for much of the reverse engineering, and Hackaday's coverage agrees that the task would have been near-impossible without that help. Readers who want to check the claims can use the repository, which has the tooling and notes but none of Semtech's proprietary material.

First test: an FFT waterfall that never leaves the chip

For his first payload, Beal wrote an FFT in C, compiled it for the chip, and drew a spectrum waterfall from inside the transceiver. The first version ran at 6.6 frames per second. After he switched to moving ADC samples into RAM by DMA, it ran at 462 fps, which he puts at a 70x speedup. What it shows is that the embedded core can do real DSP work alongside the radio hardware it sits next to.

Second test: a MeshCore repeater in 4 KB

The more ambitious result is a MeshCore repeater ported into a PRAM patch. According to the write-up, the patch handles:

  • Direct and flood routing
  • Trace packets and adverts
  • A TX queue of four full-size messages
  • A 64-entry deduplication table, so packets are only transmitted once
  • An advert timer driven by a 32 kHz counter at address 0xF11014

The patch cooperates with Semtech's ROM firmware by hooking its main event loop: a function pointer at gp+0x34 gets to inspect every event, so the repeater handles the events it cares about and passes the rest to the built-in firmware.

Two limitations matter for anyone who might build on this:

Adverts are pre-signed. Beal did not port MeshCore's cryptography. The repeater's advert is signed in advance and loaded into memory, so its timestamp never changes. That is enough to show the concept works, but it is not a full MeshCore implementation.

The chip's CPU cannot trigger a transmission directly. Beal found that the chip expects transmit bytes to arrive over the SPI bus, so the internal core cannot simply write the transmit buffer. After other attempts failed, his workaround is to switch the internal pull-ups and pull-downs on the SPI data lines on and off so that the chip effectively sends SPI commands to itself.

The microcontroller is also still on the board. Beal states that a host MCU is still needed to load the patch, since PRAM is filled over SPI. What changes is the host's role: once the patch is loaded, the host can sleep and the LR2021 does the repeating.

What was tested, and on what

The repository lists two test setups:

  • An nRF52840 on a Seeed XIAO, paired with a Seeed Wio-LR2021
  • A RAK3401 with a NiceRF LoRa2021F33-2G4 module

The sources do not include power-consumption measurements, range tests or long-duration stability data for the PRAM repeater. Any claim that this lowers a node's power draw or extends battery life is not supported by what has been published so far.

What It Means for Makers

Who it is for: This is research-grade work. It will interest people who reverse engineer RF silicon, MeshCore and LoRa mesh developers who want to know where their radios' limits are, and embedded engineers curious about the general-purpose cores tucked inside "dedicated" chips. It is not a firmware image to flash onto a deployed repeater. The advert is pre-signed with a fixed timestamp, encryption is missing, and transmit depends on an SPI pull-resistor workaround.

What it enables: The main point is architectural. If a transceiver's internal core can handle routing, deduplication and queuing, the host MCU could in principle sleep, do other work, or be replaced by a smaller part whose main job is loading the patch. Beal himself writes that running a whole mesh node inside the LR2021 is probably more trouble than it is worth, and suggests offloading carefully chosen functions instead. Even so, the FFT and repeater results show more compute inside the LR2021 than its datasheet suggests. Hackaday places the work in a recent streak of SDR-style features being unlocked in dedicated radio chips, and the hidden IQ capture mode and software LoRa receiver in the repo fit that pattern.

What it does not replace: Not the host microcontroller, which is still needed to load PRAM. Not a full MeshCore node, since cryptography is not ported. Not Semtech's own patch, which according to the repo fills nearly all of the 4 KB PRAM. The sources do not say whether custom code can be combined with Semtech's patch in the same PRAM.

Price and availability: The code and notes are freely available now in the beala/lr2021-re GitHub repository. The sources give no prices for the tested hardware (Seeed XIAO nRF52840, Seeed Wio-LR2021, RAK3401, NiceRF LoRa2021F33-2G4). Check current vendor listings before buying. The repo describes itself as independent research, not affiliated with or endorsed by Semtech, and warns that undocumented commands can hang the chip until it is reset. Nothing in the sources suggests Semtech supports this as a feature, and code built on undocumented commands and hook points could break with future silicon or patch revisions.

For now, the LR2021's CPU is something people have found, not something Semtech offers. Running a mesh repeater in 4 KB on it is a hack, and it is being published with its limitations stated.

Sources