Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 124, Issue 13

[Elvin Mollinedo Mencia]

Estimados señores ettus


Quisiera q me ayuden con mi usrp 2 con quien puedo contactarse para hacerme 
acesorar como puedo hacer una central telefónica con el proyecto OPEn bts, 
agradeciendo su ayuda.


Saludos 
Elvin Mollinedo
Santa Cruz - Bolivia 

Enviado desde mi iPhone

El 13/03/2013, a las 12:02, address@hidden escribió:

> 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. changing carrier map in ofdm (Sahoo, Anirudha)
>   2. Re: Copyrights using gr-modtool (Sean Nowlan)
>   3. Error when compiling signal processing block (Brooke Hayden)
>   4. Re: Reg:Tags_demo.cc example (Josh Blum)
>   5. Re: Reg:Tags_demo.cc example (Sean Nowlan)
>   6. Re: Copyrights using gr-modtool (Tom Rondeau)
>   7. Re: Copyrights using gr-modtool (Sean Nowlan)
>   8. Re: Reg:Tags_demo.cc example (Josh Blum)
>   9. Re: Copyrights using gr-modtool (Tom Rondeau)
>  10. IndexError: gr_firdes check failed: 0 < fa <=    sampling_freq /
>      2 (address@hidden)
>  11. Building a transport layer (M. Ranganathan)
>  12. Flexible RF, Picasso, one paper from SIGCOMM 2012 (Lin HUANG)
>  13. error while running the .cc files in gr-bluetooth (john)
>  14. adding python block to gnuradio (Mohammed Ramadan)
>  15. Re: adding python block to gnuradio (Nathan West)
>  16. Re: adding python block to gnuradio (Mike Jameson)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 12 Mar 2013 12:03:07 -0400
> From: "Sahoo, Anirudha" <address@hidden>
> To: "address@hidden" <address@hidden>
> Subject: [Discuss-gnuradio] changing carrier map in ofdm
> Message-ID:
>    <address@hidden>
>    
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi,
>  I have modified "benchmark_ofdm_rx.py" (and tx) so that the transmitter and 
> receiver
> can change the subcarrier map (based on some event, e.g., sensing outcome) and
> send packet with the new carrier map.  I have a simple handshake protocol 
> through
> which the sender and receiver synchronize their carrier map setting.
> I am seeing the following problem:
>  Even though the two sides are with the same carrier map, sometimes the 
> receiver
> does not receive packets (although sender is sending the packets). This 
> happens
> at a very high rate. At other times packets are received correctly.  The 
> sender and
> the receiver (USRP N210) are connected through a channel emulator, which 
> emulates a perfect
> channel (so it could not be because of channel error).
> 
>    As per my understanding, resetting carrier map (done in 
> "digital_ofdm_mapper_bcv.cc") is
> asynchronous. So, the python layer resets the carrier map and then at a later 
> time the ofdm_mapper
> actually sets the carrier map in the usrp device (through its "work()" 
> function). So, I thought, perhaps
> the receiver is not ready to receive next set of packets using the new 
> carrier map. So, I put a
> sleep(0.5sec) on the sender side after sender resets its carrier map to give 
> enough time to the
> receiver. But that did not fix the problem.
>   Will appreciate if someone can let me know what could be the problem and 
> how to fix it.
> 
> thanks and regards
> 
> --Anirudh Sahoo
> Advanced Network Technology Div.
> National Institute of Standards and Technology (NIST)
> 100 Bureau Drive,
> Gaithersburg, MD - 20878
> Room - B230, bldg.- 222
> Phone- 301-975-4439
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130312/40629b4d/attachment.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 12 Mar 2013 13:36:26 -0400
> From: Sean Nowlan <address@hidden>
> To: <address@hidden>
> Subject: Re: [Discuss-gnuradio] Copyrights using gr-modtool
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> 
> On 03/12/2013 11:24 AM, Tom Rondeau wrote:
>> On Tue, Mar 12, 2013 at 11:22 AM, Martin Braun (CEL)
>> <address@hidden> wrote:
>>> On Tue, Mar 12, 2013 at 11:04:20AM -0400, Tom Rondeau wrote:
>>>> On Tue, Mar 12, 2013 at 10:29 AM, Sean Nowlan
>>>> <address@hidden> wrote:
>>>>> I've noticed that gr-modtool keeps FSF's copyright assignment for a lot of
>>>>> boilerplate (CMakeLists.txt, QA code, etc.) but puts a hook for the end
>>>>> user's copyright statement in block source files. Is this a pretty 
>>>>> standard
>>>>> way of doing things?
>>>> Yes, pretty much. Of course, this is just my understanding of how
>>>> copyright of works is handled, and obviously IAMAL.
>>> I assume you meant 'IANAL'. It kind of reads the opposite way :)
>>> 
>>> MB
>> Yeah, typo....
>> 
>> Tom
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> With the understanding that I will *not* take any answers as *actual* 
> legal advice, is it generally reasonable to say:
> 1) If I copy a gnuradio block (copyright FSF), tweak a few things, and 
> redistribute, FSF retains copyright and I have no copyright to the changes
> 2) If I build a block from the ground up, it's still GPLv3 since it 
> depends on gnuradio, but I may either maintain copyright or assign it to FSF
> 
> --sean
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130312/9d04a6b1/attachment.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 12 Mar 2013 13:58:31 -0400
> From: Brooke Hayden <address@hidden>
> To: address@hidden
> Subject: [Discuss-gnuradio] Error when compiling signal processing
>    block
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset="windows-1252"
> 
> Hi all,
> 
> I am trying to create my own version of a UHD USRP Sink. I am essentially
> trying to get the current uhd_usrp_sink code to work in my own module right
> now and I have narrowed down my errors to only one centered around the
> gr_uhd_check_abi function. I don't really know what it does or where it is
> declared. I searched around and could not find what it does or where the
> function is actually defined within the GNU Radio framework. I feel like I
> may be missing an include statement, but I'm not even sure that's the
> problem. My code is almost identical to the code in the uhd_usrp_sink .cc
> and .h files. If anyone else has had this error or knows how to fix it I
> would greatly appreciate your feedback. I have included the error output
> below.
> 
> Thanks,
> ONU SDR Team
> 
> /home/sdr/RadarWaveforms/gr-radar/lib/lfm_sink_impl.cc: In function
> ?boost::shared_ptr<uhd_usrp_lfm_sink> uhd_make_usrp_lfm_sink(const
> uhd::device_addr_t&, const uhd::stream_args_t&)?:
> /home/sdr/RadarWaveforms/gr-radar/lib/lfm_sink_impl.cc:510:22: error:
> ?gr_uhd_check_abi? was not declared in this scope
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130312/98b72e57/attachment.html>
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 12 Mar 2013 13:14:11 -0500
> From: Josh Blum <address@hidden>
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Reg:Tags_demo.cc example
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 
> 
> On 03/11/2013 09:52 PM, john jade wrote:
>> Hi,
>> 
>> 1. What is get_full_seconds and get_frac_seconds printing?
> 
> Its probably the receive timestamp, its the time stamp from this object:
> 
> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html
> 
>> 2.Can we get upto precision of nano seconds using the above methods and
>> please tell me how to do it.
> 
> The fractional seconds are stored as double precision floating point.
> This gives the fractional seconds enough precision to unambiguously
> specify a clock-tick/sample-count up to rates of several petahertz.
> 
> -josh
> 
>> In the frac seconds i am getting 0.xxxxxx(only 6 digits after point-micro
>> seconds)
>> 
>> Thanks
>> 
>> 
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 12 Mar 2013 15:36:44 -0400
> From: Sean Nowlan <address@hidden>
> To: <address@hidden>
> Subject: Re: [Discuss-gnuradio] Reg:Tags_demo.cc example
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> 
> On 03/12/2013 02:14 PM, Josh Blum wrote:
>> 
>> On 03/11/2013 09:52 PM, john jade wrote:
>>> Hi,
>>> 
>>> 1. What is get_full_seconds and get_frac_seconds printing?
>> Its probably the receive timestamp, its the time stamp from this object:
>> 
>> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html
>> 
>>> 2.Can we get upto precision of nano seconds using the above methods and
>>> please tell me how to do it.
>> The fractional seconds are stored as double precision floating point.
>> This gives the fractional seconds enough precision to unambiguously
>> specify a clock-tick/sample-count up to rates of several petahertz.
> Although time can be *represented* with petahertz+ resolution, doesn't 
> the hardware clock constrain the *realizable* resolution? For example on 
> a USRP with a 100 MHz FPGA clock, would actual transmit precision be 
> limited to 10 ns?
> 
>> -josh
>> 
>>> In the frac seconds i am getting 0.xxxxxx(only 6 digits after point-micro
>>> seconds)
>>> 
>>> Thanks
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 12 Mar 2013 15:56:27 -0400
> From: Tom Rondeau <address@hidden>
> To: Sean Nowlan <address@hidden>
> Cc: GNURadio Discussion List <address@hidden>
> Subject: Re: [Discuss-gnuradio] Copyrights using gr-modtool
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Tue, Mar 12, 2013 at 1:36 PM, Sean Nowlan
> <address@hidden> wrote:
>> On 03/12/2013 11:24 AM, Tom Rondeau wrote:
>> 
>> On Tue, Mar 12, 2013 at 11:22 AM, Martin Braun (CEL)
>> <address@hidden> wrote:
>> 
>> On Tue, Mar 12, 2013 at 11:04:20AM -0400, Tom Rondeau wrote:
>> 
>> On Tue, Mar 12, 2013 at 10:29 AM, Sean Nowlan
>> <address@hidden> wrote:
>> 
>> I've noticed that gr-modtool keeps FSF's copyright assignment for a lot of
>> boilerplate (CMakeLists.txt, QA code, etc.) but puts a hook for the end
>> user's copyright statement in block source files. Is this a pretty standard
>> way of doing things?
>> 
>> Yes, pretty much. Of course, this is just my understanding of how
>> copyright of works is handled, and obviously IAMAL.
>> 
>> I assume you meant 'IANAL'. It kind of reads the opposite way :)
>> 
>> MB
>> 
>> Yeah, typo....
>> 
>> Tom
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> With the understanding that I will *not* take any answers as *actual* legal
>> advice, is it generally reasonable to say:
>> 1) If I copy a gnuradio block (copyright FSF), tweak a few things, and
>> redistribute, FSF retains copyright and I have no copyright to the changes
> 
> No, that's not what I said (or at least meant). The code generated
> from gr-modtool is copyrighted by the FSF. If you add any
> modifications to the file, that new code will be your copyright. You
> would then add a copyright notice into the file to say that this is
> copyright you, 2013.
> 
>> 2) If I build a block from the ground up, it's still GPLv3 since it depends
>> on gnuradio, but I may either maintain copyright or assign it to FSF
>> 
>> --sean
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Tue, 12 Mar 2013 16:07:58 -0400
> From: Sean Nowlan <address@hidden>
> To: Tom Rondeau <address@hidden>
> Cc: GNURadio Discussion List <address@hidden>
> Subject: Re: [Discuss-gnuradio] Copyrights using gr-modtool
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> 
>> 1) If I copy a gnuradio block (copyright FSF), tweak a few things, and
>> redistribute, FSF retains copyright and I have no copyright to the changes
>> No, that's not what I said (or at least meant). The code generated
>> from gr-modtool is copyrighted by the FSF. If you add any
>> modifications to the file, that new code will be your copyright. You
>> would then add a copyright notice into the file to say that this is
>> copyright you, 2013.
> Ok, thanks. I didn't mean to imply that's what you said; just getting 
> further clarification. :)
> Basically I'll retain FSF copyright notice (it would be a violation to 
> remove it) and add mine.
> 
> --sean
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Tue, 12 Mar 2013 15:34:33 -0500
> From: Josh Blum <address@hidden>
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] Reg:Tags_demo.cc example
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> 
> 
> On 03/12/2013 02:36 PM, Sean Nowlan wrote:
>> On 03/12/2013 02:14 PM, Josh Blum wrote:
>>> 
>>> On 03/11/2013 09:52 PM, john jade wrote:
>>>> Hi,
>>>> 
>>>> 1. What is get_full_seconds and get_frac_seconds printing?
>>> Its probably the receive timestamp, its the time stamp from this object:
>>> 
>>> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html
>>> 
>>> 
>>>> 2.Can we get upto precision of nano seconds using the above methods and
>>>> please tell me how to do it.
>>> The fractional seconds are stored as double precision floating point.
>>> This gives the fractional seconds enough precision to unambiguously
>>> specify a clock-tick/sample-count up to rates of several petahertz.
>> Although time can be *represented* with petahertz+ resolution, doesn't
>> the hardware clock constrain the *realizable* resolution? For example on
>> a USRP with a 100 MHz FPGA clock, would actual transmit precision be
>> limited to 10 ns?
> 
> The resolution as to which clock tick an event would happen at is only
> as fine as the clock you are using. -josh
> 
>> 
>>> -josh
>>> 
>>>> In the frac seconds i am getting 0.xxxxxx(only 6 digits after
>>>> point-micro
>>>> seconds)
>>>> 
>>>> Thanks
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Tue, 12 Mar 2013 16:45:43 -0400
> From: Tom Rondeau <address@hidden>
> To: Sean Nowlan <address@hidden>
> Cc: GNURadio Discussion List <address@hidden>
> Subject: Re: [Discuss-gnuradio] Copyrights using gr-modtool
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On Tue, Mar 12, 2013 at 4:07 PM, Sean Nowlan
> <address@hidden> wrote:
>>> 1) If I copy a gnuradio block (copyright FSF), tweak a few things, and
>>> redistribute, FSF retains copyright and I have no copyright to the changes
>>> No, that's not what I said (or at least meant). The code generated
>>> from gr-modtool is copyrighted by the FSF. If you add any
>>> modifications to the file, that new code will be your copyright. You
>>> would then add a copyright notice into the file to say that this is
>>> copyright you, 2013.
>> 
>> Ok, thanks. I didn't mean to imply that's what you said; just getting
>> further clarification. :)
>> Basically I'll retain FSF copyright notice (it would be a violation to
>> remove it) and add mine.
>> 
>> --sean
> 
> Exactly. Didn't want anyone to think that just because they used
> gr-modtool that we would be automatically assuming the copyright or
> their code. That is definitely not its intended use.
> 
> Tom
> 
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Tue, 12 Mar 2013 17:20:18 -0400
> From: <address@hidden>
> To: "address@hidden" <address@hidden>
> Subject: [Discuss-gnuradio] IndexError: gr_firdes check failed: 0 < fa
>    <=    sampling_freq / 2
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=utf-8
> 
> Hello everyone! I am getting another weird error here. i received my USB e4k 
> tuner and it was working. On OP25 i was using the scopes trying to figure how 
> to get the four lines of dots and with RTL_FM i was getting audio, although 
> the quality was bad. So i shut it down and i went out try on high ground but 
> the signal was still weak. So i shut it down again, put myself within line of 
> sight of the tower, and started it up and now OP25 dies like this:
> 
> Traceback (most recent call last):
> File "/home/matt/gr-baz/gr-baz-master/samples/op25_grc.py", line 595, in 
> <module>
> tb = op25_grc()
> File "/home/matt/gr-baz/gr-baz-master/samples/op25_grc.py", line 339, in 
> __init__
> self.gr_freq_xlating_fir_filter_xxx_0 = gr.freq_xlating_fir_filter_ccc(decim, 
> (firdes.low_pass(1, samp_rate, xlate_bandwidth/2, 1000)), 
> xlate_offset+xlate_offset_fine-fine_click_freq-auto_tune_offset_freq, 
> samp_rate)
> File 
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_general.py",
>  line 6871, in low_pass
> return _gnuradio_core_general.firdes_low_pass(*args, **kwargs)
> IndexError: gr_firdes check failed: 0 < fa <= sampling_freq / 2
> 
> I have no idea how OP25 (same for RTL_FM) goes from working to failing with 
> this error. Anyone have any ideas about this error?
> 
> Cheers,
> Matt
> 
> 
> 
> ------------------------------
> 
> Message: 11
> Date: Tue, 12 Mar 2013 17:32:27 -0400
> From: "M. Ranganathan" <address@hidden>
> To: address@hidden
> Subject: [Discuss-gnuradio] Building a transport layer
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hello,
> 
> I am looking for tips on building an experimental transport layer on top of
> the OFDM implementation in gnu radio. Ideally, I want to export a device
> driver interface on top of which I can bolt the TCP/IP stack of the linux
> kernel, or failing that, a user level UDP/IP or TCP/IP implementation.
> 
> 
> I am pretty sure that such a thing has been constructed before so if you
> are able to point me to any projects that do this, I would be grateful.
> 
> Thank you in advance.
> 
> Ranga
> 
> -- 
> M. Ranganathan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130312/8ea81966/attachment.html>
> 
> ------------------------------
> 
> Message: 12
> Date: Wed, 13 Mar 2013 11:56:04 +0800
> From: Lin HUANG <address@hidden>
> To: est meta <address@hidden>,    Albert Chun-Chieh Huang
>    <address@hidden>,    Discuss gnuradio
>    <address@hidden>
> Subject: [Discuss-gnuradio] Flexible RF, Picasso, one paper from
>    SIGCOMM 2012
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hello est, Albert, and all,
> 
> I read a paper, 'Picasso: Flexible RF and Spectrum Slicing', from SIGCOMM
> 2012 recently. And I found it gives a solution to integrate many spectrum
> bands into one antenna and RF chain.
> 
> Basically, Picasso uses a very wideband AD/DA and then digitally slices the
> spectrum into many bands for different usages. There are some tricks for
> interference cancellation.
> 
> I'm not a RF expert. I don't know whether this solution is really novel. I
> just remember that you mentioned that LTE has a too wide frequency range
> and this brings big challenge to mobile chipset design. Picasso is a
> possible solution to this problem.
> 
> Just FYI
> Lin
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130313/51e7763f/attachment.html>
> 
> ------------------------------
> 
> Message: 13
> Date: Tue, 12 Mar 2013 22:32:13 -0700 (PDT)
> From: john <address@hidden>
> To: address@hidden
> Subject: [Discuss-gnuradio] error while running the .cc files in
>    gr-bluetooth
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
> 
> when i try running a .cc file of gr-bluetooth , i get certain errors that
> some .h files are not there and it results in fatal error...
> 
> address@hidden:~/gr-bluetooth/src/lib$ gcc bluetooth.cc
> bluetooth.cc:149:20: fatal error: Python.h: No such file or directory
> compilation terminated.
> 
> when i run bluetooth.py, swig import error occurs and an import error
> occurs...
> 
> address@hidden:~/gr-bluetooth/src/lib$ python bluetooth
> python: can't open file 'bluetooth': [Errno 2] No such file or directory
> address@hidden:~/gr-bluetooth/src/lib$ python bluetooth.py
> Traceback (most recent call last):
>  File "bluetooth.py", line 24, in <module>
>    _bluetooth = swig_import_helper()
>  File "bluetooth.py", line 16, in swig_import_helper
>    import _bluetooth
> ImportError: No module named _bluetooth
> 
> How do i resolve this error....
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/error-while-running-the-cc-files-in-gr-bluetooth-tp40133.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> 
> 
> ------------------------------
> 
> Message: 14
> Date: Wed, 13 Mar 2013 03:57:48 -0700 (PDT)
> From: Mohammed Ramadan <address@hidden>
> To: address@hidden
> Subject: [Discuss-gnuradio] adding python block to gnuradio
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset="us-ascii"
> 
> i made python block and want to add it to module in gnuradio, i open the 
> directory of the module and use gr_motool add -t source filename.py. the tool 
> created the .cc file and .h but as templates no processing done in the files.
> so can anyone advise me to add python block?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130313/ec72cfc7/attachment.html>
> 
> ------------------------------
> 
> Message: 15
> Date: Wed, 13 Mar 2013 06:18:02 -0500
> From: Nathan West <address@hidden>
> To: Mohammed Ramadan <address@hidden>
> Cc: address@hidden
> Subject: Re: [Discuss-gnuradio] adding python block to gnuradio
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Wed, Mar 13, 2013 at 5:57 AM, Mohammed Ramadan
> <address@hidden>wrote:
> 
>> i made python block and want to add it to module in gnuradio, i open the
>> directory of the module and use gr_motool add -t source filename.py. the
>> tool created the .cc file and .h but as templates no processing done in the
>> files.
>> so can anyone advise me to add python block?
> There's a great tutorial here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
> 
> The gr_modtool work flow is that gr_modtool generates a lot of the required
> boilerplate code used by GR and then you edit those files with your signal
> processing code. Notice there's section on python blocks in the tutorial
> (Tutorial #3).
> 
> It sounds like you've already got your signal processing code done. I would
> suggest copying what you have in to the boiler plate code generated by
> gr_modtool. An alternative is importing what you already have and edit the
> work: function to call what you already have.
> 
> Make sure you tell gr_modtool that you want to generate a python block with
> the -l switch. Going through that tutorial will be the single most useful
> thing in learning how to make a new block.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130313/bc0914fe/attachment.html>
> 
> ------------------------------
> 
> Message: 16
> Date: Wed, 13 Mar 2013 11:29:04 +0000
> From: Mike Jameson <address@hidden>
> To: Mohammed Ramadan <address@hidden>
> Cc: address@hidden
> Subject: Re: [Discuss-gnuradio] adding python block to gnuradio
> Message-ID:
>    <address@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Mohammed,
> 
> Nathan just beat me to it and as he said, this link explains more about
> gr_modtool:
> 
> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
> 
> gr_modtool makes the template for you to paste your code into.
> 
> Here's my methodology on how I do it:
> 
> 1) $ gr_modtool newmod
> (type in your project name)
> 
> 2) $ cd gr-<project name>
> 
> 3) $ gr_modtool add
> (you need to make a dummy c++ block before you can build the project and
> therefore to make a python template. pick 'sync' without any qa files. see:
> http://gnuradio.org/redmine/issues/522 for explanation)
> 
> 4) $ gr_modtool add -l python
> (this is where you make the python template, if in doubt pick the 'sync'
> block)
> 
> 5) $ mkdir build && cd build && cmake ../ && make
> (look at the errors and you will see that the '<+' and '+>' need to be
> removed from the files in order for it to compile. When make works, 'sudo
> make install' will put your new project into action. don't forget to reload
> GRC or hit the blue refresh button at the top.  the GRC templates need to
> be edited too in order for them to turn into GRC icons)
> 
> Once you can compile the templates successfully, modify the files that
> gr_modtool created by pasting in your code. Good luck :)
> 
> Mike
> 
> --
> Mike Jameson M0MIK BSc
> Radio Communications Technology Specialist
> Email: address@hidden
> Web: http://www.scanoo.com
> 
> 
> On 13 March 2013 10:57, Mohammed Ramadan <address@hidden> wrote:
> 
>> i made python block and want to add it to module in gnuradio, i open the
>> directory of the module and use gr_motool add -t source filename.py. the
>> tool created the .cc file and .h but as templates no processing done in the
>> files.
>> so can anyone advise me to add python block?
>> 
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20130313/9c59d045/attachment.html>
> 
> ------------------------------
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> End of Discuss-gnuradio Digest, Vol 124, Issue 13
> *************************************************