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.

Reply via email to