Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[Marcus Müller]

Hi Ranga,

that's what pointers are for, after all. Just do it! Thanks to the 
make()-magic you basically always have a smart shared pointer instead of 
an block object (unless you really try to break the system ;) ).


Just a quick note though: MAC is usually timing-relevant. Timed commands 
might not work as you expect, so please be aware that calling 
set_command_time on your source might break functionality since there is 
no out-of-order execution.


Greetings,
Marcus

On 14.11.2013 01:26, M. Ranganathan wrote:

Hello all!

I want to write a block that can directly access the uhd_usrp_source. 
This block is a mac block hence it is up on the food chain and far 
away from uhd_usrp_source in terms of its processing function. What is 
a good way of passing it a handle to the usrp_source ?


I can think of some hacks (such as a static global pointer where the 
uhd_usrp_source C++ object registers itself) but it seems ugly to me 
to take that route. Is there a better way to access global objects 
from within a block implementation.


Thanks in advance for any help.

Regards,

Ranga

--
M. Ranganathan


___
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] pfb_arb_resampler_ccf

[Marcus Müller]

Hi bzs,
really short:

pfb = polyphase filter bank = what it is
arb = arbitrary
resampler = what it does
ccf = complex in, complex out, float taps

Greetings,
Marcus

On 14.11.2013 08:50, ?? wrote:

hello all!

who can tell me?what is "pfb_arb_resampler_ccf"?and what does it do?


bzs


___
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] GR 3.7.3 vs. gqrx?

[Ralph A. Schmid, dk5ras]

Hi,

It seems to me that gqrx cries for libgnuradio-runtime-3.7.2git.so.0.0.0,
but latest GR brings 3.7.3 into the system. Did I miss smth., or are the
projects just not yet "in sync"?

Ralph, dk5ras.

--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/







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

Re: [Discuss-gnuradio] GR 3.7.3 vs. gqrx?

[Sylvain Munaut]

Hi,

> It seems to me that gqrx cries for libgnuradio-runtime-3.7.2git.so.0.0.0,
> but latest GR brings 3.7.3 into the system. Did I miss smth., or are the
> projects just not yet "in sync"?

Well, did you rebuild everything after updating GR ?

(that includes any GR based stuff, so gr-osmosdr, gr-iqbal (if
installed), gqrx ...)

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] GR 3.7.3 vs. gqrx?

[Ralph A. Schmid, dk5ras]

> Well, did you rebuild everything after updating GR ?
> 
> (that includes any GR based stuff, so gr-osmosdr, gr-iqbal (if installed), 
> gqrx
...)

Ah, I forgot gr-iqbal! All the other stuff I updated and rebuilt, just not 
this one. Now it looks better, it only complains about the missing HW that 
really is not there :) Will try later if my bladeRF is recognized, but I expect 
so.
 
> Cheers,
> 
> Sylvain

Thanks a lot!

Ralph.



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

Re: [Discuss-gnuradio] pfb_arb_resampler_ccf

[Tom Rondeau]

On Thu, Nov 14, 2013 at 4:08 AM, Marcus Müller  wrote:
> Hi bzs,
> really short:
>
> pfb = polyphase filter bank = what it is
> arb = arbitrary
> resampler = what it does
> ccf = complex in, complex out, float taps
>
> Greetings,
> Marcus
>
>
> On 14.11.2013 08:50, 雨缘 wrote:
>
> hello all！
>
> who can tell me？what is "pfb_arb_resampler_ccf"?and what does it do?
>
>
> bzs

Also:
http://gnuradio.org/doc/doxygen/page_pfb.html

And:
http://gnuradio.org/doc/doxygen/classgr_1_1filter_1_1pfb__arb__resampler__ccf.html

Tom

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

Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[M. Ranganathan]

Marcus,

Thanks for your reply. What will the shared pointer be called. I see stuff
like this in the code:

GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)


Presumably, that generates a structure that is registered as a global
pointer. So in my mac, I want something like

extern 

At the risk of asking for too much help, can you give me some guidance or
point me to a fragment of code somewhere that does this sort of thing.

Thanks,

Ranga



On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller  wrote:

>  Hi Ranga,
>
> that's what pointers are for, after all. Just do it! Thanks to the
> make()-magic you basically always have a smart shared pointer instead of an
> block object (unless you really try to break the system ;) ).
>
> Just a quick note though: MAC is usually timing-relevant. Timed commands
> might not work as you expect, so please be aware that calling
> set_command_time on your source might break functionality since there is no
> out-of-order execution.
>
> Greetings,
> Marcus
>
>
> On 14.11.2013 01:26, M. Ranganathan wrote:
>
>  Hello all!
>
>  I want to write a block that can directly access the uhd_usrp_source.
> This block is a mac block hence it is up on the food chain and far away
> from uhd_usrp_source in terms of its processing function. What is a good
> way of passing it a handle to the usrp_source ?
>
>  I can think of some hacks (such as a static global pointer where the
> uhd_usrp_source C++ object registers itself) but it seems ugly to me to
> take that route. Is there a better way to access global objects from within
> a block implementation.
>
>  Thanks in advance for any help.
>
>  Regards,
>
> Ranga
>
> --
> M. Ranganathan
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[Marcus Müller]

In GR 3.7, the shared pointer is usually blockname::sptr;

I can't really point you to a very good example, but when you call
top_block.connect(src, sink) in C++, you're giving it spointers :)

As I said, whenever you make a block, you actually get a shared pointer 
to that instance, and not the object itself.


On 14.11.2013 15:39, M. Ranganathan wrote:

Marcus,

Thanks for your reply. What will the shared pointer be called. I see 
stuff like this in the code:


GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)


Presumably, that generates a structure that is registered as a global 
pointer. So in my mac, I want something like


extern 

At the risk of asking for too much help, can you give me some guidance 
or point me to a fragment of code somewhere that does this sort of thing.


Thanks,

Ranga



On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller > wrote:


Hi Ranga,

that's what pointers are for, after all. Just do it! Thanks to the
make()-magic you basically always have a smart shared pointer
instead of an block object (unless you really try to break the
system ;) ).

Just a quick note though: MAC is usually timing-relevant. Timed
commands might not work as you expect, so please be aware that
calling set_command_time on your source might break functionality
since there is no out-of-order execution.

Greetings,
Marcus


On 14.11.2013 01:26, M. Ranganathan wrote:

Hello all!

I want to write a block that can directly access the
uhd_usrp_source. This block is a mac block hence it is up on the
food chain and far away from uhd_usrp_source in terms of its
processing function. What is a good way of passing it a handle to
the usrp_source ?

I can think of some hacks (such as a static global pointer where
the uhd_usrp_source C++ object registers itself) but it seems
ugly to me to take that route. Is there a better way to access
global objects from within a block implementation.

Thanks in advance for any help.

Regards,

Ranga

-- 
M. Ranganathan



___
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




--
M. Ranganathan


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

Re: [Discuss-gnuradio] pfb_arb_resampler_ccf

[Marcus M??ller]

Hi bzs,

please always reply to the list, so we can all help you.
I'm very sorry, but I can't explain the concept of a polyphase 
filterbank in a few sentences; please refer to literature for this. On 
how it realizes this: The only thing I could do is look at the source 
code and translate C++ to english; I think it's better if you do that 
yourself.


Greetings,
Marcus

On 14.11.2013 10:13,  wrote:

hi??Marcus

thanks for your answer! I mean how does this module  realize and what 
function it has?


bzs



-- Original --
*From: * "Marcus M??lle";;
*Date: * Thu, Nov 14, 2013 05:08 PM
*To: * "discuss-gnuradio";
*Subject: * Re: [Discuss-gnuradio] pfb_arb_resampler_ccf

Hi bzs,
really short:

pfb = polyphase filter bank = what it is
arb = arbitrary
resampler = what it does
ccf = complex in, complex out, float taps

Greetings,
Marcus

On 14.11.2013 08:50,  wrote:

hello all??

who can tell me??what is "pfb_arb_resampler_ccf"?and what does it do?


bzs


___
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] Accessing the uhd_usrp object

[M. Ranganathan]

Marcus,

Looking around I don't see where the pointer to the block is made globally
visible. I am inclined to add some code to the make method to register the
shared pointer in a global variable when the method is called. Since my
application has only a single USRP block (source and sink), there's no
danger of overwriting something.

My problem is this:

I have python code that creates the blocks and strings them together etc.
but I want to actually access the created block from c++ code (in the mac
block implementation).

Let me know if I am seriously astray.


Thanks again for your help.






On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller  wrote:

>  In GR 3.7, the shared pointer is usually blockname::sptr;
>
> I can't really point you to a very good example, but when you call
> top_block.connect(src, sink) in C++, you're giving it spointers :)
>
> As I said, whenever you make a block, you actually get a shared pointer to
> that instance, and not the object itself.
>
>
> On 14.11.2013 15:39, M. Ranganathan wrote:
>
>Marcus,
>
>  Thanks for your reply. What will the shared pointer be called. I see
> stuff like this in the code:
>
> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
> GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)
>
>
>  Presumably, that generates a structure that is registered as a global
> pointer. So in my mac, I want something like
>
>  extern 
>
>  At the risk of asking for too much help, can you give me some guidance or
> point me to a fragment of code somewhere that does this sort of thing.
>
>  Thanks,
>
>  Ranga
>
>
>
> On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller  wrote:
>
>>  Hi Ranga,
>>
>> that's what pointers are for, after all. Just do it! Thanks to the
>> make()-magic you basically always have a smart shared pointer instead of an
>> block object (unless you really try to break the system ;) ).
>>
>> Just a quick note though: MAC is usually timing-relevant. Timed commands
>> might not work as you expect, so please be aware that calling
>> set_command_time on your source might break functionality since there is no
>> out-of-order execution.
>>
>> Greetings,
>> Marcus
>>
>>
>> On 14.11.2013 01:26, M. Ranganathan wrote:
>>
>>   Hello all!
>>
>>  I want to write a block that can directly access the uhd_usrp_source.
>> This block is a mac block hence it is up on the food chain and far away
>> from uhd_usrp_source in terms of its processing function. What is a good
>> way of passing it a handle to the usrp_source ?
>>
>>  I can think of some hacks (such as a static global pointer where the
>> uhd_usrp_source C++ object registers itself) but it seems ugly to me to
>> take that route. Is there a better way to access global objects from within
>> a block implementation.
>>
>>  Thanks in advance for any help.
>>
>>  Regards,
>>
>> Ranga
>>
>> --
>> M. Ranganathan
>>
>>
>>  ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> M. Ranganathan
>
>
>


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

Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[Marcus Leech]

Why does the MAC block need to "reach around" way down into the depths of the PHY layer?
 
on Nov 14, 2013, M. Ranganathan  wrote:


Marcus,Looking around I don't see where the pointer to the block is made globally visible. I am inclined to add some code to the make method to register the shared pointer in a global variable when the method is called. Since my application has only a single USRP block (source and sink), there's no danger of overwriting something.  
My problem is this:
I have python code that creates the blocks and strings them together etc. but I want to actually access the created block from c++ code (in the mac block implementation).  
Let me know if I am seriously astray. 
Thanks again for your help.

 


On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller  wrote:

In GR 3.7, the shared pointer is usually blockname::sptr;  I can't really point you to a very good example, but when you call top_block.connect(src, sink) in C++, you're giving it spointers :)  As I said, whenever you make a block, you actually get a shared pointer to that instance, and not the object itself.

 
On 14.11.2013 15:39, M. Ranganathan wrote:







