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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
