Re: [Discuss-gnuradio] Consuming block of data in python block

[Martin Braun (CEL)]

On Tue, Jan 29, 2013 at 02:00:15PM +0800, Sreeraj Rajendran wrote:
> As Josh explained in [1] input can be anything that you can represent as a
> numpy data type.
> 
> 
> Try using something like
> 
> gr.block.__init__(self, name="my block",
> 
>   in_sig=[numpy.dtype((numpy.float32,2))],
> 
>   out_sig=[numpy.float32])
> 
> 
> 
> Also go through fixed/arbitrary ratio blocks in [2] for implementing blocks
> with different rate.

$ gr_modtool -t decimator -l python BLOCKNAME

will take you there.

M

-- 
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


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

Re: [Discuss-gnuradio] Non-deterministic behavior

[Vanessa Gardellin]

Yes, we are using a throttle but when we execute the same python file
we obtain always different outcomes.
We would like to have repeatable experiments.
Any tips?

Thank you
Vanessa

On Mon, Jan 28, 2013 at 5:46 PM, Mike Jameson  wrote:
> Hi,
>
> Make sure you are using a 'throttle' block. Have a look at the following:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations
>
>
> Mike
> M0MIK
>
> On 28 January 2013 16:40, Vanessa Gardellin 
> wrote:
>>
>> Dear all,
>> we are experiencing an undesired random behavior when we run an
>> offline OFDM flow graph.
>> Specifically, we store a transmitted sequence of packets in a *.dat
>> file (file_sink) and then we run the receiver chain using always the
>> same file as source (file_source).
>>
>> Repeating several times the same run using the same source file, we
>> get a varying number of received right/wrong packets.
>>
>> Is there an explanation to this behavior?
>> How can we generate a repeatable experiment?
>>
>>
>> Regards,
>> Vanessa
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>



-- 
Vanessa GARDELLIN, Ph.D.
Researcher
Institute for Informatics and Telematics (IIT),
Italian National Research Council (CNR)
Via G. Moruzzi 1
56124 Pisa - ITALY
Phone: +390503158297
Room: B65/c
E-mail: vanessa.gardel...@iit.cnr.it
WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
Skype: gardellin.vanessa

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

Re: [Discuss-gnuradio] frequency drift of WBX

[Mike Jameson]

Hi,

The WBX frequency stability is determined by the accuracy of the USRP clock
signal.  For example, the USRP2 has a 100MHz internal clock which can be
locked to a 10MHz external source such as GPSDO for better frequency
stability.

See the following url for more info:

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

GSM base stations have very accurate GPS disciplined clocks in them and
'Kalibrate' allows you to measure your device's frequency stability by
using a mobile base station as a reference. Link below:

http://ttsou.github.com/kalibrate-uhd/

Cheers,

Mike
M0MIK


On 29 January 2013 02:45, Gong Zhang  wrote:

> Hi,
>I wanna know the frequency drift of WBX daughterboard.I think it may
> depend on the stability of WBX oscillator.How can I calculate it?
> Thank you.
>
> __**_
> 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] Non-deterministic behavior

[Mike Jameson]

Hi Vanessa,

If you are using a random number generator, remember to save and re-use the
same 'seed' and also to reset it to the beginning of each run.

Mike
M0MIK

On 29 January 2013 09:47, Vanessa Gardellin wrote:

> Yes, we are using a throttle but when we execute the same python file
> we obtain always different outcomes.
> We would like to have repeatable experiments.
> Any tips?
>
> Thank you
> Vanessa
>
> On Mon, Jan 28, 2013 at 5:46 PM, Mike Jameson  wrote:
> > Hi,
> >
> > Make sure you are using a 'throttle' block. Have a look at the following:
> >
> > http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations
> >
> >
> > Mike
> > M0MIK
> >
> > On 28 January 2013 16:40, Vanessa Gardellin <
> vanessa.gardel...@iit.cnr.it>
> > wrote:
> >>
> >> Dear all,
> >> we are experiencing an undesired random behavior when we run an
> >> offline OFDM flow graph.
> >> Specifically, we store a transmitted sequence of packets in a *.dat
> >> file (file_sink) and then we run the receiver chain using always the
> >> same file as source (file_source).
> >>
> >> Repeating several times the same run using the same source file, we
> >> get a varying number of received right/wrong packets.
> >>
> >> Is there an explanation to this behavior?
> >> How can we generate a repeatable experiment?
> >>
> >>
> >> Regards,
> >> Vanessa
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
>
>
>
> --
> Vanessa GARDELLIN, Ph.D.
> Researcher
> Institute for Informatics and Telematics (IIT),
> Italian National Research Council (CNR)
> Via G. Moruzzi 1
> 56124 Pisa - ITALY
> Phone: +390503158297
> Room: B65/c
> E-mail: vanessa.gardel...@iit.cnr.it
> WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
> Skype: gardellin.vanessa
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to get the carrier's frequency offset in PM demodulator?