Marcus, 
Thanks for your reply. What will the shared pointer be called. I see stuff like this in the code:  GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source) GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink) GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)  
Presumably, that generates a structure that is registered as a global pointer. So in my mac, I want something like 
extern   
At the risk of asking for too much help, can you give me some guidance or point me to a fragment of code somewhere that does this sort of thing. 
Thanks, 
Ranga





 






 
On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller  wrote:

Hi Ranga,  that's what pointers are for, after all. Just do it! Thanks to the make()-magic you basically always have a smart shared pointer instead of an block object (unless you really try to break the system ;) ).  Just a quick note though: MAC is usually timing-relevant. Timed commands might not work as you expect, so please be aware that calling set_command_time on your source might break functionality since there is no out-of-order execution.  Greetings, Marcus

 
On 14.11.2013 01:26, M. Ranganathan wrote:







Hello all! 
I want to write a block that can directly access the uhd_usrp_source. This block is a mac block hence it is up on the food chain and far away from uhd_usrp_source in terms of its processing function. What is a good way of passing it a handle to the usrp_source ?  
I can think of some hacks (such as a static global pointer where the uhd_usrp_source C++ object registers itself) but it seems ugly to me to take that route. Is there a better way to access global objects from within a block implementation.  
Thanks in advance for any help. 
Regards,
 Ranga


 --  M. Ranganathan





___
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 

   --  M. Ranganathan






-- M. Ranganathan
___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] Accessing the uhd_usrp object

[Sylvain Munaut]

Hi,

> Looking around I don't see where the pointer to the block is made globally
> visible.

No where.

There could be several UHD source/sink blocks, so nothing will be made
globally visible by GR.


> I have python code that creates the blocks and strings them together etc.
> but I want to actually access the created block from c++ code (in the mac
> block implementation).

You'll have to give the instanciated uhd source block as an argument
of your custom block constructor and play with SWIG to make the Python
object be converted back to a C++ smart pointer. Have fun.


> Let me know if I am seriously astray.

You are. Whatever you need to do, there has to be a better way.


Cheers,

Sylvain

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

Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[M. Ranganathan]

I am working on a dynamic spectrum mac where the MAC will reach out to a TV
White space DB (and also potentially do spectrum sensing) and adjust the
centre frequency of the USRP periodically.

Thanks for your help!

Regards,

Ranga


On Thu, Nov 14, 2013 at 11:07 AM, Marcus Leech  wrote:

> Why does the MAC block need to "reach around" way down into the depths of
> the PHY layer?
>
>
> on Nov 14, 2013, *M. Ranganathan*  wrote:
>
>  Marcus,
>
> Looking around I don't see where the pointer to the block is made globally
> visible. I am inclined to add some code to the make method to register the
> shared pointer in a global variable when the method is called. Since my
> application has only a single USRP block (source and sink), there's no
> danger of overwriting something.
>  My problem is this:
>
> I have python code that creates the blocks and strings them together etc.
> but I want to actually access the created block from c++ code (in the mac
> block implementation).
>  Let me know if I am seriously astray.
>
>
> Thanks again for your help.
>
>
>
>
>
> On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller  wrote:
>
>> In GR 3.7, the shared pointer is usually blockname::sptr;
>>
>> I can't really point you to a very good example, but when you call
>> top_block.connect(src, sink) in C++, you're giving it spointers :)
>>
>> As I said, whenever you make a block, you actually get a shared pointer
>> to that instance, and not the object itself.
>>
>>
>> On 14.11.2013 15:39, M. Ranganathan wrote:
>>
>>Marcus,
>>  Thanks for your reply. What will the shared pointer be called. I see
>> stuff like this in the code:
>>
>> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
>> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
>> GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)
>>
>>  Presumably, that generates a structure that is registered as a global
>> pointer. So in my mac, I want something like
>>  extern 
>>  At the risk of asking for too much help, can you give me some guidance
>> or point me to a fragment of code somewhere that does this sort of thing.
>>  Thanks,
>>  Ranga
>>
>>
>>
>> On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller wrote:
>>
>>> Hi Ranga,
>>>
>>> that's what pointers are for, after all. Just do it! Thanks to the
>>> make()-magic you basically always have a smart shared pointer instead of an
>>> block object (unless you really try to break the system ;) ).
>>>
>>> Just a quick note though: MAC is usually timing-relevant. Timed commands
>>> might not work as you expect, so please be aware that calling
>>> set_command_time on your source might break functionality since there is no
>>> out-of-order execution.
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> On 14.11.2013 01:26, M. Ranganathan wrote:
>>>
>>>   Hello all!
>>>  I want to write a block that can directly access the uhd_usrp_source.
>>> This block is a mac block hence it is up on the food chain and far away
>>> from uhd_usrp_source in terms of its processing function. What is a good
>>> way of passing it a handle to the usrp_source ?
>>>  I can think of some hacks (such as a static global pointer where the
>>> uhd_usrp_source C++ object registers itself) but it seems ugly to me to
>>> take that route. Is there a better way to access global objects from within
>>> a block implementation.
>>>  Thanks in advance for any help.
>>>  Regards,
>>>
>>> Ranga
>>>
>>> --
>>> M. Ranganathan
>>>
>>>  ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> M. Ranganathan
>>
>>
>
>
> --
> M. Ranganathan
>
> --
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>



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

Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[Marcus Müller]

Hi Ranga,

either you're seriously astray or I don't understand what you want.
This is C++ running on an operating system with segmentation. There are 
*no* globally visibly objects, there is only calls to the operating 
systems / IPC to communicate with other processes and objects that live 
within your own process that you can directly address. Ok, there's 
shared memory, but you can't move a uhd_source to shared pages; that 
doesn't make sense.


When you're in the same process, it's easy just to pass pointers around. 
They are objects as everything else. Let's assume you construct a 
flowgraph like

top_block->connect(uhd_source, processing, mac, sink)
then you can just do
mac->set_uhd_src_pointer(uhd_source)

which would be something like
mymac::set_uhd_src_pointer(uhd_source::sptr src)
{
_uhd_src_sptr = src;
}

