• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 625 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F: SERVICE CHANGED CHARACTERISTIC

RopeS
Intellectual 310 points
Part Number: CC2640R2F

Hi

I have a Peripheral Device which establishes a GATT Server. And in this device I have made sure that the SERVICE CHANGED Characteristic is not defined. The Host Device (GATT Client), with which my peripheral bonds, must use Attribute Caching and not perform Service Discovery, etc. after bonding has been established.

The Peripheral Device also drops the connection after some time to reduce power consumption. What I find is that every time the peripheral reconnects, the Host Device performs complete Service Discovery again. This is a waste of time and battery.

How do I ensure that the Host Device not rediscover all the services on reconnect?

thank you

regards

  • 0
    TI__Mastermind 23440 points
    Hi RopeS,

    This will vary depending on the Central device you use. I can't see that the spec says *must* on caching anywhere. It's an optional thing, and in my experience Central devices will behave in different ways here.

    What is specified, is that caching only persists across connections for devices that are bonded, so if you enable bonding you may increase the odds that the attribute table is cached.

    See the BT Core 5.0 spec, Volume 3, Part G, Section 2.5.2 for the exact wording.

    Best regards,
    Aslak
  • 0 in reply to Aslak N.
    TI__Mastermind 23440 points

    Hi RopeS,

    I noticed you clicked on "This did NOT resolve my issue". If you have the time, please elaborate.

    Otherwise there really isn't much more I can tell you. It seems to me that you have done what you can per the spec from the peripheral side to ensure caching is done, i.e. not having Service Changed in your attribute table. The only exception being pairing and bonding is not mentioned in your post. We do not produce, supply or support the Bluetooth functionality in third party products.

    For your reference, here is a link to the Bluetooth Core Spec v5.0. You will be interested in page 2226 which contains the section mentioned in the previous post.

    https://www.bluetooth.com/specifications/bluetooth-core-specification

    Here is a quote from the spec regarding my initial paragraph:

    Attribute caching is an optimization that allows the client to discover the
    Attribute information such as Attribute Handles used by the server once and
    use the same Attribute information across reconnections without rediscovery.

    Here is another quote regarding bonding:

    For clients that have a trusted relationship (i.e. bond) with the server, the
    attribute cache is valid across connections.

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    Intellectual 310 points
    Hi Aslak

    Thanks for the reply.
    I am going to add some more information, so that you can help me solve this.
    I agree that caching is an option, my choice of words were not the most appropriate.

    I did the following test with the Central Device:
    I paired another peripheral sample (peripheral 2) I had available with the Central device. Upon reconnection, the Central does not perform Service Discovery for this peripheral. So, this indicates to me that the Central Device voluntarily caches the Attributes Handles.

    But when I pair (bond) and allow reconnection of my peripheral Device (Peripheral 1) with the same Central Device, the Central always performs full Service Discovery.

    So, I assume the error lies in my peripheral Device implementation. After some study of the documentation, I found the Service Changed Characteristic, which seemed to explain why Service Discovery was occurring with my peripheral. But on trying to introduce alterations to resolve this, I have been unsuccessful.

    And was wondering what I was doing wrong? Or how to find the reason for this to be occurring?

    thanks
    regards
    Rui
  • 0 in reply to RopeS
    TI__Mastermind 23440 points
    Rui,

    Thanks for the details. Which device are you using as a Central? Do you have a sniffer that you use for testing? The difference in behavior should be visible in a sniffer and in the attribute table of the devices. I tested with Android 8 / S8 now with "BLE Scanner", and could not convince it to cache the attribute table with any combination of service changed and bonding.

    Best regards,
    Aslak
  • 0 in reply to Aslak N.
    TI__Mastermind 23440 points
    Hi Rui,

    I tell a slight lie. It seems the Android phone does a much more reduced service discovery when a bond exists, only primary services and rediscovery of the GAP Service characteristics. Unsure why. It goes to show that the centrals can do whatever they want.

    Best regards,
    Aslak
  • 0 in reply to Aslak N.
    Intellectual 310 points
    Hi Aslak

    Can you clarify one thing.
    The Android reduced service discovery, was that due to the bonding or due to your tinkering with the SERVICE CHANGED characteristic or both ?

    thanks
  • 0 in reply to RopeS
    TI__Mastermind 23440 points
    Hi,

    With the phone I tested with, the presence of Service Changed had no effect, just bonding or not.

    Best regards,
    Aslak