Reputation: 190
I'm developing an android app for some hardware that has a BlueGiga WT12 bluetooth modem. The hardware device sends 56 byte packets at around 240hz. I'm testing on a Samsung S5 and S8. A fully functional app has already been created for IOS and PC so we know the hardware device works.
I use a separate thread to read in the data and then dispatch it to the main thread.
The issue I'm having is when I send the command to the device telling it to start streaming, it starts to stream but very shortly after I start receiving packets at a very slow rate 10-60hz.
After some examination I realized that the device was experiencing a bufferoverflow.
After talking to our hardware guy he said the only real thing that could cause that is something on the phone side not reading fast enough, resulting in the hardware device not wanting to send more packets because it thinks the phone can't receive anymore and then the buffer overflows on the hardware device.
The WT12 has flow control enabled so maybe this is an issue with Android not giving a clear-to-send signal to the WT12. But to my knowledge we don't have access to all of the flow control stuff.
My first line of attack was to simply remove any code that I thought was slowing down the reads but that seemed to have no effect.
I also tried basically every bluetooth serial terminal app I could get my hands on, all with the same result.
So then I questioned if it was some weird problem relating to the hardware device but after using pc based (bluetooth) serial terminals I had no issues at all on the pc.
The hardware device can also operate over USB as opposed to bluetooth so I tried reading the data from it exactly the same as I had with the bluetooth connection but over USB. Using the USB serial connection I had no issues at all.
So this leads me to believe the problem must be with the bluetooth modem on the phone side. I was thinking maybe it was a flow control issue as we have flow control enabled on the WT12. Maybe android isn't sending a clear to receive signal?
The problem is to my knowledge the flow control is implemented in the bluetooth stack and we as developers have no control over it if I'm not mistaken?
Other then flow control I don't really have much idea what could be causing the hardware device to not want to send me data.
Upvotes: 0
Views: 241
Reputation: 11
I've just now been experiencing the same issues with flow control. Then I see that in case of RN4678 BT module, that it's best to disable the flow in the MCU FW and pull the cts pin low on the module. That worked for us.
Upvotes: 1