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.

On Sat, Jan 31, 2015 at 6:01 PM, Paul McMahon <[email protected]>
wrote:

> 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.
>
>
>
> On Saturday, January 31, 2015 at 3:10:50 PM UTC-5, Paul McMahon wrote:
>>
>> 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
>>
>>
>> On Wed, Jan 21, 2015 at 12:11 AM, Ytai Ben-Tsvi <[email protected]> wrote:
>>
>>> 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.
>>>
>>>  --
> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to