Re: [Discuss-gnuradio] Load original firmware in to USRPN210

2013-04-04 Thread Josh Blum


On 04/04/2013 01:48 AM, john jade wrote:
> Hi,
> 
> I modified the firmware and loaded into USRPN210.But i am not able to
> detect the device now.So,i think its the problem with the firmware that i
> loaded.
> When i use usrp_n2xx_net_burner.py to burn the original  firmware again,it
> is asking for device address.But i am not able to locate my device.
> 
> Please help me how to proceed now.
> 

see the device recovery section:
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#device-recovery-and-bricking

Hope that helps.
-josh

> 
> Thanks.
> 
> 
> 
> ___
> 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] Synchronizing 3 USRP-N200

2013-04-04 Thread Zooz Engineer
Dear Ian and All,


Although I tried what you have said, the phase is random and 
different every time I run the flow graph. I deeply suspect that 
synchronization is actually done on the boards.

I use a GPS receiver for synchronization and yesterday I noticed 
that the shape of the PPS signal is as the one in the attached image. I 
am afraid that the ripple and the overshoot can imitate the behavior of 
the PPS in much smaller period than one sec. Do you believe so? Can I 
use a usual function generator for the PPS instead of the GPS receiver? 
In other words, should the ref/pps signal be sync?

Best regards,

Zo



Subject: Re: [Discuss-gnuradio] Synchronizing 3 USRP-N200
From: i...@ionconcepts.com
Date: Wed, 3 Apr 2013 11:59:20 -0700
CC: discuss-gnuradio@gnu.org
To: xtmpcvs...@hotmail.com

Zo,Have you tried swapping cables between USRP's? both REF/PPS and signal (one 
at a time) to see if the apparent phase differences follow particular 
cables/signal paths?
On Apr 3, 2013, at 2:32 AM, Zooz Engineer  wrote:Hi 
Marcus, 

Thanks for replying. I did the following test after your comments: 

1- to rule out the scope sink problem, I used a file sink and plotted the 
output using octave: Same results observed. 
2- I took the outputs of the splitters to the oscilloscope and there are 
aligned. 

Are there other ways to test Ref/PPS other than the one I mentioned in my 
original mesage? 

Best/ 

Zo___
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] Synchronizing 3 USRP-N200

2013-04-04 Thread Ralph A. Schmid, dk5ras
First you need to ensure that the measurement of your pps signal shows the
reality, and is not some measuring error. Then you can try to calm down the
signal with some resistors, in the usual way when a rising edge
overshoots...

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Zooz
Engineer
Sent: Thursday, April 04, 2013 10:37 AM
To: Ian Buckley
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Synchronizing 3 USRP-N200

 

Dear Ian and All, 

Although I tried what you have said, the phase is random and different every
time I run the flow graph. I deeply suspect that synchronization is actually
done on the boards. 
I use a GPS receiver for synchronization and yesterday I noticed that the
shape of the PPS signal is as the one in the attached image. I am afraid
that the ripple and the overshoot can imitate the behavior of the PPS in
much smaller period than one sec. Do you believe so? Can I use a usual
function generator for the PPS instead of the GPS receiver? In other words,
should the ref/pps signal be sync? 
Best regards, 
Zo 



  _  

Subject: Re: [Discuss-gnuradio] Synchronizing 3 USRP-N200
From: i...@ionconcepts.com
Date: Wed, 3 Apr 2013 11:59:20 -0700
CC: discuss-gnuradio@gnu.org
To: xtmpcvs...@hotmail.com

Zo,

Have you tried swapping cables between USRP's? both REF/PPS and signal (one
at a time) to see if the apparent phase differences follow particular
cables/signal paths?

 

On Apr 3, 2013, at 2:32 AM, Zooz Engineer  wrote:

 

Hi Marcus, 

Thanks for replying. I did the following test after your comments: 

1- to rule out the scope sink problem, I used a file sink and plotted the
output using octave: Same results observed. 
2- I took the outputs of the splitters to the oscilloscope and there are
aligned. 

Are there other ways to test Ref/PPS other than the one I mentioned in my
original mesage? 

Best/ 

Zo

___
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] Why usrp Receiver get error packets at receiving end?

2013-04-04 Thread Arun Kumar
Hi,
I tried to send ping between two system using tunnel.py.

