Re: [Discuss-gnuradio] Signal Seperation

[Martin Braun]

On Thu, Oct 13, 2011 at 08:51:40PM -0400, Raullen Chai wrote:
> Hi, 
> 
> 
> Could somebody give me some tips and help on the following problem? Really
> appreciated!
> 
> 
> The input signal is b1(t)*sin(f1*t) + b2(t)*sin(f2*t), where f1 and f2 are
> close but different,  and b1(t) and b2(t) are two different square waves
> with different period.  
> 
> After the USRP down coverts this wave to the baseband, the two modulated sine
> waves are mixed. How could I extract b2(t) or b1(t) respectively?

How close are they with respect to the period length of the square
waves? If they are easily separated 'visually' in an FFT of the duration
of one pulse, you should be fine with filtering. Try a different filter,
with steeper flanks. Don't worry about doing something extreme, you will
only distort your phase which doesn't seem important.

MB
 
> I tried to used a baseband filter, but it seems not work well.



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



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

[Discuss-gnuradio] uhd.usrp_source COMPLEX_INT16 vs COMPLEX_FLOAT32

[Kyle Zhou]

the usrp_source in gr-uhd has two io_type uhd.io_type.COMPLEX_INT16 and 
uhd.io_type.COMPLEX_FLOAT32. 
To my understanding, the float version will produce samples between -1.0 and 
+1.0.
What is the range of the int16 version?
If the same signal is fed into the antenna, what is the relative scaling 
between these two versions?
Regards
K Z
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to implement TDMA

[qaz wsx]

Hi,

I am planning to move from CSMA to TDMA. Can anyone help me get directions
where to start. I saw that mblock are no more available, and instead 'stream
tags' are
used. I don't have knownledge of the underlying structure. I was also trying
to
understand the OpenBTS codes, but no help.

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

Re: [Discuss-gnuradio] Generating orthogonal PN sequences in GRC

[godana ebrahim]

I tried a simple setup to see if specifying the mask in GRC does things
as expected (as you told me). I took two GLFSR blocks. Both blocks are
set to the same degree (6) and the same seed. The mask of the first
block is set to 0; so that the built-in mask of degree 6 (which has an
integer value of 18) is used. For the other block, I set the mask to 18
in GRC. These two blocks are expected to give the same output sequence.
However, they did not. When I set the mask of both blocks to 0, they
give the same output. So, what is wrong ? Something I am missing here ?

brex





I am trying to use the GLFSR source in GRC with PN correlator for system 
identification. What I want is to generate a sequence from the GLFSR source and 
to get an estimate when the PN correlator uses the same sequence and to get 
zero when the sequences generated by the GLFSR and the PN correlator are 
totally orthogonal for any delay.
>
>
>
>To  make this,  I need to know how to generate two orthogonal PN sequences 
>from two different GLFSR blocks. I tried to use different seed parameters, but 
>I saw that the two sequences are still correlated for some delay (shift). 
>Anyone who has done this before ? In short, how can I generate two PN 
>sequences which are orthogonal for any delay ?

This block optionally takes both a seed and mask parameter.  The seed provides 
the initial contents of the LFSR, and the mask represents the generator 
polynomial feedback taps.

The feedback taps are the thing that creates different sequences, while the 
seed (as you have discovered) determines the phase of the generated sequence.

The block has a set of default feedback taps for each polynomial degree, which 
are known to create maximal-length PN sequences:
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/general/gri_glfsr.cc#n26

Finally, to answer your question, in order for two different GLFSR blocks to 
generate orthogonal sequences, you'll have to specify your own polynomial mask. 
 A good place to learn about maximal-length sequences with references to 
different polynomials:
http://en.wikipedia.org/wiki/Maximum_length_sequence

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

Re: [Discuss-gnuradio] How to reconfigure automatically the channel used to received data in USRPs

[Tuan (Johnny) Ta]

Can you elaborate on how exactly you solved this problem without using GRC?
What kind of interprocess communication did you use?

Thanks,
Johnny

On Tue, Sep 13, 2011 at 10:08 AM, Lebowski80 wrote:

>
> Hi Nick,
>
> I just wanted tell you that I solved my problem using interprocess
> communication, thank you for your advice!
>
> Regards
>
>
> Lebowski80 wrote:
> >
> > Ok, thank you for your advice, I will try with interprocess
> communication.
> >
> > Regards
> >
> >
> > Nick Foster-4 wrote:
> >>
> >> Short answer: You cannot open a new USRP instance to reconfigure an
> >> already-running USRP instance. You must reconfigure the existing
> >> instance.
> >>
> >> The best advice I can give is that only one flowgraph can be operational
> >> per
> >> USRP device. In your setup, USRP#1 will run a single flowgraph with a
> >> source
> >> and/or sink, USRP#2 will run a single flowgraph with a source and/or
> >> sink,
> >> and USRP#3 will run a single flowgraph with a source and/or sink. If you
> >> wish to change the parameters of USRP#2 while it is running, rather than
> >> try
> >> to open a new USRP device in your benchmark_rxr.py flowgraph, use any of
> >> the
> >> standard interprocess communication methods to talk to your
> >> already-running
> >> USRP#2 script and reconfigure it as necessary.
> >>
> >> --n
> >>
> >> On Wed, Sep 7, 2011 at 9:31 AM, Lebowski80 
> >> wrote:
> >>
> >>>
> >>> Hello Nick,
> >>>
> >>> What do you mean? Actually I'm running RX and TX in two different
> >>> flowgraphs
> >>> on USRP1, the first one in usrp_spectrum_sense.py to look for a free
> >>> channel
> >>> (so the RX). In this script I also run benchmark_tx.py by the command p
> >>> =
> >>> Popen('python benchmark_tx.py', shell =  True), then my second
> >>> flowgrapgh
> >>> (the TX).
> >>>
> >>> My problem is that on USRP2 I want to reconfigure the RX channel by
> >>> python
> >>> (RX channel = 2484 MHz in the script benchmark_rx.py and RX channel =
> >>> channel received by USRP1 in the script benchamrk_rxr.py run by
> >>> benchmark_rx.py with the command p = Popen('python benchmark_rxr.py',
> >>> shell
> >>> =  True)).
> >>>
> >>> So I'm wondering if there exists the possibility to reconfigure the
> >>> parameters of a script in the same USRP (i.e. RX frequency channel)
> >>> while
> >>> it
> >>> is running and if this is not possible what do people mean with "USRP
> >>> reconfigurability?"
> >>>
> >>> I really need an answer to understand the potentiality of my hardware,
> >>> thanks a lot!
> >>>
> >>> Regards
> >>>
> >>>
> >>>
> >>> Nick Foster-4 wrote:
> >>> >
> >>> > On Wed, Sep 7, 2011 at 3:27 AM, Lebowski80 
> >>> > wrote:
> >>> >
> >>> >>
> >>> >> Hello everyone,
> >>> >>
> >>> >> Before to explain my problem I give some technical information about
> >>> my
> >>> >> hardaware. I'm using USRPs v1 and the boards integrated are XCVR2450
> >>> >> Transceivers.
> >>> >>
> >>> >> I'm using the script usrp_spectrum_sense.py in a USRP (called USRP1)
> >>> to
> >>> >> make
> >>> >> sensing in the ISM band, after a few seconds it sends to another
> USRP
> >>> >> (Called USRP2) a free sensed channel on the central frequency 2484
> >>> MHz.
> >>> >> USRP2 listens to the channel 2484 MHz through the script
> >>> benchmark_rx.py
> >>> >> and
> >>> >> it can properly receive the free ISM channel sent by USRP1. Then, I
> >>> want
> >>> >> to
> >>> >> use the USRP2 to receive data from another USRP (called USRP3) that
> >>> uses
> >>> >> the
> >>> >> script benchmark_tx.py.
> >>> >>
> >>> >> In the script benchmark_rx.py (used by USRP2) that listens to
> channel
> >>> >> 2484
> >>> >> MHz I want to run another script that I called benchmark_rxr.py that
> >>> >> waits
> >>> >> for data sent by USRP3 to be received in the free ISM channel sent
> by
> >>> >> USRP1.
> >>> >>
> >>> >> Relevant line of the code in the script benchmark_rx.py is attached
> >>> >> below:
> >>> >>
> >>> >> p = Popen('python benchmark_rxr.py', shell =  True)
> >>> >>
> >>> >> While this is the error that I get:
> >>> >>
> >>> >> usrp_open_interface:usb_claim_interface: failed interface 2
> >>> >> could not claim interface 2: Device or resource busy
> >>> >> usrp_basic_rx: can't open rx interface
> >>> >> Traceback (most recent call last):
> >>> >>  File "benchmark_rxr.py", line 153, in 
> >>> >>main()
> >>> >>  File "benchmark_rxr.py", line 138, in main
> >>> >>tb = my_top_block(demods[options.modulation],
> >>> >> mods[options.modulation],
> >>> >> rx_callback, options)
> >>> >>  File "benchmark_rxr.py", line 46, in __init__
> >>> >>self.rxpath = usrp_receive_path.usrp_receive_path(demodulator,
> >>> >> rx_callback, options)
> >>> >>  File
> >>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
> >>> >> line 65, in __init__
> >>> >>self._setup_usrp_source(options)
> >>> >>  File
> >>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
> >>> >> line 78, in _setup_usrp_source
> >>> >>self.u = usrp_options.cr

