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
