[Discuss-gnuradio] A std_2rx_2tx.rbf firmware
So, I've basically just compiled what appears to be a functional firmware by modifying only the config files in the Verilog source. I've setup a firmware for 2rx without half-band filters and 2tx. In theory this should allow me to use 8 bit sampling while still maintaining the ability to use my BasicTX daughter board. Is there any reason why my custom firmware still will not function despite compiling successfully? Thanks, ~Jeff -- ~Jeffrey Lambert, K1VZX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Controlling USRP remotely using VNC
Hi Josh, Oh, I'll try that and let you know my/our progress Many thanks Patrik - Original Message - From: "Josh Blum" To: Sent: Monday, July 12, 2010 4:12 Subject: 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 ___ 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
[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
回复： [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 收件人： 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
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
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, in
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] Make db_base::_refclk_divisor pure virtual?
On Sun, Jul 11, 2010 at 1:38 AM, Jason Abele wrote: > Unfortunately, I am not a good person to ask about this, my name > appears on that line solely because I fixed a typo in the error > message that had made tracking down a problem in my code more > difficult. Can I ask what the problem was? > I would guess that either Eric or Johnathan have more insight into the > design decisions on the USRP daughterboard api than I can offer. Actually, I realized that the db_base::*refclk* functions are only used by some of the daughterboards, so it makes sense to only define _refclk_divisor for some dbs. The error messages might be more helpful as something like "Daughterboard must define _reflck_divisor() to use db_base::*refclk*()", though. ___ 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
[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
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
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
