AI-Driven Sub-6 GHz SDR-Based and Low-Cost Spectrum Analyzer for 5G and 6G Networks

Abstract

A spectrum analyzer is an essential instrument in telecommunications for observing and analyzing the power distribution of a signal across different frequencies. Traditionally, these devices are expensive and complex, limiting their accessibility. This paper presents an affordable spectrum analyzer prototype using a software-defined radio (SDR) module and a Raspberry Pi, coupled with a 10.1-inch touchscreen. Based on the HackRF One and Raspberry Pi 4B+, the system uses GNU Radio to capture, analyze, and display electromagnetic-signal spectra from 1 MHz to 6 GHz. The user-friendly interface and artificial intelligence-based voice module enable easy, accessible real-time selection of frequencies, bandwidth adjustment, and signal visualization, applicable to 5G and 6G networks.

1. Introduction

Over the past decade, the development and implementation of software-defined radio (SDR) systems have revolutionized wireless communications. Unlike traditional radio systems, SDR offers unprecedented flexibility and adaptability by enabling software-controlled modification of radio-frequency parameters—such as carrier frequency, bandwidth, and modulation—rather than hardware. This technological advancement has applications in many areas, from radio astronomy to spectrum monitoring [1,2]. Concurrently, the popularity of high-performance, low-cost computing platforms, such as the Raspberry Pi, has grown exponentially. These devices have proven to be computationally robust tools for implementing complex embedded systems, such as air quality monitoring, facial recognition door locks, and satellite tracking stations, due to their processing power, compact size, and low energy consumption [3,4]. The combination of SDR and Raspberry Pi presents an opportunity to develop affordable spectrum analysis systems for researchers, hobbyists, and professionals.

A spectrum analyzer is a versatile instrument for observing frequency-domain signals. It measures essential parameters such as frequency, power, gain, and noise in transmitters and investigates energy distribution across the frequency spectrum of known electromagnetic signals. In this context, this investigation provides valuable insights into bandwidth, modulation effects, and spurious-signal generation, thereby benefiting radio-frequency planning and testing. This paper aims to use SDR and Raspberry Pi to build and implement a low-cost, high-performance spectrum analyzer prototype. The suggested solution combines a Raspberry Pi that processes and displays the spectrum data in real time with a wideband SDR that records radio frequency signals over the 1 MHz to 6 GHz frequency range. This study is critical because it could make spectrum analysis tools more accessible to everyone, providing a low-cost, easy-to-use platform for wireless communications research. Additionally, the prototype has many real-world applications, including implementing adaptive communication systems, detecting communications in crowded radio-frequency environments, and monitoring the radio spectrum to identify interference and support frequency management.

Despite commercially available spectrum analyzers offering high-precision measurements, advanced dynamic ranges (in some cases exceeding 6 GHz), and calibration and operational certifications, acquisition costs typically range from several thousand to tens of thousands of US dollars (e.g., over USD 10,000) [5], depending on the instrument’s features and frequency ranges. This economic gap restricts their adoption in small universities, emerging laboratories, small businesses, and portable field deployments, particularly in resource-limited settings. Recent advances in SDR, open-source signal processing, and open-hardware embedded computing have enabled practical, low-cost solutions. In response, the proposed system is implemented at a total hardware cost of approximately USD 246, including the HackRF One, Raspberry Pi 4B+, and touchscreen interface, while maintaining essential real-time spectrum-monitoring capabilities across 1 MHz to 6 GHz. This cost reduction of over 95% compared to typical commercial-grade alternatives positions the proposed platform as a viable option for rapid signal diagnostics, field measurements, and educational scenarios in which theoretical or simulation-based frequency-spectrum analysis is sufficient. Appendix A 

Table A1. Comparison between representative commercial sub-6 GHz spectrum analyzers and the proposed low-cost prototype presented in this paper.

Ref.	Equipment	Frequency Range	Display	Portable	Battery	Touch	AI Voice	Cost (USD)	Remarks
[52]	Rigol DSA815	9 kHz–1.5 GHz	8” LCD	No	No	No	No	1200–1800	Entry-level benchtop analyzer intended for laboratory education and basic RF diagnostics.
[53]	Siglent SSA3032X Plus	9 kHz–3.2 GHz	10.1” LCD	No	No	No	No	2000–3000	Good cost-performance ratio with tracking generator and advanced measurement tools.
[41]	Deviser E8000A	9 kHz–3 GHz	Integrated LCD	Yes	Yes	Yes	No	4000–7000	Portable field instrument with integrated battery operation and touchscreen capabilities.
[54]	Keysight N9320B	9 kHz–3 GHz	LCD	No	No	No	No	5000–8000	Professional-grade instrument with higher calibration accuracy and sensitivity.
[55]	Keysight N9010B EXA	10 Hz–3.6 GHz	Large LCD	No	No	No	No	20,000–45,000	High-end laboratory analyzer with excellent displayed average noise level, phase noise, and modulation analysis.
Our work	HackRF One + Raspberry Pi 4B	1 MHz–6 GHz	10.1” Touchscreen	Yes	Yes	Yes	Yes	246	Standalone portable analyzer with real-time visualization, tactile interface, battery-backed operation, speaker audio demodulation, and AI voice assistant for accessibility and hands-free interaction.

shows a comparison between representative commercial sub-6 GHz spectrum analyzers and the proposed low-cost prototype.

Several studies have shown that low-cost SDR-based communication systems (in transmission, reception, or both) are feasible for educational use [6]. Most digital signal processing is performed in MATLAB [7] or in GNU Radio [8], with the latter preferred for its open-source nature [9]. For hardware, researchers use commercial platforms such as the USRP [8,10], which support transmission and reception at GHz frequencies [11], or more affordable platforms such as the RTL-SDR, which is receive-only and operates up to a few MHz [7]. On the other hand, recent approaches integrate artificial intelligence into SDR systems to perform spectrum sensing tasks and improve adaptivity in dynamic wireless scenarios. For example, Deep reinforcement learning (DRL) has been used for intelligent interference and jamming environments [12]. In [12], the authors proposed a dual-intelligence framework for satellite networks in which terminals and satellites employ DRL to mitigate jamming. Building on this, the authors in [13] introduce a DRL-based anti-jamming technique that employs transfer learning, thereby enhancing adaptability across a range of interference levels. While these studies focus on communication reliability and spectrum access optimization, our work complements them by proposing an SDR-based spectrum-monitoring solution with AI-driven interaction on a portable, low-cost platform.

Academic efforts in SDR-based spectrum analysis have demonstrated the feasibility of integrating SDR hardware with GNU Radio and establishing open-source frameworks for exploring the RF Spectrum in specific bands. For example, Costa et al. developed a spectrum analyzer operating in the 2.3–2.7 GHz band that uses a USRP, MATLAB, and GNU Radio [14]. Their proposal, related to cognitive radio, focuses on spectrum sensing and introduces an approach to reconstructing a broader spectral view from partial measurements. They provide experimental validation and concisely address implementation details. While this work serves as a starting point, it does not fully address the level of standalone operation, integration, or accessibility targeted here.

Other works have employed low-cost SDR-based implementations on embedded platforms. For example, in [15], the authors proposed a GNU Radio-based spectrum analyzer using a Raspberry Pi 2 and an RTL-SDR dongle, enabling standalone operation. However, this work is oriented only to analog radio reception for educational purposes, and the prototype presented operates in the range from 30 MHz to 1.7 GHz. In a similar vein, the authors in [16] describe the development of a portable analyzer focused on digital terrestrial television and FM bands. While they considered portability and accurate visualization, this approach remains focused on broadcast services. Additionally, Harianto et al. in [17] performed SDR-based measurements against a commercial analyzer in a narrow frequency range, demonstrating accurate results under controlled conditions, but not in real-world deployments. In contrast to these earlier studies, more recent work by Perotoni and dos Santos in [18] analyzes wideband monitoring, dynamic range, and sensitivity using a HackRF One platform and a PC-based architecture. Furthermore, to address the need for portability, the work in [19] presents a HackRF- and Raspberry Pi-based system for RF-EMF assessment that includes georeferencing and database integration. Finally, building on these advancements, the authors in [20] presents an even more modern approach, proposing an embedded SDR analyzer using the USRP N210 and Raspberry Pi 5 for constrained FM-band analysis.

Table 1. Comparison of SDR platforms for spectrum analysis applications [15,20,21].

Platform	ADC	Max Sample Rate	Duplex	Interface	Limitation
USRP N210	14-bit	100 MS/s	Full	GigE	High cost ($2300–$3500)
bladeRF	12-bit	40 MS/s	Full	USB	Spurious artifacts
RTL-SDR	8-bit	2.8 MS/s	RX only	USB	Poor sensitivity (−83 dBm)
HackRF One	8-bit	20 MS/s	Half	USB	High noise floor

presents a comparison of representative SDR platforms used in spectrum analysis applications. High-performance platforms such as the USRP N210 provide high resolution and wide sampling rates, enabling accurate measurements at the cost of increased system complexity and hardware cost. Mid-range platforms such as bladeRF offer improved bandwidth and full-duplex capability, although they may introduce spurious artifacts due to RF front-end limitations. Low-cost solutions such as RTL-SDR and HackRF One provide accessible alternatives, but their reduced ADC resolution and higher noise floor limit sensitivity and measurement accuracy.

