Programmatically reset ioio USB connection

[Andries Kruger]

Hi,

I've been using the IOIO for a few weeks now. I have a rooted phone that connects to the IOIO-OTG and I'm using the IOIOService to handle the board. Everything has been going pretty well. There is just one issue I am struggling to fix/workaround.

A little background: The phone will be installed in a vehicle where I don't have access to it. It will be collecting data as the driver goes on his way. I need to IOIO to start and work flawlessly without issues and if issues are detected, the phone should be able to fix itself. I've got this working pretty well now.

The issue I'm currently experiencing is that the IOIO gets disconnected from the phone (well sort off). The phone is being powered by the IOIO but the connection to the board is dead. It is kinda hard to replicate this problem but I have managed to do this by wiggling the USB connection and I think it might be caused by the vibrations in the vehicle. I do think I have a pretty good quality USB-OTG cable and the other cable is the stock Samsung cable that came with the phone. Eventually I'll try to solder the connections together but I would like to have some sort of way to fix the problem in the software should it occur. There are 3 things that fix the problem:

1) Enable/Disable USB Debugging

2) Cycle the power on the IOIO

3) Restart the phone

Restarting the phone will probably be the easiest solution but then we loose data for as long as it takes the phone to restart. I have no way of cycling the power on the IOIO without human intervention and it doesn't look like I can change the state of USB debugging even when I'm rooted.

Does anyone know of a way I can programmatically fix this?

PS: I have latest versions of firmware installed.

[Ytai Ben-Tsvi]

There are two main causes for what you're seeing:

1. The Android USB stack would sometimes not correctly detect and report a quick disconnect/reconnect event. And there are other annoying quality issues like that.
2. It is not immediately obvious how to have a Service register for connection events.

Not all is lost: it is very possible that there are software workarounds for said Android constraints that would result in a robust AOA connection. This issue has gotten to the point where it is important enough to enough people that I'm intending to take a serious look at it soon and assess what can be done.

As a last resort, it may be possible to enable a watchdog on the IOIO that would reset everything if it doesn't here from your app for a certain time and hopefully this would be able to recover from a lost connection under all circumstances regardless of how misbehaved Android is.

Feel free to look at the implementation of the AccessoryIOIOConnection yourself, or otherwise wait for updates from me.

--
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.

[Andries Kruger]

Thanks for the reply Ytai,

I wanted to avoid playing around in the firmware but maybe it will be worthwhile to do as you suggested. I also secured the USB cable connection a bit better. So far so good. Will keep testing though.

[Ionut Bungeanu]

you can try force USB to reset by updating sys.usb.config, something like

setprop sys.usb.config mtp,adb

from an adb root shell, or from java su process

ProcessBuilder pb = new ProcessBuilder(new String[]{"su", "-c","setprop mtp,adb"});

pb.redirectErrorStream(true).start();

you may need to adapt the code and replace mtp,adb with whatever getprop sys.usb.config returns when your connection is working normally.

@Ytai for accessory mode, is my impression that when a fast disconnect happens, UsbManager.getAccessoryList() will report two (or more) accessories, from which only one is good, but the IOIO framework I think it always assumes the first, and this is not always right.

[Ytai Ben-Tsvi]

Thanks for the insights!

Have you ever actually seen this list including more than one device? In any case, from previous tests it didn't seem like my app has any way of knowing that anything had changed at all, since I get no connect / disconnect events.

I'm considering a pretty serious workaround which involves having "keep-alive" functionality on both ends of the line, although even that might not suffice if the Android app is stuck on a read() and there's nobody on the other side to send anything.

--

[Ionut Bungeanu]

Yes, I did saw the list including more devices.

To overcome the issue with android not triggering an event/intent I have changed the wait() from waitForConnect() to wait(500), essentially pooling for the accessory (same for the device connection). When a fast reconnect happens is when you may end up with more than one accessory in the list.

Most probably this requires some changes in connection bootstrap open() method to not simply default to the first return accessory/device, and probably some changes in the state logic. (but I am sure you know better) 

USB attache intents are activity intents, where usb detach intents are broadcast intents. 

So instead off pooling, one can use an translucent activity to receive attach event in onCreate, and then simply finish (before setContentView, so the activity is actually never visible), and send the event down to IOIO connection manager.

I didn't follow any of this to a full working solution (time constraints), I decided to stick with USB connection. 

[Ytai Ben-Tsvi]

You probably missed my post about the topic. I think I've addressed most of those issues and the master branch on GitHub should have a version that is more reliable (no release bundle yet). Feel free to check it out and let me know if you're still seeing issues with it.

[Ionut Bungeanu]

I did not missed it. I already  took a look at the code, saw the changes to the manifest. Still need to make the time for some tests.

Thank you.

--
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/3rIOoc-QfrU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ioio-users+...@googlegroups.com.

[Gü]

Hi Andries,
I'm having the exact same setup and problems with apparently loosing the USB connection.
Unplug/Replugging the USB cable fixes this most of the time.

Have you found a better solution or workaround, and what does it look like?

Thanks and best regards

[Paul James]

Ytai - if you still monitor this group - did you ever put such a watch dog into firmware? This issue is significantly greater in android 6 than android 4. Unfortunately we had to move from 4 to 6, and now having major issues with our production system.

To unsubscribe from this group and stop receiving emails from it, send an email to ioio-...@googlegroups.com.

[Ytai Ben-Tsvi]

I haven't put a watchdog in the firmware. Shouldn't be hard to do for someone who knows what they're doing. Could be triggered either by an explicit command from the app (which will give you end-to-end) or to USB status (which will give you zero impact on the app on the expense of less coverage).

I'm probably not that someone unfortunately (for lack of availability).

To unsubscribe from this group and stop receiving emails from it, send an email to ioio-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ioio-users/ab4d7531-d1b7-4226-bcab-c7ec9f00ec41%40googlegroups.com.