I believe to correct the bug you would change this line:
mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
.sendToTarget();
to this line:
mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1,
buffer.clone())
.sendToTarget();
On Thursday, November 15, 2012 9:05:42 AM UTC-6, bob wrote:
>
> Given your diagnosis, although this works, it doesn't sound theoretically
> sound.
>
>
> What makes more sense to me is to create a new buffer for every read and
> pass it to the UI thread.
>
>
>
> On Wednesday, November 14, 2012 8:48:53 PM UTC-6, tma wrote:
>>
>> Greetings,
>>
>> I have resolved the issue by adding a simple 2KB circular
>> buffer. The buffer input pointer is managed in the bluetooth thread and the
>> output pointer in the main thread. Seems to work perfectly for 600 byte
>> bursts of data at 56KBaud.
>>
>> TMA
>>
>> On Wednesday, November 14, 2012 12:23:34 AM UTC-8, tma wrote:
>>>
>>> Further to my last I also wonder if this problem could be resolved by
>>> changing thread synchronization?
>>>
>>> TMA
>>>
>>>
>>> On Wednesday, November 14, 2012 12:00:10 AM UTC-8, tma wrote:
>>>>
>>>> Greetings,
>>>>
>>>> I think I now have a much clearer understanding of what is
>>>> causing the problem but I don't know how to fix it.
>>>>
>>>> The ConnectedThread bluetooth input stream process is
>>>> overwriting the handler message buffer before the MainThread picks it up.
>>>> But the byte count lags behind the buffer update.
>>>>
>>>> ------------------------
>>>> For example, when the following string was received:
>>>>
>>>> "la50\r\n\r-9.8 dBm\n\r\n\r>"
>>>>
>>>> -The bluetooth input stream process first picked up only the
>>>> first three characters "la5", correctly assigned the string length of 3
>>>> and
>>>> sent the message via the handler.
>>>>
>>>> -Before the main thread picked up the message the bluetooth
>>>> input stream process picked up the 17 remaining characters and overwrote
>>>> the message character buffer.
>>>>
>>>> -When the main thread picked up the first message it got a
>>>> character count of 3 from the top of the que, picked up the first three
>>>> characters which were overwritten with "0\r\n", thus the "la5" is lost.
>>>>
>>>> - Then the main thread picked up the next 17 character message
>>>> in the que. It collected the remaining characters in the buffer which had
>>>> not been overwritten with new data. Three of the characters (characters in
>>>> buffer positions 0,1 and 2) ended up being sent to the screen twice.
>>>>
>>>> ---------------------------
>>>>
>>>> I am thinking about a double buffering/circular buffer fix
>>>> with hand shaking between threads but wonder if there is a simpler
>>>> approach.
>>>>
>>>> It seems inconsistent that the "bytes" variable that records
>>>> the length of the buffer string for each message is not overwriteen but
>>>> the
>>>> character buffer is. It would seem that there should be the equivalent of
>>>> a
>>>> circular buffer in the Handler. I wonder if there is an option? I wonder
>>>> if
>>>> the Handler is implemented properly here?
>>>>
>>>> Thanks in advance for any suggestions.
>>>>
>>>> TMA
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tuesday, November 13, 2012 9:50:06 AM UTC-8, tma wrote:
>>>>>
>>>>> Greetings,
>>>>>
>>>>> As an alternative, which was easier for me as I am new to
>>>>> Android and don't yet know how to direct this data to a file, I used the
>>>>> debugger to examine the contents of the bluetooth read buffer. I found
>>>>> initially, with a breakpoint on this mHandler.obtainMessage line, that
>>>>> the
>>>>> BT read buffer was missing the odd character. I then inserted a dummy
>>>>> line
>>>>> to make a place for a breakpoint, removed the handler message line and
>>>>> found found then that the buffer content was perfect without the handler
>>>>> call.
>>>>>
>>>>> After restoring the mHandler.obtainMessage line I decided to
>>>>> take a look at the incoming message buffer in the main thread and found
>>>>> it
>>>>> to be missing half or more of the characters.
>>>>>
>>>>> Thinking the problem might be caused by the itemized UI display I
>>>>> added an editText window and directed the message output to it. I
>>>>> observed
>>>>> the same sporadic, sporadic data result.
>>>>>
>>>>> I noticed that the BT buffer read cycles twice before the first
>>>>> handler message is picked up by the main thread. I also noticed that
>>>>> there
>>>>> is no corresponding "getTarget()" statement in this code to provide a
>>>>> target definition for the "sendToTarget" extension. I don't know how to
>>>>> add
>>>>> a "getTarget" statement or if it is even required here as inferred by the
>>>>> docs.
>>>>>
>>>>> In any event it appears as if the problem is associated with
>>>>> the Handler implementation. Is a handler the best option for sending data
>>>>> between threads? Could (or should) an intent be used instead?
>>>>>
>>>>> Thanks in advance for any help!
>>>>>
>>>>> tma
>>>>>
>>>>>
>>>>>
>>>>> On Friday, November 9, 2012 7:26:58 AM UTC-8, bob wrote:
>>>>>>
>>>>>> I would look at this line in BluetoothChatService.java:
>>>>>>
>>>>>> mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
>>>>>> .sendToTarget();
>>>>>>
>>>>>> I would change that line to write to a file on the SD card.
>>>>>>
>>>>>>
>>>>>> Then, after some time, I would look at the file to see if it contains
>>>>>> what it should.
>>>>>>
>>>>>> That should help you see if it's a UI thing or a comm thing.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thursday, November 8, 2012 6:14:32 PM UTC-6, tma wrote:
>>>>>>>
>>>>>>> Hi Bob,
>>>>>>>
>>>>>>> Thanks for your reply!
>>>>>>>
>>>>>>> I thought 56 kbps should be easily obtainable but
>>>>>>> didn't know what the upper limit might be. For testing I am using an
>>>>>>> Asus
>>>>>>> Transformer Prime which has a quad processor. I thought maybe the
>>>>>>> debugger
>>>>>>> might be slowing it down so I exported the apk, installed the app
>>>>>>> directly
>>>>>>> and turned USB debugging in my tablet off via "Settings", all to no
>>>>>>> avail. I presume that should have rid the app of possible debug
>>>>>>> delays???
>>>>>>>
>>>>>>> My app is data acquisition from an external device
>>>>>>> that will eventually be graphically displayed in a GUI window. I
>>>>>>> decided I
>>>>>>> wanted to display the data as text to start with and then move on to
>>>>>>> the
>>>>>>> graphics display.
>>>>>>>
>>>>>>> I don't have any problem displaying the data with
>>>>>>> SENA's bluetooth terminal software. Thus I am absolutely sure of the
>>>>>>> quality of the data and the BT interface.
>>>>>>>
>>>>>>> I am now considering the use of the Amarino
>>>>>>> bluetooth API which also is capable of capturing the data without a
>>>>>>> glitch.
>>>>>>> But it would result in another software tier that I would prefer to
>>>>>>> avoid.
>>>>>>>
>>>>>>> TMA
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, November 8, 2012 10:36:14 AM UTC-8, bob wrote:
>>>>>>>>
>>>>>>>> What are you trying to do with the data? Maybe you don't even need
>>>>>>>> to pass it to the UI thread?
>>>>>>>>
>>>>>>>>
>>>>>>>> In theory, I'm pretty sure there should be no throughput
>>>>>>>> limitations that would prevent your use case. I think it can handle
>>>>>>>> like
>>>>>>>> 700 kbps or something.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, November 8, 2012 12:05:33 PM UTC-6, tma wrote:
>>>>>>>>>
>>>>>>>>> Greetings,
>>>>>>>>>
>>>>>>>>> I am trying to adapt the BluetoothChat example engine to
>>>>>>>>> provide serial UART comms for an extenal device that provides 1000
>>>>>>>>> byte
>>>>>>>>> bursts of data at 56KBaud (bits/S). Unfortunately the SDK
>>>>>>>>> BluetoothChat
>>>>>>>>> example, which I imagine was just intended for keyboard messaging,
>>>>>>>>> hickups
>>>>>>>>> with a 56KBaud bursts. It appears to repeat the display of the same
>>>>>>>>> text
>>>>>>>>> six times or more before moving on to the next data. In the process
>>>>>>>>> it
>>>>>>>>> misses some data. It would seem the buffers are not being managed
>>>>>>>>> properly
>>>>>>>>> between the inputstream and UI threads.
>>>>>>>>>
>>>>>>>>> I wonder if anyone here can suggest what to do to fix
>>>>>>>>> this problem?
>>>>>>>>>
>>>>>>>>> Thanks in advance!
>>>>>>>>>
>>>>>>>>> TMA
>>>>>>>>>
>>>>>>>>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
