[Discuss-gnuradio] USRP1 questions

[osama mohamed]

hi all,
i am using USRP1 with  basic tx and rx boards and i have been suffering some 
problems recently so i hope you could answer the following questions(even if 
not all of them)

Q1:
 when i run the examples tx_timed_samples.cpp and tx_burst.cpp i don't 
get any output i tried various sampling rates and amplitudes but they 
still didn't produce any output if there is a certain configuration 
(i.e. sampling rate and amplitude) that works kindly inform me also i 
would like to know the output i am expected to see?


Q2: i would like to tx a signal by setting the NCO frequency on the 
codec chip through the class codec_ctrl instead of using the PLL, is 
this doable or not and ,if yes should i use the class multi_usrp or i 
have to jump to the lower level class usrp1_impl?


Q3: can i use the low level class usrp1_impl to do the same 
functions of the examples   tx_timed_samples.cpp and tx_burst.cpp 
through setting the frequency tuning word of the codec through the class
 codec_ctrl ?


Q4: as i understand from the constructor of the class usrp1_impl  the 
sampling rates of the tx path are automatically detected and assigned 
through this constructor is this true or i have to set them through a 
certian function?

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

Re: [Discuss-gnuradio] Segmentation fault in wav file sink

[Martin Braun]

On Sun, Dec 11, 2011 at 01:18:59AM -0700, Matt Mills wrote:
> All,
> 
> The attached script crashes with a segmentation fault (or with the I/O error
> text in the code). My C++ knowledge is lacking however I believe this is
> because work() and close() are both being called simultaneously from different
> threads. The close() call is being made while the execution of work() is
> already past the "is this file handle working?" test (I think?).

Hi Matt,

a couple of things:

* Do you randomly get either segfault or i/o error? I always get the i/o
  with this code.
* Your code stresses the WAV-code a lot :) What are you trying to
  accomplish? Are you finding a bug in wavfile_sink or do you need this
  behaviour for something? Because you don't need close() if you just
  want to switch files.
* In any case, you're right. It's possible to call close() during work()
  after do_update() is finished and thus yank the fp out from under our
  feet. Actually, I can't think of any case where we need to call
  close() manually--perhaps it should even be private?

MB

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



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

Re: [Discuss-gnuradio] gr_firdes cutoff frequency

[Martin Braun]

Hi Songsong,

the cutoff frequency is relative to the given sampling rate, whatever
that is. The firdes stuff doesn't know about the "true" sampling rate.
It's not uncommon to set the sampling rate to 1 and then have cutoff
somewhere in between 0 and 1.

MB


On Mon, Dec 12, 2011 at 02:53:07PM +0900, Songsong Gee wrote:
> I'm looking benchmark program and now found use of gr.firdes.low_pass:
> 
> 
>         chan_coeffs = gr.firdes.low_pass (1.0,                  # gain
> 
>                                           sw_decim * 
> self.samples_per_symbol(),
> # sampling rate
> 
>                                           1.0,                  # cutoff
> frequency: midpoint of trans. band
> 
>                                           0.5,                  # width of
> trans. band
> 
>                                           gr.firdes.WIN_HANN)   # filter type
> 
> 
> I checked that low pass function in doxygen, and it says cutoff frequency has
> unit measure [Hz].
> 
> Recalling above expression, it says that cutoff frequency is 1.0 Hz
> 
> Is it right? Or is it a factor that is normalized to the sampling frequency?
> 
> 
> I'm asking about it because I want to use band_pass filter and I have no idea
> what value I have to choose for low/high cutoff frequency
> 
> 
> --
> 
> Seokseong Jeon, PhD Candidate
> 
> Communication & Networks Lab
> 
> IT Convergence Engineering (ITCE), POSTECH, Korea
> 
> +82 10 8338 1229, gee.songsong at gmail . com
> 
> 

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


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



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

Re: [Discuss-gnuradio] Segmentation fault in wav file sink

[Martin Braun]

On Sun, Dec 11, 2011 at 02:31:03PM -0500, Marcus D. Leech wrote:
> I think that what I'd do is cause the close() method to simply set a flag that
> says "close desired", and then do the actual close at the end of
>   the work function, probably under a mutex.

That sounds sensible. It could be done in do_update().

MB

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



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

[Discuss-gnuradio] FM transmitter

[MOHD RAFIQ]

Hi, is it possible to make gnuradio/usrp2/WBX & fedora 15, 
combination as FM transmitter to stream audio files as we can do in some smart 
phones. please help,if you  there is a grc/python file already, I have tried 
others on web but they dont work 
for my setup. I appreciate any comments, Thanks
rafiq
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] cmake errors on first attempt with master branch

[Justin Ford]

Are errors expected on the first attempt of cmake or could the errors indicate 
an underlying dependency issue?  I have other build issues and I'm trying to 
rule out all the possibilities.

When I first attempt cmake I get errors:

-- Using install prefix: /usr/local
-- Building for version: 3.5.1git-11-gfc6151d4 / 3.5.1git
-- Configuring incomplete, errors occurred!

If I simply run cmake again it finishes without complaint:

-- Using install prefix: /usr/local
-- Building for version: 3.5.1git-11-gfc6151d4 / 3.5.1git
-- Configuring done
-- Generating done
-- Build files have been written to: /home/gr/source/git/gnuradio/build

I'm working off the master branch (just pulled the latest, though I've seen 
this on each version I've used in the last week):

$ git status
# On branch master
nothing to commit (working directory clean)
[jrford@dodeca gnuradio]$ git show
commit fc6151d4516ee86b697602014b83fb08a88c30f0
Merge: 89f934b fa161e1
Author: Tom Rondeau 
Date:   Sun Dec 11 23:01:34 2011 -0500

    Merge remote-tracking branch 'jblum/cmake_qtgui_fix'

I'm on RHEL 5 x86_64:



$ cat /proc/version

Linux version 2.6.18-274.3.1.el5
(mockbu...@hs20-bc2-4.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat
4.1.2-51)) #1 SMP Fri Aug 26 18:49:02 EDT 2011

 

$ lsb_release -i -r

Distributor ID: RedHatEnterpriseClient

