Intermittent connectivity with the IOIO Board.

[Tim Frisch]

I have an application that is tied to the Activity's lifecycle. However the board when running with Open Accessory or even USB Debugging tends to intermittently drop.

I followed the pattern that was outlined by the post made here: https://groups.google.com/forum/#!msg/ioio-users/PlalZY9qse0/CoYF5IawGy4J

In order to support connection to the board across multiple activities.

Is the IOIO known to have connection troubles over a Micro A - Female - Male - Micro B connection? (Open Accessory)

Any advice/material to read on to learn more about having solid connection.

Thanks in advance guys.

[Tim Frisch]

From what I've discovered:

1. The app works fine over a genymotion/adb connection and produces no connectivity loss.

2. I am running a moto x 2013 (republic wireless) phone, and when connecting to AOA it states that it detects the app and launches it.

3. Upon launching the app - no connection is made or even attempted to be made from the looks of it to the ioio-otg.

Possible problems:

1. I did a forced re-write of the IOIO's firmware to the latest, did not solve the issue.

2. Cord problem - I tried multiple cables of differing lengths and even the officially supported sparkfun cables. No luck,

It seems that live tests just don't want to hold a stable connection?

[Ytai Ben-Tsvi]

It doesn't seem from your description that you're talking about an unstable connection, but rather a failure to connect.

It is most likely something with your app. Start with the pre-compiled HelloIOIO.apk, taken from the correct version of the software bundle (ideally, v5). If that works, try building it from source. If that works, compare it to your app. Possible pitfalls:

• Failed to link IOIOLibAccessory into your app.
• Forgot some manifest declarations.
• Forgot the manifest merging option in the project.properties file.

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

[Tim Frisch]

I had thought it would be that as well. However I have tried compiling a few of the apks you provide with no results.

I also had already enabled project manifest merger and compared my manifest files which were identical in structure.

[Tim Frisch]

Tried out the V5.04 pre-compiled HelloIOIO Apk and it worked. I will work my way down from there as you have said and if I figure it out or not I will report back here.

Thanks Ytai.

[Paul McMahon]

I also have intermittent connection issues--that is, intermittent ability to connect.

Even with the precompiled HelloIOIO program, I need to pause after cutting the power, before reapplying (same goes for the USB cable connection).

If the disconnect/connect happens quickly, no connection is made.  If I unplug again wait 2 seconds or more, then reconnect, it normally reconnects.

When it fails to connect, I get the notifications of a USB accessory (multiple of them), but the GUI doesn't get enabled. 

I've also seen the case where plugging in gets reported as "Connected as a media device" in the notification bar--with no IOIO connection established.  When in that state, it's repeatable until I power cycle the IOIO, making me think the firmware could be hung.

I don't think this was the case when I used ADB moce.

Ytai, do you not see this, when you unplug/replug quickly?  

[Ytai Ben-Tsvi]

I do see this. I don't know if this is fixable. To the best of my knowledge this is a bug with Android, where the disconnect event doesn't get generated in this case. There may or may not be a workaround. Maybe just polling periodically instead of relying on the event system.

--

[Paul McMahon]

What's the likelihood of implementing the RSA authentication to get secure ADB working?

--
You received this message because you are subscribed to a topic in the Google Groups "ioio-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ioio-users/dSISDjjariY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ioio-users+...@googlegroups.com.

[Ytai Ben-Tsvi]

If you're asking about the likelihood of *me* implementing it, it is probably fairly low. I'm open to patches, though.

[Tim Frisch]

My issue had been using old libraries. Yes the board has a hard time connecting initially sometimes. But when it does stay connected using the latest libraries seems to have fixed it dropping.

[Paul McMahon]

That is very interesting.  I've recently reverted my app back to version 3.26 of the libraries, because I have some users that have IOIO V1 boards, and those can't be upgraded to the latest firmware.  I hope I don't start to see the connection drop as you mention.  Which library version did you see that issue with?

Also--I found a workaround to the issue I highlighted below, regarding rapid power cycling or rapid cable disconnect/connect.  I found that inserting a two second wait at the beginning of the setup() routine seems to make the system impervious to rapid cycling.  I'd much rather have a self-timed approach rather than a fixed delay, but this is working for me right now.

Ytai, does that give you a clue--can you point me to an API call that I might use instead of a fixed delay?

thanks

[Ytai Ben-Tsvi]