Despite progress in aspects such as analog broadcast analysis, laboratory validation, educational platforms, cognitive radio sensing, and RF-EMF, previous contributions remain limited. Their shortcomings include a limited operating range, limited information on system integration, limited implementation details, dependence on external computers, reduced interaction capabilities, limited field portability, and reproducibility issues. In some cases, the information is brief, focused only on experimental results, or presented at a high level. In contrast, the spectrum analyzer proposed in this paper is fully integrated. It includes a detailed hardware description and justification, is battery-powered and portable, and features a 10.1-inch touchscreen for tactile use. The device operates from 1 MHz to 6 GHz, supports AI-driven voice interaction, and runs independently on a Raspberry Pi. We experimentally compare it against commercial hardware. These features position our proposal as a low-cost, open-source alternative and a practical, replicable platform for teaching, research, and field measurements in current and future 5G/6G-focused scenarios.

Table A2. Comparison of representative SDR-based low-cost spectrum analyzer proposals and the prototype presented in this paper.

Ref.	Main Applicability	SDR/Platform	Range	Portability	Battery-Powered	Touch Screen	AI Voice	Remarks/Contrast with This Work
[14]	Cognitive-radio sensing	USRP + GNU Radio + MATLAB	2.3–2.7 G	No	No	No	No	Depends on USRP and MATLAB; targets a narrow band; no standalone portable implementation.
[15]	AM/FM reception	RTL-SDR + RPi 2 + GNU Radio	30 M–1.7 G	Partially	No	No	No	Moves processing to the embedded platform, but lacks tactile and AI-assisted operation.
[16]	DTT monitoring	RTL2832U + SBC + GNU Radio	88–108 M/470–608 M	Yes	N/R	No	No	Service-specific and limited in frequency scope; no battery-powered tactile platform.
[17]	Lab validation	RTL-SDR + GNU Radio	60–80 M	No	No	No	No	Valuable as a narrowband simulation study, but not an integrated field-deployable instrument.
[18]	Wideband monitoring	HackRF + PC	Wideband	No	No	No	No	Oriented to PC-based operation rather than a portable autonomous instrument.
[19]	EMF exposure	HackRF + RPi 400 + GPS	1 M–6 G	Yes	No	No	No	Closest antecedent; well instrumented but primarily oriented to exposimetry and database.
[20]	FM monitoring	USRP N210 + RPi 5	88–108 M	Partially	No	No	No	Focused on FM broadcasting without the sub-6 GHz scope achieved here.
Our work	General purpose	HackRF + RPi 4B	1 M–6 G	Yes	Yes	Yes	Yes	Fully integrated open-hardware, battery-backed, tactile interface, and AI-driven accessibility.

compares existing proposals with the spectrum analyzer prototype presented in this paper. In summary, the main contribution of this paper is an integrated intelligent spectrum analyzer prototype that combines low-cost SDR hardware, real-time GNU Radio signal processing, standalone embedded operation, open-hardware reproducibility, and multimodal human–machine interaction. Unlike other SDR-based analyzers that focused on narrowband reception or signal visualization, the proposed platform presents a battery-backed portability, tactile operation, AI-assisted natural language control, and experimental comparison against a commercial device, thereby extending the use of low-cost SDR systems to feasible modern field-monitoring and educational sub 6 GHz with applicability ti 5G/6G scenarios.

The contributions of this paper are as follows:

• Design of a low-cost, battery-powered, portable, and tactile SDR-based spectrum analyzer operating from 1 MHz up to 6 GHz.
• Integrating GNU Radio signal processing with computing on a Raspberry Pi for standalone operation.
• Implementation of an AI-driven voice interaction interface enabling hands-free operation and configuration of the signal analyzed parameters.
• Development of a full reproducible open hardware prototype, including mechanical design, system integration, and parameter configuration.
• Experimental validation based on measurements, a comparative analysis with a commercial spectrum analyzer.

1.1. Background

1.1.1. Radio-Electric Spectrum

The radio-electric spectrum comprises electromagnetic waves that propagate through space without a guide and is used in various fields such as telecommunications, radio, television, security, transportation, emergencies, and research [22]. The use of different radio frequency bands is regulated by the International Telecommunication Union (ITU), which oversees the global management of the shared spectrum. The ITU’s radiocommunication regulations define various radio technologies and applications [23]. A radio frequency band, a contiguous and small section of the radio-electric spectrum frequencies, is typically used or reserved in this frequency range. Different applications are assigned to non-overlapping frequency ranges, as shown in Figure 1. The ITU’s role in establishing plans for each band and governing their use and sharing is crucial for preventing interference and defining protocols to ensure compatibility between transmitters and receivers, thereby ensuring system reliability [24].

1.1.2. Spectrum Analyzer

An electrical signal can be examined from two distinct perspectives: (i) in the time domain or (ii) in the frequency domain. While an oscilloscope facilitates the observation of instantaneous voltage values in the time domain, a spectrum analyzer does so in the frequency domain. Understanding these tools is crucial for anyone working in electrical engineering. Unlike an oscilloscope, which displays the sum of frequencies and harmonics on a digital screen, a spectrum analyzer shows individual frequencies and their amplitudes. The main types of analyzers are described below.

• Vectorial Spectrum Analyzer: This device operates based on the heterodyne principle, which states that two signals with similar frequencies can combine to create a new signal called the beat frequency. The vector spectrum analyzer then uses this beat frequency to determine the amplitude, phase, and other characteristics of the original signal, providing a comprehensive analysis of the signal’s properties [26].
• Swept Spectrum Analyzer: The swept spectrum analyzer operates with a systematic approach, measuring the response of the system being tested at each frequency. This is achieved by moving a sinusoidal signal across an RF spectrum. The process involves combining the signal from a local oscillator with the analyzer’s input, then filtering and amplifying the resultant signal. A linear scale for frequency and a logarithmic scale for amplitude are used to depict the results [26].
• Fast Fourier Transform Spectrum Analyzer: Through a mathematical process that separates the signal into frequency blocks, a Fast Fourier Transform (FFT) spectrum analyzer calculates the intensity of signals at different frequencies [27]. The block diagram of this spectrum analyzer is shown in Figure 2.
• Real-Time Spectrum Analyzer (RSA): This equipment, utilizing an FFT, seamlessly converts between the time and frequency domains, accurately measuring signal frequency and intensity [28]. Its continuous waveform-capture feature enables comprehensive analysis in a single view. The equipment’s exceptional sensitivity ensures the identification of weak signals. Moreover, it provides reliable, prompt responses to pulses by adjusting the trigger level and time window. A visual graph that effectively displays the results identifies issues such as distortion or noise, reassuring the audience about the equipment’s reliability [26].

Identification of the signal’s frequency, power, bandwidth, amplitude, and phase is among the spectrum analyzer’s primary test functions [29]. Furthermore, factors such as central frequency, analysis span, reference level, and bandwidth resolution are crucial to the operation of a spectrum analyzer. Figure 3 shows a comparison between the types of spectrum analyzers described above.

1.1.3. Software-Defined Radio

An SDR platform eliminates the need for hardware changes as technology advances by having software-defined parts or all of the physical-layer functions. This feature indicates that the radio system or device uses software to perform operational tasks, except for control tasks [30,31]. Figure 4 shows a timeline of the most significant events in the evolution and history of SDR.

The concept of SDR has changed over time, but the progress achieved has primarily stemmed from the same basic structure shown in Figure 5. SDR’s main functional components include:

• Radio Frequency (RF) section: Often referred to as the RF Front-End, it is responsible for sending and receiving RF signals, converting them to intermediate frequencies (IF) upon reception, or amplifying and modulating IF signals for wireless transmission.
• IF Section: During reception, this section converts the IF signal to baseband and digitizes it. During transmission, it converts the baseband signal to IF and performs analog-to-digital (ADC) or digital-to-analog (DAC) signal conversion, which is managed by the ADC/DAC modules.
• Baseband Section: This portion handles all baseband signal processing, including bit timing management, equalization, frequency hopping, and session formation. In certain situations, it is also responsible for implementing link-layer protocols within the OSI model.

Currently, there are a variety of SDR platforms available for experimentation and prototyping, including RTL-SDR, HackRF One, USRP, PlutoSDR, LimeSDR, and BladeRF [36]. Several software alternatives exist for controlling the hardware [36]; relevant examples are listed in

Table 2. Platforms to use with SDR modules, based on [9,37].

Software	Operating System	Description
SDR#	Windows	Developed for the Windows platform. It features a user-friendly graphical interface for tuning and demodulating AM, FM, and SSB signals. It is compatible with a wide range of SDR hardware, including RTL-SDR, HackRF, Airspy, and SDR#.
CubicSDR	Windows/Linux/macOS	Open-source software that runs on multiple operating systems. It provides an intuitive user interface with real-time spectrum and waterfall visualization.
Gqrx SDR	Linux/macOS	Open-source SDR receiver based on GNU Radio and Qt graphical tools. Licensed under the GNU General Public License (GPL), allowing users to modify and extend its functionality.
HDSDR	Windows	Free SDR software for Microsoft Windows systems (2000/XP/Vista/7/8/10/11). Formerly known as WinradHD, it is an advanced version of Winrad developed by Alberto di Bene.
SDR++	Windows/Linux/macOS	Open-source SDR software compatible with multiple platforms for receiving and processing radio signals.
Spektrum	Windows/Linux	Spectrum analysis software is widely used with RTL-SDR devices. It processes raw data from RTL-SDR to generate graphical representations of signal energy distribution in the frequency domain.
QTSDR	Linux	SDR software designed for Raspberry Pi devices. It uses the Qt library for its graphical interface and supports RTL-SDR hardware.
GNU Radio	Windows/Linux/macOS	Open-source software development framework that provides signal-processing blocks for creating and implementing SDR applications, widely used with low-cost hardware systems.

. For the development of this prototype, HackRF One was used as the hardware platform and GNU Radio as the SDR software platform. This choice was made due to the RF operating-frequency requirement (below 6 GHz) and the software’s open-source nature, which provides flexibility for software development.

2. Methodology

This section presents the design and implementation of the proposed spectrum analyzer. Figure 6 summarizes the processes considered in the development of the prototype.

2.1. Requirements Analysis

Figure 7 illustrates the requirements for implementing the spectrum analyzer prototype. The components included in the prototype are detailed below.

• Antenna: One or more antennas designed to capture RF signals in the range 1 MHz to 6 GHz are required. These antennas should have SMA male connectors to ensure a stable connection to the RF receiver module.
• Receiver Module: This module’s ability to receive RF signals across a broad spectrum from 1 MHz to 6 GHz demonstrates its versatility for comprehensive RF analysis. Furthermore, it should be light, weighing approximately 100 g, and compact, with dimensions of roughly 10 to 15 cm, to integrate all components into a single case and obtain a small, portable device. It is preferred that it be compatible with the Linux operating system, consume approximately 4 watts, and be powered via USB. Additionally, an SMA connector is required to connect external antennas.
• Open Hardware Platform: An open hardware platform with real-time signal processing capabilities is required, along with features that facilitate the integration of components, such as a touch screen for user interaction. To receive RF signals, the platform must have USB ports to connect an SDR receiver module, allowing the capture and analysis of these signals. In addition, it is essential that the platform be compact to enable a portable prototype and that it include a video output and a graphics card to support a touchscreen.
• Touch Screen: A touch screen of about 10 inches is sought to be integrated, as it provides optimal space for clear, readable display of data and graphics compared to low-cost commercial models. This dimension offers an ideal balance between portability and display space, enabling detailed information to be displayed without compromising the spectrum analyzer prototype’s portability.
• Control and Processing Software: This component requires the program to support appropriate capture settings, including sampling rate, bandwidth, and resolution. In addition, it must provide an interface to configure and control the underlying hardware, including functions for starting and stopping signal capture. The software must also include a section dedicated to signal processing, where operations such as filtering, spectral analysis, peak detection, and signal power calculation can be performed, all of which are essential for spectrum analysis. To facilitate interpretation of the results, the software should provide a graphical interface to visualize the captured data, including spectrum, time-frequency, and waterfall plots, as well as other visual representations. The user interface must be intuitive, with controls that allow adjustment of capture settings, selection of analysis options, and easy navigation through the results. Finally, it is essential that the software is compatible with the operating system used (e.g., Linux) and can be easily ported to other SDR platforms.
• Portable External Battery: The inclusion of a dedicated power module or battery bank is essential to ensure the prototype’s portability and autonomous operation. This component allows the spectrum analyzer to function without an external power source, which is crucial in environments with limited or no access to power outlets.

2.2. Specific Elements of the Spectrum Analyzer Prototype

This section describes the hardware and software components used in the spectrum analyzer prototype, and how each component meets the requirements set by the corresponding component in Section 2.1. To comply with the requirements of the open hardware platform, the proposed option is the Raspberry Pi 4B+, whose specifications are listed in

Table 3. Main features of the Raspberry Pi 4B+ board.

Raspberry Pi 4B+	Feature	Details
	Processor	Broadcom BCM2711, Quad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5 GHz
	RAM	8GB LPDDR4-3200 SDRAM
	Ports	2x micro HDMI (4Kp60), 2x USB 3.0, 2x USB 2.0, Gigabit Ethernet, GPIO with 40 pins
	Connectivity	Wi-Fi 802.11ac, Bluetooth 5.0, Ethernet
	Video and Audio	2x micro HDMI up to 4Kp60, stereo audio output via HDMI and 3.5 mm jack
	Power Supply	USB-C (5V 3A)
	Operating System	Raspberry Pi OS

, and which has demonstrated suitable operational performance when integrated with SDR platforms [38]. Given the requirements of signal processing,

Table 4. Main features of the GNU Radio software.

Feature	Details
Type	Radio signal processing software
Compatibility	Multiplatform (Linux, macOS, Windows)
Language	Implemented mainly in Python and C++
Functionalities	Provides signal processing blocks, supports various SDR hardware, data flow, and real-time processing
User Interface	GNU Radio Companion (GRC)
License	GNU General Public License (GPL)

presents the characteristics of the GNU Radio software that meet the parameters mentioned in Section 2.1. Similarly, the touchscreen requirements are detailed in

Table 5. Main features of the 10.1-inch IPS LCD screen.

Touchscreen LCD	Feature	Details
	Size	10.1 inches
	Resolution	1024 × 600 or 1280 × 800
	Screen Type	LCD IPS
	Touch Interface	Capacitive
	Connectivity	HDMI, USB (for touch functionality)
	Compatibility	Compatible with Raspberry Pi 5, 4B, and PC
	Power Supply	Via power adapter or USB port
	Mounting	Includes adjustable stand
	Extras	Stand included, for Raspberry Pi projects

. To achieve the required SDR module characteristics, the HackRF One model has been chosen, whose specifications are presented in

Table 6. Main features of the HackRF One module.

HackRF One RTL-SDR	Feature	Details
	Frequency Range	1 MHz to 6 GHz
	Sampling Rate	From 2 Msps to 20 Msps (quadrature)
	Resolution	8 bits
	Interfaces	High Speed USB (with Micro-B connector)
	Compatible Software	Works with SDR, HDSDR, SDR Console, GNU Radio, and other SDR software
	Power Supply	USB bus power
	Connectors	MCX antenna connector
	Size	100 mm × 60 mm × 21 mm
	Antenna Included	With SMA female connector (50 ohms)
	Clock	SMA female input and output for synchronization
	Microcontroller	LPC43xx ARM Cortex-M4

. Finally, to ensure portability of the spectrum analyzer prototype, a battery is included, with specifications shown in

Table 7. Main features of the portable battery.

Portable Battery	Feature	Details
	Output Interface	Type C 5V-3A
	Input Interface	USB to Micro USB
	Weight	240 g
	Battery Type	Lithium polymer battery
	Number of Devices	2 devices simultaneously
	Power Bank Shell	Aluminum alloy casing
	Screen	LED crystal digital display
	Fast Charging	22.5 W–10,000 mA

.

2.3. Structure and Implementation of the Spectrum Analyzer Prototype

To facilitate reproducibility, this section presents the configuration parameters and detailed information for the components that integrate the spectrum analyzer prototype, which are summarized graphically in Figure 8. The HackRF One is connected to a USB port on the Raspberry Pi, with the antenna positioned appropriately for signal reception, and operates as the system’s main RF front end. Speakers attached to the display’s audio output enable real-time playback of demodulated signals (e.g., FM signals), adding an auditory dimension akin to that of laboratory spectrum analyzers. A portable battery provides stable, continuous power to the Raspberry Pi 4B+ and all peripherals, including the HackRF One, touchscreen, and speakers. The microSD card (≥16 GB) stores the Raspberry Pi OS and required software, ensuring adequate capacity for applications and data. At the software level, GNU Radio is installed, and a flowgraph is developed to receive signals across the HackRF One’s operating range, integrating a GUI block to facilitate intuitive interaction and deliver functionality comparable to that of laboratory-grade spectrum analyzers.

2.4. Configuration Parameters of Components That Integrate the Spectrum Analyzer Prototype

Figure 9 provides a summary of the assembly and configuration of the prototype. The most significant steps are detailed below.

• GNU Radio Installation: To use GNU Radio, the operating system and all the dependencies of GNU Radio and related to the SDR platform must be updated and installed as shown in Code 1.

  Code 1. Command to install GNU Radio.

  1	sudo apt-get update
  2	sudo apt-get upgrade
  3	sudo add-apt-repository -y ppa:myriadrf/gnuradio
  4	sudo apt-get install gnuradio gnuradio-dev gr-iqbal
  5	sudo apt-get install gr osmosdr

  Code 1. Command to install GNU Radio.

  1	sudo apt-get update
  2	sudo apt-get upgrade
  3	sudo add-apt-repository -y ppa:myriadrf/gnuradio
  4	sudo apt-get install gnuradio gnuradio-dev gr-iqbal
  5	sudo apt-get install gr osmosdr

• Block Diagram Creation: The communications system diagram is designed using GNU Radio Companion, where the necessary blocks for signal reception, processing, and display are dragged and configured. The block diagram for a 1 MHz to 6 GHz receiver includes the following key blocks:

  –

  Osmocom Source Block: This block is part of the gr-osmosdr package, a collection of GNU Radio blocks that facilitate integration with various SDR receivers, such as HackRF One. The most essential parameters to be configured in this block are shown in

  Table 8. Parameters of the osmocom Source block.

  	Parameter	Description	Value	Unit
  	Output Type	Type of output data.	Complex Float32 (common for IQ signals)	NA
  	Device Arguments	Text string to specify the SDR device and its settings.	rtl = 0 (for an RTL-SDR)	NA
  	Sample Rate	Sampling rate in samples per second (SPS).	2 M	samples per second
  	Ch0: Frequency	Central frequency to which the receiver is tuned.	98.9	MHz
  	Ch0: Gain Mode	Gain mode, can be “True” for automatic or “False” for manual.	Manual	NA
  	Ch0: RF Gain (dB)	Radio frequency gain.	10	dB

  .

  –

  QT GUI Sink Block: This block displays the spectrum of a signal in real time and provides a graphical user interface (GUI).

  Table 9. Parameters of the QT GUI Sink block.

  	Parameter	Description	Value	Unit
  	FFT Size	Size of the Fast Fourier Transform.	1024k	points
  	Center Frequency	Central frequency to which the graph is tuned.	98.9	MHz
  	Bandwidth	Visualization bandwidth.	10	kHz
  	Update Rate	Indicates how many times per second the graph updates.	10	NA
  	Window Type	Type of window applied to the data.	Blackman-Harris (Ideal for spectral analysis requiring high frequency discrimination)	NA

  presents the configuration parameters of this block.

  –

  Rational Resampler Block: This block modifies a signal’s sampling rate without significantly altering its spectral content by employing decimation and interpolation algorithms. The interpolation factor determines the number of samples to add to the input signal. In contrast, the decimation factor specifies the number of samples removed from the input signal. The 

  Table 10. Parameters of the Rational Resampler block.

  	Parameter	Description	Value	Unit
  	Interpolation	Factor by which the signal sampling rate is increased.	32	NA
  	Decimation	Factor by which the signal sampling rate is reduced.	50	NA
  	Taps	Coefficients of the interpolation and decimation filters.	NA	NA
  	Fractional BW	Fractional bandwidth. Controls the amount of allowed aliasing.	0	NA

  shows the configuration parameters of this block.

  –

  Low-Pass Filter Block: This block eliminates high-frequency components above the specified cut-off frequency, 6 GHz.

  Table 11. Parameters of the Low Pass Filter block.

  	Parameter	Description	Value	Unit
  	Decimation	Factor by which the sampling rate is reduced after filtering.	8	NA
  	Gain	Gain applied to the filter.	1	NA
  	Sample Rate	Sampling rate of the input signal.	2 M	samples per second
  	Cutoff Frequency	Filter cutoff frequency.	100k	Hz
  	Transition Width	Transition bandwidth of the filter.	20k	Hz
  	Window	Window type used for filter design.	Hamming	NA
  	Beta	Parameter affecting the window shape, balancing stopband attenuation and transition bandwidth.	6.76	NA

  shows the respective block configurations. Figure 10 shows the complete block diagram used to receive and process signals from 1 MHz to 6 GHz. While Algorithm 1 shows the system-level workflow of the proposed SDR-based analyzer.

  Algorithm 1 System-level signal processing workflow of the proposed SDR-based spectrum analyzer

  1: Input: RF signal $r\left(t\right)$ captured by the antenna   2: Output: Real-time spectrum, waterfall, time-domain displays, and optional audio output   3: Initialize Raspberry Pi, GNU Radio environment, and HackRF One interface   4: Load user-defined or default parameters:     center frequency $f_c$, sample rate $f_s$, RF/IF/baseband gains, bandwidth $BW$   5: Configure Osmocom Source block with $(f_c,f_s,\mathrm{gains})$   6: Start continuous IQ acquisition from HackRF One   7: while system is active do   8:     Acquire complex IQ samples $x\left[n\right]$ from the SDR front-end   9:     Apply low-pass filtering to suppress out-of-band components:     $x_f\left[n\right]\leftarrow \mathrm{LPF}(x\left[n\right],BW)$ 10:     Apply rational resampling to match internal processing/display requirements:     $x_r\left[n\right]\leftarrow \mathrm{Resample}(x_f\left[n\right],I,D)$ 11:     Compute spectral estimate using FFT-based processing:     $X\left[k\right]\leftarrow \mathrm{FFT}\left(x_r\left[n\right]\right)$ 12:     Estimate magnitude/power spectrum and apply averaging if required 13:     Update frequency-domain visualization using QT GUI Sink 14:     Update waterfall display using time-sequenced spectral frames 15:     Update time-domain display using current sample window 16:     if audio monitoring is enabled then 17:         Apply quadrature demodulation to the filtered signal 18:         Adjust audio sample rate through resampling 19:         Send demodulated audio stream to Audio Sink 20:     end if 21:     if GUI command or voice command is received then 22:         Parse requested parameters $(f_c,BW,\mathrm{gain})$ 23:         Validate parameters against operational limits 24:         if parameters are valid then 25:            Update GNU Radio variables through callback functions 26:            Reconfigure acquisition and visualization blocks in real time 27:         else 28:            Reject command and provide user feedback 29:         end if 30:     end if 31: end while 32: Stop acquisition and release SDR and GUI resources

  The overall signal processing chain implemented in GNU Radio is illustrated in Figure 11. The workflow begins with configuring the SDR front-end parameters and continues with RF signal acquisition, filtering, spectral estimation, and real-time visualization. This structured pipeline ensures consistent processing from RF capture to spectrum display. First, the SDR parameters are configured, including the sampling rate, center frequency, RF gain, and analysis bandwidth. These parameters control receiver tuning and define the spectral window under analysis. The RF signal received by the antenna is then captured using the SDR front-end and converted into complex baseband IQ samples. The acquired IQ samples are processed using a low-pass filter to remove out-of-band noise and limit the effective bandwidth of interest. This filtering stage also reduces high-frequency components that may affect the spectral estimation. After filtering, the complex IQ samples are transformed into the frequency domain using a Fast Fourier Transform (FFT), enabling spectral analysis of the captured signal. The magnitude of the FFT output is then converted to a logarithmic power representation in decibels (dB), yielding the power spectrum of the received signal. To improve spectral stability and reduce noise fluctuations, temporal averaging is applied across consecutive FFT frames. This averaging step enhances the visibility of persistent spectral components while suppressing random noise variations.
  Finally, the processed spectrum is displayed in real time using the QT GUI frequency sink. This visualization provides continuous monitoring of the RF environment and enables the user to observe signal activity, bandwidth utilization, and power distribution across the frequency spectrum.
• Installation and Activation of the HackRF One Module: Code 2 installs all the dependencies required for the HackRF One module to work correctly. Signal reception is tested using the GQRX software.

  Code 2. Command to install all libraries for the operation of the HackRF One platform.

  1	sudo apt-get install git build-essential cmake libusb-1.0-0 dev liblog4cpp5-dev libboost-dev libboost-system-dev libboost thread-dev libboost-program-options-dev swig pkg-config libfftw3 dev
  2	sudo add-apt-repository -y ppa:myriadrf/drivers
  3	sudo add-apt-repository -y ppa:bladerf/bladerf
  4	sudo apt-get install hackrf
  5	sudo apt-get install libhackrf-dev
  6	hackRF_info
  7	sudo add-apt-repository -y ppa:gqrx/gqrx-sdr
  8	sudo apt-get install gqrx-sdr
  9	sudo apt-get install dfu-util

  Code 2. Command to install all libraries for the operation of the HackRF One platform.

  1	sudo apt-get install git build-essential cmake libusb-1.0-0 dev liblog4cpp5-dev libboost-dev libboost-system-dev libboost thread-dev libboost-program-options-dev swig pkg-config libfftw3 dev
  2	sudo add-apt-repository -y ppa:myriadrf/drivers
  3	sudo add-apt-repository -y ppa:bladerf/bladerf
  4	sudo apt-get install hackrf
  5	sudo apt-get install libhackrf-dev
  6	hackRF_info
  7	sudo add-apt-repository -y ppa:gqrx/gqrx-sdr
  8	sudo apt-get install gqrx-sdr
  9	sudo apt-get install dfu-util

• Connecting the HackRF One module to the Raspberry Pi platform: The HackRF One module is connected to one of the Raspberry Pi’s USB ports. Figure 12 presents a summary of the components of the HackRF One module to verify its correct connection and operation.
• Creation of an Interface to Capture and Process the Signals: This interface includes real-time displays of the frequency spectrum and tools for analyzing signal characteristics. The interface is programmed with the block diagrams provided by GNU Radio. Figure 13 shows a mock-up of the interface for visualizing the signals.
• Touch Screen and Audio System Assembly: The touchscreen is connected to the Raspberry Pi, as shown in Figure 14, to allow direct interaction with the system.
  To use the stereo speakers included with the touchscreen, the sound configuration must be included in the boot configuration file located in the root folder of the Raspberry Pi, as shown in Code 3. In Code 3, line 2 is used to define the type of HDMI signal that the Raspberry Pi should use, and the value equal to 1 indicates that all audio formats are supported by the touchscreen. Furthermore, in Code 3, the value 2 in line 3 enables the high-definition multimedia interface (HDMI). The values in line 4 of Code 3 are defined by the syntax shown in

  Table 12. Syntax of line 4 in Code 3.

  Parameter	Description
  clock	Pixel clock frequency in kHz
  hdisp	Number of active horizontal pixels
  hsync	Duration of horizontal sync pulse in pixels
  hfront	Duration of horizontal front porch in pixels
  hback	Duration of horizontal back porch in pixels
  vdisp	Number of active vertical lines
  vsync	Duration of vertical sync pulse in lines
  vfront	Duration of vertical front porch in lines
  vback	Duration of vertical back porch in lines
  polarity	Sync polarity. Specified as a combination of two values (0 or 1) separated by a comma (first for horizontal, then for vertical).
  aspect ratio	Screen aspect ratio. Common values are 3 (4:3) and 9 (16:9). Interlaced: If the signal is interlaced (1) or progressive (0).
  pixel-rep	Pixel repetition

  . Figure 15 shows the final version of the configuration file.

  Code 3. Command to be included in the boot file to activate the stereo speakers.

  1	sudo nano /boot/config.txt
  2	hdmi_force_edid_audio=1
  3	hdmi_drive=2
  4	hdmi_timings=1024 1 200 18 200 600 1 50 3 50 0 0 0 60 0 51200000 3
  5	sudo reboot

  Code 3. Command to be included in the boot file to activate the stereo speakers.

  1	sudo nano /boot/config.txt
  2	hdmi_force_edid_audio=1
  3	hdmi_drive=2
  4	hdmi_timings=1024 1 200 18 200 600 1 50 3 50 0 0 0 60 0 51200000 3
  5	sudo reboot

