Service discovery call back returns incorrect service UUID?

RE: Service discovery call back returns incorrect service UUID?

endnode — Sun, 12 Nov 2017 19:37:19 GMT

Yes, this is the right understanding how connections are handled by SD and its API!

RE: Service discovery call back returns incorrect service UUID?

MichaelNordicUser — Sun, 12 Nov 2017 19:21:08 GMT

Right, I want to know exactly what I my code is doing and how to use it. I don't like using these example as crutches, but they help me learn.

So this is my understanding of connection handle. A connection handle is a unique number returned by the SD in the connection call back (don't remember the exact name of the call-back). Then I can pass this number back to the SD card through functions, like for example relaying a packet to or disconnecting from a peripheral.

So then, connecting to mutiple peripherals is simple. I just need to keep track of the connection handles to manage them.

So basically, I can parse a packet for some number like a MAC address, and connect to the device. Then I can connect to another device, and basically as many devices as are supported without any special logic right? You're basically just saying, keep track of and manage the connections with the handles.

RE: Service discovery call back returns incorrect service UUID?

endnode — Sun, 12 Nov 2017 18:34:51 GMT

So yes, the code snippet might be used wisely for multi-connectable application, you just need to take ownership of the code and stop reusing examples blindly;) There are usually no easy ways, no free hugs, no food falling down from the tree just like that;)

RE: Service discovery call back returns incorrect service UUID?

endnode — Sun, 12 Nov 2017 18:32:50 GMT

You get it right basically. There is opportunity to broadcast one or more Service UUIDs to hint that this is the device which implements GATT Server and that it had UUID which is interesting for some applications. But because standard BLE adv. packet (BT 4.0-4.2) can fit only one 128-bit UUID or few 16-bit (and these are not interesting unless your main use-case is some standard profile) then it's pretty legit use case to connect to each GAP Peripheral and try to discover the server for UUIDs which you want to interact with. If you find proper set of UUIDs then you go on, if not then you disconnect.

When it comes to multi-connectivity: it's just about using proper connection handles! So make sure that all functions are having connection handle as input (and use it for all SD calls) and the same for event handlers (each event must be handled in the context of its connection handle).

RE: Service discovery call back returns incorrect service UUID?

MichaelNordicUser — Sun, 12 Nov 2017 18:03:37 GMT

Thanks again. I think I understand now. Correct me if I'm wrong. A GATT server does not have a UUID. A server is vertical stack of attributes where each attribute is assigned a unique UUID. A client will parse an advertisement packet for a MAC address and connect to the server on the basis of this MAC address.

However, the client I should program will not know the MAC address of the server beforehand, so my client should connect to the server on the basis of the first primary service UUID. This is a legitimate approach right?

Lastly, thank you for the sample code. Will the client app that uses this code be able to connect to multiple servers concurrently, or are multiple concurrent connections a special feature supported by the multi-connect example? I would like to avoid the more complicated multi-connect example if possible.

RE: Service discovery call back returns incorrect service UUID?

endnode — Sun, 12 Nov 2017 10:48:44 GMT

Btw. here is one Q&A which shows how to do simple Service Discovery algorithm based on older S130 and SDk version.

RE: Service discovery call back returns incorrect service UUID?

endnode — Sun, 12 Nov 2017 10:04:36 GMT

Again: the device is recognized by MAC not UUID, so you cannot immediately make GATT Server and some UUID as equal. But assuming each of GATT Servers you use will have different UUIDs we can go on.

When it comes to examples\ble_central\ble_app_multilink_central project then it's good starting point for multiple GAP Central and GATT Client connections in single nRF52 chip. However have you started from there just to get familiar with the project and debug while having it on DK and simulating 2-4 Peripheral boards by another nRF5x Dev Kits? That might be a good starting point. How GATT service discovery looks there? And more importantly can you get also BLE trace from some sniffer so you can understand what is really happening when DB module does the job and if you might be able to write it shorter and more efficiently?

RE: Service discovery call back returns incorrect service UUID?

