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?
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?
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.
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?
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?
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?
> 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?
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?
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:
>> 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?
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:
>>> 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?
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.
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:
>>>> 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?
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:
>>>>> 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?
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:
>>>>>> 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?
