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
From: Eric Blossom <[EMAIL PROTECTED]>
To: Jared Jensen <[EMAIL PROTECTED]>
CC: [email protected]
Subject: Re: [Discuss-gnuradio] more issues with read_i2c
Date: Mon, 30 Jul 2007 15:44:13 -0700
On Mon, Jul 30, 2007 at 12:44:11PM -0400, Jared Jensen 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
_________________________________________________________________
http://liveearth.msn.com
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