which enables you to just
_uhd_src_sptr->set_center_frequency(2);
inside your class.

Greetings,

Marcus

On 14.11.2013 16:53, M. Ranganathan wrote:

Marcus,

Looking around I don't see where the pointer to the block is made 
globally visible. I am inclined to add some code to the make method to 
register the shared pointer in a global variable when the method is 
called. Since my application has only a single USRP block (source and 
sink), there's no danger of overwriting something.


My problem is this:

I have python code that creates the blocks and strings them together 
etc. but I want to actually access the created block from c++ code (in 
the mac block implementation).


Let me know if I am seriously astray.


Thanks again for your help.






On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller > wrote:


In GR 3.7, the shared pointer is usually blockname::sptr;

I can't really point you to a very good example, but when you call
top_block.connect(src, sink) in C++, you're giving it spointers :)

As I said, whenever you make a block, you actually get a shared
pointer to that instance, and not the object itself.


On 14.11.2013 15:39, M. Ranganathan wrote:

Marcus,

Thanks for your reply. What will the shared pointer be called. I
see stuff like this in the code:

GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)


Presumably, that generates a structure that is registered as a
global pointer. So in my mac, I want something like

extern 

At the risk of asking for too much help, can you give me some
guidance or point me to a fragment of code somewhere that does
this sort of thing.

Thanks,

Ranga



On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller
mailto:mar...@hostalia.de>> wrote:

Hi Ranga,

that's what pointers are for, after all. Just do it! Thanks
to the make()-magic you basically always have a smart shared
pointer instead of an block object (unless you really try to
break the system ;) ).

Just a quick note though: MAC is usually timing-relevant.
Timed commands might not work as you expect, so please be
aware that calling set_command_time on your source might
break functionality since there is no out-of-order execution.

Greetings,
Marcus


On 14.11.2013 01:26, M. Ranganathan wrote:

Hello all!

I want to write a block that can directly access the
uhd_usrp_source. This block is a mac block hence it is up on
the food chain and far away from uhd_usrp_source in terms of
its processing function. What is a good way of passing it a
handle to the usrp_source ?

I can think of some hacks (such as a static global pointer
where the uhd_usrp_source C++ object registers itself) but
it seems ugly to me to take that route. Is there a better
way to access global objects from within a block
implementation.

Thanks in advance for any help.

Regards,

Ranga

-- 
M. Ranganathan



___
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




-- 
M. Ranganathan





--
M. Ranganathan


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

Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[M. Ranganathan]

Marcus,

Based on what you and others have replied, I think my "most elegant" plan
of attack would be to toss the generated puthon glue code (which I
generated using grc-companion BTW) and do everything in C++ so I dont have
to worry about the language interface at all.

This way, I will not need global shared pointers.

Thank you again for all the time you have spent responding to me.

Ranga


On Thu, Nov 14, 2013 at 11:43 AM, Marcus Müller  wrote:

>  Hi Ranga,
>
> either you're seriously astray or I don't understand what you want.
> This is C++ running on an operating system with segmentation. There are
> *no* globally visibly objects, there is only calls to the operating systems
> / IPC to communicate with other processes and objects that live within your
> own process that you can directly address. Ok, there's shared memory, but
> you can't move a uhd_source to shared pages; that doesn't make sense.
>
> When you're in the same process, it's easy just to pass pointers around.
> They are objects as everything else. Let's assume you construct a flowgraph
> like
> top_block->connect(uhd_source, processing, mac, sink)
> then you can just do
> mac->set_uhd_src_pointer(uhd_source)
>
> which would be something like
> mymac::set_uhd_src_pointer(uhd_source::sptr src)
> {
> _uhd_src_sptr = src;
> }
>
> which enables you to just
> _uhd_src_sptr->set_center_frequency(2);
> inside your class.
>
> Greetings,
>
> Marcus
>
>
> On 14.11.2013 16:53, M. Ranganathan wrote:
>
>  Marcus,
>
> Looking around I don't see where the pointer to the block is made globally
> visible. I am inclined to add some code to the make method to register the
> shared pointer in a global variable when the method is called. Since my
> application has only a single USRP block (source and sink), there's no
> danger of overwriting something.
>
>  My problem is this:
>
>  I have python code that creates the blocks and strings them together
> etc. but I want to actually access the created block from c++ code (in the
> mac block implementation).
>
>  Let me know if I am seriously astray.
>
>
>  Thanks again for your help.
>
>
>
>
>
>
> On Thu, Nov 14, 2013 at 9:52 AM, Marcus Müller  wrote:
>
>>  In GR 3.7, the shared pointer is usually blockname::sptr;
>>
>> I can't really point you to a very good example, but when you call
>> top_block.connect(src, sink) in C++, you're giving it spointers :)
>>
>> As I said, whenever you make a block, you actually get a shared pointer
>> to that instance, and not the object itself.
>>
>>
>> On 14.11.2013 15:39, M. Ranganathan wrote:
>>
>>Marcus,
>>
>>  Thanks for your reply. What will the shared pointer be called. I see
>> stuff like this in the code:
>>
>> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_source)
>> GR_SWIG_BLOCK_MAGIC2(uhd, usrp_sink)
>> GR_SWIG_BLOCK_MAGIC2(uhd, amsg_source)
>>
>>
>>  Presumably, that generates a structure that is registered as a global
>> pointer. So in my mac, I want something like
>>
>>  extern 
>>
>>  At the risk of asking for too much help, can you give me some guidance
>> or point me to a fragment of code somewhere that does this sort of thing.
>>
>>  Thanks,
>>
>>  Ranga
>>
>>
>>
>> On Thu, Nov 14, 2013 at 4:06 AM, Marcus Müller wrote:
>>
>>>  Hi Ranga,
>>>
>>> that's what pointers are for, after all. Just do it! Thanks to the
>>> make()-magic you basically always have a smart shared pointer instead of an
>>> block object (unless you really try to break the system ;) ).
>>>
>>> Just a quick note though: MAC is usually timing-relevant. Timed commands
>>> might not work as you expect, so please be aware that calling
>>> set_command_time on your source might break functionality since there is no
>>> out-of-order execution.
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> On 14.11.2013 01:26, M. Ranganathan wrote:
>>>
>>>   Hello all!
>>>
>>>  I want to write a block that can directly access the uhd_usrp_source.
>>> This block is a mac block hence it is up on the food chain and far away
>>> from uhd_usrp_source in terms of its processing function. What is a good
>>> way of passing it a handle to the usrp_source ?
>>>
>>>  I can think of some hacks (such as a static global pointer where the
>>> uhd_usrp_source C++ object registers itself) but it seems ugly to me to
>>> take that route. Is there a better way to access global objects from within
>>> a block implementation.
>>>
>>>  Thanks in advance for any help.
>>>
>>>  Regards,
>>>
>>> Ranga
>>>
>>> --
>>> M. Ranganathan
>>>
>>>
>>>  ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> M. Ranganathan
>>
>>
>>
>
>
> --
> M. Ranganathan
>
>
>


