Hi Jacob, On Tue, Dec 27, 2016 at 02:37:01PM -0700, Jacob Rosenthal wrote: > Hey all, been working with mynewt for a week or so now, trying to > understand the code and slim the nimble stack down for nrf51822qfaa > targets. Playing with central role now (modified blecent), and Im having > some trouble searching for a single svc by uuid (to save peer struct > memory, rather than indexing them all) > > Either I dont understand ble_gattc_disc_svc_by_uuid or it has problems. > > Its returning successfully but with a different uuid than I would expect > and weird handles
Could you show the code you are using? I haven't noticed any issues with the discover primary services by UUID operation. > 2357:[ts=18414036ssb, mod=4 level=1] GATT procedure initiated: discover > service by uuid; uuid=0000180d-0000-1000-800000805f9b34fb > 2360:[ts=18437472ssb, mod=4 level=0] host tx hci data; handle=1 length=27 > 2361:[ts=18445284ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x1b > 0x00 0x17 0x00 0x04 0x00 0x06 0x01 0x00 0xff 0xff 0x00 0x28 0xfb 0x34 0x9b > 0x5f 0x80 0x00 0x00 0x80 0x00 0x10 0x00 0x00 0x0d 0x18 0x00 0x00 > 2364:[ts=18468720ssb, mod=4 level=0] txed att command: find type value req; > conn=1 start_handle=0x0001 end_handle=0xffff attr_type=10240 > 2372:[ts=18531216ssb, mod=4 level=0] Number of Completed Packets: > num_handles=1 > 2374:[ts=18546840ssb, mod=4 level=0] handle:1 pkts:1 > 2379:[ts=18585900ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1 > pb=2 len=9 data=0x05 0x00 0x04 0x00 0x01 0x06 0x01 0x00 0x0a > 2382:[ts=18609336ssb, mod=4 level=0] rxed att command: error rsp; conn=1 > req_op=6 handle=0x0001 error_code=10 > 2384:[ts=18624960ssb, mod=64 level=3] Service discovery complete; status=0 > conn_handle=1 It looks like the peer is reporting that it doesn't support the service being requested (heart rate). The peer responds to the Find By Type Value Request with an error response (status=10; attribute not found). One thing to be careful about: be sure to check the status parameter in your GATT callback. If the status is not zero, then the service data is not valid. In this case, I would expect the status to be equal to 14 (BLE_HS_EDONE). I believe this explains why you are seeing weird handle and UUID values. The Discover Primary Service by UUID API is not obvious. The callback may get called multiple times; the last time it gets called, the status will be nonzero (BLE_HS_EDONE on successful completion). This probably seems weird, since you are only trying to discover a single service. The reason for the strange semantics is that a device is allowed to have multiple services with the same UUID; this API is hampered to allow for this obscure scenario. Unfortunately, I'm not sure why the device is reporting that it doesn't support that service. Is the peer a Mynewt device? One thing that looks strange is that your device is trying to discover the heart rate service's 128-bit UUID. If a UUID can be represented in 16 bits, then the Nimble host should specify the shorter UUID. This is something that the host does automatically as long as the application specifies the UUID correctly. From the log, the 128-bit UUID looks correct, so I am not sure why all 128 bits are being transmitted. This is just an optimization; the 128-bit UUID should work also. This might be a clue, though. [...] > I dont know if its helpful, but I noticed ble_gattc_disc_svc_by_uuid is > using the find api (ble_att_clt_tx_find_type_value) instead of a read api > (ble_att_clt_tx_read_group_type in the case of ble_gattc_disc_all_svcs) That is OK; the Discover Primary Service by Service UUID GATT procedure uses the Find By Type Value Request ATT command. Section 3.G.4.4.2 in the 4.2 spec contains a sequence diagram illustrating this (I just mention this in case you are interested). > Im trying to understand hci packets now to see what those differences are, > but in the mean time I thought Id post. > > Thanks for the stack and for any thoughts. If you don't mind sharing the code which calls ble_gattc_disc_svc_by_uuid(), and also the callback, I would be happy to take a look. Thanks, Chris
