09-18-2008 10:25 AM
Does setting a server-side BluetoothSerialPort's flow control to something other than .._NONE actually make any difference? That is, does it really provide flow control?
If so, do BluetoothSerialPort.write calls actually either:
I'm currently using the Connector.open("btspp://blahblahblah...) type of BTSPP, and I'm seeing data interleaved, especially if I call flush() on the output stream. I'm also seeing it interleaved (or overwritten) on the incoming data, so it seems to me that the Connector BTSPP code isn't using any flow control.
I want to know if I should bother using BluetoothSerialPort instead of the Connector API. If there is no flow control, then I have to implement my own, which hurts.
I'm programming for 4.2.1. I see this behavior on both 4.2.1 and 4.3 devices.
09-18-2008 03:33 PM
Are you performing any processing on the threads that are sending and receiving data? I recommend having a look at this article for an overview at processing I/O traffic.
How To - Process incoming data
Article Number: DB-00466
09-19-2008 03:08 PM
Thanks for your response. We've split out the Bluetooth Serial logic into its own program so that it's doing basically nothing other than serial IO. We run a test where:
- the PC sends 100 messages and the BB receives them
- the BB sends 100 messages and the PC receives them
- the PC and the BB send and receive 100 messages at the same time
Sometimes the whole test passes, but we still occasionally see the behavior I described earlier. It fails during the third test.
I've rewritten it using the net.rim.device.api.bluetooth API to no avail. Setting flow control seems to have no effect (we do set the flow control on both sides of the connection). I made sure to wait for BluetoothSerialPortListener.dataSent() before writing more data.
I really don't know what else to do. We haven't yet isolated the problem to the BB itself, so our PC's BT stack is still a suspect, but it's very hard to debug this particular problem.
Do you have any more ideas I can try out?
09-22-2008 10:50 AM
09-22-2008 10:53 AM
Thanks for the idea. At the moment I'm backing my changes out to a point where the communication is slow enough that we only hit this occasionally. After that, I'll do this test and report back.
09-25-2008 04:55 PM
Ok, I was finally able to run some BB->BB tests, and they didn't fail. We've seen that speed influences failure rate, so we also did C++ test driving code on the PC, and it didn't fail. Our current theory is that the culprit is .NET's SerialPort class, and BB is solid.
Thanks for your help,