[Discuss-gnuradio] more issues with read_i2c

[Jared Jensen]

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! http://maps.live.com/?wip=69&FORM=MGAC01