Notes from our journey building a real-world SDR platform.

Why We Built Integrive-100: From SDR Experiments to Real Wireless Prototypes

Software-defined radio has fundamentally changed the way wireless systems are researched and developed. With an SDR platform, engineers can generate and receive RF signals, experiment with new waveforms, evaluate modulation schemes, and validate communication algorithms without building custom radio hardware from scratch.

We followed the same path.

We have used commercially available SDR platforms extensively for wireless communication research and algorithm development. They are excellent tools for learning, experimentation, and rapid proof-of-concept development.

But as our work progressed from signal experiments toward complete wireless communication systems, our requirements began to change.

We needed more than an SDR for observing and processing signals.

We needed a platform on which we could actually build a wireless communication prototype.

Figure 1. Integrive-100, the SDR development platform we built during this project.

The Gap Between an SDR Experiment and a Wireless System

A laboratory SDR experiment and a practical wireless communication system may use many of the same signal-processing algorithms, but they are not quite the same engineering problem.

In simulation environments such as MATLAB or Python, researchers can focus primarily on the algorithm itself. Many real-world effects can be simplified, modeled separately, or temporarily excluded.

Once an algorithm moves onto real RF hardware, however, phase noise, carrier frequency offset, I/Q imbalance, fixed-point effects, timing, interfaces, and hardware constraints all become part of the system.

Sometimes the challenge is not the algorithm itself. It is everything around it.

A new synchronization, channel-estimation, or equalization algorithm, for example, may assume a particular frame structure, pilot configuration, or position in the processing chain. If the development platform does not provide sufficient control over those elements, engineers may end up spending more time adapting their algorithms to the platform than evaluating the ideas themselves.

We wanted to reduce that friction.

A real communication prototype requires the entire signal chain to operate together, including RF processing, digital signal processing, synchronization, OFDM, modulation and demodulation, FEC, framing, packet processing, and communication protocols.

But we kept coming back to this question:

Why should we have to redesign the entire PHY just to test a new algorithm?

This frustration became one of the key ideas behind Integrive-100.

How We Structured the PHY

We wanted the PHY processing chain to be accessible enough that developers could focus on the particular function they wanted to investigate without having to build an entire communication system from scratch.

Integrive-100 provides an FPGA-based PHY implementation in the Programmable Logic (PL), together with an ARM-based Processing System (PS) running Linux. During algorithm development, a selected PHY function can be implemented in software on the PS, while the remaining PHY functions continue to execute in the PL.

This creates a practical development model:

Develop the PHY function you want to investigate in the PS. Let the existing PL implementation handle the rest of the communication chain.

What makes this particularly useful is that the algorithm can be evaluated as part of an operating PHY chain rather than only against previously captured data. PHY processing can be handled at the symbol level, allowing developers to observe and evaluate how their algorithms behave while the communication system is running under real RF conditions.

For example, a researcher developing a new equalization algorithm can implement the function in software on the PS while synchronization, OFDM processing, demodulation, and other surrounding PHY functions...