Hi,
Thanks for your quick reply Mr.Eric.
But in the mentioned example interleaving in being done.
It will not serve my purpose
I think i wasnt specific last time.So here is how the story goes.
At transmitter usrp1 is connected to a host pc.
Two flex2400 daughterboards are mounted on it.
On each flex 2400 one antenna is connected to its TX/RX port.
Now i want to perform spatial demultiplexing.Now what it means is that
^>>>>>01010>>>>daughterboard1
Gnuradio>>>1011001100--->Spatial Demux>>>^
>>>>>>01011>>>daughterboard2
Now the division of data into two streams as well as transmission is happening simultaneously and in realtime..
Please tell me how to go about the spatial demux block(in gnu or python) and correspondingly spatial mux block on the receiver.
Thanks in advance.Looking forward to your reply.
Regards,
Nadia
nadiaraj@hotmail.com
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign up now.
Thursday, December 31, 2009
Re: [Discuss-gnuradio] Help REQ: Transmitting two streams simultaneously
On Thu, Dec 31, 2009 at 06:54:03PM +0000, nadia raj wrote:
>
> hi, i want to transmit two streams simultaneously from two separate
> antennas, each mounted on a separate daughterboard. Both the
> daughterboards are connected to a usrp1. and usrp1 is connected to a
> host pc.the antennas are connected to TX/RX port of the
> daughterboard respectively.I am using flex2400
> daughterboards.Looking forward to your response.
> Regards,Nadianadiaraj@hotmail.com
>
>
> hi, i want to transmit two streams simultaneously from two separate
> antennas, each mounted on a separate daughterboard. Both the
> daughterboards are connected to a usrp1. and usrp1 is connected to a
> host pc.the antennas are connected to TX/RX port of the
> daughterboard respectively.I am using flex2400
> daughterboards.Looking forward to your response.
> Regards,Nadianadiaraj@hotmail.com
>
Take a look at gnuradio-examples/python/usrp/fm_tx_2_daughterboards.py
(Although the filename mentions fm, it doesn't actually do FM (see
fm_tx4.py for an example that does that). It does however send
independent signals out two daughterboards simultaneously.)
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help REQ: Transmitting two streams simultaneously
hi,
Hotmail: Trusted email with powerful SPAM protection. Sign up now.
i want to transmit two streams simultaneously from two separate antennas, each mounted on a separate daughterboard. Both the daughterboards are connected to a usrp1. and usrp1 is connected to a host pc.the antennas are connected to TX/RX port of the daughterboard respectively.
I am using flex2400 daughterboards.
Looking forward to your response.
Regards,
Nadia
nadiaraj@hotmail.com
Hotmail: Trusted email with powerful SPAM protection. Sign up now.
[Discuss-gnuradio] Help req: mimo ofdm
Hi,
I intend to build a 2x2mimo ofdm link.I am using one usrp on each host
computer. And each usrp has two Flex 2400. Im employing spatial
multiplexing.it would be a full duplex link. If you could please tell me
how should i got about the business??
Will the subdev( ) methodology work here? If not then what strategy
should i adopt??
Thanks in advance, looking forward to your reply.
Regards,
Nadia
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.
I intend to build a 2x2mimo ofdm link.I am using one usrp on each host
computer. And each usrp has two Flex 2400. Im employing spatial
multiplexing.it would be a full duplex link. If you could please tell me
how should i got about the business??
Will the subdev( ) methodology work here? If not then what strategy
should i adopt??
Thanks in advance, looking forward to your reply.
Regards,
Nadia
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.
[Discuss-gnuradio] two stream in two cfiles
| Hi all, probably the last question of the year ;) I have a USRP v1 with 2 rfx900 daughterboard. Im trying to listen on two frequencies (one for each DB) and save the corresponding data in two differrent cfile. That at the same time. Hence i tried to modify the uspr_rx_cfile.py using trick from multi_file.py But i dont really know how to configure the mux (seams it should be 0x32103210 but not sure). Moreover how do i deal with the number of channel when creating the source. And finally, how can i connect a stream from one subdevice to the first cfile output and the second stream from the other subdevice to the second cfile? Do i need a interleaver/deinterleaver? Thanks for your precious help. Best wishes for 2010 to all of you, regards, sylvain |
Wednesday, December 30, 2009
[Discuss-gnuradio] Help: About FM implement
Hi:
I have one Basic-Tx and TV-RX in cygwin equipment to get FM frequency.
I try to do follow step, but all got error message.
Why can I do?
And the TV-RX and Bastic-TX can use in same motherboard or need use in different computer?
Thanks.
emily@ncku-34be181a97 /usr/src/gnuradio/gnuradio-examples/python/usrp
$ ./fm_tx4.py -f 91.1M
usb_control_msg failed: usb_control_msg: sending control message failed, win err
or: 附加到系統的某個裝置失去作用。
Using TX d'board A: Basic Tx
r.baseband_freq = 0
r.dxc_freq = 36.9M
r.residual_freq = 381.47m
r.inverted = True
audio-0.dat: No such file or directory
Aborted (core dumped)
emily@ncku-34be181a97 /usr/src/gnuradio/gnuradio-examples/python/usrp
$ ./usrp_wfm_rcv.py
usb_control_msg failed: usb_control_msg: sending control message failed, win err
or: 附加到系統的某個裝置失去作用。
Traceback (most recent call last):
File "./usrp_wfm_rcv.py", line 304, in <module>
app = stdgui2.stdapp (wfm_rx_block, "USRP WFM RX")
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in
__init__
wx.App.__init__ (self, redirect=False)
File "/usr/lib/python2.5/site-packages/wx-2.8-msw-ansi/wx/_core.py", line 7978
, in __init__
self._BootstrapApp()
File "/usr/lib/python2.5/site-packages/wx-2.8-msw-ansi/wx/_core.py", line 7552
, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in
OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in
__init__
self.panel = stdpanel (self, self, top_block_maker)
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in
__init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File "./usrp_wfm_rcv.py", line 94, in __init__
options.rx_subdev_spec = pick_subdevice(self.u)
File "./usrp_wfm_rcv.py", line 46, in pick_subdevice
usrp_dbid.TV_RX_MIMO,
AttributeError: 'module' object has no attribute 'TV_RX_MIMO'
嶄新的 Windows 7：找出適合您的電腦。 深入了解。
I have one Basic-Tx and TV-RX in cygwin equipment to get FM frequency.
I try to do follow step, but all got error message.
Why can I do?
And the TV-RX and Bastic-TX can use in same motherboard or need use in different computer?
Thanks.
emily@ncku-34be181a97 /usr/src/gnuradio/gnuradio-examples/python/usrp
$ ./fm_tx4.py -f 91.1M
usb_control_msg failed: usb_control_msg: sending control message failed, win err
or: 附加到系統的某個裝置失去作用。
Using TX d'board A: Basic Tx
r.baseband_freq = 0
r.dxc_freq = 36.9M
r.residual_freq = 381.47m
r.inverted = True
audio-0.dat: No such file or directory
Aborted (core dumped)
emily@ncku-34be181a97 /usr/src/gnuradio/gnuradio-examples/python/usrp
$ ./usrp_wfm_rcv.py
usb_control_msg failed: usb_control_msg: sending control message failed, win err
or: 附加到系統的某個裝置失去作用。
Traceback (most recent call last):
File "./usrp_wfm_rcv.py", line 304, in <module>
app = stdgui2.stdapp (wfm_rx_block, "USRP WFM RX")
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in
__init__
wx.App.__init__ (self, redirect=False)
File "/usr/lib/python2.5/site-packages/wx-2.8-msw-ansi/wx/_core.py", line 7978
, in __init__
self._BootstrapApp()
File "/usr/lib/python2.5/site-packages/wx-2.8-msw-ansi/wx/_core.py", line 7552
, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in
OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in
__init__
self.panel = stdpanel (self, self, top_block_maker)
File "/usr/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in
__init__
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File "./usrp_wfm_rcv.py", line 94, in __init__
options.rx_subdev_spec = pick_subdevice(self.u)
File "./usrp_wfm_rcv.py", line 46, in pick_subdevice
usrp_dbid.TV_RX_MIMO,
AttributeError: 'module' object has no attribute 'TV_RX_MIMO'
嶄新的 Windows 7：找出適合您的電腦。 深入了解。
[Discuss-gnuradio] Problems with getting block recognized
At the moment I have two problems and am unable to resolve whether they
are related to one another or different problems.
are related to one another or different problems.
The first is that I have a block built by someone else that enables
gnuradio to talk to a radio based on a Digilent Spartan 3E demo board
and an outboard daughter card that performs the A-D conversion.
Supposedly this all works. My problem is in getting gnuradio (and
python) to recognize the module. I have gone back and reviewed very
carefully the instructions in "How to Write a Signal Processing Block"
and believe that I am following the instructions, but I think that
something is not ending up where it should go when I am done. The
second problem is likely related in that the module is unable to find
the flowgraph class during the make check. Any assistance with this or
at least pointing me in the right direction would be greatly appreciated
Thanks,
-CAS
Problem description:
System is Fedora 12. The packages are installed
in /usr/share/lib/Python2.6/site-packages/gnuradio and the PYTHONPATH is
set to "/usr/share/lib/python2.6/site-packages/". The output resulting
When I run the configure && make && make check follows. This shows an
error in the test program in that it is unable to locate flowgraph. I
am assuming that this means it is not locating the gnuradio python files
where this is declared, but no amount of adding libraries or changing
the PYTHONPATH seems to help in this regard. So following up on an
e-mail thread suggestion, I executed the make install instruction. This
installed the files (built without error) into
the /usr/local/lib/python2.6/site-packages/gnuradio/ directory and these
are the only files in this directory. When I try to execute this within
python and load the gnuradio files as follows:
WEB_CONTROL = False
# Controls display of AM Sync Carrier - turn off for smaller
# window if not needed
AM_SYNC_DISPLAY = False
import os, wx, sys, math
import wx.lib.evtmgr as em
from gnuradio import blks2
from gnuradio.wxgui import powermate, fftsink2
from gnuradio import gr, audio, eng_notation, gru
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import nexsdr
This fails stating that it is unable to locate module nexsdr. I tried
moving the installed files (nexsdr.py, nexsdr.pyc, nexsdr.pyo,
_nexsdr.la, _nexsdr.os) to the site-packages/gnuradio directory with the
other gnuradio modules. This did not change anything in the response.
Here is the output of the ./configure, make, make check, and make
install commands:
[root@localhost gr-nexsdr_76.8MHz]# ./configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking whether C++ has bool... yes
checking whether C++ has buggy scoping in for-loops... yes
checking whether user wants assertions... yes
checking whether C++ has std::isnan... yes
checking whether user wants warnings... yes
checking whether g++ accepts -Wall... yes
checking whether g++ accepts -Woverloaded-virtual... yes
checking whether user wants gprof... no
checking whether user wants prof... no
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking dependency style of gcc... gcc3
checking whether ln -s works... yes
checking whether make sets $(MAKE)... (cached) yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for rm... /bin/rm
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1966080
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking how to run the C++ preprocessor... g++ -E
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld) supports shared
libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for python... /usr/bin/python
checking for python version... 2.6
checking for python platform... linux2
checking for python script directory...
${prefix}/lib/python2.6/site-packages
checking for python extension module directory...
${exec_prefix}/lib/python2.6/site-packages
checking for Python include path... /usr/include/python2.6
checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for swig... /usr/bin/swig
checking for SWIG version... 1.3.40
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for cc_r... gcc
checking for library containing clock_gettime... -lrt
checking for clock_gettime... yes
checking for gettimeofday... yes
checking for nanosleep... yes
checking for ANSI C header files... (cached) yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for strings.h... (cached) yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for sys/types.h... (cached) yes
checking for fcntl.h... (cached) yes
checking io.h usability... no
checking io.h presence... no
checking for io.h... no
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking for winioctl.h... no
checking for winbase.h... no
checking for getopt... yes
checking for usleep... yes
checking for gettimeofday... (cached) yes
checking for nanosleep... (cached) yes
checking for rand... yes
checking for srand... yes
checking for random... yes
checking for srandom... yes
checking for sleep... yes
checking for sigaction... yes
checking for struct timezone... yes
checking for struct timespec... yes
checking for ssize_t... yes
checking for getopt... (cached) yes
checking for usleep... (cached) yes
checking for gettimeofday... (cached) yes
checking for Sleep... no
checking whether mkdir accepts only one arg... no
checking for pkg-config... /usr/bin/pkg-config
checking for gnuradio-core >= 3... yes
checking GNURADIO_CORE_CFLAGS... -pthread -DOMNITHREAD_POSIX=1
-I/usr/include/gnuradio
checking GNURADIO_CORE_LIBS... -lgnuradio-core -lboost_thread-mt -lrt
-lboost_date_time-mt -lgruel -lfftw3f -lgsl -lgslcblas -lm
-lgromnithread
checking GNURADIO_CORE_INCLUDEDIR... /usr/include/gnuradio
gr_boost_include_dir =
checking boost/shared_ptr.hpp usability... yes
checking boost/shared_ptr.hpp presence... yes
checking for boost/shared_ptr.hpp... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config/Makefile
config.status: creating doc/Makefile
config.status: creating src/Makefile
config.status: creating src/lib/Makefile
config.status: creating src/python/Makefile
config.status: creating src/python/run_tests
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing run_tests commands
[root@localhost gr-nexsdr_76.8MHz]# make
make all-recursive
make[1]: Entering directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
Making all in config
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
Making all in src
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
Making all in lib
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make all-am
make[4]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[4]: Nothing to be done for `all-am'.
make[4]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
Making all in python
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[2]: Entering directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
make[2]: Leaving directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
make[1]: Leaving directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
[root@localhost gr-nexsdr_76.8MHz]# make check
Making check in config
make[1]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
Making check in src
make[1]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
Making check in lib
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make check-am
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[3]: Nothing to be done for `check-am'.
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
Making check in python
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make check-TESTS
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
E
======================================================================
ERROR: test_000_nop (__main__.qa_usrp)
----------------------------------------------------------------------
Traceback (most recent call last):
File "./qa_nexsdr.py", line 9, in setUp
self.fg = gr.flow_graph ()
AttributeError: 'module' object has no attribute 'flow_graph'
----------------------------------------------------------------------
Ran 1 test in 0.001s
FAILED (errors=1)
FAIL: run_tests
===================
1 of 1 tests failed
===================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make: *** [check-recursive] Error 1
[root@localhost gr-nexsdr_76.8MHz]# make install
Making install in config
make[1]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
make[1]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/config'
Making install in src
make[1]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
Making install in lib
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make install-am
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[4]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[4]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/include/gnuradio" || /bin/mkdir -p
"/usr/local/include/gnuradio"
/usr/bin/install -c -m 644 'nexsdr_source_c.h'
'/usr/local/include/gnuradio/nexsdr_source_c.h'
test -z "/usr/local/lib/python2.6/site-packages/gnuradio" || /bin/mkdir
-p "/usr/local/lib/python2.6/site-packages/gnuradio"
/bin/sh ../../libtool --mode=install /usr/bin/install -c
'_nexsdr.la'
'/usr/local/lib/python2.6/site-packages/gnuradio/_nexsdr.la'
libtool: install: /usr/bin/install
-c .libs/_nexsdr.so /usr/local/lib/python2.6/site-packages/gnuradio/_nexsdr.so
libtool: install: /usr/bin/install
-c .libs/_nexsdr.lai /usr/local/lib/python2.6/site-packages/gnuradio/_nexsdr.la
libtool: finish:
PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/sbin" ldconfig -n /usr/local/lib/python2.6/site-packages/gnuradio
----------------------------------------------------------------------
Libraries have been installed in:
/usr/local/lib/python2.6/site-packages/gnuradio
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
test -z "/usr/local/lib/python2.6/site-packages/gnuradio" || /bin/mkdir
-p "/usr/local/lib/python2.6/site-packages/gnuradio"
/usr/bin/install -c -m 644 'nexsdr.py'
'/usr/local/lib/python2.6/site-packages/gnuradio/nexsdr.py'
Byte-compiling python modules...
nexsdr.py
Byte-compiling python modules (optimized versions) ...
nexsdr.py
test -z "/usr/local/include/gnuradio/swig" || /bin/mkdir -p
"/usr/local/include/gnuradio/swig"
/usr/bin/install -c -m 644 '../../src/lib/nexsdr.i'
'/usr/local/include/gnuradio/swig/nexsdr.i'
make[4]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/lib'
Making install in python
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src/python'
make[2]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[3]: Entering directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[2]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[1]: Leaving directory
`/home/liveuser/Downloads/gr-nexsdr_76.8MHz/src'
make[1]: Entering directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
make[2]: Entering directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
make[2]: Nothing to be done for `install-exec-am'.
test -z "/usr/local/lib/pkgconfig" || /bin/mkdir -p
"/usr/local/lib/pkgconfig"
make[2]: Leaving directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
make[1]: Leaving directory `/home/liveuser/Downloads/gr-nexsdr_76.8MHz'
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ground the USRP1
On Wed, Dec 30, 2009 at 2:58 PM, Matt Ettus <matt@ettus.com> wrote:
indeed, i use one of the LNA's from rfbay, though i can listen to cleaner sigs with other radio equipment at hand..
/a
The only way to lower the noise figure on the TVRX is to put an amplifier in front of it. The noise figure is only about 8-9 dB, though, so it isn't that bad.
indeed, i use one of the LNA's from rfbay, though i can listen to cleaner sigs with other radio equipment at hand..
/a
Re: [Discuss-gnuradio] ground the USRP1
On 12/30/2009 11:50 AM, kdag wrote:
> hia,
>
> On Wed, Dec 30, 2009 at 2:19 PM, Matt Ettus <matt@ettus.com
> <mailto:matt@ettus.com>> wrote:
>
> On 12/30/2009 03:34 AM, Johnny Vestergaard wrote:
>
> Hi,
>
> I recently acquired a USRP1 and are looking to improve reception of
> the TVRX board (i know it's a cable tuner and has noise "issues").
> I noticed the GND pins on the USRP1 board and are wondering if i am
> supposed to ground the board through these pins?
>
>
>
> No, those will not change anything.
>
>
>
> I'm also interested on the topic of lowering the noise fig on the TVRX,
> is that somehow possible?
> hia,
>
> On Wed, Dec 30, 2009 at 2:19 PM, Matt Ettus <matt@ettus.com
> <mailto:matt@ettus.com>> wrote:
>
> On 12/30/2009 03:34 AM, Johnny Vestergaard wrote:
>
> Hi,
>
> I recently acquired a USRP1 and are looking to improve reception of
> the TVRX board (i know it's a cable tuner and has noise "issues").
> I noticed the GND pins on the USRP1 board and are wondering if i am
> supposed to ground the board through these pins?
>
>
>
> No, those will not change anything.
>
>
>
> I'm also interested on the topic of lowering the noise fig on the TVRX,
> is that somehow possible?
The only way to lower the noise figure on the TVRX is to put an
amplifier in front of it. The noise figure is only about 8-9 dB,
though, so it isn't that bad.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ground the USRP1
hia,
On Wed, Dec 30, 2009 at 2:19 PM, Matt Ettus <matt@ettus.com> wrote:
On 12/30/2009 03:34 AM, Johnny Vestergaard wrote:No, those will not change anything.
Hi,
I recently acquired a USRP1 and are looking to improve reception of
the TVRX board (i know it's a cable tuner and has noise "issues").
I noticed the GND pins on the USRP1 board and are wondering if i am
supposed to ground the board through these pins?
I'm also interested on the topic of lowering the noise fig on the TVRX, is that somehow possible?
/a
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ground the USRP1
On 12/30/2009 03:34 AM, Johnny Vestergaard wrote:
> Hi,
>
> I recently acquired a USRP1 and are looking to improve reception of
> the TVRX board (i know it's a cable tuner and has noise "issues").
> I noticed the GND pins on the USRP1 board and are wondering if i am
> supposed to ground the board through these pins?
> Hi,
>
> I recently acquired a USRP1 and are looking to improve reception of
> the TVRX board (i know it's a cable tuner and has noise "issues").
> I noticed the GND pins on the USRP1 board and are wondering if i am
> supposed to ground the board through these pins?
No, those will not change anything.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] a question about the USRP2 MIMO cable
is it ready to use yet?
I read in a post from a year ago, that it wasn't
if it is, do you just need to connect the MIMO cable to get the two streams synchronized or anything else?
I read in a post from a year ago, that it wasn't
if it is, do you just need to connect the MIMO cable to get the two streams synchronized or anything else?
[Discuss-gnuradio] ground the USRP1
Hi,
I recently acquired a USRP1 and are looking to improve reception of
the TVRX board (i know it's a cable tuner and has noise "issues").
I noticed the GND pins on the USRP1 board and are wondering if i am
supposed to ground the board through these pins?
Regards,
Johnny
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Tuesday, December 29, 2009
[Discuss-gnuradio] How to install gnu radio in cygwin?
Dear all,
I am new in gnu radio. I would like to ask about installation gnu radio in cygwin. Does anyone have complete procedure for the installation? Thank you for your help
Makmur
I am new in gnu radio. I would like to ask about installation gnu radio in cygwin. Does anyone have complete procedure for the installation? Thank you for your help
Makmur
[Discuss-gnuradio] Help req: MIMO
Hello,
I intend to build a 2x2mimo ofdm link.I am using one usrp on each host
computer. And each usrp has two Flex 2400. Im employing spatial
multiplexing.it would be a full duplex link. If you could please tell me
how should i got about the business??
Will the subdev( ) methodology work here? If not then what strategy
should i adopt??
Thanks in advance, looking forward to your reply.
Regards,
Nadia
Hotmail: Powerful Free email with security by Microsoft. Get it now.
I intend to build a 2x2mimo ofdm link.I am using one usrp on each host
computer. And each usrp has two Flex 2400. Im employing spatial
multiplexing.it would be a full duplex link. If you could please tell me
how should i got about the business??
Will the subdev( ) methodology work here? If not then what strategy
should i adopt??
Thanks in advance, looking forward to your reply.
Regards,
Nadia
Hotmail: Powerful Free email with security by Microsoft. Get it now.
Re: [Discuss-gnuradio] ENERGY DETECTOR
Thanks for the reply>
I've already checked usrp_spectrum_sense.
I have two points:
1. usrp_fft: does this file still exist ? because i cannot find it. but i
think, it just give you the same results as usrp_spectrum_sense without
tuning the frequency band.
2. You meant by using "quiet time", is to use the same method of estimating
the signal power (using fft), However, use it when you are sure that there
is no signal (can we consider this in Cognitive Radio systems??).
I've already checked usrp_spectrum_sense.
I have two points:
1. usrp_fft: does this file still exist ? because i cannot find it. but i
think, it just give you the same results as usrp_spectrum_sense without
tuning the frequency band.
2. You meant by using "quiet time", is to use the same method of estimating
the signal power (using fft), However, use it when you are sure that there
is no signal (can we consider this in Cognitive Radio systems??).
thanks
Newman, Timothy wrote:
>
> On 12/9/2009 7:49 AM, abbasi9999 wrote:
>> HI ALL
>>
>> I'm trying to implement ENERGY DETECTOR using gnu radio.
>> Is there any library or modules to help. Especially when implementing
>> energy
>> detection we need to estimate the awgn.
>> I've searched in
>> http://gnuradio.org/doc/doxygen/
>> but i cannot find any relative information.
>>
>> regards,
>>
>>
> This can all be done using the usrp_spectrum_sense script or even
> looking at usrp_fft to see how this is done. One way to estimate the
> noise is have a known "quiet time" where you measure the energy of the
> channel and use a threshold derived from that as the signal detection
> threshold.
>
> Tim
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context: http://old.nabble.com/ENERGY-DETECTOR-tp26709651p26963470.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GL sinks freeze
I put the fix on a branch "fix/waterfall" at http://gnuradio.org/git/jblum.git
I also wonder why it did not throw an error: one of the calling methods must have a try/except block, but I couldn't find it.
I put my own try/except in to print out the error. Its seems that the more recent implementation of numpy.choose only handles lookups into tables that are between size 2 and 32.
-Josh
I also wonder why it did not throw an error: one of the calling methods must have a try/except block, but I couldn't find it.
I put my own try/except in to print out the error. Its seems that the more recent implementation of numpy.choose only handles lookups into tables that are between size 2 and 32.
-Josh
On Tue, Dec 29, 2009 at 4:16 PM, Nick Foster <bistromat@hotmail.com> wrote:
Thanks Josh -- ended up finding the same thing right around the same time. =) Wonder why Python wouldn't print the error message to stderr. The diff fixes the problem for me as well. I'll take a look at switching back to using numpy.choose, although the for loop seems to work fine for now.
--n
> Date: Sat, 26 Dec 2009 22:52:04 -0500
> From: josh@joshknows.com
> To: bistromat@hotmail.com
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GL sinks freeze
>> I fixed it on my computer, it seems numpy.choose changed implementation
> since the upgrade to 9.10 (or maybe i was misusing it). I replaced the
> numpy.choose call with a python for loop. Its probably slower than a
> numpy table look up. But lets just see if this also fixes the problem
> for you.
>
> It seems the gnuradio.org server is on vacation again. Attached is the
> diff, try it out.
>
> -Josh
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign up now.
Re: [Discuss-gnuradio] error compiling audio_osx_sink on OS X 10.6.2 "audio_osx_sink.cc:101: error: ‘ComponentDescription’ was not declared in this scope "
You need to modify 'bootstrap' to use 'glibtoolize' instead of
'libtoolize'.
'libtoolize'.
The list archives are your friend: http://lists.gnu.org/archive/html/discuss-gnuradio/
, and then search for the term ... e.g. "libtoolize" top 2 hits are
about building under OSX, and the need to modify bootstrap as per the
above. Hopefully this simple change will take care of your problem &
get you moving with GNU Radio on OSX.
Please do note that, at this time, the WX Python interface is not 64-
bit compatible so you'll need to compile as 32-bit for now. WX itself
(wxWidgets) release 2.9.0 is out & is supposed to be fully 32/64-bit
on OSX now, but the Python interface is not yet. There was some
discussion on this topic recently ... search for it in the archives if
necessary when you get to that point. - MLD
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error compiling audio_osx_sink on OS X 10.6.2 "audio_osx_sink.cc:101: error: ‘ComponentDescription’ was not declared in this scope "
Hi Michael,
Thanks for the reply. I tried compiling from trunk, but unfortunately I receive this error -
% ./bootstrap
./bootstrap: line 28: libtoolize: command not found
configure.ac:126: required file `./ltmain.sh' not found
% ./configure
[...]
Component docs passed configuration checks; building.
configure: creating ./config.status
config.status: error: cannot find input file: gruel/Makefile.in
I saw someone else has had this issue previously, but I couldn't find a solution that would work for me.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error compiling audio_osx_sink on OS X 10.6.2 "audio_osx_sink.cc:101: error: ‘ComponentDescription’ was not declared in this scope "
Hi Trevor - It looks like you're trying to compile GNU Radio release
version 3.2.2, yes? If so, you will note some discussion on this list
a while ago that neither that version nor the (then) GIT master worked
on 10.6 (in either 32 or 64-bit kernel more). We updated the GIT
master to (hopefully) work on all versions of Mac OS X 10.5 (PPC,
PPC64, i386, and x86_64) and 10.6 (i386 an x86_64). So, if the above
it correct then please try using the GIT master -- or wait for the
next number release of GNU Radio. If the above isn't correct, then
please post the version of GNU Radio you're trying to compile. - MLD
version 3.2.2, yes? If so, you will note some discussion on this list
a while ago that neither that version nor the (then) GIT master worked
on 10.6 (in either 32 or 64-bit kernel more). We updated the GIT
master to (hopefully) work on all versions of Mac OS X 10.5 (PPC,
PPC64, i386, and x86_64) and 10.6 (i386 an x86_64). So, if the above
it correct then please try using the GIT master -- or wait for the
next number release of GNU Radio. If the above isn't correct, then
please post the version of GNU Radio you're trying to compile. - MLD
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error compiling audio_osx_sink on OS X 10.6.2 "audio_osx_sink.cc:101: error: ‘ComponentDescription’ was not declared in this scope "
% sw_vers
ProductName: Mac OS X
ProductVersion: 10.6.2
BuildVersion: 10C540
ProductName: Mac OS X
ProductVersion: 10.6.2
BuildVersion: 10C540
% gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)
% ./configure --with-md-cpu=x86_64
% make
[...]
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -DOMNITHREAD_POSIX=1 -I/usr/local/include -I/tmp/gnuradio-3.2.2/omnithread -I/tmp/gnurad
io-3.2.2/gnuradio-core/src/lib/runtime -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/general -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/gene
ral -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/gengen -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/gengen -I/tmp/gnuradio-3.2.2/gnuradio-co
re/src/lib/filter -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/filter -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/missing -I/tmp/gnuradio-3.
2.2/gnuradio-core/src/lib/reed-solomon -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/viterbi -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/io -
I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/g72x -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/swig -I/tmp/gnuradio-3.2.2/gnuradio-core/src/li
b/hier -I/tmp/gnuradio-3.2.2/gnuradio-core/src/lib/swig -I/usr/local/include -I/usr/local/include -I/tmp/gnuradio-3.2.2/gruel/src/include -
I/tmp/gnuradio-3.2.2/gruel/src/include -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -g -O1 -Wno-strict-alia
sing -Wno-parentheses -D_THREAD_SAFE -MT _audio_osx_la-audio_osx_sink.lo -MD -MP -MF .deps/_audio_osx_la-audio_osx_sink.Tpo -c audio_osx_si
nk.cc -fno-common -DPIC -o .libs/_audio_osx_la-audio_osx_sink.o
audio_osx_sink.cc: In constructor 'audio_osx_sink::audio_osx_sink(int, std::string, bool, int, int)':
audio_osx_sink.cc:101: error: 'ComponentDescription' was not declared in this scope
audio_osx_sink.cc:101: error: expected `;' before 'desc'
audio_osx_sink.cc:102: error: 'desc' was not declared in this scope
audio_osx_sink.cc:108: error: 'Component' was not declared in this scope
audio_osx_sink.cc:108: error: expected `;' before 'comp'
audio_osx_sink.cc:109: error: 'comp' was not declared in this scope
audio_osx_sink.cc:114: error: 'comp' was not declared in this scope
audio_osx_sink.cc:114: error: 'OpenAComponent' was not declared in this scope
audio_osx_sink.cc:115: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc:129: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc:153: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc:159: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc:166: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc: In member function 'bool audio_osx_sink::IsRunning()':
audio_osx_sink.cc:188: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc: In member function 'virtual bool audio_osx_sink::start()':
audio_osx_sink.cc:198: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc: In member function 'virtual bool audio_osx_sink::stop()':
audio_osx_sink.cc:208: warning: format '%ld' expects type 'long int', but argument 4 has type 'OSStatus'
audio_osx_sink.cc: In destructor 'virtual audio_osx_sink::~audio_osx_sink()':
audio_osx_sink.cc:223: error: 'CloseComponent' was not declared in this scope
./circular_buffer.h: In member function 'int circular_buffer<T>::enqueue(T*, UInt32) [with T = float]':
audio_osx_sink.cc:306: instantiated from here
./circular_buffer.h:155: warning: format '%ld' expects type 'long int', but argument 3 has type 'UInt32'
./circular_buffer.h:155: warning: format '%ld' expects type 'long int', but argument 4 has type 'UInt32'
./circular_buffer.h: In member function 'int circular_buffer<T>::dequeue(T*, UInt32*) [with T = float]':
audio_osx_sink.cc:369: instantiated from here
./circular_buffer.h:247: warning: format '%ld' expects type 'long int', but argument 3 has type 'UInt32'
./circular_buffer.h:247: warning: format '%ld' expects type 'long int', but argument 4 has type 'UInt32'make[4]: *** [_audio_osx_la-audio_osx_sink.lo] Error 1
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] GL sinks freeze
Thanks Josh -- ended up finding the same thing right around the same time. =) Wonder why Python wouldn't print the error message to stderr. The diff fixes the problem for me as well. I'll take a look at switching back to using numpy.choose, although the for loop seems to work fine for now.
--n
> Date: Sat, 26 Dec 2009 22:52:04 -0500
> From: josh@joshknows.com
> To: bistromat@hotmail.com
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GL sinks freeze
>
> I fixed it on my computer, it seems numpy.choose changed implementation
> since the upgrade to 9.10 (or maybe i was misusing it). I replaced the
> numpy.choose call with a python for loop. Its probably slower than a
> numpy table look up. But lets just see if this also fixes the problem
> for you.
>
> It seems the gnuradio.org server is on vacation again. Attached is the
> diff, try it out.
>
> -Josh
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign up now.
--n
> Date: Sat, 26 Dec 2009 22:52:04 -0500
> From: josh@joshknows.com
> To: bistromat@hotmail.com
> CC: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GL sinks freeze
>
> I fixed it on my computer, it seems numpy.choose changed implementation
> since the upgrade to 9.10 (or maybe i was misusing it). I replaced the
> numpy.choose call with a python for loop. Its probably slower than a
> numpy table look up. But lets just see if this also fixes the problem
> for you.
>
> It seems the gnuradio.org server is on vacation again. Attached is the
> diff, try it out.
>
> -Josh
Hotmail: Trusted email with Microsoft's powerful SPAM protection. Sign up now.
Re: [Discuss-gnuradio] Issues with porting a radio design to USRP2
On 12/29/2009 10:49 AM, Charles Irick wrote:
> Hello,
> I'm currently trying to port a radio design to the USRP2 platform but
> I am having a few issues. The current radio hardware contains a DAC
> with variable sampling rates allowing for it to be a multiple of the
> bitrate. It is currently using an IF of 60Mhz and a bitrate of 6Mbps.
> I'm wondering if there are any utilities the USRP2 provides for
> designing radios where the sampling rate and bitrate are not
> multiples, such as a DDS, given that the sampling rate is locked to
> 100MS/s. Thanks in advance.
> Hello,
> I'm currently trying to port a radio design to the USRP2 platform but
> I am having a few issues. The current radio hardware contains a DAC
> with variable sampling rates allowing for it to be a multiple of the
> bitrate. It is currently using an IF of 60Mhz and a bitrate of 6Mbps.
> I'm wondering if there are any utilities the USRP2 provides for
> designing radios where the sampling rate and bitrate are not
> multiples, such as a DDS, given that the sampling rate is locked to
> 100MS/s. Thanks in advance.
We do have all sorts of DDS modules in the FPGA and in software, but
that will only change the center frequency, not sample rate.
There are many resampling options in GNU Radio. There are polyphase
resamplers, rational resamplers, arbitrary resamplers, etc. There is
also timing recovery.
While it is often convenient to have a hardware sample rate which is an
integer number of symbols on the transmit side, you will usually still
need to resample on the receive side for timing recovery.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Issues with porting a radio design to USRP2
Hello,
I'm currently trying to port a radio design to the USRP2 platform but
I am having a few issues. The current radio hardware contains a DAC
with variable sampling rates allowing for it to be a multiple of the
bitrate. It is currently using an IF of 60Mhz and a bitrate of 6Mbps.
I'm wondering if there are any utilities the USRP2 provides for
designing radios where the sampling rate and bitrate are not
multiples, such as a DDS, given that the sampling rate is locked to
100MS/s. Thanks in advance.
I'm currently trying to port a radio design to the USRP2 platform but
I am having a few issues. The current radio hardware contains a DAC
with variable sampling rates allowing for it to be a multiple of the
bitrate. It is currently using an IF of 60Mhz and a bitrate of 6Mbps.
I'm wondering if there are any utilities the USRP2 provides for
designing radios where the sampling rate and bitrate are not
multiples, such as a DDS, given that the sampling rate is locked to
100MS/s. Thanks in advance.
Charles
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SD card failure
On 12/29/2009 01:30 AM, Gaetano Mendola wrote:
> Hi all,
> I was affected by the SD card failure announced on Ettus site (got some
> devices not working).
>
> I have a questions, my local store doesn't have SD cards, but only
> SDHC cards (4GB), will those work as well ?
> Hi all,
> I was affected by the SD card failure announced on Ettus site (got some
> devices not working).
>
> I have a questions, my local store doesn't have SD cards, but only
> SDHC cards (4GB), will those work as well ?
SDHC cards will not work. Only SD.
> I have some remarks to do as well, I hope Ettus will take those in consideration
> to improve their procedures.
>
> An email to all people that bought the usrp2 lately would have been better than
> only a "news" on Ettus home page.
I sent an email to this mailing list. I considered an email to all
recent customers of the USRP2, but decided against it because most of
the email addresses we have are for purchasing departments, not end
users, but perhaps should have sent one. Also, since good and bad cards
were mixed in the same batch, we don't know who has the bad ones.
> The instructions at
>
> http://gnuradio.org/trac/wiki/USRP2UserFAQ#HowdoIchangethefirmwareandfpgacodeontheSDCard
>
> reported on that announcement are not complete; there is no mention on the fact
> that in order to build the firmware you need the microblaze compiler,
> and even that
> isn't written where to find it, I found it with a bit of luck at:
> http://gnuradio.org/tools,
> also there is no mention on how to install it. Anyway after having
> installed it, and
> successfully compiled the firmware, I found that at the link:
>
> http://gnuradio.org/releases/usrp2-bin/trunk/
>
> is already compiled and ready to be installed :(
The wiki documentation is a little thin, I agree. I have applied some
of your suggestions to that page.
Thank you for your feedback and suggestions.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SD card failure
I've just tried it and it doesnt work here using a 4gb card. I guess the CPLD has been configured (or doesnt support SDHC) to only use SD addressing..
On the other remarks, an email did goto this mailing list - thats how I found out about the problem.
The link to the binary image files is in the instructions you linked to under "How do I change the firmware and fpga code on the SD Card?".
Instructions (and a link to the compiler source) on how to compile your own version of the firmware are on the same page at "How do I compile the firmware for the aeMB RISC processor?" I think some changes are necessary to compile mb-gcc on 64bit, I've been avoiding this with a 32bit virtual machine..
The binary versions are probably the better option unless your doing something which requires modifying the firmware (which probably means going through the fun of getting Xilinx ISE to work..)
All of these remarks would probably have been better of in a seperate email to Ettus rather than the mailing list, I've found them very helpful and forgiving with questions where I've identified bugs by forgetting basic DSP or have had problems with orders.
-
Tim
On the other remarks, an email did goto this mailing list - thats how I found out about the problem.
The link to the binary image files is in the instructions you linked to under "How do I change the firmware and fpga code on the SD Card?".
Instructions (and a link to the compiler source) on how to compile your own version of the firmware are on the same page at "How do I compile the firmware for the aeMB RISC processor?" I think some changes are necessary to compile mb-gcc on 64bit, I've been avoiding this with a 32bit virtual machine..
The binary versions are probably the better option unless your doing something which requires modifying the firmware (which probably means going through the fun of getting Xilinx ISE to work..)
All of these remarks would probably have been better of in a seperate email to Ettus rather than the mailing list, I've found them very helpful and forgiving with questions where I've identified bugs by forgetting basic DSP or have had problems with orders.
-
Tim
On Tue, Dec 29, 2009 at 9:30 AM, Gaetano Mendola <mendola@gmail.com> wrote:
I have a questions, my local store doesn't have SD cards, but only
SDHC cards (4GB), will those work as well ?
I have some remarks to do as well, I hope Ettus will take those in consideration
to improve their procedures.
An email to all people that bought the usrp2 lately would have been better than
only a "news" on Ettus home page.
The instructions at
http://gnuradio.org/trac/wiki/USRP2UserFAQ#HowdoIchangethefirmwareandfpgacodeontheSDCard
reported on that announcement are not complete; there is no mention on the fact
that in order to build the firmware you need the microblaze compiler,
and even that
isn't written where to find it, I found it with a bit of luck at:
http://gnuradio.org/tools,
also there is no mention on how to install it. Anyway after having
installed it, and
successfully compiled the firmware, I found that at the link:
http://gnuradio.org/releases/usrp2-bin/trunk/
is already compiled and ready to be installed :(
Regards
Gaetano Mendola
--
cpp-today.blogspot.com
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SD card failure
Hi all,
I was affected by the SD card failure announced on Ettus site (got some
devices not working).
I was affected by the SD card failure announced on Ettus site (got some
devices not working).
I have a questions, my local store doesn't have SD cards, but only
SDHC cards (4GB), will those work as well ?
I have some remarks to do as well, I hope Ettus will take those in consideration
to improve their procedures.
An email to all people that bought the usrp2 lately would have been better than
only a "news" on Ettus home page.
The instructions at
http://gnuradio.org/trac/wiki/USRP2UserFAQ#HowdoIchangethefirmwareandfpgacodeontheSDCard
reported on that announcement are not complete; there is no mention on the fact
that in order to build the firmware you need the microblaze compiler,
and even that
isn't written where to find it, I found it with a bit of luck at:
http://gnuradio.org/tools,
also there is no mention on how to install it. Anyway after having
installed it, and
successfully compiled the firmware, I found that at the link:
http://gnuradio.org/releases/usrp2-bin/trunk/
is already compiled and ready to be installed :(
Regards
Gaetano Mendola
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Monday, December 28, 2009
Re: [Discuss-gnuradio] Error when install wxPython in cygwin
read the error verbose: /build-local does not exist
$WXDIR must be set to a blank string
-Josh
Makmur Hidayat wrote:
> Dear all,
>
> I am new in gnu radio. Now I am installing gnu radio under cygwin. I can
> install cygwin successfully. Then I install fftw-3.2.2.tar.gz. It is also
> successfully. Then I am trying to install wxPyton, but there is error. The
> error is shown below. What is the solution? Thank you for your help.
>
> Makmur
>
> Acer@acer-b1acd3afa0 /usr/src
> $ tar -jxf wxPython-src-2.8.10.1.tar.bz2
>
> Acer@acer-b1acd3afa0 /usr/src
> $ cd $WXDIR
>
> Acer@acer-b1acd3afa0 ~
> $ mkdir build-local
>
> Acer@acer-b1acd3afa0 ~
> $ cd $WXDIR/build-local
> bash: cd: /build-local: No such file or directory
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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] Error when install wxPython in cygwin
Dear all,
I am new in gnu radio. Now I am installing gnu radio under cygwin. I can install cygwin successfully. Then I install fftw-3.2.2.tar.gz. It is also successfully. Then I am trying to install wxPyton, but there is error. The error is shown below. What is the solution? Thank you for your help.
Makmur
Acer@acer-b1acd3afa0 /usr/src
$ tar -jxf wxPython-src-2.8.10.1.tar.bz2
Acer@acer-b1acd3afa0 /usr/src
$ cd $WXDIR
Acer@acer-b1acd3afa0 ~
$ mkdir build-local
Acer@acer-b1acd3afa0 ~
$ cd $WXDIR/build-local
bash: cd: /build-local: No such file or directory
I am new in gnu radio. Now I am installing gnu radio under cygwin. I can install cygwin successfully. Then I install fftw-3.2.2.tar.gz. It is also successfully. Then I am trying to install wxPyton, but there is error. The error is shown below. What is the solution? Thank you for your help.
Makmur
Acer@acer-b1acd3afa0 /usr/src
$ tar -jxf wxPython-src-2.8.10.1.tar.bz2
Acer@acer-b1acd3afa0 /usr/src
$ cd $WXDIR
Acer@acer-b1acd3afa0 ~
$ mkdir build-local
Acer@acer-b1acd3afa0 ~
$ cd $WXDIR/build-local
bash: cd: /build-local: No such file or directory
Re: [Discuss-gnuradio] USRP2 VRT support
yes, of course
http://www.ettus.com/usrp2_vrt
Eric Blossom wrote:
> On Mon, Dec 28, 2009 at 05:21:36PM -0500, Josh Blum wrote:
>> Tim Pearce wrote:
>>> Josh,
>>>
>>> The USRP2 doesn't respond when loaded with the firmware at:
>>> http://www.ettus.com/usrp2_vrt
>>>
>>> I've just run find_usrps -e eth1 with wireshark running and can only see the
>>> outgoing packet:
>>>
>>> 1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
>>>
>>> Given the transport type is the old (I think) 0xbeef I guess this is wrong,
>>> I'm just about to recheckout the source code and compile again, but "vrt" is
>>> a directory present in where I compiled gnuradio from - I've just double
>>> checked by:
>>>
>> The vrt directory was there prior to this work. A good way to verify
>> that you pulled in the right branch would be to check
>> usrp2/firmware/include/usrp2_eth_packet.h and see that it has the
>> following defines:
>>
>> #define U2_DATA_ETHERTYPE 0xBEEF // used in our data frames
>> #define U2_CTRL_ETHERTYPE 0xBEF0 // used in our control frames
>>
>> Thats where the firmware and host code gets the ethernet transport
>> type from.
>>
>> -Josh
>
> Josh,
>
> Did you post a copy of the FPGA image? They'll need that for any of
> this stuff to work ;-)
>
> Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 VRT support
Josh,
Thanks for the help, I'd checked out the wrong version!
I haven't used git before/didn't realise it was a branch so I just ran "git clone http://gnuradio.org/git/jblum.git" and compiled
In case anyone else gets stuck with the same issue - after running this command changing branches seemed to sort everything out for me:
(from jblum/)
git checkout origin/usrp2_vrt
git checkout -b usrp2_vrt
I need to go and read up on the new non-cvs style systems :)
Cheers,
Tim
git clone http://gnuradio.org/git/jblum.git usrp2_vrt
Thanks for the help, I'd checked out the wrong version!
I haven't used git before/didn't realise it was a branch so I just ran "git clone http://gnuradio.org/git/jblum.git" and compiled
In case anyone else gets stuck with the same issue - after running this command changing branches seemed to sort everything out for me:
(from jblum/)
git checkout origin/usrp2_vrt
git checkout -b usrp2_vrt
I need to go and read up on the new non-cvs style systems :)
Cheers,
Tim
git clone http://gnuradio.org/git/jblum.git usrp2_vrt
On Mon, Dec 28, 2009 at 10:21 PM, Josh Blum <josh@ettus.com> wrote:
Tim Pearce wrote:The vrt directory was there prior to this work. A good way to verify that you pulled in the right branch would be to check
Josh,
The USRP2 doesn't respond when loaded with the firmware at:
http://www.ettus.com/usrp2_vrt
I've just run find_usrps -e eth1 with wireshark running and can only see the
outgoing packet:
1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
Given the transport type is the old (I think) 0xbeef I guess this is wrong,
I'm just about to recheckout the source code and compile again, but "vrt" is
a directory present in where I compiled gnuradio from - I've just double
checked by:
usrp2/firmware/include/usrp2_eth_packet.h and see that it has the following defines:
#define U2_DATA_ETHERTYPE 0xBEEF // used in our data frames
#define U2_CTRL_ETHERTYPE 0xBEF0 // used in our control frames
Thats where the firmware and host code gets the ethernet transport type from.
-Josh
Re: [Discuss-gnuradio] USRP2 VRT support
On Mon, Dec 28, 2009 at 05:21:36PM -0500, Josh Blum wrote:
> Tim Pearce wrote:
> >Josh,
> >
> >The USRP2 doesn't respond when loaded with the firmware at:
> >http://www.ettus.com/usrp2_vrt
> >
> >I've just run find_usrps -e eth1 with wireshark running and can only see the
> >outgoing packet:
> >
> >1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
> >
> >Given the transport type is the old (I think) 0xbeef I guess this is wrong,
> >I'm just about to recheckout the source code and compile again, but "vrt" is
> >a directory present in where I compiled gnuradio from - I've just double
> >checked by:
> >
>
> The vrt directory was there prior to this work. A good way to verify
> that you pulled in the right branch would be to check
> usrp2/firmware/include/usrp2_eth_packet.h and see that it has the
> following defines:
>
> #define U2_DATA_ETHERTYPE 0xBEEF // used in our data frames
> #define U2_CTRL_ETHERTYPE 0xBEF0 // used in our control frames
>
> Thats where the firmware and host code gets the ethernet transport
> type from.
>
> -Josh
> Tim Pearce wrote:
> >Josh,
> >
> >The USRP2 doesn't respond when loaded with the firmware at:
> >http://www.ettus.com/usrp2_vrt
> >
> >I've just run find_usrps -e eth1 with wireshark running and can only see the
> >outgoing packet:
> >
> >1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
> >
> >Given the transport type is the old (I think) 0xbeef I guess this is wrong,
> >I'm just about to recheckout the source code and compile again, but "vrt" is
> >a directory present in where I compiled gnuradio from - I've just double
> >checked by:
> >
>
> The vrt directory was there prior to this work. A good way to verify
> that you pulled in the right branch would be to check
> usrp2/firmware/include/usrp2_eth_packet.h and see that it has the
> following defines:
>
> #define U2_DATA_ETHERTYPE 0xBEEF // used in our data frames
> #define U2_CTRL_ETHERTYPE 0xBEF0 // used in our control frames
>
> Thats where the firmware and host code gets the ethernet transport
> type from.
>
> -Josh
Josh,
Did you post a copy of the FPGA image? They'll need that for any of
this stuff to work ;-)
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 VRT support
Tim Pearce wrote:
> Josh,
>
> The USRP2 doesn't respond when loaded with the firmware at:
> http://www.ettus.com/usrp2_vrt
>
> I've just run find_usrps -e eth1 with wireshark running and can only see the
> outgoing packet:
>
> 1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
>
> Given the transport type is the old (I think) 0xbeef I guess this is wrong,
> I'm just about to recheckout the source code and compile again, but "vrt" is
> a directory present in where I compiled gnuradio from - I've just double
> checked by:
>
> Josh,
>
> The USRP2 doesn't respond when loaded with the firmware at:
> http://www.ettus.com/usrp2_vrt
>
> I've just run find_usrps -e eth1 with wireshark running and can only see the
> outgoing packet:
>
> 1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
>
> Given the transport type is the old (I think) 0xbeef I guess this is wrong,
> I'm just about to recheckout the source code and compile again, but "vrt" is
> a directory present in where I compiled gnuradio from - I've just double
> checked by:
>
The vrt directory was there prior to this work. A good way to verify
that you pulled in the right branch would be to check
usrp2/firmware/include/usrp2_eth_packet.h and see that it has the
following defines:
#define U2_DATA_ETHERTYPE 0xBEEF // used in our data frames
#define U2_CTRL_ETHERTYPE 0xBEF0 // used in our control frames
Thats where the firmware and host code gets the ethernet transport type
from.
-Josh
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 VRT support
Josh,
The USRP2 doesn't respond when loaded with the firmware at: http://www.ettus.com/usrp2_vrt
I've just run find_usrps -e eth1 with wireshark running and can only see the outgoing packet:
1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
Given the transport type is the old (I think) 0xbeef I guess this is wrong, I'm just about to recheckout the source code and compile again, but "vrt" is a directory present in where I compiled gnuradio from - I've just double checked by:
make uninstall
check /usr/lib/python2.6/dist-packages/gnuradio/ doesnt exist/have anything in it (fresh install of ubuntu so I've only tried to compile this version on it too, there shouldnt be any non /usr prefix locations)
make clean
./configure --prefix=/usr (result = Configured GNU Radio release 3.3git-75429993 for build.)
make
sudo make install
sudo chmod +s /usr/bin/usrp2_socket_opener
find_usrps -e eth1 (I've tried running the non make installed compiled versions in usrp2/host/apps with the same result)
and I still see the old transport type on the outgoing message (which would explain why it still worked when I used an older firmware version I guess?)
Annoyingly I don't have a TTL cable at home but will double check I get the standard verbose whilst booting tomorrow.
Cheers,
The USRP2 doesn't respond when loaded with the firmware at: http://www.ettus.com/usrp2_vrt
I've just run find_usrps -e eth1 with wireshark running and can only see the outgoing packet:
1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
Given the transport type is the old (I think) 0xbeef I guess this is wrong, I'm just about to recheckout the source code and compile again, but "vrt" is a directory present in where I compiled gnuradio from - I've just double checked by:
make uninstall
check /usr/lib/python2.6/dist-packages/gnuradio/ doesnt exist/have anything in it (fresh install of ubuntu so I've only tried to compile this version on it too, there shouldnt be any non /usr prefix locations)
make clean
./configure --prefix=/usr (result = Configured GNU Radio release 3.3git-75429993 for build.)
make
sudo make install
sudo chmod +s /usr/bin/usrp2_socket_opener
find_usrps -e eth1 (I've tried running the non make installed compiled versions in usrp2/host/apps with the same result)
and I still see the old transport type on the outgoing message (which would explain why it still worked when I used an older firmware version I guess?)
Annoyingly I don't have a TTL cable at home but will double check I get the standard verbose whilst booting tomorrow.
Cheers,
On Mon, Dec 28, 2009 at 9:32 PM, Josh Blum <josh@ettus.com> wrote:
Along with the vrt changes, the raw ethernet protocol number has been changed for the control packets. You must run the matching host code and the firmware from the branch or it wont work. The firmware and fpga files on that link were also built and tested from this branch.
Can you run wireshark and see what packets go in and out when you run find_usrps? You should see a broadcast packet going out and a packet coming back from the usrp2. The 2 byte transport type should read BEFO in hex.
-JoshIt should print out the standard booting verbose over the serial terminal. This will make sure that at least the usrp2 microblaze is booting.
Tim Pearce wrote:
Looking through the header files this looks really useful, thanks for the
hard work guys :)
I'm having some problems getting it to work though, I've downloaded the
firmware/fpga builds from the link and with these running python/find_usrps
isnt able to find the usrp2 - its fine with the latest non-vrt firmware. The
leds flash and then the bottom right 2 leds come on. I've had a quick look
and I think find_usrps/usrp2.source_32fc should still work.
I haven't tried using firmware compiled from the git repository yet so I'll
try that and try connecting with a TTL cable attached to the debug port
tomorrow unless anyone else has a similar problem/ideas?
-Josh
(Unfortunately I've only got access to the latest Xilinx ISE which I
understand (as ever) breaks compatability with fpga code written for
previous versions. I havent had much luck synthesising with it so far
anyway, although I've only really done a quick try so far -- so I cant try
making my own fpga file as well)
Cheers,
Tim
On Wed, Dec 23, 2009 at 4:12 PM, Josh Blum <josh@ettus.com> wrote:
i pushed the patch, thanks!
-Josh
Doug Geiger wrote:
Josh Blum wrote:_______________________________________________
Folks,getting compilation errors - it looks like the vrt-related headers aren't
There has been much work in the past few months to get the VITA Radio
Transport (VRT) protocol working with the USRP2. You can read more about
the protocol here: http://www.digitalif.org/
The branch containing this work can be found on my usrp2_vrt branch:
http://gnuradio.org/cgit/jblum.git/log/?h=usrp2_vrt
Hmmm, not sure if it's due to a git-related mistake on my end, but I'm
getting the right -I line in the Makefile somehow
error: vrt/rx_packet_handler.h: No such file or directory
Looks like the $(VRT_INCLUDES) didn't make it into the
usrp2/apps/Makefile.am line for AM_CPPFLAGS?
usrp2/lib/Makefile.am has it though, and built correctly.
Hmmm, looks like it might need to be in gr-usrp2/src/Makefile.am as well.
That built at least - I'll report back once I update the SD cards and can
do some tests with them. Diff attached below:
diff --git a/gr-usrp2/src/Makefile.am b/gr-usrp2/src/Makefile.am
index 8425c49..cc37b23 100644
--- a/gr-usrp2/src/Makefile.am
+++ b/gr-usrp2/src/Makefile.am
@@ -46,6 +46,7 @@ AM_CPPFLAGS = \
$(GRUEL_INCLUDES) \
$(PYTHON_CPPFLAGS) \
$(USRP2_INCLUDES) \
+ $(VRT_INCLUDES) \
$(WITH_INCLUDES)
lib_LTLIBRARIES = libgnuradio-usrp2.la
diff --git a/usrp2/apps/Makefile.am b/usrp2/apps/Makefile.am
index 453a612..dc5800a 100644
--- a/usrp2/apps/Makefile.am
+++ b/usrp2/apps/Makefile.am
@@ -19,6 +19,7 @@ include $(top_srcdir)/Makefile.common
AM_CPPFLAGS = \
$(USRP2_INCLUDES) \
+ $(VRT_INCLUDES) \
$(STD_DEFINES_AND_INCLUDES) \
$(CPPUNIT_INCLUDES) \
$(GRUEL_INCLUDES)
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 VRT support
Along with the vrt changes, the raw ethernet protocol number has been
changed for the control packets. You must run the matching host code and
the firmware from the branch or it wont work. The firmware and fpga
files on that link were also built and tested from this branch.
changed for the control packets. You must run the matching host code and
the firmware from the branch or it wont work. The firmware and fpga
files on that link were also built and tested from this branch.
Can you run wireshark and see what packets go in and out when you run
find_usrps? You should see a broadcast packet going out and a packet
coming back from the usrp2. The 2 byte transport type should read BEFO
in hex.
-Josh
Tim Pearce wrote:
> Looking through the header files this looks really useful, thanks for the
> hard work guys :)
>
> I'm having some problems getting it to work though, I've downloaded the
> firmware/fpga builds from the link and with these running python/find_usrps
> isnt able to find the usrp2 - its fine with the latest non-vrt firmware. The
> leds flash and then the bottom right 2 leds come on. I've had a quick look
> and I think find_usrps/usrp2.source_32fc should still work.
>
> I haven't tried using firmware compiled from the git repository yet so I'll
> try that and try connecting with a TTL cable attached to the debug port
> tomorrow unless anyone else has a similar problem/ideas?
>
It should print out the standard booting verbose over the serial
terminal. This will make sure that at least the usrp2 microblaze is booting.
-Josh
> (Unfortunately I've only got access to the latest Xilinx ISE which I
> understand (as ever) breaks compatability with fpga code written for
> previous versions. I havent had much luck synthesising with it so far
> anyway, although I've only really done a quick try so far -- so I cant try
> making my own fpga file as well)
>
> Cheers,
>
> Tim
>
> On Wed, Dec 23, 2009 at 4:12 PM, Josh Blum <josh@ettus.com> wrote:
>
>> i pushed the patch, thanks!
>>
>> -Josh
>>
>>
>> Doug Geiger wrote:
>>
>>> Josh Blum wrote:
>>>
>>>> Folks,
>>>>
>>>> There has been much work in the past few months to get the VITA Radio
>>>> Transport (VRT) protocol working with the USRP2. You can read more about
>>>> the protocol here: http://www.digitalif.org/
>>>>
>>>> The branch containing this work can be found on my usrp2_vrt branch:
>>>> http://gnuradio.org/cgit/jblum.git/log/?h=usrp2_vrt
>>>>
>>>>
>>>> Hmmm, not sure if it's due to a git-related mistake on my end, but I'm
>>> getting compilation errors - it looks like the vrt-related headers aren't
>>> getting the right -I line in the Makefile somehow
>>> error: vrt/rx_packet_handler.h: No such file or directory
>>>
>>> Looks like the $(VRT_INCLUDES) didn't make it into the
>>> usrp2/apps/Makefile.am line for AM_CPPFLAGS?
>>> usrp2/lib/Makefile.am has it though, and built correctly.
>>> Hmmm, looks like it might need to be in gr-usrp2/src/Makefile.am as well.
>>>
>>> That built at least - I'll report back once I update the SD cards and can
>>> do some tests with them. Diff attached below:
>>>
>>> diff --git a/gr-usrp2/src/Makefile.am b/gr-usrp2/src/Makefile.am
>>> index 8425c49..cc37b23 100644
>>> --- a/gr-usrp2/src/Makefile.am
>>> +++ b/gr-usrp2/src/Makefile.am
>>> @@ -46,6 +46,7 @@ AM_CPPFLAGS = \
>>> $(GRUEL_INCLUDES) \
>>> $(PYTHON_CPPFLAGS) \
>>> $(USRP2_INCLUDES) \
>>> + $(VRT_INCLUDES) \
>>> $(WITH_INCLUDES)
>>>
>>> lib_LTLIBRARIES = libgnuradio-usrp2.la
>>> diff --git a/usrp2/apps/Makefile.am b/usrp2/apps/Makefile.am
>>> index 453a612..dc5800a 100644
>>> --- a/usrp2/apps/Makefile.am
>>> +++ b/usrp2/apps/Makefile.am
>>> @@ -19,6 +19,7 @@ include $(top_srcdir)/Makefile.common
>>>
>>> AM_CPPFLAGS = \
>>> $(USRP2_INCLUDES) \
>>> + $(VRT_INCLUDES) \
>>> $(STD_DEFINES_AND_INCLUDES) \
>>> $(CPPUNIT_INCLUDES) \
>>> $(GRUEL_INCLUDES)
>>>
>>>
>> _______________________________________________
>> 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] USRP2 VRT support
Looking through the header files this looks really useful, thanks for the hard work guys :)
I'm having some problems getting it to work though, I've downloaded the firmware/fpga builds from the link and with these running python/find_usrps isnt able to find the usrp2 - its fine with the latest non-vrt firmware. The leds flash and then the bottom right 2 leds come on. I've had a quick look and I think find_usrps/usrp2.source_32fc should still work.
I haven't tried using firmware compiled from the git repository yet so I'll try that and try connecting with a TTL cable attached to the debug port tomorrow unless anyone else has a similar problem/ideas?
(Unfortunately I've only got access to the latest Xilinx ISE which I understand (as ever) breaks compatability with fpga code written for previous versions. I havent had much luck synthesising with it so far anyway, although I've only really done a quick try so far -- so I cant try making my own fpga file as well)
Cheers,
Tim
I'm having some problems getting it to work though, I've downloaded the firmware/fpga builds from the link and with these running python/find_usrps isnt able to find the usrp2 - its fine with the latest non-vrt firmware. The leds flash and then the bottom right 2 leds come on. I've had a quick look and I think find_usrps/usrp2.source_32fc should still work.
I haven't tried using firmware compiled from the git repository yet so I'll try that and try connecting with a TTL cable attached to the debug port tomorrow unless anyone else has a similar problem/ideas?
(Unfortunately I've only got access to the latest Xilinx ISE which I understand (as ever) breaks compatability with fpga code written for previous versions. I havent had much luck synthesising with it so far anyway, although I've only really done a quick try so far -- so I cant try making my own fpga file as well)
Cheers,
Tim
On Wed, Dec 23, 2009 at 4:12 PM, Josh Blum <josh@ettus.com> wrote:
i pushed the patch, thanks!
-Josh
Doug Geiger wrote:
Josh Blum wrote:
Folks,Hmmm, not sure if it's due to a git-related mistake on my end, but I'm getting compilation errors - it looks like the vrt-related headers aren't getting the right -I line in the Makefile somehow
There has been much work in the past few months to get the VITA Radio
Transport (VRT) protocol working with the USRP2. You can read more about
the protocol here: http://www.digitalif.org/
The branch containing this work can be found on my usrp2_vrt branch:
http://gnuradio.org/cgit/jblum.git/log/?h=usrp2_vrt
error: vrt/rx_packet_handler.h: No such file or directory
Looks like the $(VRT_INCLUDES) didn't make it into the usrp2/apps/Makefile.am line for AM_CPPFLAGS?
usrp2/lib/Makefile.am has it though, and built correctly.
Hmmm, looks like it might need to be in gr-usrp2/src/Makefile.am as well.
That built at least - I'll report back once I update the SD cards and can do some tests with them. Diff attached below:
diff --git a/gr-usrp2/src/Makefile.am b/gr-usrp2/src/Makefile.am
index 8425c49..cc37b23 100644
--- a/gr-usrp2/src/Makefile.am
+++ b/gr-usrp2/src/Makefile.am
@@ -46,6 +46,7 @@ AM_CPPFLAGS = \
$(GRUEL_INCLUDES) \
$(PYTHON_CPPFLAGS) \
$(USRP2_INCLUDES) \
+ $(VRT_INCLUDES) \
$(WITH_INCLUDES)
lib_LTLIBRARIES = libgnuradio-usrp2.la
diff --git a/usrp2/apps/Makefile.am b/usrp2/apps/Makefile.am
index 453a612..dc5800a 100644
--- a/usrp2/apps/Makefile.am
+++ b/usrp2/apps/Makefile.am
@@ -19,6 +19,7 @@ include $(top_srcdir)/Makefile.common
AM_CPPFLAGS = \
$(USRP2_INCLUDES) \
+ $(VRT_INCLUDES) \
$(STD_DEFINES_AND_INCLUDES) \
$(CPPUNIT_INCLUDES) \
$(GRUEL_INCLUDES)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: git
git clone http://gnuradio.org/git/gnuradio.git
then if you are on osx,
in ./bootstrap,
replace litoolize by glibtoolize (add a "g" before)
C.
_________________________________________________________________
Téléchargez Internet Explorer 8 et surfez sans laisser de trace !
http://clk.atdmt.com/FRM/go/182932252/direct/01/
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About the MIMO tx/rx,
Hello all,
I am new to gnu radio and have a question regarding MIMO tx/rx. Though I've read many posts here and also read through m-block/inband code, I still don't have any idea on how to transmit two different streams via different daughter boards simultaneously (e.g., spatial multiplexing).
As far as I understand, the code basically works as follows.
1. Set the daughter board for tx using MUX (A or B or both A and B)
2. Schedule the packet transmission
Doing like this will cause every packet transmitted via same daughter board. However, I would like to specify a daughter board for each of the packets in order to implement spatial multiplexing of MIMO.. That is, I want packet X/Y to be transmitted via daughter board A/B at the same time, respectively. If you have any idea or some piece of code or links to the examples, please let me know. It will greatly help!
Many thanks in advance,
Sungro
Re: [Discuss-gnuradio] receiving HF radio using the IF radio output and USRP
On 12/28/2009 10:40 AM, Rafael Diniz wrote:
> Hi people,
> I'd like to test the DRM reception here in my home, but first I'll try AM
> reception.
> If I connect the 455kHz IF output of my radio in the BasicRx, to
> demodulate the signal (considering the radio is tunned in some radio) it's
> just a matter of running any of the AM python reception examples at 455kHz
> to listen a radio?
> Hi people,
> I'd like to test the DRM reception here in my home, but first I'll try AM
> reception.
> If I connect the 455kHz IF output of my radio in the BasicRx, to
> demodulate the signal (considering the radio is tunned in some radio) it's
> just a matter of running any of the AM python reception examples at 455kHz
> to listen a radio?
Yes.
Matt
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] receiving HF radio using the IF radio output and USRP
Hi people,
I'd like to test the DRM reception here in my home, but first I'll try AM
reception.
If I connect the 455kHz IF output of my radio in the BasicRx, to
demodulate the signal (considering the radio is tunned in some radio) it's
just a matter of running any of the AM python reception examples at 455kHz
to listen a radio?
I'd like to test the DRM reception here in my home, but first I'll try AM
reception.
If I connect the 455kHz IF output of my radio in the BasicRx, to
demodulate the signal (considering the radio is tunned in some radio) it's
just a matter of running any of the AM python reception examples at 455kHz
to listen a radio?
Thanks,
Rafael Diniz
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio.org down
On Mon, Dec 28, 2009 at 12:17:27PM +0000, Panos Μatzakos wrote:
> Hello,
>
> I'd like to ask what's wrong with gnuradio.org... Does anybody know when it is going to be up again?
>
> Hello,
>
> I'd like to ask what's wrong with gnuradio.org... Does anybody know when it is going to be up again?
>
The server is back up.
Johnathan and I will be spending the next couple of days implementing
a fix for the outages we've been seeing.
Please bear with us. I know this has been dragging on for a long while, but we
expect to get everything cut over to a new server in the next couple
of days.
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] need schematics of USRP and USRP 2
hi
GNURadio.org is down again. can any body send me schematics of USRP and USRP
2
i will be very grate full to u .
--
View this message in context: http://old.nabble.com/need-schematics-of-USRP-and-USRP-2-tp26943897p26943897.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] git
On 12/28/2009 11:55 AM, Bob McGwier wrote:
> The web site server serves git. We are all down.
> The web site server serves git. We are all down.
From the last time, try this:
git clone git://github.com/yootis/gnuradio-matt.git
This should get you a recent copy of gnuradio master. When the server
comes back, ask me how to edit .git/config to switch to the main server.
Philip
>
> Andreas Fink wrote:
>> can someone give me the exact command to check out gnuradio via git?
>> as the website is down, I'm stuck.
>>
>>
>>
>>
>> _______________________________________________
>> 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] git
The web site server serves git. We are all down.
Andreas Fink wrote:
> can someone give me the exact command to check out gnuradio via git?
> as the website is down, I'm stuck.
>
>
>
>
> _______________________________________________
> 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] git
can someone give me the exact command to check out gnuradio via git?
as the website is down, I'm stuck.
as the website is down, I'm stuck.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org down
| Hello, I'd like to ask what's wrong with gnuradio.org... Does anybody know when it is going to be up again? |
Χρησιμοποιείτε Yahoo!
Βαρεθήκατε τα ενοχλητικά μηνύ ματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων
http://login.yahoo.com/config/mail?.intl=gr
Sunday, December 27, 2009
[Discuss-gnuradio] GSM Handset Emulation
On Thu, Nov 19, 2009 at 5:00 PM, <discuss-gnuradio-request@gnu.org> wrote:
> 12. Re: GSM Handset Emulation (John Gilmore)
> 12. Re: GSM Handset Emulation (John Gilmore)
> Message: 12
> Date: Wed, 18 Nov 2009 22:08:21 -0800
> From: John Gilmore <gnu@toad.com>
> Subject: Re: [Discuss-gnuradio] GSM Handset Emulation
> To: Isaac Gerg <isaac.gerg@gergltd.com>
> Cc: Discuss-gnuradio@gnu.org
> Message-ID: <200911190608.nAJ68LC7009853@new.toad.com>
> It wouldn't be very convenient, since you'd have to have a USRP, plus
> antennas, dangling off your laptop.
that would suffice perfectly as a development platform, such that
then obtaining smaller lower-priced dedicated hardware, such as the
AD6720 (ARM7+DSP) and porting the USRP-developed softwawre, would be
an easier step.
the $40 to $50 cost of GSM "modules" is just too much. the present
situation is, thanks to the "proprietary" nature of GSM solutions,
that free software is entirely locked out of the low-cost options ($10
to $15) involving DSPs and baseband front-ends.
so - yah, regardless of how ridiculous it would look as a quotes
handset quotes it'd be a damn good start.
l.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Different modulation scheme between header and payload
Hello guys,
I try to modify the ./benchmark_tx/rx.py in gnuradio-examples/digital,
wish to set different modulation scheme for header and payload.
Ex: header with dBPSK modulation
payload with dQPSK modulation
I try to modify the ./benchmark_tx/rx.py in gnuradio-examples/digital,
wish to set different modulation scheme for header and payload.
Ex: header with dBPSK modulation
payload with dQPSK modulation
But I face some difficulties:
1.) We cannot extract arbitrary size of data for output
2.) Synchronization schemes are different among modulation schemes
(For we need to find header first, but after we find header,
we have dealt the payload with wrong synchronization scheme
already)
Could someone give me some advice about how to implement it?
I am deeply appreciative.
Fisheep :)
--
View this message in context: http://old.nabble.com/Different-modulation-scheme-between-header-and-payload-tp26934215p26934215.html
Sent from the GnuRadio mailing list archive at Nabble.com.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio.org not reachable
There's currently some kind of outage that's preventing gnuradio.org
from being reached. It's not confined to just our server. Other
large projects at the Univ of Utah are also off line.
from being reached. It's not confined to just our server. Other
large projects at the Univ of Utah are also off line.
More when I know more...
Eric
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: what is the function of whitener offset in make_packet ( ) ?
packet_util. make_packet(payload, samples_per_symbol, bits_per_symbol,
access_code=default_access_code, pad_for_usrp=True,
whitener_offset=0, whitening=True)
what is the role of whitener offset??
REGARDS,
M AHSAN LIAQAT
STUDENT TELECOMM ENGINEERING,
NUST, RWP PAKISTAN
> Date: Sat, 26 Dec 2009 12:00:27 -0500
> From: discuss-gnuradio-request@gnu.org
> Subject: Discuss-gnuradio Digest, Vol 85, Issue 26
> To: discuss-gnuradio@gnu.org
>
> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> discuss-gnuradio-request@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
> 1. Re: small question (abbasi9999)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 25 Dec 2009 15:43:28 -0800 (PST)
> From: abbasi9999 <abbasi9999@hotmail.com>
> Subject: Re: [Discuss-gnuradio] small question
> To: Discuss-gnuradio@gnu.org
> Message-ID: <26924493.post@talk.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> I want the source code so i can know what is the function of this class
> "gr_bin_statistics_f.cc". because in the API its not written clearly just
> like "control scanning and record frequency domain statistics".
> Thanks for the reply
>
>
> Josef Vukovic-3 wrote:
> >
> > 2009/12/25 abbasi9999 <abbasi9999@hotmail.com>
> >
> >>
> >> Hi all.
> >>
> >> can you please tell me where to find the source c code of the signal
> >> processing blocks which already installed in the OS.
> >>
> >
> > The blocks are probably not installed in the kernel. :-) On my system
> > Ubuntu karmic they are compiled as object code and archived in a library
> > in
> > /usr/local/lib/libgnuradio*
> >
> >
> >> my OS is Ubuntu 9.10 - the Karmic Koala -
> >> I found the source in the downloaded file gnuradio-3.2.2.tar.gz in this
> >> directory:
> >> /gnuradio-core/src/lib/general/gr_bin_statistics_f.cc
> >> but i cannot find the same directory in my OS.
> >>
> >
> > There is a directory called /usr/local/src in the filesystem. Maybe there?
> > Hm, what is it for?
> >
> >
> >> sorry for the trivial question but I'm still new.
> >>
> >>
> >> regards,
> >>
> >> --
> >> View this message in context:
> >> http://old.nabble.com/small-question-tp26919848p26919848.html
> >> Sent from the GnuRadio mailing list archive at Nabble.com.
> >>
> >>
> >>
> >> _______________________________________________
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> > regards
> > Josef Vukovic
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
>
> --
> View this message in context: http://old.nabble.com/small-question-tp26919848p26924493.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> End of Discuss-gnuradio Digest, Vol 85, Issue 26
> ************************************************
Windows Live: Keep your friends up to date with what you do online.
Subscribe to:
Posts (Atom)