When I run the tunnel.py, it shows,
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] Why usrp Receiver get error packets at receiving end?

2013-04-04 Thread Arun Kumar
Hi,

I tried to send ping between two system using tunnel.py.

When I run the tunnel.py, it shows,


UUTIMEOUT
Tx: len(payload) =   90
Rx: ok = False  len(payload) =   90
UUTx: len(payload) =   54
UUTx: len(payload) =  214
URx: ok = False  len(payload) =  214
UTx: len(payload) =  319
URx: ok = False  len(payload) =  319
UTx: len(payload) =  319
Rx: ok = False  len(payload) =  319
UTx: len(payload) =  319
Rx: ok = False  len(payload) =  319
UTx: len(payload) =   78
UUTx: len(payload) =  295
Rx: ok = False  len(payload) =  295
UUTx: len(payload) =  214
URx: ok = False  len(payload) =  214
UTx: len(payload) =   90

At the receiving end the packets not received properly, I got Rx OK=false.

I changed the min_delay=0.05 to 0.1 , but same problem I got.
I am using USRP1., gr0 up and assigned IP address.

Can anyone faced like this.

Thank you,

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


[Discuss-gnuradio] communicating between 2 usrps realtime using tcp

2013-04-04 Thread Karan Talasila
Hi,
   I am new to gnuradio. I am looking at ways to communicate between 2
usrp's using tcp protocol in realtime. I used tunnel.py but it is giving a
lot of false packets even after fiddling with delay time and sleep
variables. Moreover tunnel.py is not being advised in the forum to be used.
Can anybody suggest a better program or method to communicate between usrp's

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


[Discuss-gnuradio] GRC: Is text formatting possible in the part of a Block's XML definition file?

2013-04-04 Thread Monahan-Mitchell, Tim
In GNU Radio Companion, text in the  part of a Block's XML definition file 
appears in the "Documentation" area of a Block's property window.

Can any text formatting be specific in this area using some notation?

For example, underline words, bold text, italic text... ?

I could not find  mentioned in the GRC Wiki or in examples, but blocks use 
it.

Thanks,
Tim Monahan-Mitchell


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


[Discuss-gnuradio] send_packet python file name?

2013-04-04 Thread manjusha
Hi,

I am trying to send a file from GRC.I am successful in doing that.Now,i need
to know through which python file are the packets  being sent.

I saw a send_pkt function in pkt.py but when i put some print statements in
that function,those statements don't show up when i run the file.With which
i concluded that the function send_pkt from pkt.py has not been called.

can you please help me in finding from where the packets are being sent.

Thanks.



-
Manjusha
--
View this message in context: 
http://gnuradio.4.n7.nabble.com/send-packet-python-file-name-tp40553.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] config.h in gr_logger.h

2013-04-04 Thread mleech
 

Apparently C++ apps are failing to build at the moment, due to
gr_logger.h including the (deprecated) config.h 

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


[Discuss-gnuradio] GNURadio installation on ubuntu 12.10 virtual machine in VMWARE player.

2013-04-04 Thread Sajjad Safdar
Hi,
I am installing GNURadio on a virtual maed from iso file. When i am installing 
the gnu radio by the script
wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && 
./build-gnuradio --verbose
The installation is stopped at biulding, the message is as follows
Scanning dependencies of target _blocks_swig
[ 62%] Building CXX object 
gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o
/home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx: In 
function ‘PyObject* _wrap_new_file_sink_base(PyObject*, PyObject*)’:
/home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:11257:13:
 warning: variable ‘argv’ set but not used [-Wunused-but-set-variable]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] GNURadio installation on ubuntu 12.10 virtual machine in VMWARE player.

2013-04-04 Thread mleech
 

On 04 Apr 2013 13:33, Sajjad Safdar wrote: 

> Hi, 
> I am
installing GNURadio on a virtual maed from iso file. When i am
installing the gnu radio by the script 
> 
> wget
http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio
&& ./build-gnuradio --verbose
> 
> The installation is stopped at
biulding, the message is as follows 
> Scanning dependencies of target
_blocks_swig
> [ 62%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o
>
/home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:
In function 'PyObject* _wrap_new_file_sink_base(PyObject*,
PyObject*)':
>
/home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:11257:13:
warning: variable 'argv' set but not used
[-Wunused-but-set-variable]