• 3D Case Design and Printing: The dimensions of each component described in Section 2.2 were considered to ensure an accurate fit within the case and to provide adequate openings for ventilation of heat-generating elements, as shown in Figure 16. Based on these constraints, the internal layout of the components was defined, and a supporting structure was designed to securely hold each element while maintaining full accessibility to all ports and connections, as shown in Figure 17. At this stage, Autodesk Inventor 2024 and Ultimaker Cura were used to develop a detailed model of the case, including the main enclosure, internal brackets, and cable routing.
• Finished Prototype: The 3D case developed for the spectrum analyzer prototype not only provides adequate protection for the hardware but also improves the device’s portability and handling. Figure 18 shows the finished prototype, including the top, right side, and rear views of the assembled device, highlighting the internal organization and access to essential ports and connections.

2.5. AI Voice Assistant Implementation

To facilitate spectrum analysis for users without an extensive technical background and to improve accessibility for individuals with reduced mobility, the prototype incorporates an artificial intelligence (AI) based feature. This section details this AI capability.

2.5.1. AI-Based System Architecture

The AI voice assistant module was integrated into the existing spectrum analyzer system via a Python-based interface layer that connects Google Cloud services to the GNU Radio signal processing backend. The implementation uses Google’s Speech-to-Text API to capture voice input and the Text-to-Speech API to generate audio feedback. For intelligent query processing, the system interfaces with Google AI Studio’s API, enabling advanced natural-language understanding and technical-knowledge retrieval.

2.5.2. Voice Recognition Pipeline

The speech recognition system operates continuously when the voice assistant mode is activated, following an eight-stage circular pipeline as illustrated in Figure 19. The process begins with Stage 1 (Audio Capture), in which audio input from a USB microphone connected to the Raspberry Pi is captured using the PyAudio library. The captured audio stream is then forwarded to Stage 2 (Speech Recognition), where Google’s Speech-to-Text service processes the audio data and returns transcribed text accompanied by confidence scores. This transcription mechanism enables the system to distinguish between intentional voice commands and background acoustic interference. A noise-threshold algorithm evaluates confidence scores to ensure that only deliberate voice commands with sufficiently high confidence trigger subsequent system responses, thereby filtering out ambient noise and unclear utterances.

2.5.3. AI Integration and Command Processing

Following successful voice recognition, the system proceeds through stages 3 to 6 of the processing pipeline, as shown in Figure 19. In Stage 3 (AI Query), the transcribed text is combined with a fixed system prompt that defines the assistant’s role as a spectrum analyzer operator with expertise in RF engineering and signal analysis. This composite prompt is then transmitted to Stage 4 (AI Processing), where the Google AI Studio API performs natural language understanding and technical parameter extraction. The AI model is instructed through prompt engineering to:

• Parse natural language requests into specific analyzer parameters (frequency, bandwidth, gain).
• Provide technical explanations when requested by the user.
• Suggest appropriate measurement settings based on the operational scenario.
• Return structured responses in a format suitable for programmatic parsing.

Stage 5 (Response Generation) yields the AI-generated response, which undergoes systematic parsing in Stage 6 (Validation & Execution). At this stage, a response parsing module extracts parameter values using regular expression patterns and validates them against the analyzer’s operational constraints (a frequency range of 1 MHz to 6 GHz, bandwidth limits, and gain boundaries). When invalid or out-of-range parameters are detected, the system initiates a clarification dialogue with the user through Stage 7, requesting reformulation of the command. Upon successful validation, the extracted parameters are applied to the GNU Radio backend through its variable callback system, enabling real-time configuration updates without interrupting the signal processing pipeline. Finally, Stage 8 (User Feedback) provides auditory confirmation via the Text-to-Speech system, completing the circular workflow and returning the system to its listening state for subsequent commands.

2.5.4. API Configuration Parameters

Implementing the AI voice assistant module requires integrating three Google Cloud services, each with specific technical configurations to ensure optimal performance.

Table 13. Google cloud speech-to-text API configuration parameters.

Parameter	Description	Value	Unit
Encoding	Audio encoding format for transmission	LINEAR16	NA
Sample Rate	Audio sampling frequency for recognition	16,000	Hz
Language Code	Recognition language model identifier	en-US	NA
Model	Speech recognition model type	default	NA
Audio Channel	Number of audio input channels	1 (Mono)	NA
Enable Automatic Punctuation	Adds punctuation to transcribed text	True	NA
Max Alternatives	Maximum number of recognition hypotheses	1	NA
Profanity Filter	Filters inappropriate language	False	NA
Use Enhanced	Uses enhanced recognition model	False	NA
Enable Word Confidence	Provides confidence score per word	True	NA

details the Speech-to-Text API parameters used for audio capture and transcription.

Table 14. Google cloud text-to-speech API configuration parameters.

Parameter	Description	Value	Unit
Language Code	Voice synthesis language identifier	en-US	NA
Voice Name	Specific voice model selection	en-US-Neural2-C	NA
SSML Gender	Voice gender specification	FEMALE	NA
Audio Encoding	Output audio format	MP3	NA
Sample Rate	Output audio sampling frequency	24,000	Hz
Speaking Rate	Speed of speech synthesis	1.0	NA
Pitch	Voice pitch adjustment	0.0	st
Volume Gain	Output volume adjustment	0.0	dB
Effects Profile	Audio optimization profile	telephony-class-application	NA

presents the Text-to-Speech API configuration for generating audio feedback to the user. Finally,

Table 15. Google AI Studio Gemini API configuration parameters.

Parameter	Description	Value	Unit
Model	Generative AI model identifier	gemini-2.5-flash	NA
Temperature	Randomness control in response generation	0.3	NA
Max Output Tokens	Maximum length of generated response	256	tokens
Top-P	Nucleus sampling threshold	0.95	NA
Top-K	Top-k sampling parameter	40	NA
Candidate Count	Number of response candidates	1	NA
Stop Sequences	Sequences to halt generation	None	NA
Safety Settings	Content filtering threshold	BLOCK_MEDIUM_ AND_ABOVE	NA
System Instruction	AI role definition prompt	RF Spectrum Expert	NA
Response MIME Type	Output format specification	text/plain	NA

specifies the parameters of the Gemini AI model used for natural language processing and command interpretation. These configurations were selected in accordance with Google Cloud’s official documentation and best practices for real-time voice-controlled applications [39,40].

2.5.5. Operational Workflow

Upon system initialization, users are presented with a voice-activated menu system. The assistant offers three primary operational modes, as shown in Figure 20.

1.

Parameter Configuration Mode: Users can speak commands such as “Set the center frequency to 100 MHz with 10 MHz bandwidth” or more complex requests such as “Configure the analyzer to measure FM broadcast signals.” The AI interprets these requests and automatically configures the appropriate parameters.

2.

Capture Mode: The system supports both local and remote capture capabilities. Local captures save screenshots of the spectrum to the Raspberry Pi’s storage, while remote captures use the Telegram Bot API to send images to a designated chat channel, enabling remote monitoring.

3.

Assistance Mode: When users request help or when the system cannot interpret a command, the AI assistant provides contextual guidance, suggests proper command formats, and offers technical explanations about spectrum analysis concepts.

2.5.6. Error Handling and User Feedback

The system implements a multi-tier error handling strategy. When the AI cannot confidently parse a user’s request, it initiates a clarification dialogue, providing examples of valid commands and asking for reformulation. The text-to-speech system gives audio feedback to all operations, confirming parameter changes and alerting users to any issues. If repeated attempts fail, the system gracefully returns to the main menu, ensuring users always have a clear path forward.

2.5.7. Integration with GNU Radio

The voice control system interfaces with GNU Radio via a custom Python module that modifies the running flowgraph’s variables in real time. This feature is achieved using GNU Radio’s built-in variable callback system, allowing seamless parameter updates without interrupting signal processing. The module maintains thread safety through appropriate locking, preventing race conditions in the signal-processing pipeline during voice-command processing.

3. Results

Immediately after the device powers on, the GNU Radio script begins to execute. To visualize the desired signal, the user must enter its central frequency and select the corresponding options, as shown in Figure 21. The graphical interface options are indicated below.

1.

Central Frequency: A central frequency value is entered, considering that the SDR module operates from 1 MHz to 6 GHz and the attached antenna covers a frequency range from 40 MHz to 6 GHz.

2.