[adream]

Hello,
I am learning PM Demodulation, and someones tell me that the FM Demodulator
in gnuradio can demodulate the PM signals.
I want to get the carrier's frequency offset in PM demodulating, does
gnuradio provide this function?
For example, in my project, I set the frequency of IF signal is 70MHz, but
the real input IF signal is 70.01MHz.
In this case, I hope my program can print the carrier's frequency offset,
10KHz
Thank you.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem loading Python block

[Nemanja Savic]

Guys,

i am not able to load gr.basic_block and make signal processing block in
Python. Simplu, there is no binding within gnuradio/gr for that class.
It works perfectly for gr.hier)block2 class.
What might be the problem?

Thanks


On Tue, Jan 29, 2013 at 12:57 PM, Nemanja Savic  wrote:

> Hi Martin,
>
> here is the error I got when trying to use new version of gr_modtool:
>
> [savi_ne@ts-070046nl Desktop]$ gr_modtool.py help
>
> Using Python < 2.7 possibly buggy. Ahem. Please send all complaints to
> /dev/null.
> Traceback (most recent call last):
>   File "/usr/local/bin/gr_modtool.py", line 2665, in 
> main()
>   File "/usr/local/bin/gr_modtool.py", line 2656, in main
> modtool = cmd_dict[command]()
>   File "/usr/local/bin/gr_modtool.py", line 2629, in __init__
> ModTool.__init__(self)
>   File "/usr/local/bin/gr_modtool.py", line 282, in __init__
> self.parser = self.setup_parser()
>   File "/usr/local/bin/gr_modtool.py", line 290, in setup_parser
> parser = OptionParser(usage=Templates['usage'], add_help_option=False)
> NameError: global name 'Templates' is not defined
>
>
>
> On Mon, Jan 28, 2013 at 10:14 PM, Nemanja Savic wrote:
>
>> Hi all,
>>
>> In my first post from today, where I reported error in gr_modtool, I was
>> using script downloaded from github this morning (just to clarifu how old
>> scriot I used).
>> Basically I am trying to make my own packet deframer block, and they are
>> more or less designed like that. This block was designed just to see how
>> messages work. In GRC when I connect them in that way it works, but in test
>> script above it doesn't work.
>> Basically the problem comes from making similar block like packet
>> deframer, but I am not able to import gr.block, or gr.basic_block in python
>> (and gr.hier_block2 works perfectly)
>>
>> Cheers
>>
>>
>> On Mon, Jan 28, 2013 at 5:05 PM, Martin Braun (CEL) > > wrote:
>>
>>> - Try the latest gr_modtool from github
>>> - What you're doing seems weird--why are you connecting message blocks?
>>>   These are meant as a hackish solution to access samples from outside
>>>   the flow graph. Perhaps you want the new PDU to stream blocks?
>>>
>>> MB
>>>
>>> On Mon, Jan 28, 2013 at 04:42:04PM +0100, Nemanja Savic wrote:
>>> > Since I don't know why gr_modtool doesn't work for me, I took the
>>> older working
>>> > version and made very simple hier block in order to understand
>>> messages flow in
>>> > gnuradio.
>>> >
>>> > The block code is following:
>>> >
>>> >
>>> > from gnuradio import gr
>>> >
>>> > class msg_proba(gr.hier_block2):
>>> > def __init__(self, ):
>>> > gr.hier_block2.__init__(self, "msg_proba",
>>> > gr.io_signature(1, 1, gr.sizeof_char),  # Input
>>> signature
>>> > gr.io_signature(1, 1, gr.sizeof_char)) # Output
>>> signature
>>> >
>>> > gr_message_sink_0_msgq_out = gr_message_source_0_msgq_in =
>>> > gr.msg_queue(4)
>>> >
>>> > self.gr_message_source_0 =
>>> gr.message_source(gr.sizeof_char*1,
>>> > gr_message_source_0_msgq_in)
>>> > self.gr_message_sink_0 = gr.message_sink(gr.sizeof_char*1,
>>> > gr_message_sink_0_msgq_out, False)
>>> >
>>> > self.connect(self, self.gr_message_sink_0)
>>> > self.connect(self.gr_message_source_0, self)
>>> >
>>> >
>>> >
>>> > and the test code is following:
>>> >
>>> >
>>> >
>>> > from gnuradio import gr, gr_unittest
>>> > import test
>>> > import msg_proba
>>> >
>>> > class qa_msg_proba (gr_unittest.TestCase):
>>> >
>>> > def setUp (self):
>>> > self.tb = gr.top_block ()
>>> >
>>> > def tearDown (self):
>>> > self.tb = None
>>> >
>>> > def test_001_msg_proba (self):
>>> >
>>> > self.src_data = ()
>>> > self.expected_result = ()
>>> >
>>> > for i in range(51):
>>> >   self.src_data = self.src_data + (1,)
>>> >   self.expected_result = self.expected_result+(1,)
>>> >
>>> > self.src = gr.vector_source_b(self.src_data, False, 1)
>>> > self.dst = gr.vector_sink_b ()
>>> >
>>> > self.msg_pr = msg_proba.msg_proba()
>>> >
>>> > self.tb.connect(self.src, self.msg_pr, self.dst)
>>> >
>>> > self.tb.run ()
>>> > # check data
>>> > result_data = dst.data ()
>>> > self.assertEqual (expected_result, result_data)
>>> >
>>> > if __name__ == '__main__':
>>> > gr_unittest.main ()
>>> >
>>> >
>>> > When I run test, it doesn't finish. No errors, just stays active
>>> without giving
>>> > any results.
>>> >
>>> > Can somebody provide some explanation?
>>> >
>>> >
>>> >
>>> >
>>> > On Mon, Jan 28, 2013 at 10:28 AM, Nemanja Savic 
>>> wrote:
>>> >
>>> >
>>> > I installed new version of gr_modtool script and it won't work.
>>> The error
>>> > is following:
>>> >
>>> > [savi_ne@ts-070046nl gr-test]$ gr_modtoo

