[Discuss-gnuradio] GRCon14: Call for posters and demos

[Sebastian Koslowski]

Hello everybody,

We plan to host a poster and demo session at GNU Radio Conference 2014.
While this is a new experiment for us, other conferences have had these
for a while now. Showcasing projects or research work in this form
usually leads to more direct interaction with listeners and lively
discussions. And, well, it is always great to see stuff working right in
front of you!

If you have a cool GR-related application, project, or research work you
would like to showcase in the form of a poster or demo, please submit an
abstract on this page:

http://www.trondeau.com/grcon2014-call-for-posters/

The call for demos is open until July 31 2014.

Sebastian



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Agenda Announcement/GRCon14 Update

[John Malsbury]

Greetings,

It's been a few weeks since our last update on GRCon14.  Here's the latest:

*Conference Agenda is Posted*

I am happy and proud to announce that the agenda for GNU Radio Conference
2014 has been posted. We received an variety of great, high-quality
proposals on topics ranging from wireless security to satellite
communications and networking. Tom Rondeau and Michael Dickens spent a
great deal of time sorting through the presentations and assembling an
agenda that is packed full of interesting and educational content.  While
some minor details may change, you can find an up-to-date agenda at the
following link.  If you are a presenter and need to modify your entry,
please contact Michael Dickens to do so.

http://gnuradio.squarespace.com/grcon14-agenda/

*Help Promote GNU Radio Conference*

On another note its worth mentioning that we have been keeping a pulse on
registration. Based on the current run rate, we believe that this is going
to be *the largest* GNU Radio conference, *by far*.

With the conference agenda assembled and great forward momentum, we would
like to ask this awesome community to help us promote this event. GRCon14
is on the verge of becoming one of the largest and most influential events
with a focus on SDR and wireless implementation. With a community-driven
effort, we could really put ourselves on the map this year and generate
even more excitement with potential users and developers.

Whether you simply remind your fellow GNU Radio developer, or invite
someone new to join us for this event, we think your enthusiasm for the
event is the thing that will make the difference.

*Register for the Event*

If you would like to register for GRCon14, follow this link:

http://grcon14.eventbrite.com/

*We look forward to seeing you in September!*

Best Regards,
John Malsbury
GNU Radio Conference Chair
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FindICE.cmake

[Tom Rondeau]

On Wed, May 7, 2014 at 5:53 PM, West, Nathan wrote:

> I can confirm that this solved the issue and I'm able to build with
> Ubuntu's version of Ice. However, I think this also affects 13.10
> (that's what I've been using and I upgraded specifically to get
> ice-3.5).
>
> Thanks Tom.


Great, thanks for testing! I've pushed a branch to my github repo called
cmake_ice_libs that addresses the issues for both Ice 3.4 and 3.5. I'll use
it tomorrow to test my various setups in-house, but any other feedback
about it's applicability or problems will be helpful!

https://github.com/trondeau/gnuradio/tree/cmake_ice_libs

Thanks,
Tom