Re: [Discuss-gnuradio] Simultaneous wireless transmission and reception between USRP2s

[Tuan (Johnny) Ta]

I'm also interested in this problem. Juan Ramon, did you make any progress?
If you did, would you mind sharing it?

For Marcus, I have a more general question regarding the flow graph. If I
have in my GRC both a UHD sink and a UHD source block, is it true that the
USRP2 will stay in receive mode until there're samples on the transmit
buffer? Will it then switch to transmit mode and transmit until the transmit
buffer is empty and switch back to receive mode?

Thanks,
Johnny

On Thu, Jun 9, 2011 at 11:02 AM, Marcus D. Leech  wrote:

> Dear GNU Radio list's members,
>>
>> I have a set of USRP2+XCVR2450 with the host computers configured with
>> the *GNU Radio classic drivers* (v.3.3.0).
>>
>> My main idea is to transmit and receive data through a wireless
>> connection between the USRP2s. For now, I'm unaware of the PHY
>> technology but the only restriction I have is that the transmission and
>> reception of each node has to be carried out in a single USRP2.
>>
>> GNU Radio by default provides a set of examples but, as far as I know,
>> *tunnel.py* (in gnuradio-examples/digital folder) is the only script
>> that meets such condition.
>>
>> I would like to ask whether you know the existence any other
>> implementation that executes both the transmission and reception
>> procedure in the same USRP2s.
>>
>> Thank you in advance for your time. Any hint would be appreciated.
>>
>> Regards,
>> J.R.
>>
>>
>> __**_
>>
> You should be aware that the XCVR2450 is a *half duplex* daughtercard--the
> hardware is physically incapable of receiving and
>  transmitting *at the same time*, although it's perfectly capable of
> half-duplex operations, which can certainly happen on a single
>  USRP2 with suitable Gnu Radio flow-graph behind it.
>
>
>
>
> --
> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved

[Tuan (Johnny) Ta]

Vijay,

Can you post a GRC file with full-duplex configuration? I have the XCVR2450
board so I know I can only get half-duplex. Does the GRC full-duplex flow
graph for the WBX board achieve half-duplex for the XCVR2450 board?

Thanks,
Johnny

On Mon, Mar 14, 2011 at 12:37 PM, Vijay Pillai wrote:

> Hi Marc,
>
> How much leakage are you seeing between TX and RX on a WBX board?
>
> Yeah, GRC works fine for full duplex and it is very easy to set it up.
>
> Best regards,
> -Vijay
>
> --- On *Mon, 3/14/11, Marc Epard * wrote:
>
>
> From: Marc Epard 
> Subject: Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved
> To: "Scott Johnston" 
> Cc: "discuss-gnuradio Discussion Group" 
> Date: Monday, March 14, 2011, 12:12 PM
>
>
> On Mar 14, 2011, at 8:53 AM, Marcus D. Leech wrote:
>
> > On 14/03/2011 9:42 AM, Scott Johnston wrote:
> >> Does anybody have an example of how to setup a full duplex app?
> >>
> >> I am using the uhd with the USRP n210.
> >>
> >> Marc Epard wrote:
> >>> I've been attempting to do a full duplex send/recv using UHD on a USRP2
> with an XCVR2450.
> >
> > The XCVR2450 *hardware* doesn't support full-duplex at all, so no amount
> of cleverness on the software side can change that.
>
> Although the XCVR2450 doesn't do full duplex, the WBX does, and current UHD
> avoids the problem I described in my previous message. However, the WBX has
> enough internal leakage between tx and rx that we gave up on
> single-daughterboard full duplex. We now use a USRP2 with a WBX for tx and a
> USRP N210 with a DBSRX2 for rx.
>
> As for examples, I'll try to clean up my C++ app and post it later this
> week. GRC works fine full-duplex, too, I believe.
>
> -Marc
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://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] Simultaneous wireless transmission and reception between USRP2s

[Marcus D. Leech]

On 14/10/2011 10:04 AM, Tuan (Johnny) Ta wrote:
I'm also interested in this problem. Juan Ramon, did you make any 
progress? If you did, would you mind sharing it?


