I don't think I've seen the situation where the stream closed but the IOIO
was still connected, but I will look for that specifically.
I'm not planning to use BT in production, I just need it for development
because the phone's USB is connected to the computer for debugging. If
there were
First, to both of you: I wouldn't use Bluetooth for something that needs to
work flawlessly 24/7. Not sure if the problem is the standard, the Android
stack, the IOIO stack, the dongles or whatever, but from my experience,
connection is not 100% reliable. If your code is tolerant to occasional
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
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
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
Perhaps I'm over-thinking the disconnect() function. What happens to the
UART and the data in the UART buffers when the IOIO disconnects? I'm
assuming that the UART configuration is lost, so I interrupt the thread
that's handling the device communications and reset everything. I could set
a flag