That's just a warning, it shouldn't cause
the build to fail. 

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


[Discuss-gnuradio] Offest Multiple Access Channel

2013-04-04 Thread Manu T S
Hi Everyone,

I need help regarding a problem.

It's a Multiple Access Channel problem but one of the source is offset by
half a symbol period.


source1 ---> bytes_to_chunks(1) > chunks_to_symbol ---

|

---> black_box --->

|
source2 ---> bytes_to_chunks(1) > chunks_to_symbol ---


I want to add these to outputs such that the the symbol corresponding to
souce2 falls between two symbols of source1.

There will be RRC waveform corresponding to every bit out of the source.
The RRC waveform corresponding to a bit in source2 should fall between RRC
waveform corresponding to 2 bits of source1 ( preferably at the midpoint ).

I guess I can not do a streams to stream converter, before RRC, because
what that would give me a channel with twice the bandwidth of a single
channel.

Should I work on a new RRC filter block with 2 inputs or is there any other
way to do this?

New ideas to achieve this is also welcome.

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


Re: [Discuss-gnuradio] Offest Multiple Access Channel

2013-04-04 Thread Nathan West
On Thu, Apr 4, 2013 at 12:45 PM, Manu T S  wrote:

> Hi Everyone,
>
> I need help regarding a problem.
>
> It's a Multiple Access Channel problem but one of the source is offset by
> half a symbol period.
>
> 
> source1 ---> bytes_to_chunks(1) > chunks_to_symbol ---
>
> |
>
> ---> black_box --->
>
> |
> source2 ---> bytes_to_chunks(1) > chunks_to_symbol ---
> 
>
> I want to add these to outputs such that the the symbol corresponding to
> souce2 falls between two symbols of source1.
>
> There will be RRC waveform corresponding to every bit out of the source.
> The RRC waveform corresponding to a bit in source2 should fall between RRC
> waveform corresponding to 2 bits of source1 ( preferably at the midpoint ).
>
> I guess I can not do a streams to stream converter, before RRC, because
> what that would give me a channel with twice the bandwidth of a single
> channel.
>
> Should I work on a new RRC filter block with 2 inputs or is there any
> other way to do this?
>
> New ideas to achieve this is also welcome.
>
> --
> Manu T S
>
> Unless I'm misunderstanding it sounds like you want to interleave bytes.
http://gnuradio.org/doc/sphinx/gr/slicedice_blk.html?highlight=interleave#gnuradio.gr.interleave
Available in GRC Stream Conversions>Interleave

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


Re: [Discuss-gnuradio] GRC: Is text formatting possible in the part of a Block's XML definition file?

2013-04-04 Thread Josh Blum


On 04/04/2013 10:58 AM, Monahan-Mitchell, Tim wrote:
> In GNU Radio Companion, text in the  part of a Block's XML definition 
> file appears in the "Documentation" area of a Block's property window.
> 
> Can any text formatting be specific in this area using some notation?
> 
> For example, underline words, bold text, italic text... ?
> 
> I could not find  mentioned in the GRC Wiki or in examples, but blocks 
> use it.

You can use \ to escape a newline, but other than that, there is no
formatting. Just text.

-josh

> 
> Thanks,
> Tim Monahan-Mitchell
> 
> 
> 
> 
> 
> ___
> 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] Offest Multiple Access Channel

2013-04-04 Thread Manu T S
Hi Nathan,

Thanks for the tip
I'm not sure if its same as interleaving.
Suppose I have W bandwidth, and I interleave bits of two sources. I guess
we only get effective W/2 bandwidth per source.



On Fri, Apr 5, 2013 at 12:05 AM, Nathan West wrote:

> On Thu, Apr 4, 2013 at 12:45 PM, Manu T S  wrote:
>
>> Hi Everyone,
>>
>> I need help regarding a problem.
>>
>> It's a Multiple Access Channel problem but one of the source is offset by
>> half a symbol period.
>>
>> 
>> source1 ---> bytes_to_chunks(1) > chunks_to_symbol ---
>>
>> |
>>
>> ---> black_box --->
>>
>> |
>> source2 ---> bytes_to_chunks(1) > chunks_to_symbol ---
>> 
>>
>> I want to add these to outputs such that the the symbol corresponding to
>> souce2 falls between two symbols of source1.
>>
>> There will be RRC waveform corresponding to every bit out of the source.
>> The RRC waveform corresponding to a bit in source2 should fall between RRC
>> waveform corresponding to 2 bits of source1 ( preferably at the midpoint ).
>>
>> I guess I can not do a streams to stream converter, before RRC, because
>> what that would give me a channel with twice the bandwidth of a single
>> channel.
>>
>> Should I work on a new RRC filter block with 2 inputs or is there any
>> other way to do this?
>>
>> New ideas to achieve this is also welcome.
>>
>> --
>> Manu T S
>>
>> Unless I'm misunderstanding it sounds like you want to interleave bytes.
>
> http://gnuradio.org/doc/sphinx/gr/slicedice_blk.html?highlight=interleave#gnuradio.gr.interleave
> Available in GRC Stream Conversions>Interleave
>
> -nw
>
>



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


Re: [Discuss-gnuradio] communicating between 2 usrps realtime using tcp

2013-04-04 Thread Josh Blum


On 04/04/2013 05:31 AM, Karan Talasila wrote:
> Hi,
>I am new to gnuradio. I am looking at ways to communicate between 2
> usrp's using tcp protocol in realtime. I used tunnel.py but it is giving a
> lot of false packets even after fiddling with delay time and sleep
> variables. Moreover tunnel.py is not being advised in the forum to be used.
> Can anybody suggest a better program or method to communicate between usrp's

Checkout https://github.com/jmalsbury/pre-cog/wiki

Somewhere there is a youtube video of this where there is a TCP block
connected to the mac layer and using netcat on either computer to make a
quick instant messenger.

-josh

> 
> 
> 
> ___
> 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] communicating between 2 usrps realtime using tcp

2013-04-04 Thread Dan CaJacob
Here's the video Josh was referencing:
http://www.youtube.com/watch?v=pF_4dFQHAZE

Very Respectfully,

Dan CaJacob

-- This email contains sensitive proprietary and confidential information.
The technical data contained herein is/may be controlled under the U.S.
International Traffic in Arms Regulations (ITAR) and may not be exported to
a Foreign Person, either in the U.S. or abroad, without the proper
authorization by the U.S. Department of State. --


On Thu, Apr 4, 2013 at 2:50 PM, Josh Blum  wrote:

>
>
> On 04/04/2013 05:31 AM, Karan Talasila wrote:
> > Hi,
> >I am new to gnuradio. I am looking at ways to communicate between 2
> > usrp's using tcp protocol in realtime. I used tunnel.py but it is giving
> a
> > lot of false packets even after fiddling with delay time and sleep
> > variables. Moreover tunnel.py is not being advised in the forum to be
> used.
> > Can anybody suggest a better program or method to communicate between
> usrp's
>
> Checkout https://github.com/jmalsbury/pre-cog/wiki
>
> Somewhere there is a youtube video of this where there is a TCP block
> connected to the mac layer and using netcat on either computer to make a
> quick instant messenger.
>
> -josh
>
> >
> >
> >
> > ___
> > 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] Offest Multiple Access Channel

2013-04-04 Thread Manu T S
Sorry to bother the forum.

I have made a .grc(attached) which gives me the same result.

Of course, I have to design a receiver for this MAC, and I'm stumbling in
dark.


On Fri, Apr 5, 2013 at 12:19 AM, Manu T S  wrote:

> Hi Nathan,
>
> Thanks for the tip
> I'm not sure if its same as interleaving.
> Suppose I have W bandwidth, and I interleave bits of two sources. I guess
> we only get effective W/2 bandwidth per source.
>
>
>
> On Fri, Apr 5, 2013 at 12:05 AM, Nathan West wrote:
>
>> On Thu, Apr 4, 2013 at 12:45 PM, Manu T S  wrote:
>>
>>> Hi Everyone,
>>>
>>> I need help regarding a problem.
>>>
>>> It's a Multiple Access Channel problem but one of the source is offset
>>> by half a symbol period.
>>>
>>> 
>>> source1 ---> bytes_to_chunks(1) > chunks_to_symbol ---
>>>
>>> |
>>>
>>> ---> black_box --->
>>>
>>> |
>>> source2 ---> bytes_to_chunks(1) > chunks_to_symbol ---
>>> 
>>>
>>> I want to add these to outputs such that the the symbol corresponding to
>>> souce2 falls between two symbols of source1.
>>>
>>> There will be RRC waveform corresponding to every bit out of the source.
>>> The RRC waveform corresponding to a bit in source2 should fall between RRC
>>> waveform corresponding to 2 bits of source1 ( preferably at the midpoint ).
>>>
>>> I guess I can not do a streams to stream converter, before RRC, because
>>> what that would give me a channel with twice the bandwidth of a single
>>> channel.
>>>
>>> Should I work on a new RRC filter block with 2 inputs or is there any
>>> other way to do this?
>>>
>>> New ideas to achieve this is also welcome.
>>>
>>> --
>>> Manu T S
>>>
>>> Unless I'm misunderstanding it sounds like you want to interleave bytes.
>>
>> http://gnuradio.org/doc/sphinx/gr/slicedice_blk.html?highlight=interleave#gnuradio.gr.interleave
>> Available in GRC Stream Conversions>Interleave
>>
>> -nw
>>
>>
>
>
>
> --
> Manu T S
>



