On the log, the first highlighted lines, #921 - 924, say "IOIO
disconnected, Physical disconnect, and V/BluetoothIOIOConnection: Client
initiated disconnect" . That's not evidence of a disconnect? I don't know a
lot about the very low-level stuff, so perhaps I'd made some incorrect
assumptions.
I will include the methods that catch (sometimes just before _flush() is
called and sometimes in _flush(), as this LogCat shows) the
"java.io.IOException: Stream has been closed", but a couple notes on the
Logcat:
- Note: When I debug and single-step - it does not fail.
- The IOIOService is on a separate thread from the main thread.
- The LogCat messages with the S2Handler.* tag are from the IOIOService.
- The device handler is on another thread, and its Logcat tags are
RpLidar.*
- The IOIO Service loop calls RpLidar.connect(UART uart) via a messenger
and passes a reference to the Uart configured in the IOIOService setup()
- The RpLidar.connect sends a reset command to the Lidar and
receives some ASCII info from the Lidar such as serial number, etc.
- So far, so good.
- At about this point, the "IOIODisconnected" message is thrown, line
921 on LogCat
- It looks like the IOIO disconnected while receiving the data because
there's only 20 bytes available when normally it's 57 (line 941)
- In reset(), available() returns 20 just before _flush() is called.
Sometimes, a NullPointer Exception is thrown on the InputStream.available()
here.
- In this LogCat, the error is in _flush().
- Inside _flush() InputStream.available() and InputStream.read()are
called from the same try block and IOException "Stream has been closed" is
thrown. (line 942)
Here is the flush method:
private void _flushInput()
{
String TAG = "RpLidar._flushInput";
final int arrSize = 1000; // assume no more than this many characters in
response
byte[] readBuffer = new byte[arrSize];
try
{
while( _inputStream.available() > 0 )
_inputStream.read( readBuffer );
} catch (IOException e) {
e.printStackTrace();
Log.d(TAG,e.getLocalizedMessage()); //line 956 in LogCat
}
}
Here is the reset() method that calls _flush(). It's go a lot of waits and
sleeps and yields because of troubleshooting in progress:
/**
* Reset(reboot) the RPLIDAR core
* No response is defined in documentation, but testing shows some text is
returned
* and is flushed - See comments for details.
* @return true if command was placed in queue
*/
public synchronized boolean reset(){
String TAG = "RpLidar.reset";
Log.d(TAG, "Starting...");
//make sure IOIO is connected
if(!isOpen()) return false;
RplRequest req = getRplRequest(RequestTypes.RESET);
if(req==null){
Log.d(TAG,"FAIL: req = null");
return false;
}
if (!doRplRequest(req)) {
Log.d(TAG,"FAIL: doRplRequest failed");
return false;
}
//troubleshooting
// long timeoutMs = System.currentTimeMillis()+1000;
// while (System.currentTimeMillis() < timeoutMs){
// Thread.yield();
// }
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
Log.d(TAG,"FAIL: Sleep interrupted");
return false;
}
Log.d(TAG,"Before flush...");
try {
Log.d(TAG,"... inputStream.avail = "+_inputStream.available());
} catch (IOException e) {
e.printStackTrace();
Log.d(TAG,"FAIL: IO Exception");
return false;
} catch (NullPointerException e){
//why is this happening? BT Disconnect?
e.printStackTrace();
Log.d(TAG,"FAIL: InputSteam NullPointerException");
return false;
}
_flushInput();
try {
_outputStream.flush();
} catch (IOException e) {
e.printStackTrace();
Log.d(TAG,"FAIL: Sleep interrupted");
return false;
}
Log.d(TAG,"After flush...");
try {
Log.d(TAG,"... inputStream.avail = "+_inputStream.available());
} catch (IOException e) {
e.printStackTrace();
Log.d(TAG,"FAIL: Sleep interrupted");
return false;
}
Log.d(TAG,"Return: SUCCESS");
return true;
}
Sometimes an exception is thrown in reset just before flush, so because the
timing varies a little, it seems that the problem is external to _flush()
because the exception is sometimes before _flush starts.
I will try the calibration when I can. I do not have another BT dongle that
works with the IOIO, but I'll ask around.
I hope you see something.
Thanks,
Kevin
On Monday, December 5, 2016 at 12:05:59 AM UTC-5, Ytai wrote:
>
> I would try a different dongle and/or recalibrate the IOIO oscillator as
> described in the wiki under calibration wipe. I've seen cases where data
> losses occur silently with some dongle/phone combination, resulting in a
> disconnect.
> From your logs I see no evidence of disconnects though. Would you share
> your code?
>
> On Dec 3, 2016 8:52 PM, "Kevin Miller" <ksmil...@gmail.com <javascript:>>
> wrote:
>
>> It looks like the problem is related to Bluetooth after all. When I use
>> the UART for several exchanges, the Bluetooth disconnects 6 times out of
>> 10. See attached Logcat.I've tried two different phones.
>>
>> I see others have had similar issues. Any suggestions? I only need
>> Bluetooth for debugging, but I'm dead in the water now.
>>
>> Kevin
>>
>> On Wednesday, November 30, 2016 at 5:54:17 PM UTC-5, Kevin Miller wrote:
>>>
>>> Hello,
>>> I've got a really big project nearing completion, but now that I'm
>>> getting into the fine details of UART communication, I'm having a problem
>>> with frequent disconnect()/setup() cycles which is interfering with the
>>> serial communications. I'm using Bluetooth for developing, but I don't
>>> think that is the cause because when I run the basic HelloIOIOService
>>> example, it is rock solid. What other reasons could be causing the
>>> disconnect? Is there some way to dig deeper to see what is causing the
>>> disconnects?
>>>
>>>
>>> Thanks,
>>> Kevin
>>>
>>> --
>> 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 ioio-users+...@googlegroups.com <javascript:>.
>> To post to this group, send email to ioio-...@googlegroups.com
>> <javascript:>.
>> Visit this group at https://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 ioio-users+unsubscr...@googlegroups.com.
To post to this group, send email to ioio-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.
