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-gnuradioor, via email, send a message with subject or body 'help' to
address@hiddenYou 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. 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 <
address@hidden>
To: Tom Hendrick <
address@hidden>
Cc: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older
machines
Message-ID: <
address@hidden>
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.
>
> 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",
> send_frame_size=XXXX,send_recv_frames=XXX"
>
>
> 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
> to 512*32
>
Go with the default while trying the above.
-josh
> Thanks, -Tom
>
>
>
>
> ________________________________ From: Josh Blum <
address@hidden> To:
>
address@hidden Sent: Friday, March 1, 2013 2:55 PM Subject:
> Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older
> machines
>
>
>
> On 03/01/2013 04:51 PM, Tom Hendrick wrote:
>> Hello
all,
>>
>> 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
>> a duo core centrino processor which should be enough.
>>
>> I've made this 4 channel work successfully with the same exact
>> laptop and with ubuntu 10.04 and the older version of gnuradio that
>> uses libusrp. I get no underruns at all even for an entire hour of
>> 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
>> 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
> block. I heard this helps (you should be able to call this in python
> after the block constructs):
>
> /*! * \brief Sets max buffer size on all output ports. */ void
> set_max_output_buffer(long max_output_buffer)
>
> -josh
------------------------------
Message: 2
Date: Sat, 02 Mar 2013 20:40:09 +0100
From: "Ralph A. Schmid" <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] branch next gone?
Message-ID: <address@hidden>
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 <
address@hidden>
To: "Ralph A. Schmid" <
address@hidden>
Cc: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] branch next gone?
Message-ID:
<CA+SzT6h+Q-cuHvx1yPGNER7F+OmEMKbED=
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Mar 2, 2013 at 2:40 PM, Ralph A. Schmid <
address@hidden> 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" <
address@hidden>
To:
address@hiddenSubject: Re: [Discuss-gnuradio] branch next gone?
Message-ID: <address@hidden>
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:
> On Sat, Mar 2, 2013 at 2:40 PM, Ralph A. Schmid <
address@hidden> 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: 5
Date: Sat, 2 Mar 2013 15:22:59 -0800 (PST)
From: Tom Hendrick <
address@hidden>
To: "
address@hidden" <
address@hidden>
Cc: "
address@hidden" <
address@hidden>
Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older
machines
Message-ID:
<
address@hidden>
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 <
address@hidden>
To: Tom Hendrick <
address@hidden>
Cc: "
address@hidden" <
address@hidden>
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.
>
> 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",
> send_frame_size=XXXX,send_recv_frames=XXX"
>
>
> 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
> to 512*32
>
Go with the default while trying the above.
-josh
> Thanks, -Tom
>
>
>
>
> ________________________________ From: Josh Blum <
address@hidden> To:
>
address@hidden Sent: Friday, March 1, 2013 2:55 PM Subject:
> Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older
> machines
>
>
>
> On 03/01/2013 04:51 PM, Tom Hendrick wrote:
>> Hello all,
>>
>> 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
>> a duo core centrino processor which should be enough.
>>
>> I've made this 4 channel work successfully with the same exact
>> laptop and with ubuntu 10.04 and the older version of gnuradio that
>> uses libusrp.? I get no underruns at all even for an entire hour of
>> 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
>> 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
> block. I heard this helps (you should be able to call this in python
> after the block constructs):
>
> /*! * \brief Sets max buffer size on all output ports. */ void
> set_max_output_buffer(long max_output_buffer)
>
> -josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130302/da9eb8bc/attachment.html>
------------------------------
Message: 6
Date: Sat, 02 Mar 2013 18:25:52 -0500
From: "Marcus D. Leech" <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older
machines
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> 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-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130302/3674b8f4/attachment.html>
------------------------------
Message: 7
Date: Sat, 2 Mar 2013 15:32:09 -0800 (PST)
From: Tom Hendrick <
address@hidden>
To: "Marcus D. Leech" <
address@hidden>, "
address@hidden"
<
address@hidden>
Subject: Re: [Discuss-gnuradio] LibUSRP vs LibUHD Performance on older
machines
Message-ID:
<
address@hidden>
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 <
address@hidden>
To:
address@hidden
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 -------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130302/5dbbd03e/attachment.html>
------------------------------
Message: 8
Date: Sun, 03 Mar 2013 04:12:50 +0100
From: Arturo Rinaldi <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] GNU Radio releases 3.6.3.1 and 3.6.4
available for download
Message-ID: <
address@hidden>
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.
>
> Release 3.6.3.1 is a bug-fix only update to 3.6.3, and has no new
> features.
>
> Release 3.6.4 has both bug fixes and new features.
>
>
http://gnuradio.org/releases/gnuradio/gnuradio-3.6.3.1.tar.gz>
http://gnuradio.org/releases/gnuradio/gnuradio-3.6.4.tar.gz
>
> MD5 sums:
>
> c05a20a380532b7bce45465ba247f2d6 gnuradio-3.6.3.1.tar.gz
> 320a7f18593ec493e1061141f23c9a86 gnuradio-3.6.4.tar.gz
>
> Enjoy!
>
> Johnathan Corgan
> Corgan Labs
>
>
> Contributors:
>
> Balint Seeber <
address@hidden > <mailto:
address@hidden>>
> Ben Reynwar <
address@hidden <mailto:
address@hidden>>
> Johnathan Corgan <
address@hidden
> <mailto:
address@hidden>>
> Josh Blum <
address@hidden <mailto:
address@hidden>>
> Julien Olivain <
address@hidden > <mailto:
address@hidden>>
> Martin Braun <
address@hidden <mailto:
address@hidden>>
> Mike Jameson <
address@hidden <mailto:
address@hidden>>
> Nicholas Corgan
<
address@hidden > <mailto:
address@hidden>>
> Roy Thompson <
address@hidden <mailto:
address@hidden>>
> Sylvain Munaut <
address@hidden <mailto:
address@hidden>>
> Tim O'Shea <
address@hidden <mailto:
address@hidden>>
> Tom Rondeau <
address@hidden <mailto:
address@hidden>>
>
> Important new features (3.6.4):
>
> Ability to set processor affinity for GNU Radio blocks
>
> Tom Rondeau has implemented the ability to set processor
> affinity per block in a flowgraph. This allows the developer to
> limit the execution of a GNU Radio block thread to a set of one
> or more cores, helping optimize inter-core resources in a
> multicore system.
>
> See:
>
>
http://www.trondeau.com/home/2013/2/7/block-core-affinity.html
>
>
> Inclusion of gr_modtool by Martin Braun
>
> Previously available as a stand-alone utility, the gr_modtool
> application for creating out-of-tree GNU Radio blocks has been
> integrated within the main GNU Radio software distribution. The
> features and functionality are the same, but it is now no longer
> necessary to download this separately. See:
>
>
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules>
>
> Use of GNU Radio preferences in native C++
applications
>
> Tom Rondeau has ported the GNU Radio preferences system to allow
> its use in GNU Radio applications implemented in C++. Prior to
> this, it was only possible to access the preferences file from
> Python. Until the new manual is updated on
gnuradio.org > <
http://gnuradio.org>, you
> can see the raw commit here:
>
>
http://gnuradio.org/cgit/gnuradio.git/commit/?id=3643a858>
>
> 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
> flowgraph. This is an experimental feature that has not received
> a great deal of usage. For more details, see:
>
>
http://gnuradio.org/redmine/projects/gnuradio/wiki/PerformanceCounters
>
>
> Minor features/changes (3.6.4):
>
> atsc: added single decode Python script (Ben Reynwar)
> atsc: made equalizer taps accessible in python. (Ben Reynwar)
> 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)
> cmake: allow 64-bit systems to use Boost in non-standard
> locations (Nicholas Corgan)
> core: added min_noutput_items to gr_block API (Ben Reynwar)
> core: added operator == for tags (Martin Braun)
> core: added remove_tag_item() (Martin Braun)
> core: enabled msg_connect within python blocks (Roy Thompson)
> core: added gr_random_pdu message passing block (Tim O'Shea)
> core: added gr_fastnoise_source, default for gr_channel_model
> (Tim O'Shea)
> core: added GRC callback for gr_throttle sample_rate (Tim O'Shea)
> core: added a mutex to gr_block to sync setters and work
> function (Tom Rondeau)
> digital: improved constellation_receiver_cv documentation
(Ben
> Reynwar)
> digital: made the demod examples clearer (Martin Braun)
> digital: added simple_correlator (inverse of simple_framer) to
> gr-digital.
> gruel: changed scoped_lock mutex to account for Boost
> deprecation (Johnathan Corgan)
> grc: pull in documentation for blocks from other GR modules.
> (Julien Olivain)
> howto: added example for Python blocks (Martin Braun)
> pmt: added python converters (Martin Braun)
> 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):
>
> analog: fixed floating point accuracy issue in CTCSS squelch
> (Tom Rondeau)
> blocks: fixed use of bare boost::mutex::scoped_lock (Johnathan
> Corgan)
> blocks: fixed missing include in file_source_impl (Josh Blum)
> cmake: fixed chrono as a necessary Boost library under MSVC
> (Nicholas Corgan)
> cmake: allow user to override check for bad versions of boost
> (Tom Rondeau)
> 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)
> core: fixed missing include in gr_socket_pdu (Josh Blum)
> core: fixed missing include for gruel thread (Josh Blum)
> core: fixed redundant test settings (Josh Blum)
> core: fixed gr_random_pdu MSVC incompatibility issue (Nicholas
> Corgan)
> core: fixed missing include to gr_block_registry.h (Tim O'Shea)
> digital: fixed bug in digital_bert_rx.py (Ben Reynwar)(thanks
> Charles Ru)
> digital: fixed pfb_clock_sync grc xml file for loop bandwidth
> (Ben Reynwar)
> 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)
> grc: fixed problem of GRC_BLOCKS_PATH not being set in Windows
> (Nicholas Corgan)
> howto: fixed block parameters documentation (Julien Olivain)
> uhd: fixed gain defaults in usrp_wfm_rcv*.py examples (Mike Jameson)
> uhd: fixed default midpoint gain for usrp_am_mw_rcv.py example
> (Mike Jameson)
> uhd: fixed usrp_nbfm_ptt.py example receive path (Mike Jameson)
> uhd: fixed audio_alsa_sink busy using default in several
> examples (Mike Jameson)
> volk: fixed bad find_package missing components (Josh Blum)
> volk: fixed cmake, the profiler is no longer strictly unix (Josh
> Blum)
> volk: fixed volk_profile MSVC incompatibility (Nicholas
Corgan)
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/attachments/20130303/e0a4da48/attachment.html>
------------------------------
Message: 9
Date: Sun, 03 Mar 2013 09:19:54 +0100
From: "Ralph A.
Schmid" <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] branch next - analolg FM modulators do not
work?
Message-ID: <address@hidden>
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 <
address@hidden>
To: "
address@hidden"
<
address@hidden>
Subject: [Discuss-gnuradio] Voice over IP using GNu Radio.
Message-ID:
<
address@hidden>
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/attachments/20130303/a306df36/attachment.html>
------------------------------
Message: 11
Date: Sun, 03 Mar 2013 07:54:51 -0500
From: Phil Frost <
address@hidden>
To:
address@hidden
Subject: Re: [Discuss-gnuradio] Voice over IP using GNu Radio.
Message-ID: <
address@hidden>
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 <
address@hidden>
To:
address@hiddenSubject: [Discuss-gnuradio] how to compile the py file in gnuradio
Message-ID:
<CAFFXVuXmX-RnzR3odPCoDK8bF2fgodf+nZ5CEJ88u_ii+
address@hidden>
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/attachments/20130303/a9a2035f/attachment.html>
------------------------------
Message: 13
Date: Sun, 3 Mar 2013 06:24:48 -0800
From: Nicholas Corgan <
address@hidden>
To: Yingjie Chen <
address@hidden>
Cc:
address@hiddenSubject: Re: [Discuss-gnuradio] how to compile the py file in gnuradio
Message-ID:
<CAGCyN2MzvLxR_JUqUCDew44b+acniq93kudFfncLv=
address@hidden>
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 <
address@hidden> wrote:
> 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.
--
Nicholas Corgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130303/d27c09ce/attachment.html>
------------------------------
Message: 14
Date: Sun, 3 Mar 2013 20:18:37 +0500
From: Sundus Tahir <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Discuss-gnuradio] Error building gnuradio 3.4.2 on ubuntu
12.04 (usrp_prims.cc file error)
Message-ID:
<
address@hidden>
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 <
address@hidden>
To: "Ralph A. Schmid" <
address@hidden>
Cc: GNURadio Discussion List <
address@hidden>
Subject: Re: [Discuss-gnuradio] branch next - analolg FM modulators do
not work?
Message-ID:
<CA+
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Mar 3, 2013 at 3:19 AM, Ralph A. Schmid <
address@hidden> wrote:
> 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.
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" <
address@hidden>
To: <
address@hidden>
Subject: [Discuss-gnuradio] FW: branch next - analolg FM modulators do
not work?
Message-ID: <address@hidden>
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.
------------------------------
End of Discuss-gnuradio Digest, Vol 124, Issue 3
************************************************