-- 
Manu T S


offset_mac.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] send_packet python file name?

2013-04-04 Thread manjusha
The file is under /grc-gnuradio/blks2/packet.py



-
Manjusha
--
View this message in context: 
http://gnuradio.4.n7.nabble.com/send-packet-python-file-name-tp40553p40564.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


Re: [Discuss-gnuradio] config.h in gr_logger.h

2013-04-04 Thread Tom Rondeau
On Thu, Apr 4, 2013 at 1:27 PM,   wrote:
> Apparently C++ apps are failing to build at the moment, due to gr_logger.h
> including the (deprecated) config.h

Thanks for the note. Stupid mistake in gr_logger.h. I've pushed what
should be a fix for this.

Tom

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


Re: [Discuss-gnuradio] GNURadio installation on ubuntu 12.10 virtual machine in VMWARE player.

2013-04-04 Thread Tom Rondeau
On Thu, Apr 4, 2013 at 1:41 PM,   wrote:
> On 04 Apr 2013 13:33, Sajjad Safdar wrote:
>
> Hi,
> I am installing GNURadio on a virtual maed from iso file. When i am
> installing the gnu radio by the script
>
> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio
> && ./build-gnuradio --verbose
>
> The installation is stopped at biulding, the message is as follows
> Scanning dependencies of target _blocks_swig
> [ 62%] Building CXX object
> gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o
> /home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:
> In function ‘PyObject* _wrap_new_file_sink_base(PyObject*, PyObject*)’:
> /home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:11257:13:
> warning: variable ‘argv’ set but not used [-Wunused-but-set-variable]
>
> That's just a warning, it shouldn't cause the build to fail.


Yeah, as Marcus said, that's just a warning. Just let it continue to
run, it's building the huge swig file for gr-blocks at that stage.

Tom

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


Re: [Discuss-gnuradio] grc sorting block categories

2013-04-04 Thread Tom Rondeau
On Wed, Apr 3, 2013 at 7:54 PM, Gregory Warnes  wrote:
> Hi,
>
> I've been using GnuRadio Companion for some prototyping over the last
> couple of weeks and am finding it very helpful.
>
> Below is a (tiny) patch to enable sorting the block tree clicking on
> the column heading ('Blocks'):
>
>
> diff --git a/grc/gui/BlockTreeWindow.py b/grc/gui/BlockTreeWindow.py
> index 62afb62..2b37966 100644
> --- a/grc/gui/BlockTreeWindow.py
> +++ b/grc/gui/BlockTreeWindow.py
> @@ -70,6 +70,8 @@ class BlockTreeWindow(gtk.VBox):
>   #try to enable the tooltips (available in pygtk 2.12 and above)
>   try: self.treeview.set_tooltip_column(DOC_INDEX)
>   except: pass
> + #setup sort order
> + column.set_sort_column_id(0)
>   #setup drag and drop
>   self.treeview.enable_model_drag_source(gtk.gdk.BUTTON1_MASK,
> DND_TARGETS, gtk.gdk.ACTION_COPY)
>   self.treeview.connect('drag-data-get', self._handle_drag_get_data)
>
> I hope this is helpful.
>
> -Greg


Greg,

Very nice, thanks! I was just working on reorganizing the GRC
categories yesterday and thought how useful this would be. It's been
pushed in the latest updates on master/next.

Tom

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


