Android Question Bluetooth/Asynchstreams packet order issue?

[Arf]

My app interfaces with a bluetooth device, which sends data up in packets, usually 6 bytes but up to hundreds of bytes. In most cases the data arrives OK, but once in a while I get unexpected data, which could be a result of either a lost chunk of data, or two subsequent chunks of data arriving in the wrong order. The situation is much worse in DEBUG than in RELEASE mode.

I am testing with only 6 byte long packets at the moment. In my Asynchstreams_NewData function, I read out the number of bytes received and stick it in a fifo, buffering it up until I have at least 6 bytes and then I call my packet handler. The packet handler extracts the packet and removes the relevant data from the fifo, reporting on what is left in the fifo upon exit.

got 1
got 5
left in buf 0
got 3
got 3
left in buf 0
got 1
got 5
left in buf 0
got 1
got 5
left in buf 0
got 1
got 5
left in buf 0
got 1
got 1
got 5

So, in the case of the last NewData events, I got 7 bytes and experienced the unexpected data problem. Examining the data, if the last and second last packets were swapped around, the data would have made sense. This could be co-incidental due to the repetitive nature of the packets I am testing with.

Anyway, to cut to the chase: I was under the impression that since I cannot use Prefix mode, using a fifo to buffer the incoming data until I had enough data to decrypt a packet was all I needed to do. I need to find out why I am getting unexpected data, and I suspect that the Astream_NewData function sometimes returns chunks of data in the incorrect order.

Is this a possiblity, or am I barking up the wrong tree?

The product normally interfaces to a PC with a bluetooth dongle of my own design, I've sold hundreds of systems and worked with further development of the system every day for over 3 years and I've never once experienced a communication error, so the issue is on the android side of things, that much I know.

 

[Arf]

Or, I find myself debugging a problem that only seems to exist in debug mode os maybe I'm wasting my time.
Is it possible that the debugger wifi overhead is making the bluetooth comms really slow? And to what extent do log messages have an time impact on program execution in debug?

 

[Erel]

The order can be wrong if you show a modal dialog (msgbox) or call DoEvent during communication.

It can also happen if you pause the program execution with a breakpoint.

 

[Arf]

Thanks, do the first two still apply if the NewData and asynchstreams stuff is all within a service module?

 

[Arf]

Ah! Some experiments show that after clicking OK on a MsgBox, I most certainly am seeing a load of buffer clearing, indicative of a bluetooth data integrity failure. I really thought that creating a service to handle all comms in the background would have prevented this from happening.

So, is there any alternative form of MsgBox which doesn't block the comms, or would I need to create my own MsgBox that can be loaded on a panel or something to avoid this? The only DoEvents I can see in my project is in the StateManager code.

 

[Arf]

Aaargh this is such a headache, must have done 50 hours on it now and still can't find a satisfactory resolution.
Problem is, the modal box can stay up for quite some time, and while I can clear my receive buffer when the box goes, I then gets a torrent of garbled data that's been sitting queued all the time the box has been up.

I can try just read it and dump it till there'a no more messages, but how to differentiate between then end of the queued messages and new, good quality data?

I tried to create my own MsgBox, which constantly calls DoEvents until it disappears, but same problem with corruption. Is there any call I can make from with a modal wait for reponse that will allow me to manually collect the Asynchstreams data?

 

[SteveTerrell]

Aaargh this is such a headache, must have done 50 hours on it now and still can't find a satisfactory resolution.
Problem is, the modal box can stay up for quite some time, and while I can clear my receive buffer when the box goes, I then gets a torrent of garbled data that's been sitting queued all the time the box has been up.

I can try just read it and dump it till there'a no more messages, but how to differentiate between then end of the queued messages and new, good quality data?

I tried to create my own MsgBox, which constantly calls DoEvents until it disappears, but same problem with corruption. Is there any call I can make from with a modal wait for reponse that will allow me to manually collect the Asynchstreams data?

Presumably if you create your own message box from a panel and button there is no need (or anywhere) to keep calling DoEvents?

If you need to simulate the Modal effect you might think of putting the "message box" panel on a larger transparent panel that covers the rest of the screen and absorbs any attempt to press something else.

 

[Arf]

Thanks - this is the exact solution I was trying to implenebt - hence my other question

 

[SteveTerrell]

Don't forget to have an empty click sub for the transparent panel so it grabs any clicks.

 

[Erel]

You need to use a non-modal dialog (a regular panel). You cannot call DoEvents and you cannot hold the main thread.