Release:    5.7
This is the command line I'm using with cmake (gotta point at the up to date 
versions of some dependencies instead of the RHEL built ins):cmake 
-DPYTHON_EXECUTABLE=/usr/bin/python26 -DBOOST_INCLUDEDIR=/usr/include/boost141 
-DBOOST_LIBRARYDIR=/usr/lib64/boost141 
-DSWIG_EXECUTABLE=/usr/share/swig/2.0.4/bin/swig ../
Thanks for any insight.
Justin


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

Re: [Discuss-gnuradio] cmake errors on first attempt with master branch

[Josh Blum]

On 12/12/2011 08:40 AM, Justin Ford wrote:
> 
> Are errors expected on the first attempt of cmake or could the errors 
> indicate an underlying dependency issue?  I have other build issues and I'm 
> trying to rule out all the possibilities.
> 
> When I first attempt cmake I get errors:
> 
> -- Using install prefix: /usr/local
> -- Building for version: 3.5.1git-11-gfc6151d4 / 3.5.1git
> -- Configuring incomplete, errors occurred!
> 

Cant tell. You gotta attach the whole verbose. -josh

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

[Discuss-gnuradio] Tis the season.. n210 on ebay scamed

[dave k]

what a nice holiday surprise
anyone else buy a n210 from seller "occupyonline" ? 
They sent a envelope with a CDROM of ubuntu and some paperwork on how to 
install!! 
I know it was a gamble as he had "0" feedback. It looked legit, and to get one 
for 1200$, with ebay buyer protection, I am not worried. Ebay will refund im 
sure.
anyone else get one from this Ahole ?


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

Re: [Discuss-gnuradio] Tis the season.. n210 on ebay scamed

[Matt Mills]

I saw him selling an N210 one week, then the next he was trying to sell an
N210 + some Micro ATX machine for 2400$; I figured it was a scam after that
one...

On Mon, Dec 12, 2011 at 9:59 AM, dave k  wrote:

> what a nice holiday surprise
> anyone else buy a n210 from seller "occupyonline" ?
> They sent a envelope with a CDROM of ubuntu and some paperwork on how to
> install!!
> I know it was a gamble as he had "0" feedback. It looked legit, and to get
> one for 1200$, with ebay buyer protection, I am not worried. Ebay will
> refund im sure.
> anyone else get one from this Ahole ?
>
>
> ___
> 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] USRP1 questions

[osama mohamed]

> Date: Mon, 12 Dec 2011 08:07:57 -0800
> From: j...@ettus.com
> To: osama_valencia...@hotmail.com; usrp-us...@lists.ettus.com
> Subject: Re: [Discuss-gnuradio] USRP1 questions
> 
> 
> 
> On 12/12/2011 01:52 AM, osama mohamed wrote:
> > 
> > hi all,
> > i am using USRP1 with  basic tx and rx boards and i have been suffering 
> > some problems recently so i hope you could answer the following 
> > questions(even if not all of them)
> > 
> > Q1:
> >  when i run the examples tx_timed_samples.cpp and tx_burst.cpp i don't 
> > get any output i tried various sampling rates and amplitudes but they 
> > still didn't produce any output if there is a certain configuration 
> > (i.e. sampling rate and amplitude) that works kindly inform me also i 
> > would like to know the output i am expected to see?
> > 
> > 
> 
> Those are examples apps to demonstrate API usage. See tx waveforms or tx
> samples from file for examples that transmit.
> 
> > Q2: i would like to tx a signal by setting the NCO frequency on the 
> > codec chip through the class codec_ctrl instead of using the PLL, is 
> > this doable or not and ,if yes should i use the class multi_usrp or i 
> > have to jump to the lower level class usrp1_impl?
> > 
> > 
> If you have basic TX and usrp1, the only frequency translation occurs in
> the codec. There is no PLL.
> 
> > Q3: can i use the low level class usrp1_impl to do the same 
> > functions of the examples   tx_timed_samples.cpp and tx_burst.cpp 
> > through setting the frequency tuning word of the codec through the class
> >  codec_ctrl ?
> > 
> > 
> 
> The implementation is not exposed. You will need some "creative" coding
> if you want to access the internal objects.
> 
> What do you think is missing in the "multi_usrp" wrapper?
> 
> > Q4: as i understand from the constructor of the class usrp1_impl  the 
> > sampling rates of the tx path are automatically detected and assigned 
> > through this constructor is this true or i have to set them through a 
> > certian function?
> > 
> > 
> 
> You should manually set the desired sample rate through the API.
> See
> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#ab8bc17744d3ee94b7c5cdcb75457bd6b
>   
> -Josh





hi Josh,
thanks a lot for your support.

the problem with the "multi_usrp" wrapper is that if i use another board for 
example WBX it will generate the desired frequency through the PLL except 

for frequencies less than the minimum threshold (which is as i remember 62 MHZ 
for WBX) so in the later case it will set the PLL to the minimum 

frequency (i.e. 62 MHZ) and will compensate the difference through the NCO (as 
i understand)

i want to do the same by myself even if the target frequency is in the 
supported range by the WBX (for example : i want to set the PLL to 935 MHZ and 

tune the NCO by +or - 44MHZ to get the up and down link ranges of the GSM 
system ), the reason for using the NCO instead of the PLL is that the NCO 

tuning is instantaneous unlike that of the PLL which takes about 200 micro secs

i think this request is not supported by the "multi_usrp" wrapper ??

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

Re: [Discuss-gnuradio] USRP1 questions

[Nick Foster]

Use the advanced tuning parameters.

http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes

