HI, Is there any way of transmitting voice over ip using GNu Radio Companion. Best Regards, SAJJAD SAFDAR
on 2013-03-03 12:19
on 2013-03-03 13:56
On 03/03/2013 06:18 AM, Sajjad Safdar wrote:
> Is there any way of transmitting voice over ip using GNu Radio Companion.
To the extent that you can define what networking, modulation, and VoIP
protocols you intend to use, yes.
on 2013-03-04 20:06
Hi, I want to use transmit audiofrom PMR446 radio using USrp1 and gnuradio, through internet to other host. Then the other hostreceivethe audio and transmit over the air using USR1 and GNuradio to PMR446 radio. It should look like this PMR446 Radio > USRP1 (RFX400) > NBFM Receive(GNU Radio) > Internet > GNuRadio >NBFM Transmit > PMR446 Radio I have a working flow graph which can modulate and demodulate PMR446 Radio channels easily. I just need to transmit the channel received through internet to the other host. I am not sure whether it can be done by using TCP/UDP source/sink blocks, or some other way. Best Rgards, SAJJAD SAFDAR ________________________________ From: "discuss-gnuradio-request@gnu.org" <discuss-gnuradio-request@gnu.org> To: discuss-gnuradio@gnu.org Sent: Sunday, March 3, 2013 10:00 PM Subject: Discuss-gnuradio Digest, Vol 124, Issue 3 Send Discuss-gnuradio mailing list submissions to discuss-gnuradio@gnu.org 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 discuss-gnuradio-request@gnu.org You can reach the person managing the list at discuss-gnuradio-owner@gnu.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Discuss-gnuradio digest..." Today's Topics: 1. Re: LibUSRP vs LibUHD Performance on older machines (Josh Blum) 2. branch next gone? (Ralph A. Schmid) 3. Re: branch next gone? (Tom Rondeau) 4. Re: branch next gone? (Ralph A. Schmid) 5. Re: LibUSRP vs LibUHD Performance on older machines (Tom Hendrick) 6. Re: LibUSRP vs LibUHD Performance on older machines (Marcus D. Leech) 7. Re: LibUSRP vs LibUHD Performance on older machines (Tom Hendrick) 8. Re: GNU Radio releases 3.6.3.1 and 3.6.4 available for download (Arturo Rinaldi) 9. branch next - analolg FM modulators do not work? (Ralph A. Schmid) 10. Voice over IP using GNu Radio. (Sajjad Safdar) 11. Re: Voice over IP using GNu Radio. (Phil Frost) 12. how to compile the py file in gnuradio (Yingjie Chen) 13. Re: how to compile the py file in gnuradio (Nicholas Corgan) 14. Error building gnuradio 3.4.2 on ubuntu 12.04 (usrp_prims.cc file error) (Sundus Tahir) 15. Re: branch next - analolg FM modulators do not work? (Tom Rondeau) 16. FW: branch next - analolg FM modulators do not work? (Ralph A. Schmid, dk5ras) ---------------------------------------------------------------------- Message: 1 Date: Sat, 02 Mar 2013 11:18:04 -0600 From: Josh Blum <josh@ettus.com> To: Tom Hendrick <sdtom182@yahoo.com> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines Message-ID: <5132344C.1060805@ettus.com> Content-Type: text/plain; charset=ISO-8859-1 On 03/01/2013 05:16 PM, Tom Hendrick wrote: > Josh, > > Thank you so much for the suggestion. I will try this. I have 4GB of > ram and a 4GB swapfile size. Do you recommend any particular setting > for set_max_output_buffer(long max_output_buffer)? > > Make it 10s of megabytes, see if it helps. > Should I leave tb.run() as is, or modify the number of n_output_items > in conjunction with the I think that part of the API is deprecated (the argument to run). There is a similar call on top block, but Im recommending just the usrp source block. > older gnuradio version had the fusb_block and fusb_nblocks both set > to 512*32 > Go with the default while trying the above. -josh > >> I've made this 4 channel work successfully with the same exact >> leave my dual boot setup intact. > set_max_output_buffer(long max_output_buffer) > mailing list Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ------------------------------ Message: 2 Date: Sat, 02 Mar 2013 20:40:09 +0100 From: "Ralph A. Schmid" <ralph@schmid.xxx> To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] branch next gone? Message-ID: <5196285.0JD8SFs8Gx@dk5ras> Content-Type: text/plain; charset="us-ascii" Hi, "git checkout next" on a new system does not work, "error: pathspec 'next' did not match any file(s) known to git". Branch "maint" is available. Do I smth. wrong? Ralph. ------------------------------ Message: 3 Date: Sat, 2 Mar 2013 14:52:58 -0500 From: Tom Rondeau <tom@trondeau.com> To: "Ralph A. Schmid" <ralph@schmid.xxx> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] branch next gone? Message-ID: <CA+SzT6h+Q-cuHvx1yPGNER7F+OmEMKbED=wWSmGztkCMOoo0DA@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 2, 2013 at 2:40 PM, Ralph A. Schmid <ralph@schmid.xxx> wrote: > Hi, > > "git checkout next" on a new system does not work, "error: pathspec 'next' did > not match any file(s) known to git". Branch "maint" is available. Do I smth. > wrong? > > Ralph. Everything looks good on the server. Try: git remote update origin Then you can do a "git remote show origin" to see what branches are available. Tom ------------------------------ Message: 4 Date: Sat, 02 Mar 2013 20:59:48 +0100 From: "Ralph A. Schmid" <ralph@schmid.xxx> To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] branch next gone? Message-ID: <1398337.V67Vjc39ot@dk5ras> Content-Type: text/plain; charset="us-ascii" Sorry, got it :) git clean -d -x -f made it. Obviously smth. was messed up... TNX! Ralph. On Saturday, March 02, 2013 02:52:58 PM you wrote: > > Try: git remote update origin > > Then you can do a "git remote show origin" to see what branches are > available. > > Tom ------------------------------ Message: 5 Date: Sat, 2 Mar 2013 15:22:59 -0800 (PST) From: Tom Hendrick <sdtom182@yahoo.com> To: "josh@ettus.com" <josh@ettus.com> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines Message-ID: <1362266579.18651.YahooMailNeo@web126003.mail.ne1.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" Josh thanks so much for the suggestion.? I left the tb.run() alone, and used the default settings for the uhd_usrp_probe --args call for setting the frame size and number of frames. I also just changed the buffer size for the usrp_source block by setting the following before the tb.run(): tb.uhd_usrp_source_0.set_max_output_buffer(50000000)? and I was getting overruns still.? I also tried setting it higher to 500000000 and still got overruns within about 10-20 seconds. Do you have any other quick suggestions?? I just went back to testing on the older gnuradio libusrp 4 channel version and ubuntu 10.04 for longer durations. It gives no overruns up until about 30 minutes of running.? This is at least usable. I wonder if the buffer settings on the older setup is higher then newer one.? I'm not sure how to determine this. Thanks, -Tom ________________________________ From: Josh Blum <josh@ettus.com> To: Tom Hendrick <sdtom182@yahoo.com> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Sent: Saturday, March 2, 2013 9:18 AM Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines On 03/01/2013 05:16 PM, Tom Hendrick wrote: > Josh, > > Thank you so much for the suggestion. I will try this.? I have 4GB of > ram and a 4GB swapfile size.? Do you recommend any particular setting > for set_max_output_buffer(long max_output_buffer)? > > Make it 10s of megabytes, see if it helps. > Should I leave tb.run() as is, or modify the number of n_output_items > in conjunction with the I think that part of the API is deprecated (the argument to run). There is a similar call on top block, but Im recommending just the usrp source block. > older gnuradio version had the fusb_block and? fusb_nblocks both set > to 512*32 > Go with the default while trying the above. -josh > >> I've made this 4 channel work successfully with the same exact >> leave my dual boot setup intact. > set_max_output_buffer(long max_output_buffer) > mailing list Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... ------------------------------ Message: 6 Date: Sat, 02 Mar 2013 18:25:52 -0500 From: "Marcus D. Leech" <mleech@ripnet.com> To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines Message-ID: <51328A80.4050906@ripnet.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > 500000000 and still got overruns within about 10-20 seconds. > > Do you have any other quick suggestions? I just went back to testing > on the older gnuradio libusrp 4 channel version and ubuntu 10.04 for > longer durations. It gives no overruns up until about 30 minutes of > running. This is at least usable. I wonder if the buffer settings on > the older setup is higher then newer one. I'm not sure how to > determine this. > > Thanks, -Tom > The frame size and number of frames settings are per-session, so setting them in uhd_usrp_probe will have no effect, as far as I know, on future sessions. -- 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... ------------------------------ Message: 7 Date: Sat, 2 Mar 2013 15:32:09 -0800 (PST) From: Tom Hendrick <sdtom182@yahoo.com> To: "Marcus D. Leech" <mleech@ripnet.com>, "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines Message-ID: <1362267129.27276.YahooMailNeo@web126003.mail.ne1.yahoo.com> Content-Type: text/plain; charset="iso-8859-1" Thanks Marcus, I also thought the same thing.? Just to be safe I had run the uhd_usrp_probe call with the default settings before trying the suggestions from Josh. ________________________________ From: Marcus D. Leech <mleech@ripnet.com> To: discuss-gnuradio@gnu.org Sent: Saturday, March 2, 2013 3:25 PM Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines Josh thanks so much for the suggestion.? >I left the tb.run() alone, and used the default settings for the uhd_usrp_probe --args call for setting the frame size and number of frames. > >I also just changed the buffer size for the usrp_source block by setting the following before the tb.run(): > >tb.uhd_usrp_source_0.set_max_output_buffer(50000000)? and I was getting overruns still.? I also tried setting it higher to >500000000 and still got overruns within about 10-20 seconds. > >Do you have any other quick suggestions?? I just went back to testing on the older gnuradio libusrp 4 channel version and ubuntu 10.04 for longer durations. It gives no overruns up until about 30 minutes of running.? This is at least usable. I wonder if the buffer settings on the older setup is higher then newer one.? I'm not sure how to determine this. > >Thanks, -Tom > > The frame size and number of frames settings are per-session, so setting them in uhd_usrp_probe will have no effect, as far as I know, on ? future sessions. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... ------------------------------ Message: 8 Date: Sun, 03 Mar 2013 04:12:50 +0100 From: Arturo Rinaldi <arty.net2@gmail.com> To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] GNU Radio releases 3.6.3.1 and 3.6.4 available for download Message-ID: <5132BFB2.8060700@gmail.com> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Il 26/02/13 23:59, Johnathan Corgan ha scritto: > MD5 sums: > Contributors: > Mike Jameson <mikejamo@gmail.com <mailto:mikejamo@gmail.com>> > > > > > > locations (Nicholas Corgan) > digital: improved constellation_receiver_cv documentation (Ben > uhd: added click to change freq for uhd_fft (Mike Jameson) > Corgan) > core: fixed missing include in gr_socket_pdu (Josh Blum) > oversampling. (Tom Rondeau) > examples (Mike Jameson) > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Are you planning to build the "deb" binaries for both these new releases of gnuradio ? thanks in advance, Arturo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... ------------------------------ Message: 9 Date: Sun, 03 Mar 2013 09:19:54 +0100 From: "Ralph A. Schmid" <ralph@schmid.xxx> To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] branch next - analolg FM modulators do not work? Message-ID: <2897471.qAvMe5nUyR@dk5ras> Content-Type: text/plain; charset="us-ascii" Hi, with branch "nect" I get an error like this wenn for example a simple NBFM or WBFM transmitter is built: howing: "/media/RAS_SD/Documents/Stereo-TX.grc" Generating: "/media/RAS_SD/Documents/top_block.py" Executing: "/media/RAS_SD/Documents/top_block.py" Traceback (most recent call last): File "/media/RAS_SD/Documents/top_block.py", line 9, in <module> from gnuradio import blks2 File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2/__init__.py", line 37, in <module> exec "from gnuradio.blks2impl.%s import *" % (f,) File "<string>", line 1, in <module> File "/usr/local/lib/python2.7/dist- packages/gnuradio/blks2impl/channel_model.py", line 26, in <module> channel_model = gr.channel_model AttributeError: 'module' object has no attribute 'channel_model' >>> Done Not a really big problem as still "master" works fine... Ralph. ------------------------------ Message: 10 Date: Sun, 3 Mar 2013 03:18:50 -0800 (PST) From: Sajjad Safdar <engrsajjadsafdar@yahoo.com> To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] Voice over IP using GNu Radio. Message-ID: <1362309530.43934.YahooMailNeo@web125003.mail.ne1.yahoo.com> Content-Type: text/plain; charset="us-ascii" HI, Is there any way of transmitting voice over ip using GNu Radio Companion. Best Regards, SAJJAD SAFDAR -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... ------------------------------ Message: 11 Date: Sun, 03 Mar 2013 07:54:51 -0500 From: Phil Frost <indigo@bitglue.com> To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Voice over IP using GNu Radio. Message-ID: <5133481B.1010208@bitglue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 03/03/2013 06:18 AM, Sajjad Safdar wrote: > Is there any way of transmitting voice over ip using GNu Radio Companion. To the extent that you can define what networking, modulation, and VoIP protocols you intend to use, yes. ------------------------------ Message: 12 Date: Sun, 3 Mar 2013 21:34:57 +0800 From: Yingjie Chen <ocgcyj@gmail.com> To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] how to compile the py file in gnuradio Message-ID: <CAFFXVuXmX-RnzR3odPCoDK8bF2fgodf+nZ5CEJ88u_ii+e09Pg@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi guys, I have checked the mailing list before, but cannot fine any useful information related to my question. I have done some modifications in ofdm.py file. And I want to rebuild or compile it, how should I do? I have try to use make install command, seems nothing happen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... ------------------------------ Message: 13 Date: Sun, 3 Mar 2013 06:24:48 -0800 From: Nicholas Corgan <nick.corgan@ettus.com> To: Yingjie Chen <ocgcyj@gmail.com> Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] how to compile the py file in gnuradio Message-ID: <CAGCyN2MzvLxR_JUqUCDew44b+acniq93kudFfncLv=KOpp3usw@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Python is an interpreted language, so unlike C++, you do not need to recompile your program to run it with your changes. On Sun, Mar 3, 2013 at 5:34 AM, Yingjie Chen <ocgcyj@gmail.com> wrote: > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Nicholas Corgan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... ------------------------------ Message: 14 Date: Sun, 3 Mar 2013 20:18:37 +0500 From: Sundus Tahir <13100013@lums.edu.pk> To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] Error building gnuradio 3.4.2 on ubuntu 12.04 (usrp_prims.cc file error) Message-ID: <7A80F55758161F48859007B788A905C001A0CF8659BC@E2K7EMC.lums.net> Content-Type: text/plain; charset="Windows-1252" Hello all, I am trying to build gnuradio 3.4.2 on ubuntu 12.04 and I am getting an error running the make -j 8 command. It is a swig problem, according to this discussion in the archives: "From: Tom Rondeau Subject: Re: [Discuss-gnuradio] Build error GNU Radio release v3.3.1git-971-ga02bb131 Date: Sun, 27 Feb 2011 17:38:48 -0500 On Sun, Feb 27, 2011 at 6:51 AM, Arya Santini <address@hidden> wrote: Hi Jared, thanks for that suggestion. Anyway, I realized that I was using GNU compiler gcc-4.6 (experimental) which apparently imposes stricter rules and allows package builds to fail where previous versions used to succeed. So the suggested fix for one typical "ptrdiff_t does not name a type" is #include <cstddef.h>, which I did in the /usrp/host/swig/python/usrp_prims.cc file, and the build completed to success. Arya Thanks for bringing this up (and for the solution). The usrp_prims.cc file is actually generated by SWIG, so I've explicitly included stddef.h into the .i file, which is done for most of the other SWIG files already for other reasons. This really seems like a SWIG problem, so hopefully this will be fixed in future releases before the new GCC takes over. Hopefully, this fixes our last hole, anyways. I'll be pushing changes to next and master soon. Tom" I have tried the solution suggested (including the cstddef.h file in usrp_prisms.cc) but this does not work. Can someone help me out with this? The error I get is as follows: "make[5]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/apps' Making all in swig make[5]: Entering directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/swig' make all-am make[6]: Entering directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/swig' /bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/firmware/include -I. -I/usr/include/python2.7 -I/usr/local/include -I/home/dfe/Archive/boost_1_44_0 -g -O1 -Wno-strict-aliasing -Wno-parentheses -I../../.. -pthread -MT _usrp_prims_la-usrp_prims.lo -MD -MP -MF .deps/_usrp_prims_la-usrp_prims.Tpo -c -o _usrp_prims_la-usrp_prims.lo `test -f 'python/usrp_prims.cc' || echo './'`python/usrp_prims.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/firmware/include -I. -I/usr/include/python2.7 -I/usr/local/include -I/home/dfe/Archive/boost_1_44_0 -g -O1 -Wno-strict-aliasing -Wno-parentheses -I../../.. -pthread -MT _usrp_prims_la-usrp_prims.lo -MD -MP -MF .deps/_usrp_prims_la-usrp_prims.Tpo -c python/usrp_prims.cc -fPIC -DPIC -o .libs/_usrp_prims_la-usrp_prims.o python/usrp_prims.cc: In function ?void SWIG_Python_AddErrorMsg(const char*)?: python/usrp_prims.cc:871:42: warning: format not a string literal and no format arguments [-Wformat-security] python/usrp_prims.cc: At global scope: python/usrp_prims.cc:2636:13: error: ?ptrdiff_t? does not name a type python/usrp_prims.cc:2662:21: error: expected ?;? at end of member declaration python/usrp_prims.cc:2662:39: error: expected ?)? before ?n? python/usrp_prims.cc:2677:34: error: declaration of ?operator+=? as non-function python/usrp_prims.cc:2677:30: error: expected ?;? at end of member declaration python/usrp_prims.cc:2677:44: error: expected ?)? before ?n? python/usrp_prims.cc:2682:34: error: declaration of ?operator-=? as non-function python/usrp_prims.cc:2682:30: error: expected ?;? at end of member declaration python/usrp_prims.cc:2682:44: error: expected ?)? before ?n? python/usrp_prims.cc:2687:33: error: declaration of ?operator+? as non-function python/usrp_prims.cc:2687:30: error: expected ?;? at end of member declaration python/usrp_prims.cc:2687:43: error: expected ?)? before ?n? python/usrp_prims.cc:2692:33: error: declaration of ?operator-? as non-function python/usrp_prims.cc:2692:30: error: expected ?;? at end of member declaration python/usrp_prims.cc:2692:43: error: expected ?)? before ?n? python/usrp_prims.cc:2697:5: error: ?ptrdiff_t? does not name a type python/usrp_prims.cc:2853:23: error: ?SWIG_From_ptrdiff_t? declared as an ?inline? variable python/usrp_prims.cc:2853:23: error: ?ptrdiff_t? was not declared in this scope python/usrp_prims.cc:2853:23: note: suggested alternatives: /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:156:28: note: ?std::ptrdiff_t? /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:156:28: note: ?std::ptrdiff_t? python/usrp_prims.cc:2854:1: error: expected ?,? or ?;? before ?{? token python/usrp_prims.cc:2906:39: error: ?ptrdiff_t? has not been declared python/usrp_prims.cc: In function ?int SWIG_AsVal_ptrdiff_t(PyObject*, int*)?: python/usrp_prims.cc:2910:50: error: expected type-specifier before ?ptrdiff_t? python/usrp_prims.cc:2910:50: error: expected ?>? before ?ptrdiff_t? python/usrp_prims.cc:2910:50: error: expected ?(? before ?ptrdiff_t? python/usrp_prims.cc:2910:50: error: ?ptrdiff_t? was not declared in this scope python/usrp_prims.cc:2910:50: note: suggested alternatives: /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:156:28: note: ?std::ptrdiff_t? /usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:156:28: note: ?std::ptrdiff_t? python/usrp_prims.cc:2910:64: error: expected ?)? before ?;? token python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator_distance(PyObject*, PyObject*, PyObject*)?: python/usrp_prims.cc:3365:52: error: ?const struct swig::PySwigIterator? has no member named ?distance? python/usrp_prims.cc:3371:67: error: ?SWIG_From_ptrdiff_t? cannot be used as a function python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator_advance(PyObject*, PyObject*, PyObject*)?: python/usrp_prims.cc:3534:58: error: ?arg1->swig::PySwigIterator::advance? cannot be used as a function python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator___iadd__(PyObject*, PyObject*, PyObject*)?: python/usrp_prims.cc:3653:60: error: ?struct swig::PySwigIterator? has no member named ?operator+=? python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator___isub__(PyObject*, PyObject*, PyObject*)?: python/usrp_prims.cc:3700:60: error: ?struct swig::PySwigIterator? has no member named ?operator-=? python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator___add__(PyObject*, PyObject*, PyObject*)?: python/usrp_prims.cc:3746:85: error: ?const struct swig::PySwigIterator? has no member named ?operator+? python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator___sub____SWIG_0(PyObject*, PyObject*)?: python/usrp_prims.cc:3787:85: error: ?const struct swig::PySwigIterator? has no member named ?operator-? python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator___sub____SWIG_1(PyObject*, PyObject*)?: python/usrp_prims.cc:3830:59: error: ?const struct swig::PySwigIterator? has no member named ?operator-? python/usrp_prims.cc:3831:67: error: ?SWIG_From_ptrdiff_t? cannot be used as a function make[6]: *** [_usrp_prims_la-usrp_prims.lo] Error 1 make[6]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/swig' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/swig' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2' make: *** [all] Error 2 " ------------------------------ Message: 15 Date: Sun, 3 Mar 2013 11:15:10 -0500 From: Tom Rondeau <tom@trondeau.com> To: "Ralph A. Schmid" <ralph@schmid.xxx> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] branch next - analolg FM modulators do not work? Message-ID: <CA+SzT6juXbtxQL8MXOSW-4feOw_jfvFga_38RD_CeMPjg1S32Q@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 3, 2013 at 3:19 AM, Ralph A. Schmid <ralph@schmid.xxx> wrote: > > AttributeError: 'module' object has no attribute 'channel_model' > >>>> Done > > Not a really big problem as still "master" works fine... > > Ralph. Ralph, We have discussed and warned about this on the mailing list with our move to the 3.7 API. Because we are making core changes to the API and in which modules the blocks exist, we know there are going to be breakages in the example code. We are waiting until we are done transitioning all of the blocks before we make a concerted effort to fix all of them. Basically, if we fixed them for every change we made, we'd just be repeatedly fixing them. The 'next' branch is not guaranteed to right now work with all of the effort going in to 3.7. Tom ------------------------------ Message: 16 Date: Sun, 3 Mar 2013 17:19:15 +0100 From: "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> To: <discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] FW: branch next - analolg FM modulators do not work? Message-ID: <002e01ce182a$d9e09430$8da1bc90$@schmid.xxx> Content-Type: text/plain; charset="US-ASCII" > Ralph, > > We have discussed and warned about this on the mailing list with our move > to the 3.7 API. Because we are making core changes to the API and in which > modules the blocks exist, we know there are going to be breakages in the > example code. We are waiting until we are done transitioning all of the blocks > before we make a concerted effort to fix all of them. Basically, if we fixed > them for every change we made, we'd just be repeatedly fixing them. The OK, fine. > 'next' branch is not guaranteed to right now work with all of the effort going > in to 3.7. I know, no problem :) Just wanted to mention it. > Tom Ralph. ------------------------------ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio End of Discuss-gnuradio Digest, Vol 124, Issue 3 ************************************************
on 2013-03-04 21:45
Sajjad, > > I am not sure whether it can be done by using TCP/UDP source/sink blocks, or some other way. U r right, it can be done using TCP/UDP blks OR u can use tuntap interface -Adeel
on 2013-03-04 22:57
Hi, I really did not get to ur point. I am trying to make transmit data via TCp/UDP source but not sure how to use these blocks, Becaus ethere is only one parameter for IP , it should be destination IP , then wat about the gateway , How data will be routed? Best Regards, SAJJAD SAFDAR ________________________________ From: Adeel Anwar <adeelanwr@gmail.com> To: Sajjad Safdar <engrsajjadsafdar@yahoo.com> Cc: discuss-gnuradio@gnu.org Sent: Monday, March 4, 2013 5:13 PM Subject: Re: [Discuss-gnuradio] Voice over IP using GNu Radio. Sajjad, > >I am not sure whether it can be done by using TCP/UDP source/sink blocks, or some other way. U r right, it can be done using TCP/UDP blks OR u can use tuntap interface -Adeel On Mon, Mar 4, 2013 at 7:02 AM, Sajjad Safdar <engrsajjadsafdar@yahoo.com> wrote: > > From: "discuss-gnuradio-request@gnu.org" <discuss-gnuradio-request@gnu.org> > discuss-gnuradio-request@gnu.org > 1. Re: LibUSRP vs LibUHD Performance on older machines (Josh Blum) > 2. branch next gone? (Ralph A. Schmid) > 3. Re: branch next gone? (Tom Rondeau) > 4. Re: branch next gone? (Ralph A. Schmid) > 5. Re: LibUSRP vs LibUHD Performance on older machines (Tom Hendrick) > 14. Error building gnuradio 3.4.2 on ubuntu 12.04 (usrp_prims.cc > file error) (Sundus Tahir) > 15. Re: branch next - analolg FM modulators do not work? (Tom Rondeau) >Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> >> Thank you so much for the suggestion. I will try this. I have 4GB of >I think that part of the API is deprecated (the argument to run). There >is a similar call on top block, but Im recommending just the usrp source >block. > >> >> void set_max_output_buffer(long max_output_buffer)? >> >> >> Also, do you recommend any particular settings using uhd_usrp_probe >> --args="serial=123456, recv_frame_size=XXXX,num_recv_frames=XXXX", >-josh >> >> >> >> On 03/01/2013 04:51 PM, Tom Hendrick wrote: >>> Hello all, >>> writing to file. >>> >>> >>> Has anyone else experienced performance differences between libusrp >>> and libuhd? I just want to make sure it isn't a configuration >>> problem or something I'm doing wrong causing the overruns. If its >>> likely an issue with libuhd, I guess I will just keep a backup of >> >>> >Message: 2 >Date: Sat, 02 Mar 2013 20:40:09 +0100 >From: "Ralph A. Schmid" <ralph@schmid.xxx> >To: discuss-gnuradio@gnu.org >Subject: [Discuss-gnuradio] branch next gone? >Message-ID: <5196285.0JD8SFs8Gx@dk5ras> >Content-Type: text/plain; charset="us-ascii" > > <CA+SzT6h+Q-cuHvx1yPGNER7F+OmEMKbED=wWSmGztkCMOoo0DA@mail.gmail.com> > >------------------------------ > >> > I smth. wrong? >> Tom >Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older >tb.uhd_usrp_source_0.set_max_output_buffer(50000000)? and I was getting overruns still.? I also tried setting it higher to >500000000 and still got overruns within about 10-20 seconds. > >Do you have any other quick suggestions?? I just went back to testing on the older gnuradio libusrp 4 channel version and ubuntu 10.04 for longer durations. It gives no overruns up until about 30 minutes of running.? This is at least usable. I wonder if the buffer settings on the older setup is higher then newer one.? I'm not sure how to determine this. >Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org> >Sent: Saturday, March 2, 2013 9:18 AM >Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines > > > >On 03/01/2013 05:16 PM, Tom Hendrick wrote: >> Josh, >> >> Thank you so much for the suggestion. I will try this.? I have 4GB of >I think that part of the API is deprecated (the argument to run). There >> >> >> or should I leave it default?? The custom 4 channel usrp block in the >> older gnuradio version had the fusb_block and? fusb_nblocks both set >> >>> >>> I've had trouble making a 4 channel USRP samples at 1Ms/s write to >>> file at 500 kS/s with ubuntu 12.04 and libuhd.? I am getting >>> several overruns and I had tried adjusting some of the parameters >>> using usrd_probe_devices but with no success. I have a laptop with >>> problem or something I'm doing wrong causing the overruns.? If its >>> likely an issue with libuhd, I guess I will just keep a backup of >>> ubuntu 10.04 and gnuradio libusrp version installation files and >>> leave my dual boot setup intact. >>> >>> Thank you very much, - Tom >>> >>> >> >> You might try setting a very large output buffer on the usrp source >>> _______________________________________________ Discuss-gnuradio >URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... >Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" >> getting overruns still. I also tried setting it higher to >> 500000000 and still got overruns within about 10-20 seconds. >> >> Do you have any other quick suggestions? I just went back to testing >> on the older gnuradio libusrp 4 channel version and ubuntu 10.04 for >> longer durations. It gives no overruns up until about 30 minutes of > >------------------------------ >Content-Type: text/plain; charset="iso-8859-1" >Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older machines > > >Josh thanks so much for the suggestion.? >>I left the tb.run() alone, and used the default settings for the >>Do you have any other quick suggestions?? I just went back to > testing on the older gnuradio libusrp 4 channel version and > ubuntu 10.04 for longer durations. It gives no overruns up until > about 30 minutes of running.? This is at least usable. I wonder > if the buffer settings on the older setup is higher then newer >-- >An HTML attachment was scrubbed... >Message-ID: <5132BFB2.8060700@gmail.com> >Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > >Il 26/02/13 23:59, Johnathan Corgan ha scritto: >> GNU Radio releases 3.6.3.1 and 3.6.4 are now available for download. >> >> >> Nicholas Corgan <nick.corgan@ettus.com >> Tom Rondeau has implemented the ability to set processor >> Inclusion of gr_modtool by Martin Braun >> Use of GNU Radio preferences in native C++ applications >> >> Addition of GNU Radio block performance counters >> >> Tom Rondeau has implemented a new capability to allow monitoring >> of peformance statistics of blocks inside a running >> blocks: added 3.7 API versions of count_bits, threshold, strech, >> throttle (Tom Rondeau) >> blocks: added 3.7 API versions of peak_detector2, regenerate, >> transcendental (Tom Rondeau) >> cmake: added Fedora 18 packaging information (Nicholas Corgan) >> core: added a mutex to gr_block to sync setters and work >> function (Tom Rondeau) >> digital: improved constellation_receiver_cv documentation (Ben >> uhd: added click to change freq for uhd_fft (Mike Jameson) >> wxgui: dead code removal and formatting cleanup (Sylvain Munaut) >> wxgui: implemented persistence without using glAccum (Sylvain >> Munaut) >> >> >> Bug fixes (3.6.3.1, 3.6.4): >> cmake: disable certain Boost versions we know are buggy to fix >> Issue #513. (Tom Rondeau) >> cmake: fixing generated includes, deps, and header installation. >> core: fixed gr_pdu_to_tagged_stream XML for type (Johnathan Corgan) >> core: fixed gr_message_debug for printing PDUs (Johnathan Corgan) >> filter: fixed synthesis filter output rate when using 2x >> oversampling. (Tom Rondeau) >> grc: fixed failing drag-n-drop in GRC on Windows (Balint Seeber) >> grc: fixed Bug #485 by gracefully exiting (Martin Braun) >> volk: fixed cmake, the profiler is no longer strictly unix (Josh >> Blum) >> volk: fixed volk_profile MSVC incompatibility (Nicholas Corgan) > >thanks in advance, Arturo >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: <http://lists.gnu.org/archive/html/discuss-gnuradio... > >------------------------------ > >Message: 9 >Date: Sun, 03 Mar 2013 09:19:54 +0100 >From: "Ralph A. Schmid" <ralph@schmid.xxx> > >howing: "/media/RAS_SD/Documents/Stereo-TX.grc" > >Generating: "/media/RAS_SD/Documents/top_block.py" > >Executing: "/media/RAS_SD/Documents/top_block.py" > >Traceback (most recent call last): > File "/media/RAS_SD/Documents/top_block.py", line 9, in <module> > from gnuradio import blks2 > File "/usr/local/lib/python2.7/dist-packages/gnuradio/blks2/__init__.py", >Not a really big problem as still "master" works fine... >Date: Sun, 3 Mar 2013 03:18:50 -0800 (PST) > >Date: Sun, 03 Mar 2013 07:54:51 -0500 >To the extent that you can define what networking, modulation, and VoIP >protocols you intend to use, yes. >Message-ID: > <CAFFXVuXmX-RnzR3odPCoDK8bF2fgodf+nZ5CEJ88u_ii+e09Pg@mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >Hi guys, > >I have checked the mailing list before, but cannot fine any useful >information related to my question. I have done some modifications in >ofdm.py file. And I want to rebuild or compile it, how should I do? I >have try to use make install command, seems nothing happen. >Cc: discuss-gnuradio@gnu.org >Subject: Re: [Discuss-gnuradio] how to compile the py file in gnuradio >Message-ID: > <CAGCyN2MzvLxR_JUqUCDew44b+acniq93kudFfncLv=KOpp3usw@mail.gmail.com> >> I have checked the mailing list before, but cannot fine any useful >> >Message: 14 > >I am trying to build gnuradio 3.4.2 on ubuntu 12.04 and I am getting an error running the make -j 8 command. It is a swig problem, according to this discussion in the archives: > >"From: Tom Rondeau >Subject: Re: [Discuss-gnuradio] Build error GNU Radio release v3.3.1git-971-ga02bb131 > /usrp/host/swig/python/usrp_prims.cc file, and the build completed to > success. > > Arya > > >Thanks for bringing this up (and for the solution). The usrp_prims.cc file is actually generated by SWIG, so I've explicitly included stddef.h into the .i file, which is done for most of the other SWIG files already for other reasons. This really seems like a SWIG problem, so hopefully this will be fixed in future releases before the new GCC takes over. Hopefully, this fixes our last hole, anyways. >make[5]: Entering directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/swig' >make all-am >make[6]: Entering directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/swig' >/bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/firmware/include -I. -I/usr/include/python2.7 -I/usr/local/include -I/home/dfe/Archive/boost_1_44_0 -g -O1 -Wno-strict-aliasing -Wno-parentheses -I../../.. -pthread -MT _usrp_prims_la-usrp_prims.lo -MD -MP -MF .deps/_usrp_prims_la-usrp_prims.Tpo -c -o _usrp_prims_la-usrp_prims.lo `test -f 'python/usrp_prims.cc' || echo './'`python/usrp_prims.cc >libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/include -I/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/firmware/include -I. -I/usr/include/python2.7 -I/usr/local/include -I/home/dfe/Archive/boost_1_44_0 -g -O1 -Wno-strict-aliasing -Wno-parentheses -I../../.. -pthread -MT _usrp_prims_la-usrp_prims.lo -MD -MP -MF .deps/_usrp_prims_la-usrp_prims.Tpo -c python/usrp_prims.cc -fPIC -DPIC -o .libs/_usrp_prims_la-usrp_prims.o >python/usrp_prims.cc:2682:30: error: expected ?;? at end of member declaration >python/usrp_prims.cc:2853:23: note: suggested alternatives: >/usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:156:28: note: ?std::ptrdiff_t? >/usr/include/c++/4.6/i686-linux-gnu/./bits/c++config.h:156:28: note: ?std::ptrdiff_t? >python/usrp_prims.cc:2910:64: error: expected ?)? before ?;? token >python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator_distance(PyObject*, PyObject*, PyObject*)?: >python/usrp_prims.cc:3365:52: error: ?const struct swig::PySwigIterator? has no member named ?distance? >python/usrp_prims.cc:3371:67: error: ?SWIG_From_ptrdiff_t? cannot be used as a function >python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator_advance(PyObject*, PyObject*, PyObject*)?: >python/usrp_prims.cc:3534:58: error: ?arg1->swig::PySwigIterator::advance? cannot be used as a function >python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator___iadd__(PyObject*, PyObject*, PyObject*)?: >python/usrp_prims.cc:3653:60: error: ?struct swig::PySwigIterator? has no member named ?operator+=? >python/usrp_prims.cc: In function ?PyObject* _wrap_PySwigIterator___isub__(PyObject*, PyObject*, PyObject*)?: >python/usrp_prims.cc:3700:60: error: ?struct swig::PySwigIterator? has no member named ?operator-=? >make[5]: Leaving directory `/home/ayiesha/Downloads/gnuradio-3.4.2/usrp/host/swig' > >Subject: Re: [Discuss-gnuradio] branch next - analolg FM modulators do >> >> howing: "/media/RAS_SD/Documents/Stereo-TX.grc" >> >> Generating: "/media/RAS_SD/Documents/top_block.py" >> File "/usr/local/lib/python2.7/dist- >> packages/gnuradio/blks2impl/channel_model.py", line 26, in <module> >> channel_model = gr.channel_model >> AttributeError: 'module' object has no attribute 'channel_model' >> >>>>> Done >> >> Not a really big problem as still "master" works fine... >> >> Ralph. >we'd just be repeatedly fixing them. The 'next' branch is not >From: "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> >> modules the blocks exist, we know there are going to be breakages in the >> example code. We are waiting until we are done transitioning all of the >blocks >> before we make a concerted effort to fix all of them. Basically, if we >fixed >> them for every change we made, we'd just be repeatedly fixing them. The > >OK, fine. > >> 'next' branch is not guaranteed to right now work with all of the effort
Enable email notification
Enable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.