discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Using USRP w/o Daughterboard's


From: Robitaille, Michael
Subject: Re: [Discuss-gnuradio] Using USRP w/o Daughterboard's
Date: Fri, 4 Nov 2005 14:19:59 -0700

Eric's reply

> The code that defines determine_rx_mux_value is in

> 

>    gr-usrp/src/usrp.py

> 

> It's pretty short.

 

Thanks, I found it late last night after sending the post.

 

> You are going to need some kind of daughterboard to get access to the
high-speed A/D and D/A inputs and

> output respectively.  On the other hand, you may be able to just read a
digital i/o pin for your very

> low data rate.  The Basic Tx and Basic Rx daughterboards bring out 16
uncommitted digital i/o pins to

> headers.  To read then periodically, you'd need to hack up some custom
FPGA code.  You might need to

> build a small amount of circuitry to inteface your analog signal to the 0
to 3.3 V levels the i/o pins

> expect.

 

>From looking at the Basic RX board schematic, I can see what pins are being
used from the high speed A/D and I have modified a connecter to input the
signals on those pins.  It would seem that I could make the software think
that there is a Basic RX and just feed the signal to those pins.  The Basic
RX board is pretty simple and basically takes an unbalanced input and
converts it to a balance input.  I followed the python code until it started
to get into the c++ code (usrp1_source_c_sptr).  I will see about getting a
Basic RX board but will need to modify it (John Gilmore makes mention of
this).

 

I still think that there is a simple change that could be made to the code
to make it think that there is a Basic RX.

 

> Almost all of the high level USRP functionality is defined in two C++
header files: 

> usrp/host/lib/usrp_basic.h and usrp/host/lib/usrp_standard.h.

> 

> Through a somewhat convoluted path, the public interfaces of those classes
end being methods in the Python

> usrp.source_c and/or usrp.sink_c classes.

 

Yes the path is convoluted, I have follow source_c in usrp.py that just
calls usrp1.source_c in usrp1.py which call the usrp1_source_c_sptr in
usrp1_source_c.cc. 

 

Mike

 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]