Hi all
I'm working with openSUSE 11.4 (2.6.37.1-1.2) KDE desktop and latest stable
gnuradio version ./configure make and make install show me no errors and
modules
that I need are configured however dial_tone.py example fails. It never
happened
to me with openSUSE 11.1 and gnuradio 3.1.3
Wh
On May 16, 2011, at 3:20 AM, Marcus D. Leech wrote:
> On 05/15/2011 07:11 PM, Elvis Dowson wrote:
>> Reducing the refresh rate to 5fps makes it a bit more responsive. A value of
>> 10 makes it un-responsive. My sample rate is 3.125M sps using a USRP2, using
>> the UHD drivers.
>>
> usrp2_fft.p
On 05/15/2011 07:11 PM, Elvis Dowson wrote:
> Reducing the refresh rate to 5fps makes it a bit more responsive. A value of
> 10 makes it un-responsive. My sample rate is 3.125M sps using a USRP2, using
> the UHD drivers.
>
usrp2_fft.py was written for "classic" -- did you modify it for UHD?
A
Hi Marcus,
On May 16, 2011, at 2:44 AM, Marcus D. Leech wrote:
> Try doing two things:
>
> Turn on averaging
> Turn down the FFT frame display rate from the default 30, to something like 5
Reducing the refresh rate to 5fps makes it a bit more responsive. A value of 10
makes it un-responsive. M
Hi,
When I run usrp2_fft.grc, it just hangs on execution, nothing gets
displayed and the FFT plot doesn't get updated.
I've set the frequency to 104.1M, decimation value to 16.
The FFT Plot gui is completely un-responsive. I'm using Ubuntu-11.04 with
gnuradio-3.4.0.
Elvis Dowson
T
On Sun, May 15, 2011 at 3:30 PM, John Andrews wrote:
> How can we correctly measure what is the frequency offset between the two
> USRPs?
Set one USRP to send CW. Tune the other USRP to receive CW.
The resultant frequency on the receiver side is the frequency offset.
> Thanks
Make sense?
Bri
Hi,
When I run usrp2_fft.grc, it just hangs on execution, nothing gets
displayed and the FFT plot doesn't get updated.
I've set the frequency to 104.1M, decimation value to 16.
The FFT Plot gui is completely un-responsive. I'm using Ubuntu-11.04 with
gnuradio-3.4.0.
Elvis Dowson
On 05/15/2011 01:31 PM, turbovectorz turbovectorz wrote:
> Hi ALL,
>
> Everything compiled properly with no errors with GNU radio 3.3.0 with that
> latest Boost 1_46_1.
Using one boost library often pulls in boost system as a requirement.
This must be true for Boost 1_46_1. You may want to use
Hi ALL,
Everything compiled properly with no errors with GNU radio 3.3.0 with that
latest Boost 1_46_1.
GRC generate works but will not execute the dial_tone.grc example due the
following error:
Anyone can shed some light on this strange python command line test error?
Python 2.6.5 (r265:79063, A
How can we correctly measure what is the frequency offset between the two
USRPs?
Thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
An interesting grc application called FM-RDS
http://mmbtools.crc.ca/content/view/45/73/
I wonder if anyone successfully compiled the gr-rds-3.0 ?
I got the following error (any idea what's wrong in the installation):
-
jonathan@jonathan:~/n210_grc/
fm_rds/gr-rds-3.0svn$ m
Hi all,
I really screwed up today when I upgraded from F13 to F14 result, no network,
access denied to every device (RAID), etc.
I was able to burn (backup) sources to disk and then formatted from latest F14.
I run into probs when installing the traditional USRP1 without uhd. Configure
seems to
On 05/15/2011 06:04 AM, Daniel Bartel wrote:
I have looked for some documentation of UHD, but I wasn't were lucky.
>
UHD documentation is here:
http://www.ettus.com/uhd_docs/manual/html/
Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.or
>> Hello,
>>
>> I was wondering about a little conflict concerning the sizes of the data
>> types in GNU Radio.
>>
>> The UHD driver sends 16 bits I, 16 bits Q samples over the ethernet
>> interface at 25 MS/s and the return value of "gr.sizeof_gr_complex" is 8
>> bytes (64 bits).
>> How does
On 05/15/2011 09:04 AM, Daniel Bartel wrote:
> Hello,
>
> I was wondering about a little conflict concerning the sizes of the data
> types in GNU Radio.
>
> The UHD driver sends 16 bits I, 16 bits Q samples over the ethernet interface
> at 25 MS/s and the return value of "gr.sizeof_gr_complex" is
Hello,
I was wondering about a little conflict concerning the sizes of the data types
in GNU Radio.
The UHD driver sends 16 bits I, 16 bits Q samples over the ethernet interface
at 25 MS/s and the return value of "gr.sizeof_gr_complex" is 8 bytes (64 bits).
How does this actually work?
I have
16 matches
Mail list logo