Re: [Discuss-gnuradio] Making my own blocks

[Martin Braun]

On Tue, Nov 01, 2011 at 12:20:01PM -0400, Chris Lirakis wrote:
> Thanks to everyone who responded to my post yesterday. I've been slowly
> slogging my way through the code. Yes, it is a lot less connected than I
> originally thought. I needed to extract some helper functions from gnuradio/gr
> 
> So now I am making some custom blocks. How can I get the block ID to show up 
> in
> the graphical representation?

Are you using the howto-make-a-block as a template? If so, have a look
at the files in the grc/ subdirectory. You need to adapt these as well.

If you're using the old Makefile system, I would also like to spotlight
gr_modtool.py [1]. It's a tool which automatically writes template files
for .cc, .h and .py as well as the GRC bindings and edits the Makefiles
accordingly. You then only need to edit your stuff.

MB

[1] https://cgran.org/wiki/devtools


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



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

[Discuss-gnuradio] SDR contest

[Philip Balister]

http://wireless.vt.edu/sdrcontest/

This should be interesting to a lot of people on this list!

Philip

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

Re: [Discuss-gnuradio] QPSK with direct-sequence spread spectrum

[Tuan (Johnny) Ta]

I second Peter. As long as you make sure in your gray-coded QPSK
constellation, 0 is mapped to +1 and 1 is mapped to -1 then XOR is
equivalent to multiplication.

On Mon, Oct 31, 2011 at 1:59 PM, Peter Massam wrote:

>
> In general you're right, but it depends on the details.  Its usually quite
> straightforward, but a common mistake is to use the wrong bit-to-symbol
> mapping.  0 -> +1 and 1 -> -1 means that an XOR applied to bits is
> equivalent to multiplication applied to symbols.
>
>
> Nowlan, Sean wrote:
> >
> > Hi all,
> >
> > I'm wondering if spreading a bitstream (XOR-ing each bit with
> > SPREAD_FACTOR bits of sequence) before QPSK modulation is equivalent to
> > operating on the modulated stream, i.e., multiplying the complex output
> > with -1's and 1's from the sequence. So far I can't get the math to work
> > out. Any suggestions?
> >
> > Thanks,
> > Sean
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/QPSK-with-direct-sequence-spread-spectrum-tp32752034p32754111.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

Re: [Discuss-gnuradio] SDR contest

[Jeff Scaparra]

Is this just for students or is this open to public teams/individuals?

On Wed, Nov 2, 2011 at 11:48 AM, Philip Balister wrote:

> http://wireless.vt.edu/sdrcontest/
>
> This should be interesting to a lot of people on this list!
>
> Philip
>
> ___
> 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] SDR contest

[Jeff Scaparra]

Is this just for students or is this open to public teams/individuals?

On Wed, Nov 2, 2011 at 11:48 AM, Philip Balister wrote:

> http://wireless.vt.edu/sdrcontest/
>
> This should be interesting to a lot of people on this list!
>
> Philip
>
> ___
> 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] SDR contest

[Philip Balister]

On 11/02/2011 04:12 PM, Jeff Scaparra wrote:
> Is this just for students or is this open to public teams/individuals?

>From the project scope section:

Undergraduate and graduate students or teams of students, advised by a
faculty member, are eligible and may propose and solve any problem
related to software-defined radio

Philip

> 
> On Wed, Nov 2, 2011 at 11:48 AM, Philip Balister wrote:
> 
>> http://wireless.vt.edu/sdrcontest/
>>
>> This should be interesting to a lot of people on this list!
>>
>> Philip
>>
>> ___
>> 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] Receivers for Sale

[Jeff Kelly]

Cleaning the Shack.

USRP1 early serial # - No Case w/BasicRX, BasicTX, and one DBSRX. $500

FunDongle $150. 

Softrock 6.2 rxtx built $65.

Softrock 6.0 SDR Receiver 160 receiver built $30.

