Forum: GNU Radio more issues with read_i2c

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jared J. (Guest)
on 2007-07-30 20:49
(Received via mailing list)
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
Eric B. (Guest)
on 2007-07-31 02:44
(Received via mailing list)
On Mon, Jul 30, 2007 at 12:44:11PM -0400, Jared J. 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
Jared J. (Guest)
on 2007-07-31 21:39
(Received via mailing list)
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


>here
>         """
>         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
This topic is locked and can not be replied to.