> On Tue, May 6, 2014 at 9:14 AM, Tom Rondeau  wrote:
> > Ok, yeah, I think I've figured out the problem. They completely changed
> the
> > ICE package config files and the location of the libraries in 14.04. The
> > package config file doesn't have any include dirs specified and the
> library
> > points to an installed Microsoft DLL, which seems... strange to me.
> > Basically, I'm thinking that using the package config for Ice is
> worthless,
> > so I'm going to strip it out of the FindICE-3.5.cmake file (we'll be
> pushing
> > up the minimum required version of ICE to 3.5 with our release of v3.8.0,
> > anyways, so support for 3.4 will go away).
> >
> > The other big issue is that the libraries are installed for multi-arch
> > support, so they are located in /usr/lib/libIceX.so, anymore. And we're
> > using NO_DEFAULT_PATH when looking for libraries. I /think/ we started
> using
> > that setting to support OS X builds. I have this working now on a VM, but
> > I'm going to have to work on patching FindIce-3.5.cmake a little more to
> > make sure everything's ok and test it on multiple platforms (yay...).
> >
> > If you've followed what I said above, you should be able to quickly fix
> this
> > locally on your own machine. Basically:
> > - remove the use of package config (comment out PKG_CHECK_MODULE)
> > - remove the use of NO_DEFAULT_PATH in the FIND_LIBRARY commands
> >
> > Tom
> >
> >
> >
> > On Mon, May 5, 2014 at 5:48 PM, Ben Rosenbloom  >
> > wrote:
> >>
> >> I'm noticing this issue as well on Ubuntu 14. Ice 3.5.1 is installed via
> >> deb, but GNURadio does not see it.
> >>
> >>
> >> On Thu, May 1, 2014 at 4:03 PM, West, Nathan <
> n...@ostatemail.okstate.edu>
> >> wrote:
> >>>
> >>> On Thu, May 1, 2014 at 8:23 AM, Tom Rondeau  wrote:
> >>> > On Wed, Apr 30, 2014 at 9:11 PM, West, Nathan
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> I'm trying to build gnu radio with control port, but cmake won't
> find
> >>> >> my Ice installation. I have Ice-3.4 installed through apt on Ubuntu
> >>> >> 13.10. Digging in to the FindIce.cmake I made the following changes:
> >>> >>
> >>> >> diff --git a/cmake/Modules/FindICE.cmake
> b/cmake/Modules/FindICE.cmake
> >>> >> index 087ee9b..705c019 100644
> >>> >> --- a/cmake/Modules/FindICE.cmake
> >>> >> +++ b/cmake/Modules/FindICE.cmake
> >>> >> @@ -4,7 +4,7 @@
> >>> >>  FIND_PACKAGE(PkgConfig)
> >>> >>  PKG_CHECK_MODULES(PC_ICE Ice-3.4 QUIET)
> >>> >>
> >>> >> -if(NOT ICE_FOUND)
> >>> >> +if(NOT PC_ICE_FOUND)
> >>> >># Maybe we don't have a .pc file for Ice. Check for Config.h. If
> >>> >># that exists, get the version string and parse it for the proper
> >>> >># version.
> >>> >> @@ -21,11 +21,11 @@ if(NOT ICE_FOUND)
> >>> >>set(ICE_FOUND TRUE)
> >>> >>  endif(ICE_FOUND)
> >>> >>endif(ICE_CONFIG_INCLUDE_DIR)
> >>> >> -endif(NOT ICE_FOUND)
> >>> >> +endif(NOT PC_ICE_FOUND)
> >>> >>
> >>> >> -if(NOT ICE_FOUND)
> >>> >> +if(NOT PC_ICE_FOUND)
> >>> >>message(STATUS "  package 'Ice-3.4' not found")
> >>> >> -endif(NOT ICE_FOUND)
> >>> >> +endif(NOT PC_ICE_FOUND)
> >>> >>
> >>> >>
> >>> >>  # Recheck if we found the right version of ICE and proceed if true.
> >>> >>
> >>> >> This at least squelches the 'package Ice-3.4 not found' message,
> which
> >>> >> is an improvement. (I test this with cmake -P . I'm
> >>> >> still not able to get cmake to configure GNU Radio to build
> >>> >> control-port, and this is already extending my cmake-fu.
> >>> >>
> >>> >> I've only managed to get this configured properly through PyBOMBS.
> Any
> >>> >> suggestions on fixing this module to properly detect a distro
> >>> >> installed Ice?
> >>> >>
> >>> >> Nathan
> >>> >
> >>> >
> >>> >
> >>> > Nathan,
> >>> > Yeah, I suspect you're right on the use of the PC_ for the variables.
> >>> >
> >>> > Have you made sure that python-zeroc-ice is also installed?
> >>> >
> >>> > Tom
> >>> >
> >>>
> >>> Yea, python-zeroc-ice is installed. If I replace all of the ICE_FOUND
> >>> instances with PC_ICE_FOUND then I get a syntax error on line 36:
> >>> string(REGEX REPLACE "/include" "" ICE_PATH
> >>> ${ICE_CONFIG_INCLUDE_DIR}). I Don't see where ICE_PATH is being set in
> >>> the first place.
> >>>
> >>> Nathan
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://

Re: [Discuss-gnuradio] convert old Gnu Radio applications

[Activecat]

On Wed, May 7, 2014 at 5:08 PM, 王先达  wrote:

> Hello Sylvain
>   Thank you very much.
>   But another question i want to ask.Where can i find
> the document of function and class which are in the new api?These document
> can provide all the meaning of the function and class written by c++.And
> the document of api is so obscure that i can't find the frequently-used
> function for example the basic function for the transmit and receive.Now i
> want to write the basic transmit and receive modules by c++.And after i
> written it,which folder i place it?Thank you very much.
>


The short answer is, you can place the folder at any place you like,
usually within your home directory.

Step 1.
cd to the place where you want to place your module folder, says,
/home/xianda.
Create your out-of-tree module by using command:  "gr_modtool  newmod
gr-xianda"
This will create the folder /home/xianda/gr-xianda in the current directory.

Step 2.
cd to /home/xianda/gr-xianda
Create the transmit block by using command: "gr_modtool add -t source
transmitter01"

.
.
( refer http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FindICE.cmake

[West, Nathan]

I can confirm that this solved the issue and I'm able to build with
Ubuntu's version of Ice. However, I think this also affects 13.10
(that's what I've been using and I upgraded specifically to get
ice-3.5).

Thanks Tom.

On Tue, May 6, 2014 at 9:14 AM, Tom Rondeau  wrote:
> Ok, yeah, I think I've figured out the problem. They completely changed the
> ICE package config files and the location of the libraries in 14.04. The
> package config file doesn't have any include dirs specified and the library
> points to an installed Microsoft DLL, which seems... strange to me.
> Basically, I'm thinking that using the package config for Ice is worthless,
> so I'm going to strip it out of the FindICE-3.5.cmake file (we'll be pushing
> up the minimum required version of ICE to 3.5 with our release of v3.8.0,
> anyways, so support for 3.4 will go away).
>
> The other big issue is that the libraries are installed for multi-arch
> support, so they are located in /usr/lib/libIceX.so, anymore. And we're
> using NO_DEFAULT_PATH when looking for libraries. I /think/ we started using
> that setting to support OS X builds. I have this working now on a VM, but
> I'm going to have to work on patching FindIce-3.5.cmake a little more to
> make sure everything's ok and test it on multiple platforms (yay...).
>
> If you've followed what I said above, you should be able to quickly fix this
> locally on your own machine. Basically:
> - remove the use of package config (comment out PKG_CHECK_MODULE)
> - remove the use of NO_DEFAULT_PATH in the FIND_LIBRARY commands
>
> Tom
>
>
>
> On Mon, May 5, 2014 at 5:48 PM, Ben Rosenbloom 
> wrote:
>>
>> I'm noticing this issue as well on Ubuntu 14. Ice 3.5.1 is installed via
>> deb, but GNURadio does not see it.
>>
>>
>> On Thu, May 1, 2014 at 4:03 PM, West, Nathan 
>> wrote:
>>>
>>> On Thu, May 1, 2014 at 8:23 AM, Tom Rondeau  wrote:
>>> > On Wed, Apr 30, 2014 at 9:11 PM, West, Nathan
>>> > 
>>> > wrote:
>>> >>
>>> >> I'm trying to build gnu radio with control port, but cmake won't find
>>> >> my Ice installation. I have Ice-3.4 installed through apt on Ubuntu
>>> >> 13.10. Digging in to the FindIce.cmake I made the following changes:
>>> >>
>>> >> diff --git a/cmake/Modules/FindICE.cmake b/cmake/Modules/FindICE.cmake
>>> >> index 087ee9b..705c019 100644
>>> >> --- a/cmake/Modules/FindICE.cmake
>>> >> +++ b/cmake/Modules/FindICE.cmake
>>> >> @@ -4,7 +4,7 @@
>>> >>  FIND_PACKAGE(PkgConfig)
>>> >>  PKG_CHECK_MODULES(PC_ICE Ice-3.4 QUIET)
>>> >>
>>> >> -if(NOT ICE_FOUND)
>>> >> +if(NOT PC_ICE_FOUND)
>>> >># Maybe we don't have a .pc file for Ice. Check for Config.h. If
>>> >># that exists, get the version string and parse it for the proper
>>> >># version.
>>> >> @@ -21,11 +21,11 @@ if(NOT ICE_FOUND)
>>> >>set(ICE_FOUND TRUE)
>>> >>  endif(ICE_FOUND)
>>> >>endif(ICE_CONFIG_INCLUDE_DIR)
>>> >> -endif(NOT ICE_FOUND)
>>> >> +endif(NOT PC_ICE_FOUND)
>>> >>
>>> >> -if(NOT ICE_FOUND)
>>> >> +if(NOT PC_ICE_FOUND)
>>> >>message(STATUS "  package 'Ice-3.4' not found")
>>> >> -endif(NOT ICE_FOUND)
>>> >> +endif(NOT PC_ICE_FOUND)
>>> >>
>>> >>
>>> >>  # Recheck if we found the right version of ICE and proceed if true.
>>> >>
>>> >> This at least squelches the 'package Ice-3.4 not found' message, which
>>> >> is an improvement. (I test this with cmake -P . I'm
>>> >> still not able to get cmake to configure GNU Radio to build
>>> >> control-port, and this is already extending my cmake-fu.
>>> >>
>>> >> I've only managed to get this configured properly through PyBOMBS. Any
>>> >> suggestions on fixing this module to properly detect a distro
>>> >> installed Ice?
>>> >>
>>> >> Nathan
>>> >
>>> >
>>> >
>>> > Nathan,
>>> > Yeah, I suspect you're right on the use of the PC_ for the variables.
>>> >
>>> > Have you made sure that python-zeroc-ice is also installed?
>>> >
>>> > Tom
>>> >
>>>
>>> Yea, python-zeroc-ice is installed. If I replace all of the ICE_FOUND
>>> instances with PC_ICE_FOUND then I get a syntax error on line 36:
>>> string(REGEX REPLACE "/include" "" ICE_PATH
>>> ${ICE_CONFIG_INCLUDE_DIR}). I Don't see where ICE_PATH is being set in
>>> the first place.
>>>
>>> Nathan
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC] Co-Processors Introduction + Wiki Page

[Alfredo Muniz]

Hello everybody,

I've been selected for the GSoC project in using the keystone2 as a base to
further develop coprocessor integration in gnuradio. My mentor is Philip
Balister who mentored last year's coprocessor project with the Zynq. To
track my progress and keep notes, I will use this wiki page:

http://gnuradio.org/redmine/projects/gnuradio/wiki/keystone2

I've used blogs in the past for other projects but never got used to them
so I'm using the wiki page. I will organize it better as I get more
information and as I run into problems. I will update at least once a week.

Once the term begins, you should be able to find me around the clock on IRC
#gnuradio with name 'muniza'. I will also be joining many of the developer
calls if there is space to simply learn more about GNU Radio. Feel free to
reach me at this email with any questions, advice, concerns, etc.

Looking forward to the summer!
AM KC3BBL
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Out of Tree Block Not Showing up in GRC

[Jonathan Fox]

After some perusing, I think the XML for the meta file sink provided a good
example. Although thanks for the previous examples, it probably took all
three to figure it out.

Thanks again,

Jon


On Wed, May 7, 2014 at 3:32 AM, Martin Braun  wrote:

> Order of XML tags matters, check grc/python/block.dtd.
>
> Martin
>
>
> On 07.05.2014 02:07, Ron Economos wrote:
>
>> Here's an even more basic example that doesn't use
>> the opt tag. It shows my complete cluelessness about
>> xml, but it works.
>>
>> https://github.com/drmpeg/gr-dvbs/blob/master/grc/dvbs_puncture_bb.xml
>>
>> Ron
>>
>> On 5/6/2014 11:55 AM, Jonathan Fox wrote:
>>
>>> Thanks for the response, I was looking at the opt tags and I am still
>>> confused about how to do it. Do I need to set it up like this:
>>>
>>>   specsense.energy_detector_sink_f($vlen, $eta,
>>> $white_space.val, $samp_rate, $cntr_freq, $verbose)
>>>
>>>   
>>> Desired Detection
>>> white_space
>>> bool
>>> 
>>>   Open Band
>>>   True
>>>   val:True
>>> 
>>> 
>>>   Closed Band
>>>   False
>>>   val:False
>>> 
>>>   
>>>
>>>   
>>> Verbose
>>> verbose
>>> bool
>>> 
>>>   Yes
>>>   True
>>>   val:True
>>> 
>>> 
>>>   No
>>>   False
>>>   val:False
>>> 
>>>   
>>>
>>> Thanks,
>>>
>>> Jon
>>>
>>>
>>> On Tue, May 6, 2014 at 11:08 AM, Ron Economos >> > wrote:
>>>
>>> Take a look at:
>>>
>>> https://github.com/BogdanDIA/gr-dvbt/blob/master/grc/dvbt_
>>> inner_coder.xml
>>>
>>> Ron
>>>
>>>
>>> On 5/6/2014 7:00 AM, Jonathan Fox wrote:
>>>
>>> I have two out of tree blocks I want to add to GRC, everything
>>> compiles and installs correctly except for the GRC component
>>> (not shown in GRC). So this should be an XML issue and I think
>>> it is related to my attempts at making a drop down option
>>> choice concerning the detection of white space/closed
>>> frequencies and verbose output. My XML is attached below and
>>> you can see that under Params Desired Detection and Verbose
>>> have options.
>>>
>>> When I look at other stock GNU Radio block's XML like the low
>>> pass filter, I see that some params have opt tags. Do I need
>>> these also, if so how would I use them in my case?
>>>
>>> Thanks,
>>>
>>> Jon
>>>
>>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] I have a trouble with new types in python!

