More issues with read_i2c

GNU Radio
1

I’ve been having some issues with read_i2c. I noticed several posts
dealt
with this, and their particular solutions didn’t resolve the issue, so
here
it goes.

I ported bd_bds_rx.py and bd_basic.py to C++, along with usrp.py so I
could
include it all in my C++ signal processing app. Things in general work,
but
read_i2c doesn’t. I’m using a dbsrx on side B and using I2C_ADDR =
0x67. I
called _write_oe(0,0x0001,0x0001) and not write_io(…).

When I read_i2c I get 0x00 in the first byte and either 0x00, 0x02, or
0x04
in the second byte. I cast each byte to an int for us in the set_freq
function. (See code below.)

bool DBSRX::read_status(){
std::string retbuf = USRP_dev->read_i2c(I2C_ADDR,2);
if(retbuf.length() != 2){
printf(“ERROR : read_status returned length %d\n”,retbuf.length());
return false;
}
nStatus[0] = (int)retbuf[0];
nStatus[1] = (int)retbuf[1];

printf(“READ_STATUS read_i2c result : [0x%x,
0x%x]\n”,retbuf[0],retbuf[1]);
return true;
}

I’ve been pouring through the python code trying to find some
initialization
I’ve missed, or some setup or something, but I can’t spot anything. Any
clues on what may be causing this? Is there any documentation on what
the
actual data returned by read_i2c actually represents? I see that
db_dbs_rx.py shifts the lower byte down by 2 and calls it “adc_val”.
Any
more info on that? What adc property does that represent? Also, is the
second byte ever useful? I don’t see it used anywhere, but it usually
contains some data when I do a read_i2c. Thanks for any help.

Jared

Local listings, incredible imagery, and driving directions - all in one
place! Bing Maps - Directions, trip planning, traffic cameras & more

2

On Mon, Jul 30, 2007 at 12:44:11PM -0400, Jared J. wrote:

I’ve been having some issues with read_i2c. I noticed several posts dealt
with this, and their particular solutions didn’t resolve the issue, so here
it goes.

I ported bd_bds_rx.py and bd_basic.py to C++, along with usrp.py so I could
include it all in my C++ signal processing app. Things in general work,
but read_i2c doesn’t. I’m using a dbsrx on side B and using I2C_ADDR =
0x67. I called _write_oe(0,0x0001,0x0001) and not write_io(…).

class db_dbs_rx (db_base.db_base):
def init (self, usrp, which):
“”"
Control DBS receiver based USRP daughterboard.

    @param usrp: instance of usrp.source_c
    @param which: which side: 0 or 1 corresponding to RX_A or RX_B

respectively
@type which: int
“”"
# sets _u and _which
db_base.db_base.init(self, usrp, which)

    self._u._write_oe(self._which,0x0001,0x0001)
    self.i2c_addr = (0x67, 0x65)[self._which]

0x65 is the i2c_address for a DBSRX on the B side.
FWIW, 0x67 is for the A side.

Eric

3

D’oh! Typo. I’m actually on Side A, not B, and am using 0x67. Since
posting this, I started debugging and put in some debug statements in
usrp_prims.cc and rebuilt with make && make install. The issue was just
byte-ordering in the data buffer. I had guessed wrong as to how python
marshals data to/from C strings. Thanks for the help.

j0j

here
“”"
self._u._write_oe(self._which,0x0001,0x0001)
self.i2c_addr = (0x67, 0x65)[self._which]

0x65 is the i2c_address for a DBSRX on the B side.
FWIW, 0x67 is for the A side.

Eric

http://liveearth.msn.com