[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] more issues with read_i2c

From: Jared Jensen
Subject: Re: [Discuss-gnuradio] more issues with read_i2c
Date: Tue, 31 Jul 2007 13:38:10 -0400

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.


From: Eric Blossom <address@hidden>
To: Jared Jensen <address@hidden>
CC: address@hidden
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.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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]