[Discuss-gnuradio] More Samples..

[Ramakrishnan Muthukrishnan]

Found these signal sample files on the web.

 http://www.kb9ukd.com/digital/

-- 
  73 - Ramakrishnan, VU3RDD


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

Re: [Discuss-gnuradio] USRP heating up !

[Javs]

Hi all,

I tried the experiment again today and I think I
answered my question. I first ran the am_rcv.py
example which pops a GUI, a very tiny one since the
pre_demod, post_demod and post_filt blocks were
commented. And this was hiding on the top left corner
of my screen (I missed it). Assuming, there was no GUI
for this code, I used Cntrl C to kill it. Although I
wrongly assumed it was ended it actually was not
destroyed and was running its internal processes,
thereby heating the codecs.

I think the way the 'Destroy' destructor for the GUI's
is written is applicable only if we gracefully exit
the GUI (i.e. through File->exit  on the GUI). It
seems to me that Cntrl C does not totally kill the
internal processes in the codecs and they continuosly
receive the power. 

Lesson learnt : Avoid using Cntrl C to close your
GUI's.
 
I still am not sure of one thing though. When I run
the example 'wfm_rcv_gui.py' with my basic d'board on
the A side, the codec on the B side heats up. It seems
like when I receive on A side the Codec on the other
side has no job . If this is true, I think a better
way to cut power to the unused codec would be to use
the 'which_side' logic. Or this is probably what Eric
was inkling at when he mentioned about ways to
ameliorate the problem.


Thanks for all your help.

Javs

 

--- Eric Blossom <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 11, 2005 at 10:38:39PM -0700, Eric
> Blossom wrote:
> >
> > I've made a bunch of power measurements and Matt
> and I have been
> > discussing some ways to ameliorate the problem.  I
> expect to have a
> > few of them coded up over the next couple of days.
> 
> Following up on my own post, I wanted to make clear
> that the power
> measurements I made indicate that the power
> consumption is within
> spec.  We've been talking about ways to lower the
> power consumption by
> turning off parts of the AD9862 when they are not
> required.
> 
> Eric
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
>
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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

[Discuss-gnuradio] High-speed captures of high-quality signals available.

[Lamar Owen]

After some prompting, I have put together three high-quality signal captures 
for your enjoyment.  The captures were made using the commandline:
./usrp_rx_cfile.py -o filename.dat -d8

Signal generator is a lab-grade HP8657B, recently calibrated, with output 
level set at -10dBm, and with a 20dB attenuator at the USRP (-30dBm signal, 
theoretically).  The four frequencies used were 100kHz, 500kHz, 1MHz, and 
2MHz.  The DDC was set to zero.

Filenames are:
1MHz-sin-usrp-hp8657b-20050421.dat.bz2
2MHz-sin-usrp-hp8657b-20050421.dat.bz2
100KHz-sin-usrp-hp8657b-20050421.dat.bz2
500KHz-sin-usrp-hp8657b-20050421.dat.bz2

All are available at http://www.lamarowen.net/files/

They average 1.5-2.5MB bzip compressed; uncompressed they are roughly ten 
times that size.

USRP serial# 179 was used to make these captures, using a BasicRX module.

The results are encouraging.  Previously, I had used my cheap Elenco function 
generator; come to find out that its output is horrible and shouldn't be used 
for basically anything.  Probably a bad output coupling cap or something.

The HP8657B is only rated to go down to 0.1MHz, but it does go up to 2060MHz, 
which is the range in which it gets used at PARI (we calibrate using it at 
1420MHz and -122dBm).By comparing output levels one could look at 
frequency response to a degree.  If desired, I can use our noise source as 
well; it's calibrated flat from about 1MHz to over 100MHz.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu


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

[Discuss-gnuradio] USRP MUX questions

[Achilleas Anastasopoulos]

Dear all,
I read in the USRP description that the Receiver path has
4 ADC's and in the FPGA there are 4 DDC's implemented.
Each DDC has 2 inputs (I and Q) and two real (or one complex)
output. The MUX is swithcing the output of the 4 ADC's (or
the value zero) to the 8=4x2 inputs of the DDC's.
I attach three eps files with what I understand is the block diagram
of this implementation. It is assumed that the standard Rx dboard is on 
side 0 and the tv_rx board is on side 1.

Here are some questions:
Are the connections from the daughterboards to the ADC's
hardwired in the USRP the way it is shown in the figure,
ie, RX-A to ADC-0, RX-B to ADC-1 and the IF output of the
TV-RX to both ADC-2 and ADC-3 ?
Why is there a need for 4 DDC implemented in the FPGA?
How exactly are the 4 complex streams multiplexed into the USB port?
are we always sampling one from each of the four, or
can we control it so that we always select say DDC-0 ?
How is this controled in software?
According to usrp_wfm_gui.py the correct MUX seting for listening to
FM is0x f0 f0 f0 f2.
These connections are shown on the second eps file.
It seems to me that this is not the way the tv_rx output should be 
connected to the DDC's. To start with, why are we zeroing all Q 
channels? If this is done then we should be getting always a complex 
number with zero imaginary part...
It seems to me that the correct setup is 0x 32 32 32 32,
as it is shown in the third figure.
(however, I do have a very nice FM reception even with the f0f0f0f2,
so I guess I am missing something)

Thanks,
Achilleas


usrp1.eps
Description: PostScript document


usrp_tvrx.eps
Description: PostScript document


usrp_tvrx_correct.eps
Description: PostScript document
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] TVRX AGC Disable

[mgray]

Is there a way to disable the AGC on the TVRX (cable MODEM) board?

If a strong signal appears within the 6 MHz BW the AGC is activated and 
many weak signals are lost.  It limits the receiver dynamic range to about 
10dB.

Thanks




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

Re: [Discuss-gnuradio] RF recorder

[Justin Zygmont]

Thanks for that link, i didn't know there was such a neat GPL program out 
there:)

On Wed, 6 Apr 2005, Adam Sampson wrote:
Justin Zygmont <[EMAIL PROTECTED]> writes:
I was looking for a program that will record input from the soundcard
only when there is activity.
Would this do what you're after?
 


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