2011/12/12 osama mohamed :
>
>
>> Date: Mon, 12 Dec 2011 08:07:57 -0800
>> From: j...@ettus.com
>> To: osama_valencia...@hotmail.com; usrp-us...@lists.ettus.com
>> Subject: Re: [Discuss-gnuradio] USRP1 questions
>
>>
>>
>>
>> On 12/12/2011 01:52 AM, osama mohamed wrote:
>> >
>> > hi all,
>> > i am using USRP1 with basic tx and rx boards and i have been suffering
>> > some problems recently so i hope you could answer the following
>> > questions(even if not all of them)
>> >
>> > Q1:
>> > when i run the examples tx_timed_samples.cpp and tx_burst.cpp i don't
>> > get any output i tried various sampling rates and amplitudes but they
>> > still didn't produce any output if there is a certain configuration
>> > (i.e. sampling rate and amplitude) that works kindly inform me also i
>> > would like to know the output i am expected to see?
>> >
>> >
>>
>> Those are examples apps to demonstrate API usage. See tx waveforms or tx
>> samples from file for examples that transmit.
>>
>> > Q2: i would like to tx a signal by setting the NCO frequency on the
>> > codec chip through the class codec_ctrl instead of using the PLL, is
>> > this doable or not and ,if yes should i use the class multi_usrp or i
>> > have to jump to the lower level class usrp1_impl?
>> >
>> >
>> If you have basic TX and usrp1, the only frequency translation occurs in
>> the codec. There is no PLL.
>>
>> > Q3: can i use the low level class usrp1_impl to do the same
>> > functions of the examples tx_timed_samples.cpp and tx_burst.cpp
>> > through setting the frequency tuning word of the codec through the class
>> > codec_ctrl ?
>> >
>> >
>>
>> The implementation is not exposed. You will need some "creative" coding
>> if you want to access the internal objects.
>>
>> What do you think is missing in the "multi_usrp" wrapper?
>>
>> > Q4: as i understand from the constructor of the class usrp1_impl the
>> > sampling rates of the tx path are automatically detected and assigned
>> > through this constructor is this true or i have to set them through a
>> > certian function?
>> >
>> >
>>
>> You should manually set the desired sample rate through the API.
>> See
>>
>> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#ab8bc17744d3ee94b7c5cdcb75457bd6b
>>
>> -Josh
>
>
>
>
>
> hi Josh,
> thanks a lot for your support.
>
> the problem with the "multi_usrp" wrapper is that if i use another board for
> example WBX it will generate the desired frequency through the PLL except
>
> for frequencies less than the minimum threshold (which is as i remember 62
> MHZ for WBX) so in the later case it will set the PLL to the minimum
>
> frequency (i.e. 62 MHZ) and will compensate the difference through the NCO
> (as i understand)
>
> i want to do the same by myself even if the target frequency is in the
> supported range by the WBX (for example : i want to set the PLL to 935 MHZ
> and
>
> tune the NCO by +or - 44MHZ to get the up and down link ranges of the GSM
> system ), the reason for using the NCO instead of the PLL is that the NCO
>
> tuning is instantaneous unlike that of the PLL which takes about 200 micro
> secs
>
> i think this request is not supported by the "multi_usrp" wrapper ??
>
> thanks,
> osama riad
>
> ___
> 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] Segmentation fault in wav file sink

[Matt Mills]

On Mon, Dec 12, 2011 at 3:41 AM, Martin Braun  wrote:

> * Do you randomly get either segfault or i/o error? I always get the i/o
>  with this code..
>

I get both.


> * Your code stresses the WAV-code a lot :) What are you trying to
>  accomplish? Are you finding a bug in wavfile_sink or do you need this
>  behaviour for something? Because you don't need close() if you just
>  want to switch files.
> * In any case, you're right. It's possible to call close() during work()
>  after do_update() is finished and thus yank the fp out from under our
>  feet. Actually, I can't think of any case where we need to call
>  close() manually--perhaps it should even be private?
>

I don't think making close() private is really the right solution. I'm
recording distinct conversations so having an open() unmute() mute()
close() sequence per call makes the most sense (if a channel is idle for 20
minutes between transmissions then I'm going to have the last wav file open
for 20 minutes; unless I open a temporary file to write nothing to, which
just seems silly).

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

Re: [Discuss-gnuradio] USRP1 questions

[osama mohamed]

hi josh,

i tried the example tx_waveforms.cpp using the following arguments  --freq 
100 --rate 800 --gain 20 --wave-type "SQUARE" --wave-freq 20 --ampl 
0.3 --spb 1 but there is an under run error so is there any suggested 
answer please

sorry for asking too much questions but i am really stuck

thanks ,

osama riad 

> Date: Mon, 12 Dec 2011 08:07:57 -0800
> From: j...@ettus.com
> To: osama_valencia...@hotmail.com; usrp-us...@lists.ettus.com
> Subject: Re: [Discuss-gnuradio] USRP1 questions
> 
> 
> 
> On 12/12/2011 01:52 AM, osama mohamed wrote:
> > 
> > hi all,
> > i am using USRP1 with  basic tx and rx boards and i have been suffering 
> > some problems recently so i hope you could answer the following 
> > questions(even if not all of them)
> > 
> > Q1:
> >  when i run the examples tx_timed_samples.cpp and tx_burst.cpp i don't 
> > get any output i tried various sampling rates and amplitudes but they 
> > still didn't produce any output if there is a certain configuration 
> > (i.e. sampling rate and amplitude) that works kindly inform me also i 
> > would like to know the output i am expected to see?
> > 
> > 
> 
> Those are examples apps to demonstrate API usage. See tx waveforms or tx
> samples from file for examples that transmit.
> 
> > Q2: i would like to tx a signal by setting the NCO frequency on the 
> > codec chip through the class codec_ctrl instead of using the PLL, is 
> > this doable or not and ,if yes should i use the class multi_usrp or i 
> > have to jump to the lower level class usrp1_impl?
> > 
> > 
> If you have basic TX and usrp1, the only frequency translation occurs in
> the codec. There is no PLL.
> 
> > Q3: can i use the low level class usrp1_impl to do the same 
> > functions of the examples   tx_timed_samples.cpp and tx_burst.cpp 
> > through setting the frequency tuning word of the codec through the class
> >  codec_ctrl ?
> > 
> > 
> 
> The implementation is not exposed. You will need some "creative" coding
> if you want to access the internal objects.
> 
> What do you think is missing in the "multi_usrp" wrapper?
> 
> > Q4: as i understand from the constructor of the class usrp1_impl  the 
> > sampling rates of the tx path are automatically detected and assigned 
> > through this constructor is this true or i have to set them through a 
> > certian function?
> > 
> > 
> 
> You should manually set the desired sample rate through the API.
> See
> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#ab8bc17744d3ee94b7c5cdcb75457bd6b
>   
> -Josh
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segmentation fault in wav file sink

[Martin Braun]

On Mon, Dec 12, 2011 at 11:49:56AM +0100, Martin Braun wrote:
> On Sun, Dec 11, 2011 at 02:31:03PM -0500, Marcus D. Leech wrote:
> > I think that what I'd do is cause the close() method to simply set a flag 
> > that
> > says "close desired", and then do the actual close at the end of
> >   the work function, probably under a mutex.
> 
> That sounds sensible. It could be done in do_update().

