Re: Beginner Tutorial 3. Your First Flowgraph

The entry depends on the terminal emulator on your system
On my system the entry is

xterm_executable=/usr/bin/xterm


Am 16.12.24 um 04:45 schrieb DENISE WICKERT:
> I got the flowgraph set up exactly as in the tutorial. Hit play and get this popup message:
>
> The xterm executable " is missing.
>
> You can change this setting in your gnurado.cnf, in section
> [grc], 'xterm executable'.
>
> This is the contents of gnuradio.cnf grc.conf
>
> ***************************************
> # This file contains system wide configuration data for GNU Radio.
> # You may override any setting on a per-user basis by editing
> # ~/.gnuradio/config.conf
>
> [grc]
> global_blocks_path = /usr/share/gnuradio/grc/blocks:/usr/local/share/gnuradio/grc/blocks
> local_blocks_path =
> default_flow_graph =
> xterm_executable =
> canvas_font_size = 8
> canvas_default_size = 1280, 1024
> **************************************
>
>
> What to I change? Is it supposed to be:
>
> xterm_executable = "
>
> or what?
>
> I am very paranoid modifying system or program files having been burned many time in the past. I am using Ubuntu 20.04.6 LTS if that matters.
>
> Thanks for any help, Larry Wickert
>
> Screenshot png attached.
>

Open Position at AnySignal: Space RF Electronics Engineer

Greetings All,

I wanted to highlight one of the many exciting open positions at AnySignal: Space RF Electronics Engineer. In this role, you'll design, bring up, and drive the mass manufacturing of frontends for our integrated software radio products, including:

• High-power amplifiers ranging from 2 to 100W, covering bands from VHF up to Ka-band (30 GHz), and beyond.
• Low Noise Amplifiers (LNAs).
• Up/Down-converters of various topologies.
• Filters, power detectors, and other key components.

Some highlights that make this opportunity particularly exciting:

• At least one of our radios is flying to the surface of the Moon next year, with several additional missions to LEO and MEO.
• In the first year or two, you can expect to work harder than you ever have—alongside an amazing team "in the trenches."
• Over time, through process improvements and technical leverage, you'll help field innovations at a rate unseen in the industry.

For more details, check out the job posting here, or feel free to message me directly.

Best regards,
John Malsbury
CEO | AnySignal

Chrip

Greetings everyone! I wonder if any body was able to make common chirp signal to use with SDR like HACKRF? For now I was able to make wav file with samples but I do not understand how to visualize my signal correct spectre with qt freq sink. Hope somebody could give an advice.
Alex

Beginner Tutorial 3. Your First Flowgraph

I got the flowgraph set up exactly as in the tutorial. Hit play and get this popup message:

The xterm executable " is missing.

You can change this setting in your gnurado.cnf, in section
[grc], 'xterm executable'.

This is the contents of gnuradio.cnf grc.conf

***************************************
# This file contains system wide configuration data for GNU Radio.
# You may override any setting on a per-user basis by editing
# ~/.gnuradio/config.conf

[grc]
global_blocks_path = /usr/share/gnuradio/grc/blocks:/usr/local/share/gnuradio/grc/blocks
local_blocks_path =
default_flow_graph =
xterm_executable =
canvas_font_size = 8
canvas_default_size = 1280, 1024
**************************************


What to I change? Is it supposed to be:

xterm_executable = "

or what?

I am very paranoid modifying system or program files having been burned many time in the past. I am using Ubuntu 20.04.6 LTS if that matters.

Thanks for any help, Larry Wickert

Screenshot png attached.

[no immediate action required] Package maintainers: please check your dependencies!

Dear downstream package maintainers,

I just checked the homebrew GNU Radio packaging, and found the (as of v3.10.11.0) no
longer used dependency of python click-plugins in there. That's no big deal (probably),
but it's not the only dependency we've worked on in the last couple years.

So, please feel invited to check whether what GNU Radio depends on is actually not less
than what your package depends on. Especially, we removed:

- Qt4
- libcomedi
- a lot of Boost components we used to depend on (currently I think we're still using
date_time, program_options, system, thread, not sure that's exhaustive; anyways,
everybody's boost packaging is different)
- log4cpp

we added (not exhaustive list) for some optional features

- libsndfile
- libsoapysdr
- (if you want blocktool) pygccxml
- (if you want blocktool and the config blocks) python-jsonschema

If you want to have an overview of the libraries for which we give minimum versions,
cmake/Modules/GrMinReq.cmake is our centralized place where we keep these around.

If in doubt, raise hell :)

Cheers,
Marcus

Phase Difference calculation

Dear GNU Radio Community,

I want to extract the consistent and stable phase difference in degrees between the two signals, each of 30 Hz, from a demodulated signal from a VOR Signal RX through USRP N210. I am applying a Python block for this purpose and checking the Phase difference in degrees by giving its output to QT GUI Number sink, but I am not getting desired results, the values are continuously fluctuating, instead of the time domain, I am getting the accurate and stable two 30 Hz waves. 

Code using:

import numpy as np
from gnuradio import gr

class blk(gr.sync_block):  
    def __init__(self):  
        gr.sync_block.__init__(
            self,
            name="Phase Difference via IQ Demodulation",
            in_sig=[np.complex64, np.complex64],  # Two complex input signals
            out_sig=[np.float32]                  # Phase difference in degrees
        )

    def work(self, input_items, output_items):
        # Input complex signals
        signal1 = input_items[0]
        signal2 = input_items[1]
        # Ensure both signals have the same length
        if len(signal1) != len(signal2):
            raise ValueError("Input signals must have the same length.")
        # Demodulate signal1 to get I1 and Q1
        I1 = np.real(signal1)  # In-phase component of signal1
        Q1 = np.imag(signal1)  # Quadrature component of signal1
        # Demodulate signal2 to get I2 and Q2
        I2 = np.real(signal2)  # In-phase component of signal2
        Q2 = np.imag(signal2)  # Quadrature component of signal2
        # Calculate the phase for each signal
        phase1 = np.arctan2(Q1, I1)  # Phase of signal1 in radians
        phase2 = np.arctan2(Q2, I2)  # Phase of signal2 in radians
        # Compute the phase difference
        phase_diff_rad = phase1 - phase2
        # Normalize phase difference to the range [-π, π]
        phase_diff_rad = np.mod(phase_diff_rad + np.pi, 2 * np.pi) - np.pi
        # Convert phase difference to degrees
        phase_diff_deg = np.degrees(phase_diff_rad)
        # Output the phase difference
        output_items[0][:] = phase_diff_deg
        return len(output_items[0])

It could be possible to get stable/accurate values using IQ Demodulation technique or any other robust method? Kindly help, where I'm making mistakes.

Best regards

Muhammad Anas

Re: "L" error for using file_sink blocks.

On Thu, Dec 12, 2024 at 6:53 PM Yan, Bixing (UT-EEMCS) <b.yan@utwente.nl> wrote:

Hi,

I am using USRP X440 to build a wireless communication prototype. The host PC is equipped with i9-14900K and I am trying to use two transmit channels and two receive channels of the USRP simultaneously. I feed two generated signal to two channels by the USRP_sink block, and then I download the received data  from the USRP_source  by file_sink blocks. The sample rate I use is 150 MHz for each channel. 

However, I noticed that there are many "L" occurs when I run it. Even if I reduce the sample rate to 30 MHz, I can still see the problem. But if I use qt_gui_frequency_sink to visualize the received signal, it can hold up to 150 MHz without any errors.

I would like to ask the reason for this. What cause the "L" errors? Is it about my ssd's writing speed is not high enough?

The "L"s are coming from the transmit side of things. if you feed a single Tx channel, does the issue persist?

--M