[Mostafa Alizadeh]

Hi Marcus,
I actually have a deep, really deep,  problem with data types As you
see I have a preprocessor definition which is 32 bit number. I wanna pass
it to the make!!! how could I? If I use the gnuradio type " gr_uint32",
after turning my c++-written blocks, the GRC tells me:

*TypeError: in method '_make', argument 1 of type 'gr_uint32'*

I put an option to the xml file :

**
*CRC16*
*gr_uint32*
*CRC_type:0x00011021*
**

I know that this is not true, but I want to pass a 32-bit number to the
"make". How could I do?

please help me,

best,


On Wed, May 7, 2014 at 7:59 PM, Marcus Müller  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Mostafa,
>
>
> On 07.05.2014 16:34, Mostafa Alizadeh wrote:
> >
> > #define X 0x01864CFB
>
> Attention! This is a preprocessing define. This means that /prior/ to
> compilation, all occurences of X will be replaced by 0x01..., so your
> compiler will never see X.
>
> Is it possible that you want to define a default option for your make
> function? That works! you can just have a make function with a
> function stub like
> ...::make(int param1, float param2, unsigned char param3, int param4 =
> 0x0186);
>
> Again, XML files are only useful for defining the graphical
> representation of a GNU Radio block in GRC, it's not meant to define
> constants. There are ways to do that, but most of the time it's not
> what you want.
> You can set default values for input fields in the block options, you
> can also do dropdown menus. I don't know what you're really trying to
> do, so you might be best of to look at different blocks in GRC and
> find one that fits your problem best, and copy that block's XML.
>
> Greetings,
> Marcus
>
>
> > and I should pass X, instead of  this 0x01864CFB which is 32 bits
> > number to my "make" function of my block.
> >
> > What do you prefer for making a GRC xml file for this block?
> >
> > best,
> >
> >
> >
> > On Wed, May 7, 2014 at 5:54 PM, Marcus Müller
> > wrote:
> >
> >> Hi Mostafa, this question is far more complex than you'd expect.
> >> I'll try to explain: - GRC is but a graphical interface to python
> >> code, which itself offers access GNU Radio blocks, partly written
> >> in python, mostly written in C++ and wrapped to python. It's
> >> always important to remember that GRC != GR - As you noticed,
> >> there is not always a direct matching between C++ and python
> >> types. This is an inherent problem caused by the fact that they
> >> are different internally. - When you create a block, and set up
> >> everything accordingly (which gr_modtool will do for you), then
> >> SWIG will generate wrapper code to make these classes (which are
> >> types!) available as blocks in python - also, you can generate
> >> XML files to represent blocks in GRC. Again, this will only be
> >> used to generate python code! If you want to define things so
> >> that you can not only use them in python, generate XML. This is
> >> covered in the "writing out of tree modules" tutorial. - there is
> >> a difference between sample streams and variables: a variable in
> >> GRC is usually used to configure parameters of a block. I don't
> >> really see a reason not to use a standard integer value here; ok,
> >> you're wasting dozens of bits. But honestly, you do that once, it
> >> doesn't matter. - for streams, there is a byte type. Internally,
> >> neither python, nor GNU Radio care about the type; they just care
> >> about the item size, so defining things like "bit", packed in
> >> "byte" does never make a difference.
> >>
> >> Hope that was a little helpful, Marcus Müller
> >>
> >>
> >>
> >> On Wed, May 7, 2014 at 3:01 PM, Mostafa Alizadeh
> >> wrote:
> >>
> >>> Hello everybody, I have a new type in my gnuradio blocks which
> >>> are defined in c++. However, the GRC don't know them. *The
> >>> first question is how I could make GRC of such blocks? *
> >>>
> >>> I think if I could be able to define them in python I could add
> >>> new types to the GRC of the block. Although I'm not so familiar
> >>> with python, I want to define new type as it was previously
> >>> defined in c++ as :
> >>>
> >>> *typedef unsigned char   bit; *
> >>>
> >>> *how could I define such variable in python!!!? *(may it helps
> >>> me to make my GRC block)
> >>>
> >>> Thank,
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>
> >>>
> >>
> >
> >
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTalFKAAoJEBQ6EdjyzlHtRHwIAJnlorrctCzyARolZl4gc6mJ
> 7gTeGZc43oGj/1Ise3I7lqcY7lmBMkErGDLiKWsyWYOW0HTSHobDQr9xOY/UK5j+
> HtaFAec2WeX9spTLNUBg87ZLTJlWBjoEvl6nT