For Marcus, I have a more general question regarding the flow graph. 
If I have in my GRC both a UHD sink and a UHD source block, is it true 
that the USRP2 will stay in receive mode until there're samples on the 
transmit buffer? Will it then switch to transmit mode and transmit 
until the transmit buffer is empty and switch back to receive mode?


Thanks,
Johnny

Basically, yes.  The UHD interface will turn back to receive when the 
End-of-Burst is triggered.  But Josh probably has better details.

  I'm largely a receive-only guy in my own personal projects.


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

Re: [Discuss-gnuradio] uhd.usrp_source COMPLEX_INT16 vs COMPLEX_FLOAT32

[Josh Blum]

On 10/14/2011 03:31 AM, Kyle Zhou wrote:
> the usrp_source in gr-uhd has two io_type uhd.io_type.COMPLEX_INT16 and 
> uhd.io_type.COMPLEX_FLOAT32. 
> To my understanding, the float version will produce samples between -1.0 and 
> +1.0.
> What is the range of the int16 version?
> If the same signal is fed into the antenna, what is the relative scaling 
> between these two versions?
> Regards
> K Z
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

1.0 for floats and (1 << 15) for shorts should map to the full-scale of
the ADC/DAC.
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1io__type__t.html

-Josh

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

Re: [Discuss-gnuradio] How to implement TDMA

[Josh Blum]

On 10/14/2011 04:46 AM, qaz wsx wrote:
> Hi,
> 
> I am planning to move from CSMA to TDMA. Can anyone help me get directions
> where to start. I saw that mblock are no more available, and instead 'stream
> tags' are
> used. I don't have knownledge of the underlying structure. 

The gr-uhd sink block can use tags to precisely control timed bursts.
See gr-uhd/examples/tags_demo.cc for an example

_josh

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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Tom Rondeau]

On Fri, Oct 14, 2011 at 7:47 AM, John Ackermann N8UR  wrote:

> Marcus D. Leech said the following on 10/13/2011 09:18 PM:
>
>  On 10/13/2011 09:11 PM, John Ackermann N8UR wrote:
>>
>>> Is there a (hopefully simple) example of using the polyphase
>>> channelizer block in grc?
>>>
>>> I'm trying to do a simple case of dividing a 250 kHz wide stream from
>>> USRP into a small number (initially 4) of contiguous channels. Given
>>> my generally ignorant status, I'm stumped on setting the parameters.
>>>
>> [ snip ]
>
>
>  If it's only 250Khz wide, and you only need four, have you tried 4
>> discrete freq-xlating FIR filters? They're fairly easy to use, and can
>> produce a baseband output at a decimated rate.
>>
>
> I'm starting with 4, but if my harebrained scheme works, want to increase
> to whatever the CPU will allow.
>
> I've attached a screenshot of my test flowgraph.  It's a linear translator
> that takes a chunk of spectrum down to baseband, then retransmits it on a
> different frequency range -- similar to what the amateur satellites do.
>
> What I'm playing with is whether I can improve the transmit efficiency by
> dividing the passband into multiple, independently squelched channels so
> that I'm not amplifying and retransmitting noise where there is no real
> signal present.  For best results, you'd want to have many channels (and
> possibly some means to select adjacent channels), but to start with 4 is
> enough to see whether this idea makes any sense at all.
>
> John
>
>
>  I haven't yet figured out how to use the polyphase channelizer because I
>> almost never have the N equi-spaced channels problem in
>> my fields of interest. So, discrete filters it is (sometimes a hierarchy
>> of discrete filters).
>
>

John,
You've almost got it right except for the taps. The "taps" parameter is the
FIR taps of the prototype filter, which then gets partitioned among the N
channels of the channelizer.

While there is no example in GRC readily available, you can look at the
channelize.py example in:  gnuradio-examples/python/pfb/

Specifically, line 49 is where the filter taps are created. Notice that the
sample rate is the sample rate at the input to the channelizer while the
bandwidth and transition width are defined for the channel bandwidths. This
makes a fairly long filter that is then split up between the N channels of
the PFB.

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

Re: [Discuss-gnuradio] gr_file_sink error handling and incorrect behavior on broken pipes

[Tom Rondeau]

On Fri, Oct 14, 2011 at 1:13 AM, Achilleas Anastasopoulos  wrote:

> This relates to a previous post regarding the behavior of gr_file_sink
> when it writes to a named pipe and the other side of the pipe stops
> reading.
>
> Currently the bahavior of the block is that it does not catch the
> "errno=32=EPIPE"
> (or any errno!=0 for that matter)
> and thus the work function returns a false number of consumed items
> (for some reason even with a broken pipe it always returns 512 items
> consumed...)
>
> As a result the remaing graph keeps producing samples that are somehow
> falsely
> consumed into the file sink.
>
> I added a couple of lines to check for the errno!=0
>
> Please check and comment.
> I attach 2 python files to check the bahavior of the file sink.
> Firtst do " mkfifo fifo_rx" and then run tx.py and rx.py in different
> shells.
> You can stop start rx.py any number of times and tx.py pauses and
> restarts as well.
>
> Observe though that tx.py consumes cpu even when the pipe is broken
> because it continuosly calls
> the gr_file_sink work function...
>
> Achilleas
>


Achilleas,

I have created ticket #448 about this issue. The basic mechanism of your
patch looks correct, but it's worth having a discussion about the extent of
the errors checked and the behavior when an error occurs. I will add this to
the list of topics to discuss during our next developers' conference call
(next Thursday).

Thanks!
Tom



> ==
>
> diff --git a/gnuradio-core/src/lib/io/gr_file_sink.cc
> b/gnuradio-core/src/lib/io/gr_file_sink.cc
> index aab0158..52d4c84 100644
> --- a/gnuradio-core/src/lib/io/gr_file_sink.cc
> +++ b/gnuradio-core/src/lib/io/gr_file_sink.cc
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>
>  gr_file_sink_sptr
> @@ -64,9 +66,16 @@ gr_file_sink::work (int noutput_items,
> return noutput_items;  // drop output on the floor
>
>   while (nwritten < noutput_items){
> +errno=0;
> int count = fwrite (inbuf, d_itemsize, noutput_items - nwritten, d_fp);
> -if (count == 0)// FIXME add error handling
> +if (count == EOF){ // FIXME add error handling
> +  //printf("fwrite() returned EOF. Requested %d and wrote
> %d\n",noutput_items - nwritten,count);
>   break;
> +}
> +if (errno!=0){ // FIXME add error handling
> +  //printf("fwrite() raised error no = %d. Requested %d and wrote
> %d\n",errno,noutput_items - nwritten,count);
> +  break;
> +}
> nwritten += count;
> inbuf += count * d_itemsize;
>   }
>
> ___
> 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] New webpage look

