Android Question bluetooth/serial problems

[TechEd]

Hi there

I have been struggling with this for many days now so I hope you can help me.
I have a PIC talking to a Acer Iconia B1.
I have written both programs so I use prefix mode. It is working fine almost.
The PIC is sending data (5 char) and Acer answer ACK (06H) PIC sends next data (5 char) and so on.
This can go on for up to between 4000-20000 trans. And suddenly the chat just stops. The android do send messages but do no react on incoming data. Is there a buffer overflow or something.
How should I debug this kind of problem.
I am using serial lib 1.23.
As I can see in doc. you say that B4A should send to host (PIC) in "prefix format", I don't think this is the case ? If I send a sting this will arrive to the PIC without any header.

TechEd

 

[Erel]

In prefix mode any message you sent is sent with the prefix header. Maybe this is the cause of this error?

Prefix mode is more fragile to interruptions (missing bytes for example).

Are you handling the terminated and error events?

 

[TechEd]

In prefix mode any message you sent is sent with the prefix header. Maybe this is the cause of this error?

Prefix mode is more fragile to interruptions (missing bytes for example).

Are you handling the terminated and error events?

I thought that the prefix mode was a robust protocol. I have tried the non prefix protocol and with same result.
Is there a way to detect if the receive event is disabled so you can reinitiate the serial.
I set a breakpoint at Astream_Newdata, restart the PIC, witch starts with sending message to android, but no reaction.
If there were missing bytes something should happen.
I have a button on android that send data and this is working fine.
I am running the PIC program with MPLABX so I can se exactly what is coming on the serial port.
When android sends ACK (char(06)) I receive only one char (06H) to PIC, no header.
The same if I send a longer message only what I put into "sendbuffer" in android.
The chat can go on for several hours and suddenly for no reason just stop.
What do you mean by "terminated event" ?

 

[TechEd]

This is strange
I wrote a new B4A program, just the communication part.
I just displayed the incoming string to log ( Log(s) ).
It worked ok.
As soon as I added a "EditText" to the view and displayed the
string in it the problem occurred. After a few minutes the B4A program
ignores incoming message. What is happening.
Yes I am handling the "terminated event".
This is so frustrating.

 

[lemonisdead]

Hello,
Is your service put in the foreground ? Or perhaps has to be started sticky ?

Another idea : phone wakestate to try (phone library).

 

[TechEd]

Yes it is running in the foreground.
The phone Awake.KeepAlive(True) is done in the Activity_Create.
Isn't there a way to debug this ?

 

[positrom2]

A while ago I had posted here that EditText once the Edit-Window has opened slows down the app (communicating via BT with a µController using TextReader/Writer. Slowing-down persists even after closing the window...

 

[TechEd]

Yes I have noted that it slows down quit a bit but that doesn't matter because the µController is waiting for a ACK after each trans
of 5 char. And it can keep on chatting for such a long time before it stalls.

 

[Erel]

The prefix protocol is reliable as long as the underlying connection is reliable.

I wrote a new B4A program, just the communication part.
I just displayed the incoming string to log ( Log(s) ).
It worked ok.
As soon as I added a "EditText" to the view and displayed the
string in it the problem occurred. After a few minutes the B4A program
ignores incoming message. What is happening.
Yes I am handling the "terminated event".
This is so frustrating.

Can you post the NewData code?

 

[TechEd]

Here it is

 

[Erel]

If you change EditText1.Text = RecString to Log(RecString) will it work flawlessly?

What is the length of RecString?

Are you testing it in Release mode?

 

[TechEd]

Yes I know it work with Log(RecString), se reply 4, but as soon as I
temper with the string the problem occurs.
Each poss in the string has a special meaning and is finished of with a value with is
going to be displayed in a view, so I am running it thru a Select case procedure

The length of RecString is 5 to 7 char for each trans.

I have tested it in all three modes same result.

 

[Erel]

What do you mean with temper with the string?

 

[TechEd]

In the real big program, when a string has arrived I call a subroutine to validate the sting,
what kind of data it contains and so on. Nothing out of the ordinary. Temper is maybe wrong
word lets say validating or analyzing. After returning from that sub I send ACK (Char(06) to
the µController system for next string to be sent. The µController do not send any data unless
B4A program is ready for receiving. No heavy traffic, less then 10 char per trans.

Sorry didn't se the "?" at the end of your first line. the answer to that is that I thing so, it vent on
for about 1,5 hour without any problem. After that I stopped the execution, comment out the "Log(RecString)"
and "Log("ACK")" -line and uncomment the "EditText1.text=RecString" -line, recompile and started execution.
After about 15-20 min it staled.

 

[Erel]

Which device are you using?

Seems like an OS / UI framework problem. Try to switch to a label. Might solve this issue.

 

[TechEd]

I am using the common RN42 Bluetooth device and a Acer Iconia B1 with Android 4.1.2
I have tried it on a Samsung S3 with same result.
Ok I will test with a label instead and also
I will do a test program under Windows that is similar
and report back when I have the result.

 

[TechEd]

Now I have solved the problem.
After test towards a windows app witch worked perfect, I suspected the tablet.
I use a Aser Iconia B1 710 for this project.
The spec. says Bluetooth 4.0 nothing more.
But there is a big but. After contacting Acer they replayed that
the Iconia B1 "Only A2DP stereo headset are supported" no updates
are available. So you were right Erel it was an OS / UI framework issue.
Have tested on an other tablet works like a charm.