Re: [Discuss-gnuradio] I have a trouble with new types in python!

[王先达]

Hello
 Thank you so much.I have already read all the wiki somedays before.But 
i find it's difficult to write my own application.Have you some tutorials?And 
how do you be familiar with this area?Any advices will be appreciated.So many 
people want to learn it but no good ways to touch it.
Best regards,
Xianda Wang
At 2014-05-07 23:29:14,"Marcus Müller"  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Hi Mostafa,
>
>
>On 07.05.2014 16:34, Mostafa Alizadeh wrote:
>> 
>> #define X 0x01864CFB
>
>Attention! This is a preprocessing define. This means that /prior/ to
>compilation, all occurences of X will be replaced by 0x01..., so your
>compiler will never see X.
>
>Is it possible that you want to define a default option for your make
>function? That works! you can just have a make function with a
>function stub like
>...::make(int param1, float param2, unsigned char param3, int param4 =
>0x0186);
>
>Again, XML files are only useful for defining the graphical
>representation of a GNU Radio block in GRC, it's not meant to define
>constants. There are ways to do that, but most of the time it's not
>what you want.
>You can set default values for input fields in the block options, you
>can also do dropdown menus. I don't know what you're really trying to
>do, so you might be best of to look at different blocks in GRC and
>find one that fits your problem best, and copy that block's XML.
>
>Greetings,
>Marcus
>
>
>> and I should pass X, instead of  this 0x01864CFB which is 32 bits
>> number to my "make" function of my block.
>> 
>> What do you prefer for making a GRC xml file for this block?
>> 
>> best,
>> 
>> 
>> 
>> On Wed, May 7, 2014 at 5:54 PM, Marcus Müller
>> wrote:
>> 
>>> Hi Mostafa, this question is far more complex than you'd expect.
>>> I'll try to explain: - GRC is but a graphical interface to python
>>> code, which itself offers access GNU Radio blocks, partly written
>>> in python, mostly written in C++ and wrapped to python. It's
>>> always important to remember that GRC != GR - As you noticed,
>>> there is not always a direct matching between C++ and python
>>> types. This is an inherent problem caused by the fact that they
>>> are different internally. - When you create a block, and set up
>>> everything accordingly (which gr_modtool will do for you), then
>>> SWIG will generate wrapper code to make these classes (which are
>>> types!) available as blocks in python - also, you can generate
>>> XML files to represent blocks in GRC. Again, this will only be
>>> used to generate python code! If you want to define things so 
>>> that you can not only use them in python, generate XML. This is
>>> covered in the "writing out of tree modules" tutorial. - there is
>>> a difference between sample streams and variables: a variable in
>>> GRC is usually used to configure parameters of a block. I don't
>>> really see a reason not to use a standard integer value here; ok,
>>> you're wasting dozens of bits. But honestly, you do that once, it
>>> doesn't matter. - for streams, there is a byte type. Internally,
>>> neither python, nor GNU Radio care about the type; they just care
>>> about the item size, so defining things like "bit", packed in
>>> "byte" does never make a difference.
>>> 
>>> Hope that was a little helpful, Marcus Müller
>>> 
>>> 
>>> 
>>> On Wed, May 7, 2014 at 3:01 PM, Mostafa Alizadeh
>>> wrote:
>>> 
 Hello everybody, I have a new type in my gnuradio blocks which
 are defined in c++. However, the GRC don't know them. *The
 first question is how I could make GRC of such blocks? *
 
 I think if I could be able to define them in python I could add
 new types to the GRC of the block. Although I'm not so familiar
 with python, I want to define new type as it was previously
 defined in c++ as :
 
 *typedef unsigned char   bit; *
 
 *how could I define such variable in python!!!? *(may it helps
 me to make my GRC block)
 
 Thank,
 
 ___ 
 Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