I'm sending a patch to patch-gnuradio. In it's current form, it's just
not thread-safe.

MB


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



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

Re: [Discuss-gnuradio] Problem with new swig docs stuff

[Justin Ford]

> Date: Wed, 7 Dec 2011 11:06:29 -0700
> From: b...@reynwar.net
> To: j...@ettus.com; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Problem with new swig docs stuff
>
> On Tue, Dec 6, 2011 at 3:51 PM, Josh Blum  wrote:
> > Tom/Ben,
> >
> > I think doxyindex.py may be relying on an xml field that older doxygen's
> > do not define.
> >
> > Perhaps we could put a big try/catch around this in case it fails and
> > print to stderr. That way the build keeps going, and its just a warning
> > printed out in the terminal.
> >
> > -josh
>
> You're right, it clearly needs to be more robust. I'll have a look tonight.
>
> Ben
>

I've built successfully on the latest master branch so this appears fixed as of 
(or sooner):

$ git status
# On branch master
nothing to commit (working directory clean)
[jrford@dodeca gnuradio]$ git show
commit fc6151d4516ee86b697602014b83fb08a88c30f0
Merge: 89f934b fa161e1
Author: Tom Rondeau 
Date:   Sun Dec 11 23:01:34 2011 -0500

    Merge remote-tracking branch 'jblum/cmake_qtgui_fix'

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

Re: [Discuss-gnuradio] Segmentation fault in wav file sink

[Martin Braun]

On Mon, Dec 12, 2011 at 10:37:35AM -0700, Matt Mills wrote:
> On Mon, Dec 12, 2011 at 3:41 AM, Martin Braun  wrote:
> 
> * Do you randomly get either segfault or i/o error? I always get the i/o
>  with this code..
>
> I get both.
>  
> 
> * Your code stresses the WAV-code a lot :) What are you trying to
>  accomplish? Are you finding a bug in wavfile_sink or do you need this
>  behaviour for something? Because you don't need close() if you just
>  want to switch files.
> * In any case, you're right. It's possible to call close() during work()
>  after do_update() is finished and thus yank the fp out from under our
>  feet. Actually, I can't think of any case where we need to call
>  close() manually--perhaps it should even be private?
>  
> I don't think making close() private is really the right solution. I'm
> recording distinct conversations so having an open() unmute() mute() close()
> sequence per call makes the most sense (if a channel is idle for 20 minutes
> between transmissions then I'm going to have the last wav file open for 20
> minutes; unless I open a temporary file to write nothing to, which just seems
> silly).

Yes, that makes sense. Try this (is the same as what I sent to
patch-gnuradio). It works with your script.

MB


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

From dee7e8664410b4337e740b97a2c1b9437fba51d3 Mon Sep 17 00:00:00 2001
From: Martin Braun 
Date: Mon, 12 Dec 2011 18:11:29 +0100
Subject: [PATCH] WAV sink: is now threadsafe; do_update() therefore must be
 private

---
 gnuradio-core/src/lib/io/gr_wavfile_sink.cc |2 +-
 gnuradio-core/src/lib/io/gr_wavfile_sink.h  |   14 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gnuradio-core/src/lib/io/gr_wavfile_sink.cc b/gnuradio-core/src/lib/io/gr_wavfile_sink.cc
index a96aadc..88b2323 100644
--- a/gnuradio-core/src/lib/io/gr_wavfile_sink.cc
+++ b/gnuradio-core/src/lib/io/gr_wavfile_sink.cc
@@ -184,6 +184,7 @@ gr_wavfile_sink::work (int noutput_items,
   
   int nwritten;
   
+  gruel::scoped_lock guard(d_mutex); // hold mutex for duration of this block
   do_update();	// update: d_fp is reqd
   if (!d_fp)	// drop output on the floor
 return noutput_items;
@@ -254,7 +255,6 @@ gr_wavfile_sink::do_update()
 return;
   }
   
-  gruel::scoped_lock guard(d_mutex); // hold mutex for duration of this block
   if (d_fp) {
 close_wav();
   }
