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 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