>>> 
>> 
>> 
>> 
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iQEcBAEBAgAGBQJTalFKAAoJEBQ6EdjyzlHtRHwIAJnlorrctCzyARolZl4gc6mJ
>7gTeGZc43oGj/1Ise3I7lqcY7lmBMkErGDLiKWsyWYOW0HTSHobDQr9xOY/UK5j+
>HtaFAec2WeX9spTLNUBg87ZLTJlWBjoEvl6nT9xvbJSXDvoIBzF1cQ7EY1TkVU5V
>zLWRxwMA1G6LeP9JGCuxlA1t92hP7gLR+UOoff1EmWx2HbwF4Jin8frn6irrzqpi
>SCQ3X5VoMT2/vX10lFgbumEUhijTr5q9m3JvMIA2n7CBdq5SrLEpqjgZIHUPUxOs
>nAN9h6UZ8mSfAvxjik8X1frDpp0rJxl2iZH+r69OILBAt+nQQJzb88LHyRh7UyQ=
>=bJMO
>-END PGP SIGNATURE-
>
>___
>Discuss-gnuradio mailing li

Re: [Discuss-gnuradio] I have a trouble with new types in python!

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Mostafa,


On 07.05.2014 16:34, Mostafa Alizadeh wrote:
> 
> #define X 0x01864CFB

Attention! This is a preprocessing define. This means that /prior/ to
compilation, all occurences of X will be replaced by 0x01..., so your
compiler will never see X.

Is it possible that you want to define a default option for your make
function? That works! you can just have a make function with a
function stub like
...::make(int param1, float param2, unsigned char param3, int param4 =
0x0186);

Again, XML files are only useful for defining the graphical
representation of a GNU Radio block in GRC, it's not meant to define
constants. There are ways to do that, but most of the time it's not
what you want.
You can set default values for input fields in the block options, you
can also do dropdown menus. I don't know what you're really trying to
do, so you might be best of to look at different blocks in GRC and
find one that fits your problem best, and copy that block's XML.

Greetings,
Marcus


> and I should pass X, instead of  this 0x01864CFB which is 32 bits
> number to my "make" function of my block.
> 
> What do you prefer for making a GRC xml file for this block?
> 
> best,
> 
> 
> 
> On Wed, May 7, 2014 at 5:54 PM, Marcus Müller
> wrote:
> 
>> Hi Mostafa, this question is far more complex than you'd expect.
>> I'll try to explain: - GRC is but a graphical interface to python
>> code, which itself offers access GNU Radio blocks, partly written
>> in python, mostly written in C++ and wrapped to python. It's
>> always important to remember that GRC != GR - As you noticed,
>> there is not always a direct matching between C++ and python
>> types. This is an inherent problem caused by the fact that they
>> are different internally. - When you create a block, and set up
>> everything accordingly (which gr_modtool will do for you), then
>> SWIG will generate wrapper code to make these classes (which are
>> types!) available as blocks in python - also, you can generate
>> XML files to represent blocks in GRC. Again, this will only be
>> used to generate python code! If you want to define things so 
>> that you can not only use them in python, generate XML. This is
>> covered in the "writing out of tree modules" tutorial. - there is
>> a difference between sample streams and variables: a variable in
>> GRC is usually used to configure parameters of a block. I don't
>> really see a reason not to use a standard integer value here; ok,
>> you're wasting dozens of bits. But honestly, you do that once, it
>> doesn't matter. - for streams, there is a byte type. Internally,
>> neither python, nor GNU Radio care about the type; they just care
>> about the item size, so defining things like "bit", packed in
>> "byte" does never make a difference.
>> 
>> Hope that was a little helpful, Marcus Müller
>> 
>> 
>> 
>> On Wed, May 7, 2014 at 3:01 PM, Mostafa Alizadeh
>> wrote:
>> 
>>> Hello everybody, I have a new type in my gnuradio blocks which
>>> are defined in c++. However, the GRC don't know them. *The
>>> first question is how I could make GRC of such blocks? *
>>> 
>>> I think if I could be able to define them in python I could add
>>> new types to the GRC of the block. Although I'm not so familiar
>>> with python, I want to define new type as it was previously
>>> defined in c++ as :
>>> 
>>> *typedef unsigned char   bit; *
>>> 
>>> *how could I define such variable in python!!!? *(may it helps
>>> me to make my GRC block)
>>> 
>>> Thank,
>>> 
>>> ___ 
>>> Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> 
>>> 
>> 
> 
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTalFKAAoJEBQ6EdjyzlHtRHwIAJnlorrctCzyARolZl4gc6mJ
7gTeGZc43oGj/1Ise3I7lqcY7lmBMkErGDLiKWsyWYOW0HTSHobDQr9xOY/UK5j+
HtaFAec2WeX9spTLNUBg87ZLTJlWBjoEvl6nT9xvbJSXDvoIBzF1cQ7EY1TkVU5V
zLWRxwMA1G6LeP9JGCuxlA1t92hP7gLR+UOoff1EmWx2HbwF4Jin8frn6irrzqpi
SCQ3X5VoMT2/vX10lFgbumEUhijTr5q9m3JvMIA2n7CBdq5SrLEpqjgZIHUPUxOs
nAN9h6UZ8mSfAvxjik8X1frDpp0rJxl2iZH+r69OILBAt+nQQJzb88LHyRh7UyQ=
=bJMO
-END PGP SIGNATURE-

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] I have a trouble with new types in python!

[Mostafa Alizadeh]

Hi Marcus,
Thank you very much for your explicit explanations. Yeah, I found it so
hard to do what I thought. As you said I determined the type as "byte" and
there is no problem. But there is another problem! I have defined something
like this in c++:

#define X 0x01864CFB

and I should pass X, instead of  this 0x01864CFB which is 32 bits number to
my "make" function of my block.

What do you prefer for making a GRC xml file for this block?

best,



On Wed, May 7, 2014 at 5:54 PM, Marcus Müller wrote:

> Hi Mostafa,
> this question is far more complex than you'd expect. I'll try to explain:
> - GRC is but a graphical interface to python code, which itself offers
> access GNU Radio blocks, partly written in python, mostly written in C++
> and wrapped to python. It's always important to remember that GRC != GR
> - As you noticed, there is not always a direct matching between C++ and
> python types. This is an inherent problem caused by the fact that they are
> different internally.
> - When you create a block, and set up everything accordingly (which
> gr_modtool will do for you), then SWIG will generate wrapper code to make
> these classes (which are types!) available as blocks in python
> - also, you can generate XML files to represent blocks in GRC. Again, this
> will only be used to generate python code! If you want to define things so
> that you can not only use them in python, generate XML. This is covered in
> the "writing out of tree modules" tutorial.
> - there is a difference between sample streams and variables: a variable
> in GRC is usually used to configure parameters of a block. I don't really
> see a reason not to use a standard integer value here; ok, you're wasting
> dozens of bits. But honestly, you do that once, it doesn't matter.
> - for streams, there is a byte type. Internally, neither python, nor GNU
> Radio care about the type; they just care about the item size, so defining
> things like "bit", packed in "byte" does never make a difference.
>
> Hope that was a little helpful,
> Marcus Müller
>
>
>
> On Wed, May 7, 2014 at 3:01 PM, Mostafa Alizadeh 
> wrote:
>
>> Hello everybody,
>> I have a new type in my gnuradio blocks which are defined in c++.
>> However, the GRC don't know them.
>> *The first question is how I could make GRC of such blocks? *
>>
>> I think if I could be able to define them in python I could add new types
>> to the GRC of the block.
>> Although I'm not so familiar with python, I want to define new type as it
>> was previously defined in c++ as :
>>
>> *typedef unsigned char   bit; *
>>
>> *how could I define such variable in python!!!? *(may it helps me to
>> make my GRC block)
>>
>> Thank,
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] convert old Gnu Radio applications