Gain: A recommended predefined configuration is established to start in the “osmocom Source” block: (i) RF deactivated, (ii) IF gain at 16 dB, and (iii) baseband gain at 16 dB. In the GUI, IF gain controls can be adjusted to find the optimal configuration for the situation. If the gain is set to a low value (less than 5 dB), the signal may be masked by noise. Conversely, if the value is too high (close to 40 dB), distortion appears, manifesting as unexpected frequencies when increasing the gain, or the noise level being amplified more than the signal.

3.

Bandwidth: This value is the bandwidth applied to the spectrum visualization process to smooth the signal and reduce noise. A wider bandwidth can reduce spectrum update time and yield a smoother spectrum, whereas a narrower bandwidth can provide more detailed but slower visualization.

4.

Average: Calculates the average value of the received signal, and this average can be adjusted as required by the application.

5.

Frequency Display: A graphical representation showing how the amplitude of a signal varies as a function of frequency. In this visualization, the horizontal axis represents frequency, and the vertical axis shows the signal’s amplitude or power at each frequency.

6.

Waterfall Display: A graphical representation of signals where the horizontal axis shows frequency, the vertical axis shows time, and color or intensity represents the amplitude or power of the signal at each point. This feature allows the user to observe how the signal changes over time and to identify patterns or anomalies.

7.

Time Domain Display: This visual representation is used to observe and analyze signals as they evolve. It helps view a signal’s waveform, detect patterns, verify synchronization, and explore its modulation or temporal content.

3.1. Functions and Characteristics of the Prototype

Table 16. Cost of spectrum analyzer prototype components [42,43,44].

Component	Cost (USD)
Kit Raspberry Pi 4B+	86
Portable Battery	13
10.1-inch Touchscreen	62
HackRF One	73
3D-Printed Case	12
Total Cost	246

shows the detailed cost of each component (imported from Ecuador) used for the development of the spectrum analyzer prototype, demonstrating its economic viability compared to commercial solutions (e.g., Deviser E8000A, Tianjin Deviser Electronics Instrument Co., Ltd., Tianjin, China, spectrum analyzer), which costs thousands of dollars [41].

Table 17. Comparison between the prototype and the Deviser E8000A specifications [41].

Parameters	Prototype	Deviser E8000A
Frequency Range	1 MHz to 6 GHz	9 kHz to 3 GHz
RF input connector	SMA-type female, 50 ohms	N-type female, 50 ohms
Display Resolution	1024 × 600	640 × 480 pixels
Size	11 in diagonal	6.5 inch TFT color LCD
Power consumption	<12 W	<18 W
LAN TCP/IP interface	10Base, RJ-45 connector	10 M/100 M RJ45
USB interface	2 USB 2.0 and 2 USB 3.0	USB 2.0 port and USB 1.1 port
Resolution bandwidth	100 kHz to 1 MHz	1 Hz to 3 MHz
DC voltage	5 VDC	19 V DC @ 3.42 A
Display Log scale units	dB	0.1 to 1 dB/div in 0.1 dB step
		1 to 40 dB/div in 1 dB step
Display Linear scale units	V, mA, $\mathsf{\mu }$V	dBm, dBmV, dB$\mathsf{\mu }$V, mV
Noise floor for RBW = 100 Hz	−dBm	≤−130 dBm @ 1 MHz–1 GHz
and VBW = 3 Hz		≤−126 dBm @ 1 GHz–3 GHz

presents a comparison between the commercial equipment available in the Wireless Communications Laboratory at Escuela Politécnica Nacional, the Spectrum Analyzer Deviser E8000A, and the developed prototype. Both similarities and differences are highlighted with respect to functionality and features, emphasizing the prototype’s characteristics relative to a commercial model.

3.2. Receiver Sensitivity Considerations

One limitation of SDR-based spectrum analyzer implementations is the reduced receiver sensitivity compared to dedicated commercial spectrum analyzers such as the Deviser E8000A. This difference is primarily due to the higher noise figure of the SDR front-end, the limited number of analog filtering stages, and the absence of an integrated low-noise preamplifier. In addition, the dynamic range of low-cost SDR platforms is limited by the analog-to-digital converter resolution, thereby reducing the ability to detect low-power signals near the noise floor.

As a result, weak signals located close to the noise floor may be more difficult to observe compared to high-performance commercial instruments. This limitation is inherent to low-cost SDR platforms and should be considered when performing measurements in low-signal environments. Despite this limitation, the proposed solution remains suitable for educational environments, laboratory measurements, and short-range signal characterization, where signal levels are typically sufficient for reliable detection.

3.3. Measurement and Comparison

The measurements were conducted using different antennas depending on the frequency band under evaluation. A telescopic antenna covering the VHF band from 30 MHz to 300 MHz was used for FM and analog TV measurements. For the Wi-Fi band, a monopole antenna with a typical gain of 3 dBi and an omnidirectional radiation pattern was used. The antennas were directly connected to the SDR-based spectrum analyzer front-end. Finally, for the 5G-like OFDM signal measurements, a log-periodic antenna covering the frequency range from 850 MHz to 6500 MHz was utilized.

3.3.1. FM Radio Signals

For comparison purposes, measurements of FM radio stations from 88 MHz to 108 MHz were performed using the Deviser E8000A spectrum analyzer  [41]. These results are compared with the signals and data obtained with our spectrum analyzer prototype. The comparison is shown in

Table 18. Power values from the measurements of FM radio frequencies.

Frequency (MHz)	Station Name	Deviser E8000A Power (dBm)	Prototype (−dB)
88.1	Latina FM	−56.3	−34.83
88.5	La Metro FM	−49.5	−35.82
88.9	JM Radio	−46.6	−55.33
89.3	Radio Inti Pacha	−43.8	−38.05
89.7	HCJB La Voz de los Andes	−47.2	−38.52
90.1	Radio Festival FM	−48.3	−39.73
90.5	Radio Tropicálida FM	−44.2	−36.41
90.9	Radio Vigía FM	−49.8	−40.23
91.3	Radio Platinum	−43.7	−38.02
91.7	La Otra FM	−42.5	−40.84
92.1	Radio Visión	−43.3	−36.27
92.5	Radio Nuevo Tiempo	−41.3	−36.24
92.9	Exa FM	−48.5	−38.44
93.3	La Poderosa	−39.1	−38.87
93.7	Radio Eres	−58.2	−38.73
94.1	Galaxia FM	−46.3	−38.24
94.5	Radio Católica Nacional	−42.3	−42.44
94.9	La Única	−41.9	−42.52
95.3	Radio Gitana	−38.2	−40.57
95.7	Radio Pichincha	−43.7	−43.31
96.1	Radio Asamblea Nacional	−58.9	−46.12
96.5	Like FM	−42.2	−37.92
96.9	BBN Radio	−41.5	−41.86
97.3	La Radio Redonda	−44.8	−37.71
97.7	Joya	−50.7	−45.11
98.1	FM Mundo	−38.2	−32.12
98.5	Alfa Radio	−56.6	−52.12
98.9	Armónica FM	−36.9	−42.23
99.3	Área deportiva	−33.8	−43.21
99.7	Radio la Rumbera	−35.3	−44.52
100.1	Radio María	−34.7	−48.2
100.5	Radio Zaracay	−34.9	−43.52
100.9	Cultura FM	−37.8	−38.2
101.3	Blue Radio	−32.3	−36.74
101.7	Radio Sucesos	−35.2	−38.81
102.1	Radio La Red	−31	−37.2
102.5	Radio Francisco Estéreo	−36.2	−44.36
102.9	Radio Municipal	−28.2	−35.21
103.3	Urbana FM	−30.9	−38.45
103.7	Sonorama	−43.1	−41.12
104.1	Cobertura FM	−32.1	−43.6
104.5	Radio América	−37.2	−42.74
104.9	Contigo FM	−36.7	−36.31
105.3	Pública FM	−39.2	−42.41
105.7	CRE Satelital	−37.3	−41.85
106.1	Hot 106 Radio Fuego	−38.8	−38.12
106.5	Canela Radio	−37.4	−36.89
106.9	Radio Nacional del Ecuador	−51.2	−46.75
107.3	JC Radio	−42	−40.28
107.7	Más Candela	−43.3	−41.03

and Figure 22.

3.3.2. TV Signals

The frequency ranges of several television channels have also been analyzed. These results are presented in

Table 19. Power values from the measurements of television frequencies.

Channel Name	Video Carrier (MHz)	Audio Carrier (MHz)	Deviser E8000A Power (dBm) Video	Deviser E8000A Power (dBm) Audio	Prototype (−dB) Audio	Prototype (−dB) Video
Gamavision	55.25	59.75	−55.3	−64.2	−61.23	−69.28
Teleamazonas	67.25	71.75	−38.1	−51.3	−41.25	−63.18
TVC	77.25	81.75	−41.2	−46.3	−55.69	−67.54
EcuadorTV	175.25	179.75	−41.6	−44.3	−54.23	−67.79
Ecuavisa	181.25	185.75	−26.1	−37.9	−35.25	−58.98
TC Televisión	193.25	197.75	−39.5	−55.9	−49.14	−69.33
Channel 21	513.25	517.75	−44	−49.8	−55.36	−61.35
Channel 23	525.25	529.75	−46.2	−61.1	−76.23	−78.25

and in Figure 23.

3.3.3. Wi-Fi Signals

Subsequently, tests were conducted with a Wi-Fi network, yielding the signal power values shown in Figure 24 and

Table 20. Power and bandwidth measurements for Wi-Fi Signal (IEEE 802.11n).