[Discuss-gnuradio] Synchronize multiple USRP-N210s

[Gong Zhang]

Hi,
I wanna synchronize two USRPs to sample signal at the time.And the
synchronization accuracy should be of microseconds without external
clock and cable.This leads me to design a synchronization protocol but
not on PC because of the jitter of ethernet.It seems openBTS add a
timestamp block in FPGA.Can anybody give me some detail or other
suggestions.
Thanks.

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

Re: [Discuss-gnuradio] help about making .dat file for file source

[Tom Rondeau]

On Tue, Jan 29, 2013 at 6:14 AM, Mohammed Ramadan
wrote:

> i want to make .dat file to use it in file source in GNU-Radio Program .
> like attached one which i downloaded for making AM-Modulattion, i just want
> to make simple .dat file for making guassian signal or any DSP signal. so
> kindly any one can help me
>

Can't you just use a gr_noise_source_c -> gr_file_sink?

See this for information about the file format:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink

Also, please don't post files that large to the mailing list.

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

Re: [Discuss-gnuradio] Problem loading Python block

[Tom Rondeau]

On Tue, Jan 29, 2013 at 7:00 AM, Nemanja Savic  wrote:

> Guys,
>
> i am not able to load gr.basic_block and make signal processing block in
> Python. Simplu, there is no binding within gnuradio/gr for that class.
> It works perfectly for gr.hier)block2 class.
> What might be the problem?
>
> Thanks
>

I'm not sure what you mean by "load gr.basic_block." Do you mean inherit
from?

For signal processing endpoints, you want to use either gr_block,
gr_sync_block, gr_sync_decimator or gr_sync_interpolator.

Tom