[Marcus Müller]

Hi Xianda Wang,

when replying to a mailing list posting, please always include the list
itself, that increases the use for people.
I can't simply answer your question; software radio development is more
complicated than that.

As I said before, please follow the Tutorials on gnuradio.org to learn
how to write out-of-tree modules. They tell you all the details on how
to develop, save, build and install GNU Radio modules correctly.

Greetings,
Marcus

On 07.05.2014 15:44, 王先达 wrote:
> Hello
>  Thank you for your reply.But i have another question.When i write my 
> application for example the basic transmit and receive by c++,which folder in 
> gnuradio i place it?Can i place it to the gr-digital or 
> gnuradio-3.7.2\gr-uhd\lib or somewhere?Thank you.
> Best regrads,
> Xianda Wang
>
>
>
>
>
>
>
>
> At 2014-05-07 17:25:28,"Marcus Müller"  wrote:
>> Hi Xianda Wang,
>>
>> All the documentation is on gnuradio.org; what you're looking for is
>> mostly the GNU Radio doxygen, located at
>> http://gnuradio.org/doc/doxygen/index.html
>>
>> Greetings,
>> Marcus Müller
>>
>> On 07.05.2014 11:08, 王先达 wrote:
>>> Hello Sylvain
>>>   Thank you very much.
>>>   But another question i want to ask.Where can i find 
>>> the document of function and class which are in the new api?These document 
>>> can provide all the meaning of the function and class written by c++.And 
>>> the document of api is so obscure that i can't find the frequently-used 
>>> function for example the basic function for the transmit and receive.Now i 
>>> want to write the basic transmit and receive modules by c++.And after i 
>>> written it,which folder i place it?Thank you very much.
>>> Best regards,
>>> Xianda Wang
>>> At 2014-05-07 02:39:22,"Sylvain Munaut" <246...@gmail.com> wrote:
>  Now i want to convert old Gnu Radio applications which were
> developed in the gnuradio 3.3.0 to the gnuradio 3.7.0.Can someone give me
> some advices on this?Any advices will be appreciated.
 For modules : (or custom modules inside apps)

 Recreate the modules from scratch using the new layout using gr_modtool.
 Then cut & paste the actual processing methods from the old code and
 adapt it, one module at a time.


 For apps:

 See the http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7
 for namespace conversion.


 Cheers,

   Sylvain

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to convert from message to complex/float

[Tom Rondeau]

On Tue, May 6, 2014 at 2:54 AM, Hoang Ngo Khac wrote:

> Hi Tom, and all,
>
> I've had a look at *PDU to Tagged Stream* block.
> Regarding to adding tags, both this block and *Burst Tagger *contains
> add_item_tag() function. Which block inserts the main stream tags? I don't
> quite under stand what *Burst Tagger* does since it contains both
> add_item_tag() and get_tags_in_range() function.
>
> Thanks,
> Hoang
>

Have a read of:

http://gnuradio.org/doc/doxygen/page_stream_tags.html

That will hopefully give you a better understanding of the tags.

Tom




> On Tue, Apr 29, 2014 at 9:23 PM, Tom Rondeau  wrote:
>
>> On Tue, Apr 29, 2014 at 2:50 AM, Hoang Ngo Khac 
>> wrote:
>>
>>> Dear List,
>>>
>>> I'm beginning with gr-mac. (https://github.com/jmalsbury/gr-mac). I
>>> need complex/float data to process but some blocks give message as output 
>>> (*Tagged
>>> Stream to PDU*). I did try using *Message Source* to convert form
>>> message to complex but there was error with the ID:
>>> *NameError: global name 'blocks_message_soure_0_msgg_in' is not defined *
>>>
>>> Also, *PDU to Tagged Stream* takes *message* as input. The *Message
>>> Sink* was used but the similar error happened:
>>>
>>> Am I right using *Message Source* and *Message Sink*? If yes, how could
>>> I fix these error? If no, which blocks should be used?
>>>
>>> Thanks,
>>> Hoang
>>>  
>>
>>
>> Take a look into the gmsk_radio hier_block used in simple_trx.grc. You
>> can see how the PDU messages are converted to streams of samples. That
>> should help you out with what you might want to do.
>>
>> Tom
>>
>>
>
>
> --
> *Hoang Ngo-Khac*
> Vietnam National University, Hanoi (VNU-H)
> Univ. of Engineering and Technology (UET)
> Faculty of Electronics and Telecommunications (FET)
> Alternative email:  hoangnk...@vnu.edu.vn
> Mobilephone:  +84.163.682.7874
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python chaos

[Tom Rondeau]

On Wed, May 7, 2014 at 3:43 AM, Vanush Vaswani  wrote:

> Tom,
>
> Have you looked at PyQtGraph? I've had some success with it.
>
> Vanush
>

Thanks for the suggestion! Yes, I have looked at it. It looks like a great
project for working directly in Python, but we mostly do all of our
plotting in QT C++ and export. The use of PyQWT is specifically to get us
QWT widgets like the range, check boxes, radio buttons, etc. Pretty much
what you see under "GUI Tools -> QT" in the GRC block list. It doesn't look
like PyQtGraph provides equivalents to those (or even anything that would
effectively replace them).

Tom