[Discuss-gnuradio] GNU Radio, ControlPort, and ICE and GCC versions

2013-04-04 Thread Tom Rondeau
Just a quick note about some software version info.

GCC 4.7 and ICE 3.4.2 don't play well together. If using GNU Radio on
a machine with GCC 4.7 and you want to use ControlPort, you have two
options:

- Downgrade to GCC 4.6 (this is by far the easiest), or

- Upgrade to ICE 3.5.0.

I have verified that ICE 3.50 and GCC 4.7 build GNU Radio and
ContolPort fine. But I had to do a bit of work to get GNU Radio to
handle 3.5 properly because we are expressly looking for 3.4. Also,
when I built 3.5.0 from scratch, there was no PC file. I was able to
copy the PC file from 3.4.2 and just update it accordingly and
everything worked fine from there.

Tom

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


[Discuss-gnuradio] Updated GRC categories - prep for v3.7

2013-04-04 Thread Tom Rondeau
The next stage of preparing for GR v3.7 is work to make the GRC
component structure more sane. By duplicating blocks, we also made it
more difficult to use the GRC category tree because of duplication
there, too.

But now that we're satisfied that the blocks are working and that we
have transitioned most  of the GRC components out of gnuradio-core,
we've restructure the components.

* We removed all of the old blocks from the GRC component tree.

* This does _not_ remove the blocks from GRC, so this does not affect
GRC apps already created.

* The change affects how we find blocks, and the blocks in the
category tree are now (almost) all from 3.7.

* We have changed the category names and reorged all of the blocks, so
it might take a little bit of getting used to. But we feel the new
categorization is more intuitive.
  ** The next section shows the new category names used.

* When using the component tree, almost all the blocks listed there
are the new blocks for 3.7.

* When opening your GRC files now, if you are using a block that is
from 3.6, the name will be: "Block name (old)".
  ** This is to make it clear that you are using a pre-3.7 block.

* The (old) name is to help identify where you can update to a new 3.7
block in your flowgraph.
  ** This will help prepare you for the conversion to v3.7

* The search box will return all blocks found, including the (old)
blocks, so you can still get access to these, if you really want.


Note. Not all GRC blocks were converted this way on master. A lot of
the hierarchical blocks that had a GRC component were not necessarily
moved over to the new components on the master branch. So you might
still find a few problems when opening up old GRC files in 3.7.

To see the list of blocks that are still being pulled in the old way,
you can look at grc/blocks/block_tree.xml in the source code, or it is
installed into ${prefix}/share/gnuradio/blocks/block_tree.xml.

This should really help with transitioning your work to 3.7 when you
need to and in the meantime will not affect your current, running
systems in anyway but looks.


Tom

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


[Discuss-gnuradio] 3.7 Transition material

2013-04-04 Thread Tom Rondeau
I've started collecting the various pieces of information/advice for
helping the transition between 3.6 and 3.7 here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7

Tom

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


Re: [Discuss-gnuradio] GNURadio installation on ubuntu 12.10 virtual machine in VMWARE player.

2013-04-04 Thread Sid Boyce

On 04/04/13 18:33, Sajjad Safdar wrote:

Hi,
I am installing GNURadio on a virtual maed from iso file. When i am 
installing the gnu radio by the script

wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && 
./build-gnuradio --verbose
The installation is stopped at biulding, the message is as follows
Scanning dependencies of target _blocks_swig
[ 62%] Building CXX object 
gr-blocks/swig/CMakeFiles/_blocks_swig.dir/blocks_swigPYTHON_wrap.cxx.o
/home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx: 
In function âEUR~PyObject* _wrap_new_file_sink_base(PyObject*, 
PyObject*)âEUR^(TM):
/home/fh/gnuradio/gnuradio/build/gr-blocks/swig/blocks_swigPYTHON_wrap.cxx:11257:13: 
warning: variable âEUR~argvâEUR^(TM) set but not used 
[-Wunused-but-set-variable]



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Just leave it running, go and do something else for quite a while ... it 
stays at that stage and a few others for ages.

73 ... Sid.

--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

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


Re: [Discuss-gnuradio] Need help with control port client

