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

[Eric Blossom]

On Sat, Nov 05, 2005 at 05:50:17PM -0700, Robitaille, Michael wrote:
> Eric wrote
> 
> > Why do you think that code will need to be modified?
> 
> If I get the Basic RX board I don't.  I can't get to the web page to see if
> there is any in inventory.  If there is I will.
> 
> I did look at the AD9862 and the USRP circuit.  I have a connector to make
> contact to the J666 pins 62 and 60 which feeds the AD9862 VINP_A and VINN_A.
> I worked out the interface but can't get past the codes that check for the
> eeprom on the daughterboard.

Let me check on that later today. 

> Side but related question: How do you specify to the software if you are
> using J18 or J19 on the Basic RX DB?  J18 feeds the B inputs while J19 feeds
> the A inputs.

That's what the rx_subdev_spec is for.

  E.g., 

   $ usrp_fft.py -R a:0
   $ usrp_fft.py -R a:1


> Does the software automatically determine at which connecter
> there is an input and set's that has you data to process?

Nope.

> Is there any information on how to make your own DB (with eeprom for id) and
> input the parameters required by the software?

For the h/w design, look at Basic Rx or Basic Tx.

> You would need to have the possible slot_id for your board
> (SLOT_RX_A, SLOT_RX_B) and any other parameters like the offset.

Look at the schematics.  The boards are "plug and play".  The slot
number is effectively passed through the daughterboard connector.
Look at how the 3 address bits on the EEPROM are connected.  Compare
the Basic Tx to the Basic Rx.

> How should the eeprom be programmed?  I have
> found the daughterboard EEPROM format in usrp_i1c_addr.h.  I have been
> digging in this code way to much.

There's code to burn the daughterboard eeproms.  See
usrp/host/apps/burn-db-eeprom.  It also supports the "experimental_tx"
and "experimental_rx" daughterboard ID's.  Those are for experimental
use, like yours.

Regarding ADC offset correction:  the default values are stored in the
eeprom.  Use zero unless you've got a better idea.  We've found that
it's highly temperature sensitive.  In fact, since all of our
daughterboards block DC, there's a control loop in the FPGA that's
enabled by default, that computes an average value and subtracts it.
In your case, since you want to go to a pretty low frequency, you may
need to turn off that control loop.  This interface is exported to
Python, e.g. u.set_dc_offset_cl_enable(bits, mask)

  /*!
   * \brief Enable/disable automatic DC offset removal control loop in FPGA
   *
   * \param bits  which control loops to enable
   * \param mask  which \p bits to pay attention to
   *
   * If the corresponding bit is set, enable the automatic DC
   * offset correction control loop.
   *
   * <pre>
   * The 4 low bits are significant:
   *
   *   ADC0 = (1 << 0)
   *   ADC1 = (1 << 1)
   *   ADC2 = (1 << 2)
   *   ADC3 = (1 << 3)
   * </pre>
   *
   * By default the control loop is enabled on all ADC's.
   */
  bool set_dc_offset_cl_enable(int bits, int mask);


The OE value sets the initial configuration of the output enables to
the 16 digital bits on the daughterboard.  If you specify zeros, then
they are configured as inputs to the FPGA.  That the safest
configuration if you're not using them.

Eric