There is something quietly radical about seeing a $30-class USB television tuner behave like the front end of a handheld public-safety scanner, aircraft tracker, pager decoder, spectrum analyzer, and sub-GHz signal recorder, while the computer driving it is not a laptop, not a Raspberry Pi, and not even a conventional single-board Linux machine. LakeShark is interesting because it sits at the point where software-defined radio stops feeling like a desktop activity and starts looking like embedded firmware. It takes a LilyGO T-Display P4, built around Espressif’s ESP32-P4, plugs an RTL-SDR Blog V3 or V4 into its USB host port, and turns the pair into a self-contained portable SDR receiver with a touch display, GPS, optional keyboard, waterfall, and several decoders that would once have implied a much larger software stack.
The headline feature is not simply that LakeShark receives radio signals. Cheap SDRs have been doing that for more than a decade. The striking part is the range of demodulation and protocol work being pushed into a microcontroller-class device: P25 Phase I conventional and trunked voice, analog FM and AM reception, POCSAG pager decoding, 1090 MHz ADS-B aircraft messages, spectrum and waterfall display, passive sub-GHz capture, LoRa and MeshCore functions through the board’s own radio hardware, GPS-assisted scanning, offline maps, and GPX track recording. In the older mental model of RTL-SDR, the dongle was a small RF peripheral attached to a real computer. LakeShark changes the emphasis. The RTL-SDR remains the radio front end, but the intelligence around it—the USB transport, tuning control, digital signal processing, protocol decoding, audio generation, and user interface—runs on a handheld embedded board.
That distinction matters because software-defined radio has always been partly constrained by where the “software” was allowed to live. In professional systems, SDR moved signal processing from analog circuits into FPGAs, DSPs, CPUs, and increasingly GPUs. In hobbyist and research settings, it often meant a USB device streaming I/Q samples into GNU Radio, SDR#, SDR++, GQRX, dump1090, OP25, multimon-ng, or sdrtrunk on a desktop operating system. The PC was not incidental; it supplied floating-point compute, memory, filesystem, display, audio routing, drivers, and a rich application environment. LakeShark does not make those problems disappear. Instead, it shows that enough of them can now be solved inside a modern microcontroller platform to make a credible field receiver, and that is a meaningful change in the engineering economics of SDR.
From DVB-T Dongle to Embedded Radio Workbench
The RTL-SDR story began as a useful accident. USB DVB-T television receivers built around the Realtek RTL2832U demodulator could be persuaded to output raw I/Q samples rather than decoded television. Paired with tuner chips such as the Rafael Micro R820T, R820T2, R860, or R828D, these sticks became inexpensive receive-only SDRs covering large parts of the HF, VHF, and UHF spectrum. They were limited devices by professional SDR standards: typically 8-bit sampling, modest instantaneous bandwidth, weak large-signal behavior compared with high-end receivers, and front ends that could overload in dense RF environments. Yet their cost, availability, and openness created one of the most important grassroots radio platforms of the last decade.
An RTL-SDR dongle is not a complete radio in the traditional sense. It is closer to a programmable tuner and digitizer. The tuner selects and downconverts a slice of spectrum, the RTL2832U produces digital I/Q samples, and software running elsewhere performs the rest: filtering, demodulation, squelch, symbol timing, frame synchronization, decoding, error correction, audio output, display, logging, and network export. On a desktop PC, that division of labor is easy to hide. A user opens a waterfall, clicks a signal, chooses NFM, AM, WFM, ADS-B, POCSAG, AIS, P25, or another mode, and the machine absorbs the cost. The CPU has headroom, memory is plentiful, and the screen can redraw a spectrum at interactive rates.
Embedded SDR is less forgiving. A microcontroller has to move I/Q samples over USB without losing timing, run real-time DSP without starving the user interface, maintain audio buffers, handle touch input, keep peripheral power rails sane, and avoid turning every algorithm into a battery-draining heat source. The 8-bit samples from an RTL-SDR may sound light compared with 12- or 16-bit SDRs, but 2.4 MS/s of complex I/Q still represents a steady data stream that must be received, buffered, decimated, filtered, and interpreted. A handheld receiver cannot behave like a Python script on a workstation. It needs predictable latency, careful memory allocation, and algorithms shaped by the realities of the processor.
The ESP32-P4 is a useful signpost for why LakeShark is possible now. Unlike earlier ESP32 chips, which became famous for combining Wi-Fi, Bluetooth, and microcontroller functionality in small IoT devices, the P4 is aimed more at human-machine interfaces, multimedia, display-heavy embedded products, and high-throughput peripherals. The LilyGO T-Display P4 adds a large touchscreen, audio hardware, GPS, battery management, an ESP32-C6 co-processor for wireless connectivity, an SX1262 LoRa transceiver, sensors, and an optional keyboard expansion with additional radio-oriented hardware. This is not a bare microcontroller breakout board; it is closer to a compact embedded terminal. That makes it unusually well suited to a project that needs to be both a radio and an interface.
LakeShark’s use of the RTL-SDR Blog V3 or V4 is also pragmatic. The V3 and V4 are well-understood devices in the SDR community, with stable mechanical form factors, SMA connectors, TCXO frequency references, software-controllable bias tees, and known driver behavior. The V4 added several RF improvements over generic dongles, including a different tuner arrangement, improved HF handling through an upconverter design, band triplexing, filtering changes, and a cleaner power design intended to reduce heat and phase-noise problems. None of that turns the RTL-SDR into a laboratory-grade receiver, but it does make it a more predictable front end for portable experiments. Predictability is valuable when the rest of the system is already pushing the limits of embedded USB and DSP.
The result is not a replacement for every PC-based SDR workflow. It is better understood as a field instrument built around a narrow but ambitious set of receive tasks. A desktop SDR environment can run multiple wideband decoders, record baseband files, chain arbitrary blocks in GNU Radio, and absorb experimentation without worrying much about flash partitions or display timings. LakeShark trades that generality for portability and immediacy. It is a device you can hold, power from a battery, use outdoors, carry to an antenna site, or leave running without a laptop. For radio hobbyists, emergency communications observers, spectrum experimenters, and embedded developers, that shift changes the feel of SDR from “computer with an antenna” to “radio with software inside.”
Why P25 Trunking Is the Hard Part
Of LakeShark’s supported modes, P25 Phase I trunked voice is the one that best illustrates the engineering jump. Analog FM scanning is not trivial on an embedded device, especially when the same system is also drawing a spectrum display, but the core signal chain is well established: tune, sample, channel filter, FM demodulate, de-emphasize, squelch, and send audio to a DAC or codec. ADS-B and POCSAG are digital, but they are comparatively narrow in the structure of what a receiver must do once it has the right RF signal. P25 trunking asks for a more scanner-like behavior: understand a control channel, track system activity, follow talkgroups, retune at the right time, demodulate digital voice, decode metadata, and convert compressed voice frames into intelligible audio.
Project 25 Phase I is a digital public-safety radio standard designed for 12.5 kHz channels. The common air interface uses C4FM, a four-level frequency modulation scheme carrying 9,600 bits per second. Voice is encoded using IMBE, a vocoder designed to produce intelligible speech at low bit rates under mobile radio conditions. A conventional P25 receiver can remain on one channel and decode voice when a transmission appears. A trunked receiver has a different job. It must monitor the trunking control channel, interpret signaling messages that announce which talkgroup has been assigned to which traffic channel, and then retune quickly enough to follow the conversation. That is why P25 trunking has historically been the domain of dedicated scanners or PC software such as OP25 and sdrtrunk.
The difficulty is not only the radio modulation. It is the whole pipeline. A receiver must recover symbols from a noisy FM channel, detect frame synchronization, correct errors, extract network access codes and talkgroup information, handle trunking messages, manage channel lists, and feed IMBE parameters into a vocoder. Each stage has latency and error behavior. Miss a control-channel message and the receiver may fail to follow a call. Lose symbol timing and voice becomes garbled. Retune too slowly and the beginning of a transmission disappears. Use too much buffering and the user hears audio late. Use too little buffering and the system underruns when the display or USB stack briefly consumes attention.
On a PC, this can be spread across threads and processes with generous CPU margins. On an embedded system, every stage has to be made lean. LakeShark’s project notes point to the use of fixed-point vocoder work derived from OP25 lineage, which matters because floating-point-heavy DSP is often the wrong fit for constrained real-time devices. Fixed-point algorithms can be faster and more predictable on microcontrollers, but they also demand care. Scaling, saturation, rounding, and numerical stability become design concerns. A decoder that sounds fine on a laptop may need significant adaptation before it behaves under FreeRTOS scheduling, limited RAM, and real-time audio deadlines.
Trunked P25 also exposes one of the RTL-SDR’s physical limitations: it is a single receive chain. A dual-receiver scanner or multi-SDR PC setup can monitor a control channel continuously while another receiver follows a voice channel. With one dongle, the receiver must decide when to leave the control channel, how to return, and how to manage missed updates. In practice, many affordable trunking receivers make similar compromises, but the compromises are sharper when the hardware is both cheap and embedded. LakeShark’s significance is that it attempts this in a handheld microcontroller environment rather than assuming a Linux host and multiple processes.
There is also the public-safety reality. P25 systems vary widely. Some are conventional, some trunked, some simulcast, some encrypted, some Phase I, some Phase II TDMA, and many are configured in ways that make reception more difficult than a clean lab signal. Simulcast distortion can confuse receivers when multiple transmitters arrive with slightly different delays. Weak indoor signals may show enough energy on a waterfall but not enough quality for reliable symbol decisions. Strong nearby transmitters can overload an 8-bit front end. Encryption, when used, stops intelligible voice reception regardless of decoder quality; the receiver may detect activity and metadata, but the content is intentionally unavailable. A responsible SDR receiver has to live within those realities rather than promising magic.
LakeShark’s P25 capability is therefore impressive not because it makes P25 easy, but because it compresses so much of the receive chain into a pocketable device. It turns an ESP32-P4 board into something that behaves less like a sensor node and more like a specialized radio appliance. The conventional-versus-trunked distinction, the live display of network access code, talkgroup, source, and decoder health, and the ability to use profiles and scan lists all point toward a tool built for real monitoring workflows rather than a single proof-of-concept demodulator. That is a meaningful boundary crossing in embedded SDR design.
A Receiver for Many Different Kinds of Signals
The rest of LakeShark’s mode list is technically revealing because the signals have very different personalities. POCSAG, ADS-B, analog FM, sub-GHz OOK captures, and LoRa/MeshCore are not just different “apps” in a menu. They exercise different parts of the system and demand different assumptions about timing, bandwidth, decoding, display, and user interaction.
POCSAG is an old paging protocol, but it remains a useful test of narrowband digital reception. It typically uses two-level FSK at data rates such as 512, 1200, or 2400 bits per second, with a structure of preamble, synchronization codewords, address codewords, message data, and error correction. Compared with P25, POCSAG is simple, but that simplicity is deceptive in the field. Paging transmitters can be strong, intermittent, and sometimes located far from the receiver. Signals may be inverted depending on the demodulation chain. Messages can arrive in bursts that require the decoder to acquire quickly and remain locked. The receiver must make decisions about bit slicing, timing recovery, BCH error correction, message assembly, and display formatting. On a handheld SDR, it also needs to present the result in a way that is useful without becoming a privacy hazard or an unreadable firehose.
The continued presence of POCSAG in radio monitoring also brings an ethical and legal dimension. Pager traffic in some regions may include sensitive operational, medical, industrial, or personal information, even when transmitted without encryption. The engineering fact that an SDR can decode a signal does not automatically make collection, storage, redistribution, or publication lawful or appropriate. LakeShark’s capability is technically interesting because it demonstrates embedded FSK decoding and message handling; users still need to understand the laws and norms governing reception in their jurisdiction. The same is true, in different ways, for public-safety voice and sub-GHz capture. A portable receiver increases convenience, and convenience increases responsibility.
ADS-B occupies the opposite end of the design spectrum: it is fast, pulse-like, and aviation-specific. At 1090 MHz, aircraft Mode S transponders emit extended squitter messages that can carry identity, altitude, position, velocity, and other data. The physical layer uses pulse-position modulation, and ADS-B messages are short, frequent, and often receivable with modest antennas when aircraft are in line of sight. For a desktop user, ADS-B reception with an RTL-SDR is one of the classic “first successes”: tune to 1090 MHz, run dump1090 or a similar decoder, and watch aircraft appear on a map. On an embedded handheld, the signal chain becomes a real-time pulse detector and decoder tied to a display, traffic table, local history, GPS position, and possibly offline maps.
ADS-B is well matched to portable SDR in one sense because the information is immediately visual. A receiver that can show aircraft around the user does not need internet connectivity to feel alive. It also benefits from GPS, because the receiver’s own position matters for range rings, relative bearing, and local situational context. But ADS-B also highlights antenna and RF constraints. At 1090 MHz, small antennas can work surprisingly well, but placement dominates performance. A receiver indoors, behind coated glass, or held low to the ground may see only a fraction of the traffic visible from a rooftop antenna. The RTL-SDR’s 8-bit dynamic range can be strained by nearby strong signals, and front-end filtering is often helpful if cellular, broadcast, or other RF energy is present. LakeShark can decode the messages, but physics still decides what reaches the dongle.
Analog FM and AM reception might seem ordinary by comparison, yet they are important because they make the device feel like a general-purpose radio. Narrowband FM remains common in amateur radio, business radio, marine, airband adjacent workflows depending on modulation support and band planning, and many local services. A waterfall and spectrum view turn tuning from a blind channel-entry process into visual exploration. Tap-to-tune behavior, stepped-band scanning, and mixed channel lists are user-interface choices as much as DSP features. They make the difference between a decoder demo and a receiver someone might actually carry.
Sub-GHz capture adds another layer. Many short-range devices use on-off keying, frequency-shift keying, or proprietary packet formats in ISM bands. A passive receiver that can observe pulses, group duplicates, store captures, and export formats compatible with tools such as the Flipper ecosystem fits into a broader world of low-power device analysis. The responsible emphasis is passive observation, not unauthorized replay or interference. Technically, however, it is a natural extension of the same SDR idea: once the signal is converted into samples or edge timings, software can classify, store, and display behavior that an analog receiver would reduce to clicks or noise.
LoRa and MeshCore are different again because the LilyGO board includes its own SX1262 transceiver. That means LakeShark is not only using the RTL-SDR as a wideband receive front end; it is also coordinating onboard radio hardware. LoRa is a chirp spread-spectrum technology with very different processing assumptions from P25 C4FM or ADS-B pulse-position modulation. MeshCore nodes, offline maps, and GPS tracks turn the device toward field communications and situational logging rather than pure signal decoding. The architecture begins to resemble a radio workbench: one external SDR for broad reception, one onboard transceiver for low-power mesh experiments, a GPS receiver for context, and a touchscreen interface to tie it together.
The Architecture Behind the Illusion
The user experience LakeShark aims for is simple: plug in the dongle, choose an app, tune, decode, and view results. Underneath, the system has to solve a set of problems that are easy to underestimate because desktop operating systems usually hide them. The first is USB host control. The RTL-SDR was designed as a USB peripheral expecting a host with driver support. A microcontroller must enumerate the device, configure endpoints, initialize the tuner and demodulator, set sample rate and gain, manage transfers, and recover gracefully from stalls or power events. This is not the same as reading a UART sensor. High-rate isochronous or bulk-like sample movement places constant pressure on memory and scheduling.
Then comes buffering. SDR pipelines are pipelines precisely because each stage wants data in different shapes. USB delivers chunks. DSP filters want blocks. Demodulators may want continuous state. Protocol decoders want symbols, frames, codewords, or packets. Audio wants steady sample intervals. The display wants periodic updates but should not steal time from the decoder. If buffers are too small, short scheduling hiccups cause dropouts. If they are too large, latency grows and memory disappears. Embedded SDR firmware lives in this tension. The art is to allocate enough elasticity to survive real use without turning the receiver into a sluggish appliance.
Filtering and decimation are central. The RTL-SDR may deliver a couple of megasamples per second, but a P25 channel is only 12.5 kHz wide, POCSAG is narrowband, and analog voice occupies a small slice of the incoming spectrum.
Top comments (0)