Re: [Discuss-gnuradio] USRP noise at higher frequencies
Hi, I posted about this before (High frequency OFDM), but could not get a reply. I tried my best, but am completely stuck by now and would accept any wild guesses. I have two USRPs (TVRX and WBX-TX) connected via cable that transmit a OFDM signal (courtesy of gnuradio-examples/python/ofdm, default parameters) in between them. I have manually taken care that the carrier frequency is centered correctly on the receiver and that the amplitudes at both the transmitter and receiver are configured optimally. Now when I transmit said OFDM signal at around 100MHz, everything is looking perfectly fine. If I look at the transmitted and received signal, I see a perfectly sharp edged OFDM block in the spectrum and get 100% of the data from one USRP to the other. Nice. When I switch that same configuration into higher areas of the spectrum (400MHz+), again adjusting carrier-frequency and amplitudes, I also see the same sharp edged blocks. The SNR is a little worse, but still well beyond 30dB. This is where my problem lies. For some reason, most of the packets are broken or bursts are missing completely. If I switch to wider subcarrier distance, the transmission works again - but that isn't what I am looking for. 1) What happens at higher frequencies that invisibly destroys the OFDM block? Phase noise? Impulsive noise? Something to do with the sampling rate conversion? Any tips or pointers would be of great help. 2) How could I model a high frequency transmission (including phase noise) in GNU Radio, so that I can more easily see the problem? This is due to frequency offset. Oscillator error is in parts per million (roughly 5 to 10 ppm for a USRP1). The higher the carrier frequency, the higher the absolute error. At 100 MHz, 10 ppm error is 1 kHz. At 400 MHz, 10 ppm error is 4 kHz. The code you are using only works at a limited frequency error. The allowable frequency error is proportional to the tone spacing. So when you go to higher tone spacing it is more tolerant of the higher frequency error, and that is why it works. What you need to do is modify the code to search for the signal over a wider frequency band. I thought I took care of this by manually centering the spectrum (I do this at every frequency). I do this: 1.Launch the OFDM transmitter at 400MHz 2.Launch a receiver at 400MHz with a GNU Radio fft-sink and write down the constant offset (say 400.021MHz) 3.Launch the OFDM receiver at 400.021MHz So the OFDM signal is centered perfectly, but still I only receive broken packets. Or do you mean something else? Is the narrow band OFDM signal maybe distorted in some fashion and at 400MHz can not be properly recovered anymore? Or use the wider tone spacing. That is a perfectly valid solution that works 100%, but actually I am just wondering why the narrow band transmission that works fine at 100MHz does not work anymore at 400MHz. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] writin oscope on python
Hi everyone,
I want to see a simple cosine signal on oscope by writing a pyhton code.
I am using scopesink2.scope_sink_c tool. The code is below:
and I got this error message:
[r...@mehmet Desktop]# python mehmet_rx.py
Traceback (most recent call last):
File mehmet_rx.py, line 99, in module
my_top_block().run()
File mehmet_rx.py, line 87, in __init__
num_inputs=0,
File /usr/lib/python2.6/site-packages/gnuradio/wxgui/scopesink_gl.py,
line 144, in __init__
msg_key=MSG_KEY,
File /usr/lib/python2.6/site-packages/gnuradio/wxgui/scope_window.py,
line 430, in __init__
wx.Panel.__init__(self, parent, style=wx.SIMPLE_BORDER)
File /usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_windows.py,
line 68, in __init__
_windows_.Panel_swiginit(self,_windows_.new_Panel(*args, **kwargs))
TypeError: in method 'new_Panel', expected argument 1 of type 'wxWindow *'
The python code:
from gnuradio import gr, usrp
from gnuradio.wxgui import stdgui2, scopesink2, fftsink2, form
import wx
class my_top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
sample_rate = 32
ampl = 1000
decimation = 200
frequency = 17
gain = 1000
#create the usrp source
#0 represents the USRP number (in case you have multiple USRPs)
u = usrp.source_c(0)
#Set the decimation
u.set_decim_rate(decimation)
#Automatically choose the sub device
#(this can be done manually, see below)
subdev_spec = usrp.pick_rx_subdevice(u)
#Set the mux
u.set_mux(usrp.determine_rx_mux_value(u, subdev_spec))
#get the sub-device
subdev = usrp.selected_subdev(u, subdev_spec)
#Select receive antenna ('TX/RX' or 'RX2'): flex boards only!
subdev.select_rx_antenna('TX/RX')
#Set the gain
subdev.set_gain(gain)
#Tune the center frequency
u.tune(0, subdev, frequency)
self.wxgui_scopesink2_0 = scopesink2.scope_sink_c(
self,
title=Scope Plot,
sample_rate=32,
v_scale=0,
t_scale=0,
ac_couple=False,
xy_mode=False,
num_inputs=1,
)
self.connect((u, 0), (self.wxgui_scopesink2_0, 0))
if __name__ == '__main__':
try:
my_top_block().run()
except KeyboardInterrupt:
pass
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] May I use GUN Radio without USRP
Hello, I want to know may I use GNU radio without USRP. I mean Since USRP is just used for transiver, ADC/DAC, converting RF signal to baseband and transmitting baseband signal to GNU Radio for processing, then may I produce baseband workload by an Agilent baseband signal generator or even Matlab, and then connect GNU Radio with signal generator or Matlab? The reason I am thinking about this is that from some analysis, I find the data rate of the USB2.0 bus limits the bandwidth of the base band signal to 8 MHz, which is not enough for my project. And My focus is just baseband signal processing, I want to save money on USRP if I can use existing equipments in the lab. Thanks Hanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] writin oscope on python
I recommend making this application with the gnuradio companion and then
you can inspect/modify/learn-from the generated python code.
http://gnuradio.org/redmine/wiki/gnuradio/GNURadioCompanion
-Josh
see below
|
|
v
On 07/11/2010 05:33 AM, mehmet kabasakal wrote:
Hi everyone,
I want to see a simple cosine signal on oscope by writing a pyhton code.
I am using scopesink2.scope_sink_c tool. The code is below:
and I got this error message:
[r...@mehmet Desktop]# python mehmet_rx.py
Traceback (most recent call last):
File mehmet_rx.py, line 99, inmodule
my_top_block().run()
File mehmet_rx.py, line 87, in __init__
num_inputs=0,
File /usr/lib/python2.6/site-packages/gnuradio/wxgui/scopesink_gl.py,
line 144, in __init__
msg_key=MSG_KEY,
File /usr/lib/python2.6/site-packages/gnuradio/wxgui/scope_window.py,
line 430, in __init__
wx.Panel.__init__(self, parent, style=wx.SIMPLE_BORDER)
File /usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_windows.py,
line 68, in __init__
_windows_.Panel_swiginit(self,_windows_.new_Panel(*args, **kwargs))
TypeError: in method 'new_Panel', expected argument 1 of type 'wxWindow *'
The python code:
from gnuradio import gr, usrp
from gnuradio.wxgui import stdgui2, scopesink2, fftsink2, form
import wx
class my_top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
sample_rate = 32
ampl = 1000
decimation = 200
frequency = 17
gain = 1000
#create the usrp source
#0 represents the USRP number (in case you have multiple USRPs)
u = usrp.source_c(0)
#Set the decimation
u.set_decim_rate(decimation)
#Automatically choose the sub device
#(this can be done manually, see below)
subdev_spec = usrp.pick_rx_subdevice(u)
#Set the mux
u.set_mux(usrp.determine_rx_mux_value(u, subdev_spec))
#get the sub-device
subdev = usrp.selected_subdev(u, subdev_spec)
#Select receive antenna ('TX/RX' or 'RX2'): flex boards only!
subdev.select_rx_antenna('TX/RX')
#Set the gain
subdev.set_gain(gain)
#Tune the center frequency
u.tune(0, subdev, frequency)
self.wxgui_scopesink2_0 = scopesink2.scope_sink_c(
self,
self is a gr.top_block not a wx panel
title=Scope Plot,
sample_rate=32,
v_scale=0,
t_scale=0,
ac_couple=False,
xy_mode=False,
num_inputs=1,
)
self.connect((u, 0), (self.wxgui_scopesink2_0, 0))
if __name__ == '__main__':
try:
my_top_block().run()
except KeyboardInterrupt:
pass
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] May I use GUN Radio without USRP
I want to know may I use GNU radio without USRP. Of course! Gnuradio can be a stand-alone simulation environment. And you can interface it with anything that you can write code for. GNU Radio is... * An API for creating signal blocks (C++/Python) * A runtime environment for signal processing * A library of signal processing blocks * User scripts and applications * Hardware drivers (USRP/USRP2) * An application for creating flow graphs (GRC) I mean Since USRP is just used for transiver, ADC/DAC, converting RF signal to baseband and transmitting baseband signal to GNU Radio for processing, then may I produce baseband workload by an Agilent baseband signal generator or even Matlab, and then connect GNU Radio with signal generator or Matlab? If you can write code in some language to acquire samples from lab equipment, then you can write a custom gnuradio block for that equipment. :-) The reason I am thinking about this is that from some analysis, I find the data rate of the USB2.0 bus limits the bandwidth of the base band signal to 8 MHz, which is not enough for my project. And My focus is just baseband signal processing, I want to save money on USRP if I can use existing equipments in the lab. Can you test your application at lower data rates? Its usually a good idea to see that 1) you can implement the processing in simulation in the gnuradio environment 2) you can run the processing at a low rate on a platform like the USRP 2a) prove that the CPU can keep up at lower rates 2b) prove that the algorithm works in the presence of noise and frequency offsets So usrp can be a valuable part of your RF development even if you must replace it with a higher rate/more expensive device for delivery. Is the extra time spent integrating agilent equipment worth it if you find out that your algorithm cant run in real-time at lower usrp rates? Hope that helps! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
回复： [Discuss-gnuradio] May I use GUN Radio without USRP
Hi, Josh Thank you very much, your opinion is really helpful! Yes, GNURadio + USRP is an excellent simulation environment. I will consider again how to leverage it for my application. Hanks 发件人： Josh Blum j...@joshknows.com 收件人： discuss-gnuradio@gnu.org 发送日期： 2010/7/11 (周日) 1:08:46 下午 主 题： Re: [Discuss-gnuradio] May I use GUN Radio without USRP I want to know may I use GNU radio without USRP. Of course! Gnuradio can be a stand-alone simulation environment. And you can interface it with anything that you can write code for. GNU Radio is... * An API for creating signal blocks (C++/Python) * A runtime environment for signal processing * A library of signal processing blocks * User scripts and applications * Hardware drivers (USRP/USRP2) * An application for creating flow graphs (GRC) I mean Since USRP is just used for transiver, ADC/DAC, converting RF signal to baseband and transmitting baseband signal to GNU Radio for processing, then may I produce baseband workload by an Agilent baseband signal generator or even Matlab, and then connect GNU Radio with signal generator or Matlab? If you can write code in some language to acquire samples from lab equipment, then you can write a custom gnuradio block for that equipment. :-) The reason I am thinking about this is that from some analysis, I find the data rate of the USB2.0 bus limits the bandwidth of the base band signal to 8 MHz, which is not enough for my project. And My focus is just baseband signal processing, I want to save money on USRP if I can use existing equipments in the lab. Can you test your application at lower data rates? Its usually a good idea to see that 1) you can implement the processing in simulation in the gnuradio environment 2) you can run the processing at a low rate on a platform like the USRP 2a) prove that the CPU can keep up at lower rates 2b) prove that the algorithm works in the presence of noise and frequency offsets So usrp can be a valuable part of your RF development even if you must replace it with a higher rate/more expensive device for delivery. Is the extra time spent integrating agilent equipment worth it if you find out that your algorithm cant run in real-time at lower usrp rates? Hope that helps! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Controlling USRP remotely using VNC
Hi All, I got a problem when I want to remotely access the USRP using VNC on Fedora 12. In my case the USRP is at Los Angeles and my location is at Vasa Finland. As you can see in the screeshot below I get a Segmentation fault as local user and as root. http://www.poes-weather.com/~patrik/vnc-remote-segfault.jpg I also noted if I want to control a software that must have root privilegies it wont work remotrly using VNC. Everything works at the station (Los Angeles) This I bet is a permission problem only and I bet you guy's know howto tune the VNC client to have rights needed. It feels like there is a window inbetween me and the F12 even if I login as root using VNC. I also have a similar system on Fedora 9 setup at Vasa Finland and a client connected from Los Angeles and was able to control (full access) my USRP and computer. http://www.poes-weather.com/~patrik/vnc-remote-ok.jpg This is off topic from gnuradio but I bet some on this list know howto cure our problem. Any help appreciated, Patrik___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Controlling USRP remotely using VNC
This is probably an issue with controlling OpenGL remotely using VNC. And on some machines it works, and on some it does something wrong. If you figure it out let me know! In the meantime, you can disable the opengl graphical displays and it will revert to the non-gl ones which should definitely work over VNC. Do this, except style=nongl: http://gnuradio.org/redmine/wiki/gnuradio/CompGrWxgui#Enable-the-GL-Sinks -Josh On 07/11/2010 05:43 PM, Patrik Tast wrote: Hi All, I got a problem when I want to remotely access the USRP using VNC on Fedora 12. In my case the USRP is at Los Angeles and my location is at Vasa Finland. As you can see in the screeshot below I get a Segmentation fault as local user and as root. http://www.poes-weather.com/~patrik/vnc-remote-segfault.jpg I also noted if I want to control a software that must have root privilegies it wont work remotrly using VNC. Everything works at the station (Los Angeles) This I bet is a permission problem only and I bet you guy's know howto tune the VNC client to have rights needed. It feels like there is a window inbetween me and the F12 even if I login as root using VNC. I also have a similar system on Fedora 9 setup at Vasa Finland and a client connected from Los Angeles and was able to control (full access) my USRP and computer. http://www.poes-weather.com/~patrik/vnc-remote-ok.jpg This is off topic from gnuradio but I bet some on this list know howto cure our problem. Any help appreciated, Patrik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