I don't think Tim's original problem had anything to do with v3.26. The conclusion was that he was using an incompatible (too new) version of the client libraries and the wording "intermittent" was slightly misleading (Tim, correct me if I'm wrong). You should be just fine as far as connection reliability goes, but I do, in general, recommend upgrading to v5.x as there have been a few bugs that got fixed (see the release notes or the actual commit log and decide for yourself).

I find it surprising that waiting in the beginning of setup matters: setup() is called after the connection is already established. Can you try to further pin-point what's actually going on there by digging a little into the IOIOLibAccessory implementation? Overall, what's going on there is not very complicated and you should be able to get the hang of it.

[Tim Frisch]

How I meant originally was that I discovered I had been using too old, not too new of libraries. Re-syncing my github with the ioio master and re importing the libraries fixed my issue. Intermittent was an accurate word in my opinion as the connection to the board would break/disconnect "intermittently". Almost on queue.

[Paul McMahon]

Ytai,

I've been looking into AccessoryConnectionBootstrap, and was planning on adding some debug code, but I don't know how this can be done.  By definition, I need the phone to NOT be in ADB mode in order to trigger the AOA events, yet I need ADB mode to set breakpoints and things.

Is there some way you know of to debug AOA events?

I've been debugging with IOIObridge (which works fine), but it doesn't trigger any AOA activity, so I can't debug that.

I'd be interested in having some polling of state, rather than be event driven, so that's the type of change I'd like to pursue.

- Paul

[Paul McMahon]

Ytai,

I'm attaching 2 files here, a good example and bad one.  Each log shows the accessory connection processing, as well as the bytes passing back and forth across the interface.

In both cases, I see the IOIO wake up with the "establish connection" stream, which includes all the version numbers.

Then the phone sends the CHECK_INTERFACE code 0x02, and the IOIO0003 string.  In the passing case, IOIO responds with 0x2 0x1, indicating a version match, and we're off and running.

In the bad case, IOIO responds with 0x1 and sends the initial string all over again.

I haven't looked at the firmware code, but maybe you can tell me what that response is indicating?

thanks.

[Ytai Ben-Tsvi]

This is not a valid protocol. One thing that might explain this is that the IOIO got some corrupt data, which caused it to close the connection and immediately re-open it.

The leading 0x01 you're seeing is part of a meta protocol used only in AOA mode that works around the fact that AOA doesn't have the notion of opening and closing a connection to the accessory.

Since I don't believe it is very likely that data actually got corrupted at the USB level, it is more likely that a byte got discarded somewhere along the AOA stack, be it in the IOIO software / firmware or in the Android protocol stack.

If you want to dig deeper, you can try building the IOIO firmware with logging enabled, which would give you some diagnostics over a serial (UART) connection on one of the pins. This will allow you to know what things look like from the IOIO side.

[Paul McMahon]

OK, I've done quite a bit more debugging on this.

I first tried re-issuing the checkInterface command, and found that this did not recover the IOIO state.  Neither did issuing a SoftReset().  

But HardReset() does recover the link.  It causes my app to get re-launched, but that's an acceptable tradeoff for not being able to connect to IOIO at all.

I'm attaching the patch file here.   Changes are to IOIOImpl.java and IncomingState.java

Some explanation:

I found that when stuck in this state, it's the call to waitForInterfaceSupport that is hung, waiting on the state to change to Connected.  So I now ensure I'm already in the Connected state before calling that method, so I know it won't hang.  I issue the checkInterface in a loop ,checking for the state change manually before allowing it to proceed.   The check is via a new method in IncomingState.java called isEstablished().   I'm waiting 100ms after issuing HardReset, to give the system time to recover.

Also, I noticed some Null Pointer Exceptions inside handleSoftReset() when I was doing rapid power cycling.  I now have pointer checks at each step of that routine.

I'm not sure if you want to accept this change, but it's a decent workaround for me, so I thought I'd share this update.  If you think it's worthwhile, then we should probably limit the number of retry attempts, and throw an exception if the limit is reached.  In my experience, recovery is needed once per 10 or 20 cycles, and one retry is all that's ever needed.

[Ytai Ben-Tsvi]

Thanks for doing this work and sharing your results.

I really prefer not to push workarounds for problems that are not fully understood. Specifically I would prefer workarounds only once it is decided that a problem is out of our control to fix proper.

What might be helpful is to open a bug (on the GitHub issue tracker) specifying the observed problem and procedure for reproducing it.