External card connected to USRP board

GNU Radio
1

Hello,

I would like to develop a user card, to interface with the USRP
motherboard,
with a high resolution UHF synthesized local oscillator for a flexible
narrowband application that can not use any standard card. Is this
possible? Can I program the I2C/SPI chips through GNU radio? (The on
card ROM is not needed… I
suppose).Did someone allready try this?
Thank you,
Diana

2

On Wed, Apr 30, 2008 at 07:55:47PM +0200, Diana I. wrote:

Hello,

I would like to develop a user card, to interface with the USRP
motherboard,
with a high resolution UHF synthesized local oscillator for a flexible
narrowband application that can not use any standard card.
Is this possible?

Sure. Are you sure you can’t hook your UHF board up to a basic tx or
rx at least for prototyping? What’s your gadget’s IF?

If you’re sure you need a new board, take a look at the schematics for
some of the other daugtherboards. http://gnuradio.org/trac/wiki/USRP

Can I program the I2C/SPI chips through GNU radio?

Yes.

(The on card ROM is not needed… I suppose).

The ROM id’s the card to the system. You need it. It costs about
$0.50.

Did someone all ready try this?

People hook up all kinds of stuff to the USRP…

Thank you,
Diana

Eric

3

Sure. Are you sure you can’t hook your UHF board up to a basic tx or
rx at least for prototyping? What’s your gadget’s IF?

In fact what I need is to convert 2 CW coherent signals (beacon)IF in
UHF range (somewhere between 0.5 to 1GHz , through a very good phase
noise LO, depending on front end) to a new IF at 10.7 IF (it will be
crystal filtered and then routed by coaxial cable to basic RX card or
perhaps directly to motherboard).

If you’re sure you need a new board, take a look at the schematics for
some of the other daugtherboards. http://gnuradio.org/trac/wiki/USRP

%*********************************************************
Thats the problem. They are wide bandwidth cards and in my application
the signal has only 52dBHz CNR at best and signal power is contained
completely in a 50Hz bandwidth (so narrow bandwidth is at premium). That
is noise power would overload ADC’s and limit dynamic range. Also I am
interested in measuring the amplitude and relative phases (so no AGC at
all and other stuffs that can impair relative phases).
%***********************************************************

The ROM id’s the card to the system. You need it. It costs about
$0.50.

%**********************************************
Thanks. I know it’s a cheap component. Just wondering for the increased
complexity (mainly side effects!!). Please give me some clues (pointer
to information) to know what should be written in the ROM and
consequences in the devices programing.
%******************************************

Thank very much for answering my questions,
Diana

4

On Mon, May 05, 2008 at 06:40:32PM +0200, Diana I. wrote:

Thank very much for answering my questions,
Diana

The format of the ROM is documented in
usrp/firmware/include/usrp_i2c_addr.h.
Just be sure that bytes 0x00 through 0x02 make sense. You can set the
remainder to 0x00, but be sure to set the checksum correctly in 0x1f.
There’s a script that will do this for you over the USB.
See usrp/host/apps/burn-db-eeprom.

The relevant portion is:

// format of daughterboard EEPROM
// 00: 0xDB code for ``I’m a daughterboard’’
// 01: … Daughterboard ID (LSB)
// 02: … Daughterboard ID (MSB)
// 03: … io bits 7-0 direction (bit set if it’s an output from
m’board)
// 04: … io bits 15-8 direction (bit set if it’s an output from
m’board)
// 05: … ADC0 DC offset correction (LSB)
// 06: … ADC0 DC offset correction (MSB)
// 07: … ADC1 DC offset correction (LSB)
// 08: … ADC1 DC offset correction (MSB)
// …
// 1f: … negative of the sum of bytes [0x00, 0x1e]

#define DB_EEPROM_MAGIC 0x00
#define DB_EEPROM_MAGIC_VALUE 0xDB
#define DB_EEPROM_ID_LSB 0x01
#define DB_EEPROM_ID_MSB 0x02
#define DB_EEPROM_OE_LSB 0x03
#define DB_EEPROM_OE_MSB 0x04
#define DB_EEPROM_OFFSET_0_LSB 0x05 // offset correction for ADC or
DAC 0
#define DB_EEPROM_OFFSET_0_MSB 0x06
#define DB_EEPROM_OFFSET_1_LSB 0x07 // offset correction for ADC or
DAC 1
#define DB_EEPROM_OFFSET_1_MSB 0x08
#define DB_EEPROM_CHKSUM 0x1f

#define DB_EEPROM_CLEN 0x20 // length of common portion of eeprom

You can use the the existing “Experimental Rx” daughterboard id, 0xffff,
or define a new one. See usrp/host/lib/legacy/usrp_dbid.dat

The dbid is read from the daughterboards and is use to instantiate the
correct daughterboard code. You can see what you’ve got by calling
u.daughterboard_id(0) and u.daughterboard_id(1) to retrieve the dbid’s
from slots 0 and 1.

To talk to your daughterboard using our standard interface, you’ll
need to write a bit of python. Take a look at gr-usrp/src/db_*.py.
Start with db_base.py, then maybe db_basic.py

Eric