Cache is not used on Samsung devices leading to 1.5 seconds delay

[mrquincle]

The cache is not used on untrusted Samsung devices, e.g. Galaxy S5. This is according to the Bluetooth specification. It might be that if the service_changed characteristic is NOT present, the Samsung S5 WILL use the cache. Good thing to try!

gatts_enable_params.service_changed

There might be other ways to remove this delay, e.g. speeding up the discovery process in certain ways. There are a lot of handles that are tried and that are not present on our devices.

[AlexDM0]

According to the Nordic iOS DFU module in git, it is important that we be careful with this:

Service Changed characteristic

In order the DFU to work with iOS, the target device MUST have the Service Changedcharacteristic with Indicate property in the Generic Attribute service. Without this characteristic iOS will assume that services of this device will never change and will not invalidate them after switching to DFU bootloader mode.

To enable Service Changed characteristic for nRF5 application make sure this flag is set in your main.c file:

define IS_SRVC_CHANGED_CHARACT_PRESENT 1

Just to keep in mind.

On 9 Jan 2017, at 10:35, Anne van Rossum notifications@github.com wrote:

The cache is not used on untrusted Samsung devices, e.g. Galaxy S5. This is according to the Bluetooth specification. It might be that if the service_changed characteristic is NOT present, the Samsung S5 WILL use the cache. Good thing to try!

gatts_enable_params.service_changed

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mrquincle]

That is not the complete story.

• IF you offer different services as the bootloader. You can choose to have the same services.
• You can change BLE address if you're in DFU.

[mrquincle]

Shame!

It is tested by @eggerdo if the cache is used for untrusted devices if there is NO service changed characteristic present. The Samsung S5 never seems to use the cache for untrusted devices and always clears it after a disconnect (or before a connect).

[mrquincle]

Other solution directions:

• There is currently a private refresh() function that is used to enforce a refresh of the cache. What other functions can we access that would prevent the Samsung BLE stack to do this refresh? What exactly is different in the Samsung BLE stack? Is it actually different code on the level of Android? Or does the chip involved issue the refresh itself?
• Speed up the discovery process. What happens if an optional characteristic is not present. When checking the bluetooth log in wireshark, there are quite a few errors (that aren't real errors because it concerns optional characteristics). However, if the absence of a characteristic results in a delay to a timeout we might speed up the discovery process itself.

[mrquincle]

There are two other solutions directions if reverse engineering isn't working out for us:

• Predicting when to connect, so we can actually do the connection before a person presses a button.
• Connecting continuously, so we can be very fast at any time.

[AlexDM0]

Or like a Philips hue, go through a basestation that is hooked up through the mesh like a hub. It's optional, but improves the experience on android?

If we have background beacon functionality (beacon broadcasts during connection) we can connect whenever a user: is moving or has the app open and clicks on a room.

Cheers

On 9 Jan 2017, at 13:36, Anne van Rossum notifications@github.com wrote:

There are two other solutions directions if reverse engineering isn't working out for us:

Predicting when to connect, so we can actually do the connection before a person presses a button. Connecting continuously, so we can be very fast at any time. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mrquincle]

Yes, although with a mesh there would be no need for a hub of course.

To build up a model about the user will be very valuable, especially for our AI down the road.

[AlexDM0]

With the mesh we have no need for bluetooth connection from the phones if a user has a hub.

On Mon, Jan 9, 2017 at 9:03 PM, Anne van Rossum notifications@github.com wrote:

Yes, although with a mesh there would be no need for a hub of course.

To build up a model about the user will be very valuable, especially for our AI down the road.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/crownstone/bluenet/issues/30#issuecomment-271392147, or mute the thread https://github.com/notifications/unsubscribe-auth/AFHWTZvxXcM5wSnfKhf8j8MmjgDaJf92ks5rQpKngaJpZM4LeEhj .

[mrquincle]

Solved by not longer relying on connections https://github.com/crownstone/bluenet/issues/52.