-- 
M. Ranganathan
___
Discuss-gnurad

Re: [Discuss-gnuradio] Accessing the uhd_usrp object

[Sylvain Munaut]

Hi,


First: Please pay attention and reply to the list and not to me personally.


> A suggested "improvement" to the gnuradio code base (let me know what you
> think) :
> Please keep such objects in a globally visible list (I can provide a diff if 
> there is interest) so that applications such as mine can access them. UHD > 
> sources and sinks are likely to be quite static as are indeed most gr blocks 
> I would suspect.

What I think is that I wouldn't call that an improvement at all. IMHO
It's a horrible design ...


>> You'll have to give the instanciated uhd source block as an argument
>> of your custom block constructor and play with SWIG to make the Python
>> object be converted back to a C++ smart pointer. Have fun.
>
> It sounds quite messy and hence I had to ask this list if there was a better
> way.

Wait what ?  Passing the pointer cleanly between blocks is "messy",
but polluting the global application namespace is "clean" ??? I think
we have radically different idea of what's good design and what's not
...


> I am open to any ideas.  I could of course modify the gnuradio source code
> to export a global pointer but I'd love it if  I could leave the core source
> code alone.

If I'm not mistaken, you can control the UHD source / sink with
message passing to change the frequency. Then your MAC just has a msg
output port connecting to the uhd message input port to control it.

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] GnuradioConfig.cmake not working properly ?

[Douglas Geiger]

I think that needs to be applied to the maint branch as well: i.e.
Sylvain's first patch got applied to both master and maint, but the fix
(second patch) only ended up on master.
 Doug


On Wed, Nov 13, 2013 at 11:21 AM, Tom Rondeau  wrote:

> On Tue, Nov 12, 2013 at 1:28 PM, Martin Braun (CEL)
>  wrote:
> > On Tue, Nov 12, 2013 at 06:54:43PM +0100, Sylvain Munaut wrote:
> >> The attached patch fixes that by re-declaring the variable in the
> parent scope.
> >>
> >> This fixes the gr-osmosdr build for me.
> >> @Martin : could you give it a shot to check it fixes it for you too ?
> >
> > Yep, this fixes gr-osmosdr on my side.
> >
> > MB
>
>
> Patches applied. I also updated the OOT tutorial to use REQUIRED and
> gr-modtool now defaults to using the GnuradioConfig style checks with
> REQUIRED as well.
>
> Thanks!
>
> Tom
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Doug Geiger
doug.gei...@bioradiation.net
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GnuradioConfig.cmake not working properly ?

[Tom Rondeau]

On Thu, Nov 14, 2013 at 12:25 PM, Douglas Geiger
 wrote:
> I think that needs to be applied to the maint branch as well: i.e. Sylvain's
> first patch got applied to both master and maint, but the fix (second patch)
> only ended up on master.
>  Doug

Thanks for catching that. Since I had done some other changes to how
GnuradioConfig is used, I thought I only put that on master. Fixed
now.

Tom


> On Wed, Nov 13, 2013 at 11:21 AM, Tom Rondeau  wrote:
>>
>> On Tue, Nov 12, 2013 at 1:28 PM, Martin Braun (CEL)
>>  wrote:
>> > On Tue, Nov 12, 2013 at 06:54:43PM +0100, Sylvain Munaut wrote:
>> >> The attached patch fixes that by re-declaring the variable in the
>> >> parent scope.
>> >>
>> >> This fixes the gr-osmosdr build for me.
>> >> @Martin : could you give it a shot to check it fixes it for you too ?
>> >
>> > Yep, this fixes gr-osmosdr on my side.
>> >
>> > MB
>>
>>
>> Patches applied. I also updated the OOT tutorial to use REQUIRED and
>> gr-modtool now defaults to using the GnuradioConfig style checks with
>> REQUIRED as well.
>>
>> Thanks!
>>
>> Tom
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> --
> Doug Geiger
> doug.gei...@bioradiation.net
>
> ___
> 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] Accessing the uhd_usrp object

[M. Ranganathan]

On Thu, Nov 14, 2013 at 12:14 PM, Sylvain Munaut <246...@gmail.com> wrote:

> Hi,
>
>
> First: Please pay attention and reply to the list and not to me personally.
>


Mercy! That was an honest mistake. A thousand apologies.


>
>
> > A suggested "improvement" to the gnuradio code base (let me know what you
> > think) :
> > Please keep such objects in a globally visible list (I can provide a
> diff if there is interest) so that applications such as mine can access
> them. UHD > sources and sinks are likely to be quite static as are indeed
> most gr blocks I would suspect.
>
> What I think is that I wouldn't call that an improvement at all. IMHO
> It's a horrible design ...
>


I agree. If you notice I started off with that premise (i.e. that it was a
hack).