[Tom Rondeau]

On Fri, Oct 14, 2011 at 12:26 AM, adeel anwar  wrote:

> i think josh is right about the color. Instead of red, some shade of blue
> or green might give a better look.
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki
>
> instead of putting "Start page", "Index by Title", "Index by Date" buttons
> on right-side,
> they may be placed on the top of start page (maybe beside "History").
> This may be useful for people new to gnuradio website (initially for 2
> weeks, i thought that "start page" is the only wiki)
>
>
Ok, so to protect people from bleeding from any part of their body while
viewing the webpage, I have toned the red down a notch. But seriously, if
the webpage is causing you physical pain to look at, perhaps the brightness
of your monitor is turned up a bit too high.

So the Forces of Brightness won out for me when redoing the color scheme
specifically to get away from the drab blue and greens of the Earthtone
Coalition. I think the new colors make the site more alive and pop as
opposed to what I think was a pretty dull, boring site of blues.

The redish-orange color was taken from the GNU Radio icon that we've added
to the top of the page. Originally, I think we had the wrong value for it,
which gave that brighter red (#C82F1F), but I replaced the main banner with
what GIMP tells me is the real color from the icon, which is #C8. It
calms it down a bit, and I just replaced the link colors with this scheme
instead of the brighter scheme.

Using the redish-orange for the banner and blue for the links would clash, I
think. I mean, come on, orange and blue? What is this, UVA? (inside
joke/rivalry; I went to VA Tech.)

I'm definitely willing to entertain other suggestions for colors if most
people are finding this to be a real problem, but I'd really rather not go
back to boring old blue like we used to have.

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

Re: [Discuss-gnuradio] New webpage look

[Marcus D. Leech]

On 14/10/2011 12:22 PM, Tom Rondeau wrote:



Ok, so to protect people from bleeding from any part of their body 
while viewing the webpage, I have toned the red down a notch. But 
seriously, if the webpage is causing you physical pain to look at, 
perhaps the brightness of your monitor is turned up a bit too high.


So the Forces of Brightness won out for me when redoing the color 
scheme specifically to get away from the drab blue and greens of the 
Earthtone Coalition. I think the new colors make the site more alive 
and pop as opposed to what I think was a pretty dull, boring site of 
blues.


The redish-orange color was taken from the GNU Radio icon that we've 
added to the top of the page. Originally, I think we had the wrong 
value for it, which gave that brighter red (#C82F1F), but I replaced 
the main banner with what GIMP tells me is the real color from the 
icon, which is #C8. It calms it down a bit, and I just replaced 
the link colors with this scheme instead of the brighter scheme.


Using the redish-orange for the banner and blue for the links would 
clash, I think. I mean, come on, orange and blue? What is this, UVA? 
(inside joke/rivalry; I went to VA Tech.)


I'm definitely willing to entertain other suggestions for colors if 
most people are finding this to be a real problem, but I'd really 
rather not go back to boring old blue like we used to have.


Tom

Something I've learned in over 30 years of doing computer stuff, 
including UI design.  When it comes to UI decisions, including colours,
  layout, etc, you'll *never*, *ever* make everyone happy.  It's not 
possible.  The reason they call "personal taste" personal, is that, well,

  it's personal :-)




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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Marcus D. Leech]

On 14/10/2011 12:01 PM, Tom Rondeau wrote:


You've almost got it right except for the taps. The "taps" parameter 
is the FIR taps of the prototype filter, which then gets partitioned 
among the N channels of the channelizer.


While there is no example in GRC readily available, you can look at 
the channelize.py example in:  gnuradio-examples/python/pfb/


Specifically, line 49 is where the filter taps are created. Notice 
that the sample rate is the sample rate at the input to the 
channelizer while the bandwidth and transition width are defined for 
the channel bandwidths. This makes a fairly long filter that is then 
split up between the N channels of the PFB.


Tom

I have to wonder, though, John, whether your "scheme" for saving power 
in a linear transponder is actually going to be workable.


Yes, you'll squelch the "no signal" channels going into the transponder, 
but that is only the difference between the received Tsys over
  the filter bandwidth and the inherent noise power of the transmitter 
itself.





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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[John Ackermann N8UR]

Tom Rondeau said the following on 10/14/2011 12:01 PM:


John,
You've almost got it right except for the taps. The "taps" parameter is
the FIR taps of the prototype filter, which then gets partitioned among
the N channels of the channelizer.

While there is no example in GRC readily available, you can look at the
channelize.py example in:  gnuradio-examples/python/pfb/

Specifically, line 49 is where the filter taps are created. Notice that
the sample rate is the sample rate at the input to the channelizer while
the bandwidth and transition width are defined for the channel
bandwidths. This makes a fairly long filter that is then split up
between the N channels of the PFB.


Thanks, Tom.  So it appears that you use a firdes.lowpass type function 
in the taps setting.  I've done that and I now get somewhat more sane 
results on the output FFT.


However, I'm still seeing massive underruns when I assume the same 
sample rate as the input.  Is there a decimation going on (i.e., 
output_rate = input_rate/num_channels or something like that)?


John

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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[John Ackermann N8UR]

Marcus D. Leech said the following on 10/14/2011 12:32 PM:


I have to wonder, though, John, whether your "scheme" for saving power
in a linear transponder is actually going to be workable.

Yes, you'll squelch the "no signal" channels going into the transponder,
but that is only the difference between the received Tsys over
the filter bandwidth and the inherent noise power of the transmitter
itself.


It may not work to actually improve power efficiency, but another goal 
is to just make it sound better by not raising the background level 
across the whole output spectrum where there is no signal present.  By 
the time you add 40 or 50 dB gain at baseband, the amplified noise at 
the transmitter is pretty noticeable.


This is all just an experiment to see what can be done, and to learn 
some GRC in the process. :-)


John

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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Marcus D. Leech]

On 14/10/2011 1:06 PM, John Ackermann N8UR wrote:


It may not work to actually improve power efficiency, but another goal 
is to just make it sound better by not raising the background level 
across the whole output spectrum where there is no signal present.  By 
the time you add 40 or 50 dB gain at baseband, the amplified noise at 
the transmitter is pretty noticeable.


This is all just an experiment to see what can be done, and to learn 
some GRC in the process. :-)


John

Yup, I understand.  The question is what fraction of delivered noise in 
the absence of an actual signal is internally-generated in the transmitter,
  which fraction isn't.  But some of this problem (if you're not 
interested in TX power efficiency) should be dealt with by the receiver.


Interesting experiment.


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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Marcus D. Leech]

On 14/10/2011 12:53 PM, John Ackermann N8UR wrote:
Thanks, Tom.  So it appears that you use a firdes.lowpass type 
function in the taps setting.  I've done that and I now get somewhat 
more sane results on the output FFT.


