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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio