IOIO disconnected log but IOIO is connected

[kolbe]

I have a IOIO connected by USB ADB that from time to time loses the connection and sends out the IOIOProtocol - IOIO disconnected log. When the program tries to reconnect it the waitforconnect blocks indefinitely "Socket IOIO Connection - waiting for TCP" log until I physically unplug and reconnect the IOIO at which point it reconnects happily and the program continues. Since I want the program to run nonstop, this unplugging won't do. I don't think it is a power problem as no pin is drawing more that 5mA and the totals are fine. I've monitored Vin and it also stays constant. The device is powered externally so there is not charging being done by the IOIO.

From the IOIOLib code below, it looks like the IOIO stops receiving data from the device. If this is the case then the problem is device side, no? Although I'd rather it not disconnect, the fact that it won't reconnect and blocks (ANR) without physically disconnecting and reconnecting is troublesome. I need some light on what might be going on and possible solutions?

    private void fillBuf() throws IOException {
            try {
                validBytes_ = in_.read(inbuf_, 0, inbuf_.length);
                if (validBytes_ <= 0) {
                    throw new IOException("Unexpected stream closure");
                }
                //Log.v(TAG, "received " + validBytes_ + " bytes");
                readOffset_ = 0;
            } catch (IOException e) {
                Log.i(TAG, "IOIO disconnected");
                throw e;
            }
        }

[kolbe]

I've got that backward. The disconnect is coming from the device so the data expected from the IOIO is not arriving. Something must then be blocking on the IOIO and doesn't get reset until I unplug and reconnect. As to the cause the only thing I can think of is a power glitch of some kind but I've checked and rechecked.

[Ytai Ben-Tsvi]

I'm often running the IOIO for hours or even days without any drops, and stressing it quite a lot (using the torture test).

Moreover, if I force a disconnect condition (e.g. by sending an invalid protocol message), the connection drops and immediately gets reestablished.

So I'm guessing the problem may be related to either one of these issues:

1. Something about your application that my tests don't cover or that really annoys your Android. Please shed some light on what the application does, or otherwise let me know whether it also happens with one of the example apps.
2. Something about your Android version is non-standard / buggy in the USB or ADB layer. Which Android device / OS version are you using?
3. Electrical issues: faulty or over-long USB cable, worn out connectors, faulty IOIO board, faulty trimmer or bad setting on the trimmer (should be all the way clockwise and make sure you don't go pass the stopper that tends to break if over stressed), faulty 5V regulator, etc.

Also, I'm curious, do you have a logcat of when the disconnects occur?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/3oOCDS4R8bYJ.

To post to this group, send email to ioio-...@googlegroups.com.
To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ioio-users?hl=en.

[kolbe]

I'm leaning towards #1 at the moment. Before I bother you with more details let me investigate a problem with perhaps the wait procedure I'm using. Just briefly... I'm controlling a stepper via a controller, and doing various other tasks like reading switches, voltages, and flashing leds. I'm doing this in Basic4Android and for timing purposes I'm using it's "DoEvents" in a loop. I just realized that the "DoEvents" only allows the processing of Basic4Android UI messages. I'm guessing that from time to time if my wait is too long and the communication with the IOIO is somehow interrupted. Does this sound plausible?

On Saturday, April 28, 2012 7:20:23 AM UTC+2, Ytai wrote:

I'm often running the IOIO for hours or even days without any drops, and stressing it quite a lot (using the torture test).

Moreover, if I force a disconnect condition (e.g. by sending an invalid protocol message), the connection drops and immediately gets reestablished.

So I'm guessing the problem may be related to either one of these issues:

1. Something about your application that my tests don't cover or that really annoys your Android. Please shed some light on what the application does, or otherwise let me know whether it also happens with one of the example apps.
2. Something about your Android version is non-standard / buggy in the USB or ADB layer. Which Android device / OS version are you using?
3. Electrical issues: faulty or over-long USB cable, worn out connectors, faulty IOIO board, faulty trimmer or bad setting on the trimmer (should be all the way clockwise and make sure you don't go pass the stopper that tends to break if over stressed), faulty 5V regulator, etc.

Also, I'm curious, do you have a logcat of when the disconnects occur?

On Fri, Apr 27, 2012 at 3:43 AM, kolbe  wrote:

I've got that backward. The disconnect is coming from the device so the data expected from the IOIO is not arriving. Something must then be blocking on the IOIO and doesn't get reset until I unplug and reconnect. As to the cause the only thing I can think of is a power glitch of some kind but I've checked and rechecked.

On Friday, April 27, 2012 9:47:36 AM UTC+2, kolbe wrote:

I have a IOIO connected by USB ADB that from time to time loses the connection and sends out the IOIOProtocol - IOIO disconnected log. When the program tries to reconnect it the waitforconnect blocks indefinitely "Socket IOIO Connection - waiting for TCP" log until I physically unplug and reconnect the IOIO at which point it reconnects happily and the program continues. Since I want the program to run nonstop, this unplugging won't do. I don't think it is a power problem as no pin is drawing more that 5mA and the totals are fine. I've monitored Vin and it also stays constant. The device is powered externally so there is not charging being done by the IOIO.

From the IOIOLib code below, it looks like the IOIO stops receiving data from the device. If this is the case then the problem is device side, no? Although I'd rather it not disconnect, the fact that it won't reconnect and blocks (ANR) without physically disconnecting and reconnecting is troublesome. I need some light on what might be going on and possible solutions?

    private void fillBuf() throws IOException {
            try {
                validBytes_ = in_.read(inbuf_, 0, inbuf_.length);
                if (validBytes_ <= 0) {
                    throw new IOException("Unexpected stream closure");
                }
                //Log.v(TAG, "received " + validBytes_ + " bytes");
                readOffset_ = 0;
            } catch (IOException e) {
                Log.i(TAG, "IOIO disconnected");
                throw e;
            }
        }

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/3oOCDS4R8bYJ.

To post to this group, send email to ioio-...@googlegroups.com.

To unsubscribe from this group, send email to ioio-users+unsubscribe@googlegroups.com.

[Ytai Ben-Tsvi]

I have no idea how the B4A IOIO library works, specifically whether it is a wrapper around IOIOLib or a modified version of IOIOLib. If the former is true, there should be nothing you could do to cause the connection to drop, unless the CPU gets overloaded and starves the IOIO reader thread. If the latter is true, I would check with the people who made the modifications whether any restrictions apply.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/c7gangx8bLkJ.

To post to this group, send email to ioio-...@googlegroups.com.

To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.

[kolbe]

I've attached a log of the disconnect and the B4A IOIO library wrapper. The log is just simply the disconnect I'm talking about, here no attempt is made to reconnect. I'll get that later today.

The B4A IOIO library is mostly just a wrapper except for the initialize method. Since B4A creates the activity I just need an valid instance of ioio. I'm open to suggestions if there is a beter way to do it than what I've done.

Removing the DoEvents I mentioned below has helped but I still get the physical disconnects w/o disconnecting the IOIO.

[Ytai Ben-Tsvi]

I don't know. The wrapper does seem trivial, and the log doesn't reveal anything suspicious. Do you know whether the IOIOLib used by B4A is unmodified? Do you know which version it is?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/KQDnO4Jik-QJ.

[kolbe]

The IOIOLib is not modified. I'm using 3.23

I'm beginning to see the pattern that the disconnect happens shortly after a service starts and IOIO calls are made. Is using the IOIO in a service any different that in an activity?

08:58:43.152 <24414>[IncomingState]: IOIO Connection established. Hardware ID: SPRK0016 Bootloader ID: IOIO0303 Firmware ID: IOIO0323

On Tuesday, May 1, 2012 6:21:00 AM UTC+2, Ytai wrote:

I don't know. The wrapper does seem trivial, and the log doesn't reveal anything suspicious. Do you know whether the IOIOLib used by B4A is unmodified? Do you know which version it is?

To unsubscribe from this group, send email to ioio-users+unsubscribe@googlegroups.com.

[Ytai Ben-Tsvi]

I lost you here: which service is started and which IOIO calls do you mean? Sorry, it's probably a B4A thing that I'm not familiar with.

If you're asking in general about the difference between IOIOActivity and IOIOService, aside from the fundamental differences between an Activity and a Service, their IOIO-related stuff is the same.

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/J1HdLbLDvXgJ.

To post to this group, send email to ioio-...@googlegroups.com.

To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.

[kolbe]

Sorry for the ambiguity, I'm am talking about from within B4A. In B4A using the library wrapper I make "calls" to the IOIO. ioio.waitforconnect, ioio.opendigitalio(...), ioioled.read, etc. All the IOIOlib api is called from within a B4A program.

It appears that the problem disconnect happens most often when a scheduled B4A service starts and then that service makes calls, using the wrapper library, to the IOIOlib api. If I don't reschedule the service and just use timers to time the calls, the disconnects happens much less often.

I'm thinking that "IOIO reader thread" that you mention below might actually be running on the same thread as B4A. Given the implementation I sent of the B4A IOIOlib wrapper is this possible? Do the api explicitly call a new thread when communicating with the IOIO? I can say with certainty that the wrapper code runs on the same thread as B4A. Perhaps a clearer way of putting it is... is the IOIOlib all running on the same thread because I'm not using helper utilities and am calling the api directly?

On Wednesday, May 2, 2012 5:41:01 AM UTC+2, Ytai wrote:

I lost you here: which service is started and which IOIO calls do you mean? Sorry, it's probably a B4A thing that I'm not familiar with.

If you're asking in general about the difference between IOIOActivity and IOIOService, aside from the fundamental differences between an Activity and a Service, their IOIO-related stuff is the same.

[kolbe]

I see IOIOlib has a thread for each IOIO connected... trying to do something similar with the B4A library.

[Ytai Ben-Tsvi]

Oh, I have w guess then. Trying to read from UART or doing any other blocking operation from the UI thread in Android is prohibited. I had no idea this is how your app worked. Could this be it?

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/0iOwm4samIAJ.

To post to this group, send email to ioio-...@googlegroups.com.

To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.

[kolbe]

To bring closure to this thread... the problem was mainly a bad device usb socket (cold solder I would imagine). Because it was intermittent it wasn't obvious at first. I eventually starting having problems even connecting to the PC. After swapping the device with a new one this problem went away. There where some threading problems too but I think I've got those fixed.

Thanks for the help.

On Friday, May 4, 2012 2:21:22 AM UTC+2, Ytai wrote:

Oh, I have w guess then. Trying to read from UART or doing any other blocking operation from the UI thread in Android is prohibited. I had no idea this is how your app worked. Could this be it?

[Ytai Ben-Tsvi]

Good catch!

To view this discussion on the web visit https://groups.google.com/d/msg/ioio-users/-/1t4YPQXjxYoJ.

To post to this group, send email to ioio-...@googlegroups.com.

To unsubscribe from this group, send email to ioio-users+...@googlegroups.com.

[Greg Gradwell]

Ytai,

What's a good way to force a disconnected condition? You mentioned sending an invalid protocol message, but I don't know exactly what that means.

[Ytai Ben-Tsvi]

You can call ioio_.disconnect(), but I find it hard to imagine cases where you'd want to do this explicitly. It is normally handled for you by the IOIO application framework.

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 http://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/groups/opt_out.