However, I'm still seeing massive underruns when I assume the same 
sample rate as the input.  Is there a decimation going on (i.e., 
output_rate = input_rate/num_channels or something like that)?


John

Doesn't the PFB channelizer down-sample as well?   So your output sample 
rates from the channelizer will be mis-matched to the

  UHD USRP sink?




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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[John Ackermann N8UR]

Marcus D. Leech said the following on 10/14/2011 01:18 PM:

On 14/10/2011 12:53 PM, John Ackermann N8UR wrote:



Doesn't the PFB channelizer down-sample as well? So your output sample
rates from the channelizer will be mis-matched to the
UHD USRP sink?


That's what I'm trying to figure out.  A 4x interpolator doesn't seem to 
help, though.  I'm not sure if the "oversample" parameter in the 
channelizer might act as an interpolator, or if that provides some other 
function.


John

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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Tom Rondeau]

On Fri, Oct 14, 2011 at 1:42 PM, John Ackermann N8UR  wrote:

> Marcus D. Leech said the following on 10/14/2011 01:18 PM:
>
>  On 14/10/2011 12:53 PM, John Ackermann N8UR wrote:
>>
>
>  Doesn't the PFB channelizer down-sample as well? So your output sample
>> rates from the channelizer will be mis-matched to the
>> UHD USRP sink?
>>
>
> That's what I'm trying to figure out.  A 4x interpolator doesn't seem to
> help, though.  I'm not sure if the "oversample" parameter in the channelizer
> might act as an interpolator, or if that provides some other function.
>
> John
>

The oversample parameter is to make the outputs have some n samples/channel.
By default, it's 1, so the output sample rate of each channel is fs_in/M for
M channels; this is also the bandwidth (the signal is critically sampled).
If you have n=2, then the sample rate of each channel is 2*fs_in/M, but your
bandwidth is still fs_in/M. So you shouldn' need to worry about the
oversample rate.

So, yes, the channels are downsampled by a factor of M.

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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Marcus D. Leech]

On 14/10/2011 1:42 PM, John Ackermann N8UR wrote:

Marcus D. Leech said the following on 10/14/2011 01:18 PM:

On 14/10/2011 12:53 PM, John Ackermann N8UR wrote:



Doesn't the PFB channelizer down-sample as well? So your output sample
rates from the channelizer will be mis-matched to the
UHD USRP sink?


That's what I'm trying to figure out.  A 4x interpolator doesn't seem 
to help, though.  I'm not sure if the "oversample" parameter in the 
channelizer might act as an interpolator, or if that provides some 
other function.


John

Also, looking at your flow-graph, all of the channels are effectively at 
baseband, so if you have two or more channels come up at the same

  time, they'll collide--was that the intent?

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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Marcus D. Leech]

On 14/10/2011 1:42 PM, John Ackermann N8UR wrote:


That's what I'm trying to figure out.  A 4x interpolator doesn't seem 
to help, though.  I'm not sure if the "oversample" parameter in the 
channelizer might act as an interpolator, or if that provides some 
other function.


John

Keep in mind that the fractional interpolator, if that's what you're 
using, uses the *inverse* for the interp ratio.  So if you needed an
   interp ratio of 4, you'd specify (1/4).  That's because is can be 
used for decimation as well, and so the ratio is expressed as a decimation

   ratio.



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

Re: [Discuss-gnuradio] Generating orthogonal PN sequences in GRC

[Achilleas Anastasopoulos]

A PN sequence can be generated by a Finite State Machine (FSM).

You can use the block gr_trellis_encoder and feed it with 0's at the 
input in order to generate the PN sequence.

The only think you need to provide to it is a description of the FSM
(at this point we do not have a constructor that takes directly the
feedback polynomial and constructs the next state and output tables).

See the trellis documentation for details...

Achilleas

PS: now i see that we can generalize the trellis_encoder block to be 
used also as a block with 0 inputs, ie, emulating an all-0 input sequence...


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

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[John Ackermann N8UR]

On Oct 14, 2011, at 1:51 PM, "Marcus D. Leech"  wrote:

>> 
>> 
>> Also, looking at your flow-graph, all of the channels are effectively at 
>> baseband, so if you have two or more channels come up at the same
>  time, they'll collide--was that the intent?

No, I was afraid that might be the case but wasn't sure (and was hoping not).  
I'll have to add a multiplier on each channel to provide an offset.  Too bad 
there isn't a polyphase dechannelizer. :-).
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Polyphase Channelizer examples?

[Tom Rondeau]

On Fri, Oct 14, 2011 at 2:04 PM, John Ackermann N8UR  wrote:

>
>
> On Oct 14, 2011, at 1:51 PM, "Marcus D. Leech"  wrote:
>
> >>
> >>
> >> Also, looking at your flow-graph, all of the channels are effectively at
> baseband, so if you have two or more channels come up at the same
> >  time, they'll collide--was that the intent?
>
> No, I was afraid that might be the case but wasn't sure (and was hoping
> not).  I'll have to add a multiplier on each channel to provide an offset.
>  Too bad there isn't a polyphase dechannelizer. :-).


It's called the polyphase synthesis filter :)

gr_pfb_synthesis_filterbank_ccf.

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

Re: [Discuss-gnuradio] [USRP-users] Add trailer

[Nick Foster]

1. For Gnuradio-related questions, use the Gnuradio mailing list.

2. Gnuradio knows nothing about packets. Do you mean one of the
specific example programs included with Gnuradio?

--n

On Fri, Oct 14, 2011 at 11:30 AM, zhe yang  wrote:
> Hi, List Buddies,
> How does gnuradio detect the end of a packet? By trailer or something else
> as I haven't found the code that adds trailer to packet. Thanks.
> Best wishes,
> yours YANG, Zhe
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>

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

[Discuss-gnuradio] compile error

[Stefano Sinagra]

Hi,
I'm stuck compiling gnuradio here.
Any hint?
I tried both using the script and by hand (bootstrap etc.)
Thanks
Stefano IZ0MJE


libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../..
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/runtime
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/general
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/general
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/gengen
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/gengen
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/filter
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/filter
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/missing
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/reed-solomon
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/viterbi
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/io
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/g72x
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/swig
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/hier
-I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/swig
-I/home/sinager/gnuradio-3.4.1/gruel/src/include
-I/home/sinager/gnuradio-3.4.1/gruel/src/include -I/usr/include
-I/usr/include/python2.6 -I/usr/local/include
-I/usr/include/libusb-1.0
-I/home/sinager/gnuradio-3.4.1/gr-uhd/include -g -O1
-Wno-strict-aliasing -Wno-parentheses -I../.. -pthread -MT
_uhd_swig_la-uhd_swig.lo -MD -MP -MF .deps/_uhd_swig_la-uhd_swig.Tpo
-c python/uhd_swig.cc  -fPIC -DPIC -o .libs/_uhd_swig_la-uhd_swig.o
python/uhd_swig.cc: In function ‘PyObject*
_wrap_uart_iface_write_uart(PyObject*, PyObject*, PyObject*)’:
python/uhd_swig.cc:18635: error: no matching function for call to
‘uhd::uart_iface::write_uart(uint8_t&, const std::basic_string, std::allocator >&)’
/usr/local/include/uhd/types/serial.hpp:189: note: candidates are:
virtual void uhd::uart_iface::write_uart(const std::string&)
make[5]: *** [_uhd_swig_la-uhd_swig.lo] Errore 1
make[5]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd/swig»
make[4]: *** [all] Errore 2
make[4]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd/swig»
make[3]: *** [all-recursive] Errore 1
make[3]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd»
make[2]: *** [all] Errore 2
make[2]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd»
make[1]: *** [all-recursive] Errore 1
make[1]: uscita dalla directory «/home/sinager/gnuradio-3.4.1»
make: *** [all] Errore 2
sinager@SIRAD:~/gnuradio-3.4.1$

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

Re: [Discuss-gnuradio] compile error

[Josh Blum]

On 10/14/2011 12:32 PM, Stefano Sinagra wrote:
> Hi,
> I'm stuck compiling gnuradio here.
> Any hint?
> I tried both using the script and by hand (bootstrap etc.)
> Thanks
> Stefano IZ0MJE
> 

I think its not regenerating the swig. Try cleaning gr-uhd first.

-josh

> 
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../..
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/runtime
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/general
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/general
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/gengen
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/gengen
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/filter
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/filter
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/missing
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/reed-solomon
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/viterbi
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/io
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/g72x
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/swig
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/hier
> -I/home/sinager/gnuradio-3.4.1/gnuradio-core/src/lib/swig
> -I/home/sinager/gnuradio-3.4.1/gruel/src/include
> -I/home/sinager/gnuradio-3.4.1/gruel/src/include -I/usr/include
> -I/usr/include/python2.6 -I/usr/local/include
> -I/usr/include/libusb-1.0
> -I/home/sinager/gnuradio-3.4.1/gr-uhd/include -g -O1
> -Wno-strict-aliasing -Wno-parentheses -I../.. -pthread -MT
> _uhd_swig_la-uhd_swig.lo -MD -MP -MF .deps/_uhd_swig_la-uhd_swig.Tpo
> -c python/uhd_swig.cc  -fPIC -DPIC -o .libs/_uhd_swig_la-uhd_swig.o
> python/uhd_swig.cc: In function ‘PyObject*
> _wrap_uart_iface_write_uart(PyObject*, PyObject*, PyObject*)’:
> python/uhd_swig.cc:18635: error: no matching function for call to
> ‘uhd::uart_iface::write_uart(uint8_t&, const std::basic_string std::char_traits, std::allocator >&)’
> /usr/local/include/uhd/types/serial.hpp:189: note: candidates are:
> virtual void uhd::uart_iface::write_uart(const std::string&)
> make[5]: *** [_uhd_swig_la-uhd_swig.lo] Errore 1
> make[5]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd/swig»
> make[4]: *** [all] Errore 2
> make[4]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd/swig»
> make[3]: *** [all-recursive] Errore 1
> make[3]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd»
> make[2]: *** [all] Errore 2
> make[2]: uscita dalla directory «/home/sinager/gnuradio-3.4.1/gr-uhd»
> make[1]: *** [all-recursive] Errore 1
> make[1]: uscita dalla directory «/home/sinager/gnuradio-3.4.1»
> make: *** [all] Errore 2
> sinager@SIRAD:~/gnuradio-3.4.1$
> 
> ___
> 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] UHD Python API?

[Nowlan, Sean]

I'm not clear on this... if it's in the UHD C++ API, does that automatically 
mean it's available in the Python API through SWIG? The C++ API is fairly well 
documented but I haven't found a good Python API reference.

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

Re: [Discuss-gnuradio] UHD Python API?

[Josh Blum]

On 10/14/2011 02:53 PM, Nowlan, Sean wrote:
> I'm not clear on this... if it's in the UHD C++ API, does that
> automatically mean it's available in the Python API through SWIG? The
> C++ API is fairly well documented but I haven't found a good Python
> API reference.
> 

The API for the gr-uhd source and sink blocks is "swigged" into python.
Any calls you see in the source and sink header files will also be
available in python. You may want to start by generating some flow
graphs in grc and looking at the generated python code.

-josh

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

Re: [Discuss-gnuradio] UHD Python API?

[Nowlan, Sean]

Thanks for your response. I've done that, but if want to do something fancier 
like printing out daughterboard ID and device address, can I use "swigged" C++ 
calls?

-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Josh Blum
Sent: Friday, October 14, 2011 5:56 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Python API?



On 10/14/2011 02:53 PM, Nowlan, Sean wrote:
> I'm not clear on this... if it's in the UHD C++ API, does that 
> automatically mean it's available in the Python API through SWIG? The
> C++ API is fairly well documented but I haven't found a good Python
> API reference.
> 

The API for the gr-uhd source and sink blocks is "swigged" into python.
Any calls you see in the source and sink header files will also be available in 
python. You may want to start by generating some flow graphs in grc and looking 
at the generated python code.

-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] UHD Python API?

[Nowlan, Sean]

Can I use the following to get a pointer to the object instance and then access 
the C++ public get/set methods? Or does SWIG not dig that deep?

virtual uhd::usrp::dboard_iface::sptr get_dboard_iface(size_t chan = 0) = 0;
virtual uhd::usrp::multi_usrp::sptr get_device(void) = 0;

Sean

-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Nowlan, Sean
Sent: Friday, October 14, 2011 6:01 PM
To: j...@ettus.com; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Python API?

Thanks for your response. I've done that, but if want to do something fancier 
like printing out daughterboard ID and device address, can I use "swigged" C++ 
calls?

-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Josh Blum
Sent: Friday, October 14, 2011 5:56 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Python API?



On 10/14/2011 02:53 PM, Nowlan, Sean wrote:
> I'm not clear on this... if it's in the UHD C++ API, does that 
> automatically mean it's available in the Python API through SWIG? The
> C++ API is fairly well documented but I haven't found a good Python
> API reference.
> 

The API for the gr-uhd source and sink blocks is "swigged" into python.
Any calls you see in the source and sink header files will also be available in 
python. You may want to start by generating some flow graphs in grc and looking 
at the generated python code.

-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] UHD Python API?

[Josh Blum]

On 10/14/2011 03:04 PM, Nowlan, Sean wrote:
> Can I use the following to get a pointer to the object instance and then 
> access the C++ public get/set methods? Or does SWIG not dig that deep?
> 