Frequency (GHz)	Deviser E8000A Power (−dBm)	Prototype (−dB)
2.412	−56.3	−65.25
Channel bandwidth (MHz)	17.3	15.48

.

3.3.4. Mobile Telephony Signals

Bandwidth measurements of the 3G downlink and uplink cellular telephony signals were performed, and the results are shown in

Table 21. Power and bandwidth measurements for 3G mobile network signal.

Parameter	Deviser	Prototype
Downlink frequency range (MHz)	870–890	870–890
Uplink frequency range (MHz)	830–850	830–850
Power of downlink channels (dBm)	−64.9	−54.16
Power of uplink channels (dBm)	−54.5	−48.25
Downlink bandwidth (MHz)	3.904	3.802
Uplink bandwidth (MHz)	3.809	3.715

. The reference downlink signal from the DEVISER E8000A is shown in Figure 25, along with the information from our prototype’s signal.

3.3.5. Applicability to 5G and 6G Networks in the Sub-6 GHz Spectrum

Although the evolution towards 5G and 6G networks often highlights the use of millimeter-wave and terahertz frequencies to achieve extreme data rates, the sub-6 GHz spectrum remains valuable in these mobile telephony generations [45]. Thus, the proposed spectrum analyzer prototype, operating from 1 MHz to 6 GHz, is directly applicable to current 5G deployments and future 6G networks, as supported by the following information.

• Relevance in 5G New Radio (NR): The 3rd Generation Partnership Project defines two frequency ranges for 5G NR: (i) frequency range 1 (FR1) and (ii) frequency range 2 (FR2). FR1, commonly known as “Sub-6 GHz”, covers frequencies from 410 MHz to 7.125 GHz [46]. This range is crucial because it balances capacity with propagation characteristics that allow for wide-area coverage and indoor penetration, unlike FR2 (mmWave), which suffers from high attenuation. As shown in Table 22, the developed spectrum prototype covers most of the core 5G FR1 bands, including the widely deployed C-Band (n77, n78) and the 2.5 GHz band (n41), making it a viable, low-cost tool for monitoring commercial 5G signals.
• Role in 6G Networks: While 6G research focuses on the sub-THz spectrum (90–300 GHz) for short-range communication, the sub-6 GHz spectrum will remain essential for the “Coverage Layer” of 6G networks. According to the Global Mobile Suppliers Association and recent vision papers for IMT-2030 (6G), frequencies below 7 GHz will be re-allocated to ensure ubiquitous connectivity and to support control channels in higher-frequency bands [47,48]. Therefore, this prototype is not only capable of analyzing current 5G signals but also future-proof for monitoring the refarming of legacy bands (2G/3G/4G) into 6G coverage bands, validating its applicability to the transition towards IMT-2030 standards.

Table 22. Relationship between the prototype’s operating range and key 5G/6G bands [46,47].

Band	Frequency Range	Application in 5G/6G	Prototype Coverage
n71	617–698 MHz	5G Wide Area Coverage	Full
n28	703–803 MHz	5G/6G Indoor Penetration	Full
n41	2496–2690 MHz	5G Capacity Layer (TDD)	Full
n78	3300–3800 MHz	Core 5G Band (C-Band)	Full
n77	3300–4200 MHz	5G/6G Capacity	Full
n79	4400–5000 MHz	5G High Capacity	Full
Re-allocation	<3 GHz	Legacy bands migrating to 6G	Full

Table 22. Relationship between the prototype’s operating range and key 5G/6G bands [46,47].

Band	Frequency Range	Application in 5G/6G	Prototype Coverage
n71	617–698 MHz	5G Wide Area Coverage	Full
n28	703–803 MHz	5G/6G Indoor Penetration	Full
n41	2496–2690 MHz	5G Capacity Layer (TDD)	Full
n78	3300–3800 MHz	Core 5G Band (C-Band)	Full
n77	3300–4200 MHz	5G/6G Capacity	Full
n79	4400–5000 MHz	5G High Capacity	Full
Re-allocation	<3 GHz	Legacy bands migrating to 6G	Full

To further evaluate the applicability of the proposed solution to 5G scenarios, additional experimental validation was performed using a 10 MHz OFDM signal representative of Sub-6 GHz 5G New Radio transmissions. Since commercial 5G deployments are not currently available in Ecuador, a controlled laboratory setup was implemented as shown in Figure 26. A NI USRP-2943R software-defined radio platform was used to generate an OFDM waveform with bandwidth and spectral characteristics similar to those employed in 5G NR systems. The SDR transmitter was configured with a 30 dB gain and positioned 1 m from the measurement devices. The generated signal was then measured using both the proposed spectrum analyzer and a reference commercial instrument, the Deviser N8000A, as shown in Figure 27.

Prior to the comparison, both instruments were configured using identical measurement settings, including center frequency, span, resolution bandwidth (RBW), and detector mode. The SDR-based analyzer frequency axis was calibrated using a known OFDM signal generated with a predefined center frequency and bandwidth.

The proposed spectrum analyzer gain was set to 20 dB to avoid saturation while maintaining sufficient sensitivity for weak-signal detection. The captured IQ samples were processed using FFT-based spectrum estimation with averaging to reduce noise-floor variations.

The measurements obtained from both systems exhibit similar spectral behavior, particularly in terms of center frequency and occupied bandwidth. For this measurement, the central frequency of the OFMD signal is 2.593 GHz, consistent with measurements from the Deviser E8000A and the proposed spectrum analyzer. This agreement validates the accuracy of the proposed solution for characterizing wideband OFDM signals. Furthermore, to generate the results presented in Figure 27a, the raw data obtained from the spectrum analyzer were exported and post-processed using additional Python-based signal processing routines. This processing enabled consistent visualization and direct comparison of the proposed solution with the reference instrument measurements.

Phase noise characterization was performed using the captured complex IQ samples. The instantaneous phase was extracted and processed to estimate phase noise as a function of offset frequency. The results shown in Figure 28 demonstrate that the proposed system can evaluate oscillator stability for wideband OFDM signals.

The comparison was repeated for several signals to demonstrate consistency of the proposed solution across different frequency ranges, as shown in

Table 23. Quantitative evaluation of center frequency and bandwidth measurements across different bands.

Band	Ref. CF (GHz)	Meas. CF (GHz)	CF Error (MHz)	Ref. BW (MHz)	Meas. BW (MHz)	BW Error (%)
n41	2.593	2.5920	1.0	10	9.80	2.0
n50	1.475	1.4743	0.7	10	10.10	1.0
n66	1.745	1.7520	7.0	10	9.90	1.0

.

Although the proposed SDR-based spectrum analyzer provides a flexible and low-cost solution for signal visualization and educational measurements, several technical limitations must be considered when comparing its performance with professional commercial spectrum analyzers. One of the main limitations is related to the analog-to-digital converter (ADC) resolution. The HackRF One employs an 8-bit ADC, which constrains the achievable dynamic range. The theoretical dynamic range of an 8-bit converter is approximately 50 dB, significantly lower than that of commercial spectrum analyzers. This limited dynamic range reduces the ability to simultaneously observe weak signals in the presence of strong interferers and increases quantization noise. As a result, low-level signals close to the noise floor may be masked by stronger spectral components.

Receiver sensitivity is also limited compared to commercial spectrum analyzers. The HackRF One front-end lacks a calibrated low-noise preamplifier, and its gain stages are not optimized for precision measurements. The available gain controls (LNA, VGA, and baseband gain) provide flexibility but do not guarantee calibrated amplitude response. This results in a higher displayed noise floor and reduced capability to detect weak signals. During the comparison with the Deviser E8000A analyzer, this behavior was observed as improved weak-signal visibility in the commercial instrument.

Amplitude accuracy is another limitation of the HackRF-based implementation. Since the HackRF One is not factory-calibrated for power measurements, absolute amplitude values depend on gain configuration, antenna characteristics, cable losses, and front-end nonlinearities. Therefore, the proposed analyzer is primarily suitable for relative spectral analysis rather than absolute power measurements. In contrast, commercial spectrum analyzers provide calibrated amplitude measurements and specified measurement uncertainty.

3.4. Experimental Validation and Error Analysis

The experimental validation of the proposed SDR-based spectrum analyzer was performed using multiple real-world signals, including FM broadcasting, Wi-Fi transmissions, television signals, and OFDM-based cellular signals. These measurements allow evaluation of the system across different frequency bands, bandwidths, and modulation schemes. Frequency calibration was carried out using signals with known center frequencies. The measured center frequency $f_c^{meas}$ was obtained from the peak of the spectrum and compared with the reference value $f_c^{ref}$. The frequency deviation was computed as:

$$\mathrm{\Delta }{f}_c=|f_c^{ref}-f_c^{meas}|$$

(1)

Bandwidth estimation was performed by measuring the occupied bandwidth of the signal, and the corresponding error was calculated as:

$$\mathrm{BW}\mathrm{Error}(\%)={\displaystyle \frac{|B{W}_{ref}-B{W}_{meas}|}{B{W}_{ref}}}\times 100$$

(2)

Table 23 summarizes the quantitative results obtained across different frequency bands. The results show that frequency deviations remain within a small margin, mainly limited by FFT resolution and bin quantization effects. Bandwidth estimation errors were also found to be low, indicating consistent performance across different signal conditions.