Softrock Lite II - 40 Meter built $50


All prices add $10 for shipping CONUS only.

Please contact off list 

jkelly at bellatlantic.net

Thanks,

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

[Discuss-gnuradio] detect PPS every second for synchronization

[Yan Nie]

Dear all,

I ma using USRP N200 with LFTX & LFRX +UHD to build up a transmitter and 
receiver. The transmitter and receiver are working well if continuously running 
without changing the USRP configuration. I am trying to use a GPS as the 
synchronization signal for signal reception, which is detecting the GPS pulse 
every second and using this pulse to trigger the signal reception.

I am using the 'set_clock_config' to set the PPS clock while the flow graph for 
receiver is built. The negative edge of the GPS pulse could be detected when 
the flow graph for receiver start running. I am wondering how to continuously 
detect the GPS pulse every second and use it as PPS signal to trigger the 
signal reception, so that the receiver could be able to synchronized with other 
device using GPS pulse. I tried to create a separate thread after the receiver 
flow graph start running:  (but this approach gives the USRP2 overrun result)

def pps_setting(tb)
    while (1):
    
      #pps clock configuration
      tb.clk_cfg = uhd.clock_config_t()
      tb.clk_cfg.pps_source = uhd.clock_config_t.PPS_SMA
      tb.clk_cfg.pps_polarity = uhd.clock_config.PPS_NEG
      tb._u2source.set_clock_config(tb.clk_cfg, uhd.ALL_MBOARDS)
      tb._u2source.set_time_unknown_pps(uhd.time_spec_t(0.0))
      
      tb.set_sample_rate(tb.sample_rate_rx)
      tb.set_freq(tb.freq_rx, tb.lo_offset)
      time.sleep(1.0)

1. I am wondering what is the problem? or how to detect the GPS pulse every 
second and use it to trigger the signal reception every second for 0.5 second 
signal receiving duration.

2. The same question for RF frequency changing. if I would like to change the 
RF frequency every second, what could be the best approach? 

Thank you so much!

Thanks,
Yan

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

[Discuss-gnuradio] gr_delay

[Marcus D. Leech]

It looks like setting the delay after block instantiation doesn't do 
anything.  I checked to see whether it was a GRC issue, or the block itself,
  and indeed, gr_delay doesn't do anything with a post-instantiation 
setting.



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

[Josh Blum]

On 11/02/2011 04:35 PM, Marcus D. Leech wrote:
> It looks like setting the delay after block instantiation doesn't do
> anything.  I checked to see whether it was a GRC issue, or the block
> itself,
>   and indeed, gr_delay doesn't do anything with a post-instantiation
> setting.

trackered new issue -> http://gnuradio.org/redmine/issues/462

thanks
-josh

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

Re: [Discuss-gnuradio] gr_delay

[Marcus D. Leech]

On 11/02/2011 07:39 PM, Josh Blum wrote:


On 11/02/2011 04:35 PM, Marcus D. Leech wrote:

It looks like setting the delay after block instantiation doesn't do
anything.  I checked to see whether it was a GRC issue, or the block
itself,
   and indeed, gr_delay doesn't do anything with a post-instantiation
setting.

trackered new issue ->  http://gnuradio.org/redmine/issues/462

thanks
-josh

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


To be clear, the problem appears to be with the block itself.   GRC 
correctly adds the "set_delay" callback spooge.


But calling that callback in the C++ code doesn't appear to affect the 
delay.




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

[Josh Blum]

On 11/02/2011 04:43 PM, Marcus D. Leech wrote:
> On 11/02/2011 07:39 PM, Josh Blum wrote:
>>
>> On 11/02/2011 04:35 PM, Marcus D. Leech wrote:
>>> It looks like setting the delay after block instantiation doesn't do
>>> anything.  I checked to see whether it was a GRC issue, or the block
>>> itself,
>>>and indeed, gr_delay doesn't do anything with a post-instantiation
>>> setting.
>> trackered new issue ->  http://gnuradio.org/redmine/issues/462
>>
>> thanks
>> -josh
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> To be clear, the problem appears to be with the block itself.   GRC
> correctly adds the "set_delay" callback spooge.
> 
> But calling that callback in the C++ code doesn't appear to affect the
> delay.
> 
> 

