We're looking at around 2 weeks or so before we put out the official release.

Excellent news, thank you!

@ryanbis Ah, good to know. I will be sure to test this thoroughly. Thanks for the tip!

Excellent, please let me know if you still see the problem.

Well, it's mostly the connecting itself which is the issue... The scanning/finding is pretty consistent now...

Yes, those trigger. We added those when we noticed that the times we set in taskTimeoutRequestFilter or DefaultTaskTimeoutRequestFilter weren't triggering.

Removing all the calls to unbond() from our side does not mitigate the automatic reconnection.

Gotcha, sounds great!

Got it, thanks! Will look to alternative solutions like keeping a service in the background. Our goal is to provide push notification capabilities to the custom BLE device.

@ryanbis Awesome! We look forward to the release. Cheers, Gunnar

We are using sweetblue v2 with xamarin. I needed to basically create a java wrapper interface around the bledevice methods which required callbacks/listeners. The bindings compilation had issues with the generic type java features being used with the listeners, so I just call to my java wrapper object from c# which has simple listeners and the binding generation has no issues with. I've attached our wrapper's source code for you to use, it filters the scans without needing to call back into c# too which was a huge performance improvement.sweetbluewrapper

Glad to hear! Looking forward to the next release.

Bjoern, How are you setting your reconnect filter?

I'm having the same problems on v3.0.2, where as I connect, turn Bluetooth off and on again, it'll automatically reconnect (at least that's what the sensor says),but a NATIVE_CONNECTION_FAILED is given.

`Well, the Sweetblue library does already make a big improvement on connection time, and the amount of phones even being able to connect... I'm mostly worried about the phones that sometimes don't connect at all, but so far, I've only seen that on a Sony in my small test team... Too bad the guy doesn't want to test again to see if my latest fixes work for that issue :S

Try setting the delay between tasks option in the settings menu to something like .5 seconds (the value is in seconds). See if it improves the connection rate at all. I've heard sometimes delaying after service discovery can sometimes help with 133 gatt errors when connecting. This test should at least give us some proof that this is true or not.