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