> On Thu, Dec 5, 2013 at 1:50 AM, Tom Rondeau  wrote:
>
>> On Wed, Dec 4, 2013 at 4:49 AM, Stefan Gofferje 
>> wrote:
>> > Well, joy was short... I added a QT GUI range item and...
>> >
>> > Traceback (most recent call last):
>> >   File "/home/sgofferj/top_block.py", line 16, in 
>> > import PyQt4.Qwt5 as Qwt
>> > ImportError: No module named Qwt5
>> >
>> > libqwt5 *is* installed and there's no "qwt5" package in any repo I know
>> > off...
>>
>>
>> You must also have python-qwt5 (or PyQWT) installed to use these widgets.
>>
>> And to respond to the above comment from the OpenSUSE mailing list you
>> posted, this is /not/ reinventing the wheel. We are doing something
>> completely different with Qwt than what PyQwt does to make all of the
>> blocks work in C++. We make our own QWT widgets in C++ and then export
>> those. But we also use PyQWT for things that are naturally supported
>> there.
>>
>> Plus, PyQWT has stopped development and has even stated that they will
>> not support QWT6, which is a shame and will eventually cause us and
>> anyone else trying to use PyQWT real issues in the future. I've been
>> looking for an alternative to it.
>>
>> Tom
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] I have a trouble with new types in python!

[Mostafa Alizadeh]

Hello everybody,
I have a new type in my gnuradio blocks which are defined in c++. However,
the GRC don't know them.
*The first question is how I could make GRC of such blocks? *

I think if I could be able to define them in python I could add new types
to the GRC of the block.
Although I'm not so familiar with python, I want to define new type as it
was previously defined in c++ as :

*typedef unsigned char   bit; *

*how could I define such variable in python!!!? *(may it helps me to make
my GRC block)

Thank,
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] convert old Gnu Radio applications

[Marcus Müller]

Hi Xianda Wang,

All the documentation is on gnuradio.org; what you're looking for is
mostly the GNU Radio doxygen, located at
http://gnuradio.org/doc/doxygen/index.html

Greetings,
Marcus Müller

On 07.05.2014 11:08, 王先达 wrote:
> Hello Sylvain
>   Thank you very much.
>   But another question i want to ask.Where can i find the 
> document of function and class which are in the new api?These document can 
> provide all the meaning of the function and class written by c++.And the 
> document of api is so obscure that i can't find the frequently-used function 
> for example the basic function for the transmit and receive.Now i want to 
> write the basic transmit and receive modules by c++.And after i written 
> it,which folder i place it?Thank you very much.
> Best regards,
> Xianda Wang
> At 2014-05-07 02:39:22,"Sylvain Munaut" <246...@gmail.com> wrote:
>>>  Now i want to convert old Gnu Radio applications which were
>>> developed in the gnuradio 3.3.0 to the gnuradio 3.7.0.Can someone give me
>>> some advices on this?Any advices will be appreciated.
>> For modules : (or custom modules inside apps)
>>
>> Recreate the modules from scratch using the new layout using gr_modtool.
>> Then cut & paste the actual processing methods from the old code and
>> adapt it, one module at a time.
>>
>>
>> For apps:
>>
>> See the http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7
>> for namespace conversion.
>>
>>
>> Cheers,
>>
>>   Sylvain
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] convert old Gnu Radio applications

[王先达]

Hello Sylvain
  Thank you very much.
  But another question i want to ask.Where can i find the 
document of function and class which are in the new api?These document can 
provide all the meaning of the function and class written by c++.And the 
document of api is so obscure that i can't find the frequently-used function 
for example the basic function for the transmit and receive.Now i want to write 
the basic transmit and receive modules by c++.And after i written it,which 
folder i place it?Thank you very much.
Best regards,
Xianda Wang
At 2014-05-07 02:39:22,"Sylvain Munaut" <246...@gmail.com> wrote:
>>  Now i want to convert old Gnu Radio applications which were
>> developed in the gnuradio 3.3.0 to the gnuradio 3.7.0.Can someone give me
>> some advices on this?Any advices will be appreciated.
>
>For modules : (or custom modules inside apps)
>
>Recreate the modules from scratch using the new layout using gr_modtool.
>Then cut & paste the actual processing methods from the old code and
>adapt it, one module at a time.
>
>
>For apps:
>
>See the http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7
>for namespace conversion.
>
>
>Cheers,
>
>   Sylvain
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USB Hub with software controllable power supply for SDR

[Marcus Müller]

Hi Vanush,

turning the device off sounds like an odd solution for a temperature
problem.
Also, usually you're experiencing frequency drift with temperature,
which can, if your receiver architecture can't correct, will lead to
degraded SNR.

Thermal noise will only significantly increase if the temperature shift
is not negligible compared to the effective equiv. noise temperatures of
your system, which /should/ be dominated by the first amplifier stage.
So if I'd suggest anything, it would be just adding a cooler/fan/peltier
element to that, and see if your performance measurably increases, just
to verify it's a temperature problem at all.

Greetings,
Marcus

On 07.05.2014 08:13, Vanush Vaswani wrote:
> Hi all,
> 
> I'm looking for a USB hub that allows software control of each port.
> I have a FunCube Dongle Pro+ trying to pick up satellite signals; but as
> the dongle is plugged in continously, I believe it heats up and degrades
> SNR.
> Let me know if you can think of any solutions
> 
> Vanush
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python chaos

[Vanush Vaswani]

Tom,

Have you looked at PyQtGraph? I've had some success with it.

Vanush


On Thu, Dec 5, 2013 at 1:50 AM, Tom Rondeau  wrote:

> On Wed, Dec 4, 2013 at 4:49 AM, Stefan Gofferje 
> wrote:
> > Well, joy was short... I added a QT GUI range item and...
> >
> > Traceback (most recent call last):
> >   File "/home/sgofferj/top_block.py", line 16, in 
> > import PyQt4.Qwt5 as Qwt
> > ImportError: No module named Qwt5
> >
> > libqwt5 *is* installed and there's no "qwt5" package in any repo I know
> > off...
>
>
> You must also have python-qwt5 (or PyQWT) installed to use these widgets.
>
> And to respond to the above comment from the OpenSUSE mailing list you
> posted, this is /not/ reinventing the wheel. We are doing something
> completely different with Qwt than what PyQwt does to make all of the
> blocks work in C++. We make our own QWT widgets in C++ and then export
> those. But we also use PyQWT for things that are naturally supported
> there.
>
> Plus, PyQWT has stopped development and has even stated that they will
> not support QWT6, which is a shame and will eventually cause us and
> anyone else trying to use PyQWT real issues in the future. I've been
> looking for an alternative to it.
>
> Tom
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Questions on stream tags

[Martin Braun]

On 06.05.2014 12:18, Hoang Ngo Khac wrote:

Sorry, I didn't really get what you meant by "pipe the tagged stream
straight into the uhd sink".


If you put tagged streams into the UHD sink it'll understand that (and 
add eob automatically).


M




On Tue, May 6, 2014 at 2:36 PM, Martin Braun mailto:martin.br...@ettus.com>> wrote:

