Project Logs

Collapse

• The Manual and Example code are now available!

  Jayoung Oh • 10/20/2026 at 03:01 • 0 comments

  Manual: https://github.com/jyoh92/Integrive-100-MIMO-SDR

  Example code: https://github.com/jyoh92/examples

  Two SDR Operating Modes of Integrive-100: Host-Based and Standalone

  Integrive-100 supports two operating modes. In Host-based SDR Mode, digital I/Q samples are streamed to and from a host PC for software-based PHY processing. In Standalone SDR Mode, the real-time PHY processing chain runs directly on the FPGA, enabling independent wireless system operation without a host PC.

  Left:

  • Digital I/Q samples are streamed between Integrive-100 and a host PC.
  • PHY functions, including synchronization, channel estimation, modulation/demodulation, and FEC, are executed on the host PC using C/C++, Python, MATLAB or other software tools.
  • Ideal for algorithm development, verification, signal analysis and experimentation.

  Right:

  • Enables easy development and evaluation of PHY algorithms in real RF.
  • Enables product-level validation of PHY, MAC and networking protocols under real-world wireless conditions.
  • Accelerates the transition from validated wireless prototypes to product development.

• Characterizing SDR RF Performance: EVM, 256-QAM, and Image Rejection

  Jayoung Oh • 10/13/2026 at 23:56 • 0 comments

  My previous logs were about how Integrive-100 can be used to move PHY experiments from simulation to real RF. But this time, I’d like to turn our attention to the hardware. How much impairment is being introduced by the radio hardware itself?

  Real RF hardware introduces phase noise, I/Q imbalance, nonlinear distortion, and other imperfections that are absent or simplified in simulation. As modulation order increases, these effects become more important. If the RF chain introduces too much distortion, it can become difficult to tell whether a performance limitation comes from the algorithm being tested or from the hardware carrying the signal.

  So we characterized the RF performance of the platform, focusing on EVM, 256-QAM operation, and image rejection.

  EVM and 256-QAM Performance

  High-order modulation is a good place to start because it is particularly sensitive to RF impairments.

  In loopback measurements, the radio achieved a combined TX/RX EVM of −35 dB or better, providing approximately 3 dB of margin relative to the −32 dB reference level used for 256-QAM.

  But we also wanted to see what this looked like in an operating PHY rather than relying on the loopback EVM measurement alone.

  For this test, we implemented SIP-DDM, our PHY technology for highly reliable wireless communication, together with Reed–Solomon coding and no retransmission.

  The figure below shows the measured EVM and packet error rate (PER) as SNR changes.

  As SNR increases, EVM decreases while PER drops rapidly. At approximately 36 dB SNR, the measured EVM reaches about 1.55%, while PER falls to around 2 × 10⁻⁵.

  For us, the important part of this test was seeing the RF hardware and PHY processing working together in an actual packet-based 256-QAM link.

  I/Q Imbalance and Image Rejection

  Another RF impairment we looked at was I/Q imbalance, which can generate unwanted image components that degrade signal quality, particularly in direct-conversion RF systems. Integrive-100 uses digital I/Q calibration to suppress these image components.

  As shown in Figure 2, the measured image rejection ratio (IRR) reaches up to 75 dB, providing a reliable RF foundation for PHY algorithm evaluation.

• Taking Wireless Research Beyond Simulation

  Jayoung Oh • 09/24/2026 at 20:21 • 0 comments

  I’d like to explore how the architecture I discussed in the previous post helps us build wireless applications and validate them in real RF environments.

  From Simulation to a Real Wireless System

  Simulation is where many wireless ideas begin. A new PHY algorithm, MAC protocol, routing scheme, or sensing technique can be developed and evaluated under controlled conditions.

  But eventually, we want to answer a different question:

  What happens when we put it into a real wireless system?

  Real RF brings in factors that are difficult to capture completely in simulation, such as RF impairments, synchronization behavior, interference, multipath, changing channels, processing delays, mobility, and interactions among multiple nodes.

  These are some of the reasons why an algorithm that works well in simulation may behave differently when it becomes part of a real wireless system.

  We wanted to make it easier to validate a technology as part of a real wireless system before moving toward dedicated product hardware.

  A Simple Example: An Industrial Wireless MAC

  Consider a new MAC protocol designed for an industrial wireless network. Simulation might show how the protocol performs in terms of latency, reliability, or scheduling. But the intended application may involve multiple wireless nodes operating around metal structures and moving equipment, with interference and constantly changing radio channels.

  With multiple Integrive-100 nodes, the protocol can be implemented as part of a working wireless system and evaluated under realistic traffic, interference, mobility, and RF conditions. If the complete application performs as intended, the results go beyond a successful simulation. They show that the core technology can operate as part of a real system.

  The process looks something like this:

  Simulation → Real-Hardware Implementation → Product-Relevant Validation → Application Validation → Product Engineering

  Beyond a Single Algorithm

  The same approach can apply to PHY algorithms, multi-hop routing protocols, ISAC systems, or AI-enabled wireless applications.

  At the PHY level, a researcher can change the function they want to investigate while using the existing PHY for the surrounding communication chain. With multiple units, the same platform can become an experimental wireless network for testing MAC, routing, coordination, or other multi-node algorithms over real RF.

  Taking It Into the Real Environment

  * Example: Industrial ISAC

  Multiple Integrive-100 units could be configured as 1 Coordinator + N Wireless Nodes. Researchers could then implement their own communication and sensing algorithms and evaluate them in an industrial environment where multipath, metal structures, obstacles, interference, and moving objects become part of the experiment.

  * Example: AI-Connected Wireless Systems

  Integrive-100 can also be connected to an external AI platform, such as NVIDIA Jetson Orin. The AI processor handles inference for sensing, vision, or robotics, while Integrive-100 provides the wireless communication link, allowing researchers to evaluate AI-enabled systems under real communication constraints. 

  From Validation to Product

  Once the core technology and application have been validated in a real wireless environment, product development can begin with much of the technical uncertainty already addressed. 

  This is something we are doing ourselves. We have integrated our own wireless algorithms into Integrive-100 and are testing them in outdoor drone flight tests.
  

• Rethinking the PHY Research Workflow

  Jayoung Oh • 09/20/2026 at 02:51 • 0 comments

  From PHY Algorithms to Real RF Validation

  One of the design goals was to make it easier to test an individual PHY algorithm without rebuilding the entire communication chain around it.

  A complete wireless PHY includes synchronization, channel estimation, equalization, modulation and demodulation, FEC, framing, OFDM processing, and RF configuration. In research, however, the focus is often on only one or two of these functions.

  When testing a new channel-estimation algorithm, moving it from simulation to RF hardware still requires the surrounding receive chain to be available: synchronization, FFT processing, equalization, demodulation, framing, and data movement.

  We got tired of having to deal with all of that just to test one algorithm. What we wanted was a workflow where the function under development could run in software on the ARM-based Processing System (PS), while the existing FPGA implementation handled the surrounding PHY processing in the Programmable Logic (PL).

  This allows the algorithm to be evaluated within an operating PHY rather than only against simulated or previously captured data.

  The distinction we wanted to make here is between testing an algorithm by itself and testing it as part of an operating wireless link.

  With the complete Tx/Rx chain running, the algorithm can be evaluated at the symbol level using actual transmitted and received RF signals. This makes it possible to observe behavior under practical hardware effects that may not be fully represented in simulation.

  The same approach can be applied to other areas of PHY research, including synchronization, FEC, modulation/demodulation, OFDM processing, and framing. For synchronization in particular, real RF testing involves effects such as timing error, carrier-frequency offset, phase noise, and other RF impairments. For OFDM and waveform development, parameters such as FFT size, cyclic prefix, modulation, and framing can be explored before moving toward a real-time implementation.

  You can select the function you want to investigate and implement or evaluate a new algorithm on the embedded ARM processor, while the remaining PHY functions continue to operate in FPGA logic. In this way, the algorithm is not tested in isolation, but as part of a working PHY over real RF hardware.

  This workflow came from a frustration we kept running into in our own PHY research. I'm curious whether you've had the same experience, and how much a workflow like this could actually make a difference in your research.
  

View all 4 project logs