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 android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
