• State Verified Answer
  • Replies 6 replies
  • Subscribers 70 subscribers
  • Views 3350 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 112538
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

multiple services issue

Jim Dattolo

I'm running into something weird on SDK8.0 (I will be upgrading soon to SDK10, however it's a layered roll out so I can't update right now unless you tell me it's a bug in SDK8.0

I have two primary services. I register each and get two different handles. I then register a bunch of characteristic value attributes to each of the service handles and then discover on the central role only to find out that one service has no characteristics and the other has them all. Each service has an unique UUID, each service has a set of unique UUID characteristics and a couple in common. I see this happen on both a S130 central role and with the MCP so I trust that this is happening on the S110 side. Everything works, it's just that the service discovery is claiming zero assigned value handles to the first and all of them on the other. Reading and writing the value handles is just fine.

Any clue on why this can be happening? I can't post the code here due to client confidentially.

Parents
  • 0

    You can't do that - you have to register the service AND the characteristics for that service, then the next service and then the characteristics for that service. I recall seeing this in the documentation somewhere but I don't remember where. If you think about it however, the handles are returned when you register each piece, the softdevice doesn't wait for you to finish then go back and reorder them all, so your attribute table ends up with ... so all the characteristics end up on the second service (because BTLE only really cares about the handles it sees in order in the table).

  • 0 in reply to RK

    well I tried to explain in the previous answer. The ATT table is in handle order, a service starts at one handle and ends with the next service start handle, and all the handles in between are the characteristics and other data. So if you allowed the user to add things in any order, you'd have to basically store all that data, wait until they'd finished, and then shuffle it all into order and allocate the handles. That's more code and more memory and a much more complicated API than the one they have which is just 'allocate next handle'. Note that handles are returned right from each service and characteristic registration call, so if you register two services, they will have adjacent handles, if you add the characteristics afterwards, there's no way to add handles between them. I think the sd should actually return an error if you add chars to a service which wasn't the last one added.

Reply
  • 0 in reply to RK

    well I tried to explain in the previous answer. The ATT table is in handle order, a service starts at one handle and ends with the next service start handle, and all the handles in between are the characteristics and other data. So if you allowed the user to add things in any order, you'd have to basically store all that data, wait until they'd finished, and then shuffle it all into order and allocate the handles. That's more code and more memory and a much more complicated API than the one they have which is just 'allocate next handle'. Note that handles are returned right from each service and characteristic registration call, so if you register two services, they will have adjacent handles, if you add the characteristics afterwards, there's no way to add handles between them. I think the sd should actually return an error if you add chars to a service which wasn't the last one added.

Children
No Data
Related
Terms of service