Swig digs as deep as you tell it to. See uhd_swig.i, each header you
want to access stuff with needs a %include.

Keep in mind that that often means you need to add more %template and
other stuff. Swig is a picky beast, I have spent many hours trying to
appease it.

> virtual uhd::usrp::dboard_iface::sptr get_dboard_iface(size_t chan = 0) = 0;

This has been swigged

> virtual uhd::usrp::multi_usrp::sptr get_device(void) = 0;
> 

This has not, %include "uhd/usrp/multi_usrp.hpp" may do the trick for
most of the calls you want.

-josh

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

Re: [Discuss-gnuradio] UHD Python API?

[Nowlan, Sean]

I'm just trying to match old USRP driver functionality in some of the 
gnuradio-examples, which probably requires additional SWIGging. Does that sound 
about right?

-Original Message-
From: Josh Blum [mailto:j...@joshknows.com] On Behalf Of Josh Blum
Sent: Friday, October 14, 2011 6:09 PM
To: Nowlan, Sean
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Python API?



On 10/14/2011 03:04 PM, Nowlan, Sean wrote:
> Can I use the following to get a pointer to the object instance and then 
> access the C++ public get/set methods? Or does SWIG not dig that deep?
> 

Swig digs as deep as you tell it to. See uhd_swig.i, each header you want to 
access stuff with needs a %include.

Keep in mind that that often means you need to add more %template and other 
stuff. Swig is a picky beast, I have spent many hours trying to appease it.

> virtual uhd::usrp::dboard_iface::sptr get_dboard_iface(size_t chan = 
> 0) = 0;

This has been swigged

> virtual uhd::usrp::multi_usrp::sptr get_device(void) = 0;
> 

This has not, %include "uhd/usrp/multi_usrp.hpp" may do the trick for most of 
the calls you want.

-josh

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

[Discuss-gnuradio] building issues of 3.4.1 on Ubuntu Oneiric 11.10 - 32 bit

[Arturo Rinaldi]

I don't want to be "the guy" bothering you about building issues of 
gnuradio every time :D, but experienced again building problems from the 
3.4.1 source tarball with the latest ubuntu distro. I installed the 
dependencies as reported in the SBRAC script :


/sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev 
swig g++ \

automake autoconf libtool python-dev libfftw3-dev \
libcppunit-dev libboost-all-dev libusb-dev libusb-1.0-0-dev fort77 sdcc 
sdcc-libraries \

libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \
libqt4-dev python-numpy ccache python-opengl libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 \
cmake git-core wget sdcc libxi-dev/

then built from source the uhd images from the latest "tar.gz" from UHD 
website with


/cmake -DCPACK_GENERATOR=DEB -DENABLE_USRP_E_UTILS=ON -DENABLE_E100=ON  ..//

then :

/./configure
make

/as usual, the errors are reported in a text file

thanks in advance ;)
make[6]: uscita dalla directory 
"/home/artynet/Scrivania/gnuradio-3.4.1/usrp2/firmware"
make[5]: uscita dalla directory 
"/home/artynet/Scrivania/gnuradio-3.4.1/usrp2/firmware"
make[4]: uscita dalla directory 
"/home/artynet/Scrivania/gnuradio-3.4.1/usrp2/firmware"
make[4]: ingresso nella directory "/home/artynet/Scrivania/gnuradio-3.4.1/usrp2"
make[4]: Nessuna operazione da eseguire per "all-am".
make[4]: uscita dalla directory "/home/artynet/Scrivania/gnuradio-3.4.1/usrp2"
make[3]: uscita dalla directory "/home/artynet/Scrivania/gnuradio-3.4.1/usrp2"
make[2]: uscita dalla directory "/home/artynet/Scrivania/gnuradio-3.4.1/usrp2"
Making all in gr-usrp
make[2]: ingresso nella directory 
"/home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp"
make  all-recursive
make[3]: ingresso nella directory 
"/home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp"
Making all in src
make[4]: ingresso nella directory 
"/home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp/src"
Compile .i to .py
/usr/bin/swig -c++ -fvirtual -python -modern -keyword -w511 -outdir .  
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/runtime 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/missing 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/reed-solomon 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/viterbi 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/io 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/g72x 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/swig 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/hier 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/swig 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gruel/src/include 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gruel/src/include  -I/usr/include   
-I. -I../.. -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include  
-I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include  
-I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/firmware/include \
-MD -MF python/usrp_swig.Std \
-module usrp_swig -o python/usrp_swig.cc -oh python/usrp_swig.h 
usrp_swig.i
/bin/sed -e 's|python/\(.*\)\.cc:|\1.py:|' python/usrp_swig.Std > 
python/usrp_swig.d
/bin/rm -f python/usrp_swig.Std
make  all-am
make[5]: ingresso nella directory 
"/home/artynet/Scrivania/gnuradio-3.4.1/gr-usrp/src"
/bin/bash ../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. 
-I../..  -I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include  
-I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/host/include  
-I/home/artynet/Scrivania/gnuradio-3.4.1/usrp/firmware/include  
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/runtime 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/general 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/gengen 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/filter 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/missing 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/reed-solomon 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/viterbi 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-core/src/lib/io 
-I/home/artynet/Scrivania/gnuradio-3.4.1/gnuradio-

Re: [Discuss-gnuradio] building issues of 3.4.1 on Ubuntu Oneiric 11.10 - 32 bit

[Arturo Rinaldi]

Nella citazione in data sab 15 ott 2011 01:46:48 CEST, Ben Hilburn ha 
scritto:

Arturo -

Looks like some boost errors.  What version of boost is installed on 
your system?  Also, will you make sure that the libboost_system and 
libboost_filesystem libraries are installed?  A quick:


$ sudo updatedb
$ locate libboost | grep system

... ought to reveal the answer.

If there are incompatibilities in the newest version of boost shipping 
on Ubuntu, we'll need to take care of that quickly.


Cheers,
Ben


On Fri, Oct 14, 2011 at 4:35 PM, Arturo Rinaldi > wrote:


I don't want to be "the guy" bothering you about building issues
of gnuradio every time :D, but experienced again building problems
from the 3.4.1 source tarball with the latest ubuntu distro. I
installed the dependencies as reported in the SBRAC script :

/sudo apt-get -y install libfontconfig1-dev libxrender-dev
libpulse-dev swig g++ \
automake autoconf libtool python-dev libfftw3-dev \
libcppunit-dev libboost-all-dev libusb-dev libusb-1.0-0-dev fort77
sdcc sdcc-libraries \
libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \
libqt4-dev python-numpy ccache python-opengl libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 \
cmake git-core wget sdcc libxi-dev/

then built from source the uhd images from the latest "tar.gz"
from UHD website with