On 06.05.2014 04:44, Hoang Ngo Khac wrote:

Hi Martin, and all,

I meant, I want to add tx_sob and tx_eob to tell the USRP Sink to
start/stop the TX chain. I intend to add tags before the modulation,
where data type is /byte. /Since the provided block PDU to
Tagged Stream

takes message as input, I guess I need to make my own block(s).


On current master, you can also pipe the tagged stream straight into
the uhd sink.

M


On Mon, May 5, 2014 at 7:57 PM, Martin Braun
mailto:martin.br...@ettus.com>
__>> wrote:

 On 05.05.2014 09:56, Hoang Ngo Khac wrote:

 Dear List,

 I'm new to stream tags. Could someone help me to understand
 about stream
 tags and know how to use it?


 Remember that we have a lot tag debugging tools available,
such as
 the QT GUI Time Sink and tag debug.


 1. In GNU Radio Manual: "A stream tags is generated by
a block's
 work
 function and from there on flows the downstream...*until it
 reaches a
 sink*...".

 If we use tags to tell the USRP Sink to start/stop the
TX chain,
 do we
 need to modify the USRP Sink block?


 Probably not... are you talking about tx_sob and tx_eob?


 I found that gr_uhd_usrp_sink.cc file contains the
 get_tags_in_range()
 function. However, this file is not, at first, in the
GNU Radio
 3.7.0
 source folder. How to add this to project and make it
work with
 USRP Sink?


 Look in gr-uhd/, there it is.


 2. I am implementing a model of ofdm-based two-way
relaying network
 apply network coding. Up to now, each single
transmission in one
 time
 slot are done, but the model runs without any timing
 synchronization.
 For this, I need to use TDMA, and stream tags is the
solution. I
 list
 here the steps to make TDMA with stream tags. Could you
leave some
 comments if I miss some thing?
 + Add tags to stream; using provided block such as PDU
to Tagged
 Stream,
 or custom block.
 + Write a block for error checking, repeat request...


 Seems right. You shouldn't need other blocks to control UHD.

 M


 ___
 Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


>




_
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting this today from recent GR master build:

[Martin Braun]

On 06.05.2014 16:35, Marcus Leech wrote:

Well, I was utterly unable to get it to work, using any recent GR paired
with latest "master" of UHD.
I get the same error every time.  The swig-generated code "looks"
correct, but this error persists.
I have cleaned every vestige of Gnu Radio and UHD from my system, and
done totally-clean builds and this
   happens.  Yet, when I use the gr-osmosdr wrapper, it works just fine,
which suggests that it's in the
   SWIGging that happens for gr-uhd.



FYI: The cause of this might be tagged stream support Sean and I added a 
while back.
gr-osmosdr uses the legacy setup call, which doesn't (and won't) support 
TSBs, so this corroborates the hypothesis.


However...


on May 06, 2014, *Martin Braun*  wrote:

On 06.05.2014 01:17, Johnathan Corgan wrote:
 > On 05/05/2014 03:00 PM, Marcus D. Leech wrote:
 >
 >> NotImplementedError: Wrong number or type of arguments for
overloaded
 >> function 'usrp_source_make'.
 >> Possible C/C++ prototypes are:
 >> make(::uhd::device_addr_t const &,::uhd::io_type_t const &,size_t)
 >> gr::uhd::usrp_source::make(::uhd::device_addr_t const
 >> &,::uhd::stream_args_t const &)


The second of these make calls was changed, and this doesn't reflect the 
changes we did. Will need to investigate. I'll ping you in IRC when I 
get 'round to doing so.


M



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Out of Tree Block Not Showing up in GRC

[Martin Braun]

Order of XML tags matters, check grc/python/block.dtd.

Martin

On 07.05.2014 02:07, Ron Economos wrote:

Here's an even more basic example that doesn't use
the opt tag. It shows my complete cluelessness about
xml, but it works.

https://github.com/drmpeg/gr-dvbs/blob/master/grc/dvbs_puncture_bb.xml

Ron

On 5/6/2014 11:55 AM, Jonathan Fox wrote:

Thanks for the response, I was looking at the opt tags and I am still
confused about how to do it. Do I need to set it up like this:

  specsense.energy_detector_sink_f($vlen, $eta,
$white_space.val, $samp_rate, $cntr_freq, $verbose)

  
Desired Detection
white_space
bool

  Open Band
  True
  val:True


  Closed Band
  False
  val:False

  

  
Verbose
verbose
bool

  Yes
  True
  val:True


  No
  False
  val:False

  

Thanks,

Jon


On Tue, May 6, 2014 at 11:08 AM, Ron Economos mailto:w...@comcast.net>> wrote:

Take a look at:

https://github.com/BogdanDIA/gr-dvbt/blob/master/grc/dvbt_inner_coder.xml

Ron


On 5/6/2014 7:00 AM, Jonathan Fox wrote:

I have two out of tree blocks I want to add to GRC, everything
compiles and installs correctly except for the GRC component
(not shown in GRC). So this should be an XML issue and I think
it is related to my attempts at making a drop down option
choice concerning the detection of white space/closed
frequencies and verbose output. My XML is attached below and
you can see that under Params Desired Detection and Verbose
have options.

When I look at other stock GNU Radio block's XML like the low
pass filter, I see that some params have opt tags. Do I need
these also, if so how would I use them in my case?

Thanks,

Jon





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Python chaos

[Martin Braun]

On 07.05.2014 05:59, Vanush Vaswani wrote:

The lack of notice for Generate Options is a killer. Not to mention, if
using QT sinks with WX GUI set, a cryptic error message is the reuslt.


We know, and we have this on our long todo list for GRC. We still don't 
have an abundance of GRC devs, so don't bet on this being done next week.


Martin




On Mon, May 5, 2014 at 8:20 PM, activecat mailto:active...@gmail.com>> wrote:

Tom Rondeau-2 wrote
 > Plus, PyQWT has stopped development and has even stated that they
will
 > not support QWT6, which is a shame and will eventually cause us and
 > anyone else trying to use PyQWT real issues in the future. I've been
 > looking for an alternative to it.

Will this affect gnuradio moving away from wxwidgets toward Qt ?



--
View this message in context:
http://gnuradio.4.n7.nabble.com/Python-chaos-tp45076p47953.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] apps/ directory

[Activecat]

Refer
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Structure-of-a-module

"The apps/ subdir contains any complete applications (both for GRC and
standalone executables) which are installed to the system alongside with
the blocks."

Question:
I intend to store my flow-graphs in apps/ directory.
Will the files be "installed" to /usr/local when someone perform "sudo make
install" later ..?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio