Central can´t find primary services on Ti SensorTag

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Mon, 26 Sep 2016 13:28:22 GMT

Np :) Great that you figured it out, and thanks for the update!

RE: Central can´t find primary services on Ti SensorTag

Vehring — Fri, 23 Sep 2016 12:58:41 GMT

I finally solved it.

First of all it was wrong that the notification and the configuration characteristic writes were not successful. The method i changed my code to read back the value was confusing me because the way i did the sensor was disconnected between setting the characteristics and reading the values back. For the period characteristic it didn´t matter because it´s stored permanently but the values of the config and the notification enable are getting discarded with the disconnection. i was too stupid.

So i concentrated back on the hvx events and why they are not occuring. This solution was easy. Before the config doesn´t enable at least on of the axis of gyro-, accelero- or magnetometer no data will be sent. The Userguide of the SensorTag 2 has a lack of information there. It just mentions that if axis are disabled the values will be zero but the length will always remain 18 bytes. Nowhere is said that if notifications are enabled but no axis are configured also no notification will come.

So what i learned on connecting the SensorTag 2 is:

The base UUID of a proprietary sensor has to be coded in reverse byte order
Proprietary UUID´s have to be registered in the softdevice
The sensorTag won´t send data is notifications are enabled and no axis is configured

Thanks for all your patience and help Petter!

RE: Central can´t find primary services on Ti SensorTag

Vehring — Fri, 23 Sep 2016 07:22:20 GMT

Yes, i get read responses now. it was my mistake.

However, the values remain unchanged if i write the notification or the configuration characteristic. If i write on the period characteristic the read response shows me that value changed successfully. I know that the length shouldn´t matter, but at the moment i see no difference between the characteristics except the length.

I now investigated the gatt_status on the BLE_GATTC_EVT_WRITE_RSP event. It´s 0x0 for the successful write of the period characteristic but also on the other unsuccessfull writes of the notification and the configuration characteristics :(

What i also obtained is that the data characteristic is not compliant with the documentation of the sensortag. I read all the characteristics of the movement service. For notification, configuration and period characteristics the length is correct but the data characteristic replies me a length of 12 bytes, even the documentation says it should be 18 bytes in every configuration setting. But in the end this also shouldn´t have an effect on the other characteristics i wanna write.

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Thu, 22 Sep 2016 08:39:21 GMT

The length shouldn't matter. So you get read responses now? And the values are unchanged after you have written to them? What is the gatt_status on the write responses?

RE: Central can´t find primary services on Ti SensorTag

Vehring — Wed, 21 Sep 2016 13:41:26 GMT

Okay i get responses now.

What turned out is that i can´t successfully write Notification (UUID=0x2902) and the configuration (UUID=0xAA82) but (!) the period characteristic (UUID=0xAA83). There i read the value first (it was default 0x64 which is default of 1s) and then i set it to 0x0A which indicates 100ms period for the notification of the movement sensor. This value i read back successfully. The difference between the characteristics is that notification and configuration have a length of 2 byte and the period characteristic just 1 byte.

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Wed, 21 Sep 2016 13:18:48 GMT

You can disregard offset and data in the response when you do a normal write request. Could you check the gatt_status for the operation? You don't get a read response? That's strange. You are sure that sd_ble_gattc_read() returns NRF_SUCCESS(0x00000000) when you call it?

RE: Central can´t find primary services on Ti SensorTag

Vehring — Wed, 21 Sep 2016 12:36:25 GMT

The notification enable is the same as for the nus_c example.

static uint32_t ti_cccd_configure(uint16_t conn_handle, uint16_t cccd_handle, bool enable)

{uint8_t buf[BLE_CCCD_VALUE_LEN];

buf[0] = enable ? BLE_GATT_HVX_NOTIFICATION : 0;
buf[1] = 0;

const ble_gattc_write_params_t write_params = {
    .write_op = BLE_GATT_OP_WRITE_REQ,
    .flags    = BLE_GATT_EXEC_WRITE_FLAG_PREPARED_WRITE,
    .handle   = cccd_handle,
    .offset   = 0,
    .len      = sizeof(buf),
    .p_value  = buf
};

return sd_ble_gattc_write(conn_handle, &write_params);}

The BLE_GATTC_EVT_WRITE_RSP says, that write_op == 0x1 handle == 3D len == 0x0 offset == 0x0 data == 0x40

Intuitively i would say something´s going wrong there. Why is len 0 and data is 0x40? 3D is the value of my cccd_handle.

if i perform a sd_ble_gattc_read() with my conn_handle, cccd_handle and offset 0 no BLE_GATTC_EVT_READ_RSP occurs.

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Wed, 21 Sep 2016 10:24:20 GMT

How are you enabling notifications? Are you sure that the CCCD is 0x0001? You can try to read it after it has been written to 0x0001. If the CCCD is 0x0001, I'm not really sure, then it must be something else that triggers the actualy sending of notifications.

RE: Central can´t find primary services on Ti SensorTag

Vehring — Wed, 21 Sep 2016 10:19:09 GMT

Unfortunately there is one more issue i have to overcome. After BLE_DB_DISCOVERY_COMPLETE occurs i store the handles and the cccd of the measurement characteristic. After i assign the handles and want to enable notifications for the measurement characteristic. But somehow i don´t receive any BLE_GATTC_EVT_HVX event. So up to this point everything runs but the data is missing. What can be the reason?

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Tue, 20 Sep 2016 14:38:55 GMT

Great! Let me know if there is anything else, if not maybe you can add an answer to your question? :)