I guess the delay block should add extra delay cycles or insert dummy
samples depending upon the value. That could be useful

-josh

> 

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

Re: [Discuss-gnuradio] gr_delay

[Johnathan Corgan]

On Wed, Nov 2, 2011 at 16:43, Marcus D. Leech  wrote:

>
> To be clear, the problem appears to be with the block itself.   GRC
> correctly adds the "set_delay" callback spooge.
>
> But calling that callback in the C++ code doesn't appear to affect the
> delay.
>

Changing the delay via the callback changes the history requirements of the
block, which will not take effect until the thread executing the work()
function returns, and could be hundreds or thousands of items in the
future.  But it does take effect eventually.

One way to change this behavior would be to implement the pattern used in
the FIR blocks for when the number of taps changes.  Changing the delay
would set a flag that the work function could check for and return
immediately.  However, this wold come a high price, as the work() function
currently uses memcpy to move data from the input to the output, and
instead you'd have to have an iterative loop with a conditional equality
check in the middle.

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

Re: [Discuss-gnuradio] gr_delay

[Marcus D. Leech]

On 11/02/2011 08:03 PM, Johnathan Corgan wrote:
On Wed, Nov 2, 2011 at 16:43, Marcus D. Leech > wrote:



To be clear, the problem appears to be with the block itself.  
GRC correctly adds the "set_delay" callback spooge.


But calling that callback in the C++ code doesn't appear to affect
the delay.


Changing the delay via the callback changes the history requirements 
of the block, which will not take effect until the thread executing 
the work() function returns, and could be hundreds or thousands of 
items in the future.  But it does take effect eventually.


One way to change this behavior would be to implement the pattern used 
in the FIR blocks for when the number of taps changes.  Changing the 
delay would set a flag that the work function could check for and 
return immediately.  However, this wold come a high price, as the 
work() function currently uses memcpy to move data from the input to 
the output, and instead you'd have to have an iterative loop with a 
conditional equality check in the middle.


Johnathan
Your assertion that "it does take effect eventually" appears to not be 
true in reality (at least in this little test graph) (attached).


Looking at the code, there's an inline function, set_delay, that calls 
set_history().  And the SWIG goop appears to be correct.



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



delay_test.grc
Description: application/gnuradio-grc
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Delay Test
# Generated: Wed Nov  2 20:17:46 2011
##

from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from gnuradio.wxgui import forms
from gnuradio.wxgui import scopesink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx

class delay_test(grc_wxgui.top_block_gui):

	def __init__(self):
		grc_wxgui.top_block_gui.__init__(self, title="Delay Test")
		_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
		self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

		##
		# Variables
		##
		self.samp_rate = samp_rate = 200e3
		self.delay = delay = 0

		##
		# Blocks
		##
		_delay_sizer = wx.BoxSizer(wx.VERTICAL)
		self._delay_text_box = forms.text_box(
			parent=self.GetWin(),
			sizer=_delay_sizer,
			value=self.delay,
			callback=self.set_delay,
			label="Delay",
			converter=forms.float_converter(),
			proportion=0,
		)
		self._delay_slider = forms.slider(
			parent=self.GetWin(),
			sizer=_delay_sizer,
			value=self.delay,
			callback=self.set_delay,
			minimum=0,
			maximum=10,
			num_steps=10,
			style=wx.SL_HORIZONTAL,
			cast=float,
			proportion=1,
		)
		self.Add(_delay_sizer)
		self.wxgui_scopesink2_0 = scopesink2.scope_sink_f(
			self.GetWin(),
			title="Scope Plot",
			sample_rate=samp_rate,
			v_scale=0,
			v_offset=0,
			t_scale=0,
			ac_couple=False,
			xy_mode=False,
			num_inputs=2,
			trig_mode=gr.gr_TRIG_MODE_AUTO,
			y_axis_label="Counts",
		)
		self.Add(self.wxgui_scopesink2_0.win)
		self.gr_throttle_0 = gr.throttle(gr.sizeof_float*1, samp_rate)
		self.gr_sig_source_x_0 = gr.sig_source_f(samp_rate, gr.GR_COS_WAVE, 25000, 1, 0)
		self.gr_delay_0 = gr.delay(gr.sizeof_float*1, int(delay))

		##
		# Connections
		##
		self.connect((self.gr_delay_0, 0), (self.wxgui_scopesink2_0, 0))
		self.connect((self.gr_sig_source_x_0, 0), (self.gr_throttle_0, 0))
		self.connect((self.gr_throttle_0, 0), (self.gr_delay_0, 0))
		self.connect((self.gr_throttle_0, 0), (self.wxgui_scopesink2_0, 1))

	def get_samp_rate(self):
		return self.samp_rate

	def set_samp_rate(self, samp_rate):
		self.samp_rate = samp_rate
		self.wxgui_scopesink2_0.set_sample_rate(self.samp_rate)
		self.gr_sig_source_x_0.set_sampling_freq(self.samp_rate)

	def get_delay(self):
		return self.delay

	def set_delay(self, delay):
		self.delay = delay
		self.gr_delay_0.set_delay(int(self.delay))
		self._delay_slider.set_value(self.delay)
		self._delay_text_box.set_value(self.delay)

if __name__ == '__main__':
	parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
	(options, args) = parser.parse_args()
	tb = delay_test()
	tb.Run(True)

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

Re: [Discuss-gnuradio] gr_delay

[Johnathan Corgan]

On Wed, Nov 2, 2011 at 17:19, Marcus D. Leech  wrote:


> Your assertion that "it does take effect eventually" appears to not be
> true in reality (at least in this little test graph) (attached).
>
> Looking at the code, there's an inline function, set_delay, that calls
> set_history().  And the SWIG goop appears to be correct.
>

Quit finding bugs in years old, assumed working code!

:)

It looks like this has never worked, and maybe was never even implemented.
I'm combing through the appropriate archaeological strata in the tree to
see if the needed handling was removed at some point, but it looks unlikely.

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

Re: [Discuss-gnuradio] gr_delay

[Marcus D. Leech]

On 11/02/2011 09:33 PM, Johnathan Corgan wrote:
On Wed, Nov 2, 2011 at 17:19, Marcus D. Leech > wrote:


Your assertion that "it does take effect eventually" appears to
not be true in reality (at least in this little test graph)
(attached).

Looking at the code, there's an inline function, set_delay, that
calls set_history().  And the SWIG goop appears to be correct.


Quit finding bugs in years old, assumed working code!

:)

It looks like this has never worked, and maybe was never even 
implemented.  I'm combing through the appropriate archaeological 
strata in the tree to see if the needed handling was removed at some 
point, but it looks unlikely.


Johnathan
I even tried a quick "hack" that sets an "updated" flag, and at the top 
of the work function, calling set_history() on a d_pending

  delay value, and then immediately returning 0.  That did nothing useful.

If people have ever tried to use this for phased-array coarse delay 
setting in a dynamic sense, it never would have worked.


I want it for two-element interferometry (the nearly-degenerate-case of 
a phased array :-) ).  I can already do fine phase adjustment just using
  complex phase rotation, but coarse adjustment requires that delays be 
inserted.  I need to be able to do it dynamically.


One quick hack I tried was to have a bunch of delay blocks, each with 
their own initial delay setting, and then selecting which one
  I wanted.  That worked just fine.  So the initial set_history() 
appears to have the desired effect.




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

[Marcus D. Leech]

