[Discuss-gnuradio] data transfer
when i am trying to transfer data within the laptop , i am able to do it. but i could not achieve the same using usrp. my machine is detecting usrp properly. pls help.. also if i can get a flowgraph for data transfer which includes an routing block i'll be grateful.. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Modulation of tx_timed_samples in UHD
Hi, I have read the file tx_timed_samples.cpp. But it seems the data are sent without modulation.Is it correct? And why? Thanks in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] linking Gnuradio and Gpredict ?
Is it possible to link Gnuradio and Gpredict ? I want to use Gpredict as tracker controlling the antenna position and to pass doppler corrected frequency data to Gnuradio. Does any interface to Gpredict (or hamlib) exist ? thanks for any hints, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] linking Gnuradio and Gpredict ?
Hi, Gpredict is based on predict, which has several interfaces for Doppler prediction. Not sure if Gpredict inherited these interfaces. Yours Martin Am 22.07.2013 13:31, schrieb M Dammer: Is it possible to link Gnuradio and Gpredict ? I want to use Gpredict as tracker controlling the antenna position and to pass doppler corrected frequency data to Gnuradio. Does any interface to Gpredict (or hamlib) exist ? thanks for any hints, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] git check out fails
On Sun, Jul 21, 2013 at 9:47 PM, Matt D md...@nycap.rr.com wrote: git clone --verbose http://gnuradio.org/git/gnuradio.git I overlooked the fact the git will give to me version 3.7. this will not do. I need 3.6.3. so where i am at is here on the make test: Once you've cloned the GNU Radio repo, you can go to any version by checking out that version tag. In your case: $ git checkout v3.6.3 The following tests FAILED: 1 - qa_volk_test_all (Failed) Errors while running CTest make: *** [test] Error 8 does anyone know of a fix for this? Going to need more information here. What's your processor? OS? Which tests, exactly, fail (use 'ctest -V -R volk' to get this information)? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Network unreachable on Beaglebone Black
Hallo guys, I have installed gnuradio on Beaglebone black, which runs under Angstrom linux. uhd finding devices works good, and I am able to see my usrp1 device, but when I run uhd_rx_cfile i get following error: linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001-5ace684 Traceback (most recent call last): File /usr/bin/uhd_rx_cfile.py, line 143, in module tb = rx_cfile_block(options, filename) File /usr/bin/uhd_rx_cfile.py, line 51, in __init__ num_channels=1) File /usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 1831, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs) RuntimeError: Network is unreachable Can anybody tell what is the problem about? Thanks -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7 build failure ICE_ICESTORM-NOTFOUND etc.
On Sun, Jul 21, 2013 at 7:17 AM, Barry Jackson zen25...@zen.co.uk wrote:
On 20/07/13 15:11, Tom Rondeau wrote:
On Thu, Jul 18, 2013 at 11:23 AM, Barry Jackson zen25...@zen.co.uk
wrote:
On 18/07/13 15:19, Tom Rondeau wrote:
Do you know what version of ICE is installed on your system? GNU Radio
explicitly looks for version 3.4, so if you're using 3.5 it won't work
by default. I've tested and compiled against 3.5, though, so it's only
the cmake FindICE script that's the problem.
Also, ticket #564 is about faulty ICE detection, so this could also be
a problem with your system. I hope to work on this soon to resolve
that issue and make it easier to use either 3.4 or 3.5.
Tom
Hi Tom,
Ice version is 3.4.2.
Yes, #564 does look like the same issue except that it is reported on OSX
where I am seeing it in Linux.
Barry,
I just pushed branch 'cmake_ice' to my github repo
(github.com/trondeau/gnuradio). It does a better job of handling ICE,
the include dirs, and the required libs. It also adds the ability to
use Ice 3.5, which isn't important for you, though.
Could you check out this branch and give it a try? I'd like to know
how it works on other machines besides those which I've already gotten
things to work.
Thanks,
Tom
Tom,
No real change with your cmake_ice branch.
-- Configuring gnuradio-runtime support...
-- Dependency Boost_FOUND = 1
-- Dependency ENABLE_VOLK = ON
-- Dependency PYTHONINTERP_FOUND = TRUE
-- Enabling gnuradio-runtime support.
-- Override with -DENABLE_GNURADIO_RUNTIME=ON/OFF
-- package 'Ice-3.5' not found
-- ICE 3.5 not found. Looking for 3.4
-- package 'Ice-3.4' not found
--
-- Configuring gr-ctrlport support...
-- Dependency Boost_FOUND = 1
-- Dependency SWIG_FOUND = TRUE
-- Dependency SWIG_VERSION_CHECK = TRUE
-- Dependency ICE_FOUND =
-- Dependency ENABLE_GNURADIO_RUNTIME = ON
-- Disabling gr-ctrlport support.
Actually, it worked. This is now exactly what I had hoped to see. The
new cmake FindICE files look for everything that's needed to compile
ControlPort: the include directories, libIce, libeIceUtil, and the the
Python Ice module. If not all of these are found, it disables
gr-ctrlport.
The problem you had before was that it was finding everything, but
not really. So it enabled gr-ctrlport and cause a problem during make.
I looked at our Ice package spec and noticed that all the .pc files have
been packaged in ice-csharp-devel, which I think is wrong, however
installing that package as well makes no difference.
Yes. We don't care about C# at all. You'll need Ice for C++ and Python.
Looking in /usr/lib64/pkgconfig I find ice.pc AND Ice.pc
I initially thought that one would be a symlink to the other, but they are
different.
ice.pc is 1.0.8
Ice.pc is 3.4.2
ice.pc
--
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include
Name: ICE
Description: X Inter Client Exchange Library
Version: 1.0.8
Requires: xproto
Cflags: -I${includedir}
Libs: -L${libdir} -lICE
--
Ice.pc:
--
version = 3.4.2
mono_root = /usr
name = Ice
Name: ${name}
Description: Ice core run-time support
Version: ${version}
Libs: -r:${mono_root}/lib64/mono/${name}/${name}.dll
--
Maybe this helps?
Barry
What I'm used to seeing is a file Ice-3.4.pc, which is what the
pkg-config script in cmake is explicitly looking for. I'm completely
unfamiliar with Mageia as a distro, so you'll have to look to see what
packages you need to install for Ice support. Remember, in the end,
you'll need libIce.so, libIceUtil.so, the header files, and the
Pythong Ice module installed.
You can also use the ICE_MANUAL_INSTALL_PREFIX to point cmake to where
your Ice installations are, which works even if you don't have a .pc
file. When compiling and installing Ice 3.5.0 for my machine, there's
not pc file with this, but cmake still finds everything, anyways.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Doppler Radar Processing
Thanks, That is why I asked the question, I didn't know what is out there. Thanks, Frank -Original Message- From: Bruce Penswick [mailto:brucepensw...@yahoo.com] Sent: Sunday, July 21, 2013 10:55 AM To: Wallace, Frank L CIV NSWCDD, Q41; Adeel Anwar; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Doppler Radar Processing For your 2-D plotting, why don't you just use Matplotlib (http://matplotlib.org/) or Qwt (http://qwt.sourceforge.net/)?? Those two tools provide powerful plotting capabilities from Python and C++. Am I missing something? smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Network unreachable on Beaglebone Black
there is no such option args is the answer from app. hm, because it was in repo of angstrom linux, and I don't know If I can handle crosscompiling of newer version (is there any other way?) On Mon, Jul 22, 2013 at 5:52 PM, Marcus Leech mle...@ripnet.com wrote: really? So, if you uhd_rx_cfile --args type=usrp1 What happens? Why the horribly-out-of-date Gnu Radio? (And corresponding version of UHD?) on Jul 22, 2013, *Nemanja Savic* vlasi...@gmail.com wrote: But there is no option for that (type). it is gnuradio 3.4.3. On Mon, Jul 22, 2013 at 5:11 PM, Marcus Leech mle...@ripnet.com wrote: If you don't explicitly specify a device address, UHD will search through the defaults, including for an N2XX at 192.168.10.2. Just specify type=usrp1 in the the device args. on Jul 22, 2013, *Nemanja Savic* vlasi...@gmail.com wrote: Hallo guys, I have installed gnuradio on Beaglebone black, which runs under Angstrom linux. uhd finding devices works good, and I am able to see my usrp1 device, but when I run uhd_rx_cfile i get following error: linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001-5ace684 Traceback (most recent call last): File /usr/bin/uhd_rx_cfile.py, line 143, in module tb = rx_cfile_block(options, filename) File /usr/bin/uhd_rx_cfile.py, line 51, in __init__ num_channels=1) File /usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 1831, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs) RuntimeError: Network is unreachable Can anybody tell what is the problem about? Thanks -- Nemanja Savić -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Network unreachable on Beaglebone Black
really? So, if you uhd_rx_cfile --args "type=usrp1" What happens? Why the horribly-out-of-date Gnu Radio? (And corresponding version of UHD?) on Jul 22, 2013, Nemanja Savic vlasi...@gmail.com wrote: But there is no option for that (type). it is gnuradio 3.4.3. On Mon, Jul 22, 2013 at 5:11 PM, Marcus Leech mle...@ripnet.com wrote: If you don't explicitly specify a device address, UHD will search through the defaults, including for an N2XX at 192.168.10.2. Just specify "type=usrp1" in the the device args. on Jul 22, 2013, Nemanja Savic vlasi...@gmail.com wrote: Hallo guys, I have installed gnuradio on Beaglebone black, which runs under Angstrom linux. uhd finding devices works good, and I am able to see my usrp1 device, but when I run uhd_rx_cfile i get following error: linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001-5ace684 Traceback (most recent call last): File "/usr/bin/uhd_rx_cfile.py", line 143, in module tb = rx_cfile_block(options, filename) File "/usr/bin/uhd_rx_cfile.py", line 51, in __init__ num_channels=1) File "/usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py", line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File "/usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line 1831, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs)RuntimeError: Network is unreachable Can anybody tell what is the problem about? Thanks -- Nemanja Savić ___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Network unreachable on Beaglebone Black
But there is no option for that (type). it is gnuradio 3.4.3. On Mon, Jul 22, 2013 at 5:11 PM, Marcus Leech mle...@ripnet.com wrote: If you don't explicitly specify a device address, UHD will search through the defaults, including for an N2XX at 192.168.10.2. Just specify type=usrp1 in the the device args. on Jul 22, 2013, *Nemanja Savic* vlasi...@gmail.com wrote: Hallo guys, I have installed gnuradio on Beaglebone black, which runs under Angstrom linux. uhd finding devices works good, and I am able to see my usrp1 device, but when I run uhd_rx_cfile i get following error: linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001-5ace684 Traceback (most recent call last): File /usr/bin/uhd_rx_cfile.py, line 143, in module tb = rx_cfile_block(options, filename) File /usr/bin/uhd_rx_cfile.py, line 51, in __init__ num_channels=1) File /usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 1831, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs) RuntimeError: Network is unreachable Can anybody tell what is the problem about? Thanks -- Nemanja Savić -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.7 build failure ICE_ICESTORM-NOTFOUND etc.
Tom's 'cmake_ice' branch fixes the basic Mac OS X issue I reported in ticket #564 for ICE 3.4. I see the same issue as Barry for ICE 3.5, probably because the library names were changed (from libIce* to libZerocIce* from 3.4 to 3.5). I'll ping the MacPorts developer about this issue, to change one or the other for consistency. - MLD On Jul 21, 2013, at 7:17 AM, Barry Jackson zen25...@zen.co.uk wrote: On 20/07/13 15:11, Tom Rondeau wrote: On Thu, Jul 18, 2013 at 11:23 AM, Barry Jackson zen25...@zen.co.uk wrote: On 18/07/13 15:19, Tom Rondeau wrote: Do you know what version of ICE is installed on your system? GNU Radio explicitly looks for version 3.4, so if you're using 3.5 it won't work by default. I've tested and compiled against 3.5, though, so it's only the cmake FindICE script that's the problem. Also, ticket #564 is about faulty ICE detection, so this could also be a problem with your system. I hope to work on this soon to resolve that issue and make it easier to use either 3.4 or 3.5. Tom Hi Tom, Ice version is 3.4.2. Yes, #564 does look like the same issue except that it is reported on OSX where I am seeing it in Linux. Barry, I just pushed branch 'cmake_ice' to my github repo (github.com/trondeau/gnuradio). It does a better job of handling ICE, the include dirs, and the required libs. It also adds the ability to use Ice 3.5, which isn't important for you, though. Could you check out this branch and give it a try? I'd like to know how it works on other machines besides those which I've already gotten things to work. Thanks, Tom Tom, No real change with your cmake_ice branch. -- Configuring gnuradio-runtime support... -- Dependency Boost_FOUND = 1 -- Dependency ENABLE_VOLK = ON -- Dependency PYTHONINTERP_FOUND = TRUE -- Enabling gnuradio-runtime support. -- Override with -DENABLE_GNURADIO_RUNTIME=ON/OFF -- package 'Ice-3.5' not found -- ICE 3.5 not found. Looking for 3.4 -- package 'Ice-3.4' not found -- -- Configuring gr-ctrlport support... -- Dependency Boost_FOUND = 1 -- Dependency SWIG_FOUND = TRUE -- Dependency SWIG_VERSION_CHECK = TRUE -- Dependency ICE_FOUND = -- Dependency ENABLE_GNURADIO_RUNTIME = ON -- Disabling gr-ctrlport support. I looked at our Ice package spec and noticed that all the .pc files have been packaged in ice-csharp-devel, which I think is wrong, however installing that package as well makes no difference. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] linking Gnuradio and Gpredict ?
On 22/07/13 12:31, M Dammer wrote: Is it possible to link Gnuradio and Gpredict ? I want to use Gpredict as tracker controlling the antenna position and to pass doppler corrected frequency data to Gnuradio. In a word, yes. Can be very simple. I did it by using an XML Server in the flow graph, and wrote a quick XML client (actually I stole most of it from an example), and sent the doppler info from predict via a variable. doppler info was received from predict using some code to query predict using UDP. I think I just used nc to send the UDP query to predict, recovered the shift from the reply, and sent it back to the XML Server running within the flow graph. Unfortunately I can't find my actual code right now, but I literally copied an example, and added the UDP Predict clients bit. It went something like this pseudo code (Yes, this is a mix of shell,and python, and you need to re-write the getting doppler from predict yourself, but you get the idea, and should give you enough) import time import sys from socket import * import xmlrpclib import binascii s = xmlrpclib.Server(http://192.168.39.74:8081;) infinite=1 while infinite == 1; # Grab predict doppler using UDP DOPPLER=`nc -u -s 2 $PREDICTHOST GET_DOPPLER $NORAD_NUMBER` s.set_doppler_shift($DOPPLER) time.sleep(1) The variable (lets call it doppler_shift) exists in the flowgraph, and was multiplied appropriately and applied to the centre frequency of a FIR filter. You can pretty much pass any information you want in and out of a flow graph using a XML Server/Client pair. I've done TX/RX switching, and am currently working on telemetry decoding/display Iain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Inverted spectrum
On Sat, Jul 13, 2013 at 8:54 PM, Andrew Davis glneolistm...@gmail.com wrote: Hello all, When using pll_carriertracking_cc, the returned spectrum seems to be inverted about 0MHz, when looking though the code line 113 of gr-analog/lib/pll_carriertracking_cc_impl.cc looked odd: optr[i] = iptr[i] * gr_complex(t_real, -t_imag); could someone explain why the the imaginary component of the NCO is inverted? Thank you all, Andrew Andrew, That block was written so that it would lock to a carrier at a tone that is then used to downshift the signal. So you have a signal at fc; the PLL would lock onto that and produce a tone at -fc. This is then multiplied against the original signal to shift it down to baseband directly. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Network unreachable on Beaglebone Black
If you don't explicitly specify a device address, UHD will search through the defaults, including for an N2XX at 192.168.10.2. Just specify "type=usrp1" in the the device args. on Jul 22, 2013, Nemanja Savic vlasi...@gmail.com wrote: Hallo guys, I have installed gnuradio on Beaglebone black, which runs under Angstrom linux. uhd finding devices works good, and I am able to see my usrp1 device, but when I run uhd_rx_cfile i get following error: linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001-5ace684Traceback (most recent call last): File "/usr/bin/uhd_rx_cfile.py", line 143, in module tb = rx_cfile_block(options, filename) File "/usr/bin/uhd_rx_cfile.py", line 51, in __init__ num_channels=1) File "/usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py", line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File "/usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line 1831, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs)RuntimeError: Network is unreachable Can anybody tell what is the problem about? Thanks -- Nemanja Savić ___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Network unreachable on Beaglebone Black
Phil has kept the gnuradio recipe in OE up to date, so you should be able to get the latest version you want. You may need to get a more recent version of Angstrom, though. Have you tried using opkg update/upgrade? If that doesn't work just try using a newer image. If you don't want to cross compile there's plenty of options. You could grab a premade image from angstrom website, or build your own here: http://dominion.thruhere.net/koen/narcissus/ On Mon, Jul 22, 2013 at 11:55 AM, Nemanja Savic vlasi...@gmail.com wrote: there is no such option args is the answer from app. hm, because it was in repo of angstrom linux, and I don't know If I can handle crosscompiling of newer version (is there any other way?) On Mon, Jul 22, 2013 at 5:52 PM, Marcus Leech mle...@ripnet.com wrote: really? So, if you uhd_rx_cfile --args type=usrp1 What happens? Why the horribly-out-of-date Gnu Radio? (And corresponding version of UHD?) on Jul 22, 2013, Nemanja Savic vlasi...@gmail.com wrote: But there is no option for that (type). it is gnuradio 3.4.3. On Mon, Jul 22, 2013 at 5:11 PM, Marcus Leech mle...@ripnet.com wrote: If you don't explicitly specify a device address, UHD will search through the defaults, including for an N2XX at 192.168.10.2. Just specify type=usrp1 in the the device args. on Jul 22, 2013, Nemanja Savic vlasi...@gmail.com wrote: Hallo guys, I have installed gnuradio on Beaglebone black, which runs under Angstrom linux. uhd finding devices works good, and I am able to see my usrp1 device, but when I run uhd_rx_cfile i get following error: linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001-5ace684 Traceback (most recent call last): File /usr/bin/uhd_rx_cfile.py, line 143, in module tb = rx_cfile_block(options, filename) File /usr/bin/uhd_rx_cfile.py, line 51, in __init__ num_channels=1) File /usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py, line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File /usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py, line 1831, in usrp_source return _uhd_swig.usrp_source(*args, **kwargs) RuntimeError: Network is unreachable Can anybody tell what is the problem about? Thanks -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Nemanja Savić -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Measuring RSS during packet reception
Hi all, finally I added only delay of 64 samples due to correlate access code and it works good. My filter is of order 165 and with that additional delay the rssi is wrong. Why there is no delay due to the filter? Thank you On Fri, Jul 19, 2013 at 12:05 AM, Nemanja Savic vlasi...@gmail.com wrote: Hi Adeel, all, thank you again for your reply. The structure of my receiver is following: /--- filter --- quadrature demod threshold detector --- clock synchronization --- correlate ac --- deframer usrp source / / \ / \--- rms --- 10 log / Inside clock synchronization block stream is broken it might be that I am not able to determine where the actual burst started (maybe roughly) and that's why I want to send information about rssi together with every symbol value (i will think about idea to use 6 upper unused bits to put rssi inside). With current configuration it looks like the only delay I need to calculate is due to filter at the begining? (all other blocks should not introduce any delay). What should I do in order to get the order of filter? Best, Nemanja On Thu, Jul 18, 2013 at 5:50 PM, Adeel Anwar adeela...@gmail.com wrote: Nemanja, The problem that I have now is how to ensure that samples from demodulator chain and samples from RSSi calculator come in the same time to the symbol decision block. How can I tune this delay and is it deterministic? Yes, the delay is fix and can be determined by adding delay of all Filters in Rx-chain. Moreover IIRC, corrrelate-access-code itself adds 64bits delay that u need to cater for in ur custom block. On every symbol I read RSSI and send that value forward. As soon as I detect premble i start calculating RSSi for the packet based on number of symbols I will suggest that donot calculate RSSI for every symbol instead calculate RSSI for complete packet -Adeel On Thu, Jul 18, 2013 at 8:05 PM, Nemanja Savic vlasi...@gmail.comwrote: Hi, thank you Adeel for your answer. I implemented almost the same approach yesterday. I bring signal from USRP through rms and log calculator directly to the block for sampling symbol value. On every symbol I read RSSI and send that value forward. As soon as I detect premble i start calculating RSSi for the packet based on number of symbols. The problem that I have now is how to ensure that samples from demodulator chain and samples from RSSi calculator come in the same time to the symbol decision block. How can I tune this delay and is it deterministic? Many thanks, Nemanja On Thu, Jul 18, 2013 at 2:33 AM, Adeel Anwar adeela...@gmail.comwrote: Nemanja, I built this block sometime back. The ideas is to construct a custom RSSI Measurement block having input 1: complex IQ-samples after USRP-SRC or before AGC 2: byte-stream after digital_correlate_access_code_bb. Output byte stream has data in LSB (1st bit) while Flag in 2nd bit shows header detection) 3: Calculate system/filters group-delay between the complex-IQ samples stream and output-of-correlate-access-code. This delay will depend on the a) No. of filters in system e.g. FLL-Filter, PFB-Timing-Synch etc b) No. of filter Taps 3: Delay the complex IQ-samples stream by amount calculated in 3 4: In Custom RSSI-Measurement Block use following logic if (2-bit of correlate-access-code-stream) is High: Take average of N-items from IQ-samples stream where N depends on a) No of symbol in packet b) Samples-per-Symbol Hope this helps -Adeel On Wed, Jul 17, 2013 at 12:36 AM, Nemanja Savic vlasi...@gmail.comwrote: This looks a bit silly cause I am speaking with myself. Anyway, maybe I can do something with probe_avg_mag_sqr, but maybe somebody can tell me how can I access that block's values from another block? Best, Nemanja On Tue, Jul 16, 2013 at 3:16 PM, Nemanja Savic vlasi...@gmail.comwrote: The only way that is on my mind is to detect burst and store it in a file, and then to send a message to the block that will read that file, and in case of successfull demodulation and decoding to calcualte signal power, but it looks pretty robust and non elegant. Cheers, Nemanja On Tue, Jul 16, 2013 at 2:26 PM, Nemanja Savic vlasi...@gmail.comwrote: Any suggestions on this topic, opinions? Best Nemanja On Tue, Jul 9, 2013 at 4:23 PM, Nemanja Savic vlasi...@gmail.comwrote: Hi again gnuradioers, as always, I would like to ask for your opinion before starting to write my own block. Basically, I would like to add a feature to my receiver to be able to calculate average signal strength during signal reception. When I receive a valid packet I would like to have a RSS value. My question is what is the best way to accomplish this in GNURADIO? Using tags or messages, ...? IS there anything similar already provided so that I can take a look?
[Discuss-gnuradio] Using Gnuradio Companion to send identical signals with usrp1 to XCRV2450 and sbx daughter boards
Hi, sorry for sending the email to both list, but it seems it might be a joint topic. Please advise ma if I'm wrong. However here is my situation: I have send identical signals (1MHz sinusoidal) to these two daughter boards and measured the actual output signal with a spectrum analyzer as described is the linked file: https://dl.dropboxusercontent.com/u/54059714/2013JUL22_Eval_USRP1_XCVR2450_SBX_pub.pdf The XCRV gives the DC-leakage at carrier, my signal at carrier + 1 MHz and the image at carrier - 1 MHz. But the SBX only gives a 14 MHz wide something I cannot classify. Maybe the SBX is broken? Maybe it doesn't work correctly with the USRP1 and Gnuradio? Any advise is appreciated. Mario ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using Gnuradio Companion to send identical signals with usrp1 to XCRV2450 and sbx daughter boards
It would be useful to see your exact flow-graph. Also, how old is your USRP1? What rev of UHD code are you running? on Jul 22, 2013, mario behn mario.b...@gmail.com wrote: Hi, sorry for sending the email to both list, but it seems it might be a joint topic. Please advise ma if I'm wrong. However here is my situation: I have send identical signals (1MHz sinusoidal) to these two daughter boards and measured the actual output signal with a spectrum analyzer as described is the linked file: https://dl.dropboxusercontent.com/u/54059714/2013JUL22_Eval_USRP1_XCVR2450_SBX_pub.pdf The XCRV gives the DC-leakage at carrier, my signal at carrier + 1 MHz and the image at carrier - 1 MHz. But the SBX only gives a 14 MHz wide something I cannot classify. Maybe the SBX is broken? Maybe it doesn't work correctly with the USRP1 and Gnuradio? Any advise is appreciated. Mario ___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using Gnuradio Companion to send identical signals with usrp1 to XCRV2450 and sbx daughter boards
Hi Marcus, the USRP1 has been bought with all the components in july 2012 and the UHD driver and Gnuradio have been installed at beginning of July 2013 using the installation script running on Ubuntu 12.04 LTS. From my screenshot in the file I find this line: [...] linux; GNU C++ version 4.6.3; Boost_1048DD; UHD_003.005.003-87-g8f4000ff using Volk machine: avx_64_mmx_orc -Loading firmware image ... [...] I hope this helps. Thanks Mario On Mon, Jul 22, 2013 at 8:48 PM, Marcus Leech mle...@ripnet.com wrote: It would be useful to see your exact flow-graph. Also, how old is your USRP1? What rev of UHD code are you running? on Jul 22, 2013, *mario behn* mario.b...@gmail.com wrote: Hi, sorry for sending the email to both list, but it seems it might be a joint topic. Please advise ma if I'm wrong. However here is my situation: I have send identical signals (1MHz sinusoidal) to these two daughter boards and measured the actual output signal with a spectrum analyzer as described is the linked file: https://dl.dropboxusercontent.com/u/54059714/2013JUL22_Eval_USRP1_XCVR2450_SBX_pub.pdf The XCRV gives the DC-leakage at carrier, my signal at carrier + 1 MHz and the image at carrier - 1 MHz. But the SBX only gives a 14 MHz wide something I cannot classify. Maybe the SBX is broken? Maybe it doesn't work correctly with the USRP1 and Gnuradio? Any advise is appreciated. Mario -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with libtool while making the gnuradio 3.5
Hi All, I was trying to install gnuradio 3.5. I used this command to install dependencies sudo apt-get -y install git-core autoconf automake libtool g++ python-dev swig pkg-config libboost-all-dev libfftw3-dev libcppunit-dev libgsl0-dev libusb-dev sdcc libsdl1.2-dev python-wxgtk2.8 python-numpy python-cheetah python-lxml doxygen python-qt4 python-qwt5-qt4 libxi-dev libqt4-opengl-dev libqwt5-qt4-dev libfontconfig1-dev libxrender-dev And then followed following ./bootstrap Success ./configure --with-boost=$BOOST_PREFIX Success make Following Error: Entering directory `/home/himanshu/gnuradio-3.5.0/gruel/src/lib/pmt' /bin/bash ../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../.. -I/home/himanshu/gnuradio-3.5.0/gruel/src/include -I/home/himanshu/gnuradio-3.5.0/gruel/src/include -I/usr/include-g -O2 -Wall -Woverloaded-virtual -pthread -MT pmt.lo -MD -MP -MF .deps/pmt.Tpo -c -o pmt.lo pmt.cc libtool: Version mismatch error. This is libtool 2.4 Debian-2.4-2ubuntu1, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.4 Debian-2.4-2ubuntu1 libtool: and run autoconf again. make[8]: *** [pmt.lo] Error 63 Thanks Shashank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with libtool while making the gnuradio 3.5
so I tried following and now have this error $ rm aclocal.m4 $ aclocal $ autoconf $ ./configure Error: checking for CPPUNIT... yes ./configure: line 13863: syntax error near unexpected token `1.37' ./configure: line 13863: `AX_BOOST_BASE(1.37)' Last time there were no error for ./configure but this time there is this error. What should I do? Thank you for inputs Shashank On Mon, Jul 22, 2013 at 4:04 PM, Shashank Gaur shashankg...@ieee.orgwrote: Hi All, I was trying to install gnuradio 3.5. I used this command to install dependencies sudo apt-get -y install git-core autoconf automake libtool g++ python-dev swig pkg-config libboost-all-dev libfftw3-dev libcppunit-dev libgsl0-dev libusb-dev sdcc libsdl1.2-dev python-wxgtk2.8 python-numpy python-cheetah python-lxml doxygen python-qt4 python-qwt5-qt4 libxi-dev libqt4-opengl-dev libqwt5-qt4-dev libfontconfig1-dev libxrender-dev And then followed following ./bootstrap Success ./configure --with-boost=$BOOST_PREFIX Success make Following Error: Entering directory `/home/himanshu/gnuradio-3.5.0/gruel/src/lib/pmt' /bin/bash ../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../.. -I/home/himanshu/gnuradio-3.5.0/gruel/src/include -I/home/himanshu/gnuradio-3.5.0/gruel/src/include -I/usr/include-g -O2 -Wall -Woverloaded-virtual -pthread -MT pmt.lo -MD -MP -MF .deps/pmt.Tpo -c -o pmt.lo pmt.cc libtool: Version mismatch error. This is libtool 2.4 Debian-2.4-2ubuntu1, but the libtool: definition of this LT_INIT comes from libtool 2.2.6b. libtool: You should recreate aclocal.m4 with macros from libtool 2.4 Debian-2.4-2ubuntu1 libtool: and run autoconf again. make[8]: *** [pmt.lo] Error 63 Thanks Shashank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