>
>
> >> You'll have to give the instanciated uhd source block as an argument
> >> of your custom block constructor and play with SWIG to make the Python
> >> object be converted back to a C++ smart pointer. Have fun.
> >
> > It sounds quite messy and hence I had to ask this list if there was a
> better
> > way.
>
> Wait what ?  Passing the pointer cleanly between blocks is "messy",
> but polluting the global application namespace is "clean" ??? I think
> we have radically different idea of what's good design and what's not
> ...
>
>
> > I am open to any ideas.  I could of course modify the gnuradio source
> code
> > to export a global pointer but I'd love it if  I could leave the core
> source
> > code alone.
>
> If I'm not mistaken, you can control the UHD source / sink with
> message passing to change the frequency. Then your MAC just has a msg
> output port connecting to the uhd message input port to control it.
>


I will look at the block again but I could not see that.


Thanks for taking the time to reply.

Regards,

Ranga



>
> Cheers,
>
> Sylvain
>



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

Re: [Discuss-gnuradio] [User Experience] Hangout Thursday

[Martin Braun (CEL)]

The call has started, to join please head to #gnuradio on Freenode and
the G+ page.

We'll be streaming live on YouTube, too.

MB

On Mon, Nov 11, 2013 at 06:24:51PM +0100, Martin Braun (CEL) wrote:
> Hi everyone,
> 
> Thursday is our first post-conference hangout regarding everything user
> experience related. This includes:
> 
> - The web site (in particular: state of the in-wiki docs, FAQ)
> - Tutorials
> - General user experience
> 
> At the conference, this spawned many different discussions and I've
> received lots of feedback, so I'm expecting a busy call.
> 
> For people who have joined the community recently: This is a good place
> to help and contribute. In order to improve docs etc., we need GNU Radio
> beginners to give us feedback or, better still, write stuff yourself.
> 
> The call starts 19:00 CET. Please head over to our Google Plus community
> page (https://plus.google.com/communities/105194615257651755927) to find
> out more and convert the time to your timezone.
> 
> Please also join the #gnuradio IRC channel during the call. This way we
> can coordinate people who have trouble joining (and no matter how
> tech-savvy you think you are, G+ has ways of keeping you out of the call
> :). Also, we might run into participant limits, because hangouts only
> take 10 people max.
> 
> Looking forward to new faces and good discussions!
> 
> Martin
> 
> -- 
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
> 
> Dipl.-Ing. Martin Braun
> Research Associate
> 
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
> 
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
> 
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association



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


-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgprl6kU9mOgP.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] No USRPs found on interface eth0

[nesimi eldarov]

 Dear All,

I will ask you very old and classical question:
'RuntimeError: No USRPs found on interface eth0'

I have USRP N200

I run:
$ sudo ifconfig eth0 192.168.10.1
$ uhd_find_devices
linux; GNU C++ version 4.4.1; Boost_103800; UHD_003.005.004-140-gfb32ed16

--
-- UHD Device 0
--
Device Address:
    type: usrp2
    addr: 192.168.10.2
    name: 
    serial: F3F0D3
$ sudo find_usrps
No USRP2 found.
$ sudo ftw_ofdm_tx.py --interface=eth0 --freq=2.412e9 --interp=5 
--payload="some arbitrary text as MSDU ASCII payload" --regime=1
Traceback (most recent call last):
  File "/usr/local/bin/ftw_ofdm_tx.py", line 171, in 
    main()
  File "/usr/local/bin/ftw_ofdm_tx.py", line 153, in main
    tb = my_top_block(options, my_msg)
  File "/usr/local/bin/ftw_ofdm_tx.py", line 59, in __init__
    self._setup_usrp_sink()
  File "/usr/local/bin/ftw_ofdm_tx.py", line 72, in _setup_usrp_sink
    self.u = usrp2.sink_32fc(self._interface, self._mac_addr)
  File "/usr/lib/python2.6/dist-packages/gnuradio/usrp2.py", line 1102, in 
sink_32fc
    return _usrp2.sink_32fc(*args, **kwargs)
RuntimeError: No USRPs found on interface eth0

Can you please help me to find a solution to this problem?

--
NE


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

Re: [Discuss-gnuradio] No USRPs found on interface eth0

[Nick Foster]

The solution is the USRP2 interface is no longer supported, and software
which uses it must be ported to UHD. The find_usrps tool is no longer
usable with modern Ettus hardware.

--n


On Thu, Nov 14, 2013 at 10:02 AM, nesimi eldarov  wrote:

> Dear All,
>
> I will ask you very old and classical question:
> 'RuntimeError: No USRPs found on interface eth0'
>
> I have USRP N200
>
> I run:
> $ sudo ifconfig eth0 192.168.10.1
> $ uhd_find_devices
> linux; GNU C++ version 4.4.1; Boost_103800; UHD_003.005.004-140-gfb32ed16
>
> --
> -- UHD Device 0
> --
> Device Address:
> type: usrp2
> addr: 192.168.10.2
> name:
> serial: F3F0D3
> $ sudo find_usrps
> No USRP2 found.
> $ sudo ftw_ofdm_tx.py --interface=eth0 --freq=2.412e9 --interp=5
> --payload="some arbitrary text as MSDU ASCII payload" --regime=1
> Traceback (most recent call last):
>   File "/usr/local/bin/ftw_ofdm_tx.py", line 171, in 
> main()
>   File "/usr/local/bin/ftw_ofdm_tx.py", line 153, in main
> tb = my_top_block(options, my_msg)
>   File "/usr/local/bin/ftw_ofdm_tx.py", line 59, in __init__
> self._setup_usrp_sink()
>   File "/usr/local/bin/ftw_ofdm_tx.py", line 72, in _setup_usrp_sink
> self.u = usrp2.sink_32fc(self._interface, self._mac_addr)
>   File "/usr/lib/python2.6/dist-packages/gnuradio/usrp2.py", line 1102, in
> sink_32fc
> return _usrp2.sink_32fc(*args, **kwargs)
> RuntimeError: No USRPs found on interface eth0
>
> Can you please help me to find a solution to this problem?
>
> --
> NE
>
>
>
> ___
> 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] No USRPs found on interface eth0