On 11/02/2011 09:33 PM, Johnathan Corgan wrote:
On Wed, Nov 2, 2011 at 17:19, Marcus D. Leech > wrote:


Your assertion that "it does take effect eventually" appears to
not be true in reality (at least in this little test graph)
(attached).

Looking at the code, there's an inline function, set_delay, that
calls set_history().  And the SWIG goop appears to be correct.


Quit finding bugs in years old, assumed working code!

:)

It looks like this has never worked, and maybe was never even 
implemented.  I'm combing through the appropriate archaeological 
strata in the tree to see if the needed handling was removed at some 
point, but it looks unlikely.


Johnathan
Also, I wonder whether it has anything to do with the fact that it's a 
gr_sync_block, and not a gr_sync_decimator.  The FIR filters are all
  gr_sync_decimators, and perhaps the block executors treatment of them 
and their history setting is the main difference here.




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

[Johnathan Corgan]

On Wed, Nov 2, 2011 at 18:39, Marcus D. Leech  wrote:


> I want it for two-element interferometry (the nearly-degenerate-case of a
> phased array :-) ).  I can already do fine phase adjustment just using
>   complex phase rotation, but coarse adjustment requires that delays be
> inserted.  I need to be able to do it dynamically.
>
> One quick hack I tried was to have a bunch of delay blocks, each with
> their own initial delay setting, and then selecting which one
>   I wanted.  That worked just fine.  So the initial set_history() appears
> to have the desired effect.
>

You could create an FIR filter with zero-valued taps up to the delay, and a
single 1.0 tap at the end, then modify the taps as needed to adjust the
delay.

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

Re: [Discuss-gnuradio] gr_delay

[Johnathan Corgan]

On Wed, Nov 2, 2011 at 18:41, Marcus D. Leech  wrote:


> Also, I wonder whether it has anything to do with the fact that it's a
> gr_sync_block, and not a gr_sync_decimator.  The FIR filters are all
>   gr_sync_decimators, and perhaps the block executors treatment of them
> and their history setting is the main difference here.
>

I don't think it matters.  Grepping the tree to find out what code pays
attention to d_history member in the block class turns up...very little
aside from the initial block construction sequence (creating buffers, etc.)

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

Re: [Discuss-gnuradio] gr_delay

[Marcus D. Leech]

On 11/02/2011 09:45 PM, Johnathan Corgan wrote:



You could create an FIR filter with zero-valued taps up to the delay, 
and a single 1.0 tap at the end, then modify the taps as needed to 
adjust the delay.


Johnathan

Slick.


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

[Marcus D. Leech]

On 11/02/2011 09:48 PM, Johnathan Corgan wrote:
On Wed, Nov 2, 2011 at 18:41, Marcus D. Leech > wrote:


Also, I wonder whether it has anything to do with the fact that
it's a gr_sync_block, and not a gr_sync_decimator.  The FIR
filters are all
  gr_sync_decimators, and perhaps the block executors treatment of
them and their history setting is the main difference here.


I don't think it matters.  Grepping the tree to find out what code 
pays attention to d_history member in the block class turns up...very 
little aside from the initial block construction sequence (creating 
buffers, etc.)


Johnathan
OK, so here's a new attemp, with dynamic selection of taps for the FIR 
filter.  It also appears to not work.  Only filter taps that exist on

  startup are working properly.  Gulp.



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



delay_test.grc
Description: application/gnuradio-grc
#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: Delay Test
# Generated: Wed Nov  2 22:19:21 2011
##

from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from gnuradio.wxgui import forms
from gnuradio.wxgui import scopesink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx

class delay_test(grc_wxgui.top_block_gui):

	def __init__(self):
		grc_wxgui.top_block_gui.__init__(self, title="Delay Test")
		_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
		self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

		##
		# Variables
		##
		self.taps4 = taps4 = [0.0,0.0,0.0,0.0,1.0]
		self.taps3 = taps3 = [0.0,0.0,0.0,1.0]
		self.taps2 = taps2 = [0.0,0.0,1.0]
		self.taps1 = taps1 = [0.0,1.0]
		self.taps0 = taps0 = [1.0]
		self.tapsarray = tapsarray = [taps0,taps1,taps2,taps3,taps4]
		self.delay = delay = 0
		self.taps = taps = tapsarray[delay]
		self.samp_rate = samp_rate = 200e3

		##
		# Blocks
		##
		self.wxgui_scopesink2_0 = scopesink2.scope_sink_f(
			self.GetWin(),
			title="Scope Plot",
			sample_rate=samp_rate,
			v_scale=0,
			v_offset=0,
			t_scale=0,
			ac_couple=False,
			xy_mode=False,
			num_inputs=2,
			trig_mode=gr.gr_TRIG_MODE_AUTO,
			y_axis_label="Counts",
		)
		self.Add(self.wxgui_scopesink2_0.win)
		self.gr_throttle_0 = gr.throttle(gr.sizeof_float*1, samp_rate)
		self.gr_sig_source_x_0 = gr.sig_source_f(samp_rate, gr.GR_COS_WAVE, 25000, 1, 0)
		self.gr_fir_filter_xxx_0 = gr.fir_filter_fff(1, (taps))
		self._delay_chooser = forms.radio_buttons(
			parent=self.GetWin(),
			value=self.delay,
			callback=self.set_delay,
			label="Delay",
			choices=[0, 1, 2, 3, 4],
			labels=[],
			style=wx.RA_HORIZONTAL,
		)
		self.Add(self._delay_chooser)

		##
		# Connections
		##
		self.connect((self.gr_sig_source_x_0, 0), (self.gr_throttle_0, 0))
		self.connect((self.gr_throttle_0, 0), (self.wxgui_scopesink2_0, 1))
		self.connect((self.gr_throttle_0, 0), (self.gr_fir_filter_xxx_0, 0))
		self.connect((self.gr_fir_filter_xxx_0, 0), (self.wxgui_scopesink2_0, 0))

	def get_taps4(self):
		return self.taps4

	def set_taps4(self, taps4):
		self.taps4 = taps4
		self.set_tapsarray([self.taps0,self.taps1,self.taps2,self.taps3,self.taps4])

	def get_taps3(self):
		return self.taps3

	def set_taps3(self, taps3):
		self.taps3 = taps3
		self.set_tapsarray([self.taps0,self.taps1,self.taps2,self.taps3,self.taps4])

	def get_taps2(self):
		return self.taps2

	def set_taps2(self, taps2):
		self.taps2 = taps2
		self.set_tapsarray([self.taps0,self.taps1,self.taps2,self.taps3,self.taps4])

	def get_taps1(self):
		return self.taps1

	def set_taps1(self, taps1):
		self.taps1 = taps1
		self.set_tapsarray([self.taps0,self.taps1,self.taps2,self.taps3,self.taps4])

	def get_taps0(self):
		return self.taps0

	def set_taps0(self, taps0):
		self.taps0 = taps0
		self.set_tapsarray([self.taps0,self.taps1,self.taps2,self.taps3,self.taps4])

	def get_tapsarray(self):
		return self.tapsarray

	def set_tapsarray(self, tapsarray):
		self.tapsarray = tapsarray
		self.set_taps(self.tapsarray[self.delay])

	def get_delay(self):
		return self.delay

	def set_delay(self, delay):
		self.delay = delay
		self.set_taps(self.tapsarray[self.delay])
		self._delay_chooser.set_value(self.delay)

	def get_taps(self):
		return self.taps

	def set_taps(self, taps):
		self.taps = taps
		self.gr_fir_filter_xxx_0.set_taps((self.taps))

	def get_samp_rate(self):
		return self.samp_rate

	def set_samp_rate(self, samp_rate):
		self.samp_rate = samp_rate
		self.gr_sig_s