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

Excellent news, thank you!

@benp thanks a lot, will check it out!

@caeduk Please post a new topic with specific steps to reproduce the issue you're having so we can investigate it on our end.

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

@caeduk that's a good solution is similar to what we do: Before switching the device to be in firmware update OTA/DFU mode, we keep track of which device will be put into that mode. Undiscover the device after the disconnection. Set the setListener_DeviceReconnect to null. We only trigger a connection in the DefaultDeviceReconnectFilter if we know that the device is not transitioning into its firmware update mode.

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.

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

Glad to hear! Looking forward to the next release.

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

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.

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.