[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Communication Between Two GNU-Radio Stations
|
From: |
Emmanuel Mukose |
|
Subject: |
[Discuss-gnuradio] Communication Between Two GNU-Radio Stations |
|
Date: |
Tue, 11 Jun 2013 17:01:59 +0000 |
Hi Guys,
Am trying to configure my USRPs using GNU radio. But that is for a single
station. If I wanted to have multiple stations communicating between
themselves, how would I implement this? Basiically I want to have these USRPs
configured as Base Station. Can anyone help me figure out this?
Thanks,
Emmanuel Mukose
13. Re: reg. PSK Mod Block in Gnu radio (Marcus D. Leech)
14. Re: make test errors (Dave L)
15. Re: make test errors (Josh Blum)
16. Re: Regarding exponential operator in gnuradio (Nathan West)
17. pre-cog source doubt (Yogesh Dahiya)
18. Re: pre-cog source doubt (Yogesh Dahiya)
19. Re: Tun/Tap Problem while Running tunnel.py while wireshark
recognizes (Karan Talasila)
20. Re: USRP_N200 unable to connect via vmplayer (Karan Talasila)
21. Re: USRP_N200 unable to connect via vmplayer (Ankan Roybardhan)
22. Re: USRP_N200 unable to connect via vmplayer (Josh Blum)
23. LTE implementation on USRP (Shahab e)
24. 802.22 implementation on Gnu Radio? (M. Ranganathan)
25. Re: Tun/Tap Problem while Running tunnel.py while wireshark
recognizes (Tom Rondeau)
26. Re: reg. PSK Mod Block in Gnu radio (Tom Rondeau)
27. Re: LTE implementation on USRP (Evan Merewether)
28. Re: GMSK image sending issue (Tom Rondeau)
29. Re: Installing Hierarchical Blocks (Tom Rondeau)
30. Re: [USRP-users] How to Travel Commercial Airlines with USRP
(Ralph A. Schmid, dk5ras)
31. Volk error (Jay Prakash)
32. Problem with all the functionalities (uhd_fft,
gnuradio-companion etc) after installing gr-gras (Jay Prakash)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Jun 2013 12:01:58 -0400
From: Tom Rondeau <address@hidden>
To: Pratik Kumar <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] gnuradio-companion
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 10, 2013 at 11:50 AM, Pratik Kumar
<address@hidden> wrote:
> I am new to gnuradio.
> Can i get this channel as a block in gnuradio-companion.
Depends on what version you are using, but most likely, yes.
In the "Blocks" list on the right hand side of gnuradio-companion you
can find this under "Channel Models" (or just search for channel model
by typing in your search query after clicking into the box of blocks).
We have moved that block out of Python and reimplemented it in C++, so
you can't get exactly the block you linked to, but the C++ block
functions the same.
Tom
------------------------------
Message: 2
Date: Mon, 10 Jun 2013 16:06:01 +0000 (UTC)
From: Marcus Leech <address@hidden>
To: address@hidden
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] gnuradio-companion
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/f34a8ba0/attachment.html>
------------------------------
Message: 3
Date: Mon, 10 Jun 2013 13:17:34 -0400
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Detecting underflows with
uhd_usrp_sink
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 06/10/2013 09:43 AM, Sean Nowlan wrote:
> Do late packets always get dropped by the USRP? What happens if its buffers
> get filled up with samples, all of which are late?
The stream args have a policy parameter. Also, these args can be set
from a parameter in the USRP GRC blocks, as well as the constructor for
the gr-uhd blocks themselves.
This should be helpful:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef
-josh
>
> "Marcus D. Leech" <address@hidden> wrote:
>
>>> L = late packet, there was a time on the packet which was> time on
>>> device when
>>>
>>>
>> There are two different "cases" for late packets happening.
>>
>> The first is that you haven't sent your packet far enough in advance to
>> account for latency variations on the host. Unfortunately, on a
>> general-purpose
>> OS like Windows or Linux, latency variability can be extreme, and for
>> long-running flow-graphs you might need to develop a good model to determine
>> what the worst-case is and account for that.
>>
>> The second is that the clock on the USRP and the clock on the host will
>> tend to drift apart over time, particularly if both of them are "free
>> running".
>> So when you schedule timed bursts far enough in advance during the
>> start of a "session", it's entirely possible that after quite some time, the
>> two clocks have drifted apart unfavourably in terms of allowing you
>> to schedule things far enough in advance, relative to the USRP clock.
>> PC clocks are *terrible* by themselves. They'll drift significant
>> fractions of a second on a daily basis without any outside steering.
>> The USRP
>> clock, even free-running, is typically much, much better.
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 4
Date: Mon, 10 Jun 2013 10:57:08 -0700
From: vamshi krishna dodla <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Regarding exponential operator in gnuradio
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi all, does gnuradio have an exponential operator (like e^jw). If not how
to implement it in gnuradio.
--
Thanks & Regards
Vamshi Krishna Dodla
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/65a5fa61/attachment.html>
------------------------------
Message: 5
Date: Mon, 10 Jun 2013 13:58:13 -0400
From: Sean Nowlan <address@hidden>
To: <address@hidden>, <address@hidden>
Subject: Re: [Discuss-gnuradio] Detecting underflows with
uhd_usrp_sink
Message-ID: <address@hidden>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
On 06/10/2013 01:17 PM, Josh Blum wrote:
>
> On 06/10/2013 09:43 AM, Sean Nowlan wrote:
>> Do late packets always get dropped by the USRP? What happens if its buffers
>> get filled up with samples, all of which are late?
> The stream args have a policy parameter. Also, these args can be set
> from a parameter in the USRP GRC blocks, as well as the constructor for
> the gr-uhd blocks themselves.
>
> This should be helpful:
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef
Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second
period with 50/50 duty cycle) and I started the flowgraph 10 minutes
late. With the "next_burst" policy, could I rely on the USRP to
dutifully drop all late bursts? Are the packets dropped in the Ethernet
buffer or does the TX sample buffer fill up first? If it's the latter
case, my scenario implies that the TX buffer will have to be filled and
emptied multiple times until there are no more late packets, and normal
transmissions begin. This would happen at the sample rate times the
number of samples sent.
I suppose I'd also want to implement a message handler to drop the flood
of "L" symbols before they get piped to STDERR/STDOUT.
Do I have the right understanding of this process? Thanks!
--sean
P.S. -- Copying to USRP list since this could be relevant to people there.
> -josh
>
>> "Marcus D. Leech" <address@hidden> wrote:
>>
>>>> L = late packet, there was a time on the packet which was> time on
>>>> device when
>>>>
>>>>
>>> There are two different "cases" for late packets happening.
>>>
>>> The first is that you haven't sent your packet far enough in advance to
>>> account for latency variations on the host. Unfortunately, on a
>>> general-purpose
>>> OS like Windows or Linux, latency variability can be extreme, and for
>>> long-running flow-graphs you might need to develop a good model to determine
>>> what the worst-case is and account for that.
>>>
>>> The second is that the clock on the USRP and the clock on the host will
>>> tend to drift apart over time, particularly if both of them are "free
>>> running".
>>> So when you schedule timed bursts far enough in advance during the
>>> start of a "session", it's entirely possible that after quite some time, the
>>> two clocks have drifted apart unfavourably in terms of allowing you
>>> to schedule things far enough in advance, relative to the USRP clock.
>>> PC clocks are *terrible* by themselves. They'll drift significant
>>> fractions of a second on a daily basis without any outside steering.
>>> The USRP
>>> clock, even free-running, is typically much, much better.
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 6
Date: Mon, 10 Jun 2013 17:59:16 +0000 (UTC)
From: Marcus Leech <address@hidden>
To: address@hidden
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Regarding exponential operator in
gnuradio
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/7dc23994/attachment.html>
------------------------------
Message: 7
Date: Mon, 10 Jun 2013 14:06:40 -0400
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Detecting underflows with
uhd_usrp_sink
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
>
> Ok, makes sense. So lets say I scheduled 20 minutes of bursts (1 second
> period with 50/50 duty cycle) and I started the flowgraph 10 minutes
> late. With the "next_burst" policy, could I rely on the USRP to
> dutifully drop all late bursts? Are the packets dropped in the Ethernet
> buffer or does the TX sample buffer fill up first? If it's the latter
The bursts will be dropped as they are consumed by the VITA deframer.
This deframer sits between the TX buffering and the transmit DSP. So
yes, there will be some amount of buffered samples in the device, which
will need to be dropped.
Anything that is due for transmission that is several orders of
magnitude >> ethernet latency should probably stay in the host
application. :-)
> case, my scenario implies that the TX buffer will have to be filled and
> emptied multiple times until there are no more late packets, and normal
> transmissions begin. This would happen at the sample rate times the
> number of samples sent.
>
Because the DSP is upstream of the framer. The framer can drain samples
out of the buffering at the rate of the FPGA clock, this is ~100Msps for
the N210.
-josh
> I suppose I'd also want to implement a message handler to drop the flood
> of "L" symbols before they get piped to STDERR/STDOUT.
>
> Do I have the right understanding of this process? Thanks!
>
> --sean
>
> P.S. -- Copying to USRP list since this could be relevant to people there.
>
>> -josh
>>
>>> "Marcus D. Leech" <address@hidden> wrote:
>>>
>>>>> L = late packet, there was a time on the packet which was> time on
>>>>> device when
>>>>>
>>>>>
>>>> There are two different "cases" for late packets happening.
>>>>
>>>> The first is that you haven't sent your packet far enough in advance to
>>>> account for latency variations on the host. Unfortunately, on a
>>>> general-purpose
>>>> OS like Windows or Linux, latency variability can be extreme, and
>>>> for
>>>> long-running flow-graphs you might need to develop a good model to
>>>> determine
>>>> what the worst-case is and account for that.
>>>>
>>>> The second is that the clock on the USRP and the clock on the host will
>>>> tend to drift apart over time, particularly if both of them are "free
>>>> running".
>>>> So when you schedule timed bursts far enough in advance during the
>>>> start of a "session", it's entirely possible that after quite some
>>>> time, the
>>>> two clocks have drifted apart unfavourably in terms of allowing you
>>>> to schedule things far enough in advance, relative to the USRP clock.
>>>> PC clocks are *terrible* by themselves. They'll drift significant
>>>> fractions of a second on a daily basis without any outside steering.
>>>> The USRP
>>>> clock, even free-running, is typically much, much better.
>>>>
>>>>
>>>> --
>>>> Marcus Leech
>>>> Principal Investigator
>>>> Shirleys Bay Radio Astronomy Consortium
>>>> http://www.sbrac.org
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------
Message: 8
Date: Tue, 11 Jun 2013 02:42:19 +0530
From: Yogesh Dahiya <address@hidden>
To: Ankit Kaushik <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] gnuradio software architecture
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for the link. I got the idea of gnuradio scheduler.
top_block calls start which creates gnuradio_scheduler which topological
sort the flowgraph and create threads for each block according to sort.
But it did'nt explain how blocks are connected .I know that publish and
subscribe are used to connect blocks but how stream is buffered and
processed inside block is vague to me. Do you have Zhuo Lu paper explaining
how gnuradio core works. Sumit's link is not working.
If you have any more resource do forward.
Thanks again
On Mon, Jun 10, 2013 at 12:10 PM, Ankit Kaushik <
address@hidden> wrote:
> **
> On 10.06.2013 05:34, Yogesh Dahiya wrote:
> **
>
> **Hey is there any documentation explaining the software architecture of
> gnuradio. I means how blocks are connected , scheduled. Basically how
> everything is working behind the scene**
>
> Last year Sumit tried to explain this in his blog...
>
>
> http://sumitgnuradio.blogspot.de/2012/10/gnuradio-scheduler-part-1-how-gnu-radio.html?view=timeslide
>
> might be helpful!
>
> Ankit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/cf93ef28/attachment.html>
------------------------------
Message: 9
Date: Mon, 10 Jun 2013 18:00:21 -0400
From: Ankan Roybardhan <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I have vmplayer virtual machine running on my computer as my system is GPT
partition style and which is not taking dual boot of any release of ubuntu.
I connect to an ethernet port to a USRP rx... and do a uhd_find_devices ..
it says no device found.. although I have a valid gnuradio distro +uhd on
my computer and it works fine when I am not using the USRP though..
Could it be because of the vm that I am using? Please suggest what do I
need to do!!
this is my eth0 config-
eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
Interrupt:19 Base address:0x2000
This shows up when I am doing my firmware update-
address@hidden:~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
--fpga usrp_n200_r3_fpga.bin --auto_reboot
linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
Searching for USRP N2XX with IP address 192.168.10.3.
Error: No USRP N2XX found.
my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same ethernet
sw
-Regards,
Ankan Roybardhan
University of Florida.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/60a3b263/attachment.html>
------------------------------
Message: 10
Date: Mon, 10 Jun 2013 16:25:02 -0700
From: vamshi krishna dodla <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] reg. PSK Mod Block in Gnu radio
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf
Hi all, why does the output of PSK Mod block is imperfect, compared to
theoritical QPSK constellation.( iam implementing qpsk with 4 sampl/sym and
4 constellation points).The experiment im doing is the same in link (
http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf).
--
Thanks & Regards
Vamshi Krishna.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/b781f0be/attachment.html>
------------------------------
Message: 11
Date: Mon, 10 Jun 2013 19:29:02 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] reg. PSK Mod Block in Gnu radio
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 06/10/2013 07:25 PM, vamshi krishna dodla wrote:
> http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf
>
>
> Hi all, why does the output of PSK Mod block is imperfect, compared to
> theoritical QPSK constellation.( iam implementing qpsk with 4
> sampl/sym and 4 constellation points).The experiment im doing is the
> same in link
> (http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf).
>
>
> --
> Thanks & Regards
> Vamshi Krishna.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
This kind of question is *much* better accompanied by the flow-graph
you're working, perhaps an FFT and constellation plot, etc, etc.
You question, as presented, reduces to "why does thing thing I'm doing
not work". Which nobody will be able to help you with.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/c523bfb3/attachment.html>
------------------------------
Message: 12
Date: Mon, 10 Jun 2013 20:48:25 -0400
From: Clark Pope <address@hidden>
To: Ankan Roybardhan <address@hidden>, "address@hidden"
<address@hidden>
Subject: Re: [Discuss-gnuradio] USRP_N200 unable to connect via
vmplayer
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
________________________________
> Date: Mon, 10 Jun 2013 18:00:21 -0400
> From: address@hidden
> To: address@hidden
> Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer
>
> I have vmplayer virtual machine running on my computer as my system is
> GPT partition style and which is not taking dual boot of any release of
> ubuntu.
>
> I connect to an ethernet port to a USRP rx... and do a uhd_find_devices
> .. it says no device found.. although I have a valid gnuradio distro
> +uhd on my computer and it works fine when I am not using the USRP
> though..
>
> Could it be because of the vm that I am using? Please suggest what do I
> need to do!!
>
> this is my eth0 config-
>
> eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
> inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
> inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
> TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
> Interrupt:19 Base address:0x2000
>
>
> This shows up when I am doing my firmware update-
>
>
> address@hidden:~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
> usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
> --fpga usrp_n200_r3_fpga.bin --auto_reboot
> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>
> Searching for USRP N2XX with IP address 192.168.10.3.
> Error: No USRP N2XX found.
>
> my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same
> ethernet sw
>
>
>
> -Regards,
> Ankan Roybardhan
> University of Florida.
>
You're sure its not at the default address 192.168.10.2?
Don't know if you have the same problem but I use a USB to GigE adapter from
vmware player and I found that it ONLY works if I boot the VM with the
interface that is connected to the USRP as the only active network connection.
I can enable the network interface to the host OS after I boot and it still
works but for some reason if the VMnetX interfaces are active at boot it messes
up the ability to find the USRP.
-Clark
------------------------------
Message: 13
Date: Mon, 10 Jun 2013 21:25:18 -0400
From: "Marcus D. Leech" <address@hidden>
To: vamshi krishna dodla <address@hidden>,
"address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] reg. PSK Mod Block in Gnu radio
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/10/2013 08:13 PM, vamshi krishna dodla wrote:
> can you please reply
>
>
When I'm good and ready.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 14
Date: Mon, 10 Jun 2013 18:57:48 -0700 (PDT)
From: Dave L <address@hidden>
To: Tom Rondeau <address@hidden>, GNURadio Discussion List
<address@hidden>
Subject: Re: [Discuss-gnuradio] make test errors
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
The CPU on the laptop is an Intel i3-2350M (64 bit).
What steps should I take (or where can I learn how) to resolve the problem with
Volk?
Dave
________________________________
From: Tom Rondeau <address@hidden>
To: Botany Dave <address@hidden>
Sent: Monday, June 10, 2013 6:41 AM
Subject: Re: [Discuss-gnuradio] make test errors
On Thu, Jun 6, 2013 at 11:52 PM, Botany Dave <address@hidden> wrote:
> I'm new to this, and I'm sure it will show...
>
> I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I
> followed the instructions at
> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview
> and am getting errors on four modules when I run make test. They are:
>
> 86 - qa_fir_filter
> 91 - qa_freq__xlating_fir_filter
> 150 - qa_constellation_receiver
> 169 - qa_codec2_vocoder
>
> Here is the output of ctest -V -R qa for each of those modules. I'd really
> appreciate any guidance on how to resolve these failures.
>
> 86: Test command: /bin/sh
> "/home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh"
> 86: Test timeout computed to be: 9.99988e+06
> 86: .........FF
> 86: ======================================================================
> 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter)
> 86: ----------------------------------------------------------------------
> 86: Traceback (most recent call last):
> 86:? File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
> 262, in test_fir_filter_scc_001
> 86:? ? self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
> 86:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 86:? ? self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 86:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 86:? ? (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
> 86:
> 86: ======================================================================
> 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter)
> 86: ----------------------------------------------------------------------
> 86: Traceback (most recent call last):
> 86: Using Volk machine: avx_32_mmx
> 86:? File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
> 281, in test_fir_filter_scc_002
> 86:? ? self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
> 86:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 86:? ? self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 86:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 86:? ? (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
> 86:
> 86: ----------------------------------------------------------------------
> 86: Ran 11 tests in 0.035s
> 86:
> 86: FAILED (failures=2)
> 1/1 Test #86: qa_fir_filter ....................***Failed? ? 0.30 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =? 0.31 sec
>
> The following tests FAILED:
>? ? ? 86 - qa_fir_filter (Failed)
> Errors while running CTest
>
>
> 91: Test command: /bin/sh
> "/home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh"
> 91: Test timeout computed to be: 9.99988e+06
> 91: ........FFFF
> 91: ======================================================================
> 91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter)
> 91: ----------------------------------------------------------------------
> 91: Traceback (most recent call last):
> 91:? File
> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
> 412, in test_fir_filter_scc_001
> 91:? ? self.assertComplexTuplesAlmostEqual(expected_data,
> result_data[-20:], 5)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 91:? ? self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 91:? ? (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 91: AssertionError: (-0.00775564694777+0.0437113791704j) != (nan+nanj)
> within 5 places
> 91:
> 91: ======================================================================
> 91: Using Volk machine: avx_32_mmx
> 91: FAIL: test_fir_filter_scc_002 (__main__.test_freq_xlating_filter)
> 91: ----------------------------------------------------------------------
> 91: Traceback (most recent call last):
> 91:? File
> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
> 442, in test_fir_filter_scc_002
> 91:? ? self.assertComplexTuplesAlmostEqual(expected_data,
> result_data[-20:], 5)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 91:? ? self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 91:? ? (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 91: AssertionError: (-0.0080680437386-0.00158522999845j) != (nan+nanj)
> within 5 places
> 91:
> 91: ======================================================================
> 91: FAIL: test_fir_filter_scf_001 (__main__.test_freq_xlating_filter)
> 91: ----------------------------------------------------------------------
> 91: Traceback (most recent call last):
> 91:? File
> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
> 352, in test_fir_filter_scf_001
> 91:? ? self.assertComplexTuplesAlmostEqual(expected_data,
> result_data[-20:], 5)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 91:? ? self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 91:? ? (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 91: AssertionError: (-0.0330070219934+0.101965591311j) != (nan+nanj) within
> 5 places
> 91:
> 91: ======================================================================
> 91: FAIL: test_fir_filter_scf_002 (__main__.test_freq_xlating_filter)
> 91: ----------------------------------------------------------------------
> 91: Traceback (most recent call last):
> 91:? File
> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
> 382, in test_fir_filter_scf_002
> 91:? ? self.assertComplexTuplesAlmostEqual(expected_data,
> result_data[-20:], 5)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 74, in assertComplexTuplesAlmostEqual
> 91:? ? self.assertComplexAlmostEqual (a[i], b[i], places, msg)
> 91:? File
> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
> 47, in assertComplexAlmostEqual
> 91:? ? (msg or '%s != %s within %s places' % (`first`, `second`, `places`
> ))
> 91: AssertionError: (0.00824625696987-1.50158575707e-05j) != (nan+nanj)
> within 5 places
> 91:
> 91: ----------------------------------------------------------------------
> 91: Ran 12 tests in 0.045s
> 91:
> 91: FAILED (failures=4)
> 1/1 Test #91: qa_freq_xlating_fir_filter .......***Failed? ? 0.32 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =? 0.34 sec
>
> The following tests FAILED:
>? ? ? 91 - qa_freq_xlating_fir_filter (Failed)
> Errors while running CTest
>
>
> 150: Test command: /bin/sh
> "/home/dave/gnuradio/build/gr-digital/python/qa_constellation_receiver_test.sh"
> 150: Test timeout computed to be: 9.99988e+06
> 150: Segmentation fault (core dumped)
> 1/1 Test #150: qa_constellation_receiver ........***Failed? 13.64 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =? 13.66 sec
>
> The following tests FAILED:
>? ? 150 - qa_constellation_receiver (Failed)
> Errors while running CTest
>
>
> 169: Test command: /bin/sh
> "/home/dave/gnuradio/build/gr-vocoder/python/qa_codec2_vocoder_test.sh"
> 169: Test timeout computed to be: 9.99988e+06
> 169: F
> 169: ======================================================================
> 169: FAIL: test001_module_load (__main__.test_codec2_vocoder)
> 169: ----------------------------------------------------------------------
> 169: Traceback (most recent call last):
> 169:? File "/home/dave/gnuradio/gr-vocoder/python/qa_codec2_vocoder.py",
> line 56, in test001_module_load
> 169:? ? self.assertEqual(expected_data, actual_result)
> 169: AssertionError: Tuples differ: (0, 0, 0, 3, 2, 0, 1, 5, 6, 7,... !=
> (0L, 0L, 0L, 3L, 2L, 0L, 1L, 5...
> 169:
> 169: First differing element 112:
> 169: 24
> 169: 25
> 169:
> 169: Diff is 3978 characters long. Set self.maxDiff to None to see it.
> 169:
> 169: ----------------------------------------------------------------------
> 169: Ran 1 test in 0.503s
> 169:
> 169: FAILED (failures=1)
> 1/1 Test #169: qa_codec2_vocoder ................***Failed? ? 0.86 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) =? 0.87 sec
>
> The following tests FAILED:
>? ? 169 - qa_codec2_vocoder (Failed)
> Errors while running CTest
>
>
>
> I've rerun apt-get on for the following, and all report back as being the
> most current release:
> python-dev
> python-wxgtk2.8
> python-numpy
> python-cheetah
> python-lxml
> python-qt4
> python-qwt5-qt4
>
> Any help you can offer would be very much appreciated.
> libqt4-opengl-dev libqwt5-qt4-dev libfontconfig1-dev libxrender-dev
Dave,
Thanks for the details in your question. The first three look like
Volk issues and the last looks like a precision error.
What is the computer hardware? Specifically, what processor, processor
architecture (32 or 64 bit), and are your running it in a VM?
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/46ebe244/attachment.html>
------------------------------
Message: 15
Date: Mon, 10 Jun 2013 22:12:05 -0400
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] make test errors
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Run volk/lib/test_all from the build dir
If a kernel fails, it will tell you which one, start commenting out its
implementations in the source dir volk/kernels/volk/volk_*.h until the
test works. We narrow down suspect implementation and fix.
-josh
On 06/10/2013 09:57 PM, Dave L wrote:
> The CPU on the laptop is an Intel i3-2350M (64 bit).
>
> What steps should I take (or where can I learn how) to resolve the problem
> with Volk?
>
> Dave
>
>
>
>
> ________________________________
> From: Tom Rondeau <address@hidden>
> To: Botany Dave <address@hidden>
> Sent: Monday, June 10, 2013 6:41 AM
> Subject: Re: [Discuss-gnuradio] make test errors
>
>
> On Thu, Jun 6, 2013 at 11:52 PM, Botany Dave <address@hidden> wrote:
>> I'm new to this, and I'm sure it will show...
>>
>> I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I
>> followed the instructions at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview
>> and am getting errors on four modules when I run make test. They are:
>>
>> 86 - qa_fir_filter
>> 91 - qa_freq__xlating_fir_filter
>> 150 - qa_constellation_receiver
>> 169 - qa_codec2_vocoder
>>
>> Here is the output of ctest -V -R qa for each of those modules. I'd really
>> appreciate any guidance on how to resolve these failures.
>>
>> 86: Test command: /bin/sh
>> "/home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh"
>> 86: Test timeout computed to be: 9.99988e+06
>> 86: .........FF
>> 86: ======================================================================
>> 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter)
>> 86: ----------------------------------------------------------------------
>> 86: Traceback (most recent call last):
>> 86: File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
>> 262, in test_fir_filter_scc_001
>> 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
>> 86: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 86: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
>> 86:
>> 86: ======================================================================
>> 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter)
>> 86: ----------------------------------------------------------------------
>> 86: Traceback (most recent call last):
>> 86: Using Volk machine: avx_32_mmx
>> 86: File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line
>> 281, in test_fir_filter_scc_002
>> 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5)
>> 86: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 86: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places
>> 86:
>> 86: ----------------------------------------------------------------------
>> 86: Ran 11 tests in 0.035s
>> 86:
>> 86: FAILED (failures=2)
>> 1/1 Test #86: qa_fir_filter ....................***Failed 0.30 sec
>>
>> 0% tests passed, 1 tests failed out of 1
>>
>> Total Test time (real) = 0.31 sec
>>
>> The following tests FAILED:
>> 86 - qa_fir_filter (Failed)
>> Errors while running CTest
>>
>>
>> 91: Test command: /bin/sh
>> "/home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh"
>> 91: Test timeout computed to be: 9.99988e+06
>> 91: ........FFFF
>> 91: ======================================================================
>> 91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter)
>> 91: ----------------------------------------------------------------------
>> 91: Traceback (most recent call last):
>> 91: File
>> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
>> 412, in test_fir_filter_scc_001
>> 91: self.assertComplexTuplesAlmostEqual(expected_data,
>> result_data[-20:], 5)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 91: AssertionError: (-0.00775564694777+0.0437113791704j) != (nan+nanj)
>> within 5 places
>> 91:
>> 91: ======================================================================
>> 91: Using Volk machine: avx_32_mmx
>> 91: FAIL: test_fir_filter_scc_002 (__main__.test_freq_xlating_filter)
>> 91: ----------------------------------------------------------------------
>> 91: Traceback (most recent call last):
>> 91: File
>> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
>> 442, in test_fir_filter_scc_002
>> 91: self.assertComplexTuplesAlmostEqual(expected_data,
>> result_data[-20:], 5)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 91: AssertionError: (-0.0080680437386-0.00158522999845j) != (nan+nanj)
>> within 5 places
>> 91:
>> 91: ======================================================================
>> 91: FAIL: test_fir_filter_scf_001 (__main__.test_freq_xlating_filter)
>> 91: ----------------------------------------------------------------------
>> 91: Traceback (most recent call last):
>> 91: File
>> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
>> 352, in test_fir_filter_scf_001
>> 91: self.assertComplexTuplesAlmostEqual(expected_data,
>> result_data[-20:], 5)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 91: AssertionError: (-0.0330070219934+0.101965591311j) != (nan+nanj) within
>> 5 places
>> 91:
>> 91: ======================================================================
>> 91: FAIL: test_fir_filter_scf_002 (__main__.test_freq_xlating_filter)
>> 91: ----------------------------------------------------------------------
>> 91: Traceback (most recent call last):
>> 91: File
>> "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line
>> 382, in test_fir_filter_scf_002
>> 91: self.assertComplexTuplesAlmostEqual(expected_data,
>> result_data[-20:], 5)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 74, in assertComplexTuplesAlmostEqual
>> 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg)
>> 91: File
>> "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line
>> 47, in assertComplexAlmostEqual
>> 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places`
>> ))
>> 91: AssertionError: (0.00824625696987-1.50158575707e-05j) != (nan+nanj)
>> within 5 places
>> 91:
>> 91: ----------------------------------------------------------------------
>> 91: Ran 12 tests in 0.045s
>> 91:
>> 91: FAILED (failures=4)
>> 1/1 Test #91: qa_freq_xlating_fir_filter .......***Failed 0.32 sec
>>
>> 0% tests passed, 1 tests failed out of 1
>>
>> Total Test time (real) = 0.34 sec
>>
>> The following tests FAILED:
>> 91 - qa_freq_xlating_fir_filter (Failed)
>> Errors while running CTest
>>
>>
>> 150: Test command: /bin/sh
>> "/home/dave/gnuradio/build/gr-digital/python/qa_constellation_receiver_test.sh"
>> 150: Test timeout computed to be: 9.99988e+06
>> 150: Segmentation fault (core dumped)
>> 1/1 Test #150: qa_constellation_receiver ........***Failed 13.64 sec
>>
>> 0% tests passed, 1 tests failed out of 1
>>
>> Total Test time (real) = 13.66 sec
>>
>> The following tests FAILED:
>> 150 - qa_constellation_receiver (Failed)
>> Errors while running CTest
>>
>>
>> 169: Test command: /bin/sh
>> "/home/dave/gnuradio/build/gr-vocoder/python/qa_codec2_vocoder_test.sh"
>> 169: Test timeout computed to be: 9.99988e+06
>> 169: F
>> 169: ======================================================================
>> 169: FAIL: test001_module_load (__main__.test_codec2_vocoder)
>> 169: ----------------------------------------------------------------------
>> 169: Traceback (most recent call last):
>> 169: File "/home/dave/gnuradio/gr-vocoder/python/qa_codec2_vocoder.py",
>> line 56, in test001_module_load
>> 169: self.assertEqual(expected_data, actual_result)
>> 169: AssertionError: Tuples differ: (0, 0, 0, 3, 2, 0, 1, 5, 6, 7,... !=
>> (0L, 0L, 0L, 3L, 2L, 0L, 1L, 5...
>> 169:
>> 169: First differing element 112:
>> 169: 24
>> 169: 25
>> 169:
>> 169: Diff is 3978 characters long. Set self.maxDiff to None to see it.
>> 169:
>> 169: ----------------------------------------------------------------------
>> 169: Ran 1 test in 0.503s
>> 169:
>> 169: FAILED (failures=1)
>> 1/1 Test #169: qa_codec2_vocoder ................***Failed 0.86 sec
>>
>> 0% tests passed, 1 tests failed out of 1
>>
>> Total Test time (real) = 0.87 sec
>>
>> The following tests FAILED:
>> 169 - qa_codec2_vocoder (Failed)
>> Errors while running CTest
>>
>>
>>
>> I've rerun apt-get on for the following, and all report back as being the
>> most current release:
>> python-dev
>> python-wxgtk2.8
>> python-numpy
>> python-cheetah
>> python-lxml
>> python-qt4
>> python-qwt5-qt4
>>
>> Any help you can offer would be very much appreciated.
>> libqt4-opengl-dev libqwt5-qt4-dev libfontconfig1-dev libxrender-dev
>
> Dave,
>
> Thanks for the details in your question. The first three look like
> Volk issues and the last looks like a precision error.
>
> What is the computer hardware? Specifically, what processor, processor
> architecture (32 or 64 bit), and are your running it in a VM?
>
> Tom
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 16
Date: Mon, 10 Jun 2013 23:06:48 -0400
From: Nathan West <address@hidden>
To: vamshi krishna dodla <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] Regarding exponential operator in
gnuradio
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
http://gnuradio.org/doc/doxygen/gr__expj_8h_source.html
On Monday, June 10, 2013, vamshi krishna dodla wrote:
> Hi all, does gnuradio have an exponential operator (like e^jw). If not how
> to implement it in gnuradio.
>
>
> --
> Thanks & Regards
> Vamshi Krishna Dodla
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130610/f1d0fa58/attachment.html>
------------------------------
Message: 17
Date: Tue, 11 Jun 2013 10:13:00 +0530
From: Yogesh Dahiya <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] pre-cog source doubt
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I was looking at the source of pre-cog and there is this piece of code
which i am not able to locate ( pmt_mgr() ) in the documentation.
self.mgr = pmt.pmt_mgr()
for i in range(64):
self.mgr.set(pmt.pmt_make_blob(10000))
blob = self.mgr.acquire(True )
There is no reference of pmt_mgr in documentation. Can somebody
expalain its operation or point to relevant docs.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/ec87ac2d/attachment.html>
------------------------------
Message: 18
Date: Tue, 11 Jun 2013 10:45:01 +0530
From: Yogesh Dahiya <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] pre-cog source doubt
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Okay I found in older grextras (
https://github.com/ncorgan/grextras/blob/master/include/gruel/pmt_mgr.h)
/*
* ------------------------------------------------------------------------
* Manage a collection of PMTs -> memory wise
*
* When a PMT reference count becomes zero, the pmt and contents is deleted.
* With a manager, the PMT will not be deleted, but released to the manager.
* Then, the PMT can be acquired again for re-use by the user.
*
* This offers 2 benefits:
* - Avoids expensive memory allocation overhead (re-use is key)
* - An upstream producer can block until resources become released
* ------------------------------------------------------------------------
*/
On Tue, Jun 11, 2013 at 10:13 AM, Yogesh Dahiya <address@hidden>wrote:
>
> I was looking at the source of pre-cog and there is this piece of code which
> i am not able to locate ( pmt_mgr() ) in the documentation.
>
> self.mgr = pmt.pmt_mgr()
> for i in range(64):
> self.mgr.set(pmt.pmt_make_blob(10000))
> blob = self.mgr.acquire(True )
>
>
> There is no reference of pmt_mgr in documentation. Can somebody expalain its
> operation or point to relevant docs.
>
> Thanks
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/160a8937/attachment.html>
------------------------------
Message: 19
Date: Tue, 11 Jun 2013 10:46:19 +0530
From: Karan Talasila <address@hidden>
To: Jay Prakash <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] Tun/Tap Problem while Running
tunnel.py while wireshark recognizes
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi Jay and Tom,
we too are having similar issues in communicating
between two USRP's using tunnel.py. we fiddled a lot with the gain values,
changed frequencies, modified delay variables in the code but found that
even though there is pretty good full duplex communication of packets
between the USRP's, the ping command is not giving a good output. we tried
and received a minimum ping packet loss of 60%. we couldn't get better than
that with all the modifications we tried. we thought that the ping is not
receiving the icmp back in time so it is showing as a false packet because
the usrp packets reception on both ends is fine.
Any suggestions will be very helpful. Thank You.
On Mon, Jun 10, 2013 at 8:00 PM, Jay Prakash
<address@hidden>wrote:
> Yes I have tested using different frequency.No help.
>
> And while debugging I figured out that PHY layer receives the packet from
> transmitter sent as ping ICMP packets and decodes the sender's address.
> After that it writes to the tun/tap. But tun/tap reply is unavailable.
> Ie there is some problem in tun/tap and PHY layer interface.
>
> How to figure this out?
>
>
> Jay Prakash
> Senior Undergraduate
> Electronics Engineering
> IIT (BHU)
> VARANASI
>
> +91-9559475258
> http://about.me/jay.prakash/
> http://www.linkedin.com/profile/view?id=91120191&trk=hb_tab_pro_top
>
>
>
>
> On Mon, Jun 10, 2013 at 7:13 PM, Tom Rondeau <address@hidden> wrote:
>
>> On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
>> <address@hidden> wrote:
>> > We are working on establishing a tunnel for MAC protocol design using
>> > tunnel.py given as example in GNU Radio but are unable to receive ping
>> reply
>> > from the other node.
>> >
>> > We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
>> > 192.168.200.1 on Machine A connected to N210 series of USRP.
>> > and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.
>> >
>> > 1. Now on pinging machine B from A we can see ping packets being sent
>> to B
>> > by A using wireshark, but there is no reply on node A.
>> >
>> > 2. We went into details and saw there were ARQ requests from B
>> repetitively.
>> > I manually added the mac address to update the table.
>> > Now ARQ request ceased to exist but still there were no replies on A.
>> >
>> >
>> > 3. Since we knew the Packaging details of ICMP we read the packets being
>> > received by B and found the exact source address of A from the frame. It
>> > means message have been successfully decoded by the destination and it
>> knows
>> > whom to reply for the ping but still I don't find any reception
>> confirmation
>> > on source side.
>> >
>> > What may be the possible problems?USRP antenna gain?Packets collision?
>> >
>> > In short we are unable to use tunnely.py and are seeking for possible
>> > causes.
>> >
>> > Jay Prakash
>> > Senior Undergraduate
>>
>> You could be having gain issues. Test this using the standard
>> uhd_siggen and uhd_fft programs to understand what settings give you
>> the best gain.
>>
>> Also, try using different frequencies for transmit and receive (use
>> the -h on the command line to figure out how to do this).
>>
>> Tom
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
Regards
Karan Talasila
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/a38b7dc1/attachment.html>
------------------------------
Message: 20
Date: Tue, 11 Jun 2013 10:59:16 +0530
From: Karan Talasila <address@hidden>
To: Clark Pope <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] USRP_N200 unable to connect via
vmplayer
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Check if your usrp is surely on 192.168.10.3. Run uhd_usrp_probe and
check if it is giving any output. Do you have gigabit ethernet card on your
laptop. If not, you will have to use a switch in between and some times
switch might be an issue.
one more thing, are you connected on static ip? If you are on dhcp, change
it to static ip and see.
On Tue, Jun 11, 2013 at 6:18 AM, Clark Pope <address@hidden> wrote:
> ________________________________
> > Date: Mon, 10 Jun 2013 18:00:21 -0400
> > From: address@hidden
> > To: address@hidden
> > Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer
> >
> > I have vmplayer virtual machine running on my computer as my system is
> > GPT partition style and which is not taking dual boot of any release of
> > ubuntu.
> >
> > I connect to an ethernet port to a USRP rx... and do a uhd_find_devices
> > .. it says no device found.. although I have a valid gnuradio distro
> > +uhd on my computer and it works fine when I am not using the USRP
> > though..
> >
> > Could it be because of the vm that I am using? Please suggest what do I
> > need to do!!
> >
> > this is my eth0 config-
> >
> > eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
> > inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
> > inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
> > Interrupt:19 Base address:0x2000
> >
> >
> > This shows up when I am doing my firmware update-
> >
> >
> > address@hidden
> :~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
> > usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
> > --fpga usrp_n200_r3_fpga.bin --auto_reboot
> > linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
> >
> > Searching for USRP N2XX with IP address 192.168.10.3.
> > Error: No USRP N2XX found.
> >
> > my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same
> > ethernet sw
> >
> >
> >
> > -Regards,
> > Ankan Roybardhan
> > University of Florida.
> >
>
> You're sure its not at the default address 192.168.10.2?
>
> Don't know if you have the same problem but I use a USB to GigE adapter
> from vmware player and I found that it ONLY works if I boot the VM with the
> interface that is connected to the USRP as the only active network
> connection. I can enable the network interface to the host OS after I boot
> and it still works but for some reason if the VMnetX interfaces are active
> at boot it messes up the ability to find the USRP.
>
> -Clark
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
--
Regards
Karan Talasila
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/0b8cf46b/attachment.html>
------------------------------
Message: 21
Date: Tue, 11 Jun 2013 02:19:20 -0400
From: Ankan Roybardhan <address@hidden>
To: Karan Talasila <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] USRP_N200 unable to connect via
vmplayer
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
1. I tried using vm bridged connection over NAT.. i assigned 192.168.10.1
and subnet 255.255.255.0 in the ubuntu network setting running on
vmplayer.. I am pretty much sure about the other USRP IP since.. i used
some other machine to do uhd_find_devices .. so check for their IPs..
2. My ethernet port is working fine on windows.. I though did not check it
on my vm.. bt hopefully it is working since it is recognizing the LAN..
3. The sw is perfectly fine tested OK.
4. I changed it from dhcp to manual ipv4 settings as 1. the problem
persists.. the device is on 192.168.10.3..
i did uhd_usrp_probe with --args=<ip of the usrp>... it says the same.
could not find devices..
I feel there is a big issue with the vmplayer network settings with uhd...
-Ankan Roybardhan.
On Tue, Jun 11, 2013 at 1:29 AM, Karan Talasila <address@hidden> wrote:
> Hi,
> Check if your usrp is surely on 192.168.10.3. Run uhd_usrp_probe and
> check if it is giving any output. Do you have gigabit ethernet card on your
> laptop. If not, you will have to use a switch in between and some times
> switch might be an issue.
>
> one more thing, are you connected on static ip? If you are on dhcp, change
> it to static ip and see.
>
>
> On Tue, Jun 11, 2013 at 6:18 AM, Clark Pope <address@hidden> wrote:
>
>> ________________________________
>> > Date: Mon, 10 Jun 2013 18:00:21 -0400
>> > From: address@hidden
>> > To: address@hidden
>> > Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer
>> >
>> > I have vmplayer virtual machine running on my computer as my system is
>> > GPT partition style and which is not taking dual boot of any release of
>> > ubuntu.
>> >
>> > I connect to an ethernet port to a USRP rx... and do a uhd_find_devices
>> > .. it says no device found.. although I have a valid gnuradio distro
>> > +uhd on my computer and it works fine when I am not using the USRP
>> > though..
>> >
>> > Could it be because of the vm that I am using? Please suggest what do I
>> > need to do!!
>> >
>> > this is my eth0 config-
>> >
>> > eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
>> > inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
>> > inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
>> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> > RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
>> > TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
>> > collisions:0 txqueuelen:1000
>> > RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
>> > Interrupt:19 Base address:0x2000
>> >
>> >
>> > This shows up when I am doing my firmware update-
>> >
>> >
>> > address@hidden
>> :~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
>> > usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
>> > --fpga usrp_n200_r3_fpga.bin --auto_reboot
>> > linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>> >
>> > Searching for USRP N2XX with IP address 192.168.10.3.
>> > Error: No USRP N2XX found.
>> >
>> > my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same
>> > ethernet sw
>> >
>> >
>> >
>> > -Regards,
>> > Ankan Roybardhan
>> > University of Florida.
>> >
>>
>> You're sure its not at the default address 192.168.10.2?
>>
>> Don't know if you have the same problem but I use a USB to GigE adapter
>> from vmware player and I found that it ONLY works if I boot the VM with the
>> interface that is connected to the USRP as the only active network
>> connection. I can enable the network interface to the host OS after I boot
>> and it still works but for some reason if the VMnetX interfaces are active
>> at boot it messes up the ability to find the USRP.
>>
>> -Clark
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards
> Karan Talasila
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/3895b2bc/attachment.html>
------------------------------
Message: 22
Date: Tue, 11 Jun 2013 02:35:28 -0400
From: Josh Blum <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] USRP_N200 unable to connect via
vmplayer
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On 06/11/2013 02:19 AM, Ankan Roybardhan wrote:
> 1. I tried using vm bridged connection over NAT.. i assigned 192.168.10.1
> and subnet 255.255.255.0 in the ubuntu network setting running on
> vmplayer.. I am pretty much sure about the other USRP IP since.. i used
> some other machine to do uhd_find_devices .. so check for their IPs..
> 2. My ethernet port is working fine on windows.. I though did not check it
> on my vm.. bt hopefully it is working since it is recognizing the LAN..
> 3. The sw is perfectly fine tested OK.
> 4. I changed it from dhcp to manual ipv4 settings as 1. the problem
> persists.. the device is on 192.168.10.3..
> i did uhd_usrp_probe with --args=<ip of the usrp>... it says the same.
> could not find devices..
>
> I feel there is a big issue with the vmplayer network settings with uhd...
Well, can you ping the USRP from the VM? That would eliminate the
question of uhd and UDP sockets.
Can you ping another device with a static IP though the VM, like a
router that is connected to the same network interface as the USRP?
-josh
>
> -Ankan Roybardhan.
>
>
> On Tue, Jun 11, 2013 at 1:29 AM, Karan Talasila <address@hidden> wrote:
>
>> Hi,
>> Check if your usrp is surely on 192.168.10.3. Run uhd_usrp_probe and
>> check if it is giving any output. Do you have gigabit ethernet card on your
>> laptop. If not, you will have to use a switch in between and some times
>> switch might be an issue.
>>
>> one more thing, are you connected on static ip? If you are on dhcp, change
>> it to static ip and see.
>>
>>
>> On Tue, Jun 11, 2013 at 6:18 AM, Clark Pope <address@hidden> wrote:
>>
>>> ________________________________
>>>> Date: Mon, 10 Jun 2013 18:00:21 -0400
>>>> From: address@hidden
>>>> To: address@hidden
>>>> Subject: [Discuss-gnuradio] USRP_N200 unable to connect via vmplayer
>>>>
>>>> I have vmplayer virtual machine running on my computer as my system is
>>>> GPT partition style and which is not taking dual boot of any release of
>>>> ubuntu.
>>>>
>>>> I connect to an ethernet port to a USRP rx... and do a uhd_find_devices
>>>> .. it says no device found.. although I have a valid gnuradio distro
>>>> +uhd on my computer and it works fine when I am not using the USRP
>>>> though..
>>>>
>>>> Could it be because of the vm that I am using? Please suggest what do I
>>>> need to do!!
>>>>
>>>> this is my eth0 config-
>>>>
>>>> eth0 Link encap:Ethernet HWaddr 00:0c:29:23:94:4e
>>>> inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
>>>> inet6 addr: fe80::20c:29ff:fe23:944e/64 Scope:Link
>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>>> RX packets:39419 errors:0 dropped:0 overruns:0 frame:0
>>>> TX packets:14888 errors:0 dropped:0 overruns:0 carrier:0
>>>> collisions:0 txqueuelen:1000
>>>> RX bytes:48827305 (48.8 MB) TX bytes:1521561 (1.5 MB)
>>>> Interrupt:19 Base address:0x2000
>>>>
>>>>
>>>> This shows up when I am doing my firmware update-
>>>>
>>>>
>>>> address@hidden
>>> :~/Downloads/uhd-images_003.005.001-release/share/uhd/images$
>>>> usrp_n2xx_simple_net_burner --addr 192.168.10.3 --fw usrp_n200_fw.bin
>>>> --fpga usrp_n200_r3_fpga.bin --auto_reboot
>>>> linux; GNU C++ version 4.6.3; Boost_104800; UHD_003.005.003-78-g49a4929b
>>>>
>>>> Searching for USRP N2XX with IP address 192.168.10.3.
>>>> Error: No USRP N2XX found.
>>>>
>>>> my machine is 192.168.10.1 .. the usrp is on 192.168.10.3 via same
>>>> ethernet sw
>>>>
>>>>
>>>>
>>>> -Regards,
>>>> Ankan Roybardhan
>>>> University of Florida.
>>>>
>>>
>>> You're sure its not at the default address 192.168.10.2?
>>>
>>> Don't know if you have the same problem but I use a USB to GigE adapter
>>> from vmware player and I found that it ONLY works if I boot the VM with the
>>> interface that is connected to the USRP as the only active network
>>> connection. I can enable the network interface to the host OS after I boot
>>> and it still works but for some reason if the VMnetX interfaces are active
>>> at boot it messes up the ability to find the USRP.
>>>
>>> -Clark
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Regards
>> Karan Talasila
>>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
------------------------------
Message: 23
Date: Tue, 11 Jun 2013 12:11:56 +0200
From: Shahab e <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] LTE implementation on USRP
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Sorry if this question was already asked. I am looking for LTE
implementation on USRP boards using GNU Radio. The only link I could find
is the following:
https://twiki.eurecom.fr/twiki/bin/view/OpenAirInterface/GetSources
But it seems it is a simulation tool running on GNU Radio and I am not sure
if it can be implemented on USRP.
Can it be implemented on USRP? and if not is there any other available
sources?
My second question is how can I evaluate the delays between a feedback and
a scheduling decision? I am trying to do a project and the delay must not
exceed than 5 ms.
Sincerely,
Shahab
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/d410319e/attachment.html>
------------------------------
Message: 24
Date: Tue, 11 Jun 2013 06:57:25 -0400
From: "M. Ranganathan" <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] 802.22 implementation on Gnu Radio?
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hello!
I am wondering if there are any implementations of 802.22 on GR. Any
pointers would be appreciated.
Thank you
Ranga
--
M. Ranganathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/77732962/attachment.html>
------------------------------
Message: 25
Date: Tue, 11 Jun 2013 09:32:08 -0400
From: Tom Rondeau <address@hidden>
To: Karan Talasila <address@hidden>
Cc: Jay Prakash <address@hidden>, GNURadio Discussion
List <address@hidden>
Subject: Re: [Discuss-gnuradio] Tun/Tap Problem while Running
tunnel.py while wireshark recognizes
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 11, 2013 at 1:16 AM, Karan Talasila <address@hidden> wrote:
> Hi Jay and Tom,
> we too are having similar issues in communicating
> between two USRP's using tunnel.py. we fiddled a lot with the gain values,
> changed frequencies, modified delay variables in the code but found that
> even though there is pretty good full duplex communication of packets
> between the USRP's, the ping command is not giving a good output. we tried
> and received a minimum ping packet loss of 60%. we couldn't get better than
> that with all the modifications we tried. we thought that the ping is not
> receiving the icmp back in time so it is showing as a false packet because
> the usrp packets reception on both ends is fine.
>
> Any suggestions will be very helpful. Thank You.
I was hoping that what I said to Jay would have been a bit of a help
to get him going. But go back in this list a few months to read my
post about not using tunnel.py. There are a number of problems with it
at this point. Fundamentally, the CSMA decision is made too far away
from the antenna to be of any real value. Also, there is no FEC, so
any wrong bit in a frame means you lose that entire frame.
You'll be better served building your application of using GNU Radio
blocks to transmit data.
Tom
> On Mon, Jun 10, 2013 at 8:00 PM, Jay Prakash <address@hidden>
> wrote:
>>
>> Yes I have tested using different frequency.No help.
>>
>> And while debugging I figured out that PHY layer receives the packet from
>> transmitter sent as ping ICMP packets and decodes the sender's address.
>> After that it writes to the tun/tap. But tun/tap reply is unavailable.
>> Ie there is some problem in tun/tap and PHY layer interface.
>>
>> How to figure this out?
>>
>>
>> Jay Prakash
>> Senior Undergraduate
>> Electronics Engineering
>> IIT (BHU)
>> VARANASI
>>
>> +91-9559475258
>> http://about.me/jay.prakash/
>> http://www.linkedin.com/profile/view?id=91120191&trk=hb_tab_pro_top
>>
>>
>>
>>
>> On Mon, Jun 10, 2013 at 7:13 PM, Tom Rondeau <address@hidden> wrote:
>>>
>>> On Thu, Jun 6, 2013 at 3:22 PM, Jay Prakash
>>> <address@hidden> wrote:
>>> > We are working on establishing a tunnel for MAC protocol design using
>>> > tunnel.py given as example in GNU Radio but are unable to receive ping
>>> > reply
>>> > from the other node.
>>> >
>>> > We created tun/tap interface using ./tunnel.py -f 990M and ipconfig
>>> > 192.168.200.1 on Machine A connected to N210 series of USRP.
>>> > and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B.
>>> >
>>> > 1. Now on pinging machine B from A we can see ping packets being sent
>>> > to B
>>> > by A using wireshark, but there is no reply on node A.
>>> >
>>> > 2. We went into details and saw there were ARQ requests from B
>>> > repetitively.
>>> > I manually added the mac address to update the table.
>>> > Now ARQ request ceased to exist but still there were no replies on A.
>>> >
>>> >
>>> > 3. Since we knew the Packaging details of ICMP we read the packets
>>> > being
>>> > received by B and found the exact source address of A from the frame.
>>> > It
>>> > means message have been successfully decoded by the destination and it
>>> > knows
>>> > whom to reply for the ping but still I don't find any reception
>>> > confirmation
>>> > on source side.
>>> >
>>> > What may be the possible problems?USRP antenna gain?Packets collision?
>>> >
>>> > In short we are unable to use tunnely.py and are seeking for possible
>>> > causes.
>>> >
>>> > Jay Prakash
>>> > Senior Undergraduate
>>>
>>> You could be having gain issues. Test this using the standard
>>> uhd_siggen and uhd_fft programs to understand what settings give you
>>> the best gain.
>>>
>>> Also, try using different frequencies for transmit and receive (use
>>> the -h on the command line to figure out how to do this).
>>>
>>> Tom
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards
> Karan Talasila
------------------------------
Message: 26
Date: Tue, 11 Jun 2013 09:38:51 -0400
From: Tom Rondeau <address@hidden>
To: vamshi krishna dodla <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] reg. PSK Mod Block in Gnu radio
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 10, 2013 at 7:25 PM, vamshi krishna dodla
<address@hidden> wrote:
> http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf
>
>
> Hi all, why does the output of PSK Mod block is imperfect, compared to
> theoritical QPSK constellation.( iam implementing qpsk with 4 sampl/sym and
> 4 constellation points).The experiment im doing is the same in link
> (http://gnuradio.squarespace.com/storage/tutorial/rondeau-costterra2.pdf).
>
>
> --
> Thanks & Regards
> Vamshi Krishna.
Inter-symbol interference. Look up the root raised cosine filter and
you'll see why. Basically, an RRC is /not/ a Nyquist filter. Now think
about what that means to the receiver.
Tom
------------------------------
Message: 27
Date: Tue, 11 Jun 2013 08:25:11 -0600
From: "Evan Merewether" <address@hidden>
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] LTE implementation on USRP
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
Search this forum for openLTE announcement. (File link here:
sourceforge.net/projects/openlte)
Evan Merewether - 575-640-5582
_____
From: address@hidden
[mailto:address@hidden On Behalf Of
Shahab e
Sent: Tuesday, June 11, 2013 4:12 AM
To: address@hidden
Subject: [Discuss-gnuradio] LTE implementation on USRP
Hi,
Sorry if this question was already asked. I am looking for LTE
implementation on USRP boards using GNU Radio. The only link I could find is
the following:
https://twiki.eurecom.fr/twiki/bin/view/OpenAirInterface/GetSources
But it seems it is a simulation tool running on GNU Radio and I am not sure
if it can be implemented on USRP.
Can it be implemented on USRP? and if not is there any other available
sources?
My second question is how can I evaluate the delays between a feedback and a
scheduling decision? I am trying to do a project and the delay must not
exceed than 5 ms.
Sincerely,
Shahab
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/46213eb8/attachment.html>
------------------------------
Message: 28
Date: Tue, 11 Jun 2013 10:53:08 -0400
From: Tom Rondeau <address@hidden>
To: Jay Prakash <address@hidden>
Cc: Adarsh Jain <address@hidden>, GNURadio Discussion List
<address@hidden>
Subject: Re: [Discuss-gnuradio] GMSK image sending issue
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, Jun 3, 2013 at 12:06 PM, Jay Prakash
<address@hidden>wrote:
> The module is behaving erratically and most of the time there is no
> reception of .jpg file.
>
> This problem is more dominant in case different USRPs are used in sending
> and receiving.
>
Remember, unless you've put in FEC encoding and decoding, there is no FEC
in the examples. Any bit that goes wrong will cause the CRC to fail and the
packet to be rejected. You can never guarantee an environment where you
don't lose any bits.
Problems with different USRPs is likely due to different frequency offsets.
The more offset you have, the works you're GMSK demod will perform.
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/d96de6f0/attachment.html>
------------------------------
Message: 29
Date: Tue, 11 Jun 2013 10:50:18 -0400
From: Tom Rondeau <address@hidden>
To: Bastian Bloessl <address@hidden>
Cc: gnuradio mailing list <address@hidden>
Subject: Re: [Discuss-gnuradio] Installing Hierarchical Blocks
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Jun 4, 2013 at 1:45 AM, Bastian Bloessl
<address@hidden> wrote:
> Hi all,
>
> I'm working on a OOT module and created a hierarchical block in GRC. I
> wonder if there is a nice way to include it in the installation process.
>
> Currently, the user would have to open the hier block in GRC, build it,
> restart GRC and open the actual flow graph that is utilizing the hier block.
>
> Should I somehow compile it with grcc during installation?
>
> Best,
> Bastian
Basian,
Yes, you should be able to make a Cmake rule to run grcc on the .grc
file to build the Python file. That could be done either during cmake
time or compile time (depends on how you want to go with it; possibly
whichever you find easier to add to the cmake files). By the end of
cmake/make, you'd have a .py file. So you would also just have a rule
to install this .py file like you would any other Python file.
Tom
------------------------------
Message: 30
Date: Tue, 11 Jun 2013 17:38:44 +0200
From: "Ralph A. Schmid, dk5ras" <address@hidden>
To: <address@hidden>
Subject: Re: [Discuss-gnuradio] [USRP-users] How to Travel Commercial
Airlines with USRP
Message-ID: <address@hidden>
Content-Type: text/plain; charset="us-ascii"
This is also my experience with even more strange electronic devices. Just
carrying a bunch of handheld two-way radios rose some eyebrows, they had to
go through a test for hidden explosives, and that was all.
Ralph.
From: address@hidden
[mailto:address@hidden On Behalf Of Matt
Ettus
Sent: Sunday, 09 June, 2013 21:42
To: Bruce Penswick
Cc: address@hidden; address@hidden
Subject: Re: [Discuss-gnuradio] [USRP-users] How to Travel Commercial
Airlines with USRP
These days you will have more trouble with a screwdriver than with the usrp.
We fly with them all the time.
Matt
On Jun 9, 2013 12:27 PM, "Bruce Penswick" <address@hidden> wrote:
Hello:
Quick question: I'm flying commercial for a work-trip, American Airlines
from Los Angeles to Dallas, and I need to bring my USRP N200. How can I
bring it with me? Does anyone have any experience flying commercial airlines
with USRPs? Should I put it into my checked-in luggage? I'm afraid it would
get flagged as something dangerous, and they'd rip open my luggage. Do you
think I could carry it on-board the plane, after security makes me open it
and they look inside it? Or is it just going to create too many problems,
and would I be better off just mailing it to Dallas ahead of my trip?
Any thoughts, advice, experiences would be much appreciated!!
Thanks for your help!!
Best Regards,
Bruce P.
_______________________________________________
USRP-users mailing list
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/90e9a87d/attachment.html>
------------------------------
Message: 31
Date: Tue, 11 Jun 2013 21:20:58 +0530
From: Jay Prakash <address@hidden>
To: Thomas Rondeau <address@hidden>, "address@hidden"
<address@hidden>
Subject: [Discuss-gnuradio] Volk error
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Running GRC files give following error after re-installation and update
with gr-extras.
Using Volk machine: sse4_2_32_orc
The program 'python2.7' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 958 error_code 9 request_code 137 minor_code 8)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
Jay Prakash
Senior Undergraduate
Electronics Engineering
IIT (BHU)
VARANASI
+91-9559475258
http://about.me/jay.prakash/
http://www.linkedin.com/profile/view?id=91120191&trk=hb_tab_pro_top
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/26f89c1f/attachment.html>
------------------------------
Message: 32
Date: Tue, 11 Jun 2013 21:12:56 +0530
From: Jay Prakash <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Problem with all the functionalities
(uhd_fft, gnuradio-companion etc) after installing gr-gras
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi!
Today I reinstalled using gr-gras and gr-extra.
But now there is some volk problem.
"
UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
*
Using Volk machine: sse4_2_32_orc
ASSERT FAIL
/home/electron/Downloads/gras/lib/gras_impl/output_buffer_queues.hpp:140
total_idle_times[i] <= (time_now() - _init_time)
terminate called after throwing an instance of 'std::runtime_error'
what(): ASSERT FAIL total_idle_times[i] <= (time_now() - _init_time)
Aborted* "
Help me out.
Jay Prakash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130611/04871f45/attachment.html>
------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 127, Issue 15
*************************************************
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Discuss-gnuradio] Communication Between Two GNU-Radio Stations,
Emmanuel Mukose <=