[Top][All Lists]

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

[Discuss-gnuradio] more issues with read_i2c

From: Jared Jensen
Subject: [Discuss-gnuradio] more issues with read_i2c
Date: Mon, 30 Jul 2007 12:44:11 -0400

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 
                return false;
        nStatus[0] = (int)retbuf[0];
        nStatus[1] = (int)retbuf[1];

        printf("READ_STATUS read_i2c result : [0x%x, 
        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.


Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01

reply via email to

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