Android Question Asyncstreams Bluetooth Connection Issue

[Taylor Chapman]

Hi there,

I am very new to B4A and am developing a remote control app that communicates with an Arduino Uno via the Bluetooth serial port. 5 bytes get sent in one direction or the other about 30msec minimum between packets. The writes from the tablet to the micro are working very well. I have question regarding the speed at which B4A can receive BT serial input and how to implement a timeout of some kind.

Originally we were using Asyncstreams in prefix mode and it seemed like it could keep up. However, we would occasionally receive only part of the packet ( we think) and all the following packets would become unsynced. For example if we received only 4 of the 5 bytes in our packet then the following packet would scoop the first byte to complete the prefix mode number of expected bytes and launch newdata. From a post we spotted prefix mode will simply wait until it gets the expected number of bytes without any timeout. Please set us straight if that is not the case! Is it possible to implement a timeout and clear the unfinished data packet so it will be ready for the next packet to come in?

We couldn't see anyway to do this in prefix mode and so we are currently trying the non-prefix version of asyncstreams. While prefix mode would sure be easier to handle (since the entire packets is read in only one newdata event) we figured it might be the only way to implement a timeout. When we send the data slow enough it is able to keep up most of the time, though we still lose a packet every once in a while. But when we send the data packet quickly (once every 30 milliseconds or so) we get the following error message: "Sending message to waiting queue" and then after some time "Ignoring Event (too many queued events: astreams_newdata)".

Any help or suggestions would be very much appreciated! Feel free to request any further details such as specific code / logs.

Thanks!
Taylor

 

[KitCarlson]

I use Bluetooth with AVR embedded system at 115.2 kbaud non prefix mode without problems.

Here are things that worked well for me.

The newdata event concatenates packets, checks for start and end, then processes. Then it deletes processed packet from buffer. The integrity of handling newdata received bytes is very important.

The tablet commands are mostly small packets for soft buttons and timer requests for information from the embedded side. The embedded packet back to the tablet, contains information about the packet, so the tablet can process properly. The tablet updates numeric values, plots data, data logs .... I have not experience problems with data logs happening, along with real time plots, numeric updates, navigation of modes and tables on embedded side via tablet soft button controls.

From a user interface 50 mS response is often good enough. I have found timers set to less than 100 mS have jitter, but that is likely an Android issue.

The B4A application was similar to an already debugged and tested VB6 rs232 application in conjunction with embedded system.

I use a Saleae Logic analyzer to capture both rx, tx at the TTL embedded side, to insure confidence there.

 

[Erel]

Sending message to waiting queue

This message appears when the activity that is handling the event is paused. You should use a Service to manage the communication.

It is not possible to clear the "buffer" in prefix mode. Your only option is to restart the connection.

 

[Taylor Chapman]

I've resolved this issue and I am just posting a follow up for anyone that's interested.

Firstly, the slow connect speed was due to the fact that I had accidentally initialized asyncStreams in two separate activities - now I am using a service to manage bluetooth and it works much faster.

I have decided not to use prefix mode because it is necessary for me to clear the buffer if the data becomes unsynced. Currently I am running a 50ms timeout that clears the buffer if I have not received a full packet. This is working well.

Thanks for your replies!
Taylor