> On Tue, Jan 29, 2013 at 12:57 PM, Nemanja Savic wrote:
>
>> Hi Martin,
>>
>> here is the error I got when trying to use new version of gr_modtool:
>>
>> [savi_ne@ts-070046nl Desktop]$ gr_modtool.py help
>>
>> Using Python < 2.7 possibly buggy. Ahem. Please send all complaints to
>> /dev/null.
>> Traceback (most recent call last):
>>   File "/usr/local/bin/gr_modtool.py", line 2665, in 
>> main()
>>   File "/usr/local/bin/gr_modtool.py", line 2656, in main
>> modtool = cmd_dict[command]()
>>   File "/usr/local/bin/gr_modtool.py", line 2629, in __init__
>> ModTool.__init__(self)
>>   File "/usr/local/bin/gr_modtool.py", line 282, in __init__
>> self.parser = self.setup_parser()
>>   File "/usr/local/bin/gr_modtool.py", line 290, in setup_parser
>> parser = OptionParser(usage=Templates['usage'], add_help_option=False)
>> NameError: global name 'Templates' is not defined
>>
>>
>>
>>  On Mon, Jan 28, 2013 at 10:14 PM, Nemanja Savic wrote:
>>
>>> Hi all,
>>>
>>> In my first post from today, where I reported error in gr_modtool, I was
>>> using script downloaded from github this morning (just to clarifu how old
>>> scriot I used).
>>> Basically I am trying to make my own packet deframer block, and they are
>>> more or less designed like that. This block was designed just to see how
>>> messages work. In GRC when I connect them in that way it works, but in test
>>> script above it doesn't work.
>>> Basically the problem comes from making similar block like packet
>>> deframer, but I am not able to import gr.block, or gr.basic_block in python
>>> (and gr.hier_block2 works perfectly)
>>>
>>> Cheers
>>>
>>>
>>> On Mon, Jan 28, 2013 at 5:05 PM, Martin Braun (CEL) <
>>> martin.br...@kit.edu> wrote:
>>>
 - Try the latest gr_modtool from github
 - What you're doing seems weird--why are you connecting message blocks?
   These are meant as a hackish solution to access samples from outside
   the flow graph. Perhaps you want the new PDU to stream blocks?

 MB

 On Mon, Jan 28, 2013 at 04:42:04PM +0100, Nemanja Savic wrote:
 > Since I don't know why gr_modtool doesn't work for me, I took the
 older working
 > version and made very simple hier block in order to understand
 messages flow in
 > gnuradio.
 >
 > The block code is following:
 >
 >
 > from gnuradio import gr
 >
 > class msg_proba(gr.hier_block2):
 > def __init__(self, ):
 > gr.hier_block2.__init__(self, "msg_proba",
 > gr.io_signature(1, 1, gr.sizeof_char),  # Input
 signature
 > gr.io_signature(1, 1, gr.sizeof_char)) # Output
 signature
 >
 > gr_message_sink_0_msgq_out = gr_message_source_0_msgq_in =
 > gr.msg_queue(4)
 >
 > self.gr_message_source_0 =
 gr.message_source(gr.sizeof_char*1,
 > gr_message_source_0_msgq_in)
 > self.gr_message_sink_0 = gr.message_sink(gr.sizeof_char*1,
 > gr_message_sink_0_msgq_out, False)
 >
 > self.connect(self, self.gr_message_sink_0)
 > self.connect(self.gr_message_source_0, self)
 >
 >
 >
 > and the test code is following:
 >
 >
 >
 > from gnuradio import gr, gr_unittest
 > import test
 > import msg_proba
 >
 > class qa_msg_proba (gr_unittest.TestCase):
 >
 > def setUp (self):
 > self.tb = gr.top_block ()
 >
 > def tearDown (self):
 > self.tb = None
 >
 > def test_001_msg_proba (self):
 >
 > self.src_data = ()
 > self.expected_result = ()
 >
 > for i in range(51):
 >   self.src_data = self.src_data + (1,)
 >   self.expected_result = self.expected_result+(1,)
 >
 > self.src = gr.vector_source_b(self.src_data, False, 1)
 > self.dst = gr.vector_sink_b ()
 >
 > self.msg_pr = msg_proba.msg_proba()
 >
 > self.tb.connect(self.src, self.msg_pr, self.dst)
 >
 > self.tb.run ()
 > # check data
 > result_data = dst.data ()
 > self.assertEqual (expected_result, result_data)
 >
 > if __name__ == '__main__':
 > gr_unittest.main ()
 >
>

Re: [Discuss-gnuradio] Non-deterministic behavior

[Vanessa Gardellin]

We do not have any random generator in the code that we wrote.
We generate 100 packets always of the same size and containing all "a".

Could it be something that depends on the scheduler or on how threads
are handled?