MichaelNordicUser — Sat, 11 Nov 2017 23:53:29 GMT

Thanks. This is exactly what I want to do. I want to connect to multiple GATT servers I know the UUIDs of. Is this multi-link app the closest example in the SDK of what I want to accomplish? You make it sound so simple, but I have no idea how to accomplish this.

RE: Service discovery call back returns incorrect service UUID?

endnode — Sat, 11 Nov 2017 22:52:49 GMT

Well I cannot comment much on how exactly db_discovery module works because as I said I never found use for it. If I'm looking for specific Service and Characteristics then it can be done in two simple loops going through certain ranges of GATT handles and there are even GATT Methods where you ask for handle with given UUID and you get straight answer so why to discover all objects and building some database? This is what generic devices with separated GATT Client and APP layers do, e.g. all phones and tablets and probably PCs. But that's basically never the case on embedded system such as nRF5x. You basically always know what UUID are you looking for right now so I don't see any use of this module...

RE: Service discovery call back returns incorrect service UUID?

MichaelNordicUser — Sat, 11 Nov 2017 22:15:57 GMT

Thanks for the feeback. I will flash the chip and start from scratch. I am reading the docs and trying to understand the database discovery module. Am I correct when I say that the discovery event handler forwards discovery events to the ble_lbs_on_db_disc_evt function if the server UUID in the discovery event matches the registered Light Service UUID? Or are all discovery events whose UUID matches a registered UUID (and no others) forward to ble_lbs_on_db_disc_evt function? Or am I just not making any sense?

RE: Service discovery call back returns incorrect service UUID?

endnode — Sat, 11 Nov 2017 19:46:12 GMT

You seems to be missing how advertiser/broadcaster and connection link work. The scenario you describe is very much unlikely and the probability that you have bug in your code is many times bigger. GATT Service discovery has nothing to do with advertisement and it cannot be disturbed by any such packet even if it would be sent (mainly because receiver cannot by any chance accept it as part of the valid link). I'm afraid you lost control over your project long time ago and from some messy RTT debug messages (which you are unsure what they say and where they come from) it will be hard to get it together again.

Also 95% of GATT Clients have very simple use case of "find one service => find one characteristic under it => use it as communication tube" so I have feeling that most of things your client does on app layer is totally wasting of time and code space.

RE: Service discovery call back returns incorrect service UUID?

RK — Sat, 11 Nov 2017 10:47:26 GMT

and apart from that there are various error codes which tell you whether the data is even valid and none of those have been checked. So this is a print out of random nubers.

RE: Service discovery call back returns incorrect service UUID?

endnode — Sat, 11 Nov 2017 10:08:07 GMT

Hi,

The point is that you print out only short 16-bit (2-byte) UUIDs. Nordic stack always work with full 128-bit UUIDs in a little bit special form (which makes sense if you appreciate how UUIDs are defined in BT SIG specification):

Each UUID is pair of short UUID value (in your case 0x1523 or 0x0011) and "UUID type" which is actually index in virtual table of known (= provisioned to Soft Devie BLE stack through GATT API function sd_ble_uuid_vs_add) - or actually unknown - 128-bit UUID bases.
So the fact that some UUIDs have the same 16-bit short part can be only coincidence, the type says all.

In addition there are definitely more than one service on phone's GATT Server so firstly I'm not sure if your service discovery is doing what it should (or what you want) and secondly the questions "Why is it that the service UUID of the my phone is 1523 ? Is that right?" don't make any sense. if you as if it's possible that GATT Server on the phone has such service then indeed it's possible, why not? If there is any application which provisions such GATT Service then it's there. Who knows what you have on that phone?:) And btw. there can be even more GATT objects with the same UUID on the same server. They will have different handle IDs but UUID is like a name and you can have several people named John in your house so it works the same way.

When it comes tho discovery of your blinky app it kind of indicates that your GATT Service discovery is out of control or just acting weirdly: why would your discovery DB module report the same service 8 times? Unless you modified the GATT Server code and it really contains 8 such Services... but I doubt.