RE: Central can´t find primary services on Ti SensorTag

Vehring — Tue, 20 Sep 2016 14:22:34 GMT

Oh a close look brought me back on track. In my ble_ti_on_db_disc_evt i asked if the discovered UUID type is BLE_UUID_TYPE_BLE. After changing to BLE_UUID_TYPE_VENDOR_BEGIN i discover the characteristics with UUID 0xAA81 till 0xAA83. So i guess now i´ll be able to make it run.

Thanks

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Tue, 20 Sep 2016 13:38:46 GMT

I'm not following. The types aren't advertised directly. You can see how the advertisment is built up in section B here. The AD type tells you if it is a Bluetooth SIG UUID (16 bit) or a propritary UUID (128 bit). And what is in the advertisment doesn't really matter, as long as you are able to identify the device you want to connect to.

Do you get any BLE_DB_DISCOVERY_COMPLETE events in db_disc_handler()?

RE: Central can´t find primary services on Ti SensorTag

Vehring — Mon, 19 Sep 2016 13:51:10 GMT

Sorry, i posted my comment as answer. So here again:

The sd_ble_gattc_characteristics_discover() was just a try because i read somewhere that there are different approaches to get the handle of the characteristics i want. However it was a dead end. The code i have still uses the same order that is given by all the examples. When the adv_report comes i check if it´s the right peripheral (by advertised service or name) and then i connect to it. When the BLE_GAP_EVT_CONNECTED event occurs i want to discover the services.

First i had everything in a multilink project but i copied it into a new example to identify the issues i have. The problem is still that the db discovery reports 0 services. I found out that the Ti advertises me the ble type "BLE_UUID_TYPE_BLE" and not "BLE_UUID_TYPE_VENDOR_BEGIN" even the UUID´s are custom. Is it okay that the base UUID still gets registered even the type ist "BLE_UUID_TYPE_BLE"?

I asked myself what´s going on with the registering of the custom UUID. When i register my base UUID the function returns me the uuid type, which is "0x02". There has to be a mismatch if the advertisement report offers me the service UUID with type 0x01. How do i have to align this?

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Thu, 15 Sep 2016 12:58:32 GMT

Are you sure you are not calling ble_db_discovery_start() several times? When are you calling it? When you get the BLE_GAP_EVT_CONNECTED event? You said above that you were doing "sd_ble_gattc_characteristics_discover() before executing ble_db_discovery_start()", are you doing that now? Why?