On Tue, Jan 29, 2013 at 12:09 PM, Mike Jameson  wrote:
> Hi Vanessa,
>
> If you are using a random number generator, remember to save and re-use the
> same 'seed' and also to reset it to the beginning of each run.
>
> Mike
> M0MIK
>
>
> On 29 January 2013 09:47, Vanessa Gardellin 
> wrote:
>>
>> Yes, we are using a throttle but when we execute the same python file
>> we obtain always different outcomes.
>> We would like to have repeatable experiments.
>> Any tips?
>>
>> Thank you
>> Vanessa
>>
>> On Mon, Jan 28, 2013 at 5:46 PM, Mike Jameson  wrote:
>> > Hi,
>> >
>> > Make sure you are using a 'throttle' block. Have a look at the
>> > following:
>> >
>> > http://gnuradio.org/redmine/projects/gnuradio/wiki/Simulations
>> >
>> >
>> > Mike
>> > M0MIK
>> >
>> > On 28 January 2013 16:40, Vanessa Gardellin
>> > 
>> > wrote:
>> >>
>> >> Dear all,
>> >> we are experiencing an undesired random behavior when we run an
>> >> offline OFDM flow graph.
>> >> Specifically, we store a transmitted sequence of packets in a *.dat
>> >> file (file_sink) and then we run the receiver chain using always the
>> >> same file as source (file_source).
>> >>
>> >> Repeating several times the same run using the same source file, we
>> >> get a varying number of received right/wrong packets.
>> >>
>> >> Is there an explanation to this behavior?
>> >> How can we generate a repeatable experiment?
>> >>
>> >>
>> >> Regards,
>> >> Vanessa
>> >>
>> >> ___
>> >> Discuss-gnuradio mailing list
>> >> Discuss-gnuradio@gnu.org
>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>>
>>
>>
>> --
>> Vanessa GARDELLIN, Ph.D.
>> Researcher
>> Institute for Informatics and Telematics (IIT),
>> Italian National Research Council (CNR)
>> Via G. Moruzzi 1
>> 56124 Pisa - ITALY
>> Phone: +390503158297
>> Room: B65/c
>> E-mail: vanessa.gardel...@iit.cnr.it
>> WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
>> Skype: gardellin.vanessa
>
>



-- 
Vanessa GARDELLIN, Ph.D.
Researcher
Institute for Informatics and Telematics (IIT),
Italian National Research Council (CNR)
Via G. Moruzzi 1
56124 Pisa - ITALY
Phone: +390503158297
Room: B65/c
E-mail: vanessa.gardel...@iit.cnr.it
WWW: http://www.iit.cnr.it/staff/vanessa.gardellin/
Skype: gardellin.vanessa

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

Re: [Discuss-gnuradio] help about making .dat file for file source

[Nemanja Savic]

Just calculate samples in whatever way you want and store them to files,
using python, C, or any other language.
Here is part of my code for making samples of complex sin wave in python:

for i in range(n_samples):
> sine[i] = math.sin(2*math.pi*i/n_samples)
> cosine[i] = math.cos(2*math.pi*i/n_samples)
> pom = sine[i]*sine[i] + cosine[i] * cosine[i]
> f.write(struct.pack('ff', sine[i], cosine[i]))
> f.close()
>


On Tue, Jan 29, 2013 at 12:14 PM, Mohammed Ramadan  wrote:

> i want to make .dat file to use it in file source in GNU-Radio Program .
> like attached one which i downloaded for making AM-Modulattion, i just want
> to make simple .dat file for making guassian signal or any DSP signal. so
> kindly any one can help me
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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

Re: [Discuss-gnuradio] Problem loading Python block

[Tom Rondeau]

On Tue, Jan 29, 2013 at 7:40 AM, Nemanja Savic  wrote:

> I'm not sure what you mean by "load gr.basic_block." Do you mean inherit
>> from?
>
>
> I want to make my block which very similar to packet deframer. Here is th
> code:
>
> class packet_tst(gr.hier_block2):
>> def __init__(self, access_code=None, threshold=-1):
>>
>> gr.hier_block2.__init__(
>> self,
>> "packet_tst",
>> gr.io_signature(1, 1, 1),  # Input signature
>> gr.io_signature(0, 0, 0) # Output signature
>> )
>>
>> if not access_code:
>> access_code = packet_utils.default_access_code
>> if not packet_utils.is_1_0_string(access_code):
>> raise ValueError, "Invalid access_code %r. Must be string of
>> 1's and 0's" % (access_code,)
>>
>> if threshold == -1:
>> threshold = 12  # FIXME raise exception
>>
>> msgq = gr.msg_queue(4)  # holds packets from the PHY
>> self.correlator =
>> gr_digital.correlate_access_code_bb(access_code, threshold)
>>
>> self.framer_sink = gr.framer_sink_1(msgq)
>> self.connect(self, self.correlator, self.framer_sink)
>>
>> self.hlp_blk = helper_block(msgq)
>>
>
> in the same file is also defined class helper_block in this way:
>
> class helper_block(gr.basic_block):
>> def __init__(self, msgq):
>> gr.basic_block.__init__(
>> self, name = "helper_block",
>> in_sig = None, out_sig = None
>> #num_msg_outputs = 1
>> )
>>
>> self._msgq = msgq
>>
>> def work(self, input_items, output_items):
>> while True:
>> try: msg = self._msgq.delete_head()
>> except: return -1
>> print "Message received"
>
>
I have no idea what files these are from. Are they part of the GNU Radio
source code? I can't find references to them.