[Marcus Leech]

Try:
uhd_usrp_probe --args "addr=192.168.10.2"
 
Also, be certain that Network Manager isn't resetting the interface back to DHCP (automatic IP address selection).  If Network Manager "owns"
  the interface, *and* the interface isn't configured for static-IP according ot Network Manager, it'll keep trying DHCP, fail, and then take
  the interface out of service.
 
Also, be certain that your network interface supports 1GiGe.
 
And there's absolute NO reason to run any of this stuff as root.  None at all.
 
on Nov 14, 2013, nesimi eldarov  wrote:
Dear All,I will ask you very old and classical question:'RuntimeError: No USRPs found on interface eth0'I have USRP N200I run:$ sudo ifconfig eth0 192.168.10.1$ uhd_find_deviceslinux; GNU C++ version 4.4.1; Boost_103800; UHD_003.005.004-140-gfb32ed16 UHD Device 0--Device Address:    type: usrp2    addr: 192.168.10.2    name:     serial: F3F0D3$ sudo find_usrpsNo USRP2 found.$ sudo ftw_ofdm_tx.py --interface=eth0 --freq=2.412e9 --interp=5 --payload="some arbitrary text as MSDU ASCII payload" --regime=1Traceback (most recent call last):  File "/usr/local/bin/ftw_ofdm_tx.py", line 171, in     main()  File "/usr/local/bin/ftw_ofdm_tx.py", line 153, in main    tb = my_top_block(options, my_msg)  File "/usr/local/bin/ftw_ofdm_tx.py", line 59, in __init__    self._setup_usrp_sink()  File "/usr/local/bin/ftw_ofdm_tx.py", line 72, in _setup_usrp_sink    self.u = usrp2.sink_32fc(self._interface, self._mac_addr)  File "/usr/lib/python2.6/dist-packages/gnuradio/usrp2.py", line 1102, in sink_32fc    return _usrp2.sink_32fc(*args, **kwargs)RuntimeError: No USRPs found on interface eth0Can you please help me to find a solution to this problem?--NE ___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] No USRPs found on interface eth0

[Marcus Leech]

Gah!
I missed the second-half where nesazeri was using find_usrps.
 
Indeed, if you have software that uses the "classic" (pre-UHD) interface, that interface has been obsolete for several years and is no longer
  supported.  The N2XX in particular, *does not* support the "classic" interface.
 
 
 
on Nov 14, 2013, Nick Foster  wrote:

The solution is the USRP2 interface is no longer supported, and software which uses it must be ported to UHD. The find_usrps tool is no longer usable with modern Ettus hardware.
 
--n


On Thu, Nov 14, 2013 at 10:02 AM, nesimi eldarov  wrote:

Dear All,I will ask you very old and classical question:'RuntimeError: No USRPs found on interface eth0'I have USRP N200I run:$ sudo ifconfig eth0 192.168.10.1$ uhd_find_devices linux; GNU C++ version 4.4.1; Boost_103800; UHD_003.005.004-140-gfb32ed16 UHD Device 0--Device Address:     type: usrp2    addr: 192.168.10.2    name:     serial: F3F0D3$ sudo find_usrpsNo USRP2 found.$ sudo ftw_ofdm_tx.py --interface=eth0 --freq=2.412e9 --interp=5 --payload="some arbitrary text as MSDU ASCII payload" --regime=1 Traceback (most recent call last):  File "/usr/local/bin/ftw_ofdm_tx.py", line 171, in     main()  File "/usr/local/bin/ftw_ofdm_tx.py", line 153, in main    tb = my_top_block(options, my_msg)   File "/usr/local/bin/ftw_ofdm_tx.py", line 59, in __init__    self._setup_usrp_sink()  File "/usr/local/bin/ftw_ofdm_tx.py", line 72, in _setup_usrp_sink    self.u = usrp2.sink_32fc(self._interface, self._mac_addr)   File "/usr/lib/python2.6/dist-packages/gnuradio/usrp2.py", line 1102, in sink_32fc    return _usrp2.sink_32fc(*args, **kwargs)RuntimeError: No USRPs found on interface eth0Can you please help me to find a solution to this problem? --NE
___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 


___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] Status of GNU Radio with OSX 10.9

[Michael Dickens]

I just pushed r113379 < https://trac.macports.org/changeset/113379 > to 
MacPorts, which works for me on 10.8 and 10.9, to get full GNU Radio with GRC 
working.  For folks using OSX / MacPorts for GNU Radio and UHD, I invite you to 
try out these changes to see if they work for you; you'll want to do "sudo port 
selfupdate" to get the changes.  Enjoy! - MLD
--
Michael Dickens, Mac OS X Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com


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

Re: [Discuss-gnuradio] [User Experience] Hangout Thursday

[Martin Braun (CEL)]

On Thu, Nov 14, 2013 at 06:58:20PM +0100, Martin Braun (CEL) wrote:
> The call has started, to join please head to #gnuradio on Freenode and
> the G+ page.
> 
> We'll be streaming live on YouTube, too.

The recording is available at
http://www.youtube.com/watch?v=7LN6M-8bJuU.

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgp24y0OfokME.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] build-gnuradio debian 7.2 (wheezy) support

[Clemens Hopfer]

Hi,

build-gnuradio does not yet support debians latest stable version 7.2, 
although it builds nicely.

I attached a patch, it just adds 7.2 to the debian_version switch in line 588.

regards,
Clemens--- build-gnuradio.orig	2013-11-14 22:55:11.536081955 +0100
+++ build-gnuradio	2013-11-14 22:55:50.728275463 +0100
@@ -585,7 +585,7 @@
 		sudo apt-get -y purge 'libgnuradio*' >>$LOGDEV 2>&1
 		sudo apt-get -y purge 'python-gnuradio*' >>$LOGDEV 2>&1
 		case `cat /etc/debian_version` in
