Overview

This week I focused on learning the CorteXlab workflow for running GNU Radio applications on remote USRP nodes. Along the way, I encountered and resolved several execution issues related to task packaging, container environments, and GNU Radio configuration. I also designed an initial concept for a task monitoring system that can track experiment status and collect success/failure information across multiple nodes.

1. Creating and Running a GNU Radio Flowgraph

I created a GNU Radio flowgraph using GNU Radio Companion (GRC) based on the tutorial provided by my mentor.

After generating the Python file, I packaged it into a MINUS task and submitted it to a USRP-equipped node on CorteXlab.

This helped me understand:

• GNU Radio Companion (GRC)
• Generated Python flowgraphs
• MINUS task creation and submission
• Running experiments on remote nodes

2. Debugging Task Execution

File Location Issue

My first attempt failed because the container could not find the Python file.

Error:

python3: can't open file '/root/test_recieve.py'

To investigate, I used a temporary command inside the container to locate the file.

The actual path was:

/cortexlab/homes/sayantan_maity/test_reciever/test_recieve.py

This confirmed that the task package was transferred correctly and helped identify the correct execution path.

GNU Radio Import Failure

After fixing the file path issue, the next error was:

ModuleNotFoundError: No module named 'gnuradio'

Initially, I suspected a problem with the Docker image, but further testing showed that GNU Radio was installed correctly.

The issue was that the GNU Radio environment was not initialized when Python was executed directly.

This failed:

python3 test_recieve.py

This worked:

bash -lc "python3 test_recieve.py"

The solution was to launch Python through bash -lc, which correctly loads the GNU Radio environment inside the container.

Successful USRP Initialization

Once the environment issue was resolved, the flowgraph successfully started and connected to the USRP.

The logs showed:

• UHD initialization
• USRP device detection
• Successful communication with the radio hardware

This confirmed that:

• The Docker image was correct
• GNU Radio was installed properly
• UHD was functioning correctly
• The node could access the USRP

Flowgraph Waiting for User Input

The next issue appeared after startup.

The flowgraph printed:

Press Enter to quit:

The generated Python file had been created with the Prompt for Exit option in GRC.

Since tasks run non-interactively inside containers, the program waited indefinitely for keyboard input.

My mentor suggested using:

Run to Completion

instead of:

Prompt for Exit

when generating the Python flowgraph.

This removes the interactive prompt and allows automated execution.

3. Container Debugging Techniques Learned

During the debugging process, I learned several useful techniques:

• Reading task logs (stdout and stderr)
• Inspecting result directories
• Locating files inside containers
• Understanding container execution environments
• Diagnosing GNU Radio startup issues

These techniques significantly improved my understanding of remote experiment execution.

4. Proposed Task Monitoring System

Motivation

As the number of experiments grows, manually checking each task becomes inefficient.

I wanted a way to answer:

• Which tasks are currently running?
• Which nodes are being used?
• Which tasks passed?
• Which tasks failed?
• Why did a task fail?

Proposed Solution: JSON-Based Task Registry

I propose maintaining a centralized JSON registry on the controlling machine.

When a task is submitted, it is automatically added to the registry.

Example:

{
  "24360": {
    "status": "RUNNING",
    "nodes": {
      "node17": {},
      "node03": {}
    }
  }
}

Monitoring Process

A Python monitoring service periodically checks task status using:

minus task info <task_id>

and updates the registry.

Possible task states:

• WAITING
• RUNNING
• FINISHED
• ABORTED

Multi-Node Task Support

For tasks running on multiple nodes, each node is monitored independently.

Example:

{
  "24360": {
    "nodes": {
      "node17": {
        "status": "PASS"
      },
      "node03": {
        "status": "FAIL",
        "reason": "ModuleNotFoundError: No module named 'gnuradio'"
      }
    },
    "overall_status": "FAIL"
  }
}

This makes it easy to identify exactly which node failed.

Failure Reason Collection

When a task completes, the monitoring service inspects:

• stdout
• stderr

and extracts useful failure information such as:

ModuleNotFoundError
RuntimeError
FileNotFoundError
UHD initialization errors

The extracted error message is stored in the registry.

Example:

{
  "node03": {
    "status": "FAIL",
    "reason": "ModuleNotFoundError: No module named 'gnuradio'"
  }
}

Example Dashboard View

Task 24359
└── node24 : PASS

Task 24360
├── node17 : PASS
└── node03 : FAIL
    Reason: ModuleNotFoundError: No module named 'gnuradio'

Task 24361
├── node08 : RUNNING
└── node12 : RUNNING

Future Extensions

Because the registry is stored as JSON, it can later be integrated with:

• CI/CD pipelines
• Web dashboards
• Databases
• Experiment management tools

without significant redesign.

Conclusion

This week I successfully learned how to deploy and debug GNU Radio experiments on CorteXlab. I resolved issues related to file paths, container environments, GNU Radio initialization, and flowgraph execution.

Additionally, I designed a JSON-based task monitoring architecture capable of tracking task states, node-level success/failure information, and failure reasons. This provides a foundation for future automation and experiment monitoring capabilities.

This week, I improved the initial HIL orchestration prototype by making the OAR reservation process more user-friendly and flexible.

The script now supports three reservation modes:

• Best Allocation
• Preferred Nodes
• Future Reservation

Users can configure walltime and reservation parameters interactively, while the script automatically generates the appropriate OAR command.

To simplify node selection, users only need to enter node numbers (e.g., 31,36), and the script converts them into the corresponding CortexLab hostnames automatically.

I also added an interactive TX/RX assignment step. After nodes are allocated, the script displays the available nodes and allows users to choose which node should act as the transmitter (TX) and which should act as the receiver (RX). This provides more flexibility when preparing HIL experiments involving multiple nodes.

LINK: https://github.com/Sayantan-Maity-hub/gnuradio-hardware-in-loop/blob/main/cortexlab/orchestration.py

In my HIL/GNU Radio workflow, I created a small Python automation script to submit an OAR job, extract the job ID, and retrieve allocated compute nodes automatically.

The main purpose of this script is:

Extract the Job ID for getting detailed information about the submitted OAR job Extract allocated hostnames/nodes for future automatic scenario YAML generation Dynamically assign TX and RX nodes for SDR experiments

Link: https://github.com/Sayantan-Maity-hub/gnuradio-hardware-in-loop

Hi! I am Sayantan Maity, a B.S. Electronics Systems student at IIT Madras.

This summer, I will be working on the GNU Radio GSoC project:

Hardware-in-the-Loop CI Using CortexLab

The goal of the project is to extend GNU Radio’s software-only CI system with automated SDR hardware validation using the CortexLab wireless experimentation platform.

During the community bonding period, I am:

• studying existing GNU Radio CI workflows,
• understanding CortexLab infrastructure,
• refining experiment architecture,
• and preparing the implementation roadmap with mentors.

I’m excited to work with the GNU Radio community this summer!