[Discuss-gnuradio] Waterfall display in uhd_fft
Hello, We are running gnuradio v 3.7.8 on Ubuntu 15.08. H/W is B210.We are looking at our self echo from EME (moon bounce). When running uhd_fft, we see clear EME echo signals on the FFT display (10-20 db above the noise). However, we don't see these signals on the waterfall display. We do see the very large signals when we transmit.Is there a way to adjust the "vertical" range of the display so that the noise is mapped onto something black or nearly so and signals 20 db above the noise appear as bright colors? Sincerely, Dan Marlow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP CODEC loopback error with B210
Hello, We have been experiencing occasional "CODEC loopback test" failures when using a B210. A very similar problem was reported at http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-September/015645.html In our case* the problem happens roughly once per every 20 attempts. We were able to workaround the problem using a "try . . . except" block in the python code that instantiates the top_block module, but would like to know if there is a better solution. Sincerely, Dan Marlow *Ubuntu 15.04 Python 2.7.9 gnuradio 3.7.8 UHD_003.009.000-1-g71985969 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Meta file time stamp
On Sep 9, 2015, at 12:46 PM, Tom Rondeau wrote: > On Wed, Sep 2, 2015 at 3:51 PM, Daniel Marlow <mar...@princeton.edu> wrote: > Dear All, > > We are experiencing unexpected behavior with the time stamps in the meta > file headers. It > appears that in cases where the flowgraph experiences data drops, the > timestamp is properly > updated. However, in cases, where the flowgraph hits the maximum segment > size (4 MB in our case), > the calculation of timestamp is done in such a way that appears to neglect a > decimation factor > in one of our blocks (keep_1_in_n). Details can be found below. Any > suggestions as to what's > going on or what to do about it would be most appreciated. > > Sincerely, > Dan Marlow > > Details: > >OS: Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64) > >H/W: Ettus B210 with GPSDO, > Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz 8GB memory USB3 > > gnuradio: 3.7.8 > > Flowgraph: This is provided to give an idea of what we are doing. It is > close to what we > are using, but not exact, since we edited the output > generated by GRC. > > > > > The actual top_block we are running is attached below. > > > > > Results: gr_read_file_metadata test09.dat > headers.txt > > > Yeah, I think I can see this as a problem. It's getting the sample rate from > the UHD device as a tag, but that doesn't know that the sample rate has been > changed through the flowgraph. > > Can you open an issue on the gnuradio.org issue tracker to remind me about > this? > > Tom > Hi Tom, Thanks for getting back to me. I had attempted to post an update to this, but something went wrong with my mail client and it didn't go out. Anyway, we figured out the problem. In a nutshell, we did not understand the meaning of the "relative rate change parameter" in the calling sequence for the meta file sink block. That is (obviously in hindsight) the way in which the system learns about decimation factors that come in between the UHD and the file sink. In particular, if there is a stage that decimates by N, the relative rate change parameter should be set to 1/N. Sincerely, Dan Marlow___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Meta file time stamp
Dear All,
We are experiencing unexpected behavior with the time stamps in the meta file
headers. It
appears that in cases where the flowgraph experiences data drops, the timestamp
is properly
updated. However, in cases, where the flowgraph hits the maximum segment size
(4 MB in our case),
the calculation of timestamp is done in such a way that appears to neglect a
decimation factor
in one of our blocks (keep_1_in_n). Details can be found below. Any
suggestions as to what's
going on or what to do about it would be most appreciated.
Sincerely,
Dan Marlow
Details:
OS: Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)
H/W: Ettus B210 with GPSDO,
Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz 8GB memory USB3
gnuradio: 3.7.8
Flowgraph: This is provided to give an idea of what we are doing. It is
close to what we
are using, but not exact, since we edited the output
generated by GRC.
B210_2ch_filewriter.grc
Description: Binary data
The actual top_block we are running is attached below.
#!/usr/bin/env python2
##
# GNU Radio Python Flow Graph
# Title: Top Block
# Generated: Thu Jul 23 11:29:50 2015
##
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import fft
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.fft import window
from gnuradio.filter import firdes
from optparse import OptionParser
import specest
import time
import pmt
from DAQ import rxcntl
class top_block(gr.top_block):
def __init__(self, fname1='raw1.dat', fname2='raw2.dat'):
gr.top_block.__init__(self, "Top Block")
##
# Extra Variables
##
self.fname1 = fname1
self.fname2 = fname2
self.nChannels = nChannels = 1
print "Entering top_block: fname1={0:s} fname2={1:s}".format(self.fname1,self.fname2)
##
# Variables
##
self.freq1 = freq1 = 142000
self.freq2 = freq2 = 142000
self.samp_rate = samp_rate = 1/4.
self.gain = gain = 60
self.N_average = N_average = 512
self.FFT_size = FFT_size = 32
self.BW = BW = 2000
self.BW = BW = 2500
##
# Blocks
##
self.uhd_usrp_source_0 = uhd.usrp_source(
",".join(("ser=F61177", "")),
uhd.stream_args(
cpu_format="fc32",
channels=range(self.nChannels),
),
)
self.uhd_usrp_source_0.set_subdev_spec("A:A A:B", 0)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(self.freq1, 0)
self.uhd_usrp_source_0.set_gain(gain, 0)
self.uhd_usrp_source_0.set_bandwidth(BW, 0)
#sensorNames = self.uhd_usrp_source_0.get_mboard_sensor_names(0)
#print "Sensor names=" + str(sensorNames)
GPStime = self.uhd_usrp_source_0.get_mboard_sensor("gps_time")
GPS_locked = self.uhd_usrp_source_0.get_mboard_sensor("gps_locked")
print "GPS Info: {0:s}; {1:s}".format(str(GPS_locked),str(GPStime))
self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()), uhd.ALL_MBOARDS)
if self.nChannels == 2 :
self.uhd_usrp_source_0.set_center_freq(self.freq2, 1)
self.uhd_usrp_source_0.set_gain(gain, 1)
self.uhd_usrp_source_0.set_bandwidth(BW, 1)
self.specest_moving_average_vff_0 = specest.moving_average_vff(N_average, FFT_size, 1, 4096)
self.fft_vxx_0 = fft.fft_vcc(FFT_size, True, (window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0 = blocks.vector_to_stream(gr.sizeof_float*1, FFT_size)
self.blocks_stream_to_vector_0 = blocks.stream_to_vector(gr.sizeof_gr_complex*1, FFT_size)
self.blocks_keep_one_in_n_0_0 = blocks.keep_one_in_n(gr.sizeof_float*FFT_size, N_average)
self.blocks_complex_to_mag_squared_0 = blocks.complex_to_mag_squared(FFT_size)
self.blocks_file_meta_sink_0 = blocks.file_meta_sink(gr.sizeof_float*1, self.fname1, self.samp_rate, \
1, blocks.GR_FILE_FLOAT, False, 100, self._extras(), False)
self.blocks_file_meta_sink_0.set_unbuffered(False)
if self.nChannels == 2 :
self.specest_moving_average_vff_1 = specest.moving_average_vff(N_average, FFT_size, 1, 4096)
self.fft_vxx_0_0 = fft.fft_vcc(FFT_size, True, (window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0_0 = blocks.vector_to_stream(gr.sizeof_float*1,
[Discuss-gnuradio] HRPT receiver
Hello, In the gnuradio/gr-noaa/README file under usrp_rx_hrpt.py, there is a comment that reads as follows: The present HRPT demodulator is only tested at decimation 16.The only other valid decimation rates are 24 and 32, which may work, but with more bit errors. No other decimation rates will work. My (perhaps naive) question is whether the important parameter is the decimation rate, or the sampling rate. For example, with 64 MHz USRP, a decimation of 16 would give 4 MHz sampling, whereas with a higher rate USRP, the same decimation would yield a higher sampling rate. I would appreciate it if someone could clarify this point for me. Sincerely, Dan Marlow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HRPT receiver
Hi Marcus, Thanks. That explains it. Will try 5 MHz with our N200. Cheers, Dan On Jun 30, 2015, at 4:56 PM, Marcus Müller wrote: Hi Daniel, that README refers to things of the past (when you specified a decimation rather than the sampling rate you want), and USRP refered to what we nowadays call the USRP1. In the version of the usrp_rx_hrpt.grc, from which the .py gets generated, the USRP source is just configured to 4MS/s. The question is whether 4MS/s is really the optimum rate; I haven't studied the HRPT signal enough to answer this. In principle, for the 100MHz devices (N210/N200), 4MS/s is a suboptimal rate, since the decimation (25) is odd, and I'd try with something less strange, like 5MS/s. Best regards, Marcus On 06/30/2015 10:49 PM, Daniel Marlow wrote: Hello, In the gnuradio/gr-noaa/README file under usrp_rx_hrpt.py, there is a comment that reads as follows: The present HRPT demodulator is only tested at decimation 16.The only other valid decimation rates are 24 and 32, which may work, but with more bit errors. No other decimation rates will work. My (perhaps naive) question is whether the important parameter is the decimation rate, or the sampling rate. For example, with 64 MHz USRP, a decimation of 16 would give 4 MHz sampling, whereas with a higher rate USRP, the same decimation would yield a higher sampling rate. I would appreciate it if someone could clarify this point for me. Sincerely, Dan Marlow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] B210 two-channel operation
Hello, OS: Ubuntu 14.01.1 gnu-radio: 3.7.6 Dell Optiplex 765 I am having trouble using the B210 USRP in two channel mode. Things work well when I use grc to configure the B210 with one channel, but when I try using two channels, I get the error shown below. This is quite similar to a problem I had earlier with a TVRX2, which was fixed with a "-M build." I am still using the same build and the TVRX2 continues to work fine. Perhaps I am not configuring the B210 properly? I attach the .grc and top_block.py files. Any suggestions would be most welcome.Sincerely,Dan Marlow B210b.grc Description: Binary data #!/usr/bin/env python ## # Gnuradio Python Flow Graph # Title: Top Block # Generated: Tue Jan 27 14:20:47 2015 ## from gnuradio import eng_notation from gnuradio import gr from gnuradio import uhd from gnuradio import wxgui from gnuradio.eng_option import eng_option from gnuradio.fft import window from gnuradio.filter import firdes from gnuradio.wxgui import fftsink2 from gnuradio.wxgui import forms from grc_gnuradio import wxgui as grc_wxgui from optparse import OptionParser import time import wx class top_block(grc_wxgui.top_block_gui): def __init__(self): grc_wxgui.top_block_gui.__init__(self, title=Top Block) _icon_path = /usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY)) ## # Variables ## self.size = size = 1024 self.samp_rate = samp_rate = 100 self.gain = gain = 20 self.freq = freq = 115000 self.FFT_refresh = FFT_refresh = 10 self.BW = BW = 100 ## # Blocks ## self._gain_text_box = forms.text_box( parent=self.GetWin(), value=self.gain, callback=self.set_gain, label=RF Gain, converter=forms.float_converter(), ) self.Add(self._gain_text_box) self._freq_text_box = forms.text_box( parent=self.GetWin(), value=self.freq, callback=self.set_freq, label=Center Frequency, converter=forms.float_converter(), ) self.Add(self._freq_text_box) self.wxgui_fftsink2_0_0_0 = fftsink2.fft_sink_c( self.GetWin(), baseband_freq=freq, y_per_div=10, y_divs=10, ref_level=-20, ref_scale=2.0, sample_rate=samp_rate, fft_size=size, fft_rate=FFT_refresh, average=False, avg_alpha=0.1, title=FFT Plot, peak_hold=False, ) self.Add(self.wxgui_fftsink2_0_0_0.win) self.wxgui_fftsink2_0_0 = fftsink2.fft_sink_c( self.GetWin(), baseband_freq=freq, y_per_div=10, y_divs=10, ref_level=-20, ref_scale=2.0, sample_rate=samp_rate, fft_size=size, fft_rate=FFT_refresh, average=False, avg_alpha=0.1, title=FFT Plot, peak_hold=False, ) self.Add(self.wxgui_fftsink2_0_0.win) self.uhd_usrp_source_0 = uhd.usrp_source( ,.join((, )), uhd.stream_args( cpu_format=fc32, channels=range(2), ), ) self.uhd_usrp_source_0.set_subdev_spec(A:A, 0) self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()), uhd.ALL_MBOARDS) self.uhd_usrp_source_0.set_samp_rate(samp_rate) self.uhd_usrp_source_0.set_center_freq(freq, 0) self.uhd_usrp_source_0.set_gain(gain, 0) self.uhd_usrp_source_0.set_antenna(RX2, 0) self.uhd_usrp_source_0.set_bandwidth(BW, 0) self.uhd_usrp_source_0.set_center_freq(freq, 1) self.uhd_usrp_source_0.set_gain(gain, 1) self.uhd_usrp_source_0.set_antenna(RX2, 1) self.uhd_usrp_source_0.set_bandwidth(BW, 1) ## # Connections ## self.connect((self.uhd_usrp_source_0, 0), (self.wxgui_fftsink2_0_0, 0)) self.connect((self.uhd_usrp_source_0, 1), (self.wxgui_fftsink2_0_0_0, 0)) def get_size(self): return self.size def set_size(self, size): self.size = size def get_samp_rate(self): return self.samp_rate def set_samp_rate(self, samp_rate): self.samp_rate = samp_rate self.wxgui_fftsink2_0_0.set_sample_rate(self.samp_rate) self.wxgui_fftsink2_0_0_0.set_sample_rate(self.samp_rate) self.uhd_usrp_source_0.set_samp_rate(self.samp_rate) def get_gain(self): return self.gain def set_gain(self, gain):
[Discuss-gnuradio] specest issue
Dear All:
OS: Ubuntu 14.01.1
gnu-radio: 3.7.6
Dell Optiplex 765
I want to use the moving_average_vff block from specest, which is not
available in GRC. I tried installing gr-specest using pybombs (gnuradio was
already installed on this system using /usr/local/build-gnuradio -m ).
The pybombs installation of gr-specest seemed to go OK, but top_block.py fails
at the import specest line nonetheless.The error trace and the
top_block.py that I am using appear below (the top_block.py was generated from
GRC and then slightly modified to included the moving_average_vff block).A
linux find command reveals that the apparently missing .so is in
/usr/local/lib/libgnuradio-specest.so. Should it be somewhere else?
Any help would be greatly appreciated.
Sincerely,
Dan Marlow
marlow@phy-gr5:~/gnuradio/TVRX2$ python top_block.py
Traceback (most recent call last):
File top_block.py, line 7, in module
import specest
File /usr/local/lib/python2.7/dist-packages/specest/__init__.py, line 45,
in module
from specest_swig import *
File /usr/local/lib/python2.7/dist-packages/specest/specest_swig.py, line
28, in module
_specest_swig = swig_import_helper()
File /usr/local/lib/python2.7/dist-packages/specest/specest_swig.py, line
24, in swig_import_helper
_mod = imp.load_module('_specest_swig', fp, pathname, description)
ImportError: libgnuradio-specest.so: cannot open shared object file: No such
file or directory
marlow@phy-gr5:~/gnuradio/TVRX2$
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Mon Dec 22 13:34:46 2014
##
import specest
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import fft
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.fft import window
from gnuradio.filter import firdes
from gnuradio.wxgui import forms
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import time
import wx
class top_block(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title=Top Block)
_icon_path = /usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
##
# Variables
##
self.samp_rate = samp_rate = int(5.0e6)
self.gain = gain = 20
self.freq = freq = 400e6
self.N_average = N_average = 4096
self.FFT_size = FFT_size = 128
self.BW = BW = 170
##
# Blocks
##
self._gain_text_box = forms.text_box(
parent=self.GetWin(),
value=self.gain,
callback=self.set_gain,
label=RF Gain,
converter=forms.float_converter(),
)
self.Add(self._gain_text_box)
self._freq_text_box = forms.text_box(
parent=self.GetWin(),
value=self.freq,
callback=self.set_freq,
label=Center Frequency,
converter=forms.float_converter(),
)
self.Add(self._freq_text_box)
self.uhd_usrp_source_0 = uhd.usrp_source(
,.join((addr=192.168.10.2, )),
uhd.stream_args(
cpu_format=fc32,
channels=range(1),
),
)
self.uhd_usrp_source_0.set_time_source(gpsdo, 0)
self.uhd_usrp_source_0.set_subdev_spec(A:RX1, 0)
self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()),
uhd.ALL_MBOARDS)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(freq, 0)
self.uhd_usrp_source_0.set_gain(gain, 0)
self.uhd_usrp_source_0.set_bandwidth(BW, 0)
self.fft_vxx_0 = fft.fft_vcc(FFT_size, True,
(window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0 =
blocks.vector_to_stream(gr.sizeof_float*1, FFT_size)
self.blocks_stream_to_vector_0 =
blocks.stream_to_vector(gr.sizeof_gr_complex*1, 128)
self.blocks_keep_one_in_n_0 = blocks.keep_one_in_n(gr.sizeof_float*128,
N_average)
self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_float*1,
./testfile.dat, False)
self.blocks_file_sink_0.set_unbuffered(False)
self.blocks_complex_to_mag_squared_0 =
blocks.complex_to_mag_squared(FFT_size)
self.vectorAverage=specest.moving_average_vff(N_average,FFT_size,2000)
##
# Connections
##
Re: [Discuss-gnuradio] specest issue
No, I didn't. And I am not sure why not, since it made it work so much better!
Seriously . . . thanks for the help. I should have known that.
Cheers,
Dan
On Dec 23, 2014, at 11:56 AM, Marcus D. Leech wrote:
On 12/23/2014 08:47 AM, Daniel Marlow wrote:
Dear All:
OS: Ubuntu 14.01.1
gnu-radio: 3.7.6
Dell Optiplex 765
I want to use the moving_average_vff block from specest, which is not
available in GRC. I tried installing gr-specest using pybombs (gnuradio
was already installed on this system using /usr/local/build-gnuradio -m ).
The pybombs installation of gr-specest seemed to go OK, but top_block.py
fails at the import specest line nonetheless.The error trace
and the top_block.py that I am using appear below (the top_block.py was
generated from GRC and then slightly modified to included the
moving_average_vff block).A linux find command reveals that the
apparently missing .so is in /usr/local/lib/libgnuradio-specest.so. Should
it be somewhere else?
Any help would be greatly appreciated.
Sincerely,
Dan Marlow
After you installed specest, did you do a sudo ldconfig ?
marlow@phy-gr5:~/gnuradio/TVRX2$ python top_block.py
Traceback (most recent call last):
File top_block.py, line 7, in module
import specest
File /usr/local/lib/python2.7/dist-packages/specest/__init__.py, line
45, in module
from specest_swig import *
File /usr/local/lib/python2.7/dist-packages/specest/specest_swig.py,
line 28, in module
_specest_swig = swig_import_helper()
File /usr/local/lib/python2.7/dist-packages/specest/specest_swig.py,
line 24, in swig_import_helper
_mod = imp.load_module('_specest_swig', fp, pathname, description)
ImportError: libgnuradio-specest.so: cannot open shared object file: No such
file or directory
marlow@phy-gr5:~/gnuradio/TVRX2$
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Mon Dec 22 13:34:46 2014
##
import specest
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import fft
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.fft import window
from gnuradio.filter import firdes
from gnuradio.wxgui import forms
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import time
import wx
class top_block(grc_wxgui.top_block_gui):
def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title=Top Block)
_icon_path = /usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
##
# Variables
##
self.samp_rate = samp_rate = int(5.0e6)
self.gain = gain = 20
self.freq = freq = 400e6
self.N_average = N_average = 4096
self.FFT_size = FFT_size = 128
self.BW = BW = 170
##
# Blocks
##
self._gain_text_box = forms.text_box(
parent=self.GetWin(),
value=self.gain,
callback=self.set_gain,
label=RF Gain,
converter=forms.float_converter(),
)
self.Add(self._gain_text_box)
self._freq_text_box = forms.text_box(
parent=self.GetWin(),
value=self.freq,
callback=self.set_freq,
label=Center Frequency,
converter=forms.float_converter(),
)
self.Add(self._freq_text_box)
self.uhd_usrp_source_0 = uhd.usrp_source(
,.join((addr=192.168.10.2, )),
uhd.stream_args(
cpu_format=fc32,
channels=range(1),
),
)
self.uhd_usrp_source_0.set_time_source(gpsdo, 0)
self.uhd_usrp_source_0.set_subdev_spec(A:RX1, 0)
self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()),
uhd.ALL_MBOARDS)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(freq, 0)
self.uhd_usrp_source_0.set_gain(gain, 0)
self.uhd_usrp_source_0.set_bandwidth(BW, 0)
self.fft_vxx_0 = fft.fft_vcc(FFT_size, True,
(window.blackmanharris(FFT_size)), True, 1)
self.blocks_vector_to_stream_0 =
blocks.vector_to_stream(gr.sizeof_float*1, FFT_size)
self.blocks_stream_to_vector_0 =
blocks.stream_to_vector(gr.sizeof_gr_complex*1, 128)
self.blocks_keep_one_in_n_0 =
blocks.keep_one_in_n(gr.sizeof_float*128, N_average)
self.blocks_file_sink_0 = blocks.file_sink(gr.sizeof_float*1,
./testfile.dat, False)
self.blocks_file_sink_0
[Discuss-gnuradio] RX channel 1 out of range for configured RX frontends
Hello, We are using a TVRX2 board with a N200 USRP.Until recently, the system was working properly with two channels using the attached flowgraph.For reasons that are unclear, it stopped working and is no longer capable of two channel operation (if we set the Num channels parameter to 1, the system works, but with only one channel).So far as we can tell, nothing in the S/W changed. Version details and the error message appears below. Suggestions what has gone wrong would be most appreciated. --Dan H/W: Dell Optiplex Dual 2.4 GHz, 2 GB / USRP N200 with TVRX2 GPSDO boards. OS: Ubuntu 14 gnuradio: 3.7.6 Traceback (most recent call last): File /home/marlow/gnuradio/TVRX2/top_block.py, line 177, in module tb = top_block() File /home/marlow/gnuradio/TVRX2/top_block.py, line 94, in __init__ channels=range(2), File /usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py, line 122, in constructor_interceptor return old_constructor(*args) File /usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py, line 1753, in make return _uhd_swig.usrp_source_make(*args) RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of range for configured RX frontends http://www.hep.princeton.edu/~marlow/gnuradio/TVRX2.png http://www.hep.princeton.edu/~marlow/gnuradio/TVRX2.grc___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RX channel 1 out of range for configured RX frontends
On Nov 3, 2014, at 5:59 PM, Marcus D. Leech wrote: On 11/03/2014 05:55 PM, Daniel Marlow wrote: Hello, We are using a TVRX2 board with a N200 USRP.Until recently, the system was working properly with two channels using the attached flowgraph. For reasons that are unclear, it stopped working and is no longer capable of two channel operation (if we set the Num channels parameter to 1, the system works, but with only one channel).So far as we can tell, nothing in the S/W changed. Version details and the error message appears below. Suggestions what has gone wrong would be most appreciated. --Dan There's a fix for this problem in the most recent master of GR, which doesn't appear in the maint branch. It was a wee problem in gr-uhd that was introduced by wanting to be more strict about master-clock LOCK, and, well, that provoked other underlying problems. What are you using the TVRX2 for, BTW. I'll note that it has cannot-be-defeated hardware AGC, so it's of only limited utility for radio astronomy, which I think you're probably using it for :) Hi Marcus, Thanks. Does that mean we need a new install of GR? The one we have is quite recent. Regarding the TVRX2, I did not know about the AGC issue. We are using it for RA (pulsar searches). Since we are doing synchronous detection, it's not clear to me that the AGC will be a fundamental problem, since we don't need quantitative power measurements. We wanted two channels since we are using crossed Yagi's. I don't see any alternatives from Ettus. --Dan H/W: Dell Optiplex Dual 2.4 GHz, 2 GB / USRP N200 with TVRX2 GPSDO boards. OS: Ubuntu 14 gnuradio: 3.7.6 Traceback (most recent call last): File /home/marlow/gnuradio/TVRX2/top_block.py, line 177, in module tb = top_block() File /home/marlow/gnuradio/TVRX2/top_block.py, line 94, in __init__ channels=range(2), File /usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py, line 122, in constructor_interceptor return old_constructor(*args) File /usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py, line 1753, in make return _uhd_swig.usrp_source_make(*args) RuntimeError: LookupError: IndexError: multi_usrp: RX channel 1 out of range for configured RX frontends http://www.hep.princeton.edu/~marlow/gnuradio/TVRX2.png http://www.hep.princeton.edu/~marlow/gnuradio/TVRX2.grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why is fft output complex?
On Oct 11, 2014, at 5:38 PM, k1...@comcast.net k1...@comcast.net wrote: I can't wrap my head around why fft transform of complex signal produces a complex output. After all the output reflects the amount of energy per frequency bin and frequency bins and energy are both real numbers, no? I'm trying to write a python script to analyze the energy across frequency bins but I don't know where to insert a complex to mag block. I think if I can understand the fft I will know to put the complex to mag. Thanks Brad. _ Dear Brad, What you write is mostly correct. But you are thinking of the power spectrum, which is the modulus of the FFT and thus entirely real. An FFT contains more information. For example, a Fourier Transform (the continuous version of an FFT) can be inverted using an Inverse Fourier Transform to exactly reproduce the original time-domain waveform.That would not be possible using the power spectrum alone, since information is lost in going from the complex Fourier Transform to the power spectrum. --Dan Marlow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TVRX2 and GRC
On Oct 4, 2014, at 6:39 PM, Marcus D. Leech wrote: On Oct 3, 2014, at 7:30 PM, Marcus D. Leech wrote: If you put your flow-graph itself (.grc file) somewhere, or attach it, we can take a better look. What kind of comptuer? (OS, CPU/MEM specifics, etc). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Hi Marcus, Thanks. The .grc file is attached. Other details: o Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz o Memory 3GB o OS 14.1 Ubuntu Cheers, Dan I've attached updates to your graph that should make it behave more rationally: 2Msps sample rate -- consistent with your programmed 1.7MHz analog bandwidth Deleted antenna spec in source block--it contained invalid specification Made the device address spec valid Moved things into user-changable variables: freq and gain Made both source and FFT use the samp_rate variable, so changing that variable will change both source and FFT sink Made FFT sink turn on averaging, and use freq variable to set center frequency I'd suggest looking it over carefully, and comparing against what you originally had. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org TVRX2.grc Hi Marcus, Many thanks. We will give that a try. Cheers, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TVRX2 and GRC
On Oct 3, 2014, at 7:30 PM, Marcus D. Leech wrote: If you put your flow-graph itself (.grc file) somewhere, or attach it, we can take a better look. What kind of comptuer? (OS, CPU/MEM specifics, etc). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org Hi Marcus, Thanks. The .grc file is attached. Other details: o Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz o Memory 3GB o OS 14.1 UbuntuCheers,Dan TVRX2.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TVRX2 and GRC
On Oct 3, 2014, at 7:49 PM, Jeff Long wrote: Dan, If you execute the various sudo sysctl ... lines shown in the warnings, does it work any better? You can make these permanent. man sysctl.conf - Jeff Hi Jeff, Thanks for the suggestion.We will give that a try. Cheers, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Parsing extra metadata
Hi Tom, Thanks for looking at this. The answer is yes, as can be seen from the output below. The rx_freq field is not something that I added. I did add the dumm field, however. Sincerely, Dan Marlow marlow@phy-gr2:~/pulsar/DAQ$ gr_read_file_metadata meta_test.dat.hdr HEADER 0 Version Number: 0 Sample Rate: 400.00 sps Seconds: 0.184295 Item size: 4 Data Type: float (5) Complex? False Header Length: 189 bytes Extra Length: 40 Extra Header? True Size of Data: 65536 bytes 16384 items Extra Header: rx_freq: 1.2e+09 dumm: 1408561917746092 On Aug 21, 2014, at 6:03 PM, Tom Rondeau wrote: On Tue, Aug 19, 2014 at 3:13 PM, Daniel Marlow mar...@princeton.edu wrote: Hello, I am trying to add some extra information to the standard metadata file header. Following the information posted on http://gnuradio.org/doc/doxygen/page_metadata.html , I am able to write and read the standard metadata.I have attempted to add extra metadata with the following lines in my flowgraph: # add some extra meta data key = pmt.pmt_intern(dummy) val = pmt.pmt_from_long(77) extras = pmt.pmt_make_dict() extras = pmt.pmt_dict_add(extras, key, val) extras_str = pmt.pmt_serialize_str(extras) nItems = 1024*size self.blocks_file_meta_sink_0 = blocks.file_meta_sink(gr.sizeof_float*1,./meta_test.dat, samp_rate, 1, blocks.GR_FILE_FLOAT, False, nItems, extras_str, True) self.blocks_file_meta_sink_0.set_unbuffered(False) I think that the writing is going OK, since the length of the header increases by a reasonable amount and a Unix hexdump indicates that the dummy data is present. However, I am stuck when it comes to getting at the extra data using the parse_file_metadata functions. In particular, when I try to read the data using: cHeader = c[0:185] # character array read from file pmt_dict = pmt.pmt_deserialize_str(cHeader) p = parse_file_metadata.parse_header(pmt_dict,False) p_extra = parse_file_metadata.parse_extra_dict(pmt_dict,info,True) The first parse_file_metadata line successfully provides the standard metadata, but the second parse_file_metadata does not provide the extra dummy data. I suspect that it has to do with my poor understanding of what should go in the info argument. Any help would be greatly appreciated. Sincerely, Dan Marlow Dan, What happens when you run gr_read_metadata on the file that's created? Does that show your extra header info? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Parsing extra metadata
Hello, I am trying to add some extra information to the standard metadata file header. Following the information posted on http://gnuradio.org/doc/doxygen/page_metadata.html , I am able to write and read the standard metadata.I have attempted to add extra metadata with the following lines in my flowgraph: # add some extra meta data key = pmt.pmt_intern(dummy) val = pmt.pmt_from_long(77) extras = pmt.pmt_make_dict() extras = pmt.pmt_dict_add(extras, key, val) extras_str = pmt.pmt_serialize_str(extras) nItems = 1024*size self.blocks_file_meta_sink_0 = blocks.file_meta_sink(gr.sizeof_float*1,./meta_test.dat, samp_rate, 1, blocks.GR_FILE_FLOAT, False, nItems, extras_str, True) self.blocks_file_meta_sink_0.set_unbuffered(False) I think that the writing is going OK, since the length of the header increases by a reasonable amount and a Unix hexdump indicates that the dummy data is present. However, I am stuck when it comes to getting at the extra data using the parse_file_metadata functions. In particular, when I try to read the data using: cHeader = c[0:185] # character array read from file pmt_dict = pmt.pmt_deserialize_str(cHeader) p = parse_file_metadata.parse_header(pmt_dict,False) p_extra = parse_file_metadata.parse_extra_dict(pmt_dict,info,True) The first parse_file_metadata line successfully provides the standard metadata, but the second parse_file_metadata does not provide the extra dummy data. I suspect that it has to do with my poor understanding of what should go in the info argument. Any help would be greatly appreciated. Sincerely, Dan Marlow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBFM receive block and FM demodulation process questions
Hello J, You can find some details on this at URL: http://radioware.nd.edu/documentation/basic-gnuradio It sounds like much of this will be old hat to you, but there is a section entitled Exploring the FM receiver, which addresses at least some of your specific question. Sincerely, Dan Marlow On Jul 10, 2011, at 9:07 PM, concernedconsumer wrote: Hello, I am a high school student and am very interested in the AM and FM demodulation processes. I have been using gnu radio in combination with a USRP to receive radio signals, demodulate, and listen. This past year, I worked through the details of AM demodulation in gnu radio by computing mixing, low-pass filtering, decimating, interpolating, and normalizing algorithms. This helped me better understand the AM demodulation process, and especially what was being done in each of the gnu radio blocks. I am now trying to do the same thing with FM demodulation and have implemented the following; frequency x-lating FIR filtering, calculating the instantaneous frequencies, and decimating and interpolating routines (as performed in the rational resampler). My question is about the instantaneous frequencies in FM demodulation. I know that the frequency of the carrier varies with the strength of the transmitted signal. The instantaneous frequencies must then be the deviation of the modulated signal from the carrier (which is at baseband) and denote changes in the strength of the transmitted signal. Still, I must be missing some steps that are performed in the WBFM block. After I calculate the instantaneous frequencies, what do I have to do to complete the demodulation process and be able to play the file back through the audio sink? I have attached a screenshot of the gnuradio-companion flow graph I am following, along with a pdf of the process I am implementing. What does the WBFM block do, mathematically, to the signal? I would also appreciate feedback on the process I am using. Thanks, J screenshot_grc .png FM_demodProcess.pdf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Daniel R. Marlow mar...@princeton.edu Homepage: http://wwwphy.princeton.edu/~marlow/ Phone: 609 258 4383 Fax: 609 258 6360 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