2013-04-04 Thread Alexandru Csete
On Thu, Apr 4, 2013 at 1:52 AM, Alexandru Csete  wrote:
> Greetings,
>
> I'm trying to write a control port client in C++ but I got stuck and
> need some help.
>
> My problem is that the control port interface gives us a map
> containing GNURadio::KnobPtr but to get access to the value I need a
> typed pointer, e.g. GNURadio::KnobDPtr, which is derived from KnobPtr.
> I tried a static_cast as illustrated in this snippet:
> http://pastebin.com/NqWyqSeu - but gcc throws it right back at me with
> an error:
>
> In file included from /usr/include/Ice/LocalObjectF.h:15:0,
>  from /usr/include/Ice/CommunicatorF.h:24,
>  from /usr/include/Ice/Initialize.h:13,
>  from /usr/include/Ice/Ice.h:13,
>  from strx-mon.cpp:1:
> /usr/include/Ice/Handle.h: In constructor
> ‘IceInternal::Handle::Handle(const IceInternal::Handle&) [with Y
> = GNURadio::Knob, T = GNURadio::KnobD]’:
> strx-mon.cpp:28:72:   instantiated from here
> /usr/include/Ice/Handle.h:73:9: error: invalid conversion from
> ‘GNURadio::Knob*’ to ‘GNURadio::KnobD*’ [-fpermissive]
>

Sorry for the noise. I realized that adding -fpermissive to gcc will
make it compile and run as expected. I guess I can now look forward to
being publicly crucified at the next C++ convention... On the other
hand the Python does the same thing behind the scenes so I will not
loose any sleep over this.

Alex

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


Re: [Discuss-gnuradio] Need help with control port client

2013-04-04 Thread Tom Rondeau
On Thu, Apr 4, 2013 at 6:37 PM, Alexandru Csete  wrote:
> On Thu, Apr 4, 2013 at 1:52 AM, Alexandru Csete  wrote:
>> Greetings,
>>
>> I'm trying to write a control port client in C++ but I got stuck and
>> need some help.
>>
>> My problem is that the control port interface gives us a map
>> containing GNURadio::KnobPtr but to get access to the value I need a
>> typed pointer, e.g. GNURadio::KnobDPtr, which is derived from KnobPtr.
>> I tried a static_cast as illustrated in this snippet:
>> http://pastebin.com/NqWyqSeu - but gcc throws it right back at me with
>> an error:
>>
>> In file included from /usr/include/Ice/LocalObjectF.h:15:0,
>>  from /usr/include/Ice/CommunicatorF.h:24,
>>  from /usr/include/Ice/Initialize.h:13,
>>  from /usr/include/Ice/Ice.h:13,
>>  from strx-mon.cpp:1:
>> /usr/include/Ice/Handle.h: In constructor
>> ‘IceInternal::Handle::Handle(const IceInternal::Handle&) [with Y
>> = GNURadio::Knob, T = GNURadio::KnobD]’:
>> strx-mon.cpp:28:72:   instantiated from here
>> /usr/include/Ice/Handle.h:73:9: error: invalid conversion from
>> ‘GNURadio::Knob*’ to ‘GNURadio::KnobD*’ [-fpermissive]
>>
>
> Sorry for the noise. I realized that adding -fpermissive to gcc will
> make it compile and run as expected. I guess I can now look forward to
> being publicly crucified at the next C++ convention... On the other
> hand the Python does the same thing behind the scenes so I will not
> loose any sleep over this.
>
> Alex

Alex,

That's nice to know. I was waiting until I had more time to help you
out with this, but no need.

It'll be good to have some C++ apps using ControlPort out there for us
to look at :)

Tom

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


[Discuss-gnuradio] Error in Interpolating FIR filter

2013-04-04 Thread Manu T S
Executing the attached flow graph I get the following error.

#
>>> gr_fir_ccc: using SSE
Traceback (most recent call last):
  File "/home/manu/coding/top_block.py", line 72, in 
tb.Run(True)
  File
"/usr/local/lib/python2.7/dist-packages/grc_gnuradio/wxgui/top_block_gui.py",
line 76, in Run
self.start()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
line 97, in start
self._tb.start(max_noutput_items)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
line 3077, in start
return _gnuradio_core_runtime.gr_top_block_sptr_start(self,
max_noutput_items)
RuntimeError: gr_buffer_add_reader: nzero_preload must be >= 0
###

What could be the possible reason?

I have installed using build-gnuradio script on day before yesterday.



-- 
Manu T S
<>

resampler_test.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio