BluetoothInputStream read problem

[Lee Surprenant]

I downloaded bluecove and was able to set up the tests and samples with no issues.  However, I now have a problem using bluecove 1.2.2 for reading byte streams from low-level client devices (through an SPP service).

I have been using the opened BluetoothInputStream.read(byte[] b, int off, int len) method to read in a buffer and must send back a response quickly after receiving the whole message.  However, I have found that although I read all the bytes successfully, I later obtain
java.io.IOException: Failed to write
    at com.intel.bluetooth.BluetoothPeer.send(Native Method)
    at com.intel.bluetooth.BluetoothOutputStream.write(BluetoothOutputStream.java:81)

However, by reading the device spec, I discoverred that if I use len=the exact size of the data packet for my read, then everything works perfectly.  Only problem is the messages vary in length depending on the mode of the device, and as mentioned in the doc the InputStream.available() returns 0 all the time.

Is this a defect in bluecove, in windows, or is there a known workaround for this scenerio?

thanks,

Lee

[Vlad Skarzhevskyy]

The "InputStream.available() returns 0" is bug in bluecove and is
documented. I know how to fix this but I had no time to do so
recently.

the work around is to write message len before message and read it in client.

Also I used to have problem on some cell phone while reading and
writing data to BT stream at the same time from different threads. But
I'm not sure 100%.

--
Vlad

[lmsurprenant]

Vlad,

I tried sending this yesterday, but it doesn't seem to have gone
through. Apologies if this is a dup.

Thank you for the info and the quick response. Comments Inline...

On Mar 26, 11:28 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:

> The "InputStream.available() returns 0" is bug in bluecove and is
> documented. I know how to fix this but I had no time to do so
> recently.

This will be nice to have.

> the work around is to write message len before message and read it in client.

Unfortunately, I am working with a dumb device and therefor have no
control over the message. However, looks like I can determine the
type of message (and thus the length) after reading a number of
bytes. This would work but I would rather do processing away from the
serial connection (connection layer should just get bytes, not read
messages). Therefor this works but is not ideal.

> Also I used to have problem on some cell phone while reading and
> writing data to BT stream at the same time from different threads. But
> I'm not sure 100%.

My problem is that if the device does not receive a confirmation ack
message, it powers down and tries again later. However, I do not know
when to send this because the read() will simply block if there are no
bytes to be read. I was getting hit by some synchronization errors
previously, but have now successfully implement an additional "byte
queue" to effectively sychronize the two level of reads. That is, I
have a thread constantly reading and inserting bytes to the queue.
Then I use the size() method to determine how many bytes are ready to
be read.
This is the best I could come up with for now, but simply having the
"available()" method could bypass this (perhaps you could do something
similar under the covers of bluecove if you needed to?).

> --
> Vlad

Besides this issue, I have found blue-cove to be very useful and fun
to play with. Great stuff!

thanks,

Lee

[skarzh...@gmail.com]

This bug would be fixed in version 1.2.3
Just added the code to SVN
will use function: ioctlsocket

InputStream.available()
returns the amount of data that can be read in a single call to the
read() function, which may not be the same as the total amount of data
queued on the socket.