diff --git a/gnuradio-core/src/lib/io/gr_wavfile_sink.h b/gnuradio-core/src/lib/io/gr_wavfile_sink.h
index 5fd3eaa..6a6b7eb 100644
--- a/gnuradio-core/src/lib/io/gr_wavfile_sink.h
+++ b/gnuradio-core/src/lib/io/gr_wavfile_sink.h
@@ -86,6 +86,13 @@ private:
   short convert_to_short(float sample);
 
   /*!
+   * \brief If any file changes have occurred, update now. This is called
+   * internally by work() and thus doesn't usually need to be called by
+   * hand.
+   */
+  void do_update();
+  
+  /*!
* \brief Writes information to the WAV header which is not available
* a-priori (chunk size etc.) and closes the file. Not thread-safe and
* assumes d_fp is a valid file pointer, should thus only be called by
@@ -108,13 +115,6 @@ public:
   void close();
 
   /*!
-   * \brief If any file changes have occurred, update now. This is called
-   * internally by work() and thus doesn't usually need to be called by
-   * hand.
-   */
-  void do_update();
-  
-  /*!
* \brief Set the sample rate. This will not affect the WAV file
* currently opened. Any following open() calls will use this new
* sample rate.
-- 
1.7.5.4



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

Re: [Discuss-gnuradio] Segmentation fault in wav file sink

[Matt Mills]

On Mon, Dec 12, 2011 at 10:47 AM, Martin Braun  wrote:

> On Mon, Dec 12, 2011 at 11:49:56AM +0100, Martin Braun wrote:
> > On Sun, Dec 11, 2011 at 02:31:03PM -0500, Marcus D. Leech wrote:
> > > I think that what I'd do is cause the close() method to simply set a
> flag that
> > > says "close desired", and then do the actual close at the end of
> > >   the work function, probably under a mutex.
> >
> > That sounds sensible. It could be done in do_update().
>
> I'm sending a patch to patch-gnuradio. In it's current form, it's just
> not thread-safe.
>

But wont this only close() a file when the sink is receiving samples? I
would think it would be extremely confusing if close() doesnt actually
close a file until the next sample is received, especially if there is a
valve in front of the wav_file sink.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segmentation fault in wav file sink

[Matt Mills]

On Mon, Dec 12, 2011 at 10:57 AM, Matt Mills  wrote:

>
> But wont this only close() a file when the sink is receiving samples? I
> would think it would be extremely confusing if close() doesnt actually
> close a file until the next sample is received, especially if there is a
> valve in front of the wav_file sink.
>

Nevermind, I suppose I should look at the patch BEFORE replying ;)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP1 questions

[Nick Foster]

2011/12/12 osama mohamed :
> hi josh,
>
> i tried the example tx_waveforms.cpp using the following arguments  --freq
> 100 --rate 800 --gain 20 --wave-type "SQUARE" --wave-freq 20
> --ampl 0.3 --spb 1 but there is an under run error so is there any
> suggested answer please
>
> sorry for asking too much questions but i am really stuck

Leave spb at the default value. Does it overflow then? Does it
overflow with rate=4e6 or rate=6.4e6?

--n

>
> thanks ,
>
> osama riad
>
>> Date: Mon, 12 Dec 2011 08:07:57 -0800
>> From: j...@ettus.com
>> To: osama_valencia...@hotmail.com; usrp-us...@lists.ettus.com
>> Subject: Re: [Discuss-gnuradio] USRP1 questions
>>
>>
>>
>> On 12/12/2011 01:52 AM, osama mohamed wrote:
>> >
>> > hi all,
>> > i am using USRP1 with basic tx and rx boards and i have been suffering
>> > some problems recently so i hope you could answer the following
>> > questions(even if not all of them)
>> >
>> > Q1:
>> > when i run the examples tx_timed_samples.cpp and tx_burst.cpp i don't
>> > get any output i tried various sampling rates and amplitudes but they
>> > still didn't produce any output if there is a certain configuration
>> > (i.e. sampling rate and amplitude) that works kindly inform me also i
>> > would like to know the output i am expected to see?
>> >
>> >
>>
>> Those are examples apps to demonstrate API usage. See tx waveforms or tx
>> samples from file for examples that transmit.
>>
>> > Q2: i would like to tx a signal by setting the NCO frequency on the
>> > codec chip through the class codec_ctrl instead of using the PLL, is
>> > this doable or not and ,if yes should i use the class multi_usrp or i
>> > have to jump to the lower level class usrp1_impl?
>> >
>> >
>> If you have basic TX and usrp1, the only frequency translation occurs in
>> the codec. There is no PLL.
>>
>> > Q3: can i use the low level class usrp1_impl to do the same
>> > functions of the examples tx_timed_samples.cpp and tx_burst.cpp
>> > through setting the frequency tuning word of the codec through the class
>> > codec_ctrl ?
>> >
>> >
>>
>> The implementation is not exposed. You will need some "creative" coding
>> if you want to access the internal objects.
>>
>> What do you think is missing in the "multi_usrp" wrapper?
>>
>> > Q4: as i understand from the constructor of the class usrp1_impl the
>> > sampling rates of the tx path are automatically detected and assigned
>> > through this constructor is this true or i have to set them through a
>> > certian function?
>> >
>> >
>>
>> You should manually set the desired sample rate through the API.
>> See
>>
>> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#ab8bc17744d3ee94b7c5cdcb75457bd6b
>>
>> -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] underrun occurs when frequency changing

[Yan Nie]

> >Really appreciate any of your suggestion!
> >
> Underrun is caused by your flow-graph not being able to provide samples to 
> the hardware at the specified rate.  It looks to me like in
>   your flow-graph above, your message-queue can easily get starved for new 
> bits, and so the entire flow-graph stalls.  But that's just
>   after a superficial inspection.  Since you actually *go to sleep* for an 
> entire second, it seems like it would be pretty easy for the flow-graph
>   to stall.
 
Thank you so much for your reply. I am wondering what the reason causes my 
message-queue could easily get starved for new bits? How to avoid this problem 
with my message-queue? Is the problem of the wrong setting about the msg_limit 
for the message-queue? I do not understand how to set the limit for msgq. What 
it depends on?

I tried to make the  bits loading thread "sleep" for only 0.005s, though still 
the underrun occurs. What is the reason of that? 

Thanks you so much for any of your suggestions.

Thanks,
Yan

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

Re: [Discuss-gnuradio] underrun occurs when frequency changing

[Marcus D. Leech]

On 12/12/2011 01:41 PM, Yan Nie wrote:

Really appreciate any of your suggestion!


Underrun is caused by your flow-graph not being able to provide samples to the 
hardware at the specified rate.  It looks to me like in
   your flow-graph above, your message-queue can easily get starved for new 
bits, and so the entire flow-graph stalls.  But that's just
   after a superficial inspection.  Since you actually *go to sleep* for an 
entire second, it seems like it would be pretty easy for the flow-graph
   to stall.
  
Thank you so much for your reply. I am wondering what the reason causes my message-queue could easily get starved for new bits? How to avoid this problem with my message-queue? Is the problem of the wrong setting about the msg_limit for the message-queue? I do not understand how to set the limit for msgq. What it depends on?


I tried to make the  bits loading thread "sleep" for only 0.005s, though still 
the underrun occurs. What is the reason of that?

Thanks you so much for any of your suggestions.

Thanks,
Yan


You need to look at the flow of bits into your flow-graph, and make sure 
that flow can keep up with the sample-rate demanded by the
  rest of the flow-graph, right up to whatever you've programmed the 
hardware to do.




--
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] cmake errors on first attempt with master branch

[Josh Blum]

On 12/12/2011 09:59 AM, Justin Ford wrote:
> 
> 
> 
> 
>> Date: Mon, 12 Dec 2011 08:44:48 -0800
>> From: j...@ettus.com
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] cmake errors on first attempt with master 
>> branch
>>
>>
>> Cant tell. You gotta attach the whole verbose. -josh
>>
> 
> I piped the output to file and saw this at the console:
> 
> $ cmake -DPYTHON_EXECUTABLE=/usr/bin/python26 
> -DBOOST_INCLUDEDIR=/usr/include/boost141 
> -DBOOST_LIBRARYDIR=/usr/lib64/boost141 
> -DSWIG_EXECUTABLE=/usr/share/swig/2.0.4/bin/swig ../ > cmake_output.txt
> CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:653 (file):
>   file FILE(SYSTEM_PATH ENV result) must be called with only three arguments.
> Call Stack (most recent call first):
>   cmake/Modules/GrBoost.cmake:62 (find_package)
>   gruel/CMakeLists.txt:23 (include)
> 
> The output file and what I hope are the verbose you're looking for are 
> attached.  If I've misunderstood your request I'll be happy to send other 
> cmake output.
> 

Well that looks like the problem. So, I didnt see that code in my
findboost.cmake. Which means either you have a findboost with a bug,
and/or this is a code path that does not get exercised much but is now
because you are manually setting the library/include dir to something
custom. I attached the findboost.cmake from my system in case that helps.

-Josh



# - Try to find Boost include dirs and libraries
# Usage of this module as follows:
#
# NOTE: Take note of the Boost_ADDITIONAL_VERSIONS variable below.
# Due to Boost naming conventions and limitations in CMake this find
# module is NOT future safe with respect to Boost version numbers,
# and may break.
#
# == Using Header-Only libraries from within Boost: ==
#
#   find_package( Boost 1.36.0 )
#   if(Boost_FOUND)
#  include_directories(${Boost_INCLUDE_DIRS})
#  add_executable(foo foo.cc)
#   endif()
#
#
# == Using actual libraries from within Boost: ==
#
#   set(Boost_USE_STATIC_LIBSON)
#   set(Boost_USE_MULTITHREADED  ON)
#   set(Boost_USE_STATIC_RUNTIMEOFF)
#   find_package( Boost 1.36.0 COMPONENTS date_time filesystem system ... )
#
#   if(Boost_FOUND)
#  include_directories(${Boost_INCLUDE_DIRS})
#  add_executable(foo foo.cc)
#  target_link_libraries(foo ${Boost_LIBRARIES})
#   endif()
#
#
# The components list needs to contain actual names of boost libraries only,
# such as "date_time" for "libboost_date_time".  If you're using parts of
# Boost that contain header files only (e.g. foreach) you do not need to
# specify COMPONENTS.
#
# You should provide a minimum version number that should be used. If you provide this 
# version number and specify the REQUIRED attribute, this module will fail if it
# can't find the specified or a later version. If you specify a version number this is
# automatically put into the considered list of version numbers and thus doesn't need
# to be specified in the Boost_ADDITIONAL_VERSIONS variable (see below).
#
# NOTE for Visual Studio Users:
# Automatic linking is used on MSVC & Borland compilers by default when
# #including things in Boost.  It's important to note that setting
# Boost_USE_STATIC_LIBS to OFF is NOT enough to get you dynamic linking,
# should you need this feature.  Automatic linking typically uses static
# libraries with a few exceptions (Boost.Python is one).
#
# Please see the section below near Boost_LIB_DIAGNOSTIC_DEFINITIONS for
# more details.  Adding a TARGET_LINK_LIBRARIES() as shown in the example
# above appears to cause VS to link dynamically if Boost_USE_STATIC_LIBS
# gets set to OFF.  It is suggested you avoid automatic linking since it
# will make your application less portable.
#
# === The mess that is Boost_ADDITIONAL_VERSIONS (sorry?) 
#
# OK, so the Boost_ADDITIONAL_VERSIONS variable can be used to specify a list of
# boost version numbers that should be taken into account when searching
# for Boost. Unfortunately boost puts the version number into the
# actual filename for the libraries, so this variable will certainly be needed
# in the future when new Boost versions are released.
#
# Currently this module searches for the following version numbers:
# 1.33, 1.33.0, 1.33.1, 1.34, 1.34.0, 1.34.1, 1.35, 1.35.0, 1.35.1,
# 1.36, 1.36.0, 1.36.1, 1.37, 1.37.0, 1.38, 1.38.0, 1.39, 1.39.0,
# 1.40, 1.40.0, 1.41, 1.41.0, 1.42, 1.42.0, 1.43, 1.43.0, 1.44, 1.44.0,
# 1.45, 1.45.0, 1.46, 1.46.0, 1.46.1
#
# NOTE: If you add a new major 1.x version in Boost_ADDITIONAL_VERSIONS you should
# add both 1.x and 1.x.0 as shown above.  Official Boost include directories
# omit the 3rd version number from include paths if it is 0 although not all
# binary Boost releases do so.
#
# set(Boost_ADDITIONAL_VERSIONS "1.78" "1.78.0" "1.79" "1.79.0")
#
# = = 
#
# Variables used by this module, they

[Discuss-gnuradio] New build-gnuradio

[Marcus D. Leech]

Updated some Ubuntu depends that have come in "from the field", 
including "gtk2-engines-pixbuf".



--
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] problems with python blocks [attn: jblum]

[Paul Miller]

On Wed, Dec 7, 2011 at 2:03 PM, Josh Blum  wrote:
> I cant say yet as to why, but at least its reproducible.

I spent a few hours source diving today and gdb-stepping.  I
could not figure it out, but I did find that it's broken in every
minor release after 2.0.1 (2.0.2, 3 and 4).

I finally gave up and just left 2.0.1 installed.  Now I can at
least work in my cool block.  But my boring test block still
doesn't work.  It nolonger sagfaults, which is nice, but it seems
to loop forever.  I've been pouring over the docs (such as they
are) and I can't see any obvious reason why it should loop
infinitely like it does.  I noticed none of your QA uses
basic_block.  I'd give up and use sync_block, but I expect you
want to know about these problems.

On the other hand, I still find it rather likely I'm just doing
something wrong.  The verbosity code long cuts are due to the
fact that I've been debugging for a while, but this is what I'm
seeing infinitely loop right now:



class gr_norm(gr.basic_block):
def __init__(self):
gr.basic_block.__init__(self, name="normalizer", 
in_sig=[numpy.complex64], out_sig=[numpy.complex64])

def general_work(self, input_items, output_items):

# buffer references
in0 = input_items[0]
out = output_items[0]

print "here %d" % len( in0 )

x = 0
for i in in0:
print 'i: %s' % i

# process data
mag = math.sqrt( i.real ** 2 + i.imag ** 2 )

if abs(mag)<0.01:
mag=0.01 # avoid divide by 0

out[x] = i / mag;
x = x + 1

#self.consume_each(len(out))
self.consume(0, x)

return x





using this qa... 

def test_001_gr_norm(self):
src_data = [ -10, 10, -10j, 10j ]
expected_result = [ -1, 1, -1j, 1j ]

src = gr.vector_source_c(src_data, False)
nor = gr_norm()
dst = gr.vector_sink_c()

tb = gr.top_block()
tb.connect(src, nor)
tb.connect(nor, dst)
tb.run()

result_data = dst.data()

self.assertFloatTuplesAlmostEqual(expected_result, result_data, 6)


-- 
If riding in an airplane is flying, then riding in a boat is swimming.
116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.


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

Re: [Discuss-gnuradio] problems with python blocks [attn: jblum]

[Josh Blum]

On 12/12/2011 05:10 PM, Paul Miller wrote:
> 
> On Wed, Dec 7, 2011 at 2:03 PM, Josh Blum  wrote:
>> I cant say yet as to why, but at least its reproducible.
> 
> I spent a few hours source diving today and gdb-stepping.  I
> could not figure it out, but I did find that it's broken in every
> minor release after 2.0.1 (2.0.2, 3 and 4).
> 

Its weird that feval works ok, I tried for a bit, but I couldnt figure
out what was different about my blocks. This will take more effort to
figure out if thats possible, but I do think its a bug in swig.

> I finally gave up and just left 2.0.1 installed.  Now I can at
> least work in my cool block.  But my boring test block still
> doesn't work.  It nolonger sagfaults, which is nice, but it seems
> to loop forever.  I've been pouring over the docs (such as they
> are) and I can't see any obvious reason why it should loop
> infinitely like it does.  I noticed none of your QA uses
> basic_block.  I'd give up and use sync_block, but I expect you
> want to know about these problems.
> 
> On the other hand, I still find it rather likely I'm just doing
> something wrong.  The verbosity code long cuts are due to the
> fact that I've been debugging for a while, but this is what I'm
> seeing infinitely loop right now:
> 
> 

Try retuning -1 when your block no longer gets any samples. Basically,
it has no condition in which to exit, so it runs forever. Most blocks
are like this, which is why you dont use run(), but rather
start()/stop() for the continuous processing case.

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

Re: [Discuss-gnuradio] Problem with new swig docs stuff

[Tom Rondeau]

On Wed, Dec 7, 2011 at 1:06 PM, Ben Reynwar  wrote:

> On Tue, Dec 6, 2011 at 3:51 PM, Josh Blum  wrote:
> >
> >> 
> >> [ 47%] Generating general_swig_doc.i
> >> Error in xml in file
> /home/gr/source/git/gnuradio/build/gnuradio-core/src/lib/swig/general_swig_doc_swig_docs/xml/gr__simple__framer__sync_8h.xml
> >> Traceback (most recent call last):
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line
> 253, in 
> >> make_swig_interface_file(di, swigdocfilename,
> custom_output=custom_output)
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/swig_doc.py", line
> 196, in make_swig_interface_file
> >> blocks = di.in_category(Block)
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py",
> line 140, in in_category
> >> self.confirm_no_error()
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py",
> line 206, in confirm_no_error
> >> self.check_parsed()
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py",
> line 203, in check_parsed
> >> self._parse()
> >>   File
> "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line 51,
> in _parse
> >> self._members += converted.members()
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py",
> line 174, in members
> >> self.confirm_no_error()
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py",
> line 206, in confirm_no_error
> >> self.check_parsed()
> >>   File "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/base.py",
> line 203, in check_parsed
> >> self._parse()
> >>   File
> "/home/gr/source/git/gnuradio/docs/doxygen/doxyxml/doxyindex.py", line 163,
> in _parse
> >> self.set_descriptions(self._retrieved_data.compounddef)
> >> AttributeError: 'NoneType' object has no attribute 'compounddef'
> >> make[2]: *** [gnuradio-core/src/lib/swig/general_swig_doc.i] Error 1
> >> make[1]: ***
> [gnuradio-core/src/lib/swig/CMakeFiles/_gnuradio_core_filter.dir/all] Error
> 2
> >> make: *** [all] Error 2
> >>
> >
> > Tom/Ben,
> >
> > I think doxyindex.py may be relying on an xml field that older doxygen's
> > do not define.
> >
> > Perhaps we could put a big try/catch around this in case it fails and
> > print to stderr. That way the build keeps going, and its just a warning
> > printed out in the terminal.
> >
> > -josh
>
> You're right, it clearly needs to be more robust.  I'll have a look
> tonight.
>
> Ben
>


It turns out that the problem was with the '&' in the doxygen markup. I was
able to change this link to one that doesn't use '&'. it also looks like
this is a problem with old Doxygen format.

Hopefully, we won't see this again or Ben can put in a quick fix for it.

I have also updated the build process such that if you specify
'-DENABLE_DOXYGEN=False' it does not build the swigdocs, either. So any
future problems that might occur due to issues with markup, etc., we can at
least get around by not having these guys generated at all.

(I would also like to stop having to support Redhat, but I know too many
places are still using it.)

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

Re: [Discuss-gnuradio] FM transmitter

[محمد روسلي]

Hi,

There are example python code and grc from the repository. You can try it
yourself.

Regards,
Muhammad

On Tue, Dec 13, 2011 at 2:41 AM, MOHD RAFIQ  wrote:

> Hi, is it possible to make gnuradio/usrp2/WBX & fedora 15, combination as
> FM transmitter to stream audio files as we can do in some smart phones.
> please help,if you  there is a grc/python file already, I have tried others
> on web but they dont work for my setup. I appreciate any comments, Thanks
> rafiq
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Regards,
Muhammad b Rosli
Student
Bachelor of Electrical and Electronic
University of Canterbury
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FM transmitter

[Rafael Diniz]

Take also a look in here:
http://mmbtools.crc.ca/content/view/45/73/
and here:
http://www.opendigitalradio.org/index.php/FM_RDS_Stereo_transmitter_using_gnuradio

Best regards,
Rafael Diniz

> Hi,
>
> There are example python code and grc from the repository. You can try it
> yourself.
>
> Regards,
> Muhammad
>
> On Tue, Dec 13, 2011 at 2:41 AM, MOHD RAFIQ 
> wrote:
>
>> Hi, is it possible to make gnuradio/usrp2/WBX & fedora 15, combination
>> as
>> FM transmitter to stream audio files as we can do in some smart phones.
>> please help,if you  there is a grc/python file already, I have tried
>> others
>> on web but they dont work for my setup. I appreciate any comments,
>> Thanks
>> rafiq
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> Regards,
> Muhammad b Rosli
> Student
> Bachelor of Electrical and Electronic
> University of Canterbury
> ___
> 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 build-gnuradio

[محمد روسلي]

Hi,

I personally think we should include that as a part of pre-requisite
library required for Ubuntu.

Regards,
Muhammad Rosli
Student
University of Canterbury

On Tue, Dec 13, 2011 at 11:31 AM, Marcus D. Leech  wrote:

> Updated some Ubuntu depends that have come in "from the field", including
> "gtk2-engines-pixbuf".
>
>
> --
> 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
>



-- 
Regards,
Muhammad b Rosli
Student
Bachelor of Electrical and Electronic
University of Canterbury
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FM transmitter

[محمد روسلي]

Hi,

Initially I would like to recommend that links as I worried the gnuradio
has changed the source and sink for the USRP. But, I guess it wouldn't hurt.

Thanks Rafael.

Regards,
Muhammad Rosli
Student
University of Canterbury

On Tue, Dec 13, 2011 at 3:27 PM, Rafael Diniz  wrote:

> Take also a look in here:
> http://mmbtools.crc.ca/content/view/45/73/
> and here:
>
> http://www.opendigitalradio.org/index.php/FM_RDS_Stereo_transmitter_using_gnuradio
>
> Best regards,
> Rafael Diniz
>
> > Hi,
> >
> > There are example python code and grc from the repository. You can try it
> > yourself.
> >
> > Regards,
> > Muhammad
> >
> > On Tue, Dec 13, 2011 at 2:41 AM, MOHD RAFIQ 
> > wrote:
> >
> >> Hi, is it possible to make gnuradio/usrp2/WBX & fedora 15, combination
> >> as
> >> FM transmitter to stream audio files as we can do in some smart phones.
> >> please help,if you  there is a grc/python file already, I have tried
> >> others
> >> on web but they dont work for my setup. I appreciate any comments,
> >> Thanks
> >> rafiq
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >>
> >
> >
> > --
> > Regards,
> > Muhammad b Rosli
> > Student
> > Bachelor of Electrical and Electronic
> > University of Canterbury
> > ___
> > 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
>



-- 
Regards,
Muhammad b Rosli
Student
Bachelor of Electrical and Electronic
University of Canterbury
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problems with python blocks [attn: jblum]

[Paul Miller]

On Mon, Dec 12, 2011 at 05:19:13PM -0800, Josh Blum wrote:
> Its weird that feval works ok, I tried for a bit, but I couldnt figure
> out what was different about my blocks. This will take more effort to
> figure out if thats possible, but I do think its a bug in swig.

Well, let me know if I can help.  I doubt it, but I'm at least
familiar with compiling and digging around in there already.

> Try retuning -1 when your block no longer gets any samples. Basically,
> it has no condition in which to exit, so it runs forever. Most blocks
> are like this, which is why you dont use run(), but rather
> start()/stop() for the continuous processing case.

Yes, that's got it.

Thanks.


-- 
If riding in an airplane is flying, then riding in a boat is swimming.
116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.

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

[Discuss-gnuradio] Default antenna with RFX2400

[Phone Naing MYINT]

Hi,

I'm using USRP2 with RFX2400 daughter board. I'm using GRC. By default which 
antenna are used for USRP-source and USRP-sink?

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

Re: [Discuss-gnuradio] Default antenna with RFX2400

[Josh Blum]

On 12/12/2011 08:14 PM, Phone Naing MYINT wrote:
> Hi,
> 
> I'm using USRP2 with RFX2400 daughter board. I'm using GRC. By default which 
> antenna are used for USRP-source and USRP-sink?

http://files.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series

-josh

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

Re: [Discuss-gnuradio] Default antenna with RFX2400

[Marcus D. Leech]

On 12/12/11 11:14 PM, Phone Naing MYINT wrote:
>
> Hi,
>
>  
>
> I'm using USRP2 with RFX2400 daughter board. I'm using GRC. By default
> which antenna are used for USRP-source and USRP-sink?
>
>  
>
> PN
>
>   
http://files.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series

-- 
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] Default antenna with RFX2400

[Phone Naing MYINT]

Hi,

TX is clear, defaulted to TX/RX. RX default to direct conversion, what does it 
mean? For receive, using TX/RX or RX2 provides same performance?

PN 

-Original Message-
From: discuss-gnuradio-bounces+phonenaing.myint=sg.panasonic@gnu.org 
[mailto:discuss-gnuradio-bounces+phonenaing.myint=sg.panasonic@gnu.org] On 
Behalf Of Josh Blum
Sent: Tuesday, December 13, 2011 12:18 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Default antenna with RFX2400



On 12/12/2011 08:14 PM, Phone Naing MYINT wrote:
> Hi,
> 
> I'm using USRP2 with RFX2400 daughter board. I'm using GRC. By default which 
> antenna are used for USRP-source and USRP-sink?

http://files.ettus.com/uhd_docs/manual/html/dboards.html#rfx-series

-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] Default antenna with RFX2400

[Josh Blum]

On 12/12/2011 08:25 PM, Phone Naing MYINT wrote:
> Hi,
> 
> TX is clear, defaulted to TX/RX. RX default to direct conversion, what does 
> it mean?

RFX2400 is a direct conversion receiver *and* a direct conversion
transmitter. What the docs really should say:

1) When you tune the transmit chain, the default behaviour is to tune
the LO away from the desired center frequency.

2) When you tune the receive chain, the default behavior is to tune the
LO as close as possible to the desired center frequency.

You can of course, override this behavior:
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes

 For receive, using TX/RX or RX2 provides same performance?
> 

TXRX vs RX2 is just a simple switch. You must pick what is most useful
for your application (full vs half duplex). Obviously, for a
receive-only application, either antenna option is good.

-josh

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

[Discuss-gnuradio] USRP2 metric measurement

[MOHD RAFIQ]

Hi, 

I need to measure any metric(say RSSI) of one USRP2 from the other, to 
implement a selection scheme that selects best USRP2 based on best metric. 

what best can be measured to estimate the quality of the link.
All comments/suggestions are welcome
I am using gnuradio 3.5, on fedora 15.
USRP2 with WBX daughter boards 

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