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.

[RK]

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).

[Jim Dattolo]

ah, I was thinking that could be the case but why? The API has the handle for each service in the registration call to the characteristic. relying on the order of the calls seems very clunky, esp since all of the information needed to do it without that is already in the API.

[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.

[Jim Dattolo]

I understand that, what I am talking about is why the API requires the service handle to be passed on every charateristic creation. The stack should just cache the last service handle and use that if it needs bookkeeping internally. That would tell the caller that order is important. The way it's setup there is an implied "order doesn't matter" since we have to pass the handle for the service.

[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.