> when I try to run test or flowgraph, I get this error:
>
>  in 
>> class helper_block(gr.basic_block):
>>
>> AttributeError: 'module' object has no attribute 'basic_block'
>> -- Process completed
>> ***Failed
>>
>> 0% tests passed, 1 tests failed out of 1
>
>
Sounds like you don't have something installed correctly. You wouldn't
normally be inheriting straight from gr_basic_block, but you should be able
to.


> And in tutorial on how to write signal processing block, it is stated to
> use gr.basic_block.
>

Which tutorial? Again, I don't think this is in the main GNU Radio source,
so please point out where you are getting this from.

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

[Discuss-gnuradio] Subject: Re: DARPA spectrum challenge teams?

[Uher, Jason J.]

I was interested, but really wasn't able to make the time commitment work out.  
With that said, if anyone refrained from entering a team because they were in 
desperate need of a  half-committed member who lived near Arlington and could 
attend the final challenge I'm open to joining up ;)

Date: Mon, 28 Jan 2013 20:23:22 -0700
From: Ben Reynwar 
To: Tom Rondeau 
Cc: GNURadio Discussion List 
Subject: Re: [Discuss-gnuradio] DARPA spectrum challenge teams?
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

I'll be part of the University of Arizona team and am also curious who
else is participating.

On Mon, Jan 28, 2013 at 6:10 PM, Tom Rondeau  wrote:
> Hello!
>
> We're close to the deadline for teams to sign up for the spectrum challenge
> (http://dtsn.darpa.mil/spectrumchallenge/Register.aspx). I haven't heard
> much from the crowd here. Is anyone planning on participating?
>
> 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] Problem loading Python block

[Nemanja Savic]

OK, I'll try to explain everything.

I want to design block responsible for decoding messages, calculating crc,
etc ... In order to do that I investigated packet_demod_base block from
main gnuradio branch,
and also packet_deframer from gr_extras group of blocks. I realized that
such kind of blocks consists of correlator, framer sink which acts like
message sink, and finally of some kind of message source. Framer sink sends
messages to message
source and message source then does packet checking and everything.

I also wanted to design my block in that fashion, so I used correlator and
framer sink and I wanted to design my own block which is able to receive
messages from packet framer and to check it. The code I provided in the
last post is my own, and not the part of gnuradio. Here is complete source
file of my block:

import numpy
from math import pi
from gnuradio import gr
from gruel import pmt
from gnuradio.digital import packet_utils
import gnuradio.digital as gr_digital


class packet_tst(gr.hier_block2):
def __init__(self, access_code=None, threshold=-1):

gr.hier_block2.__init__(
self,
"packet_tst",
gr.io_signature(1, 1, 1),  # Input signature
gr.io_signature(0, 0, 0) # Output signature
)

if not access_code:
access_code = packet_utils.default_access_code
if not packet_utils.is_1_0_string(access_code):
raise ValueError, "Invalid access_code %r. Must be string of
1's and 0's" % (access_code,)

if threshold == -1:
threshold = 12  # FIXME raise exception

msgq = gr.msg_queue(4)  # holds packets from the PHY
self.correlator = gr_digital.correlate_access_code_bb(access_code,
threshold)

self.framer_sink = gr.framer_sink_1(msgq)
self.connect(self, self.correlator, self.framer_sink)

self.hlp_blk = helper_block(msgq)

class helper_block(gr.basic_block):
def __init__(self, msgq):
gr.basic_block.__init__(
self, name = "helper_block",
in_sig = None, out_sig = None
#num_msg_outputs = 1
)

self._msgq = msgq


def work(self, input_items, output_items):
while True:
try: msg = self._msgq.delete_head()
except: return -1
print "Message received"

At the moment the block is designed only to write something to standard
output if it receives a message. The problem is gr.basic_block as I
described in previous post. Python interpreter doesn't complain about
gr.hier_block2, but only about gr.basic_block.
The tutorial for writing blocks in python is from gnuradio.org:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules#Tutorial-3-Writing-a-signal-processing-block-in-Python

