Hi Kevin,
I have been facing similar issues.
1. I tried the code similar to the one you posted on Github. It seems to
lower down the disconnects if I read from UART in one thread and process
the read data on another thread.
2. At times I saw that whenever the stream got closed IOIO was still
connected. Its just that the stream somehow got closed. You can test it
with a TRY/Catch. A BRUTE solution I am using is to restart the thread in
this situation which is reading the UART. So In the Main service setup() I
start all the threads. Then in loop() function I Check if all the threads
reading UART and IO's are alive. If any of them is dead due to an exception
but IOIO is still connected I re-init the thread.
THis seems to reduce the number of times the system used to die.
YTai: I have 7-8 IOIO's working with 2-3 different makes of Bluetooth
dongles. But it seems the disconnection still happens atleast 3-4 times
each day(my systems run 24x7). The flow for disconnections is similar to
what Kevin shared. You talked about Calibrating the Oscillators could you
share the link or give pointers where to search?
PS
On Monday, 5 December 2016 12:42:04 UTC+5:30, Kevin Miller wrote:
>
> 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> 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.
>>> To post to this group, send email to ioio-...@googlegroups.com.
>>> 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.