-		*6.0*|*wheezy*|*sid*|*7.1*|*7.0*)
+		*6.0*|*wheezy*|*sid*|*7.2*|*7.1*|*7.0*)
 			PKGLIST="libfontconfig1-dev libxrender-dev libpulse-dev swig g++
 			automake autoconf libtool python-dev libfftw3-dev
 			libcppunit-dev libboost-all-dev libusb-dev libusb-1.0-0-dev fort77


signature.asc
Description: This is a digitally signed message part.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] No USRPs found on interface eth0

[Nasimi Eldarov]

Yes, more than 3 years old software :)
https://www.cgran.org/wiki/ftw80211ofdmtx

Thanks!
-
NE


On Thu, Nov 14, 2013 at 7:20 PM, Marcus Leech  wrote:

> Gah!
>
> I missed the second-half where nesazeri was using find_usrps.
>
> Indeed, if you have software that uses the "classic" (pre-UHD) interface,
> that interface has been obsolete for several years and is no longer
>   supported.  The N2XX in particular, *does not* support the "classic"
> interface.
>
>
>
> on Nov 14, 2013, *Nick Foster*  wrote:
>
> The solution is the USRP2 interface is no longer supported, and software
> which uses it must be ported to UHD. The find_usrps tool is no longer
> usable with modern Ettus hardware.
>
> --n
>
>
> On Thu, Nov 14, 2013 at 10:02 AM, nesimi eldarov  wrote:
>
>> Dear All,
>>
>> I will ask you very old and classical question:
>> 'RuntimeError: No USRPs found on interface eth0'
>>
>> I have USRP N200
>>
>> I run:
>> $ sudo ifconfig eth0 192.168.10.1
>> $ uhd_find_devices
>> linux; GNU C++ version 4.4.1; Boost_103800; UHD_003.005.004-140-gfb32ed16
>>
>> --
>> -- UHD Device 0
>> --
>> Device Address:
>> type: usrp2
>> addr: 192.168.10.2
>> name:
>> serial: F3F0D3
>> $ sudo find_usrps
>> No USRP2 found.
>> $ sudo ftw_ofdm_tx.py --interface=eth0 --freq=2.412e9 --interp=5
>> --payload="some arbitrary text as MSDU ASCII payload" --regime=1
>> Traceback (most recent call last):
>>   File "/usr/local/bin/ftw_ofdm_tx.py", line 171, in 
>> main()
>>   File "/usr/local/bin/ftw_ofdm_tx.py", line 153, in main
>> tb = my_top_block(options, my_msg)
>>   File "/usr/local/bin/ftw_ofdm_tx.py", line 59, in __init__
>> self._setup_usrp_sink()
>>   File "/usr/local/bin/ftw_ofdm_tx.py", line 72, in _setup_usrp_sink
>> self.u = usrp2.sink_32fc(self._interface, self._mac_addr)
>>   File "/usr/lib/python2.6/dist-packages/gnuradio/usrp2.py", line 1102,
>> in sink_32fc
>> return _usrp2.sink_32fc(*args, **kwargs)
>> RuntimeError: No USRPs found on interface eth0
>>
>> Can you please help me to find a solution to this problem?
>>
>> --
>> NE
>>
>>
>>
>> ___
>> 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] [User Experience] Hangout Thursday

[Vanush Vaswani]

I just wanted to say, that I thought this is a great example of a FOSS
project site.

http://ardour.org/

For new users, the abilities of the project is made clear. The current
gnuradio content could be migrated to the 'Community' sub section.
One difference is that gnuradio is theoretically an API not
application software - but I still think the site serves as a good
example.


On Fri, Nov 15, 2013 at 6:11 AM, Martin Braun (CEL)
 wrote:
> On Thu, Nov 14, 2013 at 06:58:20PM +0100, Martin Braun (CEL) wrote:
>> The call has started, to join please head to #gnuradio on Freenode and
>> the G+ page.
>>
>> We'll be streaming live on YouTube, too.
>
> The recording is available at
> http://www.youtube.com/watch?v=7LN6M-8bJuU.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> 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] Introducing GNU Radio's new logo!

[Tom Rondeau]

The GNU Radio project has grown tremendously over the past couple of
years. We've gained a significant number of contributors and users and
have seen a wonderful growth of applications, both "in the lab" and
deployed in the field. The project community is maturing into a
full-fledged ecosystem: working groups, conferences, hardware vendors
advertising they work with GNU Radio, and a good number of people
building their professional careers (and livelihood) on the project.
And I'm very proud of where we are with the code as the basis for all
of this incredible activity.

Representation of ourselves and our project to groups and people
outside of our community is growing increasingly important. We are
really excited that so many people are proud to associate themselves
with GNU Radio. As part of this community growth, we are unveiling our
new logo to provide a new look and feel that represents our project as
well as the community we are a part of.

I have put the logo up as SVG files into a github repo for everyone to
access and use for your purposes. The README explains the licensing,
etc.
https://github.com/gnuradio/gr-logo.git

I will be updating the website tonight to reflect the new logo.

Best,
Tom and the GNU Radio development team

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

[Discuss-gnuradio] Cannot Get Latest GNU Radio

[Paul B. Huter]

I am trying to get the most up-to-date (3.7.x) version of GNU Radio, but my
computer keeps downloading version 3.6.x. I am running Linux Mint 14.

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

Re: [Discuss-gnuradio] Cannot Get Latest GNU Radio

[Marcus D. Leech]

I am trying to get the most up-to-date (3.7.x) version of GNU Radio, 
but my computer keeps downloading version 3.6.x. I am running Linux 
Mint 14.


Any suggestions?


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

How are you downloading it?

Mint likely only has 3.6.X in its package repositories...


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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