I am trying to implement heart rate service from external MCU using BGAPI. The MCU connect with BLE112 via Uart. System communicate with BLEGUI run on PC via a BLE112D.
My problem is: I don't know how to get the "handle" for function "ble_cmd_attributes_write(handle, offset, value_len, value_data)"?
When kick "Connect" from BLEGUI, the MCU receive 1 packet:
the function corresponding with that packet is:
msg->connection = 0
msg->bonding = 255
msg->address_type = 0
msg->flags = 5
I tried to assigned: handle = msg->connection. But it is not correct.
Thank you very much for your help,
Try reading through the following two examples carefully, they will show you how to discover a remote GATT database (i.e. get the list of characteristics and their handles over the air):
It may be good to start with the latter example because it is written for BLED112. The first example is written in BGScript but the basic sequence of commands and events is still the same.
You may also want to read through this introductory material if you haven't already done so:
In the heart rate sensor example, my application is server, BLEGUI is client. Client send "connect" command and after that send "enable notification". The Server send data every 1s.
My problem is I can not get the handle of the "heart rate" characteristic. In case of using script, base on "id="xgatt_hr"" on the gatt.xml file, we can treat it as handle and call "attributes_write(xgatt_hr,0,2,tmp(0:2))" easily. But my application using BGAPI, I can not see the "id="xgatt_hr"", so how can I get the handle of "heart rate" characteristic?
Just my temporary solution: I am wait for the packet "ble_evt_attributes_status()" from BLEGUI after enable "notification = true" then I get the handle inside struct "ble_msg_attributes_status_evt_t". Then I send command base on that handle and th
May I ask are there any way to get the handle of all characteristic from Server side. Because Handle is very important when call "write" command.
Did you go through the HR collector example? It includes some quite verbose comments about how the service and characteristic discovery works. I am copying the large comment block from the source file hr_collector.bgs below for your reference. All the relevant commands and events are listed there.
>> begin copy-paste
# ================================================================ # BASIC ARCHITECTURAL OVERVIEW: # The program starts, initializes the dongle to a known state, then starts # scanning. Each time an advertisement packet is found, a scan response # event packet is generated. These packets are read by polling the serial # port to which the BLE(D)11x is attached. # # The basic process is as follows: # a. Scan for devices # b. If the desired UUID is found in an ad packet, connect to that device # c. Search for all "service" descriptors to find the target service handle range # d. Search through the target service to find the heart rate measurement attribute handle # e. Enable notifications on the heart rate measurement attribute # f. Read and display incoming heart rate values until terminated # # FUNCTION ANALYSIS: # # 1. system_boot: # Sets scan parameters and initiates a scan with the "gap_discover" command. # # 2. gap_scan_response: # Raised during scanning whenever an advertisement packet is detected. The # data provided includes the MAC address, RSSI, and ad packet data payload. # This payload includes fields which contain any services being advertised, # which allows us to scan for a specific service. In this demo, the service # we are searching for has a standard 16-bit UUID which is contained in the # "uuid_hr_service" variable. Once a match is found, the script initiates # a connection request with the "gap_connect_direct" command. # # 3. connection_status # Raised when the connection status is updated. This happens when the # connection is first established, and the "flags" byte will contain 0x05 in # this instance. However, it will also happen if the connected devices bond # (i.e. pair), or if encryption is enabled (e.g. with "sm_encrypt_start"). # Once a connection is established, the script begins a service discovery # with the "attclient_read_by_group_type" command. # # 4. attclient_group_found # Raised for each group found during the search started in #3. If the right # service is found (matched by UUID), then its start/end handle values are # stored for usage later. We cannot use them immediately because the ongoing # read-by-group-type procedure must finish first. # # 5. attclient_find_information_found # Raised for each attribute found during the search started after the service # search completes. We look for two specific attributes during this process; # the first is the unique heart rate thermometer measurement attribute which has # a standard 16-bit UUID (contained in the "uuid_hr_measurement_characteristic" # variable), and the second is the corresponding "client characteristic # configuration" attribute with a UUID of 0x2902. The correct attribute here # will always be the first 0x2902 attribute after the measurement attribute # in question. Typically the CCC handle value will be either +1 or +2 from # the original handle. # # 6. attclient_procedure_completed # Raised when an attribute client procedure finishes, which in this script # means when the "attclient_read_by_group_type" (service search) or the # "attclient_find_information" (descriptor search) completes. Since both # processes terminate with this same event, we must keep track of the state # so we know which one has actually just finished. The completion of the # service search will (assuming the service is found) trigger the start of # the descriptor search, and the completion of the descriptor search will # (assuming the attributes are found) trigger enabling indications on the # measurement characteristic. # # 7. attclient_attribute_value # Raised each time the remote device pushes new data via notifications or # indications. (Notifications and indications are basically the same, except # that indications are acknowledged while notifications are not--like TCP vs. # UDP.) In this script, the remote slave device pushes heart rate measurements # out as notifications approximately once per second. These values are # displayed out UART1/Alt1 @ 115200,8/N/1 without flow control. # # ================================================================
If you need to know what is the handle of HR characteristics on the peripheral side, then have a look at the file names attributes.txt that is generated when you build your project. It includes list of handle values. See sample below:
the above example is from the "hr" sample project in the SDK.
The previous response I posted is related to how the client can get the handle from peripheral over the air.
the attributes.txt is correctly what I am looking for. Thank you very much