Hope this helps.

Thanks


On Tue, Jan 29, 2013 at 2:16 PM, Tom Rondeau  wrote:

> On Tue, Jan 29, 2013 at 7:40 AM, Nemanja Savic  wrote:
>
>> I'm not sure what you mean by "load gr.basic_block." Do you mean inherit
>>> from?
>>
>>
>> I want to make my block which very similar to packet deframer. Here is th
>> code:
>>
>> class packet_tst(gr.hier_block2):
>>> def __init__(self, access_code=None, threshold=-1):
>>>
>>> gr.hier_block2.__init__(
>>> self,
>>> "packet_tst",
>>> gr.io_signature(1, 1, 1),  # Input signature
>>> gr.io_signature(0, 0, 0) # Output signature
>>> )
>>>
>>> if not access_code:
>>> access_code = packet_utils.default_access_code
>>> if not packet_utils.is_1_0_string(access_code):
>>> raise ValueError, "Invalid access_code %r. Must be string of
>>> 1's and 0's" % (access_code,)
>>>
>>> if threshold == -1:
>>> threshold = 12  # FIXME raise exception
>>>
>>> msgq = gr.msg_queue(4)  # holds packets from the PHY
>>> self.correlator =
>>> gr_digital.correlate_access_code_bb(access_code, threshold)
>>>
>>> self.framer_sink = gr.framer_sink_1(msgq)
>>> self.connect(self, self.correlator, self.framer_sink)
>>>
>>> self.hlp_blk = helper_block(msgq)
>>>
>>
>> in the same file is also defined class helper_block in this way:
>>
>> class helper_block(gr.basic_block):
>>> def __init__(self, msgq):
>>> gr.basic_block.__init__(
>>> self, name = "helper_block",
>>> in_sig = None, out_sig = None
>>> #num_msg_outputs = 1
>>> )
>>>
>>> self._msgq = msgq
>>>
>>> def work(self, input_items, output_items):
>>> while True:
>>> try: msg = self._msgq.delete_head()
>>> except: return -1
>>> print "Message received"
>>
>>
> I have no idea what files these are from. Are they part of the GNU Radio
> source code? I can't find references to them.
>
>
>
>> when I try to run test or flowgraph, I get this error

Re: [Discuss-gnuradio] Non-deterministic behavior

[Marcus D. Leech]

On 01/29/2013 04:47 AM, Vanessa Gardellin wrote:

Yes, we are using a throttle but when we execute the same python file
we obtain always different outcomes.
We would like to have repeatable experiments.
Any tips?

Thank you
Vanessa

Are you using a channel model in the middle of your simulation?



--
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

Re: [Discuss-gnuradio] Subject: Re: DARPA spectrum challenge teams?

[Sreeraj Rajendran]

Is this half-committed member ready to become a team lead for two Indian 
graduate students? Then we would also like to give it a shot.


---

Regards
Sreeraj Rajendran
http://home.iitb.ac.in/~rsreeraj




 From: "Uher, Jason J." 
To: "discuss-gnuradio@gnu.org"  
Sent: Tuesday, 29 January 2013 7:09 PM
Subject: [Discuss-gnuradio] Subject: Re:  DARPA spectrum challenge teams?
 

I was interested, but really wasn't able to make the time commitment work out.  
With that said, if anyone refrained from entering a team because they were in 
desperate need of a  half-committed member who lived near Arlington and could 
attend the final challenge I'm open to joining up ;)

Date: Mon, 28 Jan 2013 20:23:22 -0700
From: Ben Reynwar 
To: Tom Rondeau 
Cc: GNURadio Discussion List 
Subject: Re: [Discuss-gnuradio] DARPA spectrum challenge teams?
Message-ID:
    
Content-Type: text/plain; charset=ISO-8859-1

I'll be part of the University of Arizona team and am also curious who
else is participating.

On Mon, Jan 28, 2013 at 6:10 PM, Tom Rondeau  wrote:
> Hello!
>
> We're close to the deadline for teams to sign up for the spectrum challenge
> (http://dtsn.darpa.mil/spectrumchallenge/Register.aspx). I haven't heard
> much from the crowd here. Is anyone planning on participating?
>
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP sending packets after closing application

[maiconkist]

Hi list,

I notice that after running any application (for example uhd_fft), the USRP
continues to send a lot of packets to my machine. Is there something I am
missing ? Maybe the application is not closing correctly and stopping the
USRP from sending packets.


Thanks.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/USRP-sending-packets-after-closing-application-tp39267.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] USRP sending packets after closing application

