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
flowgraph.pdf
Description: Adobe PDF document
Re: "L" error for using file_sink blocks.
On Thu, Dec 12, 2024 at 6:53 PM Yan, Bixing (UT-EEMCS) 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
[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