/cmake -DCPACK_GENERATOR=DEB -DENABLE_USRP_E_UTILS=ON
-DENABLE_E100=ON  ..//

then :

/./configure
make

/as usual, the errors are reported in a text file

thanks in advance ;)

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


i'll let you know as soon as possible.i'm doing a new virtual 
machine with amd64 architecture. Stay Tuned :D



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

Re: [Discuss-gnuradio] building issues of 3.4.1 on Ubuntu Oneiric 11.10 - 32 bit

[Arturo Rinaldi]

Nella citazione in data sab 15 ott 2011 01:56:04 CEST, Arturo Rinaldi ha 
scritto:


Nella citazione in data sab 15 ott 2011 01:46:48 CEST, Ben Hilburn ha
scritto:


Arturo -

Looks like some boost errors. What version of boost is installed on
your system? Also, will you make sure that the libboost_system and
libboost_filesystem libraries are installed? A quick:

$ sudo updatedb
$ locate libboost | grep system

... ought to reveal the answer.

If there are incompatibilities in the newest version of boost
shipping on Ubuntu, we'll need to take care of that quickly.

Cheers,
Ben


On Fri, Oct 14, 2011 at 4:35 PM, Arturo Rinaldi mailto:arty.n...@gmail.com>> wrote:

I don't want to be "the guy" bothering you about building issues
of gnuradio every time :D, but experienced again building problems
from the 3.4.1 source tarball with the latest ubuntu distro. I
installed the dependencies as reported in the SBRAC script :

/sudo apt-get -y install libfontconfig1-dev libxrender-dev
libpulse-dev swig g++ \
automake autoconf libtool python-dev libfftw3-dev \
libcppunit-dev libboost-all-dev libusb-dev libusb-1.0-0-dev fort77
sdcc sdcc-libraries \
libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \
libqt4-dev python-numpy ccache python-opengl libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools python-qwt5-qt4 \
cmake git-core wget sdcc libxi-dev/

then built from source the uhd images from the latest "tar.gz"
from UHD website with

/cmake -DCPACK_GENERATOR=DEB -DENABLE_USRP_E_UTILS=ON
-DENABLE_E100=ON ..//

then :

/./configure
make

/as usual, the errors are reported in a text file

thanks in advance ;)

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




i'll let you know as soon as possible.i'm doing a new virtual
machine with amd64 architecture. Stay Tuned :D

here it is, the version is 1.46. the 1.42 version is also present in the 
repositories, but 11.10 installs 1.46 by default..


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

[Discuss-gnuradio] Ben's docstring work

[Tom Rondeau]

I've been doing a lot of work lately on the in-code documentation, and I've
finally gotten around to working with Ben Reynwar's docstring work to insert
the Doxygen docstrings into Python. This results in us being able call
help(gr.something) and get the full documentation that's available in the
header file. I've made a few changes, such as moving the meat of the code
into the docs directory and a few other minor things, and it's now in a
branch 'docstrings' available at:

git://github.com/trondeau/gnuradio.git

This branch has also been updated to the latest in next.

The issue that I wanted to bring up here is that the process for doing this
is not quite automatic, though it's _mostly_ automatic. The problem is that
the docs directory is processed last (and has to be), so the output XML
files that are parsed are not available until after the build is done. This
means that you have to build once, run the swig_doc.py file to generate a
SWIG file from the XML files, then rebuild the entire project to insert the
documentation into Python.

The good news is that the .i file is kept in git and is part of the project,
so it's as relevant as the last time someone checked it in. So for the most
part, you don't really have to worry about this process unless you are
changing documentation in the code. The bad part is that if you are working
on the documentation, you have to remember to update this periodically.

I think that the benefits of this outweigh the negatives, and I'm about
ready to put this into our next branch so it will be a part of 3.5. But I
wanted to give people some time to look over the process and suggest
possible modifications that might make things work more smoothly or even
integrated into the regular build process.

Here's the information that I put into a README.doxyxml file for the
instructions to produce the docstrings:

===
The process of updating and exporting the Doxygen document strings
into Python consists of a few steps.

1. Make sure the 'docs' component will be built, which requires
Doxygen.

2. Build the project like normal, which will run Doxygen and store the
   XML files into $(top_builddir).

3. In $(top_srcdir)/docs/doxygen, run the command:

   $ python swig_doc.py \
 $(top_builddir)/docstrings/docs/doxygen/xml \
 $(top_srcdir)/gnuradio-core/src/lib/swig/swig_doc.i

   This uses the XML output of Doxygen to to rebuild a SWIG file that
   contains all of the current Doxygen markups.

4. Rebuild the GNU Radio libraries. Since gnuradio.i is included in
   all of the GNU Radio components, and gnuradio.i includes
   swig_doc.i, when the libraries are rebuilt, they will now include
   the documentation strings in Python.

5. Install GNU Radio. Now, when you run help() in Python on a GNU
   Radio block, you will get the full documentation.
===

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

Re: [Discuss-gnuradio] Ben's docstring work

[Josh Blum]

On 10/14/2011 07:44 PM, Tom Rondeau wrote:
> I've been doing a lot of work lately on the in-code documentation, and I've
> finally gotten around to working with Ben Reynwar's docstring work to insert
> the Doxygen docstrings into Python. This results in us being able call
> help(gr.something) and get the full documentation that's available in the
> header file. I've made a few changes, such as moving the meat of the code
> into the docs directory and a few other minor things, and it's now in a
> branch 'docstrings' available at:
> 
> git://github.com/trondeau/gnuradio.git
> 
> This branch has also been updated to the latest in next.
> 
> The issue that I wanted to bring up here is that the process for doing this
> is not quite automatic, though it's _mostly_ automatic. The problem is that
> the docs directory is processed last (and has to be), so the output XML
> files that are parsed are not available until after the build is done. This
> means that you have to build once, run the swig_doc.py file to generate a
> SWIG file from the XML files, then rebuild the entire project to insert the
> documentation into Python.
> 

So suppose it this way:

Currently the docs/doxygen component builds a monolithic html and xml
folder for the whole project. I suppose we may like the monolithic html
because it makes a nice index.html and other index-like stuff. But the
purpose of the xml has been primarily to extract documentation
information (like in grc).

So, perhaps we keep the docs/doxygen html generator and turn off the
xml. In place of the monolithic xml, we have a per-component set of
build rules that calls doxygen on the headers to generate xml, and a
build rule that calls swig_doc.py to generate swig_doc.i. Think of a
macro that takes a list of .h files and generates the appropriate build
rules for xml, and then xml -> swig_docs.i.

If the docs are accessible through python, we probably dont need grc to
parse the xml. Instead, it can find the component in python and query
its docs, hopefully by reading the module's docstrings (__doc__) if it
really works like that.

-Josh

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