[Josh Blum]

On 01/29/2013 10:25 AM, maiconkist wrote:
> Hi list,
> 
> I notice that after running any application (for example uhd_fft), the USRP
> continues to send a lot of packets to my machine. Is there something I am
> missing ? Maybe the application is not closing correctly and stopping the
> USRP from sending packets.


Are you seeing that LEDC is left on?
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds

Basically, if the device is not cleaned up properly, like the app is
just killed, when in continuous streaming mode, the device will continue
to stream.

However, usually this closes the sockets, the kernel then sends a ICMP
destination unreachable to the USRP and the USRP FW shuts down the RX DSP.

Perhaps that isnt happening or something is still running in the background?

-josh

> 
> 
> Thanks.
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/USRP-sending-packets-after-closing-application-tp39267.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] Benchmark Duplex

[Dong Wang]

Hi

When I try to establish the duplex comunication between two USRPs, I found
that if I put the code A infront of code B, only the transmitter works, but
if I put code B infront of code A, only receiver works.
Could anyone tells me the reason?
Thanks a lot!


code A:
self.source = uhd_receiver(options.args, symbol_rate,
   options.samples_per_symbol,
   options.rx_freq, options.rx_gain,
   options.spec, options.antenna,
   options.verbose)


code B:
self.sink = uhd_transmitter(options.args, symbol_rate,
options.samples_per_symbol,
options.tx_freq, options.tx_gain,
options.spec, options.antenna,
options.verbose)

Best regards!

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

[Discuss-gnuradio] USRP N210 Potentially Fried

[Justyn Bell]

Hello list,

We had a group of students working with two of our USRP N210s, and they 
had a problem receiving.. anything.  The USRP, however, still transmits.


I have verified that the USRP indeed doesn't receive a signal by 
attaching an FFT to the output of a UHD:USRP Source and transmitting 
both from another USRP as well as an analog handset we have in the lab.  
I can verify that both sources are transmitting (the handset at pretty 
high power) via a spectrum analyzer.  However, the FFT doesn't move in 
average amplitude at all, it remains around -65dB.


I've also tried re-flashing the firmware to no avail.  I also switched 
out one of the defective N210s for a third that we own, and verified 
that it works as normal.


Is there a better way of troubleshooting this, or has this ever occurred 
before?  Because they both can't receive today, and were tested and 
worked yesterday, this can't be a coincidence.  The antennas were not 
touched or moved at all, which would rule out the students doing 
something stupid like directly connecting the two RF ports.


What do I do next?

--
Justyn


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

[Discuss-gnuradio] gnuradio/conf.d in the wrong prefix

[Josh Blum]

I configured gr 3.6.4 to install in my prefix /opt/usr, and I caught the
installer putting the conf stuff in /usr/local anyways. I wasnt sure if
this was the intention, since there was some ramblings about FHS, and
/etc stuff

cmake ~/src/gnuradio/ -DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=/opt/usr/gr

The end of the make install including error:

> -- Installing: /opt/usr/gr/include/gruel/swig/gr_intrusive_ptr.i
> -- Installing: /opt/usr/gr/include/gruel/swig/pmt_swig.i
> -- Installing: /opt/usr/gr/include/gruel/swig/gruel_common.i
> -- Installing: /opt/usr/gr/include/gruel/swig/pmt_swig_doc.i
> -- Installing: /opt/usr/gr/lib64/python2.6/site-packages/gruel/__init__.py
> -- Installing: /opt/usr/gr/lib64/python2.6/site-packages/gruel/__init__.pyc
> -- Installing: /opt/usr/gr/lib64/python2.6/site-packages/gruel/__init__.pyo
> -- Installing: /opt/usr/gr/lib64/python2.6/site-packages/gruel/pmt/__init__.py
> -- Installing: 
> /opt/usr/gr/lib64/python2.6/site-packages/gruel/pmt/__init__.pyc
> -- Installing: 
> /opt/usr/gr/lib64/python2.6/site-packages/gruel/pmt/__init__.pyo
> CMake Error at gnuradio-core/cmake_install.cmake:38 (FILE):
>   file cannot create directory: /usr/local/etc/gnuradio/conf.d.  Maybe need
>   administrative privileges.
> Call Stack (most recent call first):
>   cmake_install.cmake:47 (INCLUDE)
> 
> 

-josh

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