Android writes and timeouts?

[dibari]

I'm making a number of write requests to a pedometer. On iOS, everything seems to work fine, but Android seems to get overloaded at handling multiple requests. I've added a delay between each request of about 200-500ms, and it seems to work just fine. Is there some type of known issue with simultaneous quests? I've tested on both a samsung and htc.

[kgillespieatmosphere]

Android does not handle queuing properly so if you send multiple request depending on the chipset you may either lose a message or never get any out. I have a lot of testing android devices so I have seen the behaviours between them and Samsung, and HTC are the worst, anything using mediatek chipsets like Acer work really well, Intel android devices are pretty good and LGs Nexus are okay as well.

Which brings me to my biggest problem is that without the Bluetooth LE plug-in handling queuing for my projects I have to write a ton of additional code to handle a queue compared to iOS also I don't have the complete control over the android API so what I really need to do is patch the java code to handle queuing unless Randdusing is working on that already?

[kgillespieatmosphere]

So my suggested fix would be the following for the Android part of the plugin to implement a command stack. I have done this before with other projects and it works out okay, though you can get flooding.

Instead of the functions writeAction, and readAction all trying to do there BLE API calls right then and there when they are called instead they will send their command request to a master queue. After they send their command to the master queue they then check to see if the plugin is still waiting for a request back from BLE and if it not then execute the next command on the queue. If it is wait. When ever a request comes back from the BLE stack to the plugin the plugin should then pull the oldest command of the queue and then execute it. This will mean that no command is lost but it does mean you could flood the queue and get a long time before all the messages are pushed out.

I can code this up but before I do I would like rand's two cents. Maybe he already has been thinking about this.

[diverJohn]

Please read my throughput issue #98 which discusses this very issue.

[kgillespieatmosphere]

You observations are only true for some of the Android systems. Currently I have noticed four different behaviour patterns with all the Android devices that I currently test on.

I have tried your push 4 and wait but it doesn't seem to work on Android devices with Qualcomm and Intel chipsets.

This is more of a consistency issue with the plugin. One would expect that even if performance is not the same that at least the behaviour would be similar. When using this plugin with iOS and some Android devices (Mediatek) you don't have messages that you send to the plugin completely lost, there isn't even a message to let your application know "Hey that request you just tried to send will not be able to get through because the BLE stack is busy". It would be really awesome if we could get the plugin for Android to detect what chipset and platform it's on so it can optimize it's queuing. Like in the case of Broadcom chipsets send out 4 write commands before waiting for returns, etcetera. Even a "Stack Busy" error would be useful so a users application would know when it needs to stop trying to send messages.

[randdusing]

Sorry for the delay..was in Africa for 2 months :)

I'm not actively working on a queueing solution, but it's something I'd like to introduce with my next major release.

[kgillespieatmosphere]

I was also wondering if there is anyway we could get some unit testing for the BLE plugin with benchmarking. Mostly so we can track how Android is coming along in terms of speed and stability.

[randdusing]

Sorry for the long delay. Trying to revive this project over the next couple weeks.

1. Queuing - I think I'm going to defer this to the app level. Promises like in the Angular wrapper make this really easy to handle.
2. Testing - Having some sort of test that could be run across Android devices would be nice. I'm working on a project involving multiple connections from an Android device, and the Bluetooth stack on my Nexus 7 "breaks down" pretty quickly. I'd like to create a test that could benchmark various devices.

[maximilianloy]

Having a queue in the plugin would be a great help! We do periodic requests in the background in addition to UI interactions triggering BLE commands. If things overlap we see commands being canceled on Android.

[randdusing]

@maximilianloy See my last post. I think it's better to defer this to the app by using promises. Much simpler than trying to implement a full solution in Android.

[randdusing]

Queueing is now part of Android for read, write, subscribe, unsubscribe, readDescriptor and writeDescriptor. Let me know if you run into any issues.