Re: [Discuss-gnuradio] usrp_basic and gr_block
On Sat, Jun 17, 2006 at 03:23:53PM -0500, Michael Ford wrote: I'm trying to use a function in the usrp_basic class, but there's no SWIG .i script for it. While looking at the tutorials, I read that all processing blocks need to derive from the class gr_block. However, this isn't the case for usrp_basic. I guess this makes sense, as usrp_basic isn't really a processing block - the function I'm wanting to use just reads input from the RSSI circuit. Should I be consulting the Dawei Shen's processing block tutorial at all then? the usrp_basic class isn't even under the gr package. Hi Michael, Pretty much all of usrp_basic.h as well as usrp_standard.h is wrapped by gr-usrp/src/usrp1.i. The usrp specific classes that derive from gr_block are usrp1_source_base.h and usrp1_sink_base.h. I recall Matt mentioning that to read the RSSI you use one of the aux adcs. These are already wrapped. See usrp1.i: int read_aux_adc (int which_dboard, int which_adc); Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Squelch developments
Frank wrote the keyer code that runs in PowerSDR and is distributed with DttSP and wrote the ramp used in it as well as the agc. It is perfect shaping. You could derive a Gaussian shape that would minimize the time bandwidth product but the bandwidth would widen. It is better to spend slightly more time and narrow the bandwidth of the transition as the hear can plainly hear in the CW transmissions from the SDR-1000 or the onset of the agc with very strong signals on a quiet band. Bob N4HY Frank Brickle wrote: Exactly. 73 Frank AB2KT Johnathan Corgan wrote: Frank Brickle wrote: Yes, although half a cycle of a raised cosine is almost as easy, and analytically correct. 1/2 - cos(x)/2, for x from 0 to pi? Should this be applied (in reverse) as a decay window when squelch cuts in, as well as the attack window we've been talking about? -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_basic and gr_block
I apologize for not responding earlier - I found the usrp1.i file not long after I made my post. I was confused at first because in my search for the read_aux_adc() function, I had originally found it in usrp_basic.{cc, h}
-Michael Ford-On 6/18/06, Eric Blossom [EMAIL PROTECTED] wrote:
On Sat, Jun 17, 2006 at 03:23:53PM -0500, Michael Ford wrote: I'm trying to use a function in the usrp_basic class, but there's no SWIG .i script for it. While looking at the tutorials, I read that all processing
blocks need to derive from the class gr_block. However, this isn't the case for usrp_basic. I guess this makes sense, as usrp_basic isn't really a processing block - the function I'm wanting to use just reads input from the
RSSI circuit. Should I be consulting the Dawei Shen's processing block tutorial at all then? the usrp_basic class isn't even under the gr package.Hi Michael,Pretty much all of usrp_basic.h as well as usrp_standard.h is wrapped
by gr-usrp/src/usrp1.i.The usrp specific classes that derive fromgr_block are usrp1_source_base.h and usrp1_sink_base.h.I recall Matt mentioning that to read the RSSI you use one of the auxadcs.These are already wrapped.
See usrp1.i:int read_aux_adc (int which_dboard, int which_adc);Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_basic and gr_block
after setting the PYTHONPATH variable to point to
~/gr-build/gr-usrp/src/ (where usrp1.py is located), I ran my python
test script, and got the following error:
$ python test_sender.py Traceback (most recent call last):
File test_sender.py, line 22, in ?
import usrp1
File /home/mford1/gr-build/gr-usrp/src/usrp1.py, line 4, in ?
import _usrp1
ImportError: No module named _usrp1
After searching my computer, I find that there is in fact no module
called _usrp1, only a libtool file in the ~/gr-build/gr-usrp/src/
directory called usrp1.la. I'm guessing there might be something wrong
with my installation.
-Michael Ford-
On 6/18/06, Michael Ford [EMAIL PROTECTED] wrote:
I apologize for not responding earlier - I found the usrp1.i file
not long after I made my post. I was confused at first because in my
search for the read_aux_adc() function, I had originally found it in
usrp_basic.{cc, h}
-Michael Ford-On 6/18/06, Eric Blossom
[EMAIL PROTECTED] wrote:
On Sat, Jun 17, 2006 at 03:23:53PM -0500, Michael Ford wrote: I'm trying to use a function in the usrp_basic class, but there's no SWIG .i script for it. While looking at the tutorials, I read that all processing
blocks need to derive from the class gr_block. However, this isn't the case for usrp_basic. I guess this makes sense, as usrp_basic isn't really a processing block - the function I'm wanting to use just reads input from the
RSSI circuit. Should I be consulting the Dawei Shen's processing block tutorial at all then? the usrp_basic class isn't even under the gr package.Hi Michael,Pretty much all of usrp_basic.h as well as usrp_standard.h is wrapped
by gr-usrp/src/usrp1.i.The usrp specific classes that derive fromgr_block are usrp1_source_base.h and usrp1_sink_base.h.I recall Matt mentioning that to read the RSSI you use one of the auxadcs.These are already wrapped.
See usrp1.i:int read_aux_adc (int which_dboard, int which_adc);Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_basic and gr_block
This is all well for functions found in usrp.py, but even though I import usrp.py, and usrp.py successfully imports usrp1.py, I'm unable to successfully call functions from usrp1.py (i.e. read_aux_adc()). Calling the function with either a usrp- or usrp1- prefix gives me an error of the module not having a read_aux_adc attribute.On 6/18/06, Eric Blossom [EMAIL PROTECTED] wrote: On Sun, Jun 18, 2006 at 02:18:01PM -0500, Michael Ford wrote: after setting the PYTHONPATH variable to point to ~/gr-build/gr-usrp/src/ (where usrp1.py is located), I ran my python test script, and got the following error: $ python test_sender.py Traceback (most recent call last):File test_sender.py, line 22, in ? import usrp1File /home/mford1/gr-build/gr-usrp/src/usrp1.py, line 4, in ?import _usrp1 ImportError: No module named _usrp1 After searching my computer, I find that there is in fact no module called _usrp1, only a libtool file in the ~/gr-build/gr-usrp/src/ directory called usrp1.la. I'm guessing there might be something wrong with my installation. -Michael Ford- Don't do it that way ;)Just install gr-usrp as usual, then write your test script someplaceelse.To import the usrp code, do like all of the examples:from gnuradio import usrpu = usrp.source_c (...)You may want to take a look at the code in gnuradio-examples/python/usrpEric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_basic and gr_block
On Sun, Jun 18, 2006 at 06:34:19PM -0500, Michael Ford wrote: This is all well for functions found in usrp.py, but even though I import usrp.py, and usrp.py successfully imports usrp1.py, I'm unable to successfully call functions from usrp1.py (i.e. read_aux_adc()). Calling the function with either a usrp- or usrp1- prefix gives me an error of the module not having a read_aux_adc attribute. After creating an instance of the usrp object use the object, not the class. You want to invoke a method of the object. [EMAIL PROTECTED] tmp]$ python Python 2.4.1 (#1, Sep 13 2005, 00:39:20) [GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] on linux2 Type help, copyright, credits or license for more information. from gnuradio import usrp u = usrp.source_c(0, 64) v = u.read_aux_adc(0, 0) print v 224 You might want to spend a bit of time with the python tutorial at http://www.python.org/doc I prefer the pdf formatted version available here: http://docs.python.org/download.html Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_basic and gr_block
On Sun, Jun 18, 2006 at 08:21:57PM -0500, Michael Ford wrote:
Why are there almost no constructors defined in any of the usrp1.py classes?
I was chugging along until I realized that most of the classes have no
constructors. Should I be using the shared pointer classes?
[In the future please be sure to post these to the list, not directly to me.
Use the Reply-to-all command in your mail tool.]
First off, trying to read the machine generated code in usrp1.py is
a path to madness... Don't go there.
From the C++ point of view, they have constructors; they happen to be
protected or private. The are only callable by their friend:
gr_make_foo for class gr_foo. This hackery is required to ensure that
there are no non-boost::shared_ptrgr_foo's floating around. This
allows them to interact reasonably with Python's reference counting.
As a result we are able to store references to classes in both C++
data structures as well as in Python data structures without leaking
memory and/or having other object lifetime problems.
The way that we wrap the C++ with SWIG results in the gr_make_foo
function that returns a shared pointer being called automatically
instead of the protected constructor. This all takes place
transparently.
If you care about this level of detail (since you're still trying to
get your bearings, I suggest you avoid this), you might want to look
at how one of the more simple blocks are wrapped. E.g.,
gnuradio-core/src/lib/general/gr_add_const_ff.{h,cc,i}
GR_SWIG_BLOCK_MAGIC is defined in
gnuradio-core/src/lib/runtime/gr_swig_block_magic.i
It's not supposed to be understandable ;)
You can generally ignore all this, even when writing new blocks.
In that case, just follow the recipe in How to write a new block.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