RE: Central can´t find primary services on Ti SensorTag

Vehring — Wed, 14 Sep 2016 15:24:59 GMT

Okay now i´m sure i have the right settings for the base UUID and so on. However the primary services discovery still responds that i found 0 services the command sd_ble_gattc_char_value_by_uuid_read gives some interesting result:

in p_value of the response i had 4 different values

0xFEED0303
0x58334C54
0x004CFF0B
0xAA800203

The last seems interesting to me but i couldn´t find how p_value is formated. Can somebody help me out?

RE: Central can´t find primary services on Ti SensorTag

Vehring — Wed, 14 Sep 2016 10:50:16 GMT

Basically my services also have a 128bit UUID. I can only register 16bit UUID´s with ble_db_discovery_evt_register, but if i understand right this is working if i register the right 2 bytes from the 128bit UUID.

I actually add the vendor specific UUID F000AA80-0451-4000-B000-000000000000 with UUID type 2 (sd_ble_uuid_vs_add). The event i register is the corresponding 16bit UUID "0xAA80", also with type 2 (ble_db_discovery_evt_register). The code is basically the same las the nus_c example.

Does base ID mean the 128bit UUID of the service i´m looking for?

RE: Central can´t find primary services on Ti SensorTag

Vehring — Tue, 13 Sep 2016 15:28:17 GMT

Unfortunately i don´t have a nRF dev pack here. I use a Taiyo Yuden evaluation board with a nRF51422. One thing i figured out is that the base UUID for the movement service has to be F000AA80-0451-4000-B000-000000000000 where the AA80 indicates the movement service. I could read that with the Ti SensorTag App for Smartphone. Now the ble_db_discovery_start get´s stuck with NRF_ERROR_BUSY. How can this happen?

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Tue, 13 Sep 2016 14:50:02 GMT

The first proprietary base UUID you add will have 0x02, the second 0x03 and so on. It doesn't matter how you connect to it. Maybe a sniffer trace would help explaining what is going on? You can use nRF Sniffer.

RE: Central can´t find primary services on Ti SensorTag

Vehring — Tue, 13 Sep 2016 14:14:11 GMT

Unfortunately i still can´t discover services. I added the registering of the base UUID of the SensorTag which should be F0000000-0451-4000-B000-000000000000 according to link text

Is it sure that every proprietary service uses the UUID Type BLE_UUID_TYPE_VENDOR_BEGIN (0x02)?

In my program i hand over the UUID of the Movement Service (0xAA80) which i also use to identify my sensortag in the adv_report and then connect to it. This should be okay, right?

RE: Central can´t find primary services on Ti SensorTag

Vehring — Tue, 13 Sep 2016 12:18:50 GMT

No it doesn´t use SIG base UUID. You gave me a good hint, i didn´t knew i have to register that proprietary base UUID at the softdevice.

I have to check but i have the hope it´s the problem i have.

RE: Central can´t find primary services on Ti SensorTag

Petter Myhre — Tue, 13 Sep 2016 12:04:46 GMT

CSC uses the Bluetooth SIG base UUID, but I don't think the other UUIDs you are looking for uses it. They probably use a proprietary base UUID. Could it be that you have skipped registering the base with the SoftDevice? And that you give an incorrect UUID to the database discovery module? Have a look at how it is done in ble_nus_c_init() in the ble_app_uart_c example.

RE: Central can´t find primary services on Ti SensorTag

Vehring — Mon, 12 Sep 2016 07:28:14 GMT

Now i execute sd_ble_gattc_characteristics_discover() before executing ble_db_discovery_start(). In this case the primary service discovery returns BLE_DB_DISCOVERY_COMPLETE but the characteristics of the motion service (0xAA80) all have UUID 0x000, but they should have 0xAA81 for the measurement data, 0xAA82 for the configuration and 0xAA83 so i can´t store any CCCD-handle. How can this happen? If i perform sd_ble_gattc_char_value_by_uuid_read the return value is 0x11. What should this mean? Invalid data?