The sensor might be clock stretching forever. On May 9, 2014 10:22 AM, "Alexander Bashmakov" <[email protected]> wrote:
> Hi Ytai, > > I haven't had a chance to get a hold of a logic analyzer, but I did make > some progress. For a while I was getting valid data from the sensor, but > then something happened and I'm back to a state where the writeRead blocks > forever either on the first or the second call. Inside TwiMasterImpl, the > waitReady()->safeWait() call never returns. Do you have any idea what could > be causing this? > > On Wednesday, May 7, 2014 9:51:26 AM UTC-7, Alexander Bashmakov wrote: >> >> Thanks for your suggestions. I will try the logic analyzer option. >> >> On Wednesday, May 7, 2014 8:44:17 AM UTC-7, Ytai wrote: >>> >>> 0x27 is the right address. >>> There may be several possible reasons for getting 'false': >>> >>> - Electrical issues: bad wiring, bad sensor, wiring to the wrong >>> IOIO or device pins, missing pull-ups, etc. The ideal way to check this >>> is >>> with a logic analyzer or an oscilloscope. If you don't have access to >>> such, >>> trial and error... >>> - Software issues: using the wrong device address, an overly high >>> bus speed, the wrong bus number, unsupported protocol. >>> >>> Note that because the sending of one byte is a hack, it might be normal >>> for this transaction to return false (i.e. the device NACKs it on purpose). >>> The second one should work though. >>> Another thing to check is power cycling the sensor itself. I've seen I2C >>> sensors from Honeywell (not this specific one) get stuck in various nasty >>> bad states, which are sometimes (but not always) recoverable by >>> power-cycling. >>> >>> >>> On Tue, May 6, 2014 at 7:02 PM, Alexander Bashmakov >>> <[email protected]>wrote: >>> >>>> I'm using a breakout board which already has the resistors: >>>> >>>> https://www.sparkfun.com/products/11295 >>>> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Weather/HIH6130_ >>>> Breakout_v10.pdf >>>> >>>> The documentation says the Measurement Request command consists of the >>>> 7-bit slave address followed by a write bit = 0. The Data Fetch command is >>>> the slave address followed by a read bit = 1. Given that the default slave >>>> address should be 0x27, does that mean I have to pass 0x4E and 0x4F in the >>>> address argument for the two writeRead() calls respectively? I tried that, >>>> but still got a false result for both calls. >>>> >>>> >>>> On Tuesday, May 6, 2014 6:54:57 PM UTC-7, Ytai wrote: >>>> >>>>> Have you wired pull ups correctly? >>>>> On May 6, 2014 6:27 PM, "Alexander Bashmakov" <[email protected]> >>>>> wrote: >>>>> >>>>>> I tried the following code: >>>>>> >>>>>> byte[] request = new byte[] {0x00}; >>>>>> boolean result = mTwi.writeRead(0x27, false, request, >>>>>> request.length, null, 0); // Read buffer is null, read length is 0 >>>>>> Log.i("MR command result: " + result); >>>>>> Thread.sleep(100); >>>>>> byte[] response = new byte[4]; >>>>>> result = mTwi.writeRead(0x27, false, null, 0, response, >>>>>> response.length); // Write buffer is null, write length is 0 >>>>>> Log.i("DF command result: " + result); >>>>>> >>>>>> In this case, both calls to writeRead() return false. I'm fairly >>>>>> stuck at this point. >>>>>> >>>>>> On Tuesday, May 6, 2014 5:41:16 PM UTC-7, Ytai wrote: >>>>>>> >>>>>>> I think your second transaction needs to be read-only (i.e. >>>>>>> writeLength = 0). >>>>>>> Note that for both read and write buffers, if the length is 0 the >>>>>>> buffer can be null (you don't need the funny zero-length array). >>>>>>> >>>>>>> >>>>>>> On Tue, May 6, 2014 at 5:13 PM, Alexander Bashmakov < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Some more progress made, new code: >>>>>>>> >>>>>>>> >>>>>>>> byte[] request = new byte[] {0x00}; >>>>>>>> byte[] response = new byte[0]; >>>>>>>> Log.i("Sending MR command"); >>>>>>>> boolean result = mTwi.writeRead(0x27, false, request, >>>>>>>> request.length, response, response.length); >>>>>>>> Log.i("MR command result: " + result); // result is true >>>>>>>> after power cycling >>>>>>>> Thread.sleep(100); >>>>>>>> request = new byte[] {0x01}; >>>>>>>> >>>>>>>> response = new byte[4]; >>>>>>>> Log.i("Sending DF command"); >>>>>>>> result = mTwi.writeRead(0x27, false, request, request.length, >>>>>>>> response, response.length); >>>>>>>> Log.i("DF command result: " + result); // result is >>>>>>>> false >>>>>>>> >>>>>>>> I am struggling to understand what should the value of the second >>>>>>>> request be for Data Fetch. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, May 6, 2014 2:27:54 PM UTC-7, Alexander Bashmakov wrote: >>>>>>>>> >>>>>>>>> Hi Troy, >>>>>>>>> >>>>>>>>> Would you be able to post a sample of your working code? I'm also >>>>>>>>> trying to use HIT-6130 and having issues. Here's my code so far: >>>>>>>>> >>>>>>>>> byte[] request = new byte[] {0x00}; >>>>>>>>> byte[] response = new byte[0]; >>>>>>>>> Log.i("Sending MR command"); >>>>>>>>> boolean result = twi.writeRead(0x27, false, request, >>>>>>>>> request.length, response, response.length); >>>>>>>>> Log.i("MR command result: " + result); >>>>>>>>> Thread.sleep(100); >>>>>>>>> response = new byte[4]; >>>>>>>>> Log.i("Sending DF command"); >>>>>>>>> result = twi.writeRead(0x27, false, request, request.length, >>>>>>>>> response, response.length); >>>>>>>>> Log.i("DF command result: " + result); >>>>>>>>> >>>>>>>>> After the second writeRead, I get a ConnectionLostException and >>>>>>>>> the last log message never gets printed. Any help would be >>>>>>>>> appreciated. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wednesday, June 5, 2013 5:31:19 AM UTC-7, Troy Collinsworth >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Awesome sauce!!! That worked like a charm. Thanks for the quick >>>>>>>>>> response. >>>>>>>>> >>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "ioio-users" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To post to this group, send email to [email protected]. >>>>>>>> Visit this group at http://groups.google.com/group/ioio-users. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "ioio-users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at http://groups.google.com/group/ioio-users. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ioio-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/ioio-users. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "ioio-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/ioio-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
