• State Verified Answer
  • Replies 6 replies
  • Subscribers 70 subscribers
  • Views 3347 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

    I always assumed it was for completeness and incase one day the implementation changes to allow you to put services in in any order and reorders them later (unlikely). I do think, since the handle is passed-in and it's known whether that is the last service or not, it ought to return an error if one adds to the 'wrong' service, that at least would make it clear that order does matter. As it is, yes, it's rather redundantly redundant.

Reply
  • 0 in reply to RK

    I always assumed it was for completeness and incase one day the implementation changes to allow you to put services in in any order and reorders them later (unlikely). I do think, since the handle is passed-in and it's known whether that is the last service or not, it ought to return an error if one adds to the 'wrong' service, that at least would make it clear that order does matter. As it is, yes, it's rather redundantly redundant.

Children
No Data
Related
Terms of service