The proposed system was also compared with a commercial spectrum analyzer (Deviser E8000A) under similar measurement conditions. The comparison shows good agreement in center frequency and bandwidth estimation for all evaluated signals. However, the commercial analyzer exhibited a lower noise floor and improved detection of weak signals.

These differences are attributed to the hardware limitations of the HackRF One, including its 8-bit ADC resolution, higher effective noise floor, and lack of preselection filtering and calibrated gain stages. These factors impact sensitivity and measurement precision, particularly for low-power signals. It is important to note that the validation focuses on frequency-domain accuracy; amplitude calibration and a complete uncertainty analysis are not included and are considered future work. Despite these limitations, the results demonstrate that the proposed system provides reliable spectral characterization across multiple wireless technologies.

3.5. Performance of the AI-Driven Voice Control System

The integration of the artificial intelligence module provided a seamless hands-free interface for controlling the spectrum analyzer’s hardware parameters, allowing users to configure key parameters (e.g., center frequency, gain, and bandwidth) without direct touchscreen interaction. This is particularly useful in scenarios where manual interaction is inconvenient or limited, such as field measurements, mobile deployments, or situations requiring continuous monitoring. Experimental results confirmed that the system accurately interprets natural-language commands and translates them into real-time adjustments within the signal-processing flowgraph. The voice recognition pipeline maintained high reliability during the testing phase, successfully executing complex configuration tasks without manual intervention. The following specific results were obtained during the functional validation of the AI assistant:

• Automated Standard Selection: The AI module demonstrated the ability to identify and apply parameters for common wireless standards. When prompted to display Wi-Fi Channel 10, the system automatically tuned the center frequency to $2.457$ GHz with a 20 MHz bandwidth. Similarly, a command for the full Bluetooth spectrum resulted in a configuration centered at $2.4425$ GHz with an 85 MHz span.
• Precision in Manual Tuning: Direct adjustment of RF parameters showed high responsiveness. Verbal commands to set the center frequency to 100 MHz and the RF gain to 25 dB were processed successfully, with the graphical user interface reflecting the changes instantaneously. This confirms the robustness of the Python-based interface layer in managing the hardware’s operational limits.
• Data Management and Connectivity: The voice-triggered capture system proved efficient for both local and remote monitoring. The “Local Capture” command successfully stored high-resolution screenshots in the internal storage directory with standardized timestamps. Furthermore, the “Online Capture” mode successfully interfaced with the Telegram Bot API, transmitting real-time spectral data to a remote chat, which validates the prototype’s utility for remote diagnostic applications.
• Audio and Feedback Systems: The text-to-speech (TTS) engine provided clear auditory confirmation for every successful parameter update. During FM radio tests, the system accurately tuned to specific channels, such as $88.3$ MHz with 200 kHz bandwidth, while simultaneously allowing the user to control the demodulation volume via voice commands.

A summary of the AI-driven voice assistant module’s operation is presented in the video available at [49]. Furthermore, for details on the prototype project, see the corresponding GitHub repository [50].

3.6. Limitations of the Proposed Prototype

While the proposed prototype demonstrates the feasibility of implementing a portable, low-cost, and practical SDR-based spectrum analyzer for sub-6 GHz monitoring, there are several technical constraints and limitations, which are described below:

• Dynamic Range and ADC Resolution: The SDR hardware used in the prototype, the HackRF One, uses an 8-bit ADC [51], which limits the maximum dynamic range and increases quantization noise compared to laboratory-grade spectrum analyzers (e.g., the Deviser E8000A [41]). This hardware condition reduces the ability to accurately detect weak signals in the presence of potential interferers.
• Receiver Sensitivity and Noise Floor: The prototype exhibits lower sensitivity than commercial instruments due to the lack of low-noise amplification stages or high-selective preselection filters. In practical deployments, this limitation can be mitigated by incorporating external band-selective filters and low-noise amplifiers.
• Amplitude Calibration and Accuracy: The proposed prototype lacks factory-calibrated absolute power measurements. Therefore, amplitude levels may be affected by antenna features, cable losses, front-end nonlinearities, and gain factors. For these reasons, our proposal is suited for preliminary spectral analysis rather than precision RF metrology applications.
• Resolution Bandwidth and Spectral Purity: In the proposed prototype, the achieved RBW, spurious-free dynamic range, and phase-noise characteristics are primarily determined by hardware limitations and software-defined processing rather than by calibrated, dedicated instrumentation-grade analog architectures. Therefore, although the prototype enables flexible real-time visualization, it cannot replace high-end analyzers in rigorous laboratory testing scenarios.
• Computational Scalability: The capabilities of the Raspberry Pi 4B+ platform constrain the use of larger FFT sizes, broader bandwidths, and advanced real-time AI processing. Future scalability for more demanding applications may require higher computational capacity (e.g., using edge-computing platforms).
• Battery Autonomy and Field Deployment: The battery module supports autonomous and portable operation; however, its operational lifetime depends on factors such as CPU load, software-defined radio (SDR) activity, screen brightness, and speaker usage. This limitation may constrain outdoor campaigns or long-term monitoring unless larger battery units are implemented, which would necessitate new mechanical hardware. Additionally, the current mechanical design lacks waterproofing, dust protection (e.g., IP68 certification), and fall protection.
• Frequency-range Limitations: The proposed SDR-based implementation cannot directly analyze millimeter-wave bands relevant to 5G Frequency Range 2 (FR2) and prospective 6G systems without integrating additional up- or down-conversion hardware or specialized millimeter-wave front-ends.
• Scope of the AI Module: The AI component is primarily designed for voice-based human–machine interaction and hands-free parameter configuration. However, it currently lacks capabilities for automatic spectrum interpretation, anomaly detection, and signal or modulation classification and recognition. These functionalities represent potential avenues for future research.
• Dependence on Cloud Services: The current voice assistant implementation relies on external APIs. While this approach improves usability, it also relies on third-party services and Internet connectivity, which can introduce communication latency. Developing a fully local, proprietary, and custom AI solution could provide greater operational autonomy and enhanced privacy.

Although these limitations exist, they are consistent with the prototype’s low-cost design philosophy and do not reduce its effectiveness as an accessible platform for research experimentation, rapid diagnostics, field surveys, practical sub-6 GHz spectrum analysis, and educational purposes.

4. Conclusions

This paper presents the detailed implementation of a spectrum analyzer prototype that uses the HackRF One platform, the Raspberry Pi 4B+, a portable battery, and a touch screen for an interactive user interface. The Raspberry Pi runs GNU Radio, which allows real-time signal processing and visualization. This spectrum analyzer prototype is portable, enabling the analysis and visualization of electromagnetic signals from 1 MHz to 6 GHz, with potential applicability to 5G and forthcoming 6G networks. Furthermore, the proposed prototype features an intuitive graphical interface and an AI-driven voice assistant that enable easy access to key functions, including frequency selection, bandwidth adjustment, real-time visualization, and hands-free operation if needed.

The development of the spectrum analyzer prototype has required a total investment of USD 246, underscoring its economic viability relative to commercial spectrum analyzers and making the prototype on display almost 11 times less expensive than laboratory equipment. This comparison highlights the effectiveness of using open-source tools and affordable hardware to create radio spectrum analysis solutions that can compete with high-cost commercial equipment in terms of basic functionality.

The spectrum analyzer prototype has proven effective for analyzing a wide range of telecommunications signals, including FM radio, television, 3G networks, and Wi-Fi. Owing to its wide operating frequency range, spanning 1 MHz to 6 GHz, the prototype enables monitoring and evaluation of most telecommunications services across the radio spectrum, including 5G and 6G networks. This ability to cover multiple frequency bands not only underscores the device’s versatility and utility but also highlights its potential for applications across contexts, from research and education to implementation in specific telecommunications network monitoring and diagnostic projects.

The prototype is equipped with a 10,000 mAh battery, enabling approximately 2 h of autonomous operation, powering the touchscreen, the HackRF One module, and the RPi. This stand-alone operation capability makes it an ideal tool for field use, allowing users to perform radio spectrum analysis in various environments without an external power source, making it highly portable and operationally autonomous. Furthermore, thanks to the AI-driven voice assistant, the proposed prototype can be used by people with disabilities and by those with a basic or no background in operating such devices.

Integrating an AI-driven voice assistant is particularly useful when manual interaction is limited or impractical. While this paper demonstrates the feasibility of natural-language control for real-time spectrum analysis, a more comprehensive evaluation of accessibility and usability is still needed. Future work might include a formal, user-centered study to assess the effectiveness of the voice interface across multiple scenarios and conditions, including user factors (e.g., varying levels of technical expertise or different accessibility limitations), as a contribution to achieving more inclusive SDR-based communication systems.

Several research directions can be pursued to enhance the proposed prototype further. The next hardware steps are to adopt higher-resolution SDR platforms, integrate 12–16-bit ADCs, incorporate calibrated RF front-ends, and include low-noise amplification stages. These improvements should enhance dynamic range, sensitivity, and fidelity, thereby narrowing the gap to professional-grade spectrum analyzers. For signal processing, future work can integrate advanced artificial intelligence techniques such as reinforcement learning to enable signal classification, adaptive spectrum sensing, and interference analysis. Further steps may include federated learning, which enables multiple devices to collaboratively learn spectrum patterns in a distributed manner, thereby enhancing scalability while maintaining data privacy. Another research direction is to integrate this device into unmanned aerial vehicles to enable mobile interference analysis of gNodeB and beamforming. This integration is under current investigation by the authors as part of ongoing work.