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.
I am interested in calculation BER for Tx-Rx system.I used this prototype.But there is no significant change in BER even though I change delay value.How do I complete dynamic BER for the channel ie file transfer will be like a burst.I like to monitor channel BER dynamically for every hop.Jay PrakashSenior Undergraduate
On Sun, Jun 2, 2013 at 9:30 PM, <address@hidden> wrote:Send Discuss-gnuradio mailing list submissions to
address@hidden
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hidden
You can reach the person managing the list at
address@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."
Today's Topics:
1. Segfaults on exit from GRC (Marcus D. Leech)
2. External modules include path / namespace (Sylvain Munaut)
3. Test Results on gnuradio-3.6.5 & exe extensions (vsrk sarma)
4. MAC layer implementation on USRP (Medhat Hamdy)
5. MAC layer implementation on USRP (Medhat Hamdy)
6. MAC layer implementation on USRP (Medhat Hamdy)
7. Re: Test Results on gnuradio-3.6.5 & exe extensions
(Martin Braun (CEL))
8. Re: External modules include path / namespace (Martin Braun (CEL))
9. Re: External modules include path / namespace (Sylvain Munaut)
10. Re: External modules include path / namespace (Johnathan Corgan)
11. Gnu-companion (Pratik Kumar)
12. Re: Gnu-companion (Marcus D. Leech)
13. Re: Gnu-companion (Volker Schroer)
----------------------------------------------------------------------
Message: 1
Date: Sat, 01 Jun 2013 17:39:54 -0400
From: "Marcus D. Leech" <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] Segfaults on exit from GRC
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm still seeing these. Everything else is fine, but on exit from GRC,
I get segfaults.
dmesg has the following to say:
[150439.794647] gnuradio-compan[30536]: segfault at fffffffffffffff8 ip
00007f575ffe46d3 sp 00007fff783c56c0 error 6 in
libgnuradio-core-3.6.5.so.0.0.0[7f575fe60000+2a5000]
[150644.537869] gnuradio-compan[30549]: segfault at fffffffffffffff8 ip
00007f1e561876d3 sp 00007fff1873e970 error 6 in
libgnuradio-core-3.6.5.so.0.0.0[7f1e56003000+2a5000]
[151445.989406] gnuradio-compan[30615]: segfault at fffffffffffffff8 ip
00007f44a3bfa6d3 sp 00007fffa34ee7a0 error 6 in
libgnuradio-core-3.6.5.so.0.0.0[7f44a3a76000+2a5000]
[151836.222126] gnuradio-compan[30919]: segfault at fffffffffffffff8 ip
00007fd7823136d3 sp 00007fffb2da9900 error 6 in
libgnuradio-core-3.6.5.so.0.0.0[7fd78218f000+2a5000]
[160084.612744] gnuradio-compan[7142]: segfault at fffffffffffffff8 ip
00007fe52d92f6d3 sp 00007fff584a6770 error 6 in
libgnuradio-core-3.6.5.so.0.0.0[7fe52d7ab000+2a5000]
[160182.727210] gnuradio-compan[7173]: segfault at fffffffffffffff8 ip
00007f73c59ad6d3 sp 00007fff95f20fa0 error 6 in
libgnuradio-core-3.6.5.so.0.0.0[7f73c5829000+2a5000]
This is on Fedora 14, x86_64 on an AMD Phenom II X4
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 2
Date: Sun, 2 Jun 2013 00:18:49 +0200
From: Sylvain Munaut <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] External modules include path / namespace
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8
Hi,
>From looking at what gr_modtool generate, you get
include: $prefix/include/module_name/
namespace: gr::module_name::
python: $prefix/lib/site-package/module_name/
Since the module are placed in the gr:: namespace, wouldn't it make
sense to have :
include: $prefix/include/gnuradio/module_name/
namespace: gr::module_name::
python: $prefix/lib/site-package/gnuradio/module_name/
This would also make external modules that much closer to internal
ones and further reduce the difference between in-tree / out-of-tree
Cheers,
Sylvain
------------------------------
Message: 3
Date: Sun, 2 Jun 2013 11:52:51 +0530
From: vsrk sarma <address@hidden>
To: discuss-gnuradio <address@hidden>
Subject: [Discuss-gnuradio] Test Results on gnuradio-3.6.5 & exe
extensions
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I just built and installed gnuradio-3.6.5 on HP-Compaq nx-5115 with Ubuntu
13.04.
Following two tests failed out of 239: qa_udp_source_sink and qa_ofdm_txtrx
Errors while running Ctest: Error 8
Are test failures because as I have no hardware connected?
I set -DCMAKE_INSTALL_PREFIX=$HOME/gnuradio
Another strange observation is that all .py files in various examples
folders have exe extensions,( e.g. dial_tone.py.exe). Is there an
abnormality?
--
vsrk sarma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/2d8c8569/attachment.html>
------------------------------
Message: 4
Date: Sun, 2 Jun 2013 03:38:34 -0700 (PDT)
From: Medhat Hamdy <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] MAC layer implementation on USRP
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
Hi everyone,
I am trying to develop MAC implementation on the USRP. Is there any thing that would help me do that.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/1476dcc8/attachment.html>
------------------------------
Message: 5
Date: Sun, 2 Jun 2013 03:41:59 -0700 (PDT)
From: Medhat Hamdy <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] MAC layer implementation on USRP
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="us-ascii"
Hi everyone,
I am trying to develop a MAC layer protocol on the USRP. Is there any thing that would help me.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/95c6b5a7/attachment.html>
------------------------------
Message: 6
Date: Sun, 2 Jun 2013 03:46:05 -0700 (PDT)
From: Medhat Hamdy <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] MAC layer implementation on USRP
Message-ID:
<address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
?Hi everyone,
I am trying to develop a MAC layer protocol on the USRP. Is there any thing that would help me.
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/54486b64/attachment.html>
------------------------------
Message: 7
Date: Sun, 2 Jun 2013 15:44:31 +0200
From: "Martin Braun (CEL)" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Test Results on gnuradio-3.6.5 & exe
extensions
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
On Sun, Jun 02, 2013 at 11:52:51AM +0530, vsrk sarma wrote:
> I just built and installed gnuradio-3.6.5 on HP-Compaq nx-5115 with Ubuntu
> 13.04.
>
> Following two tests failed out of 239: qa_udp_source_sink and qa_ofdm_txtrx
Can you please send the output of
$ ctest -V -R udp_source
and
$ ctest -V -R ofdm_txrx
> Errors while running Ctest: Error 8
>
> Are test failures because as I have no hardware connected?
No.
> I set -DCMAKE_INSTALL_PREFIX=$HOME/gnuradio
Make sure you're PATHs are all correct if you do that.
> Another strange observation is that all .py files in various examples folders
> have exe extensions,( e.g. dial_tone.py.exe). Is there an abnormality?
I'm not entirely sure if you're being serious, but just in case: That's
normal. I doubt that any binary on your system has such an extension,
given you're on Ubuntu.
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/9b59aa7e/attachment.pgp>
------------------------------
Message: 8
Date: Sun, 2 Jun 2013 15:57:14 +0200
From: "Martin Braun (CEL)" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] External modules include path /
namespace
Message-ID: <address@hidden>
Content-Type: text/plain; charset="utf-8"
On Sun, Jun 02, 2013 at 12:18:49AM +0200, Sylvain Munaut wrote:
> include: $prefix/include/module_name/
> namespace: gr::module_name::
> python: $prefix/lib/site-package/module_name/
>
> Since the module are placed in the gr:: namespace, wouldn't it make
> sense to have :
>
> include: $prefix/include/gnuradio/module_name/
> namespace: gr::module_name::
> python: $prefix/lib/site-package/gnuradio/module_name/
>
> This would also make external modules that much closer to internal
> ones and further reduce the difference between in-tree / out-of-tree
Just pointing out that oot-modules have always been a bit different,
e.g. import MODULE vs. from gnuradio import MODULE. Also, I don't mind
having a dedicated folder for core gnuradio stuff.
I agree making the folder structures for in- and out-tree modules more
similar is good, though. So, just some thoughts here, perhaps we'll talk
about this this week.
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
Research Associate
Kaiserstra?e 12
Building 05.01
76131 Karlsruhe
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
KIT -- University of the State of Baden-W?rttemberg and
National Laboratory of the Helmholtz Association
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/cf900876/attachment.pgp>
------------------------------
Message: 9
Date: Sun, 2 Jun 2013 16:28:33 +0200
From: Sylvain Munaut <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] External modules include path /
namespace
Message-ID:
<CAHL+j0_eXWmtYCW7jpP-z_=-Zx1rN8J9gbtayce=address@hidden>
Content-Type: text/plain; charset=UTF-8
Hi Martin,
>> include: $prefix/include/gnuradio/module_name/
>> namespace: gr::module_name::
>> python: $prefix/lib/site-package/gnuradio/module_name/
>>
>> This would also make external modules that much closer to internal
>> ones and further reduce the difference between in-tree / out-of-tree
>
> Just pointing out that oot-modules have always been a bit different,
> e.g. import MODULE vs. from gnuradio import MODULE. Also, I don't mind
> having a dedicated folder for core gnuradio stuff.
> I agree making the folder structures for in- and out-tree modules more
> similar is good, though. So, just some thoughts here, perhaps we'll talk
> about this this week.
I don't mind having a namespace for core stuff either but then maybe
it should have like gnuradio.ext.module_name or something and make it
coherent between include/c++ namespace/python.
Else you end up having to include some "gnuradio marker" in the module
name to make sure it doesn't clash with general python stuff or
general include stuff.
I actually only realized that oot were still not under some "gnuradio"
separate path when converting a module this weekend and since I guess
a lot of OOT module are going to get ported soon, now would be the
right time.
Cheers,
Sylvain
------------------------------
Message: 10
Date: Sun, 2 Jun 2013 10:30:20 -0400
From: Johnathan Corgan <address@hidden>
To: "Martin Braun (CEL)" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] External modules include path /
namespace
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Jun 2, 2013, at 9:58, "Martin Braun (CEL)" <address@hidden> wrote:
> On Sun, Jun 02, 2013 at 12:18:49AM +0200, Sylvain Munaut wrote:
>> include: $prefix/include/module_name/
>> namespace: gr::module_name::
>> python: $prefix/lib/site-package/module_name/
>>
>> Since the module are placed in the gr:: namespace, wouldn't it make
>> sense to have :
>>
>> include: $prefix/include/gnuradio/module_name/
>> namespace: gr::module_name::
>> python: $prefix/lib/site-package/gnuradio/module_name/
>>
>> This would also make external modules that much closer to internal
>> ones and further reduce the difference between in-tree / out-of-tree
>
> Just pointing out that oot-modules have always been a bit different,
> e.g. import MODULE vs. from gnuradio import MODULE. Also, I don't mind
> having a dedicated folder for core gnuradio stuff.
> I agree making the folder structures for in- and out-tree modules more
> similar is good, though. So, just some thoughts here, perhaps we'll talk
> about this this week.
The main reason OOT modules are 'import foo' and not 'from gnuradio
import foo' is that OOT modules typically install into
$PREFIX=/usr/local, and if GNU Radio is installed into $PREFIX=/usr,
the import would not work.
Johnathan
------------------------------
Message: 11
Date: Sun, 2 Jun 2013 11:33:34 -0400
From: Pratik Kumar <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Gnu-companion
Message-ID:
<CAKxNru6QyYekftzZ-i96cp1ugV4Rt=address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I am getting an error while executing flow graph
I have used that built script to install gnu radio
& i have set the path as told by the script.
Executing: "/home/kiit/top_block.py"
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
(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
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)[image:
Inline image 1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/9a5c3f0f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error.png
Type: image/png
Size: 159856 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/9a5c3f0f/attachment.png>
------------------------------
Message: 12
Date: Sun, 02 Jun 2013 11:53:31 -0400
From: "Marcus D. Leech" <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Gnu-companion
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 06/02/2013 11:33 AM, Pratik Kumar wrote:
> I am getting an error while executing flow graph
> I have used that built script to install gnu radio
> & i have set the path as told by the script.
>
>
> Executing: "/home/kiit/top_block.py"
>
> 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
> (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
> option to change this behavior. You can then get a meaningful
> backtrace from your debugger if you break on the gdk_x_error()
> function.)Inline image 1
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I've seen this happen on an older Ubuntu release on a VM -- are you
running it on a VM, and on what Ubuntu release?
--
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/20130602/27e5fb06/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 159856 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130602/27e5fb06/attachment.png>
------------------------------
Message: 13
Date: Sun, 02 Jun 2013 17:55:08 +0200
From: Volker Schroer <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Gnu-companion
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Try to set
style = nongl
in
<install_prefix>/etc/gnuradio/conf.d/gr-wxgui.conf
Am 02.06.2013 17:33, schrieb Pratik Kumar:
> I am getting an error while executing flow graph
> I have used that built script to install gnu radio
> & i have set the path as told by the script.
>
>
> Executing: "/home/kiit/top_block.py"
>
> 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
> (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
> option to change this behavior. You can then get a meaningful
> backtrace from your debugger if you break on the gdk_x_error()
> function.)Inline image 1
>
>
> _______________________________________________
> 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
End of Discuss-gnuradio Digest, Vol 127, Issue 2
************************************************
